Развитие методов параллельной обработки спутниковых данных

Стремительное развитие национальных и международных систем ДЗЗ привело к доступности большого количества спутниковой информации для потребителя, в том числе с российских приборов и спутников. Это привело к существенному расширению области применения спутниковых данных, и, соответственно, к резкому возрастанию числа информационных продуктов, которые необходимо получать на их основе. В результате, для обработки как «сырых» данных, так и информационных продуктов требуется все больше вычислительных ресурсов.

Рассмотрим структуру вычислительного комплекса, существующего в ИКИ РАН для обработки и хранения данных ДЗЗ, которая проиллюстрирована на рисунке 1.
 

 Рисунок 1 - Схема комплекса обработки данных

Кластер серверов (станций) обработки, используемых в ИКИ РАН, состоит на данный момент из множества выделенных компьютеров (преимущественно 1-юнитовых).  Каждая машина имеет в наличии от 8 до 16 процессорных ядер и от 8 до 32 Гигабайт оперативной памяти. В рамках разработанной в ИКИ РАН архитектуры построения системы обработки спутниковых данных используется понятие «задание», как элементарной единицы выполнения обработки, которой соответствует совокупность требуемого набора данных, необходимого программного обеспечения и инструкций по его применению. До недавнего времени на каждой станций обработки в каждый момент времени выполнялось только одно задание на обработку. Однако такой вариант оказывается недостаточно эффективным, особенно если учесть, что некоторые средства обработки 32-разрядные и/или 1-процессорные. Такие приложения имеют ограничение в 3 Гб занимаемой оперативной памяти и, таким образом, могут быть запущены одновременно в несколько потоков в рамках одной сессии обработки, без особого ущерба для производительности каждого экземпляра процесса. Это позволяет создать высокую нагрузку и, как следствие, увеличить скорость обработки исходных данных.

Рассмотрим время, необходимое на обработку небольших легких заданий при параллельном запуске от 1 до 10 потоков на одном обработчике. Всего 20 заданий 500 Мб общим весом. Характеристики обработчика – 16 Гб оперативной памяти, 8 ядер, скорость диска - 100 мб/c. Время обработки полного комплекта данных для различного числа потоков приведено на рисунке 2.

 Рисунок 2 – Время обработки полного комплекта данных при параллельном выполнении заданий

Видно, что при использовании такой схемы, можно получить выигрыш почти в 3 раза по скорости уже на 5 потоках. Дальнейшее увеличение числа одновременно обрабатываемых заданий уже не приносит существенной пользы. Нужно отметить, что расчет количества потоков может быть произведен как статически, так и динамически, в зависимости от количества ядер и оперативной памяти конкретного обработчика.

Другой вариант распараллеливания можно применить, если требуется обработать большое количество файлов в рамках одного задания. При этом суммарный объем обрабатываемых данных не позволяет одновременно запускать несколько заданий, из-за ограниченного объема жесткого диска обработчика. Тогда файлы можно разделить на несколько частей, к примеру, положив их в разные директории. Каждая часть может быть обработана независимо (и одновременно). В примере представлена предобработка данных для создания композита данных спутника Landsat 8, а именно построение масок облачности. На входе 400 сцен, 200 Гб общим весом, 12 ядерный процессор с 24 Гб оперативной памяти.

Нужно отметить, что в данной обработке некоторые части также распараллелены внутри кода через CreateThread, что, по сути, приводит к некоторой избыточности, так что применять данный подход следует с осторожностью, как видно из графика, можно получить даже замедление суммарной скорости обработки. На данном графике (рисунок 3) по вертикали отмечены часы, затраченные на обработку, по горизонтали – число потоков (порций данных).

 

Рисунок 3 – Время для случая с параллельной обработкой комплектов

Также встречаются ситуации, когда файлов много, но разделение их на части невозможно. В качестве примера можно привести задачу интерполяции временных серий данных, полученных с использованием прибора MODIS. Интерполяция каждой точки временного ряда может быть выполнена независимо друг от друга. В этом случае внутри операции можно с легкостью использовать thread-ы. На следующем графике, приведенном на рисунке 4, показаны времена при использовании такого распараллеливания кода. По вертикали отложено время в часах, а по горизонтали количество потоков (threads). На входе 194 файла MODIS со спутников Terrra и Aqua в синусоидальной проекции, на выходе 97 файлов интерполированных значений индексов NDVI. Обработчик имеет 16 ядер и 24 Гб. оперативной памяти.

 
Рисунок 4 - Вариант с проведением параллельной обработка при помощи метода CreateThread

Отсутствие выигрыша при увеличении количества потоков до 16 объясняется ограничением дискового массива, он не может отдавать данные с требуемой скоростью. Как показывает практика это основное препятствие (наряду со скоростью получения данных с сервера по сети) на пути к ускорению вычислений.

На основании проведенного исследования была показана эффективность применения рассматриваемых подходов к распараллеливанию обработки в рамках одного вычислительного узла. Все представленные варианты в настоящее время внедрены и используются для повышения эффективности выполнения различных задач по обработке спутниковых данных. При этом они дают максимальный выигрыш практически в три раза. Избыточное распараллеливание также можно использовать, но требуется предварительное тестирование, так как оно может привести и к падению эффективности выполнения обработки, как показано на рисунке 3.