Від необроблених таблиць до дашбордів: Як семантичні шари BI забезпечують узгодженість показників

Проблема з трьома числами доходів

Будь-яка організація, яка досягає певної величини, рано чи пізно стикається із знайомою та сором’язливою невдачею: дашборд фінансів показує дохід у розмірі 2,1 мільйона фунтів стерлінгів минулого кварталу, дашборд продажів – 2,3 мільйона фунтів стерлінгів, а звіт маркетингової служби – 1,9 мільйона фунтів стерлінгів, і всі три команди одночасно праві, оскільки кожна з них створила власне запит SQL із власним приватним визначенням «доходу» — один включає податки, інший виключає повернення коштів, оброблені після закінчення кварталу, третій вважає угоду доходом у дату підписання замість дати виставлення рахунку. Ніхто не брехав; три незалежно підтримувані запити просто кодували три дещо різні бізнес-правила, і нічого не змушувало їх узгоджуватися.

Це фундаментально не проблема якості даних — базові рядки в сховищі можуть бути абсолютно точними — це проблема узгодженості визначень, і її неможливо вирішити шляхом ще більш ретельного очищення даних. Для цього необхідно точно визначити розрахунок показника лише один раз, у визначеному місці, щоб усі дашборди та всі аналітики могли отримувати дані звідти, а не дозволяти кожному автору звіту незалежно перевизначати його в своєму власному запиті SQL. Це єдине визначене місце і є призначенням семантичного шару.

Що таке семантичний шар

Семантичний шар розташований між необробленими таблицями сховища даних та інструментами, які люди використовують для аналізу чисел — дашбордами, електронними таблицями, інструментами для створення нестандартних запитів — і містить декларативні визначення показників та вимірів, за якими їх можна розрізати, а не прямий SQL-код, написаний окремо для кожного звіту. Визначення показника визначає базовий вимір (наприклад, `sum(order_amount)`), з якої таблиці або моделі він береться, та будь-які фільтри або бізнес-логіку, що застосовуються (виключаючи повернення платежів, виключаючи внутрішні тестові облікові записи), які записуються в одному місці — часто у вигляді конфігурації в інструменті, такому як dbt's metrics layer, LookML у Looker або окремий продукт для створення семантичного шару, наприклад Cube.

Критично важливо, що семантичний шар також визначає, за якими вимірами може бути легітимно розрізаний показник, та як ці виміри пов’язані з базовою таблицею фактів, щоб коли аналітик у дашборді продажів запитує «дохід за регіоном», а аналітик у фінансовому дашборді запитує «дохід за категоріями продуктів», обидва запити компілювалися з одного й того ж визначення показника та з однієї й тієї ж логіки зв’язку з базовою таблицею, що гарантує узгодженість підсумків, незважаючи на те, що обидва перегляди ріжуть дані зовсім різними способами. Це семантичний шар забезпечує для показників те саме, що й зірка схеми — фактів таблиця — надає єдине авторитетне джерело, з якого можна будувати різні перегляди без повторного визначення базового арифметичного кожного разу.

Показники як згенеровані запити, а не кешовані числа

Часто виникає помилкове уявлення, що семантичний шар є по суті кешем — місцем, де числа попередньо обчислюються та зберігаються для швидкого отримання. У більшості сучасних реалізацій це набагато ближче до протилежного: семантичний шар визначає показник як шаблон запиту, і коли дашборд або аналітик запитує «дохід за регіонами за минулий місяць», семантичний шар перетворює цей запит на фактичний SQL-запит проти сховища в момент запиту, враховуючи будь-які фільтри та групування, необхідні для конкретного запиту, і сховище виконує його свіжо (часто проти результатів кешуються для продуктивності, але джерело правди — це згенерований запит, а не застаріле кешоване число, яке хтось забув оновити).

Цей підхід до генерації запитів в момент запиту дозволяє одному й тому ж визначенню показника відповідати як «загальний дохід цього року», так і «дохід за регіонами по місяцях» правильно, без необхідності для автора показника передбачати всі можливі комбінації нарізів завчасно — семантичний шар генерує відповідні `GROUP BY` та з’єднання на основі будь-яких вимірів, які запит просить, обмежені правилами, які визначають, які виміри допустимо використовувати для нарізування показника в першу чергу, запобігаючи безглуздим комбінаціям, таким як підсумовування частково-додатного показника балансу по часових періодах.

Розгортання та компроміс щодо управління

Добре побудований семантичний шар робить інтерактивне розгортання (drill-down) в дашборді плавним: клацнути на графі «дохід за регіонами», щоб розгорнутися до «доходу за регіонами по продуктам» для цього конкретного регіону – це не розроблена вручну функція лише для цього одного дашборду, а BI-інструмент запитує семантичний шар щодо тієї ж основної метрики з більш дрібним розділом тих самих визначених розмірностей, що послідовно працює у всіх дашбоардах, побудованих на цьому семантичному шарі, без необхідності написання окремого коду розгортання вручну для кожного.

Компроміс, який створює централізація, – це тертя щодо управління: метрику більше не можна переозначити імпульсивно тим, хто будує конкретний дашборд під тиском дедлайну, оскільки зміна того, що означає «дохід», потребує звернення до тих, хто володіє визначеннями семантичного шару, зазвичай до команди інженерів-аналітиків, і ця зміна впливає на всі дашборди, які споживають цю метрику. Це тертя є реальною втратою швидкості для одноразових аналізів, але це саме той витрачений виграш, який дозволяє організації уникнути проблеми з трьома різними числами – невеликий податок на кожну окрему зміну, сплачений для гарантування того, що цифри, які представляють різні команди керівництву під час зустрічі, дійсно узгоджуються між собою.

Часті запитання

Спробуйте наживо

Усе, що вище, працює прямо у вашому браузері — відкрийте the simulation і змінюйте параметри під час роботи. Нічого не встановлюється, нічого не завантажується на сервер, уся модель живе в одній вкладці.