Пайплайн данных
Пайплайн обычно описывается как граф зависимостей: задачи, которые выполняются в определённом порядке. У каждой задачи есть свой код, входные и выходные таблицы, расписание и сигналы об ошибках.
Из чего состоит
- Источник данных: продуктовая база, файлы, API.
- Шаги извлечения, преобразования и загрузки.
- Оркестратор (Airflow, Dagster, Prefect и подобные), который запускает задачи по расписанию.
- Мониторинг и алерты, чтобы команда узнала о поломках раньше пользователей.
Что важно
- Идемпотентность: повторный запуск шага не должен дублировать данные и портить картину.
- Контроль качества: проверки на пустые значения, дубликаты, расхождения с источниками.
- Документация: какие таблицы что значат, кто за них отвечает, как часто обновляются.
Когда применять и когда нет
Применять
- Регулярные процессы перемещения данных между системами
- Аналитика, ML и отчётность опираются на свежие данные
- Расчётов становится слишком много, чтобы делать их вручную
Не применять
- Маленькие разовые задачи — для них достаточно одного SQL-запроса или скрипта
Примеры применения
Раньше команда собирала маркетинговый отчёт вручную: выгружала траты из рекламных кабинетов, склеивала в Excel, добавляла выручку из биллинга и присылала по почте. С запуском пайплайна на Airflow всё это делает оркестратор: каждое утро в 6:00 данные обновляются, дашборд показывает свежие цифры, а команда уже к 9:00 видит ROAS по каналам за вчерашний день. Если что-то ломается, в Slack приходит автоматическое уведомление.
Часто задаваемые вопросы
ETL — это конкретный паттерн пайплайна (extract → transform → load). Пайплайн — более общее понятие: внутри него могут быть и ETL, и ELT, и обработка потоков, и ML-фичи. Любой ETL — это пайплайн, не каждый пайплайн — ETL.
Самый известный — Apache Airflow, его выбирают по умолчанию. Современные альтернативы — Dagster и Prefect: у них удобнее работа с зависимостями данных и тестированием. Для маленьких задач подойдёт даже cron, но при росте сложности он быстро становится узким местом.