У попередній статті я розповів про основи DATA VAULT, описав основні елементи DATA VAULT та їх призначення. На цьому не можна вважати тему DATA VAULT вичерпаною, необхідно поговорити про такі щаблі еволюції DATA VAULT.
І в цій статті я сконцентруюсь на розвитку DATA VAULT та переході до BUSINESS DATA VAULT або просто BUSINESS VAULT.
Причини появи BUSINESS DATA VAULT
Слід зазначити, що DATA VAULT маючи певні сильні сторони не позбавлений недоліків. Одним із таких недоліків є складність у написанні аналітичних запитів. Запити мають значну кількість JOIN'ів, код виходить довгим та громіздким. Також дані, що потрапляють у DATA VAULT, не піддаються жодним перетворенням, тому з точки зору бізнесу DATA VAULT у чистому вигляді не має безумовної цінності.
Саме для усунення цих недоліків методологію DATA VAULT було розширено такими елементами як:
- PIT (point in time) таблиці;
- BRIDGE таблиці;
- PREDEFINED DERIVATIONS.
Давайте детальніше розберемо призначення цих елементів.
PIT таблиці
Як правило, один бізнес об'єкт (HUB) може мати у своєму складі дані з різною частотою оновлення, наприклад, якщо ми говоримо про дані, що характеризують людину, ми можемо сказати, що інформація про номер телефону, адресу або електронну пошту має вищу частоту оновлення, ніж скажімо, ПІБ, дані паспорта, сімейний стан або стать.
Тому, при визначенні сателітів, слід мати на увазі частоту їхнього оновлення. Чому це важливо?
Якщо в одній таблиці зберігати атрибути з різною частотою оновлення, доведеться додавати рядок до таблиці при кожному оновленні найчастіше змінного атрибута. Як наслідок – зростання обсягу дискового простору, збільшення часу виконання запитів.
Тепер, коли ми розділили сателіти за частотою оновлення, і можемо завантажувати дані незалежно, слід забезпечити можливість отримання актуальних даних. Найкраще, без використання зайвих JOIN'ів.
Поясню, наприклад, потрібно отримати актуальну (за датою останнього оновлення) інформацію із сателітів, що мають різну частоту оновлення. Для цього потрібно не тільки зробити JOIN, але й створити кілька вкладених запитів (до кожного сателіту, що містить інформацію) з вибором максимальної дати оновлення MAX (Дата оновлення). З кожним новим JOIN'ом такий код розростається і дуже швидко стає складним для розуміння.
PIT таблиця покликана спростити такі запити, PIT таблиці заповнюються одночасно із записом нових даних DATA VAULT. PIT таблиця:
Таким чином, у нас є інформація про актуальність даних по всіх сателітах на кожен момент часу. Використовуючи JOIN'и до PIT таблиці, ми можемо повністю виключити вкладені запити, природно за умови, що PIT заповнюється щодня і без перепусток. Навіть якщо перепустки в PIT мають місце, отримати актуальні дані можна лише використовуючи один вкладений запит до самого PIT'у. Один вкладений запит відпрацює швидше, ніж вкладені запити до кожного сателіту.
BRIDGE
Таблиці типу BRIDGE також використовують для спрощення аналітичних запитів. Однак відмінністю від PIT є засіб спрощення та прискорення запитів між різними хабами, лінками та їх сателітами.
Таблиця містить всі ключі для всіх сателітів, які часто використовуються в запитах. Крім того, за необхідності хешовані бізнес ключі можуть доповнюватися ключами у текстовому вигляді, якщо найменування ключів потрібні для аналізу.
Справа в тому, що без використання BRIDGE, в процесі отримання даних, що знаходяться в сателітах, що належать різним хабам, потрібно зробити JOIN не тільки самих сателітів, але і лінків, що зв'язують хаби.
Наявність чи відсутність BRIDGE визначається конфігурацією сховища, необхідністю оптимізації швидкості виконання запитів. Універсальний приклад BRIGE придумати складно.
PREDEFINED DERIVATIONS
Ще одним типом об'єктів, який наближає нас до BUSINESS DATA VAULT є таблиці, що містять попередньо розраховані показники. Такі таблиці справді важливі для бізнесу, вони містять інформацію, агреговану за заданими правилами і дозволяють отримати доступ до неї відносно просто.
Архітектурно PREDEFINED DERIVATIONS являють собою, ніщо інше, як ще один сателіт певного хаба. Він, як і звичайний сателіт, містить бізнес ключ і дату формування запису в сателіті. На цьому однак подібності закінчуються. Подальший склад атрибутів такого «спеціалізованого» сателіту визначається бізнес-користувачами на основі найбільш затребуваних, попередньо розрахованих показників.
Наприклад, хаб містить інформацію про співробітника, може включати сателіт з такими показниками, як:
- Мінімальна зарплатня;
- максимальна зарплата;
- Середня зарплата;
- Накопичувальний результат нарахованої зарплати тощо.
Логічно включати PREDEFINED DERIVATIONS до складу PIT таблиці цього хаба, тоді можна легко отримати зрізи даних по співробітника конкретно обрану дату.
ВИСНОВКИ
Як показує практика використання DATA VAULT бізнес користувачами дещо важко з кількох причин:
- Код запитів складний та громіздкий;
- Велика кількість JOIN'ів впливає на швидкодію запитів;
- Для написання аналітичних запитів потрібне визначне знання структури сховища.
Щоб спростити доступ до даних, DATA VAULT розширюється додатковими об'єктами:
- PIT (point in time) таблиці;
- BRIDGE таблиці;
- PREDEFINED DERIVATIONS.
У наступному я планую розповісти, на мій погляд, найцікавіше для тих, хто працює з BI. Я представлю способи створення таблиць – фактів та таблиць – вимірювань на базі DATA VAULT.
Матеріали статті засновані:
- На Кента Граціано, в якій, крім детального опису, містяться схеми моделі;
- Книзі: "Building a Scalable Data Warehouse with DATA VAULT 2.0";
- Стаття .
Джерело: habr.com