Сайт А. Мокрышева

RAW, CLEAN, MAPPED и AGGREGATED как основа проверяемой корпоративной отчетности

ETL часто воспринимают как технический механизм: забрать данные из одной системы, преобразовать и загрузить в другую.

Для небольших задач такой подход может работать. Но в корпоративной архитектуре, где есть ERP, CRM, бухгалтерия, казначейство, склад, производство, бюджетирование, DWH, OLAP или EPM, простого «забрать и положить» недостаточно.

Данные должны пройти управляемый путь: сохраниться в исходном виде, пройти проверку, получить связь с целевой моделью, агрегироваться до нужной детализации и при этом сохранить возможность drill-down от итоговой цифры в отчете до исходной строки.

Поэтому ETL — это не набор разрозненных загрузочных скриптов. Это система таблиц фактов, справочников и мэппинга, организованная в последовательные слои обработки данных.

Из чего состоит ETL-система

Архитектурно ETL-система строится вокруг трех типов таблиц.

Первый тип — таблицы фактов.

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

Второй тип — таблицы справочников.

Они задают допустимые значения: продукты, контрагенты, статьи бюджета, счета учета, подразделения, ЦФО, валюты, проекты, сотрудники, юридические лица, периоды и другие классификаторы.

Третий тип — таблицы мэппинга.

Они связывают значения исходных систем со структурой целевой системы. Например, исходный счет учета превращается в управленческую статью, подразделение ERP — в ЦФО, номенклатура — в продуктовую группу, контрагент — в клиентский сегмент.

Базовый поток ETL состоит из четырех слоев

RAW; CLEAN; MAPPED; AGGREGATED. Каждый слой — это группа таблиц. Каждый следующий слой является результатом обработки предыдущего. Между слоями обязательно сохраняются идентификаторы и связи, чтобы итоговую цифру можно было проследить назад до источника.

RAW: данные как есть RAW — первый слой ETL.

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

Если из ERP выгружено 10 000 строк документов, в RAW должно быть видно, что именно эти 10 000 строк были получены, не повреждены и не потеряны.

RAW-слой хранит не только бизнес-данные, но и технический контекст: источник, пакет загрузки, файл или API-вызов, дату загрузки, период данных, версию, статус и контрольные суммы.

RAW не предназначен для аналитики. Он фиксирует исходную точку данных и позволяет доказать, что ошибка, если она возникла, появилась не на этапе извлечения.

CLEAN: проверенные данные CLEAN — второй слой ETL.

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

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

Так ETL превращает качество данных в управляемый процесс, а не в ручное расследование.

MAPPED: данные с адресом в целевой системе

MAPPED — третий слой ETL. Здесь проверенные данные из CLEAN связываются с целевой моделью.

По сути, MAPPED — это копия CLEAN-таблиц, к которым добавлены поля справочников целевой системы. Эти поля задают адрес строки в DWH, OLAP, EPM или другой аналитической модели.

Например, к исходному счету учета добавляется управленческая статья, к исходному подразделению — целевой ЦФО, к номенклатуре — продуктовая группа, к контрагенту — клиентский сегмент, к операции — целевой показатель.

Именно MAPPED-слой превращает операционные данные в управленческие. Таблицы мэппинга должны хранить исходные значения, целевые значения, условия применения, период действия, версию правила, коэффициенты распределения и статус.

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

MAPPED-таблица должна сохранять и исходные, и целевые поля. Нельзя просто заменить одно другим, иначе будет невозможно объяснить, почему строка попала именно в эту статью, продукт, ЦФО или показатель.

Если для строки не найден валидный мэппинг, она не должна проходить дальше. Такая строка корректна с точки зрения источника, но непригодна для целевой отчетности, пока для нее не определено место в целевой модели.

AGGREGATED: данные в детализации целевой системы

AGGREGATED — четвертый слой ETL. Здесь данные из MAPPED сворачиваются до детализации целевой системы. Исходные системы обычно хранят данные детальнее, чем нужно аналитическому контуру. ERP хранит строки документов, банк — отдельные движения, CRM — сделки, производство — операции.

Но DWH, OLAP или EPM часто работают с агрегированными комбинациями: период, сценарий, версия, статья, ЦФО, продукт, валюта, показатель, сумма. AGGREGATED-слой формирует такие итоговые строки. При этом детализация не должна теряться.

В MAPPED-таблицы добавляется идентификатор AGGREGATED-строки, в которую вошла каждая конкретная строка или сумма.

Благодаря этому можно построить drill-down: целевая цифра → AGGREGATED → MAPPED → CLEAN → RAW → источник. Это главный принцип надежного ETL.

Агрегация должна происходить только после проверки и мэппинга, иначе теряется связь между итогом и исходными данными.

Справочники и мэппинг

В ETL важно различать справочники исходных систем и справочники целевой системы. Справочники источников используются на CLEAN-слое. Они подтверждают, что данные корректны внутри исходной системы. Справочники целевой системы используются на MAPPED-слое.

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

Например, в ERP появился новый счет или продукт, но для него еще не создана управленческая статья или продуктовая группа.

Поэтому таблицы мэппинга — это не техническая мелочь, а методологическое ядро ETL. В них описано, как операционная реальность компании переводится в язык управленческой отчетности.

Ошибки как часть ETL-процесса

Ошибки ETL должны храниться в отдельных таблицах, а не только в технических логах. Ошибка может возникнуть на CLEAN-слое, когда данные не соответствуют правилам источника. Или на MAPPED-слое, когда данные корректны, но не связаны с целевой моделью. Для каждой ошибки нужно хранить слой, правило, описание, источник, пакет загрузки, период, статус и ответственного за исправление.

Часть ошибок может блокировать весь пакет, часть — только отдельные строки, часть — проходить как предупреждение. Но это должно быть явным правилом процесса. Такой подход делает ошибки управляемыми и понятными не только разработчикам, но и владельцам данных.

Версии, периоды и пакеты

Для корпоративного ETL критичны технические измерения: период данных, период загрузки, пакет и версия. Период данных показывает, к какому бизнес-периоду относится факт. Период загрузки показывает, когда данные попали в ETL. Пакет фиксирует конкретную порцию данных: файл, выгрузку, API-вызов или сессию загрузки. Версия отражает состояние данных или правил: рабочая, проверенная, финальная, опубликованная.

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

Архитектурный принцип

ETL нужно проектировать не как набор процедур, а как систему связанных таблиц. Минимальная архитектура должна включать: RAW-таблицы фактов; CLEAN-таблицы фактов; MAPPED-таблицы фактов; AGGREGATED-таблицы фактов; справочники источников; справочники целевой системы; таблицы мэппинга; таблицы ошибок; таблицы пакетов; таблицы версий; таблицы правил проверки и агрегации. Главная цель такой архитектуры — трассируемость.

Каждая итоговая цифра должна иметь путь назад к исходным строкам. Каждое преобразование должно иметь правило. Каждый мэппинг должен иметь версию. Каждая ошибка должна иметь статус.

Что важно разработчику

Разработчику важно не превращать ETL в набор одноразовых скриптов. Первый источник почти всегда кажется простым.

Потом добавляется второй, меняется формат, появляются новые справочники, частичные перезагрузки, версии мэппинга, требования аудита и необходимость объяснить цифру в отчете. Поэтому даже в первом релизе стоит заложить базовую дисциплину: хранить RAW как есть, отделять CLEAN от RAW, отделять MAPPED от CLEAN, делать AGGREGATED отдельным слоем, не агрегировать до мэппинга, сохранять идентификаторы между слоями, вести ошибки, пакеты, версии и правила. Это выглядит избыточно только до первого серьезного расхождения в отчетности.

Финальный вывод

Корпоративная ETL-система — это не просто перенос данных между системами. Это набор связанных таблиц фактов, справочников и мэппинга, организованных в четыре слоя: RAW — данные, загруженные из исходных систем как есть; CLEAN — данные, проверенные по типам, форматам, диапазонам и справочникам источников; MAPPED — проверенные данные, дополненные целевыми аналитиками; AGGREGATED — данные, свернутые до детализации целевой системы.

Ключевой принцип — не потерять связь между слоями.Итоговая цифра в отчете должна быть связана с AGGREGATED-строкой, AGGREGATED — с MAPPED, MAPPED — с CLEAN, CLEAN — с RAW, а RAW — с исходной системой.

Именно эта цепочка делает данные проверяемыми. Без нее ETL становится черным ящиком. С ней ETL превращается в надежный контур корпоративной архитектуры данных, на который можно опираться в отчетности, бюджетировании, план-факт анализе, управленческом учете и принятии решений.