Обработка данных искусственной диафрагмы (SAR) в Azure

Статья
06/01/2023

SAR — это форма радара, которая используется для создания двухмерных изображений трехмерных реконструкции объектов, таких как пейзажи. SAR использует движение радиолокационной антенны по цели, чтобы обеспечить более точное пространственное разрешение, чем обычные стационарные радиолокационные радары.

Обрабатывается

Данные удаленного датчика и данных SAR всегда обрабатывались линейным образом из-за того, как были написаны алгоритмы. Исторически данные обрабатывались на отдельных и power-машинах, которые можно масштабировать только по вертикали. Существует ограниченный способ масштабирования этого процесса вертикально и горизонтально, так как компьютеры, используемые для обработки данных, были дорогостоящими. Из-за повышения стоимости не удалось обработать эти данные в режиме реального времени или почти в режиме реального времени. После изучения проблемного пространства мы смогли придумать альтернативные способы горизонтального масштабирования этого процесса.

Масштабирование с помощью AKS и рабочих процессов Argo

Обработка данных SAR, особенно необработанную обработку L0, обычно включает в себя инструменты для конкретного поставщика, а не программное обеспечение с открытым исходным кодом. Таким образом, масштабируемый конвейер обработки должен иметь возможность выполнять двоичные файлы, зависящие от поставщика, а не полагаться на доступ к исходному коду для изменения алгоритма и горизонтального масштабирования с помощью таких технологий, как Apache Spark. Контейнеризация позволяет поставщику упаковать двоичные файлы в контейнер, а затем выполняться в большом масштабе. Хотя производительность обработки данного изображения не увеличится, многие изображения можно обрабатывать параллельно. Служба Azure Kubernetes является естественным подходом для выполнения контейнерного программного обеспечения в большом масштабе. Рабочие процессы Argo предоставляют низкоуровневый подход Kubernetes для выполнения конвейеров в любом кластере Kubernetes. Эта архитектура позволяет горизонтально масштабировать конвейер обработки, который использует предоставленные поставщиком двоичные файлы и (или) программное обеспечение с открытым кодом. Хотя обработка любого отдельного файла или образа не будет происходить быстрее, многие файлы могут обрабатываться одновременно параллельно. Благодаря гибкости AKS каждый шаг в конвейере может выполняться на оборудовании, которое лучше всего подходит для инструмента, например GPU, большого количества ядер или увеличенной памяти.

Необработанные продукты получаются приложением наземной станции, которое, в свою очередь, записывает данные в Хранилище BLOB-объектов Azure. С помощью подписки Сетка событий Azure уведомление предоставляется Центры событий Azure при записи нового образа продукта в хранилище BLOB-объектов. События Argo, работающие на Служба Azure Kubernetes, подписываются на уведомление Центры событий Azure и после получения события активирует рабочий процесс Argo Workflows для обработки изображения.

Рабочие процессы Argo задаются с помощью пользовательского определения ресурсов Kubernetes, позволяющего создавать daG или простой конвейер, определяя объекты Kubernetes. Каждый шаг в конвейере или DAG может запускать модуль Pod Kubernetes, выполняющий работу. Модуль Pod может запускать простой скрипт оболочки или выполнять код в пользовательском контейнере, включая выполнение средств, относящихся к поставщику, для обработки продуктов удаленного датчика. Так как каждый шаг в конвейере является другим объектом Kubernetes, обычные запросы ресурсов Kubernetes используются для указания требований шага. Например, для завершения работы средства, зависяющего от поставщика, может потребоваться GPU или узел с высокой памятью и (или) ядрами. Эти требования можно указать с помощью запросов ресурсов Kubernetes и сопоставления Kubernetes и /или nodeSelectors. Kubernetes сопоставляет эти запросы с узлами, которые могут удовлетворить потребности, если такие узлы существуют.

При использовании Служба Azure Kubernetes это обычно включает создание пулов узлов с соответствующим номером SKU вычислений Azure для удовлетворения потребностей потенциальных конвейеров. Эти пулы узлов можно задать для автоматического масштабирования, чтобы ресурсы не потреблялись при выполнении шагов конвейера, требующих их выполнения.

Обработка с помощью Azure Synapse

Подход к использованию Azure Synapse немного отличается от обычного конвейера. Как правило, многие фирмы по обработке данных уже имеют алгоритмы обработки данных. Возможно, они не хотят переписать алгоритмы, которые уже написаны, но им может потребоваться способ горизонтального масштабирования этих алгоритмов. Здесь показан подход, с помощью которого они могут легко запускать код на распределенной платформе, например Apache Spark, и не беспокоиться о работе со всеми сложностями при работе с распределенной системой. Мы пользуемся векторизацией и архитектурой SIMD, где мы обрабатываем несколько строк одновременно, а не обрабатываем одну строку одновременно. Эти функции относятся к Кадру данных Apache Spark и JVM

Прием данных

Данные удаленного датчика отправляются на земную станцию. Приложение наземной станции собирает данные и записывает данные в большой двоичный объект служба хранилища.

Преобразование данных

Большой двоичный объект служба хранилища отправляет событие в Службу "Сетка событий" о созданном файле.
Event-Grid уведомляет функцию, зарегистрированную для получения события.
Функция активирует конвейер Spark Azure Synapse. Этот конвейер имеет собственную библиотеку и конфигурацию, необходимую для запуска задания Spark. Задание Spark выполняет тяжелые вычисления и записывает результат в хранилище BLOB-объектов, где его можно использовать при любых подчиненных процессах.

В этом подходе с помощью Apache Spark мы приклеим библиотеку, которая имеет алгоритмы с JNA. JNA требует определить интерфейсы для машинного кода и выполнить тяжелый подъем для преобразования данных в собственную библиотеку и из собственной библиотеки в доступные типы Java. Теперь без основной перезаписи можно распределить вычисления данных на узлах и на одном компьютере. Обычное выполнение Spark в этой модели выглядит следующим образом.

Рекомендации

Size	Ядра	Память (ГБ)	Узлы	Исполнитель	Стоимость (USD)
Небольшой	4	32	20-200	2-100	11.37 до 113.71
Средняя	8	64	20-200	2-100	22.74–227.42
Большой	16	128	20-200	2-100	45.48 до 454.85
Очень большая	32	256	20-200	2-100	90.97 до 909.70
Экстрабольшой	64	512	20-200	2-100	181.94 до 1819.39

Size	Time(mins)
Небольшой	120
Средняя	80
Большой	67
Очень большая	50
Экстрабольшой	40

Конфигурация Spark

Имя свойства	Стоимость
Spark.driver.maxResultSize	2 ГБ
Spark.kryoserializer.buffer.max	2000
Spark.sql.shuffle.partitions	1000

Указанная выше конфигурация использовалась в случае использования BYOLB, так как было много данных, которые были перенесены из исполнителя и узлов драйвера. Конфигурации по умолчанию не были достаточно для обработки варианта использования, когда мы перемещали результаты в составе кадра данных. Мы могли бы попробовать трансляцию данных, но так как они были обработаны в рамках трансляции кадра данных, значения не были выбраны, так как мы хотели преобразовать каждую строку кадра данных.

Версия Spark

Мы использовали Apache Spark 3.1 с Scala 2.12 для разработки конвейеров. Эта версия совместима с Java 11, которая имеет улучшения сборщика мусора по сравнению с Java 8.

Абстракция данных

Кадры данных

Оптимальный вариант в большинстве случаев.
Предоставляет оптимизацию запросов через Catalyst.
Комплексное создание кода.
Прямой доступ к памяти.
Низкие накладные расходы при сборке мусора.
Не так удобно для разработчиков, как наборы данных, так как нет проверка времени компиляции или программирования объектов домена.

Устойчивые распределенные наборы данных (RDD)

Вам необязательно использовать наборы RDD, если только вам не нужно создать пользовательский RDD.
Отсутствует оптимизация запросов через Catalyst.
Отсутствует комплексное создание кода.
Высокие накладные расходы при сборке мусора.
Необходимо использовать устаревшие API-интерфейсы Spark 1.x.

Потенциальные варианты использования

Цифровая обработка сигналов
Операции с необработанными вспомогательными данными.
Обработка изображений и обработка.
Вычисление тяжелых задач, которые должны быть распределены.

Соавторы

Эта статья обновляется и поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник

Харджит Сингх | Старший инженер-архитектор
Брайан Потеря | Главный архитектор инженеров

Дополнительные участник:

Никхил Манчанда | Главный менеджер по проектированию
Билли Ринальди | Главный менеджер по проектированию
Джоуи Фрейзи | Главный менеджер по проектированию
Кэти Смит | Специалист по обработке и анализу данных
Стив Труитт | Главный диспетчер программ