Google Earth Engine позволяет работать с растровыми данными, хранящимися в ваших собственных сегментах Google Cloud Storage (GCS). Используя оптимизированные для облака файлы GeoTIFF (COG), вы можете получать доступ к своим данным и анализировать их непосредственно в Earth Engine, не загружая пиксели в хранилище объектов Earth Engine.
Такой подход с облачной инфраструктурой дает ряд преимуществ, особенно при управлении большими наборами данных или интеграции Earth Engine в более широкие рабочие процессы Google Cloud или внешние инструменты и платформы.
Зачем использовать Cloud Storage и COG?
- Гибкость и совместимость. Храните данные в стандартных сегментах Cloud Storage, к которым можно получить доступ с помощью других инструментов и сервисов. Независимо от того, загружаете ли вы данные напрямую или экспортируете их из Earth Engine, Cloud Storage служит единым источником достоверной информации как для Earth Engine, так и для внешних рабочих процессов.
- Управление данными и исходящим трафиком. Хранение данных в Cloud Storage обеспечивает стандартные возможности управления хранилищем объектов. Это позволяет скачивать, переносить и передавать данные с помощью функций Cloud Storage, таких как Requester Pays или общедоступные сегменты, а также управлять доступом с помощью стандартного Cloud IAM.
- Гибкое масштабирование. Избегайте ограничений на хранение в Earth Engine. Cloud Storage предоставляет практически неограниченное хранилище с возможностью самостоятельного масштабирования до петабайтов.
- Быстрая регистрация. Регистрация COG-файла происходит быстро, потому что Earth Engine считывает только метаданные (например, проекцию и размеры) из заголовка файла для индексации и проверки. Фактические данные пикселей остаются в Cloud Storage и считываются по запросу во время вычислений, поэтому отдельная задача приема данных не требуется.
Рабочие процессы COG в Earth Engine
Earth Engine поддерживает двунаправленные рабочие процессы с COG в Cloud Storage: вы можете считывать COG непосредственно из GCS в Earth Engine и записывать результаты вычислений из Earth Engine непосредственно в GCS в виде COG.
Чтение COG из Cloud Storage
Чтобы добавить COG-файлы, размещенные в GCS, в Earth Engine, можно воспользоваться одним из двух вариантов:
Прямая загрузка (
ee.Image.loadGeoTIFF). Загрузка одного изображения напрямую с помощью его URI в GCS. Этот вариант подходит для быстрых тестов, специального анализа или временных данных:JavaScript
var image = ee.Image.loadGeoTIFF('gs://google-sample-bucket/my_image.tif');Python
image = ee.Image.loadGeoTIFF('gs://google-sample-bucket/my_image.tif')Полные примеры можно найти в разделе Изображения из файлов Cloud GeoTIFF.
Зарегистрированные объекты. Зарегистрируйте один или несколько файлов COG как объекты Earth Engine, используя манифест загрузки (см. руководство по регистрации COG). Это рекомендуемый способ для рабочих процессов, особенно при создании коллекций изображений.
| Функция | Прямая загрузка (loadGeoTIFF) |
Зарегистрированный объект (манифест) |
|---|---|---|
| Настройка | Нет (только URI GCS) | Манифест (клиент Python, CLI или REST) |
| Эффективность | Стандартный (заголовок читается при чтении). | Оптимизированный (индексируется при создании) |
| Управляющие | Объект не создан | Учитывается в квоте на количество объектов, а не на хранилище. |
| Пример использования | Прототипирование, специальный анализ | Рабочие процессы, требующие быстрого чтения. |
Запись COG в Cloud Storage
Чтобы сохранить результаты вычислений Earth Engine в виде COG в корзине Cloud Storage, используйте функцию пакетного экспорта Export.image.toCloudStorage (см. Экспорт изображений) и задайте для параметра cloudOptimized значение true в formatOptions. Это указывает Earth Engine на необходимость скомпилировать изображение и записать его непосредственно в сегмент GCS в качестве полностью совместимого COG.
Поддерживаемые местоположения сегментов Cloud Storage
Чтобы Earth Engine мог получить доступ к вашему сегменту Cloud Storage, он должен находиться в одном из следующих регионов или макрорегионов центров обработки данных:
- Макрорегион
us - Любой двойной регион США, включающий
us-central1 - Регион
us-central1
Если сегмент находится в другом региональном центре обработки данных, Earth Engine отклонит запросы на регистрацию и чтение. Earth Engine получает доступ к COG, хранящимся исключительно в сегментах Google Cloud Storage. Внешние поставщики услуг облачного хранения данных и общие URL HTTP не поддерживаются.
Спецификации экспорта COG в Earth Engine
При экспорте результатов анализа из Earth Engine с помощью Export.image.toCloudStorage с cloudOptimized: true в formatOptions встроенный экспортер Earth Engine автоматически применяет следующие стандарты:
- Структура файла. Создает файл BigTIFF (
BIGTIFF=YES) с внутренней разбивкой на фрагменты (TILED=YES) и копирует все обзоры в начало файла. - Автоматические обзорные изображения. Если размеры выходного растра составляют 512 x 512 пикселей или больше, Earth Engine автоматически создает пять уровней обзорных изображений с масштабом, равным степени двойки (
[2, 4, 8, 16, 32]). Earth Engine динамически выбирает метод передискретизации обзорных изображений на основе типа данных выходных пикселей: кубическая передискретизация для изображений с плавающей запятой и передискретизация по ближайшему соседу для всех остальных целочисленных или дискретных изображений. - Сжатие и разбиение на фрагменты по умолчанию. Earth Engine экспортирует COG-файлы с разбиением на фрагменты размером 256 x 256 пикселей и сжатием LZW (
COMPRESS=LZW). Сжатие и размеры фрагментов нельзя настроить вformatOptions. - Автоматическое разбиение на фрагменты. Если экспортируемое растровое изображение слишком велико (превышает 4 ГиБ в несжатом виде), Earth Engine автоматически разбивает его на несколько пространственных фрагментов с названием
baseFilename-yMin-xMin(см. Экспорт больших файлов). - Превышение ограничений на сегментирование. Чтобы экспортировать большие растровые изображения (до 16 ГиБ без сжатия и 131 072 пикселей на сторону) в виде одного файла без сегментирования, укажите
fileDimensionsвнутриformatOptions. Каждый размер должен быть положительным целым числом, кратным размеру фрагмента (по умолчанию – 256, например[65536, 65536]). ПосколькуfileDimensionsзадает максимальный размер файла, а не выходную граничную рамку, передача большого верхнего предела приводит к экспорту в один файл без необходимости точных расчетов сетки. Вы также можете передатьskipEmptyFiles: true, чтобы предотвратить создание пустых фоновых фрагментов. - Оптимизация. При настройке экспорта большого объема данных оцените, что для вас важнее:количество файлов или скорость экспорта. Если указать меньшие значения
fileDimensionsилиshardSize, будет создано больше фрагментов файлов, но это позволит максимально эффективно использовать параллельную обработку на серверах и ускорить экспорт. Если же вы отмените ограничения, чтобы создать один большой файл, то управлять им и делиться данными будет проще, но экспорт может занять больше времени из-за сборки одного файла и узких мест ввода-вывода. Очень большие однофайловые экспорты COG, приближающиеся к пределу в 16 ГиБ в несжатом виде (особенно изображения, которые плохо сжимаются), также могут превышать временную емкость хранилища во время обзора и сборки COG. Если экспорт не удался, попробуйте разбить файл на более мелкие части или преобразовать стандартный экспорт GeoTIFF внешним образом.
Как настроить создание COG за пределами Earth Engine
Экспорт напрямую с помощью cloudOptimized: true – самый простой способ создать готовые к использованию COG для большинства рабочих процессов. Однако вы также можете экспортировать стандартный GeoTIFF (cloudOptimized: false, по умолчанию) и самостоятельно преобразовать его в COG с помощью внешних инструментов, таких как GDAL. Двухэтапный экспорт и преобразование могут быть полезны, если вам нужно:
- Настройте сжатие и макет. Выберите размер блоков (например,
512x512), предикторы, методы передискретизации или кодеки сжатия (например,ZSTD) в соответствии с набором данных (см. подготовку файлов COG). - Избегайте ошибок, связанных с нехваткой места, при экспорте больших файлов. Если при экспорте не создавать обзор и не переписывать макет COG, то снижается нагрузка на память и временное хранилище, поэтому при экспорте больших файлов реже возникают ошибки, связанные с нехваткой места.
- Сокращение времени экспорта Earth Engine. Перенос создания обзора и форматирования COG в собственную вычислительную среду сокращает фазу экспорта Earth Engine.
Сведения о расходах и классах хранилища
При анализе зарегистрированных объектов COG операции чтения из Earth Engine не приводят к списанию средств за операции чтения из Cloud Storage или извлечение данных из вашего проекта Google Cloud.
Cloud Storage взимает плату в основном за стандартное ежемесячное хранение данных (ГБ/месяц) и за передачу данных внешних клиентов или исходящий трафик (в зависимости от местоположения сегмента и конфигурации сети клиента).
Рекомендации по классам хранилища
- Стандартное хранилище (рекомендуется). Лучше всего подходит для активных рабочих процессов Earth Engine. Поскольку для него не действуют правила минимальной длительности хранения, вы можете перезаписывать, обновлять и удалять временные COG-файлы, не опасаясь штрафов за раннее удаление. Кроме того, если вы или ваши соавторы получаете доступ к сегменту с помощью настольного ГИС-ПО, скриптов GDAL или блокнотов машинного обучения вне Earth Engine, при использовании стандартного хранилища не взимается никаких дополнительных сборов за извлечение.
- Хранилища Nearline, Coldline и Archive. Все классы Cloud Storage обеспечивают такой же низкий уровень задержки и пропускную способность, как и стандартное хранилище, поэтому при использовании более холодных уровней хранения в Earth Engine не возникает снижения производительности при чтении. Хотя при вычислениях в Earth Engine можно считывать данные из этих уровней без оплаты за извлечение, правила хранения в Cloud Storage предусматривают строгие минимальные сроки хранения (30 дней для Nearline, 90 дней для Coldline и 365 дней для Archive). Если изменить или удалить файлы до истечения минимального срока хранения, взимается дополнительная плата за досрочное удаление. Кроме того, за доступ к холодным объектам из любого внешнего клиентского инструмента взимается высокая дополнительная плата за извлечение данных.
Подробные сведения о розничных ценах и правилах в отношении минимальной продолжительности хранения приведены в руководстве по ценам на Google Cloud Storage.
Общий рабочий процесс
Обычно при работе с COG в Earth Engine выполняются следующие действия:
Для импорта внешних данных:
- Оптимизация. Преобразуйте растровые файлы в формат COG с помощью внешних инструментов, например GDAL, локальных скриптов или облачных конвейеров обработки.
- Загрузка. Загрузите данные о себестоимости реализованных товаров в поддерживаемый сегмент Cloud Storage, расположенный в регионе
us-central1или в макрорегионе США. - Разрешения. Убедитесь, что у вас и у всех соавторов проекта есть доступ к файлам на чтение в Cloud Storage (см. разрешения COG).
- Зарегистрируйте COG. Используйте клиентскую библиотеку Python, инструмент командной строки
earthengineили REST API, чтобы зарегистрировать COG как объекты Earth Engine (см. раздел Регистрация COG).
Для экспорта результатов:
- Экспорт. Выполните пакетный экспорт из Earth Engine в Cloud Storage, задав для параметра
cloudOptimizedзначениеtrue(см. Экспорт изображений). - Регистрация (необязательно). Зарегистрируйте экспортированный COG в Earth Engine как новый объект для дальнейшего анализа (см. регистрацию COG).
Готовы начать? Чтобы зарегистрировать первый объект, следуйте подробному руководству по регистрации контента, принадлежащего вам.