Научная обработка данных спутниковых изображений на Google Cloud Platform

1. Вступление
2. Описание процесса расчета
3. Входные данные
4. Данные изображения
5. Дорожные справочные данные
6. Дизайн решения на облачной платформе Google
7. Основными компонентами решения являются:

В рамках PoC-проекта на 5 человеко-дней с CloudEO AG мы создали приложение на Google App Engine и Google Cloud Storage для высокопараллельной обработки данных спутниковых изображений. Облачная инфраструктура Google оказалась масштабируемой, поэтому время обработки может быть сокращено в 12 раз по сравнению с современным аппаратным обеспечением ПК. Параллельно затраты составляли всего 3 € (4 $) на обработку одной спутниковой сцены размером около 5 ГБ.

Вступление

CloudEO AG со штаб-квартирой в Мюнхене создает новый облачный рынок геоинформационных услуг. Он соединяет геоданные, геоинформацию и геоприложения на безопасной и профессиональной гибридной облачной платформе.
Целью PoC было оценить ценность облачной инфраструктуры Google для параллельной обработки данных спутникового изображения с точки зрения производительности, а также экономической эффективности.

Описание процесса расчета

Конкретный процесс, который должен быть реализован, - это сопоставление спутниковых изображений наблюдения Земли с векторами дорог путем корреляции, чтобы точно определять местоположение изображения на земле, используя векторы дорог в качестве эталона. Этот процесс также известен как геопривязка , Для выполнения этой задачи изображения делятся на предварительно определенное количество подизображений (также называемых корреляционными ячейками), и для каждого подизображения вектор смещения в измерении x и y рассчитывается для максимальной корреляции с опорным изображением дороги. Полное количество шагов, которые нужно выполнить для каждого подизображения, следующее:

1. Извлечь спутниковое изображение и изображение дороги с заданными координатами и размерами
2. Примените краевой фильтр к спутниковому изображению, чтобы извлечь края.
3. Соотнесите отфильтрованный по краям подизображение с подизображением дороги для данного числа смещений x / y и определите комбинацию x / y с максимальной корреляцией.

Рисунок 1: Массив из 676 корреляционных ячеек с наложенными дорожными векторами (синего цвета)
через спутниковую сцену RapidEye над Германией.

Входные данные

В качестве репрезентативного примера из реальной жизни PoC был выполнен с одной спутниковой сценой над Германией с разрешением около 5 м относительно земли.
Параметры этой сцены являются типичными значениями:

Данные изображения

Формат: необработанный байтовый массив
Пикселей: 44000
Пиксельные столбцы: 40000
Байт на пиксель 1 (оттенки серого)
Файлы / группы: 3

Дорожные справочные данные

То же, что данные изображения, один файл
Байт на пиксель: 1

Таблица, содержащая шаги обработки данных, была предоставлена ​​в виде файла CSV со следующей структурой:

Поле Описание Тип Определяет тип шага обработки (извлечение и фильтрация изображения, извлечение дорог, корреляция). Полоса, в которой должен обрабатываться полоса (файл), X x позиция в файле изображения для извлечения или x смещение для корреляции Y y позиция в файле изображения для извлечения y смещение для корреляции Xdim горизонтальный размер подизображения Xdim вертикальный размер подизображения

Дизайн решения на облачной платформе Google

Для решения задачи с использованием облачной платформы Google мы решили хранить спутниковые снимки на Google Cloud Storage , Каждый файл имеет размер около 1,6 ГБ, и у нас их было четыре: три спутниковых изображения (красный, зеленый и синий канал) и одно дорожное эталонное изображение.
Для обработки данных изображения у нас были альтернативы использования App Engine или Compute Engine. Поскольку нам пришлось бы организовать Compute Engine с помощью приложения App Engine, а область применения PoC составляла всего 5 человеко-дней, мы решили полностью решить задачу, используя App Engine и Java в качестве языка программирования.

Следующее изображение иллюстрирует проект решения высокого уровня:

Основными компонентами решения являются:

• Веб-сервлет, показывающий простой пользовательский интерфейс, который позволяет устанавливать некоторые параметры конфигурации, запускать новое задание или видеть текущее состояние задания.
• Ядро приложения (контроллер), управляющее обработкой данных изображения. Он читает этапы обработки и помещает новые задачи в очередь задач. Мы также реализовали использование Pipeline API как альтернатива. В обоих случаях мы взаимодействуем с хранилищем данных App Engine для хранения конфигурации отдельных задач.
• Дочерние задачи, которые порождаются API-интерфейсом очереди задач / конвейера автоматически и работают с вложенными изображениями данных изображения. Они получают доступ к данным изображения, расположенным в облачном хранилище Google, с помощью API Google Cloud Storage Java , API предоставляет методы для позиционирования курсора чтения в определенном месте внутри файла, чтобы можно было читать подизображения без необходимости считывания всего файла.
• Дочерние задачи также будут выполнять саму обработку изображения (обнаружение границ и корреляция).
• Результаты расчетов сохраняются в хранилище данных для последующего отображения / загрузки.

Результаты

Мы выполнили 3 различных полных теста производительности на данных с различными конфигурациями для параметров очереди задач (максимальная скорость, размер сегмента, максимальное число одновременных операций), класса экземпляра внешнего интерфейса, отложенных задержек и пустых экземпляров. Решение Pipeline API не использовалось для тестовых запусков, поскольку оно вызвало значительно больший объем операций записи в хранилище данных по сравнению с нашим собственным решением.

Оказалось, что использование довольно консервативных значений для параметров очереди задач (макс. Скорость 10 / с, размер сегмента 100, макс. Одновременное число 200) и низкий класс экземпляра дали лучшие результаты в производительности и затратах. Повышение производительности класса экземпляра или пропускной способности очереди задач даже отрицательно сказалось на общем времени выполнения, возможно, из-за большого количества одновременных запросов к данным Google Cloud Storage.

С описанной выше конфигурацией работа может быть выполнена менее чем за 1 час с затратами около 4 $. Это сокращение полного времени выполнения в 12 раз по сравнению с текущей реализацией, используемой CloudEO. Директор по технологиям в CloudEO сказал, что затраты в 4 $ практически ничтожны в общем процессе создания полной спутниковой сцены. Мы потратили ок. 5 человеко-дней на внедрение и тестирование производительности, общая продолжительность проекта составила около 3 недель. В целом мы можем доказать, что Google App Engine хорошо подходит для выполнения научных расчетов с высокой степенью распараллеливания.

Если у вас есть дополнительные вопросы, пожалуйста, не стесняйтесь обращаться к нам.

Похожие

Комментарии