В продолжение недавней статьи для дата-инженеров по эффективной работе с Apache AirFlow, сегодня разберем еще несколько рекомендаций от компании Astronomer, которая продвигает и коммерциализирует этот ETL-оркестратор. Чем полезна микрооркестрация с несколькими средами AirFlow, как обеспечить повторное использование и воспроизводимость, зачем нужна интеграция с инструментами и процессами CI/CD.
Микрооркестрация с множеством сред Airflow
Монолитная среда оркестрации недостаточно гибка, чтобы удовлетворить разнообразные требования всех пользователей, особенно в части самообслуживания. Поэтому целесообразно создать несколько распределенных сред Airflow для поддержки отдельных регионов, бизнес-подразделений и/или команд. Эта идея распределения похожа на микросервисную архитектуру, а также сетки данных, которые сегодня становятся очень популярными. Как и в случае создания микросервисов, следует настроить каждую среду Airflow для удовлетворения конкретного набора требований, специфичных для функциональной области бизнеса или домена обработки данных типа Data Science, ML и пр.
Создание нескольких сред Airflow для конкретных вариантов использования или функций также согласуется с архитектурой Data Mesh и акцентом на децентрализацию ответственности за создание, обслуживание и владение различными видами данных: DAG, задачи, настраиваемые операторы и код, который каждая команда использует в своих конвейерах. В децентрализованной системе каждая команда имеет некоторую свободу в развитии собственных знаний и реализации местных приоритетов при сохранении соответствия общекорпоративным стандартам организации.
При микро-оркестрации сред Apache AirFlow необходима кодификация стандартов для общих или повторяющихся DAG, задач, пользовательских операторов и другого кода, чтобы обеспечить согласованность и повторное использование, а также интеграцию с процессами CI/CD. Стоит помнить, что развертывание Airflow во внутренней инфраструктуре — это не задача «под ключ», а поддерживать и защищать нескольких распределенных сред тоже бывает не так просто. Аналогичное замечание относится к проблеме получения единого представления о конвейерах данных и потоках, которые они поддерживают. Каждая из этих проблем подчеркивает преимущества развертывания Airflow в контексте полностью управляемой службы.
Повторное использование и воспроизводимость
Формализация стандартов повторного использования облегчает децентрализованным командам и пользователям самообслуживания совместное использование Airflow. Можно стандартизировать общие пользовательские операторы Airflow, чтобы гарантировать, что они ведут себя одинаково при каждом запуске. Или определить и внедрить различные типы повторяющихся интеграций, таких как повторяющиеся задачи перемещения и/или преобразования данных, извлечения фичей и пр., чтобы они могли быть доступны и повторно использованы. Управляемые облачные сервисы могут упростить это, предоставив структуру, встроенные элементы управления и стандарты, которые обеспечивают некоторые вспомогательные условия для повторного использования и воспроизводимости.
Также дата-инженеры Astronomer рекомендуют осознанно и централизованно продвигать культуру, которая отдает приоритет повторному использованию и воспроизводимости данных и конвейеров их обработки. Например, дать дата-инженерам полномочия определять и формализовать полезные пользовательские операторы, задачи, сценарии и другой код, чтобы сделать их доступными для всех потенциальных пользователей. Это позволит не беспокоиться о поддержке сотен пользовательских операторов или об их исправлении при изменении библиотек, API или других зависимостей.
Формализация и стандартизация повторно используемые операторы, задачи и пользовательский код конвейера данных, а также создавая их экземпляры в каком-либо управляемом контексте типа системы контроля версий, специального хранилища фичей и т.д. также способствует повторному использованию, воспроизводимости и доверию.
Интеграция с инструментами и процессами CI/CD
Дата-инженеры Astronomer рекомендуют контролировать версии DAG в корпоративном репозитории GitHub, где публикуются новые образы Airflow, код разработки данных и зависимости. Также имеет смысл регулярно определять повторно используемый код и добавлять его в проекты, которые поддерживаются в системе контроля версий GitHub и управляются CI/CD. Повторно используемый код может включать не только DAG, задачи и пользовательские операторы, но и любой пользовательский код, например Python-скрипты или SQL-запросы, которые вызываются этими операторами.
Помимо поощрения повторного использования, это позволяет управлять версиями задач, конвейеров данных и пользовательского кода, а также упрощает их обслуживание. У дата-инженеров есть корпоративный репозиторий GitHub для многократно используемых задач и кода конвейера данных, которые используются в DAG. Эта логика конвейера данных всегда актуальна. После того, как дата-инженер данных извлечет последний проект из корпоративного репозитория GitHub и обновит свои DAG или задачи, он может создать и опубликовать новый образ в корпоративном реестре образов с помощью Astro CLI, о котором мы рассказывали ранее. Далее новый образ проходит через процесс CI/CD, что разбирается в нашей новой статье.
Вместо резюме: наблюдаемость и современная оркестровка данных
Оркестровка данных дает низкоуровневую наблюдаемость в пользовательских конвейерах, то есть в двухточечных соединениях, которые составляют систему доставки бизнес-данных. Это позволяет дата-инженерам быстро и легко выявлять проблемы в их источниках и разрабатывать способы их устранения, а также дает возможность наблюдать, понимать и абстрагировать конвейеры данных как потоки. Так получаются сети данных, которые объединяются и доставляют данные по отдельным регионам, функциональным областям и децентрализованным командам организации. Это позволяет сопоставлять потоки данных с бизнес-процессами, чтобы наблюдать, понимать и улучшать цифровые продукты, а также оптимизировать доставку срочной информации, поддерживающей операционные решения.
Аналогично, современная организация данных упрощает разработку и доставку совершенно новых потоков для поддержки новых клиентоориентированных продуктов и услуг или для выхода на новые рынки и регионы. Поэтому следует всегда собирать и анализировать метаданные о происхождении данных, которые генерируются каждый раз, когда запускаются DAG Airflow. Рекомендуется собирать и анализировать метаданные, чтобы наблюдать и концептуализировать конвейеры данных как различные типы бизнес-ориентированных абстракций. В частности, платформа Astronomer Astro использует OpenLineage, стандарт с открытым исходным кодом для передачи данных и других типов метаданных. Astro использует OpenLineage для автоматического извлечения событий происхождения данных во время работы DAG.
Код курса
ADH-AIR
Ближайшая дата курса
Продолжительность
ак.часов
Стоимость обучения
0 руб.
В заключение отметим синергетический эффект применения лучших практик. Например, при запуске производственных DAG в контейнерах, становится возможным встроить в них инструментарий для отслеживания происхождения данных. А при централизованном управлении экземплярами среды выполнения Airflow гораздо проще собирать и анализировать эти метаданные. Если поместить повторно используемый код (задачи, операторы и пользовательскую логику конвейера данных) в репозиторий Git, это не только упростит обслуживание, но и позволит сделать этот код доступным для повторного использования. Наконец, при проектировании DAG с учетом встроенного параллелизма Airflow, задачи будут выполняться лучше и быстрее, а зависимости между ними будут менее хрупкими и более надежными.
Все подробности администрирования и эксплуатации Apache AirFlow для организации ETL/ELT-процессов в аналитике больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
