Методология хранилища — это философия происхождения данных
Inmon, Kimball, Data Vault, Anchor: что выбор архитектуры говорит о том, насколько легко потом ответить «откуда эти данные»
Когда выбирают архитектуру корпоративного хранилища, говорят о масштабируемости, скорости запросов, стоимости поддержки. Редко — о том, насколько легко будет потом ответить на вопрос: откуда пришли эти данные? Кто их изменил? Когда?
Между тем именно этот вопрос определяет, работает ли система аудита, выполняются ли регуляторные требования, можно ли доверять отчёту — и можно ли вообще построить систему ИИ, которая понимает что происходит с данными.
Два определения «правды»
В основе каждой методологии лежит философский выбор: что считать правдой о данных.
Inmon и Kimball отвечают: правда — это выверенный, согласованный ответ. «Единая версия правды» (single version of the truth). Данные очищаются, согласуются между источниками, загружаются в хранилище в том виде, в котором организация договорилась их использовать.
Data Vault отвечает иначе: правда — это полная историческая запись того, что происходило. «Все данные, всё время» (all of the data, all of the time). Вопрос не «какое правильное значение», а «что именно пришло из какого источника и в какой момент».
Это не просто разные лозунги. Это два разных решения о том, где и как хранить информацию о происхождении данных — и в итоге о том, насколько трудно будет ответить на вопрос «откуда это взялось».
Inmon: длинный путь до истины
Архитектура Inmon строится послойно: источники → staging-слой → нормализованное хранилище (3NF) → витрины данных для аналитиков. Каждый слой — отдельная трансформация.
Нормализация до третьей нормальной формы означает: данные разложены по таблицам так, чтобы минимизировать избыточность. Это хорошо для целостности, но усложняет восстановление пути данных. Чтобы проследить путь одной цифры из аналитического отчёта до исходного файла загрузки, нужно пройти через несколько слоёв джойнов и трансформаций.
Важное достоинство: дизайн Inmon time-variant — каждое значение привязано к временному периоду. Это не то же самое, что журнал происхождения, но это хоть какая-то история. Данные не просто перезаписываются.
Практическая сложность: цепочка происхождения из аналитической витрины до источника проходит через staging и 3NF-слой. Каждая трансформация — потенциальный разрыв. Документировать и поддерживать актуальность этой цепочки — организационная задача, не структурная.
Kimball: читаемо, но агрегация ломает цепочку
Звёздная схема Кимбалла — самая дружелюбная для аналитиков архитектура. Таблицы фактов и измерений, понятные бизнес-имена, плоские структуры. BI-инструменты и языковые модели одинаково хорошо её понимают.
Происхождение данных читается на бизнес-уровне: conformed dimensions (согласованные измерения) — это явная общая точка происхождения между разными звёздными схемами. Если измерение «клиент» используется в продажах, финансах и логистике — это один объект с одним источником.
Но здесь работает фундаментальное ограничение, установленное ещё в 2000 году академическими исследованиями (Cui, Widom & Wiener, ACM Transactions on Database Systems, 298+ цитирований): агрегация разрывает стандартную цепочку происхождения строк.
Когда таблица фактов хранит SUM(AMOUNT) вместо отдельных транзакций — исходные строки структурно потеряны. Алгоритмы трассировки, работающие для обычных запросов выборки и проекции, для агрегатов не применимы: нужны специальные методы, которые никак не встроены в звёздную схему.
Это не слабость конкретной реализации — это математическое свойство агрегации. Независимо от того, насколько тщательно задокументирован ETL, если исходные строки свёрнуты в агрегат, полное происхождение на уровне записей не восстановимо стандартными методами.
Второй слабый момент — multi-writer таблицы (о которых мы писали в статье про эффект кучи): когда несколько ETL-процессов загружают данные в одну таблицу фактов из разных источников, Kimball не даёт структурных средств разделить «какая строка от какого процесса». Это вопрос договорённостей и документации, не архитектуры.
Data Vault: происхождение встроено, но слои создают новый вопрос
Data Vault 2.0 — единственная методология, в которой происхождение данных зашито структурно в каждый объект.
Три основных конструкта — Hub (бизнес-ключи), Link (связи) и Satellite (атрибуты) — все содержат обязательные поля RECORD_SOURCE и LOAD_DATE. Это не рекомендация, не best practice, не опциональное поле governance-команды. Это часть спецификации: без этих полей объект Data Vault — не Data Vault.
Спутники (Satellites) работают по принципу append-only: никаких UPDATE или DELETE. Каждое изменение значения атрибута создаёт новую строку с отметкой времени и ссылкой на источник. Raw Vault — это иммутабельная хронологическая летопись, а не кэш текущего состояния.
Это прямо решает проблему multi-writer таблиц: несколько источников, пишущих в один спутник, различаются полем RECORD_SOURCE. Статически, по схеме, без дополнительной документации.
Но здесь возникает новый вопрос, который исследования оставляют открытым: Data Vault 2.0 строится в три слоя — Raw Vault, Business Vault (с бизнес-логикой и деривациями) и Information Mart (часто — та же звёздная схема поверх Vault).
Между слоями — трансформации. И эти трансформации создают те же разрывы в цепочке происхождения, что и в других методологиях. Raw Vault прозрачен. Что происходит с происхождением при переходе в Business Vault — зависит от реализации, а не от стандарта методологии.
Anchor Modeling: теория без практики
Anchor Modeling доводит нормализацию до предела: каждый атрибут — в своей таблице (6NF). Якоря (Anchors) — это сущности, Атрибуты — отдельные таблицы, Связи (Ties) — таблицы отношений.
Теоретически это максимально гранулярное отслеживание происхождения: каждое значение атрибута изолировано, происхождение каждого конкретного поля не смешивается с другими.
Практически — исследование не нашло ни одного подтверждённого источника о применении Anchor в контексте отслеживания происхождения данных. Все 11 утверждений об Anchor Modeling в процессе верификации получили 0–3 балла — отклонены единогласно. Это говорит об одном: методология академически интересна и используется в нескольких европейских организациях, но зрелой практики и документации по работе с происхождением данных в ней нет.
Что это означает для систем ИИ над хранилищем
Когда система на основе ИИ — RAG, GraphRAG, NL2SQL — работает над корпоративным хранилищем, она видит две вещи: схему данных и историю SQL-запросов. И то, и другое определяется методологией.
Звёздная схема Kimball — наиболее читаемая для языковых моделей. Плоские таблицы, бизнес-имена, понятная структура «факт + измерения». Происхождение на уровне таблиц читается легко. Происхождение на уровне отдельных агрегированных значений — не читается в принципе.
3NF Inmon — сложнее для автоматического понимания: много таблиц с техническими именами, длинные цепочки джойнов. Но паттерны нормализации предсказуемы — система, обученная понимать 3NF, может систематически строить граф зависимостей.
Data Vault Raw Vault — самый сложный для наивного NL2SQL: паттерны Hub/Link/Satellite непривычны, запросы требуют понимания структуры. Но: если система знает паттерн — она получает из схемы больше информации о происхождении данных, чем из любой другой методологии. RECORD_SOURCE и LOAD_DATE читаются напрямую.
Data Vault Information Mart — часто это та же звёздная схема. Для NL2SQL верхнего слоя разницы с Kimball нет.
Практически это означает: системы ИИ над Data Vault выигрывают на задачах происхождения данных (откуда это пришло, когда загрузилось, из какого источника) и проигрывают на задачах простого business reporting, если работают с Raw Vault, а не с Information Mart.
Агрегация: универсальный ограничитель
Независимо от методологии, один тип трансформации разрывает цепочку происхождения структурно: агрегация.
Когда данные проходят через GROUP BY + SUM/COUNT/AVG — стандартная трассировка от результата к исходным строкам невозможна стандартными методами. Это установлено академически (Cui, Widom & Wiener, 2000) и не опровергнуто за 25 лет.
Это важно для любой системы, которая строит граф происхождения данных из истории SQL-запросов: запросы с агрегацией создают разрывы в графе. Таблица фактов с суммарными показателями — это конечная точка, не промежуточная.
Происхождение данных как критерий выбора
Исследование не нашло ни одной статьи или академической работы, которая рассматривала бы выбор методологии КХД через призму происхождения данных как первичный критерий. Стандартные критерии — производительность, гибкость, стоимость поддержки, скорость разработки.
Это пробел. И он значимый.
Если организация знает, что через три года ей нужно будет:
- отвечать на вопросы регулятора «откуда пришли эти данные»,
- строить систему ИИ, которая понимает историю данных,
- автоматически обнаруживать потоки через чувствительные таблицы —
то выбор методологии — это не просто архитектурное решение. Это решение о том, насколько дорого будет решать эти задачи потом.
Data Vault строит граф происхождения автоматически, встроенно, с первого дня. Kimball потребует дополнительных инструментов и договорённостей. Inmon даст историю — но не происхождение в полном смысле. Anchor обещает максимум — но зрелой практики нет.
Методология хранилища — это архитектура доверия к данным. Не только для аналитиков, которые работают с ними сейчас. Для систем, которые будут спрашивать «откуда это» — завтра.