Загрузка падает молча
Скрипт запускается по cron, падает с ошибкой подключения и об этом никто не знает до момента, когда руководитель открывает отчёт, а данных за вчера нет. Иногда ошибку замечают через неделю.
ETL и ELT-процессы
Данные приходят вовремя и целиком — каждую ночь, без ручной сборки
Строим конвейеры загрузки и преобразования данных: расписание и зависимости, ретраи, алерты, идемпотентные перезапуски, проверки качества и понятный процесс догрузки истории после сбоя.
Или сразу: +7 (962) 368-39-51 Telegram
Airflow
расписание, зависимости и ретраи
dbt
преобразования под контролем версий
CDC
изменения из источника без полной выгрузки
тесты
проверка данных до попадания в отчёт
Как ломаются загрузки данных
Большинство проблем в конвейерах не связано с технологией: это отсутствие проверок, идемпотентности и наблюдаемости.
Повторный запуск удваивает данные
После сбоя оператор запускает скрипт заново, и вчерашние заказы вставляются второй раз. Отчёт показывает рост продаж, которого не было, а найти источник дублей удаётся не сразу.
Инкрементальная загрузка не видит удаления
Из источника забираются только строки с датой изменения. Удалённые записи остаются в витрине навсегда, а обновления статусов, сделанные без смены даты, теряются.
Изменение в источнике ломает конвейер
В 1С переименовали реквизит, в API маркетплейса добавили обязательное поле, и загрузка останавливается или пишет NULL в витрину. Тихая порча данных опаснее явной ошибки.
Секреты и доступы живут в скриптах
Пароли к базам, токены API и учётные записи FTP прописаны прямо в коде cron-скриптов. Уходит сотрудник — вместе с ним уходит и понимание, какие доступы нужно отозвать.
Данные пришли, но они неверные
Загрузка формально успешна: строки есть. Но в них отрицательные суммы, дубли по номеру заказа, ссылки на несуществующих клиентов и нулевые ключи — и всё это уже в отчёте.
Что мы делаем с процессами загрузки
От разбора текущих скриптов до конвейера с расписанием, тестами и алертами в мессенджер.
Оркестрация и расписание
Собираем загрузки в управляемый граф зависимостей вместо набора cron-задач, которые запускаются «примерно в одно время».
- DAG-и в Apache Airflow или Dagster с явными зависимостями между шагами
- Ретраи с нарастающей задержкой и разделение временных и постоянных ошибок
- SLA и оповещения: алерт в Telegram или на почту при срыве расписания
- Ограничение параллелизма, чтобы загрузка не конкурировала с рабочими системами
Извлечение из источников
Забираем данные из всех систем, где они появляются, выбирая способ под нагрузку и требования к свежести.
- REST и GraphQL API, включая пагинацию, лимиты и повторные попытки
- Прямое чтение из PostgreSQL и MySQL по реплике, а не с мастера
- 1С через HTTP-сервисы, выгрузки или чтение реплики базы
- CDC на Debezium и Kafka для источников, где нужны изменения в реальном времени
Преобразование и качество
Описываем преобразования кодом в репозитории, чтобы их можно было проверить, отревьюить и раскатить как обычный релиз.
- dbt-модели по слоям staging и mart с едиными макросами
- Инкрементальные модели с уникальным ключом и стратегией merge
- Тесты: уникальность, отсутствие NULL в ключах, ссылочная целостность, допустимые диапазоны
- Готовые проверки на аномалии: резкое падение объёма строк или скачок суммы
Надёжность и восстановление
Проектируем процесс так, чтобы сбой был рутинным событием, а не аварией с ручной правкой данных.
- Идемпотентность: повторный запуск за тот же период не создаёт дублей
- Watermark и учёт опоздавших записей в инкрементальных загрузках
- Backfill истории по расписанию после исправления логики
- Логи запусков, метрики длительности и наблюдаемость по каждому шагу
Как строится процесс загрузки
Начинаем с инвентаризации того, что уже работает, — обычно часть скриптов можно использовать как основу.
-
01 1 неделя
Инвентаризация
Собираем список источников, текущих скриптов, расписаний и известных проблем. Фиксируем требования к свежести данных по каждому отчёту.
-
02 2–3 недели
Оркестратор и первые DAG-и
Поднимаем Airflow, переносим критичные загрузки, настраиваем ретраи, алерты и логирование запусков.
-
03 3–6 недель
Преобразования и тесты
Переносим логику из скриптов в dbt-модели, добавляем тесты качества и защиту от дублей, настраиваем backfill.
-
04 по SLA
Дежурство и развитие
Описываем регламент: как читать алерты, как догрузить период, как добавить источник. Передаём команде или берём на поддержку.
Чем ETL отличается от ELT и что выбрать
В классическом ETL преобразование происходит до загрузки: данные очищаются и обогащаются на стороне процесса, и в хранилище попадает уже подготовленная структура. В ELT сначала загружается сырой слепок из источника, а преобразования выполняются средствами самого хранилища — как правило, SQL-моделями dbt. Второй подход стал основным там, где хранилище достаточно мощное, потому что сырые данные остаются доступны для пересборки и разбора инцидентов.
На практике мы чаще строим гибрид: из источников данные забираются в слой raw максимально близко к оригиналу, включая технические поля вроде времени изменения и идентификатора загрузки, а преобразования живут в dbt-моделях поверх него. Это даёт воспроизводимость: любую витрину можно пересобрать заново из сырых данных, не обращаясь повторно к рабочей системе.
Идемпотентность: почему один и тот же запуск должен давать один результат
Идемпотентность означает, что повторный запуск процесса за тот же период не изменяет результат. Это главное свойство надёжного конвейера: сбои случаются всегда, и реакция на них должна быть скучной — просто запустить шаг снова. Без идемпотентности восстановление превращается в ручную чистку дублей, а иногда и в сверку сумм с бухгалтерией.
Мы добиваемся этого несколькими приёмами: загрузка периода выполняется в staging-таблицу с последующим merge по ключу и дате, для каждого запуска фиксируется окно загрузки и watermark, а вставки сопровождаются идентификатором загрузки. Для инкрементальных моделей задаётся уникальный ключ, а удаления обрабатываются отдельно — через сравнение снимков или через CDC. Проверка простая: запускаем один и тот же период дважды и убеждаемся, что количество строк и контрольные суммы не изменились.
Как понять, что данные в отчёте верные
Доверие к данным строится не на обещаниях, а на проверках, которые выполняются автоматически при каждой загрузке. Мы настраиваем четыре группы тестов. Структурные — на схему: наличие обязательных колонок, соответствие типов, отсутствие NULL в ключах. Логические — на допустимые значения: сумма неотрицательна, статус входит в справочник, дата не из будущего.
Связностные тесты проверяют ссылочную целостность: каждая позиция заказа ссылается на существующий заказ и товар. И, наконец, объёмные: количество строк и сумма за день не отличаются от обычного диапазона более чем на заданный процент. Если тест падает, витрина не обновляется, а дежурный получает уведомление с конкретной причиной — это лучше, чем отчёт с тихо испорченными цифрами.
Частые вопросы
Для двух-трёх загрузок в сутки иногда достаточно cron и небольших скриптов с логированием. Airflow становится нужен, когда появляются зависимости между шагами, потребность в ретраях, разделении по расписанию и наглядной истории запусков. Мы не усложняем инфраструктуру заранее: если нагрузка небольшая, делаем простое решение, а оркестратор подключаем тогда, когда он реально экономит время дежурства.
Это типовая ситуация: документы проводятся позже даты операции, статусы пересчитываются, возвраты уменьшают выручку прошлых периодов. Мы обрабатываем её явно: витрина строится с окном пересчёта, например последние 30 дней перезагружаются при каждом запуске, а изменения фиксируются в истории. Так отчёт за прошлый месяц всегда актуален и при этом можно увидеть, как цифра менялась.
Один источник с одной таблицей переносится за день-два: переносим логику, добавляем идемпотентность и тесты. Источники с историей, справочниками и неочевидной логикой обновлений — например 1С или маркетплейсы — занимают от недели до трёх, потому что требуют разбора бизнес-правил. Обычно мы предлагаем начать с двух самых критичных источников и дальше идти по приоритету.
Каждый запуск пишет статус, длительность и количество обработанных строк. Настраиваются два уровня контроля: технический — упал шаг, превышено время, не прошёл тест; бизнесовый — данных за период меньше ожидаемого, сумма отклонилась от нормы. Алерты приходят в Telegram или на почту дежурному, а история запусков доступна в веб-интерфейсе оркестратора.
Data Science: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Загрузки данных требуют ручного контроля?
Опишите, из каких систем и с какой периодичностью нужно забирать данные, — предложим схему конвейера и сроки.