Найти в Дзене

Как я автоматизировал рутину с ETL: от Python-скриптов до Airflow

Всем привет! Я — практикующий исследователь данных, и на этом канале делюсь тем, что реально работает в IT. Никакой сухой теории, только личный опыт, рабочие инструменты и грабли, на которые я уже наступил за вас. Рад, что вы здесь! ETL (Extract, Transform, Load) — это сердце аналитики данных, но, хм, какая же это порой рутина! Выгружай данные, чисти их, пихай в базу — и так по кругу. Я, как любой нормальный человек, не очень люблю повторять одно и то же, поэтому расскажу, как я укрощал ETL-процессы: от кустарных Python-скриптов до Airflow, а заодно пробегусь по другим инструментам, их плюсам, минусам и кому они зайдут. Поехали! 😎 Когда я только ворвался в аналитику данных несколько лет назад, ETL для меня звучало как что-то из научной фантастики. На первой работе мне сказали: "Вот тебе базы, выгружай данные, чисти, строй отчёты". Благо я знал Python и хорошо дружил с Excel. Тогда я начал разбираться, как автоматизировать этот ад (данные мне нужно было брать из CRM, благо мне дали дос
Оглавление

Всем привет! Я — практикующий исследователь данных, и на этом канале делюсь тем, что реально работает в IT. Никакой сухой теории, только личный опыт, рабочие инструменты и грабли, на которые я уже наступил за вас. Рад, что вы здесь!

ETL (Extract, Transform, Load) — это сердце аналитики данных, но, хм, какая же это порой рутина! Выгружай данные, чисти их, пихай в базу — и так по кругу. Я, как любой нормальный человек, не очень люблю повторять одно и то же, поэтому расскажу, как я укрощал ETL-процессы: от кустарных Python-скриптов до Airflow, а заодно пробегусь по другим инструментам, их плюсам, минусам и кому они зайдут. Поехали! 😎

Картинка сгенерирована в Шедевруме
Картинка сгенерирована в Шедевруме

Предисловие: моя боль с ETL

Когда я только ворвался в аналитику данных несколько лет назад, ETL для меня звучало как что-то из научной фантастики. На первой работе мне сказали: "Вот тебе базы, выгружай данные, чисти, строй отчёты". Благо я знал Python и хорошо дружил с Excel. Тогда я начал разбираться, как автоматизировать этот ад (данные мне нужно было брать из CRM, благо мне дали доступ к БД на PostgreSQL, несколько онлайн Гугл таблиц, API ФНС и корявые данные из баз нескольких подведомственных порталов). Мой путь — это эволюция от "лишь бы работало" до "всё по-взрослому". Надеюсь, мой опыт поможет тебе не наступить на те же грабли.

Я не инженер данных и не архитектор, но порой на позиции Аналитика данных ставят задачи на которые ты не рассчитывал, но решать их придется (я всё начинал с нуля и сам, но старался всё делать по документации и негласным правилам).

Шаг 1: Python-скрипты и Bash — мои первые костыли

На старте я писал Python-скрипты для ETL. Брал pandas для обработки данных, psycopg2 для подключения к PostgreSQL, кидал всё в CSV, а потом пушил в базу. Работало? Да. Удобно? Нет. Скрипты жили в папке на рабочем столе или на сетевом диске "S:", назывались типа script1_final_final.py, и если что-то ломалось, я часами искал, где косяк.

Для запуска по расписанию я прикрутил Bash-скрипты и cron на сервере. Выглядело это как:

#!/bin/bash
python3 /home/robert13/script1_final_final.py

Круто? Для новичка — блЯстяще😁. Но когда скриптов стало 10, а они начали падать из-за зависимостей или багов, я понял: что-то надо менять. Плюс, если данные не приходили вовремя, всё рушилось, по утрам я ловил стресс, к вечеру исправлял ситуацию.

Плюсы Python + Bash:

  • Простота. Если знаешь Python, за день напишешь ETL.
  • Гибкость. Хочешь — парси данные, хочешь — чисти в pandas.
  • Бесплатно. Никаких лицензий.

Минусы:

  • Хаос. Скрипты плодятся, документации ноль, отлаживать — боль.
  • Нет мониторинга. Упал скрипт? Узнаешь, когда дашборд не отрисовался без данных, или кто-то из пользователей уидел что актуальные данные отсутствуют и к тебе уже пришли с претензией и т.д.
  • Не масштабируется. 100 скриптов? Удачи управлять🙃.

Кому подойдёт: Новичкам, малым проектам, где ETL — это пара выгрузок в неделю. Если ты фрилансер или делаешь пэт-проект, этого хватит.

Шаг 2: Airflow — любовь и немного боли

Однажды когда я понял, что дальше так жить нельзя, погуглив я узнал о Apache Airflow, и это был поворотный момент. Спойлер: В своей следующей работе я узнал про него намного больше и так получилось что он стал моим основным инструментом, ну почти основным. Airflow — это оркестратор, который берёт твои ETL-задачи, раскладывает их по полочкам и запускает по расписанию. Я переписал свои скрипты в DAGи (Directed Acyclic Graphs), и жизнь заиграла новыми красками.

Теперь мой ETL выглядел так:

  • Extract: скрипт тянет данные из API или базы.
  • Transform: Python-оператор чистит данные в pandas.
  • Load: пушит в DWH (в моем случае ClickHouse).

Всё это в одном DAGе, с зависимостями (если Extract упал, Transform не запустится) и логами. Airflow сам шлёт алерты, если что-то пошло не так. Плюс, веб-интерфейс — это просто кайф: видишь, какие таски выполнены, где ошибка, можно перезапустить одной кнопкой.

Как я перешёл:

  1. Установил Airflow локально (через Docker, чтоб не мучиться).
  2. Разобрался с DAGами — это как Python-скрипты, но с расписанием и зависимостями (буквально к обычному скрипту добавляются несколько строк).
  3. Перенёс свои ETL-процессы в Airflow, разбив на таски.
  4. Настроил алерты в Telegram через Airflow hooks.

Через месяц я полностью отказался от Bash и cron. Теперь всё в одном месте, с мониторингом и без ночных паник.

Понятно, что это было не так просто как на словах, есть куча готовых DAGs по умолчанию и ты можешь с легкостью протестить или заточить под себя, сначала мне было психологически тяжело, я постоянно думал "а вдруг это не так делается, вдруг я чего-то не знаю", так и было, но со временем ко всему привыкаешь. Мне было легче, потому что у меня уже были готовые скрипты на пайтон, которые я копил месяцами на каждый процесс, оставалось только их чуток видоизменить и добавить пару строчек с расписанием и импортами (кстати некоторые DAGs, после выхода чата гпт я закинул в него и он здорово мне их отрерайтил, код стал более компактным и эффективным, но не советывал бы генерить полностью DAGs во всяких ИИ, во всяком случае пока не набьете свои шишки и руку).

Плюсы Airflow:

  • Оркестрация. Зависимости, расписания, ретраи — всё под контролем.
  • Мониторинг. Логи, алерты, веб-интерфейс — красота.
  • Масштабируемость. Хоть 1000 DAGов, Airflow справится.
  • Комьюнити. Куча туториалов и плагинов.

Минусы:

  • Сложность на старте. Разобраться с Airflow — это не за вечер, хотя зависит от человека (я просто обычно торможу всё долго обдумываю и изучаю).
  • Ресурсы. Локально на слабом ноуте возможно будет тормозить, я запускал через WSL (Ubuntu) у себя на винде - ноут конечно был не слабый (с Airflow нужно работать на линуксе, насколько я знаю он работает только на ней), а впоследствии я перенес всё на сервер в котором стоял Debian.
  • Оверкилл для мелочей. Если у тебя 2 скрипта, Airflow — как танк для поездки в магазин.

Кому подойдёт: Командам, где много ETL-процессов, или аналитикам, которые хотят автоматизировать свою ETL рутину. Если ты работаешь в компании с DWH и кучей данных, Airflow — хороший выбор.

Другие инструменты для ETL: что пробовал, что думаю

Пока я укрощал Airflow, заглядывался на другие инструменты. Вот мой разбор:

1. Pentaho Data Integration (PDI)

Что это: Open-source инструмент с графическим интерфейсом. Перетаскиваешь блоки (выгрузка, трансформация), собираешь пайплайн.
Плюсы: Не надо кодить, удобно для новичков. Много коннекторов (базы, API).
Минусы: Интерфейс староват, тяжеловесный. Если надо сложную логику, проще написать на Python.
Кому подойдёт: Тем, кто боится кода, или небольшим командам, где ETL — это простые выгрузки.

2. Talend

Что это: Ещё один ETL-инструмент с GUI, но покруче Pentaho. Есть бесплатная версия.
Плюсы: Мощный, много интеграций, поддержка Big Data.
Минусы: Бесплатная версия ограничена, а платная — дорого. Сложновато для новичков.
Кому подойдёт: Крупным компаниям или тем, кто работает с большими данными и готов платить.

3. Apache NiFi

Что это: Инструмент для потоковой обработки данных с веб-интерфейсом.
Плюсы: Реально крут для real-time ETL, визуальный редактор.
Минусы: Не для классического ETL (складских задач). Требует времени на освоение.
Кому подойдёт: Тем, кто работает с потоками данных (IoT, логи), а не с батч-обработкой.

4. DBT (Data Build Tool)

Что это: Инструмент для трансформаций (Transform) в ETL, работает поверх SQL.
Плюсы: Простота, если любишь SQL. Интеграция с DWH (Snowflake, BigQuery). Модно в 2025 году.
Минусы: Только для Transform, Extract и Load надо прикручивать отдельно.
Кому подойдёт: Аналитикам, которые хотят писать SQL и автоматизировать трансформации в DWH.

Что мне нравится: Я фанат Airflow за его гибкость и контроль. DBT тоже зашёл — SQL + версия-контроль данных = кайфушки.
Что не очень: GUI-инструменты (Pentaho, Talend) кажутся медленными, если привык к коду. NiFi крут, но не мой случай — я больше про батчи, а не потоки.

Итоги

ETL — это рутина, но её можно приручить. Я начал с Python и Bash — это как езда на велике без тормозов: быстро, но опасно. Airflow стал моим внедорожником: мощный, надёжный, но надо уметь рулить. Если ты новичок, стартуй с Python-скриптов, но как только процессов станет больше — бери Airflow или dbt. А если код не твоё, попробуй Pentaho или Talend.

Главное — не бойся пробовать и ломать. Мои первые скрипты были трешем, но они работали. Теперь я сплю спокойно, а Airflow пашет за меня (шутка с большой долей правды).

Кстати когда я пришел аналитиком в банк, в БАНК!!! - мне по наследству достались Python скрипты, которые отрабатывали по времени (некоторые каждый час, другие каждые три, и третьи каждый день) и всё это через Планировщик задач Windows 😄. В общем чего только не увидишь в этой профессии.

Я не претендую на истину в последней инстанции, просто рассказываю, как иду по пути аналитика. Спасибо, что дочитали! 😎 Подписывайтесь 👇👇👇, лайкайте 👍🏽👍🏽, пишите в комментах пожелания, вопросы, замечания. Буду рад любой активности. Впереди разборы инструментов, навыков и IT-фишек!