Поговорим о методологии интеграции источников с хранилищами данных. Статья описывает научную теорию и, в первую очередь, носит задачу упорядочить свои собственные знания.

AI не использовался при написании и при редактировании.

Все мы знаем о понятиях ETL/ELT, оно же ETLT. В добавок к этим паттернам на проектах применяют необязательную стадию проверки качества данных, создают аудит загрузок данных, а так же систематизируют дальнейшую поддержку. Но перечисленные стадии не являются обязательными. В то же время они показали свою полезность и если эти стадии добавить к базовым паттернам, получим следующее поколение процессов ETL/ELT с суффиксом «++», то есть ETLT++.

ETLT

Очистка и валидация данных являются критически важными. Шаблон ETLT обеспечивает качество данных на начальном этапе преобразования и обозначается T1, рисунок — 1. На данном этапе применяются очистка, проверка и нормализация. Только после этого контроля данные загружаются в хранилище. Затем на втором этапе T2 применяются бизнес‑правила трансформации, обогащение и формирование схемы. ETLT гарантирует, что последующие бизнес‑преобразования не будут падать с ошибкой из‑за некачественных входных данных. Так же такая схема позволяет выполнять повторные трансформации T2 без повторного извлечения исходных данных.

ETLT очень хорошо работает, когда качество данных не само собой разумеющееся, например источник не является базой данных. В системах, где надежность источника низкая. Паттерн гарантирует, что ошибочные записи будут обнаружены до того, как они попадут в хранилище.

Однако, несмотря на свои сильные стороны, шаблон не подразумевает: обязательного исполнения дата контрактов, возможности детерминированного воспроизведения, хранения истории, мониторинга и расчетных показателей качества данных. Важно отметить, что дата команды делают в том или ином виде все вышеперечисленное, но как стандарт или понятие отсутствует.

ETLT++

ETLT++ добавляет к ETLT расширенные контрольные метрики и функции. Отличие заключается в переходе от случайных процессов к паттерну проектирования, который гарантирует воспроизводимость, мониторинг, непрерывное обеспечение качества и историчность данных.

Определяется ETLT++ как последовательность этапов:

ETLT++ = ⟨E, C, T1 , L, T2 , O⟩

где:

E (Extract): этап обычной экстракции из источника
C (Data Contract): Дата контракт. Объект правил в формате JSON или другом виде. Контракт обычно указывает на различные правила. Дополнительно задается строгость правил (hard/soft).
T1 (Validation and Cleaning): Непосредственно применение контракта. При нарушении hard правила запись помещается в карантин (может быть отдельная таблица), при нарушении soft правила логируется предупреждение. Если возникают какие‑либо hard, то останавливается вся загрузка.
L (Load into Versioned Storage): Загрузка записей в raw zone, которая сохраняет все записи методом append. Гарантируется историчность.
T2 (Business Logic Transformation): Операции трансформации, которые преобразуют сырые данные в структурированные, готовые к анализу наборы данных, например, агрегации, обогащения или отслеживание исторических изменений, с использованием SQL трансформации.
O (Outputs): Публикация подготовленных наборов данных.

C — Data Contracts

Data contract — статическая спецификация правил/проверок, которую должен пройти набор данных перед загрузкой в хранилище. Дата контракты очень важны. Без механизма фильтрации, некачественные данные попадают в хранилище. Одна ошибка на стороне источника (например, отрицательное значение оплаты счета) исказит итоговые цифры. В отличие от ETLT, где механизмы проверки могут быть от случая к случаю, ETLT++ обозначает этапы проверок данных, определенных в data contracts, как обязательные и явные средства защиты.

Data contracts не являются чем‑то новым, однако в существующих системах они часто являются необязательными или внедряются непоследовательно.

Правила могут быть классифицированы как hard или soft. Hard rules — это строгие ограничения, и в случае их нарушения данные не должны поступать в конвейер. Soft rules носят рекомендательный характер, нарушения вызывают только желтый уровень предупреждений, но не блокируют обработку. Это различие обеспечивает гибкость.

T1 — Validation: Enforcing Contracts

Этап непосредственно применения T1. Валидация данных.

На данном этапе для каждой записи в поступающем пакете: вычисляется индикатор нарушения hard правил. Если запись нарушает правило, то она помещается в карантин. А валидация остальных записей пакета продолжается. Если нарушено soft правило, залогировать предупреждение, но разрешить продолжение обработки.

На уровне всего входящего пакета вычисляется общее количество нарушений hard правил и если оно больше нуля, загрузку всего пакета пометить ошибочным и остановить; в противном случае продолжить выполнение следующего процесса.

Пример: Предположим, мы получаем пакет из пяти записей клиентов, рисунок 2.

Рисунок 2 - Пример валидации — Рисунок 2 — Пример валидации

Только запись 1002 нарушает hard правило и помещается в карантин. Поскольку пакет ошибочный, загрузка пакета останавливается до разрешения проблемы. Иными словами, в ETLT++ качество данных является не опцией, а обязательным свойством.

L — Loading and Versioning

ETLT++ рассматривает загрузку данных в режиме append‑only как обязательную. Данные сохраняются неизменяемыми: после вставки записи никогда не удаляются и не изменяются, а только добавляются. Это гарантирует, что аналитики, аудиторы и инженеры всегда могут совершить «путешествие во времени» по набору данных для воспроизведения и валидации.

Мы рассмотрели основные этапы ELT++ процесса. Далее мы рассмотрим дополнительную аналитику качества загрузки данных.

Мониторинг и обеспечение качества данных

Этапы рассмотрели, но даже при их наличии конвейеры могут генерировать ошибки, задержки или несоответствия из‑за сбоев на стороне источников, пропуски данных.

ETLT++ предлагает Service Level Indicators (SLIs), которые отражают основные аспекты качества как: freshness, completeness, accuracy и contract adherence. Данные аспекты предлагаются как обязательные.

Freshness — эта метрика оценивает, насколько актуальными являются данные. Например, если система ожидает ежедневные данные о продажах, но последний пакет был получен три дня назад, SLI для freshness просигнализирует о проблеме.

Freshness = Current Time − Timestamp of Latest Batch

Completeness оценивает, все ли ожидаемые записи или поля были получены. Низкий показатель указывает на отсутствующие или частичные данные.

Completeness = Number of Records Received / Number of Records Expected

Accuracy измеряет, насколько хорошо данные соответствуют правилам валидации, определенным в дата контрактах. Например, если возраст, цены или даты выходят за пределы ожидаемых диапазонов, accuracy снижается. Поддержание высокой accuracy гарантирует, что данные, используемые для отчетности и принятия решений достаточны.

Accuracy = 1 − Invalid_records / Total Number of Records

Contract Adherence это метрика уровня пакета и проверяет, соблюдает ли каждый поступающий пакет согласованный data contract, включая как hard rules (которые должны быть выполнены), так и soft rules (которые могут генерировать предупреждения). Contract adherence может мониториться как процент пакетов, полностью соответствующих контракту. Отслеживание contract adherence обеспечивает видимость того, поставляют ли источники данные в ожидаемом формате и структуре.

Contract Adherence = Number of Compliant Batches / Total Batches

Как только индикаторы SLIs определены, пайплайн оснащается инструментами для автоматического сбора метаданных. Показатели качества вычисляются для каждого набора данных и сравниваются с заранее определенными пороговыми значениями SLO (Service Level Objective). Если какая‑либо метрика падает ниже приемлемого уровня, автоматические оповещения уведомляют инженеров, или запускаются корректирующие действия, такие как повторная загрузка, перерасчет и тд. Исторические данные SLI сохраняются для аудита и анализа трендов, а циклический анализ значений SLI непрерывно улучшает качество данных с течением времени, рисунок 3.

Пример действий при превышении индикаторов:

Freshness: Проверить, что последний пакет пришел в пределах 24 часов.
Completeness: Подтвердить, что все ожидаемые значения и поля присутствуют.
Accuracy: Суммы транзакций неотрицательны и находятся в ожидаемых диапазонах.
Contract Adherence: Проверить, что схема соответствует согласованному определению и обязательные поля присутствуют.

Заключение

ETLT++ это:

Data Contracts
Versioned хранение
Continuous monitoring: SLIs и SLOs интегрированы в пайплайн.

Эти свойства выносят ETL/ELT на совершенно новый качественный уровень.

Эта статья результат глубокой переработки научной статьи от ноября 2025 итальянских исследователей Rucco, C., Saad, M., Longo, A. Original article