Inmon и Corporate Information Factory
До сих пор мы изучали отдельные техники — нормализацию, star schema, SCD. Но из чего собрать целый data warehouse? В каком порядке строить, что считать «источником истины», как избежать хаоса из десятков несогласованных таблиц? На эти вопросы отвечают методологии DWH — целостные подходы к проектированию хранилища. Их две классических: Inmon и Kimball, плюс третий путь — Data Vault.
Начнём с Inmon. Билл Инмон (Bill Inmon) — человек, которого называют «отцом data warehouse»; он сформулировал само понятие ещё в начале 1990-х. Его подход известен как Corporate Information Factory (CIF) — «корпоративная фабрика информации».
Идея: единое нормализованное ядро
Инмон определил data warehouse как «предметно-ориентированное, интегрированное, неизменяемое и хранящее историю собрание данных для поддержки принятия решений». Ключевое слово — интегрированное: данные из всех source-систем сводятся в одно согласованное место.
Центральная конструкция CIF — enterprise data warehouse (EDW): единое хранилище, в которое стекаются данные со всей компании. И спроектировано это ядро в нормализованной форме, обычно до 3NF — как полноценная реляционная база.
Почему нормализованное ядро? Логика Инмона: EDW — это «единый источник истины» (single source of truth) для всего предприятия. Источник истины обязан быть строго непротиворечивым. Нормализация (вспомните модуль про неё) как раз для этого и придумана: 3NF устраняет избыточность, а значит — и аномалии обновления, рассинхрон данных. Один факт хранится ровно в одном месте. Нормализованное ядро — это структура, в которой данные физически не могут противоречить сами себе.
Стоит вдуматься в эту связку, потому что она объясняет всю философию Inmon. Если в нормализованной схеме каждый факт хранится один раз, то противоречие в принципе негде возникнуть: нет двух копий значения, которые могли бы разойтись. А раз EDW должен быть тем местом, на которое опирается вся компания, эта структурная гарантия непротиворечивости становится не приятным бонусом, а обязательным требованием. Inmon сознательно выбирает строгость хранения над удобством запросов на уровне ядра — потому что ядро у него отвечает за истину, а не за скорость аналитики. Удобство запросов он отдаёт витринам, которые строятся отдельно.
При этом «интегрированное» в определении Инмона — это не просто «всё в одной базе». Интеграция означает приведение данных из разных источников к единым определениям, единым кодам, единым единицам измерения. Если в CRM пол клиента закодирован как M/F, в HR-системе как 1/0, а во внешнем источнике как «муж»/«жен», то при загрузке в EDW все три приводятся к одному стандарту. Именно эта работа по унификации — а не просто складывание данных рядом — и делает EDW единым источником истины. ETL-процесс в CIF несёт основную тяжесть интеграции: он не только переносит данные, но и согласовывает их семантику.
Top-down: сначала ядро, потом витрины
Подход Inmon называют top-down — «сверху вниз». Сначала строится общее (enterprise-ядро, охватывающее всю компанию), и лишь потом из него выводится частное (data marts под конкретные отделы).
Логика последовательности такая. Сначала аналитики и архитекторы строят корпоративную модель данных всего предприятия — описывают все бизнес-сущности и их связи целиком. Затем по этой модели создают нормализованный EDW и наполняют его через ETL из source-систем. И только когда ядро работает, поверх него строят data marts — витрины под нужды конкретных отделов (финансы, маркетинг, продажи).
Важная деталь: сами data marts в CIF обычно делают размерными (star schema) — нормализованное ядро для прямых аналитических запросов неудобно (десятки JOIN). То есть Inmon не отвергает размерное моделирование — он помещает его на «последнюю милю», в витрины. Различие с Kimball не «нормализация против звезды», а в том, ЧТО является источником истины и в каком ПОРЯДКЕ всё строится.
Поскольку все data marts выводятся из одного согласованного ядра, они автоматически непротиворечивы между собой. Витрина финансов и витрина продаж берут «выручку» из одного и того же места в EDW — числа сойдутся по построению.
Это свойство — автоматическая согласованность витрин — заслуживает особого внимания, потому что именно оно отличает Inmon от наивного подхода «каждый отдел строит свою витрину сам». Когда витрины выводятся из общего ядра, у них нет физической возможности разойтись: «клиент», «продукт», «выручка» в любой витрине — это проекция одних и тех же данных EDW. Знаменитая проблема корпоративной аналитики — «два отдела принесли на совещание разные цифры одной и той же метрики» — в архитектуре Inmon структурно исключена. Это и есть то, ради чего терпят долгий старт: ядро один раз делает данные согласованными, и дальше всякая витрина наследует эту согласованность бесплатно.
Запомните формулу Inmon: ОДНО нормализованное ядро (источник истины) -> МНОГО размерных витрин (для потребления). Ядро отвечает за интеграцию и согласованность, витрины — за удобство и скорость запросов. Это два разных слоя с разными задачами и разными моделями данных.
Цена и выгода подхода Inmon
У top-down есть характерный профиль сильных и слабых сторон.
Выгода — согласованность. Единое нормализованное ядро по построению непротиворечиво. Любые две витрины согласованы, потому что выведены из одного источника. Корпоративная модель данных охватывает всё предприятие сразу — нет «островов данных», которые потом не состыкуешь. Для крупной организации с строгими требованиями к достоверности отчётности это решающее преимущество.
Цена — время до первого результата. Прежде чем бизнес увидит хоть один работающий отчёт, нужно: построить корпоративную модель данных всего предприятия, спроектировать и наполнить нормализованный EDW, и только потом сделать первую витрину. Это долгий путь. В индустрии Inmon-проекты традиционно описывают как «дольше доходящие до результата» по сравнению с Kimball — на это уходят не недели, а заметно больше времени.
Цена — требования к команде. Спроектировать корпоративную модель данных и нормализованный EDW — задача для опытных архитекторов данных. Подход требовательнее к квалификации и к бюджету команды.
Конкретные цифры вроде “9-18 месяцев на Inmon-проект” — это индустриальная молва (industry folklore), а не измеренный факт. Реальный срок зависит от размера компании, числа источников, зрелости команды. Правильная формулировка — Inmon-подход “как правило, дольше доходит до первого результата”, чем Kimball; точные числа в месяцах называть не следует.
Где Inmon уместен
Top-down подход Inmon оправдан там, где согласованность важнее скорости запуска.
- Крупное предприятие со множеством разнородных source-систем. Когда данные разбросаны по десяткам систем и их обязательно нужно интегрировать в одно непротиворечивое целое, нормализованное enterprise-ядро решает эту задачу системно.
- Строгие требования к достоверности. Банки, страхование, регуляторная отчётность — там, где расхождение чисел между отчётами недопустимо, единый источник истины критичен.
- Долгосрочный горизонт. Если warehouse строят надолго и готовы инвестировать в фундамент сейчас ради устойчивости потом, длительный старт оправдан.
И наоборот: стартапу, которому отчёт нужен через месяц, top-down не подойдёт — слишком долгий разгон. Для таких случаев есть Kimball, к которому перейдём в следующем уроке.
Стоит честно сказать и о том, как воспринимают Inmon сегодня. Чистый top-down Inmon в его первоначальном виде применяют реже, чем тридцать лет назад: рынок ускорился, бизнес редко готов ждать, а инструменты вроде dbt сделали инкрементальное моделирование удобным. Но было бы ошибкой считать Inmon «устаревшим». Его центральная идея — интегрированный, нормализованный, согласованный слой как источник истины — жива и активно применяется, просто чаще как ОДИН ИЗ слоёв гибридной архитектуры, а не как вся методология целиком. Когда в современном lakehouse строят согласованный silver-слой, в нём работает именно философия Inmon. Поэтому понимать Inmon необходимо: даже если вы никогда не построите чистый CIF, вы почти наверняка будете работать со слоем, устроенным по его принципам.
Полезно зафиксировать ещё один аспект — роль ETL в подходе Inmon. Раз ядро нормализованное и интегрированное, основная интеллектуальная работа приходится на ETL-процессы между источниками и EDW: именно они согласуют семантику, приводят коды к единому виду, разрешают конфликты данных из разных систем. В CIF ETL — это не просто «перекачка», а место, где данные становятся истиной. Это отличается от чисто размерного подхода, где значительная часть логики уходит в проектирование самих витрин. Понимание, что у Inmon тяжесть смещена в сторону интеграционного ETL, помогает оценивать трудоёмкость и риски такого проекта.
| Аспект | Характеристика подхода Inmon |
|---|---|
| Направление | Top-down: сначала ядро, потом витрины |
| Ядро (источник истины) | Enterprise DWH, нормализованный (3NF) |
| Data marts | Размерные (star schema), выведены из ядра |
| Сильная сторона | Согласованность, интеграция, единый источник истины |
| Слабая сторона | Дольше до первого результата, выше требования к команде |
| Когда уместен | Крупное предприятие, строгая отчётность, долгий горизонт |
Попробуй сам
Представьте компанию с тремя source-системами: интернет-магазин (PostgreSQL), складская система (отдельная БД), CRM поддержки. Руководство хочет согласованную отчётность по всей компании.
- Опишите по шагам, как строился бы этот warehouse по Inmon: что делают сначала, что потом, что в самом конце.
- Что в этой схеме является «источником истины» и почему он нормализован?
- Витрина продаж и витрина поддержки обе используют сущность «клиент». Почему при подходе Inmon они автоматически согласованы?
- Назовите одну ситуацию, в которой долгий старт Inmon был бы неприемлем, и объясните почему.