Як ми перейшли з мануальної системи оркестрації даних на Airflow

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Усім привіт. Мене звати Сергій Зайченко, я Data Analyst застосунку Taimi в українській продуктовій IT-компанії appflame. Моя робота полягає в тому, щоб аналізувати маркетингові дані користувачів, переводити їх у читабельний формат і допомагати іншим командам робити висновки з цих даних для прийняття ефективних рішень.

Рік тому наша аналітична команда перейшла з мануальної системи оркестрації даних на Airflow та значно спростила собі життя. У цій статті я розповім, як ми здійснили цей перехід, які ресурси для цього знадобилися, а також про плюси та мінуси роботи з Airflow.

Цей матеріал буде цікавим для команд, які вагаються, чи переходити на Airflow, і шукають кейси та досвід інших спеціалістів, на який можна спертися. Почнемо з бази.

Що таке оркестрація даних та на яких проєктах її варто (або не варто) впроваджувати

У нас на продукті є багато різних даних, серед яких:

  • продуктові (наприклад, дані про реєстрацію користувачів);
  • маркетингові (наприклад, дані з реклами в соцмережах);
  • фінансові показники (наприклад, витрати операційної команди та команди саппорту) тощо.

Вони зберігаються в різних таблицях та надходять з різних джерел, у різний час та в різному форматі. Для того, щоби нашим командам було простіше проаналізувати ці дані, робити певні висновки та ухвалювати рішення, ми маємо зібрати всі дані разом та сформувати адекватний звіт, доступний для загального розуміння. Це ми виконуємо за допомоги системи оркестрації даних (і Airflow — одна із таких систем).

Вона координує, коли та за яких умов дані мають бути оброблені, адже дуже важливо, щоби кожен набір даних мав своє місце та час у процесі обробки, а кожна таблиця збиралася своєю чергою та відповідала певним валідаційним вимогам.

Якщо ви ставите питання, чи потрібна вам така система, то спершу варто зрозуміти, чи потрібно вам автоматизовувати процеси. Якщо ви не використовуєте автоматизацію і витрачаєте багато часу на те, щоби перезаливати дані вручну, чи постійно стикаєтеся з однаковими проблемами під час обробки даних — то вона однозначно вам допоможе.

Які в нас були причини для переходу на Airflow і які ми бачили ризики

Раніше ми мали власну мануальну систему оркестрації даних із назвою Sandal. У ній була можливість планувати запуск скриптів за розкладом через UI (cron), але система була недостатньо гнучкою, виконувала всі задачі в однаковому форматі, не могла повʼязати дві задачі між собою чи провалідувати якість їхнього виконання.

Якщо одна задача падала, й ми цього не помітили — інші задачі виконувалися з помилками. Доводилося все власноруч вимикати, шукати проблему та перезапускати процес. І такі баги в нас відбувалися доволі часто через постійні зміни в скриптах і наших підходах.

На виправлення помилок йшло багато часу, й наша команда почала дивитися в бік альтернативних варіантів, які могли бути більш гнучкими, легкими в налаштуванні, здатними автоматично перезапускати задачі та повідомляти нам про помилки.


Мануальна система Sandal

Усі ці проблеми можливо розв’язати в Sandal. Запрограмувати звʼязок між різними задачами, зробити можливість автоматичного перезапуску задач, що впали з помилками, додати альортинг і кастомні валідації. Але навіщо робити велосипед, коли такі системи вже існують та зарекомендовані в індустрії?

Урешті-решт ми зупинилися на Airflow через те, що про нього є багато гайдів, мануалів, модулів, інтеграцій тощо. І нам було вкрай важливо мати можливість консультуватися з багатьма різними спеціалістами, якщо щось піде не так. Ми розглядали ще декілька альтернатив — Dagster, Prefect, Luigi, але вони або молоді й ще недостатньо обкатані, або ще старші за Airflow, але однаково не мають широкого кола користувачів, з якими ми могли б проконсультуватися. Ми надавали перевагу Airflow також через те, що буде набагато легше знайти в команду людину, яка вміє працювати із цією системою, ніж із будь-якою іншою.

Коли ми почали змістовніше говорити про перехід на іншу систему, ми натрапили на такі ризики:

  • більша частина команди звикла працювати з нашою мануальною системою та неохоче сприймала ідею змін (як це часто трапляється);
  • не всі бачили потреби в нововведеннях, адже Sandal закривав задачі інших команд, а Airflow тим часом вважався дуже корисним переважно тільки для аналітиків;
  • для роботи з Airflow потрібно хоча б базове знання Python, а серед команди аналітиків Taimi на той момент було всього дві людини, які з ним працювали;
  • й очевидним ризиком була відсутність досвіду роботи з Airflow у команді. Нашу мануальну систему могли підняти 15 людей у команді, Airflow на той момент могли б підняти тільки двоє: я та мій колега. І були побоювання, що все може розвалитися і ніхто це не збере, якщо ми з ним одночасно будемо не на звʼязку.

Зрештою фінальне рішення зробив наш CTO і на одному із мітингів сказав «переходимо», аргументувавши тим, що ця автоматизація заощадить нам багато часу та сил у майбутньому. Тоді я взяв на себе відповідальність перевести на Airflow всі процеси обробки даних, а решта команди мала навчитися працювати з новим інструментом за допомогою профільних курсів.

На перенесення нашого воркфлоу ми виділили три місяці, хоча в нас вийшло вкластися у два, паралельно ми також виконували свої щоденні задачі.

Як відбувався процес переходу на Airflow та хто над цим працював

Щоб спростити собі задачу, на початку ми вирішили перейти на Airflow частково та перевели на нову систему тільки основні скрипти, які були важливі безпосередньо для роботи команди Data Analysts.

Скрипти для:

  • формування таблиці в ClickHouse по SQL-запиту;
  • публікацій оновлень в Slack;
  • вивантаження маркетингових звітів файлами та надсилання їх у Slack.

На нашій мануальній системі Sandal ми тимчасово залишили скрипти та процеси, які й так уже добре працюють та які повʼязані з іншими базами даних (бо вони набагато рідші, їх складніше переписувати та для нашої команди аналітиків це не було обовʼязковим). Мануальною системою продовжив користуватися наш Data Engineer та команда Back-end розробників, які паралельно спостерігали за нашими успіхами в переході на Airflow.

Перед початком роботи ми розподілили наші обовʼязки та флоу на дві частини: підготовка до переходу та його обкатка.

Протягом першого місяця я консультувався з розробниками нашої поточної мануальної системи щодо того, як усе влаштовано в неї під капотом, які в неї скрипти та за якою логікою вони виконуються. Я мав отримати оригінальний код, зрозуміти, що відбувається всередині нього, переписати його з PHP на Python і підлаштувати його під Airflow так, щоб усі процеси відбувалися так само, й ми не помітили різниці в готових таблицях.

Коли я отримав ці дані, ми почали підіймати Airflow — цим займалася команда DevOps. Вони налаштовували його працездатність і сумісність з іншими сервісами, як-от Elastic Search, Slack (там він формує та публікує нам щоденні звіти з Airflow), а також вони давали нам доступи на аутентифікацію, щоби ми могли заходити та вносити зміни як адміністратори.

Тоді ж наш Data Engineer налаштовував інтеграцію з нашими базами даних і давав дозволи на створення, видалення та перегляд даних на сервері. Команда аналітиків займалася написанням DAG (Directed Acyclic Graph, або сценаріїв).


Декілька наших активних DAG

Потім почалася обкатка. Приблизно місяць ми копіювали скрипти, створювали нові та адаптували їх. На цьому етапі ми повністю відтворили всю логіку роботи мануальної системи на Airflow. Далі почали вже додавати певні смартфункції, заради яких ми переходили на цю систему, наприклад:

  • запуск задач за умови, що всі інші задачі, від якої вони залежать, успішно виконані;
  • запуск задачі за 20 хвилин після успішного виконання попередньої;
  • перевірка таблиці одразу після її формування;
  • можливість тегати в чаті конкретних людей, якщо помилка під час збору чи перевірці таблиць сталася в їхній зоні відповідальності.

З якими челенджами стикнулися

Загалом Airflow дуже легкий в опануванні, для роботи з ним достатньо базових навичок Python та, як і будь-який інший новий інструмент, він вимагає ресурсу та додаткового часу для вивчення. Але треба враховувати, що в ньому є трохи незвичним формат встановлення залежностей між задачами — складно використовувати ці залежності в синтаксисі коду, коли ти намагаєшся додати такі вирази в loop, то все стає трохи контрінтуїтивним, наче працюєш у кількох вимірах.

Варто також зазначити, що один з основних челенджів для нас полягав у тому, що не вся команда регулярно користувалася Python, і в нас не було досвіду розробки (створенню DAG) в Airflow. Тож треба було підтягнути власні знання, і ми проходили кілька курсів. Я можу рекомендувати ось цей.


Задачі одного з DAG

Доволі типовий челендж роботи з Airflow, на який ми також натрапили — це незручність його дебагінгу. По-перше, Airflow не завжди показує проблему в коді, якщо помилка трапилась не в частині коду, що виконується безпосередньо на його сервері. Також він виконує код у себе на сервері, тож потрібно деякий час чекати на оновлення та виконання запитів для перегляду логів та пошуку помилок.

Деякі запити можуть виконуватися по 10 хвилин, і мені доводилося чекати, поки Airflow виконає та вивантажить логи. Далі треба шукати там помилку і знову писати код у себе на ноуті та чекати, поки він розгорнеться та опрацюється на сервері. Це доволі довго, адже ці хвилини перетворюються в години протягом робочого дня, але разом із тим це дисциплінує писати код без помилок і з першої спроби.

P.S. Як я дізнався вже потім, є методи, за допомогою яких це можна трохи пришвидшити, наприклад, підняти сервер локально. У такому разі його швидше дебажити, адже код швидше розгортається. Та під подібні задачі краще залучати розробників з аналогічною експертизою.

Також на початку переходу ми зіткнулися з дуже банальною проблемою. Ми написали доволі простий скрипт, але він не працював — Airflow збирав дані, але не міг їх записати, і логи не містили корисної інформації. Я думав, що проблема в новому скрипті, і витратив день на його переписування, але марно.

Згодом з’ясувалося, що я шукав проблему не там. Наступного дня я звернувся до нашого Data Engineer, який під час перевірки логів бази даних знайшов причину: Airflow мав доступ до зчитування, але не мав дозволу на запис даних. Цю проблему ми не помітили одразу, адже на стороні Airflow все виглядало добре, а помилка була на сервері бази даних. У цей момент я вкотре переконався, що дуже важливо, щоб у вашій команді був спеціаліст, який може подивитися на проблему під призмою іншої експертизи.

Ще мене змусило замислитися те, на якому рівні ми хочемо моніторити процес виконання сценаріїв (DAG). У Airflow кожен крок у цих сценаріях — це окрема задача (task). Наприклад, процес збору даних для нашого репорту має декілька етапів: збір даних із джерел, створення консолідованої таблиці та генерація репорту. На початку я хотів, щоби кожен з цих етапів був окремою задачею в Airflow, це б дало нам змогу детально відстежувати процес на кожному кроці. Тоді я налаштував чотири задачі для збірки однієї таблиці:

  • очищення даних;
  • збір та агрегація таблиці;
  • запис таблиці на диск;
  • її перевірка й потім публікація у Slack.

Через кілька місяців я зрозумів, що це доволі дрібний рівень, Airflow постійно нас спамив та підвисав через складні сценарії, і ми перейшли на більш глобальний рівень, де одна задача — це зібрана та перевірена таблиця. Тоді я зрозумів, що багато речей в Airflow можна налаштувати під себе, він доволі гнучкий, і це ніби розвʼязало мені руки після нашої мануальної системи. Але тільки методом тестування ви зможете зрозуміти для себе, як вам буде комфортніше з ним працювати.


Флоу збору маркетингових даних

Підсумовуючи, хочу сказати, що хоч в Airflow є вузькі місця, вони найбільше зʼявляються на початку роботи: є проблема з тривалістю його налаштування, дебагінгом, іноді важко читати логи тощо. Але коли це починає працювати, то працює майже бездоганно. У нас за рік роботи з Airflow майже не було проблем, пов’язаних із тим, що він впав і ніхто не знає, чого він впав. А якщо це й було, то є можливість дуже швидко це пофіксити. Наразі ми переводимо іншу частину технічної команди на Airflow, щоби у тому числі полегшити робочий процес розробникам та Data Engineer.

Які ми отримали результати та які висновки зробили

Найголовніший результат цього переходу — це те, що в аналітиків звільнилося до 3–4 додаткових годин на тиждень (та багато нервових клітин). Цей заощаджений ресурс наразі ми вкладаємо в нашу основну аналітичну роботу. Раніше ми мали кожен день моніторити наші показники, перезапускати агрегації наших проміжних таблиць та перевіряти, щоб кожна з них збиралася правильно, а зараз ми можемо поставити автоматичні перевірки та Airflow буде нас смикати, якщо дані сильно розходяться.

Також, у нас з’явився інструмент, завдяки якому ми можемо писати дуже мануальні та складні перевірки. Наприклад, якщо сьогодні понеділок і в наших користувачів сильно змінився LTV, то потрібно зібрати дані знову, а якщо це не допоможе два рази підряд, то тегнути відповідного аналітика. Або ж якщо дані в бекапах розходяться з даними в основних таблицях і зараз конкретна година дня.

Ще ми змогли автоматизувати процеси, яких нам бракувало на мануальній системі. Наприклад, наразі ми спочатку збираємо основні таблиці, потім випускаємо наш репорт. Якщо не спрацьовують алерти, то ми оновлюємо дані в дашбордах. Як тільки дашборди оновилися і туди підтягнулися свіжі дані ми тегаємо маркетологів, щоби вони бачили, що можна ці дані досліджувати.

І загалом, я радий, що ми почали працювати з новим, популярним інструментом — це добре для нашого карʼєрного зростання та загального розвитку.

Наостанок — три поради на основі нашого досвіду переходу на Airflow.

  1. Якщо у вас обмежені ресурси та час, плануйте поступовий перехід: почніть з перенесення найважливіших та найчастіше використовуваних процесів та скриптів.
  2. Почніть заздалегідь вивчати особливості роботи з Airflow. Для навчання підійдуть онлайн-курси, а також зайдіть у професійні спільноти, де можна отримати підтримку та консультації. Наприклад: Чат Airflow Україна, Спільнота Data Engineers. ChatGPT також дуже гарно допомагає з підказками з Airflow.
  3. Ретельно перевіряйте доступи та права, які ви даєте Airflow із самого початку, щоб уникнути витрачених годин на пошук проблеми.

Якщо у вас є питання або потрібні поради щодо налаштування Airflow, ви хотіли б поділитися своїми думками щодо статті — пишіть у коментарях під статтею або мені у LinkedIn.

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Цю проблему ми не помітили одразу, адже на стороні Airflow все виглядало добре, а помилка була на сервері бази даних.

не дуже згоден, що це помилка сервера баз даних. Відсутність прав це помилка кліента, яку кліент повинен вміти відповідним чином обробляти.

До речі дійсно які недоліки Ви знайшли у Prefect?

Мені Prefect сподобався набагато більше. Після Airflow це був ковток свіжого повітря після задимленого підземелля постійного страждання з інтерфейсом, скедулінгом та дебагінгом в Airflow.

Наступна стаття: «як ми робили моніторинг для airflow»

Теж про це подумав)

Та насправді там все порівняно прямолінійно, бо він з коробки вміє експортити prometheus-метрики за ендпоїнтом, лиш збирай та обробляй. + завжди можна навішати алертів на рівні отримувачів щодо того чи прийшли взагалі дані.

Я працював у компанії, що робила спеціалізоване рішення для моніторингу airflow.
А графана ось: github.com/...​and-ai/airflow-dashboards

Для локального airflow можна юзати astro cli, та запускати його в одну команду astro dev start

Підписатись на коментарі