Двухэтапное преобразование: что уже умеет классический ETLT
Возьмём типичный конвейер: скрипт тянет данные из чужого API, что-то чистит по ходу, кладёт в хранилище, а поверх — SQL с бизнес-логикой. Это и есть ETLT. Суффикс «T» здесь не один: первая трансформация T1 выполняется до загрузки и отвечает за очистку, проверку и нормализацию записей, вторая T2 — уже после загрузки и занимает бизнес-правилами, обогащением и формированием схемы. Разделение не косметическое: оно гарантирует, что бизнес-преобразования не упадут из-за мусора на входе, а T2 можно переиграть заново, не вытягивая источник повторно.
Сильнее всего схема проявляет себя там, где надёжность источника под вопросом — например, при интеграции не с базой данных, а с файлами или внешним сервисом. Проверки на T1 отсекают ошибочные записи до того, как они доедут до хранилища.
Ограничения начинаются там же, где заканчивается этот контур. ETLT не обязывает исполнять дата-контракты, не даёт детерминированного воспроизведения, не хранит историю, не мониторит качество и не считает метрики этого качества. Команды обычно делают что-то из этого списка, но как раз — по-разному и без общего стандарта, поэтому результат зависит от того, кто именно писал пайплайн, а не от зафиксированного понятия в проекте. Именно эти пробелы закрывает надстройка, которую автор обозначает как ETLT++ (разбор на Хабре).
Почему классический ETLT не гарантирует качество данных
Отрицательная сумма оплаты по счёту. В источнике это один неверный знак, а в отчёте — искажённая выручка за месяц и неверные бонусы менеджерам. ETLT такую запись не остановит: у паттерна нет обязательного набора проверок, поэтому одна ошибка на стороне источника спокойно доезжает до хранилища и портит итоговые цифры.
Причина в том, что четыре вещи, которые у зрелых команд и так есть, в ETLT остаются необязательными:
- Дата-контракты. В ETLT проверки существуют «от случая к случаю»: набор правил и их строгость не зафиксированы как явный артефакт. Меняется источник — меняется и то, что мы вообще проверяем.
- Детерминированное воспроизведение. Повторить вчерашний прогон и получить тот же результат нельзя: нет гарантии, что входные данные и правила совпадут.
- История. ETLT не требует append-only загрузки, поэтому старые записи могут перезаписываться и исчезать. Аудитор не восстановит, что именно пришло в источник.
- Мониторинг и метрики качества. Свежесть, полнота и точность данных никто не считает регулярно. О проблеме узнают из жалобы на кривой отчёт, а не из алерта.
Каждая из этих дыр бьёт по-своему, но вместе они дают один сценарий: данные попадают в хранилище без явного барьера, а понять, когда и почему всё сломалось, уже невозможно. Перечисленные практики команды применяют, но как стандарт и обязательное понятие они в ETLT отсутствуют — и именно этот пробел закрывает следующее поколение процесса.
Структура ETLT++ как последовательность этапов
ETLT++ удобно записать одной строкой как последовательность из шести элементов:
ETLT++ = ⟨E, C, T1, L, T2, O⟩Каждый элемент — отдельный этап конвейера, и вместе они образуют воспроизводимый, наблюдаемый и историчный процесс. Разберём их по порядку.
E — Extract. Обычное извлечение данных из источника. Это точка входа, знакомая по любому ETL/ELT-пайплайну.
C — Data Contract. Спецификация правил, которые набор данных обязан пройти до попадания в хранилище. Контракт оформляется как явный артефакт (например, в JSON) и задаёт строгость каждого правила: hard или soft. Именно здесь фиксируется, что вообще считается корректной записью.
T1 — Validation and Cleaning. Применение контракта к поступающим данным. При нарушении hard-правила запись уходит в карантин (часто в отдельную таблицу), а soft-правило лишь логирует предупреждение. Если в пакете обнаружено хотя бы одно нарушение hard-правила, вся загрузка пакета останавливается.
L — Load into Versioned Storage. Загрузка в raw zone по принципу append-only: записи только добавляются, но никогда не удаляются и не изменяются. Это и даёт историчность — аналитик, аудитор или инженер может вернуться к состоянию набора данных на нужный момент.
T2 — Business Logic Transformation. Преобразование сырых данных в готовые к анализу наборы: агрегации, обогащение, отслеживание исторических изменений. Обычно реализуется SQL-трансформациями. Важное свойство: T2 можно перезапускать без повторного извлечения источника, поскольку данные уже лежат в версионированном хранилище.
O — Outputs. Публикация подготовленных наборов данных для потребителей — отчётности, аналитики, дашбордов.
Разница с классическим ETLT видна уже в самой записи кортежа: раньше проверки качества, история и мониторинг жили «сбоку» от процесса, теперь это обязательные элементы последовательности. Подробное описание методологии и её происхождение можно найти в оригинальной статье.
Data Contracts: от необязательного элемента к обязательной защите
Допустим, источник присылает пакет из ста записей. Одна из них содержит отрицательную сумму оплаты счёта, остальные корректны. Что делать: отбросить одну запись, принять пакет целиком или остановить загрузку? Ответ зависит от того, к какому типу относится нарушенное правило.
Дата контракт в ETLT++ — это статическая спецификация проверок, которые набор данных обязан пройти до попадания в хранилище. Контракт оформляется как объект правил в формате JSON или аналогичном виде и помимо самих проверок задаёт строгость каждого правила — hard или soft. Это различие и определяет реакцию конвейера на конкретное нарушение.
Hard rules — строгие ограничения. Если запись их нарушает, она не должна пройти в конвейер. Soft rules носят рекомендательный характер: нарушение даёт жёлтое предупреждение в логах, но обработку не блокирует. Такая градация даёт гибкость: жёстко отсекается то, что гарантированно испортит данные, а сомнительные случаи остаются видимыми, но не останавливают работу.
На этапе T1 правила применяются к каждой записи входящего пакета по отдельности. Логика простая: у записи вычисляется индикатор нарушения hard-правил. Если он сработал, запись отправляется в карантин — часто это отдельная таблица. Остальные записи пакета при этом продолжают проверяться. Для soft-правила поведение иное: пишем предупреждение в лог и пропускаем запись дальше.
Карантин — это не свалка брака, а рабочий инструмент. Запись в изолированной таблице можно разобрать, починить на стороне источника и провести повторно, не пересобирая весь пакет вслепую.
Дальше работает уровень всего пакета. По нему считается суммарное число нарушений hard-правил. Если счётчик больше нуля, весь пакет помечается ошибочным и загрузка останавливается до устранения проблемы. С нулём — конвейер идёт к следующему этапу.
Разберём на примере из статьи. В пакете есть одна проблемная запись — номер 1002. Только она нарушает hard-правило, и только она уходит в карантин. Но поскольку пакет в целом оказался ошибочным, загрузка останавливается целиком, пока проблему не разрешат.
Почему останавливать весь пакет, а не продолжать с уцелевшими записями? Потому что иначе итоговые цифры будут считаться по неполным данным, и расхождение никак себя не проявит. Остановка здесь — механизм защиты от тихой неверной отчётности.
Именно поэтому в ETLT++ качество данных — не опция, а обязательное свойство процесса. Контракты, задающие правила, и этап T1, который их применяет, превращают разрозненные проверки «от случая к случаю» в явный и воспроизводимый механизм: каждый набор данных заранее знает, что считается корректной записью, а что нет.
Версионное хранение и историчность как требование append-only
После того как пакет прошёл проверки T1, встаёт вопрос не «куда положить данные», а «что с ними можно делать дальше». Ответ в ETLT++ жёсткий: только добавлять. Этап L загружает записи в raw zone — сырую зону — и работает по принципу append-only. Вставленную строку больше нельзя удалить или изменить, можно лишь дописать следующую.
Правило звучит почти тривиально, но меняет характер хранилища. Обычная таблица живёт по логике «текущее состояние»: обновили цену товара — старая перезаписана. Append-only хранит всю последовательность: цена менялась трижды, и все три значения остаются на месте, каждое со своей меткой времени. Никакая правка задним числом такое хранилище не затрёт.
Зачем это нужно на практике? Представьте разбор инцидента. Аналитик замечает, что отчёт за прошлый квартал не сходится с текущими цифрами. Если данные перезаписывались, восстановить первоначальную картину нечем — прежние значения стёрты. Если хранилище версионирует записи, инженер, аудитор или аналитик может «пройти» по набору данных назад во времени, увидеть, какие строки лежали в системе на нужную дату, и воспроизвести расчёт.
Отсюда и второе следствие: воспроизводимость. Любой результат можно пересчитать на том же срезе данных, что был в момент его получения. Это отделяет гипотезу «в отчёте ошибка» от факта «данные тогда были именно такие» — а без истории такой спор неразрешим.
Технически append-only снимает часть привычных операций: UPDATE и DELETE для raw zone не предусмотрены, вместо них пишутся новые версии строк. Неизменяемость — не ограничение ради самого ограничения, а источник гарантии историчности: если запись нельзя переписать, её невозможно и потерять незаметно.
Ещё одно следствие затрагивает следующий этап. Бизнес-трансформация T2 берёт сырые данные из версионированного хранилища и строит по ним готовые наборы — агрегации, обогащения, отслеживание исторических изменений. Сырьё остаётся нетронутым, поэтому трансформацию можно переписать и прогнать заново, не заглядывая повторно в источник.
SLIs и SLOs: метрики качества данных и автоматический контроль
Четыре обязательных аспекта качества данных в ETLT++ измеряются конкретными формулами, и каждая из них отвечает на свой вопрос о состоянии конвейера.
Freshness показывает, насколько свежи данные. Метрика считается как разница между текущим временем и меткой последнего пакета:
Freshness = Current Time − Timestamp of Latest Batch
Если система ждёт ежедневные продажи, а последний пакет пришёл три дня назад, индикатор сразу это покажет.
Completeness отвечает на вопрос, все ли ожидаемые записи или поля получены:
Completeness = Number of Records Received / Number of Records Expected
Низкое значение сигнализирует об отсутствующих или частичных данных.
Accuracy измеряет соответствие данных правилам валидации из дата-контракта. Скажем, возраст, цены или даты выходят за ожидаемые диапазоны — точность падает:
Accuracy = 1 − Invalid_records / Total Number of Records
Contract Adherence работает на уровне пакета и проверяет соблюдение согласованного контракта — как hard, так и soft правил. Метрика считается как доля полностью соответствующих пакетов:
Contract Adherence = Number of Compliant Batches / Total Batches
Дальше начинается автоматика. Пайплайн сам собирает метаданные и вычисляет эти SLI для каждого набора данных, а затем сравнивает их с заранее заданными порогами SLO. Если метрика проваливается ниже приемлемого уровня, система либо шлёт оповещение инженерам, либо сразу запускает корректирующее действие — повторную загрузку, перерасчёт и подобное. Конкретные проверки при срабатывании выглядят так: убедиться, что последний пакет пришёл в пределах 24 часов; подтвердить наличие всех ожидаемых значений и полей; проверить, что суммы транзакций неотрицательны и лежат в ожидаемых диапазонах; сверить схему с согласованным определением и обязательными полями. История значений SLI сохраняется для аудита и анализа трендов, а циклический пересмотр показателей постепенно улучшает качество данных по материалам статьи.
Ключевые выводы и практический совет по внедрению ETLT++
Три вещи в ETLT++ держат всю конструкцию. Дата-контракты превращают проверку из необязательного шага в жёсткое условие: правила делятся на hard и soft, и нарушение hard-правила не пропускает пакет дальше. Append-only хранение сохраняет каждую вставленную запись неизменной, поэтому инженер, аудитор или аналитик может восстановить состояние данных на любой момент. Мониторинг замыкает цикл: SLI сравниваются с порогами SLO, и при просадке запускаются оповещения или корректирующие действия вроде повторной загрузки и перерасчёта.
Практический совет: не внедряйте всё сразу. Начните с одного критичного источника — опишите для него контракт, отметьте, какие правила hard, а какие soft, и включите для него метрику contract adherence. Так вы увидите реальный процент пакетов, приходящих в ожидаемом формате, прежде чем расширять контракты на остальные конвейеры.
