В рамках практического обучения дата-инженеров сегодня мы собрали 10 лучших практик проектирования конвейеров обработки данных в рамках Apache AirFlow, которые касаются не только особенностей этого фреймворка. Также рассмотрим, какие принципы разработки ПО особенно полезны для инженерии больших данных с Apache AirFlow.
ТОП-10 рекомендаций дата-инженеру для настройки Apache Airflow и не только
Мы уже рассказывали про лучшие практики работы с DAG в Apache AirFlow. Однако, помимо тонкостей объединения задач в workflow-процессы, для проектирования эффективных конвейеров обработки данных дата-инженеру нужно учесть еще много аспектов, в том числе за пределами этого фреймворка. В частности, для построения качественных data pipeline’а и их беспроблемной эксплуатации следует [1]:
- определить наборы, источники, места приема и средства обработки данных, включая озера и хранилища, СУБД, BI-системы, а также средства обработки и архивирования. Перед развертыванием конвейера в production все его компоненты следует протестировать по отдельности и вместе друг с другом.
- четко определить структуры СУБД, схемы и таблицы со всеми типами данных, с указанием их мест хранения, в т.ч. временного, отчетного и архивного. Отсутствие этого шага может привести к созданию нескольких копий таблиц в разных схемах.
- разделить среды данных для разработки, тестирования и промышленной эксплуатации конвейеров. Среды разработки и тестирования могут иметь всего несколько последовательных исполнителей AirFlow с минимальной конфигурацией и СУБД SQL Lite. А production среда должна иметь Celery, Kubernetes или локальных исполнителей для параллелизма и MySQL для хранения метаданных.
- установить SLA для каждой задачи, чтобы отслеживать его во время разработки и эксплуатации с оповещением при превышении порогового значения. О том, что такое SLA и как это связано с другими эксплуатационными показателями, мы писали здесь.
- отслеживать тайм-аут выполнения каждой задачи, чтобы она не блокировала выполнение других задач в случае зависания, сбоя или аварийного завершения. Для критически важных рабочих нагрузок можно использовать отслеживание ошибок в реальном времени с помощью Sentry. Вообще желательно настроить автоматический мониторинг и отслеживание всех заданий Airflow с генерацией уведомлений. Количество повторных попыток и интервалы следует указывать в соответствии с критичностью задачи.
- по возможности использовать методы сжатия файлов, например, Parquet или ORC с кодеками snappy или gzip;
- сократить применение пользовательских функций и операторов Python, стандартизировав использование встроенных возможностей;
- использовать параметризованные переменные, передавая их как JSON-объекты. Их можно десериализовать, чтобы получить значения отдельных переменных.
- хранить логи в озере данных, таком как AWS S3 или Hadoop HDFS, чтобы избежать сбою DAG’ов из-за заполнения свободного пространства жесткого диска при логгировании на уровне Airflow VM.
- сократить размер конвейера. Чем больше задач в одном data pipeline’е, тем сложнее его поддерживать. Например, если в конвейере более 5-10 задач, следует подумать о его разделении на несколько pipeline’ов. С этой же целью облегчения эксплуатации рекомендуется делать конвейеры идемпотентными, чтобы инженеры поддержки быстро смогли найти восстановить его, повторив исправленное задание с последнего неудачного шага.
Однако, это не единственные рекомендации, которые помогут дата-инженеру проектировать и поддерживать по-настоящему эффективные конвейеры обработки данных с помощью Apache AirFlow. Практикующим инженерам данных пригодится еще парочка советов, которые мы рассмотрим далее.
Если можете не писать, не пишите: DRY и другие полезные принципы разработки ПО для инженера данных
Поскольку инженерия данных использует многие концепции из разработки ПО, неудивительно, что принцип не повторения (Don’t Repeat Yourself, DRY) актуален и здесь. В частности, ELT-процессы с разными источниками и приемниками данных могут содержать большое количество одинакового Python-кода. Чтобы каждый раз не писать это вручную, целесообразно генерировать DAG автоматически из Python-файлов, переменных или коннекторов, а также YAML-конфигураций. Как это сделать на практике, мы расскажем в следующий раз.
Еще одним полезным принципом, активно используемым в DataOps, является самообслуживание (self-service) систем хранения и обработки данных, включая конвейеры. К примеру, вместо рутинной для дата-инженера задачи подключения очередного источника или приемника данных в pipeline гораздо эффективнее будет создать интерфейс для пользователей, который позволит им взаимодействовать с существующими DAG’ами. Например, с помощью простого YAML-файла или полноценного веб-интерфейса.
Наконец, следует помнить о лучших практиках разработки ПО, используя шаблоны архитектурного проектирования систем [2], например, как в кейсе бразильской ИТ-компания QuintoAndar, о котором мы рассказывали здесь. Дата-инженеры QuintoAndar разработали промежуточный компонент Mediator на базе одноименного паттерна, чтобы облегчить взаимодействие между разными DAG’ами в Apache AirFlow. О важности модульного тестирования пользовательского кода DAG читайте в нашей новой статье.
Узнайте больше про использование Apache AirFlow для разработки сложных конвейеров аналитики больших данных с Hadoop и Spark на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
