Вчера мы рассматривали проблему управления накладными расходами в сложных конвейерах обработки больших данных на примере использования Apache AirFlow в агрегаторе аренды частного жилья Airbnb. Сегодня разберем, как именно инженеры компании решили проблему роста накладных расходов, отделив бизнес-логику от логики оркестрации в конвейерах Spark-заданий. Читайте далее про принципы проектирования Big Data Pipeline’ов в соответствии с лучшими практиками DataOps.
Как спроектировать Data Pipeline: отличия бизнес-логики от логики оркестрации
Обычно конвейеры обработки данных отражают структуру базового приложения. При этом можно попасть в ситуацию, когда задания отправляются в кластер через скрипт Spark-submit, предоставляемый Apache Spark. Скрипту нужно предоставить класс, который соответствует одной задаче в конвейере. Как правило, классы разрабатываются в соответствии с традиционными принципами программной инженерии, выполняя одну операцию преобразования с узкой областью видимости. Таким образом, логика оркестрации существует отдельно от бизнес-логики, что является, с одной стороны, идеологически верным, но, с другой стороны – вызывает проблемы рассинхронизации. Например, внесение изменений в data pipeline требует скоординированного развертывания изменений в нескольких системах, что зачастую выполняется вручную. Это может источником новых ошибок и дополнительным «пожирателем ресурсов», таких как время инженера Big Data. Поэтому, в лучших практиках DataOps, бизнес-логика pipeline’а должна быть спроектирована так, чтобы ее можно было поддерживать и масштабировать, а логика оркестрации – таким образом, чтобы обеспечить максимальную производительность, отслеживаемость и надежность конвейера обработки больших данных.
Несмотря на очевидность этого утверждения, на практике бизнес-конструкции и конструкции оркестровки, то есть фактические классы, которые определяют бизнес-операции и логику оркестрации, объединяются вместе, при этом конфликтуя друг с другом. В частности, логические абстракции с узкой областью видимости при непосредственном сопоставлении с DAG приводят к конвейеру, чрезмерная ширина или глубина которого может вызвать значительные накладные расходы. Поэтому дата-инженеры Airbnb решили создать в своих приложениях слой между бизнес-логикой и логикой оркестровки, который позволит удовлетворить потребности каждой системы. Важнейшей целью здесь было полное отделение оркестровки конвейера от бизнес-логики, чтобы структуры оркестрации минимизировала накладные расходы, а структура бизнес-логики уменьшала ее сложность. Таким образом, структура задач конвейера в виде DAG-графа (Directed Acyclic Graph) должна быть полностью независимой от структуры бизнес-логики Big Data приложения. Это позволит значительно сократить накладные расходы без каких-либо изменений в структуре бизнес-логики или порядке доставки задач.
Однако, вышеописанное решение должно обеспечивать отказоустойчивость, т.к. чем дольше задание выполняется в распределенной вычислительной среде, тем больше вероятность его сбоя. Как правило, задания по обработке данных легко повторить идемпотентным образом, когда результат операции не зависит от количества повторов ее выполнения. Поэтому стоимость неудачного задания сводится к потере времени, затраченное до отказа, плюс время, потраченное на повторение операции. Разумеется, объединение всех заданий в одну огромную задачу избавит от всех накладных расходов, но значительно повысит риск сбоя. Это может нивелировать всю экономию времени от удаления других источники накладных расходов. Таким образом, дата-инженер должен найти баланс между оптимальной производительностью и отказоустойчивостью pipeline’а. Например, в случае Airbnb для больших сегментов конвейера стоимость и риск повторных попыток были намного ниже, чем накладные расходы, связанные с разделением задач на части. Практика показывает, если накладные расходы равны или превышают 10% времени выполнения задания, то их объединение, вероятно, будет безопасным и наиболее оптимальным вариантом. Таким образом, инженеры Big Data компании Airbnb пришли к следующим выводам относительно проектирования быстрых и надежных конвейеров обработки больших данных [1]:
- естественная эволюция data pipeline’ов, от монолитных наборов скриптов до гибких Spark-приложений, естественным образом приводит к кодированию структуры приложения в конвейере;
- при сокращении времени выполнения конвейера данных, следует проанализировать этот процесс полностью, а не только время полезных вычислений MapReduce;
- помимо полезных вычислений, каждый конвейер данных также производит накладные расходы, вызванные сложностью его оркестровки и глубиной DAG-графа;
- кодирование структуры приложения в конвейере приводит к тесной связи логики приложения с логикой оркестровки, что приводит к росту накладных расходов, делая задачи MapReduce слишком «мелкими»;
- отделив логику оркестровки от бизнес-логики, можно снизить накладные расходы без ущерба для качества приложения;
- повышая производительность конвейера, следует помнить об отказоустойчивости, чтобы не потерять сэкономленное на накладных расходах время, тратя его на повторение задач, в которых часто случаются сбои;
Еще 3 достоинства Apache AirFlow для DataOps-инженера
При том, что дата-инженеры Airbnb еще продолжают свои эксперименты с Apache AirFlow по сокращению накладных расходов в корпоративных pipeline’ах, тестирование вышеприведенных гипотез показало, снижение потерь времени с 2 часов до 15–30 минут. Такая оптимизация не только улучшит время доставки результатов конвейера обработки данных согласно принципам DataOps, но и позволит в будущем запускать pipeline’ы с часовой периодичностью в соответствии с новыми требованиями бизнеса [1]. Справедливость вышеописанных выводов подтверждают наблюдения дата-инженеров компании Tamr, специализирующейся на DataOps-услугах и решениях. С точки зрения DataOps-практик специалисты Tamr отмечают следующие особенности Airflow в качестве средства эффективного планирования и оркестрации Big Data конвейеров [2]:
- возможность использовать существующие инструменты и инфраструктуру для перемещения данных при централизации оркестровки;
- поддержка принципа «инфраструктура как код» за счет использования языка Python для кодирования оркестровки, что предоставляет широкий набор инструментов для разработки, управления, анализа и публикации кода;
- ориентация на производство (production), включая доступность, масштабируемость, анализ сбоев, безопасность и управление. В Airflow есть журнал упреждающей записи (WAL, Write Ahead Log) и распределенное выполнение для обеспечения доступности и масштабируемости. Механизм Python-логгирования упрощает интеграцию, с другими Big Data системами, в частности, с ELK-стеком. В помощь администратору Big Data Apache AirFlow имеет плагин для мониторинга с Prometheus.
Совокупность перечисленных факторов в Airflow обеспечивает возможность координировать деятельность в разных системах масштабируемым, надежным и перезапускаемым способом с интеграцией в современные среды развертывания, масштабирования и мониторинга. Конечным результатом является значительное снижение затрат, в т.ч. накладных расходов, и повышение расширяемости оркестрации конвейеров больших данных, повышая скорость доставки нужных данных в соответствии с принципами DataOps [2].
В заключение добавим, что Apache AirFlow — это оптимальное, но не единственный инструмент дата-инженера для оркестровки рабочих задач. В качестве альтернативы можно рассмотреть Luigi, Argo, MLFlow и KubeFlow. О сходствах и различиях этих фреймворков мы рассказываем здесь.
Освоить детали администрирования и эксплуатации Apache Airflow в production на реальных проектах цифровизации частного бизнеса, а также государственных и муниципальных предприятий, вы сможете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
