Самая дорогая часть аналитики — не дашборд. Самая дорогая часть — интеграции и трансформации данных. Там рождаются «почему не сходится» и «давайте ещё один файл».
Термины на 1 минуту:
- ETL (Extract–Transform–Load) — извлечь данные → преобразовать → загрузить в DWH.
- ELT (Extract–Load–Transform) — загрузить “как есть” → преобразовать уже внутри DWH.
- Источник данных — система, где данные появляются (1С, DMS, SFA, EDI, Excel дистрибьютора).
- Справочник — единый список сущностей (SKU, клиенты, точки, дистрибьюторы).
- Логирование — журнал загрузок: что пришло, что не пришло, что было исправлено.
ETL или ELT — что выбрать “по‑человечески”
- ETL полезен, когда нужно жёстко контролировать качество ДО загрузки.
- ELT удобен, когда источников много и вы хотите быстро начать, а преобразования наращивать постепенно.
На практике чаще всего работает гибрид: грузим «сырые» данные в слой Raw, затем строим “правильные” витрины.
7 правил ETL, которые экономят месяцы
1) Каждый источник — отдельный контракт данных.
Что, когда, в каком формате, что считается ошибкой.
2) Идентификаторы важнее названий.
Нужны стабильные ключи: SKU_ID, Client_ID, Distributor_ID.
3) Справочники — не “потом”.
Без единого каталога SKU и контрагентов KPI не будут сходиться.
4) Версионируйте правила.
Если поменяли расчёт KPI — фиксируйте дату и версию.
5) Загрузка без логов — это лотерея.
Должно быть видно, что пришло, что пропало, что “подозрительно”.
6) Один календарь периодов.
Неделя/месяц/закрытый период должны быть одинаковы для всех отчётов.
7) Контроль качества по правилам.
Отрицательные продажи, остатки “в минус”, дубли точек, неожиданные скачки.
Мини‑шаблон “контракта данных” с дистрибьютором
Что считать “хорошим ETL” для бизнеса
Три типовых поломки ETL (и как их поймать заранее)
- Сдвиг формата: в файле поменяли колонку местами → загрузка “молча” поехала. Лечится валидацией схемы.
- Пропуск выгрузки: данные не пришли сегодня, но отчёт построился на вчерашних. Лечится алертом «данные не обновились».
- Тихие дубли: одна и та же строка загружена дважды → KPI “подросли”. Лечится контролем уникальности ключей.
Хороший ETL — это не “прошло без ошибок”. Это когда:
- вы заранее знаете, что считать «данные не пришли» (и получаете сигнал),
- есть понятная причина отклонений (например, 12% SKU без мэппинга),
- можно восстановить историю: что было в файле, что исправили, что отбросили.
И ещё: ETL должен быть повторяемым. Если один человек ушёл в отпуск — загрузка не должна превращаться в ручной квест.
- частота (ежедневно/неделя),
- состав полей,
- допустимые значения,
- правила закрытых периодов,
- кто отвечает за исправления,
- SLA на повторную выгрузку при ошибке.
Если ETL сделан как «пара скриптов без правил», он всегда превращается в ручную поддержку. Если ETL оформлен как контракт и контроль качества — он масштабируется на десятки источников.
Лонгрид про DWH/ETL/OLAP/BI: "Управление данными в компании: DWH, ETL, OLAP и BI без магии и маркетинга".
Продукт ARK для качества данных и мастер‑данных (единые справочники, правила проверки, работа с дублями): ARK Space MDM.