Розробка сховища – справа довга та серйозна.
Багато чого в житті проекту залежить від того, наскільки добре продумана об'єктна модель та структура бази на старті.
Загальноприйнятим підходом були і залишаються різні варіанти поєднання схеми "зірка" із третьою нормальною формою. Як правило, за принципом: вихідні дані – 3NF, вітрини – зірка. Цей підхід, перевірений часом і підкріплений великою кількістю досліджень - перше (а іноді й єдине), що спадає на думку досвідченому DWH-шнику при думці про те, як має виглядати аналітичне сховище.
З іншого боку — бізнесу в цілому та вимогам замовника зокрема властиво швидко змінюватися, а цим — зростати як углиб, так і вшир. І ось тут проявляється основний недолік зірки - обмежена гнучкість.
І якщо у вашому тихому та затишному житті DWH-розробника раптово:
- постало завдання "зробити швидко хоч щось, а потім подивимося";
- з'явився бурхливо розвивається, з підключенням нових джерел та переробкою бізнес-моделі мінімум раз на тиждень;
- з'явився замовник, який не представляє як система має виглядати і які функції виконувати зрештою, але готовий до експериментів та послідовного уточнення бажаного результату з послідовним наближенням до нього;
- заглянув менеджер проектів із радісною звісткою: "А тепер у нас аджайл!".
Або якщо вам просто цікаво дізнатися, як ще можна будувати сховища — велкам під кат!
Що означає «гнучкість»
Для початку давайте визначимося, якими властивостями повинна володіти система, щоб її можна було назвати гнучкою.
Окремо варто зазначити, що ці властивості повинні ставитися саме до системі, А не до процесу її розробки. Тому якщо ви хотіли почитати про Agile як методологію розробки, краще ознайомитись з іншими статтями. Наприклад, тут же, на Хабре, є безліч цікавих матеріалів (як и , Так і ).
Це не означає, що процес розробки та структура ХД зовсім не пов'язані. Загалом розробляти по Agile сховище гнучкої архітектури має бути значно легшим. Однак на практиці частіше зустрічаються варіанти і з розробкою за Agile класичного DWH за Кімбалом і DataVault — по вотерфолу, ніж щасливі збіги гнучкості у двох її іпостасях на одному проекті.
Отже, які ж можливості має мати гнучке сховище? Тут можна виділити три пункти:
- Рання поставка та швидке доопрацювання — це означає, що в ідеалі перший бізнес-результат (наприклад, перші звіти, що працюють) повинен бути отриманий якомога раніше, тобто ще до того, як повністю спроектована і впроваджена система цілком. При цьому кожна наступна доопрацювання теж повинна займати якнайменше часу.
- Ітеративне доопрацювання — це означає, що кожна наступна доробка в ідеалі не повинна торкатися функціоналу, що вже працює. Саме цей момент часто стає найбільшим кошмаром на великих проектах — рано чи пізно окремі об'єкти починають обростати такою кількістю зв'язків, що простіше повністю повторити логіку в копії поруч, ніж додати поле в існуючу таблицю. І якщо вас дивує, що аналіз впливу доопрацювання на існуючі об'єкти може займати більше часу, ніж сама доробка — ви, швидше за все, ще не працювали з великими ХД у банкінгу чи телекомі.
- Постійна адаптація до мінливих вимог бізнесу — загальна об'єктна структура має бути спроектована не просто з урахуванням можливого розширення, а з розрахунком на те, що напрям цього чергового розширення не міг би вам навіть наснитися на етапі проектування.
І так, відповідність усім цим вимогам в одній системі можлива (зрозуміло, у певних випадках і з деякими застереженнями).
Нижче я розгляну дві найпопулярніші для ХД методології гнучкого проектування. Anchor model и Сховище даних. За дужками залишаються такі чудові прийоми, як наприклад EAV, 6NF (у чистому вигляді) і все, що стосується NoSQL рішень — не тому, що вони чимось гірші, і навіть не тому, що в цьому випадку стаття загрожувала б придбати обсяг середньостатистичного Дисера. Просто все це стосується рішень трохи іншого класу — або до прийомів, які ви можете застосовувати в специфічних випадках, незалежно від загальної архітектури вашого проекту (як EAV), або до глобально інших парадигм зберігання інформації (як, наприклад, графові БД та інші варіанти) NoSQL).
Проблеми “класичного” підходу та їх вирішення у гнучких методологіях
Під "класичним" підходом маю на увазі стару добру зірку (незалежно від конкретної реалізації нижчих шарів, хай вибачать мене представники Кімбола, Інмона і CDM).
1. Жорстка кардинальність зв'язків
В основу такої моделі закладається чіткий поділ даних на вимірювання (Dimension) и факти (Fact). І це, чорт забирай, логічно — адже аналіз даних у переважній більшості випадків зводиться саме до аналізу певних чисельних показників (фактів) у певних розрізах (вимірюваннях).
При цьому зв'язки між об'єктами закладаються у вигляді зв'язків між таблицями із зовнішнього ключа. Це виглядає цілком природно, але відразу призводить до першого обмеження гнучкості. жорсткому визначенню кардинальності зв'язків.
Це означає, що на етапі проектування таблиць ви повинні точно визначити для кожної пари пов'язаних об'єктів, чи можуть вони ставитися як багато-багатьом, чи тільки 1-ко-многим, і “у який бік”. Від цього безпосередньо залежить, в якій із таблиць буде первинний ключ, а в якій — зовнішній. Зміна цього відношення при отриманні нових вимог з великою ймовірністю призведе до переробки бази.
Наприклад, проектуючи об'єкт “касовий чек” ви, спираючись на закляття запевнення відділу продажу, заклали можливість дії однієї промо-акції на кілька чекових позицій (але не навпаки):
А через деякий час, колеги запровадили нову маркетингову стратегію, в якій на ту саму позицію можуть діяти кілька промо-акцій одночасно. І тепер вам треба доопрацювати таблиці, виділивши зв'язок окремого об'єкта.
(Всі похідні об'єкти, в яких відбувається джойн чека на промо, тепер теж потребують доопрацювання).
Зв'язки в Data Vault та Anchor Model
Уникнути такої ситуації виявилося досить просто: не треба вірити відділу продажу для цього достатньо всі зв'язки спочатку зберігати в окремих таблицях і обробляти як багато-багатьом.
Такий підхід був запропонований Деном Лінстедтом (Dan Linstedt) як частина парадигми Сховище даних та повністю підтриманий Ларсом Реннбеком (Lars Rönnbäck) в Якірної моделі (Anchor Model).
У результаті отримуємо першу особливість гнучких методологій:
Зв'язки між об'єктами не зберігаються в атрибутах батьківських сутностей, а є окремим типом об'єктів.
В Сховище даних такі таблиці-зв'язки називаються посилання, А в Якірної моделі - Tie. На перший погляд вони дуже схожі, хоча назвою їхньої відмінності не вичерпуються (про що піде мова нижче). В обох архітектурах таблиці-зв'язки можуть пов'язувати будь-яку кількість сутностей (Не обов'язково 2).
Ця на перший погляд надмірність дає істотну гнучкість при доробках. Така структура стає толерантною не тільки до зміни кардинальностей існуючих зв'язків, а й до додавання нових — якщо тепер у чекової позиції з'явиться ще й посилання на касира, що пробив, поява такої зв'язки стане просто надбудовою над існуючими таблицями без впливу на будь-які існуючі об'єкти і процеси.
2. Дублювання даних
Друга проблема, розв'язувана гнучкими архітектурами, менш очевидна і властива насамперед вимірюванням типу SCD2 (повільно змінюються виміри другого типу), хоч і лише їм.
У класичному сховищі вимір зазвичай є таблицею, яка містить сурогатний ключ (як PK) а також набір бізнес-ключів і атрибутів в окремих колонках.
Якщо вимір підтримує версію, до стандартного набору полів додаються межі часу дії версії, а на один рядок у джерелі з'являється кілька версій у сховищі (по одній на кожну зміну версійних атрибутів).
Якщо вимір містить хоча б один версійний атрибут, що часто змінюється, кількість версій такого вимірювання буде значним (навіть якщо інші атрибути не версійні, або ніколи не змінюються), а якщо таких атрибутів кілька — кількість версій може зростати в геометричній прогресії від їх кількості. Такий вимір може займати істотний обсяг дискового простору, хоча більшість даних, що зберігаються в ньому, — просто дублі значень постійних атрибутів з інших рядків.
При цьому дуже часто застосовується ще й денормалізація - Частина атрибутів навмисно зберігаються у вигляді значення, а не посилання на довідник або інший вимір. Такий підхід прискорює доступ до даних, знижуючи кількість джойнів при зверненні до виміру.
Як правило, це призводить до того, що та сама інформація зберігається одночасно в кількох місцях. Наприклад, інформація про регіон проживання та приналежності категорії клієнта може одночасно зберігатися у вимірах “Клієнт”, фактах “Купівля”, “Доставка” та “Звернення до кол-центру”, а також у таблиці-зв'язці “Клієнт – Клієнтський менеджер”.
В цілому описане вище відносяться і до звичайних (не версійних) вимірів, але у версійних можуть мати інший масштаб: поява нової версії об'єкта (особливо заднім числом), призводить не просто до оновлення всіх зв'язаних таблиць, а до появи нових версій пов'язаних об'єктів — коли Таблиця 1 використовується при побудові Таблиці 2, а Таблиця 2 при побудові Таблиці 3 і т.д. Навіть якщо жоден атрибут Таблиці 1 не бере участі у побудові Таблиці 3 (а беруть участь інші атрибути Таблиці 2, отримані з інших джерел), версійне оновлення цієї конструкції як мінімум призведе до додаткових накладних витрат, а як максимум – до зайвих версій у Таблиці 3, яка тут взагалі "ні до чого" і далі по ланцюжку.
3. Нелінійна складність доопрацювання
При цьому кожна нова вітрина, що будується на основі іншої, збільшує кількість місць, у яких дані можуть "розійтися" при внесенні змін до ETL. Це, своєю чергою, призводить до зростання складності (і тривалості) кожної наступної доопрацювання.
Якщо вищеописане стосується систем з ETL-процесами, що рідко допрацьовуються, жити в такій парадигмі можна — досить просто стежити за тим, щоб нові доробки коректно вносилися у всі пов'язані об'єкти. Якщо ж доопрацювання відбуваються часто, ймовірність випадково "упустити" кілька зв'язків суттєво зростає.
Якщо також врахувати, що "версійний" ETL значно складніше, ніж "не версійний", уникнути помилок при частому доопрацюванні всього цього господарства стає досить складно.
Зберігання об'єктів та атрибутів у Data Vault та Anchor Model
Підхід, запропонований авторами гнучких архітектур, можна сформулювати так:
Потрібно відокремити те, що змінюється, від того, що залишається постійним. Тобто зберігати ключі окремо від атрибутів.
При цьому не варто плутати не версійний атрибут з незмінним: перший не зберігає історію своєї зміни, але може змінюватись (наприклад, при виправленні помилки введення або отримання нових даних) другий — не змінюється ніколи.
Погляди на те, що саме можна вважати незмінним у Data Vault та Якірній моделі розходяться.
З погляду архітектури Сховище данихнезмінним можна вважати весь набір ключів - натуральні (ІПН організації, код товару в системі-джерелі тощо) та сурогатні. При цьому інші атрибути можна розділити за групами за джерелом та/або частотою змін для кожної групи вести окрему таблицю із незалежним набором версій.
У парадигмі ж Anchor Model незмінним вважається тільки сурогатний ключ сутності. Все інше (включаючи натуральні ключі) просто окремий випадок його атрибутів. При цьому всі стандартні атрибути незалежні один від одного, тому для кожного атрибута має бути створена окрема таблиця.
В Сховище даних таблиці, що містять ключі сутностей, називаються Хабамі (Hub). Хаби завжди містять фіксований набір полів:
- Натуральні ключі сутності
- Сурогатний ключ
- Посилання на джерело
- Час додавання запису
Записи у Хабах ніколи не змінюються та не мають версій. Зовні хаби дуже схожі на таблиці типу ID-map, що застосовуються в деяких системах для генерації сурогатів, проте як сурогати в Data Vault рекомендується застосовувати не цілісний сіквенс, а хеш від набору бізнес-ключів. Такий підхід спрощує завантаження зв'язків та атрибутів із джерел (не треба джойнітися на хаб для отримання сурогату, досить просто порахувати хеш від натурального ключа), але може викликати інші проблеми (пов'язані, наприклад, з колізіями, регістром та недрукованими символами у рядкових ключах тощо) .п.), тому є загальноприйнятим.
Усі інші атрибути сутностей зберігаються у спеціальних таблицях, які називаються Сателітами (Satellit). Один хаб може мати кілька сателітів, які зберігають різні набори атрибутів.
Розподіл атрибутів за сателітами відбувається за принципом спільної зміни — в одному сателіті можуть зберігатися не версійні атрибути (наприклад, дата народження та СНІЛС для фіз.особи), в іншому — версійні, що рідко змінюються (наприклад, прізвище і номер паспорта), в третьому — часто змінюються (наприклад, адреса доставки, категорія, дата останнього замовлення і.т.п). Версійність при цьому ведеться на рівні окремих сателітів, а не сутності в цілому, тому розподіл атрибутів доцільно проводити так, щоб перетин версій усередині одного сателіту був мінімальним (що скорочує загальну кількість версій, що зберігаються).
Також, для оптимізації процесу завантаження даних, окремі сателіти часто виносяться атрибути, одержувані з різних джерел.
Сателіти зв'язуються з Хабом по зовнішньому ключу (що відповідає кардинальності 1-кому). Це означає, що багато атрибутів (наприклад, кілька контактних номерів телефону в одного клієнта) підтримується такою архітектурою “за замовчуванням”.
В Якірної моделі (Anchor Model) таблиці, що зберігають ключі, називаються Якорями (Anchor). І зберігають вони:
- Тільки сурогатні ключі
- Посилання на джерело
- Час додавання запису
Натуральні ключі з точки зору Якорної Моделі вважаються звичайними атрибутами. Такий варіант може бути більш складним для розуміння, але він дає набагато більше простору для ідентифікації об'єкта.
Наприклад, якщо дані про ту саму сутність можуть надходити з різних систем, у кожній з яких використовується свій натуральний ключ. У Data Vault це може призводити до досить громіздких конструкцій з кількох хабів (по одному на джерело + об'єднувальна майстер-версія), в Якірній моделі ж натуральний ключ кожного джерела потрапляє у свій атрибут і може використовуватися при завантаженні незалежно від інших.
Але тут криється і один підступний момент: якщо в одній сутності поєднуються атрибути з різних систем, швидше за все існують деякі правила "склейки", Якими система повинна розуміти, що записи з різних джерел відповідають одному примірнику сутності.
В Сховище даних ці правила швидше за все визначатимуть формування "сурогатного хаба" майстер-сутності і ніяк не впливати на Хаби, що зберігають натуральні ключі джерел та їх вихідні атрибути. Якщо в якийсь момент правила склеювання зміниться (або прийде оновлення атрибутів, за якими вона проводиться), достатньо буде переформувати сурогатні хаби.
В Якірної моделі а така сутність швидше за все буде зберігатися в єдиному якорі. Це означає, що всі атрибути, незалежно від того, з якого джерела вони отримані, будуть прив'язані до того самого сурогату. Розділити помилково злиті записи і в цілому відстежувати актуальність склеювання в такій системі може виявитися суттєво важче, особливо, якщо правила досить складні і часто змінюються, а той самий атрибут може бути отриманий з різних джерел (хоча точно можливо, тому що кожна версія атрибута зберігає посилання на джерело).
У будь-якому випадку, якщо у вашій системі передбачається реалізація функціоналу дедублікації, злиття записів та інших елементів MDMварто особливо уважно ознайомитися з аспектами зберігання натуральних ключів у гнучких методологіях. Ймовірно, більш громіздка конструкція Data Vault раптово виявиться безпечнішою з погляду помилок злиття.
Якірна модель також передбачає додатковий тип об'єкта, що називається Вузлом (Knot) по суті це спеціальний вироджений вид якоря, який може містити лише один атрибут. Вузли передбачається використовуватиме зберігання плоских довідників (наприклад підлогу, сімейний стан, категорія обслуговування клієнтів тощо). На відміну від Якоря, Вузол не має пов'язаних таблиць атрибутіва його єдиний атрибут (назва) завжди зберігається в одній таблиці з ключем. Вузли зв'язуються з якорями таблицями-зв'язками (Tie) також, як якоря один з одним.
Однозначної думки щодо використання Вузлів немає. Наприклад, , Який активно просуває застосування Якірної моделі в Росії, вважає (не безпідставно), що для жодного довідника не можна точно стверджувати, що він завжди буде статичним та однорівневим, тому для всіх об'єктів краще відразу використовувати повноцінний Якір.
Ще одна важлива відмінність Data Vault та Якірної моделі полягає в наявності атрибутів у зв'язків:
В Сховище даних Зв'язки є такими ж повноцінними об'єктами, як і Хаби, і можуть мати власні атрибути. У Якірної моделі Зв'язки використовуються тільки для з'єднання Якорів та власних атрибутів мати не можуть. Ця відмінність дає суттєво різні підходи до моделювання фактів, про що йтиметься далі.
Зберігання фактів
До цього ми говорили переважно про моделювання вимірів. З фактами справа трохи менш однозначна.
В Сховище даних типовий об'єкт для зберігання фактів Зв'язок (Link), в Сателіті якої складаються речові показники.
Такий підхід видається інтуїтивно зрозумілим. Він дає простий доступ до аналізованих показників і загалом схожий традиційну таблицю фактів (тільки показники зберігаються над самій таблиці, а “сусідній”). Але є й підводні камені: одна з типових доробок моделі – розширення ключа факту – викликає необхідність додавання до Link нового зовнішнього ключа. А це, у свою чергу, "ламає" модульність і потенційно викликає необхідність доробок інших об'єктів.
В Якірної моделі Зв'язок не може мати власних атрибутів, тому такий підхід не прокотить - абсолютно всі атрибути та показники повинні мати прив'язку до одного конкретного якоря. Висновок з цього простий - для кожного факту теж потрібен свій якір. Для частини того, що ми звикли сприймати як факти, це може виглядати природно – наприклад, факт покупки чудово зводиться до об'єкта “замовлення” або “чек”, відвідування сайту – до сесії тощо. Але трапляються й факти, для яких знайти такий природний об'єкт-носій не так просто — наприклад, залишки товарів на складах на початок кожного дня.
Відповідно, проблем з модульністю при розширенні ключа факту в Якірної моделі не виникає (досить просто додати новий Зв'язок до відповідного Якоря), але проектування моделі для відображення фактів менш однозначно, можуть з'являтися "штучні" Якорі, що відображають об'єктну модель бізнесу не очевидно.
Як досягається гнучкість
Конструкція, що вийшла, в обох випадках містить істотно більше таблиць, ніж традиційний вимір. Але може займати істотно менше дискового простору при тому наборі версійних атрибутів, як і традиційний вимір. Ніякої магії тут, звісно, немає — вся справа нормалізації. Розподіляючи атрибути за Сателітами (Data Vault) або окремими таблицями (Anchor Model), ми зменшуємо (або зовсім виключаємо) дублювання значень одних атрибутів за зміни інших.
Для Сховище даних виграш залежатиме від розподілу атрибутів за Сателітами, а для Якірної моделі - Практично прямо пропорційний середній кількості версій на об'єкт вимірювання.
Проте виграш за місцем, що займається, — важлива, але не головна перевага окремого зберігання атрибутів. Разом з окремим зберіганням зв'язків такий підхід робить сховище. модульною конструкцією. Це означає, що додавання як окремих атрибутів, так і нових предметних областей в такій моделі виглядає як надбудова над існуючим набором об'єктів без зміни. І це саме те, що робить описані методології гнучкими.
Також це нагадує перехід від штучного виробництва до масового — якщо у традиційному підході кожна таблиця моделі унікальна і потребує окремої уваги, то у гнучких методологіях — це вже набір типових деталей. З одного боку, таблиць стає більше, процеси завантаження та вибірки даних мають виглядати складніше. З іншого — вони стають типовими. Отже, можуть бути автоматизовані та керуватися метаданими. Питання "як укладатимемо?", відповідь на який міг займати істотну частину робіт з проектування доробок, тепер просто не стоїть (як і питання про вплив зміни моделі на працюючі процеси).
Це не означає, що аналітики в такій системі зовсім не потрібні — хтось все ще має опрацювати набір об'єктів з атрибутами та розібратися звідки та як усе це завантажувати. Але обсяг робіт, а також ймовірність та ціна помилки суттєво знижуються. Як на етапі аналізу, так і при розробці ETL, яка в значній частині може звестися до редагування метаданих.
Темна сторона
Все вищеописане робить обидва підходи справді гнучкими, технологічними та придатними для ітеративного доопрацювання. Зрозуміло є і “бочка дьогтю”, про яку ви, гадаю, вже здогадуєтеся.
Декомпозиція даних, що лежить в основі модульності гнучких архітектур, призводить до збільшення кількості таблиць і, відповідно, накладних витрат на джойни під час вибірки. Для того, щоб просто отримати всі атрибути вимірювання, в класичному сховищі достатньо одного селекту, а гнучка архітектура вимагатиме цілого ряду джойнів. Причому якщо для звітів всі ці джойни можна написати заздалегідь, то аналітики, які звикли писати SQL руками, страждатимуть подвійно.
Є кілька фактів, що полегшують таке становище:
При роботі з великими вимірами майже ніколи не використовуються одночасно всі його атрибути. Це означає, що джойнів може бути меншим, ніж здається при першому погляді на модель. У Data Vault можна також врахувати ймовірну частоту спільного використання при розподілі атрибутів за сателітами. При цьому самі Хаби або Якорі потрібні в першу чергу для генерації та мапінгу сурогатів на етапі завантаження та рідко використовуються у запитах (особливо це стосується Якорів).
Усі джойни – за ключом. Крім того, більш "стислий" спосіб зберігання даних знижує накладні витрати на сканування таблиць там, де воно необхідне (наприклад при фільтрації за значенням атрибута). Це може призвести до того, що вибірка з нормалізованої бази з купою джойнів буде навіть швидшою, ніж сканування одного важкого виміру з великою кількістю версій на рядок.
Наприклад, ось у статті є докладний порівняльний тест продуктивності якорної моделі з вибіркою з однієї таблиці.
Багато залежить від движка. Багато сучасних платформ мають внутрішні механізми оптимізації джойнів. Наприклад, MS SQL і Oracle вміють "пропускати" джойни на таблиці, якщо їх дані не використовуються ніде, крім інших джойнів і не впливають на фінальну вибірку (table/join elimination), а MPP Vertica , показала себе як чудовий двигун для якірної моделі з урахуванням деякої ручної оптимізації плану запиту. З іншого боку, зберігати якірну модель, наприклад, на Click House, що має обмежену підтримку join, поки виглядає не дуже гарною ідеєю.
Крім того, для обох архітектур існують спеціальні прийоми, що полегшують доступом до даних (як з погляду продуктивності запитів, так кінцевих користувачів). Наприклад, Point-In-Time таблиці в Data Vault або спеціальні табличні функції в Якірної моделі.
Разом
Основна суть розглянутих гнучких архітектур полягає у модульності їхньої “конструкції”.
Саме ця властивість дозволяє:
- Після деякої початкової підготовки, пов'язаної з розгортанням метаданих та написанням базових алгоритмів ETL, швидко надати замовнику перший результат як парочки звітів, містять дані лише кількох об'єктів джерел. Цілком продумувати (навіть верхньорівнево) всю об'єктну модель для цього не обов'язково.
- Модель даних може почати працювати (і приносити користь) лише з 2-3 об'єктами, а потім поступово розростатися (щодо Якірної моделі Микола красиве порівняння з грибницею).
- Більшість доробок, включаючи розширення предметної галузі та додавання нових джерел не зачіпає існуючий функціонал і не викликає небезпеки зламати щось, що вже працює.
- Завдяки декомпозиції на стандартні елементи, ETL-процеси в таких системах виглядають однотипно, їх написання піддається алгоритмізації і, зрештою, автоматизації.
Ціною такої гнучкості є продуктивність. Це не означає, що досягти прийнятної продуктивності на таких моделях неможливо. Найчастіше вам просто може знадобитися більше зусиль і уваги до деталей для досягнення потрібних метрик.
Додатки
Типи сутності Сховище даних
Докладніше про Data Vault:
Типи сутностей Anchor Model
Докладніше про Anchor Model:
Зведена таблиця із загальними рисами та відмінностями розглянутих підходів:
Джерело: habr.com