В CRM клиент называется одним способом. В банке — другим. Реклама принесла свой идентификатор, а Excel добавил пробел в конце строки. Все данные существуют. Встретиться им пока сложно.
ETL — это процесс, который забирает данные из источников, приводит их к общим правилам и загружает туда, где их можно нормально анализировать.
Что такое ETL простыми словами
ETL расшифровывается как Extract, Transform, Load:
- Extract — извлечь. Получить данные из CRM, рекламы, банка, файлов и других систем.
- Transform — преобразовать. Очистить, связать, привести даты, валюты и справочники к одному виду.
- Load — загрузить. Записать подготовленные данные в хранилище или другую систему.
ETL не является одной конкретной программой. Это порядок работы с данными. Его можно собрать кодом, облачным сервисом или даже Power Query для небольшой задачи.
Пример ETL-процесса
Компания хочет видеть прибыль по рекламным каналам. Процесс забирает расходы из рекламных кабинетов, сделки из CRM, оплаты из банка и себестоимость из учётной системы.
На этапе преобразования приводим даты к одному часовому поясу, соединяем заказ с оплатой, убираем дубли, учитываем возвраты и сопоставляем источники. Затем загружаем готовые таблицы в DWH — хранилище данных.
Дашборд читает уже подготовленный слой. Ему не приходится каждый раз заново знакомить «ООО Ромашка» с «Ромашка, ООО».
Полная и частичная загрузка
При полной загрузке процесс переносит весь набор данных. Это удобно для первого запуска и небольших таблиц.
При частичной загрузке берутся только новые и изменившиеся записи. Такой подход быстрее, но требует надёжно определять изменения и уметь повторить шаг без дублей.
Полезно хранить журнал: когда процесс запустился, сколько строк забрал, что отклонил и где остановился. Молчаливый ETL очень вежливый, но для поддержки неудобный.
ETL и ELT: в чём разница
В ETL данные преобразуются до загрузки в целевое хранилище. В ELT сначала загружаются, затем преобразуются силами самого хранилища.
Выбор зависит от объёма, инструментов, требований к безопасности и того, нужно ли сохранять сырой слой. Название подхода менее важно, чем понятные правила и возможность проверить путь цифры.
Сначала договоритесь о данных
Для каждого источника нужен простой контракт: какие поля приходят, что они означают, где уникальный идентификатор, как записана дата и что считается удалением.
Если CRM завтра переименует статус или начнёт отдавать дату в другом часовом поясе, процесс должен заметить изменение, а не тихо пересчитать историю. Поэтому схему и правила лучше хранить рядом с кодом или настройками загрузки.
Какие проверки ставить в ETL
- источник доступен и ответил полностью;
- число строк не изменилось необъяснимо резко;
- ключевые поля не стали пустыми;
- уникальные ID действительно уникальны;
- сумма оплат сверяется с контрольным источником;
- отклонённые строки сохранены и видны ответственному.
Зелёный статус «процесс завершён» недостаточен. Он мог успешно загрузить ноль строк. Нужны проверки результата.
Как повторять загрузку без дублей
ETL должен безопасно переживать повторный запуск. Для этого используют стабильный ключ записи, время изменения и правило обновления: добавить новую строку, заменить текущую или сохранить новую версию.
Например, оплата с одним ID не должна появиться дважды после повторного запроса к банку. А изменение статуса сделки должно обновить нужную запись или добавить версию истории — в зависимости от задачи.
Повторяемость особенно важна после сбоя. Если процесс остановился на середине, команда должна продолжить с понятной точки, а не очищать всё вручную и надеяться на лучшее.
Как не потерять историю
Рабочие системы часто показывают только текущее состояние. Менеджер поменял ответственного — старое значение исчезло. Для аналитики может быть важно знать, кто вёл сделку в момент продажи.
Поэтому заранее решите, какие изменения нужно хранить как историю: статусы, ответственных, цены, сегменты клиента. Не обязательно версионировать всё подряд. Сохраняйте то, что влияет на отчёты и решения.
Что делать при сбое
Журнал должен показать источник, шаг, время, число обработанных строк и текст ошибки. Уведомление отправляется человеку, который может принять действие. После исправления загрузка повторяется идемпотентно, а контрольные суммы сверяются снова.
Если отчёт использует неполные данные, лучше явно показать задержку обновления. Старое честное число полезнее свежего наполовину.
Подробный пример одного потока
Нужно связать рекламный расход с оплатой. Из кабинета забираем кампанию, дату и расход. Из CRM — заявку, сделку, клиента и рекламные метки. Из банка — платёж с назначением и суммой.
На извлечении сохраняем исходные ответы и время загрузки. На преобразовании приводим даты к одному часовому поясу, очищаем телефоны, сопоставляем рекламные метки со справочником и связываем оплату со сделкой. На загрузке обновляем таблицы расходов, сделок и оплат по стабильным ключам.
После выполнения сверяем сумму рекламных расходов с кабинетом, количество сделок с CRM и общий объём поступлений с банком. Несвязанные оплаты не удаляем: отправляем в отдельный список на проверку.
Только затем витрина считает выручку и маржу по каналам. Если одна оплата не связалась, отчёт показывает её как проблему качества, а не незаметно теряет.
Как выбрать расписание
Частота загрузки должна соответствовать решению. Дашборд для ежедневной работы может обновляться каждый час. Управленческий P&L — раз в день или после закрытия периода. Нет смысла опрашивать медленный источник каждую минуту, если цифру обсуждают раз в месяц.
Задайте допустимую задержку для каждого набора. Если источник опоздал, система сообщает об этом и не смешивает свежие данные с устаревшими без отметки.
Что учесть по безопасности
Процессу выдавайте только нужные права. Ключи хранятся в secret store, а не в коде и логах. Персональные данные ограничиваются, маскируются или не переносятся, если для отчёта они не нужны.
Доступ к сырым данным и журналам тоже контролируется: в них могут оказаться значения, которые нельзя показывать всем пользователям BI.
Как принять ETL-процесс
- Провести контрольные записи от источника до витрины.
- Повторить загрузку и убедиться, что дублей нет.
- Проверить исправление изменённой записи.
- Сымитировать недоступность источника.
- Проверить уведомление, журнал и точку продолжения.
- Сверить итоговые суммы с системами.
Что делать, когда источник изменился
CRM может переименовать поле, API — вернуть новый формат даты, а таблица — получить ещё одну колонку. Если поток молча проглотил изменение, ошибка обнаружится уже в отчёте.
Поэтому на входе полезно проверять схему: обязательные поля, типы данных и допустимые значения. При несовместимом изменении загрузка останавливается, сохраняет понятную ошибку и не заменяет хорошие данные пустыми.
Совместимые изменения тоже фиксируются. Новая необязательная колонка может загрузиться, но владелец потока должен решить, нужна ли она в модели. Автоматизация не отменяет договорённость о смысле.
Как работать с опоздавшими данными
Заказ мог появиться сегодня, а оплата — через неделю. Сделку могли исправить задним числом. Поэтому загрузка только «всё после последней даты» иногда пропускает изменения.
Один из простых вариантов — каждый раз перечитывать небольшое окно назад. Например, ежедневный поток заново забирает последние семь дней и обновляет записи по устойчивому идентификатору. Для более старых исправлений нужен отдельный журнал изменений или периодическая сверка.
Как безопасно пересчитать историю
Если формула изменилась, часто нужно обновить прошлые периоды. Такой пересчёт называют backfill. Его лучше запускать отдельно от обычной загрузки: указать диапазон дат, версию правила и ожидаемый объём.
Сначала проверяем небольшой период. Затем считаем контрольные суммы до и после, сохраняем журнал и только потом расширяем диапазон. Если 10 миллионов строк внезапно стали 6 миллионами, процесс не должен радостно сообщить «готово».
Кто за что отвечает
У каждого потока нужен владелец данных и технический владелец. Первый объясняет смысл поля и принимает бизнес-правило. Второй следит за загрузкой, логами и восстановлением. Пользователь отчёта знает, куда сообщить о проблеме.
Для критичных потоков зафиксируйте допустимую задержку и срок восстановления. Например, продажи должны обновиться к 9:00, предупреждение уходит после 30 минут задержки, а отчёт показывает время последнего успешного обновления.
Как не превратить ETL в дорогой пылесос
Полные загрузки просты, но с ростом данных начинают тратить время и деньги. Храните объём, длительность и стоимость каждого запуска. Часто достаточно перейти на частичную загрузку, убрать ненужные поля и реже пересчитывать старую историю.
Оптимизация нужна после измерения. Если маленькая таблица обновляется за минуту, сложная архитектура экономии может стоить дороже самой загрузки.
Как мы строим ETL в работе
Я начинаю с бизнес-вопроса и одной цепочки данных. Например: рекламный расход → заявка → сделка → оплата → маржа.
Затем фиксируем ключи связи, правила очистки и проверки. Несколько записей проводим руками от источника до отчёта. После этого автоматизируем расписание и контроль.
Маркетолог получает обновляемую экономику каналов. Продажи — единые статусы. Собственник — цифру, путь которой можно объяснить, а не только показать.
Если данные уже есть во всех системах, но вместе собираются вручную, можно начать с одного ETL-потока. Кнопка ниже — чтобы спроектировать его со мной.
