Оглавление
Кто такой Кимбалл и каков его подход
Для начала познакомимся с автором методологии, о которой пойдёт речь.
Ральф Кимбалл — автор методологии размерного моделирования (dimensional modeling).
Его методология, ориентированная на удобство бизнес‑аналитики, стала одним из наиболее известных подходов к проектированию хранилищ данных.
Основной его труд – это книга «The Data Warehouse Toolkit». И вот эта же книга в переводе:
Здесь и далее, говоря «Кимбалл», буду иметь ввиду его подход, изложенный в этих книгах.
Факты и измерения
Таблицы в размерном моделировании глобально делятся на 2 типа: факты и измерения. Вот как можно кратко их охарактеризовать:
|
параметр |
факты |
измерения |
|
суть данных: |
бизнес-события |
описательный контекст |
|
формат: |
числа |
текст |
|
описание: |
глаголы действий |
«кто, что, где, когда, почему и как», окружающие событие |
|
в SQL-запросе: |
то, что агрегируем |
то, по чему фильтруем и группируем |
|
таблицы: |
узкие и длинные |
широкие и короткие |
|
null: |
оставляем |
заменяем описательной строкой (например, ‘undefined’) |
Что же такое такое согласованные факты и измерения? Давайте разберёмся по-порядку.
Согласованные факты
Согласованные факты — это когда одни и те же бизнес-события — в разных местах — имеют:
-
одинаковое наименование
-
одинаковое определение
Например, в магазине выручка не называлась бы:
-
revenue,
-
sales,
-
rev,
-
sales_amount,
-
rub_amount,
-
[…]
а везде называлась бы одним способом, например, revenue.
В онлайн-кинотеатре это могло бы быть одинаковое определение, например, времени смотрения. Вместо разных:
-
watched_time,
-
play_duration_sec,
-
wt,
-
[…]
для одинакового факта было бы одно название.
А если в двух витринах расчёт факта/определение факта отличается, то и названия должны быть разными. Например:
-
watched_time
-
watched_time_without_pause
Лирическое отступление
Прежде чем перейти к согласованным измерениям, позволю себе небольшое лирическое отступление. Один из важных принципов по Кимбаллу можно сформулировать так:
И особенно важны для хранилища — измерения:
Согласованные измерения
Итак, особенно важной частью своего подхода Кимбалл считает согласованные измерения.
Это когда один и тот же описательный контекст бизнес-событий — в разных местах — имеет:
-
одинаковое наименование
-
одинаковое определение
-
связан с разными таблицами фактов
Например, в магазине покупатель не назывался бы:
-
customer_id,
-
client_id,
-
user_id,
-
shop_client_id,
-
[…]
А везде назывался бы одним способом, например, customer_id; и это значение использовалось в разных таблицах фактов, например, в таблице заказов, в таблице с адресом доставки и т.д.
В онлайн-кинотеатре это могло бы быть одинаковое определение, например, того же пользователя/клиента и/или его профиля. Вместо разных:
-
user_id,
-
merged_user_id,
-
userid,
-
[…]
или
-
profile_id,
-
multiprofile_uid,
-
[…]
для одинакового определения пользователя/профиля было бы одно название. А если в двух витринах определение пользователя отличается, то и названия осознанно должны быть разными. Например:
-
user_id
-
merged_user_id
Как технически организовываются согласованные измерения – описано в главе 19, можно выделить в частности:
-
подсистема 8: согласующая система стр. 560-562
-
подсистема 14: конвейер суррогатных ключей стр. 576-578
-
подсистема 17: система управления измерениями стр.580-581
-
подсистема 18: система предоставления фактов стр.581-582
Но, поскольку у нас общий обзор, углубляться в детали технической реализации здесь мы не будем. Посмотрим лучше, для чего всё это нужно и какую ценность приносят согласованные факты и измерения.
SVOT, или single version of truth
Согласованные измерения помогают исследовать данные в хранилище:
-
и вглубь (drill-down),
-
и вдоль (drill across).
Например, имея согласованный идентифиактор клиента вы можете:
-
наряду с агрегированными данными (N покупок в месяц) посмотреть детализированные данные (по каждой из N покупок) — это пример исследования вглубь (drill-down)
-
наряду с данными о покупках посмотреть данные из других бизнес-областей (например, данные о выданных промокодах или данные о смене адреса) — это пример исследования вдоль (drill across)
Всё это позволяет иметь в хранилище единую версию правды — то есть согласованное, непротиворечивое и авторитетное представление данных. Ценность этого в том, что все пользователи — аналитики, менеджеры, отделы — опираются на одни и те же данные при принятии решений. Это устраняет ситуацию, когда в разных отделах какие-то данные/метрики считают по-разному, и руководство не знает, на которые из этих данных лучше опереться.
Итак, согласованные факты и измерения помогают иметь в хранилище единую версию правды (SVOT): они буквально и есть инструментарий Кимбалла (как указано в названии книг).
К сожалению, на практике хранилище данных может не иметь согласованных измерений или фактов. Сам Кимбалл считает это ошибкой №1 в списке возможных неудач при построении DWH.
Возможно, более повсеместное знакомство с принципами моделирования данных поможет дата-инженерам и аналитикам DWH говорить на одном языке и строить ту самую SVOT)
ссылка на оригинал статьи https://habr.com/ru/articles/1052842/