Як я почав звертати увагу на це питання
Чесно кажучи, ще кілька років тому я не приділяв багато уваги моделюванню даних. Тоді, працюючи дата-аналітиком, я насправді не вважав це частиною своєї роботи. Під крилом сильних дата-інженерів і менеджера з управління даними я був наче розбещена дитина. Уся моя аналітика починалася з data mart’ів, і я просто сприймав це як належне.
Але коли я отримав нову роль Analytics Engineer, усе змінилося. Тепер справа не лише в аналізі — побудова та підтримка самої аналітичної інфраструктури стали частиною моєї відповідальності. З березня я серйозно замислився над тим, як правильно проєктувати data lake і data warehouse, і навіть мав можливість створити книжковий клуб з моделювання Кімбала разом з іншими Analytics Engineers з різних компаній.
Завдяки як навчанню, так і практичній роботі, я зрозумів, що створення справді стабільного середовища вимагає неймовірної уваги до деталей і ретельного проєктування. Моделювання даних — це не «додаткова робота», а фундамент усього, що відбувається далі.
Проте, коли мене запитують: «Чому це настільки важливо?», я часто не міг чітко це пояснити або навести правильні приклади одразу. Саме тому я хочу використати цей пост, щоб зібрати свої думки про важливість правильного моделювання даних — те, що легко не помітити, коли зосереджуєшся лише на створенні дашбордів, проведенні аналізу або побудові прогнозних моделей.
Чому шарування важливе (Raw >> Transform >> Mart >> Semantic/BI) і чому підхід Кімбала використовується на рівні Mart?
З огляду на те, яку велику увагу сьогодні приділяють даним, мені пощастило, що на попередній роботі я завжди працював у середовищах, де вже існував data mart. Але не кожна компанія має сильну команду з даних або інфраструктуру для її підтримки. Наприклад, у моїй першій компанії не було ні окремої команди з даних, ні data mart.
У таких ситуаціях доводиться перетворювати вихідні дані безпосередньо в той вигляд, який потрібен для аналізу або дашбордів. На практиці це означає копіювання продакшн-бази даних або завантаження витягів, їх переформатування під свої потреби, а потім побудову потрібних графіків.
Коли визначення KPI відрізняються
Простий приклад — коли різні відділи по-різному визначають «дохід». Наприклад, фінансовий відділ може визначати дохід як Gross Sales, тоді як маркетинговий відділ — як Net Sales.
Без шару Mart і Semantic Layer обидві команди будуть брати дані з однієї широкої таблиці, але застосовувати власну логіку. У результаті з’являються два різні значення під однією і тією ж назвою KPI — «Revenue».
Тепер уявімо, що обидві команди погоджуються, що дохід має означати Net Sales, і в шарі Mart ви призначаєте стовпець net_sales_amount як revenue. З цього моменту кожен дашборд, який використовує «Revenue», буде стабільно посилатися на net_sales_amount без необхідності щоразу перевизначати його.
У цей момент хтось може сказати: «Ну добре, а хіба не можна просто чітко домовитися, що Revenue означає Net Sales?» Можна, але уявіть, що в компанію приходить новий аналітик. У своєму першому проєкті йому потрібно створити дашборд із показником доходу. Не маючи контексту попередніх домовленостей, він, швидше за все, візьме gross_sales_amount із вихідних даних. І ось плутанина починається знову.
Саме тут моделювання Кімбала додає цінність у межах шару Mart. Підхід Кімбала наголошує на створенні таблиці фактів продажів (Sales Fact Table) з чітким зерном (наприклад, один рядок = один рядок замовлення) та збереженні gross_sales_amount, discount_amount і net_sales_amount як окремих стовпців. Таким чином, незалежно від того, як «Revenue» буде визначено в майбутньому, таблиця фактів завжди міститиме всі необхідні складові для цього. У поєднанні з узгодженими вимірами (Product, Customer, Date) всі відділи інтерпретують KPI в одному контексті.
Коротко кажучи, шарування забезпечує узгодженість визначень KPI та їх повторне використання на семантичному рівні, тоді як моделювання Кімбала гарантує, що шар Mart має правильну структуру фактів і вимірів та достатню гнучкість для підтримки цих KPI. У результаті, якщо визначення доходу зміниться пізніше, достатньо просто змінити, який саме стовпець використовується — і жоден із дашбордів нижчого рівня не зламається.
Коли змінюються вихідні дані
Ось ще один приклад. Уявімо, що є три різні дашборди, які використовують стовпець customer_id, але звертаються безпосередньо до продакшн-бази даних (без використання шару Mart). Відповідно, кожен дашборд має власне визначення на семантичному рівні.
Тепер припустимо, що команда, яка працює з продакшн-БД, перейменовує стовпець з customer_id на cust_id. Раптово всі три дашборди ламаються. Щоб це виправити, потрібно відкрити модель даних кожного дашборда і вручну замінити customer_id на cust_id.
Але якщо між ними є шар Mart, і всі дашборди беруть дані з централізованої таблиці fact_orders, яка містить стовпець customer_id, ситуація змінюється. У моделі, яка створює fact_orders, потрібно зробити це відображення лише один раз:
SELECT
cust_id AS customer_id, - map only once here
order_id,
order_date,
…
FROM raw.orders;З цією однією зміною всі три дашборди продовжать працювати без додаткових правок.
І саме тут моделювання Кімбала йде ще далі. Замість прямого використання природних ключів із джерельної системи (cust_id, customer_id), Кімбал рекомендує пов’язувати таблиці фактів і вимірів за допомогою сурогатних ключів.
Сурогатний ключ — це штучний ключ, який генерується всередині сховища даних, а не переноситься з джерельної системи. Зазвичай це просте ціле число (наприклад, customer_key = 101), яке використовується як стабільний зв’язок між таблицями фактів і вимірів. Перевага в тому, що навіть якщо джерельна система змінює назви ключів — або, що гірше, повторно використовує той самий ключ для іншої сутності — сурогатний ключ залишається незмінним. Це означає, що історичні дані зберігаються, а зв’язки між фактами і вимірами ніколи не ламаються.
Коротко кажучи, шарування гарантує, що зміни можна обробити в одному місці, тоді як моделювання Кімбала структурно мінімізує вплив цих змін у межах шару Mart.
Коли продуктивність стає проблемою
Припустимо, що вихідна таблиця orders містить мільярди рядків. Тепер ви хочете побудувати геопросторову візуалізацію «місячні продажі за штатами за останні 3 роки».
Якщо підключити BI-інструмент безпосередньо до сирих даних, йому доведеться сканувати мільярди рядків і виконувати GROUP BY за місяцем і штатом. Запит зрештою може повернути результат, але це буде повільно. З ростом компанії і збільшенням кількості рядків ви навіть можете почати отримувати помилки тайм-ауту. З точки зору користувача дашборду це означає поганий досвід — і з часом люди просто перестануть користуватись цим інструментом.
З шаром Mart ви можете підтримувати як таблицю fact_orders (на детальному рівні рядків замовлення), так і таблицю fact_sales_monthly (попередньо агреговану на рівні місяця/штату). Для запиту «місячні продажі за штатами» дашборд може звертатися до fact_sales_monthly. Тепер замість мільярдів рядків обробляється лише кілька тисяч, і ви отримуєте той самий результат — швидко та стабільно.
Саме тут моделювання Кімбала дає чіткі рекомендації. Кімбал визначає кілька типів таблиць фактів саме для таких випадків:
- Транзакційні таблиці фактів фіксують кожну детальну подію (наприклад, кожен рядок замовлення).
- Періодичні snapshot-таблиці фактів підсумовують показники за регулярні інтервали (наприклад, місячні продажі).
- Накопичувальні snapshot-таблиці фактів відстежують процеси з часом (наприклад, виконання замовлення).
Свідомо моделюючи як атомарні транзакційні факти, так і періодичні знімки, ви не лише покращуєте продуктивність — ви створюєте схему, яка гнучко підтримує різні типи аналізу на відповідному рівні деталізації, не перевантажуючи користувачів або BI-інструменти.
Відсутність розширюваності
Підхід «одна велика таблиця» часто погано адаптується до нових бізнес-змін. Уявімо, наприклад, що компанія купує новий бренд. Раптово, окрім існуючих клієнтів, продуктів і транзакцій, потрібно інтегрувати дані іншої компанії: її клієнтів, продукти та транзакції. Без шару Mart майже неможливо акуратно додати ці нові сутності.
Проблеми швидко накопичуються. По-перше, виникає невідповідність стовпців: дані замовлень придбаної компанії можуть містити поля, яких у нас раніше не було (наприклад, fulfillment_center або payment_channel). Щоб втиснути їх у широку таблицю, доведеться додати десятки nullable-стовпців або змінити існуючі структури. По-друге, проблема конфлікту ключів: придбана компанія також використовує customer_id і product_id, але з іншою системою ідентифікації, яка може перетинатися або суперечити нашій. Без сурогатних ключів майже неможливо їх розрізнити. По-третє, відсутність керування історією: якщо придбана компанія використовує той самий SKU для іншого продукту, одна плоска таблиця змішає минулі й поточні продажі некоректно. І нарешті, вплив на дашборди: існуючі дашборди не мають фільтрів типу «Включити/Виключити придбану компанію», тому щойно нові дані з’являться, метрики різко зміняться або зламаються.
З шаром Mart і моделюванням Кімбала ці проблеми стають керованими. Ви можете або створити нову таблицю фактів для придбаної компанії, або інтегрувати її дані в існуючу таблицю, зберігаючи узгодженість через conformed dimensions. Виміри Customer, Product і Order можна розширити за допомогою сурогатних ключів, щоб додати нові дані без порушення історії. А на семантичному рівні можна визначити метрики, такі як «Revenue (тільки основна компанія)» і «Revenue (усі компанії)» — так існуючі дашборди продовжать працювати без змін, а нові аналізи легко врахують придбання.
Що далі та підсумкова думка
Після того як ви опануєте основи шарування та моделювання Кімбала — чітке визначення зерна, використання сурогатних ключів, проєктування узгоджених вимірів, застосування шаблонів таблиць фактів і роботу з SCD — наступний крок полягає в тому, щоб вийти за межі просто «правильної» моделі. Мета — побудувати сховище даних, яке є надійним, масштабованим і зручним у використанні.
Саме тут з’являються операційні найкращі практики:
- Угоди щодо найменування ▶️ Послідовні префікси, такі як
dimCustomer,factOrders,rpt_…, і зрозумілі для бізнесу назви стовпців, як-отorder_date_key(замість незрозумілих кодів типуodt_dt), зменшують плутанину. - Перевірки якості даних ▶️ Автоматизовані тести допомагають виявляти проблеми на ранніх етапах: відсутність «сирітських» зовнішніх ключів, відсутність дублікатів сурогатних ключів, відсутність від’ємних продажів. Інструменти, такі як dbt tests або Great Expectations, підтримують надійність моделей.
- Каталог даних і документація ▶️ Кожна таблиця фактів і вимірів повинна мати чіткі метадані: зерно, ключі та визначення метрик. Аналітики не повинні здогадуватись, чи включає «Net Revenue» знижки чи ні.
- Обмеження та управління (governance) ▶️ Відстеження походження даних (lineage) через шари Raw → Transform → Mart → Semantic. Документування обробки SCD, щоб користувачі розуміли, чи бачать вони поточний стан, чи історичну правду.
- Галузеві патерни Кімбала ▶️ Різні галузі акцентують увагу на різних бізнес-процесах: Retail (продажі, промоакції, запаси), Procurement (закупівлі, надходження, платежі), Order Management (замовлення, рахунки, відвантаження), Finance (головна книга, бюджети, прогнози). Дослідження цих доменів показує, як однакові принципи Кімбала адаптуються до різних ланцюгів створення цінності.
Разом ці практики перетворюють сховище даних із суто технічного артефакту на спільний актив компанії — зручний для пошуку, узгоджений і стійкий.
І тепер, із розвитком AI та LLM, спосіб, у який ми проєктуємо та використовуємо дані, може змінюватися:
- Запити природною мовою — AI може допомогти нетехнічним користувачам генерувати SQL або ставити бізнес-запитання напряму. Але якщо базова схема неорганізована або KPI неузгоджені, AI лише посилить проблеми поганого моделювання.
- Автоматизовані трансформації та пайплайни — AI все більше буде автоматично генерувати код, але йому все одно потрібна добре структурована цільова модель. Без чітко визначеного зерна, сурогатних ключів і узгоджених вимірів AI не зможе правильно узгоджувати дані між різними доменами.
У підсумку, одна велика таблиця може дати вам результат, який потрібен прямо зараз. Але шарова архітектура, побудована на моделюванні Кімбала та підкріплена цими найкращими практиками, дає значно більше: фундамент даних, який росте разом із бізнесом, адаптується до нових інструментів (включаючи AI) і зберігає довіру до даних.
ОРИГІНАЛ СТАТТІ:Data Modeling Done Right: Why Layering + Kimball Are the Foundation of Trust
АВТОР СТАТІ:Taeeun Kwon (Harrison Kwon)
🚀Долучайтесь до нашої спільноти Telegram:
🚀Долучайтесь до нашої спільноти FaceBook:
🚀Долучайтесь до нашої спільноти Twiter X:
