Kimball: data marts из conformed dimensions

В прошлом уроке — Inmon: единое нормализованное ядро, из которого выводятся витрины. Теперь второй классический подход, во многом противоположный по направлению движения. Ральф Кимбалл (Ralph Kimball) сформулировал его в книге «The Data Warehouse Toolkit» (1996). Это bottom-up методология — «снизу вверх».

Если Inmon строит сначала общее (ядро), то Kimball строит сначала частное (отдельные витрины под конкретные процессы) и интегрирует их в целое позже — через механизм, который вы уже изучили в модуле про dimension-таблицы: conformed dimensions. Это противоположное Inmon направление движения, и именно оно определяет все остальные различия двух подходов — скорость, требования к команде, способ обеспечения согласованности.

Идея: начни с витрины, не с ядра

У Inmon перед первым отчётом надо построить корпоративное ядро. Kimball предлагает обратное: не ждать ядра, а сразу взять один конкретный бизнес-процесс и построить под него размерную витрину (star schema).

Выбрали процесс «продажи» — спроектировали fct_sales, окружили его dimensions, наполнили из source-систем. Витрина готова и уже отвечает на вопросы бизнеса. Отдельного нормализованного enterprise-ядра при этом нет вообще — размерные витрины и есть warehouse.

Каждая витрина строится по знакомому вам четырёхшаговому процессу Kimball: выбрать бизнес-процесс, объявить grain, выбрать dimensions, выбрать facts. Результат — star schema, сразу оптимизированная под аналитические запросы: dimension соединяется с fact одним JOIN, никаких десятков соединений нормализованной схемы.

Стоит увидеть, в чём именно философское расхождение с Inmon. Inmon считает, что сначала надо построить «правильную» полную картину всего предприятия, а потом из неё нарезать удобные куски. Kimball исходит из того, что полную картину предприятия заранее построить трудно и долго, а ценность бизнесу нужна быстро — поэтому надо начинать с конкретного, ясно очерченного процесса, который понятен и нужен прямо сейчас. Это прагматичный, итеративный взгляд: не «спроектируем идеальный фундамент», а «решим конкретную задачу, потом следующую, и пусть хранилище вырастет из реальных потребностей». Размерная модель (star schema) для этого подходит идеально — она строится вокруг одного бизнес-процесса и сразу даёт удобный для запросов результат.

Bottom-up: но как же интеграция?

Здесь возникает законный вопрос. Если строить витрины по отдельности, не получится ли тот самый хаос, которого Inmon избегает своим ядром? Витрина продаж со своим справочником клиентов, витрина поддержки — со своим, и числа не сходятся?

Ответ Kimball — conformed dimensions и bus architecture. Вы уже изучали это в модуле 13, теперь видно, какую роль оно играет в методологии целиком.

Идея: витрины строятся по отдельности, но не на произвольных, а на общих, согласованных dimensions. dim_customer, dim_date, dim_product — conformed: одни и те же таблицы с одними и теми же ключами, переиспользуемые всеми витринами. Когда витрина продаж и витрина поддержки обе ссылаются на одну dim_customer, они автоматически интегрированы — drill-across между ними работает.

Инструмент планирования — bus matrix (тоже из модуля 13): строки — бизнес-процессы, столбцы — conformed dimensions. Команда рисует bus matrix в начале, договариваясь о наборе общих dimensions. Дальше витрины можно делать по одной, в любом порядке — они состыкуются, потому что ключи conformed dimensions совпадают.

Так bottom-up даёт интегрированный warehouse: целое собирается из частей не через единое ядро, а через общую шину согласованных dimensions. Набор всех витрин, подключённых к общей шине, и есть enterprise data warehouse в терминологии Kimball.

Цена и выгода подхода Kimball

Профиль сильных и слабых сторон у Kimball зеркальный по отношению к Inmon.

Выгода — быстрый результат. Не нужно строить корпоративное ядро перед первым отчётом. Выбрали процесс, построили витрину — бизнес уже получает ценность. В индустрии Kimball-проекты традиционно описывают как «быстрее доходящие до результата», чем Inmon: первая витрина появляется заметно раньше.

Выгода — incremental-доставка. Warehouse растёт витрина за витриной. Каждая новая витрина — это законченный, полезный результат, а не «ещё один кусок недостроенного фундамента». Можно остановиться, показать ценность, продолжить.

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

Цена — дисциплина conformed dimensions. Вся интеграция держится на том, что dimensions действительно conformed. Если команда схалтурит и витрины начнут заводить свои справочники, warehouse рассыпется на несвязанные острова. Inmon-ядро навязывает согласованность структурой; Kimball требует её соблюдать дисциплиной.

Эту цену важно не недооценивать. У Inmon ошибиться с согласованностью трудно: ядро одно, и витрины физически не могут разойтись. У Kimball согласованность — это договорённость, которую люди должны соблюдать на каждом шаге: использовать общую dim_customer, а не делать свою; согласовывать изменения conformed dimensions с другими командами; поддерживать bus matrix в актуальном состоянии. Стоит одной команде под давлением сроков завести «временный» собственный справочник клиентов — и drill-across с её витриной ломается. Поэтому Kimball-проект требует не только технической, но и организационной дисциплины: code review, владельцы conformed dimensions, общие соглашения. Там, где этой дисциплины нет, bottom-up действительно вырождается в хаос несвязанных витрин — ровно то, чем критики пугают Kimball.

Где Kimball уместен

Bottom-up подход Kimball оправдан там, где важны скорость запуска и постепенная отдача.

• Нужен быстрый результат. Когда бизнесу важно увидеть работающую аналитику скоро, а не через длительный enterprise-проект.
• Постепенный рост. Когда warehouse удобнее наращивать витрина за витриной, показывая ценность на каждом шаге.
• Команда без тяжёлого enterprise-опыта. Star schema доступнее в проектировании, чем корпоративная нормализованная модель.
• Аналитический фокус. Размерная модель изначально заточена под BI-запросы — это её родная задача.

Kimball — самый распространённый подход к аналитическому моделированию и сегодня; современные инструменты вроде dbt прямо рекомендуют строить Kimball-витрины.

Стоит понять, почему именно Kimball оказался так живуч в эпоху облачных warehouse и dbt. Размерная модель идеально ложится на инструментарий ELT: каждая витрина — это набор SQL-трансформаций, dimensions и facts материализуются как таблицы, conformed dimensions переиспользуются через ref(). Инкрементальная природа Kimball — «витрина за витриной» — точно совпадает с тем, как команды работают в dbt: модель за моделью, pull request за pull request. Там, где громоздкое корпоративное ядро Inmon плохо сочетается с быстрым итеративным циклом, Kimball-витрина — естественная единица работы. Поэтому современный консенсус: размерное моделирование остаётся стандартом аналитического слоя, и dbt прямо ведёт пользователя к Kimball-структурам (dim_*, fct_*, staging-intermediate-marts).

При этом важно не впасть в другую крайность. То, что Kimball удобен и распространён, не делает его универсальным ответом. Для строго auditable хранения сырья из множества источников лучше подходят другие структуры (Data Vault), а размерная витрина в современной архитектуре всё чаще не источник истины, а gold/consumption-слой поверх него. Kimball — отличный инструмент для своей задачи (аналитический слой для BI), и грамотный инженер применяет его именно как инструмент, а не как догму. В следующем уроке сравним Inmon и Kimball напрямую — по времени, согласованности и требованиям к команде.

Попробуй сам

Та же компания, что в прошлом уроке: интернет-магазин, склад, CRM поддержки.

1. Опишите по шагам, как строился бы warehouse по Kimball: с чего начать, что делать дальше.
2. Что в подходе Kimball играет роль «источника истины» вместо нормализованного ядра Inmon?
3. Витрина продаж и витрина поддержки обе используют «клиента». За счёт какого механизма они оказываются согласованы — и что будет, если этим механизмом пренебречь?
4. Сравните: у Inmon согласованность обеспечивается структурой (единое ядро), у Kimball — чем? В чём риск второго варианта?