Як і коли створювати сховища даних. Розбираємо основи

Привіт, спільното! Мене звати Олександр Федірко, і в ІТ я вже 20 років. Колись починав зі стеку Microsoft і MS SQL Server, займався як напряму базами даних, так і всім, що входило до поняття Business Intelligence (зі стеку Microsoft в ті часи — це були сервіси SSIS, SSAS, SSRS). А потім були і Oracle, і нереляційні бази даних. У команді GlobalLogic я з 2018 року, 5 років із яких обіймаю посаду голови Big Data Практик у Східній та Центральній Європі. У цій статті хочу поділитись своєю теоретично-практичною базою про сховища даних, зібраною за роки досвіду, в зручному та зрозумілому форматі.

Тож, коли потрібно створювати сховище даних? Які є популярні підходи, інструменти та технології? Розглянемо дві класичні схеми — Star та Snowflake. Зупинимось на таких поняттях як міри, таблиці фактів/вимірів і тому, як вони повʼязані між собою у схемі. В результаті ви матимете концептуальне розуміння того, як спроєктувати сховище даних, з конкретними прикладами до згаданої теорії.

Замість вступу: контекст і бекграунд

Чим більше організації накопичують даних, тим складніше їм управляти цими даними. CRM, ERP, системи управління персоналом, бухгалтерський облік, юридичні платформи, інструменти маркетингу та продажів — кожен із цих бізнес-напрямків та програмних рішень працює на основі даних. А фахівці, що опікуються цими даними, щодня стикаються з викликом: як ефективно зібрати, зберігати та організувати весь цей величезний обсяг інформації.

Завдання з бізнес-аналітики та загалом аналітики даних завжди залежать від того, що саме прагнуть дізнатися користувачі інформації. Ось декілька прикладів таких аналітичних задач:

• Створити єдине, узгоджене бачення даних, усуваючи численні визначення «клієнт» у відділах організації.
• Об’єднати та класифікувати великі обсяги даних за певними критеріями, такими як місяць, рік, регіон чи категорія клієнтів.
• Відфільтрувати дані за конкретними параметрами: регіоном, датою або категорією продукту.

Коли даними опікуються різні команди в різних підрозділах, часто виникають так звані «силоси» даних. Ці ізольовані системи перешкоджають обміну даними, що зрештою призводить до їхнього дублювання. На допомогу приходить концепція Single Source of Truth (SOT). Цей підхід передбачає збір даних з усіх куточків підприємства та їхнє об’єднання в одному централізованому сховищі, що потім визнається авторитетним джерелом для всієї компанії. Якісна аналітика та бізнес-аналітика потребують точних і повних даних, що базуються саме на принципі SOT.

Data Lake, Data Warehouse і Data Mart

Щоб краще зрозуміти процес побудови сховища даних, варто ознайомитися з основними поняттями та термінами.

Data Lake (озеро даних) — централізоване сховище, де зберігаються «сирі» дані, як неструктуровані, так і структуровані. Зберігати сирі дані саме в озері даних — доволі зручно для деяких цільових юзкейсів, таких як пристрої ІоТ, соціальні мережі, машинне навчання та стрімінг. Однак, щоб ці дані стали корисними, фахівцям необхідно їх спочатку вилучити (extract), перетворити (transform) і потім завантажити (load) (процес ETL) у велике центральне сховище — сховище даних (data warehouse).

Варто зазначити, що озера даних не завжди є частиною архітектури даних організації. Так само і сховища даних не обов’язково залежать від озер даних.

Data Warehouse (сховище даних). Воно вже містить чіткі, впорядковані та повні дані. Саме на їхній основі працівники компанії отримують своєчасну інформацію, що дозволяє їм приймати виважені рішення. Ці дані особливо зручні для створення звітів і різноманітних візуалізацій.

Data Mart (вітрина даних) — це окрема, менша база даних, яка є частиною сховища. Вона містить лише ту інформацію, що потрібна конкретному відділу, команді або групі користувачів у компанії. Наприклад, замість того, щоб відділ кадрів мав доступ до всіх корпоративних даних, для них створюється окрема вітрина. Вона містить виключно впорядковану інформацію про співробітників. Це дозволяє швидко знаходити потрібні дані та забезпечує чіткі права доступу.

Потік даних з озером даних і без нього

Я завжди рекомендую створювати озеро даних до того, як буде створено сховище даних. Але є організації, які пропускають цей етап. Розглянемо обидва сценарії на практиці.

Ось так виглядатиме потік даних при роботі з джерелами, озером, сховищем і вітринами даних:

Рис. 1 — Озеро даних, сховища даних, вітрина даних

А ось так — без озера даних:

Рис. 2 — Сховища даних і вітрина даних

Середовища даних без озера даних

Як я казав, деякі організації не створюють озера даних у своїй екосистемі. Щоб визначити, чи потрібно створювати озеро даних, варто звернути увагу на тип даних і їх розмір. Наприклад, озеро даних може не знадобитися, якщо у вас є лише структуровані дані і ви не плануєте розміщувати неструктуровані дані у своєму сховищі. Або якщо обсяг / розмір даних не вимагає використання Big Data технік.

Чим хороші екосистеми без озера даних?

• Спрощена архітектура з меншою кількістю компонентів і технологій.
• Уніфіковані механізми трансформації даних. Якщо ви працюєте лише зі структурованими даними, вам буде достатньо підходу, орієнтованого виключно на SQL. У більшості випадків не буде потреби у складних фреймворках, які були б потрібні з не-/напівструктурованими даними.
• Легше знайти дата-інженерів з конкретною технологічною спеціалізацією (наприклад, Snowflake) та навичками роботи з SQL.

В усіх інших випадках я рекомендую створювати озера даних перед тим, як переходити до сховища.

ETL-процес

ETL-процес є ключовим етапом, що дозволяє об’єднувати дані з різних джерел, трансформувати їх і завантажувати вже оброблену інформацію до сховища даних. Як це відбувається?

1. Спочатку структуровані та неструктуровані дані, отримані з різних джерел, експортуються до зони обробки.
2. На етапі обробки виправляються різноманітні недоліки, що могли виникнути під час введення даних. Зокрема, помилки у форматуванні, орфографічні помилки або пропущені значення.
3. Після обробки дані трансформуються. Цей етап передбачає приведення інформації до єдиної схеми, яка була розроблена для сховища даних.
4. Нарешті, перетворені та повністю готові дані переносяться із зони обробки до сховища даних. Тепер вони готові для використання.

Під час процесу ETL відбуваються два типи івентів, які забезпечують підготовку даних для подальшого використання — Ingestion і Wrangling.

• Ingestion (поглинання) — транспортування даних від їхніх джерел до місця призначення. На цьому етапі отримані дані вже мають відповідати певній структурі або формату. Ingestion може бути запланованим і запускатися за запитом або ж виконуватися за розкладом.
• Wrangling (перебір) — перетворення та організація необроблених даних у формат, придатний для конкретних бізнес-потреб. Цей етап передбачає: очищення даних, видалення дублікатів, обʼєднання даних, фільтрацію та підготовку даних до використання кінцевими споживачами та застосунками.

Транзакційна vs аналітична обробка даних

Два популярні підходи до обробки даних — це OLTP (транзакційна обробка даних) та OLAP (аналітична обробка даних).

OLTP підтримує дані для бізнес-транзакцій: покупки, замовлення, повернення, відшкодування тощо. OLTP підходить для простих, атомарних запитів і роботи суто з транзакційними даними, таких як роздрібні продажі або фінансові операції. Приклади OLTP — це транзакції в банкоматах і обробка платежів за кредитними картками. База даних OLTP зазвичай нормалізується, тобто її структура поділяється на менші, логічно пов’язані частини для оптимізації транзакцій.

Хоча OLTP може бути високоефективним для транзакційних даних, він не є оптимальним для аналітики. А якщо спробувати використати дані, структуровані для OLTP, в аналітиці? Ось які проблеми можуть виникнути:

• Оскільки дані нормалізовані та розкидані по багатьох таблицях, для отримання потрібної інформації часто доводиться писати надмірно складні SQL-запити. При цьому нерідко дублюються операції об’єднання (JOIN).
• Аналітичні запити є ресурсоємними і виконуються повільно. Це може негативно впливати на інші транзакції в базі даних, що погіршує її загальну продуктивність.
• Операції об’єднання (JOIN), агрегації (GROUP BY) та сортування (ORDER BY) великих обсягів даних вимагають значних обчислювальних ресурсів, створюючи додаткове навантаження на систему.

Перетворення нормалізованих даних у формат для аналітики вимагає додаткових ресурсів, таких як пам’ять, IO та CPU. Довгі запити можуть значно навантажувати базу даних, а це призводить до блокувань. Через такі блокування редагування даних під час виконання аналітичного запиту стає неможливим.

OLAP натомість призначений для роботи з аналітичними даними та ідеально підходить для великих корпоративних баз даних. Цей підхід є оптимальним для розвʼязання аналітичних бізнес-завдань, таких як візуалізація та звітність. Дані OLAP зазвичай багатовимірні та денормалізовані:

• Багатовимірні дані мають централізовану таблицю фактів, яка містить посилання на виміри.
• Денормалізація — це процес «покращення» даних саме для аналітичних цілей. Він полягає у створенні надлишкових даних та зменшенні кількості таблиць чи необхідних операцій об’єднання (JOIN).

Канонічна модель даних

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

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

Створення канонічної моделі — must-have перед тим, як розгортати сховища та вітрини даних. Щоби створити таку модель, потрібно провести інтервʼю зі стейкхолдерами організації та обговорити підходи до стандартизації. В результаті ви маєте досягти консенсусу щодо термінів, атрибутів і взаємозв’язків, які будуть використані для уніфікації даних у межах усієї компанії.

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

Масштабування в рамках Enterprise City Map та Enterprise Data Platform

Коли ми говоримо про роль сховища даних у корпоративних системах, маємо на увазі весь той потік даних, що генерується бізнес-юнітами + централізовану платформу для їхнього збору (Data Platform-и). Виглядає це приблизно так:

Рис.3 — Мапа підприємства

Як поєднується все описане вище у платформі даних? У Data Platform функціональність сховища даних логічно розміщується в компоненті Source of Truth та блоці управління даними (Governance).

Нагадаю: SOT означає, що сховище даних є основним, найбільш авторитетним джерелом інформації в організації. Блок управління даними відповідає за якість, безпеку та правила користування даними. Цей компонент охоплює моделювання даних (визначення їх структури) і вітрини даних (тематичні підмножини даних для конкретних потреб). А перед сховищем даних зазвичай йдуть озера даних, які відповідають за ingestion, первинну обробку (той самий wrangling) та очищення «сирих» даних.

Рис. 4 — Корпоративна платформа даних

Впровадження рішення для сховища даних

Функції та їх застосування на практиці

Підходи до моделювання сховищ

Для ефективної аналітики та звітності дата-інженерам слід обрати оптимальний підхід до побудови сучасного data warehouse, що відповідає потребам організації. Кожен підхід має свої переваги та недоліки, і їх потрібно зважити при виборі оптимального рішення. Розглянемо найпопулярніші чотири підходи до проєктування сховища даних, з якими я стикався на практиці.

Вимірне (dimensional) сховище даних за Кімбалом — підхід «знизу-вгору». Це означає, що архітектура вашого сховища даних формується, виходячи з того, як інформація споживається у вітринах даних. Ця техніка забезпечує більш швидке отримання даних. Вона орієнтована на аналітичні завдання та передбачає використання таблиць фактів (fact tables) і вимірів (dimension tables), побудованих за схемами Star або Snowflake.

Корпоративне сховище даних за Інмоном — підхід «зверху-вниз». Він фокусується насамперед на інтеграції даних у сховищі. Білл Інмон рекомендує створення централізованого сховища даних на корпоративному рівні, яке зберігає нормалізовані дані. Потім ці дані спрямовуються до різних вітрин для окремих груп споживачів і застосунків. У вітринах даних так само застосовуються схеми Star або Snowflake.

Data Vault — цей підхід вже вимагатиме досвідчених дата-архітекторів. Його розробив Ден Лінстед. Цей підхід фіксує зміни даних щоразу, коли змінюється або додається джерело інформації. Він базується на ідеї, що всі дані є релевантними. І навіть ті, що не відповідають встановленим визначенням чи бізнес-правилам (так звані non-conforming data), не є проблемою для сховища даних.

Моделювання Data Vault зосереджено навколо концепції хабів (hubs), лінків (links) і сателітів (satellites).

• Хаби представляють ключові бізнес-концепції (наприклад, клієнт, продукт).
• Лінки описують асоціації між хабами (наприклад, замовлення, що пов’язує клієнта з продуктом).
• Сателіти зберігають детальну інформацію про хаби та їхні взаємозв’язки, фіксуючи зміни цих даних у часі.

Для компаній, яким потрібне вимірне моделювання, дані з Data Vault вимагатимуть додаткової конвертації.

Підхід Data Vault вважається складнішим за моделі Кімбала та Інмона з кількох ключових причин:

1. Абстракція та кількість сутностей: модель Data Vault вводить додатковий рівень абстракції через використання хабів, лінків і сателітів. Це означає, що для розуміння моделі потрібно оперувати не лише звичними таблицями фактів і вимірів (як у Кімбала) або нормалізованими таблицями (як у Інмона), а й цими трьома сутностями.
2. Управління історією даних: Data Vault робить акцент на збереженні повної історії змін даних у сателітах. Хоча це є сильною стороною моделі, управління цією історією, особливо при великих обсягах даних, може бути технічно складнішим з точки зору зберігання, індексації та запитів.
3. Непряме представлення бізнес-логіки: Бізнес-логіка та аналітичні потреби не відображаються безпосередньо в моделі Data Vault. Щоб отримати дані для аналітики, часто потрібні додаткові зміни. Наприклад, створення вітрин даних з вимірною моделлю на основі Data Vault. Це додає ще один рівень складності до загальної архітектури.
4. Потреба у висококваліфікованих фахівцях: Через свою складність і абстрактність, розробка та підтримка Data Vault вимагає від дата-архітекторів глибокого розуміння принципів моделювання даних, процесів ETL/ELT та особливостей роботи з історичними даними. Відповідно, і крива навчання є більш стрімкою для нових фахівців.

Ще один специфічний підхід — Anchor Modeling. Він підходить для побудови гнучких та еволюціонуючих сховищ даних. Він забезпечує високу стійкість до змін у вимогах бізнесу та джерелах даних, а також спрощує перевірку та відстеження походження даних. У порівнянні з підходом Data Vault, Anchor Modeling більш адаптований до змін у вихідних даних. Розберемо основні концепції Anchor Modeling на прикладі CRM того самого інтернет-магазину:

1. Anchor (Анкер): бізнес-сутність, яка має унікальну ідентифікацію і відносно стабільний набір ідентифікуючих атрибутів.

Приклад: Таблиця customer_anchor. Вона містить єдиний стовпець customer_id (первинний ключ, унікальний ідентифікатор клієнта). Можливо, також буде стовпець customer_uid (унікальний зовнішній ідентифікатор, якщо такий є). Сама таблиця не містить жодних інших описових атрибутів клієнта (ім’я, адреса тощо).

SQL
CREATE TABLE customer_anchor (
    customer_id INT PRIMARY KEY,
    customer_uid VARCHAR(255) UNIQUE
);

2. Attribute (Атрибут): зберігає окремі атрибути сутності. Кожен атрибут знаходиться у своїй власній таблиці та пов’язаний з анкером через його ідентифікатор. Це дозволяє легко додавати нові атрибути без зміни існуючої структури.

Приклад: таблиця customer_name_attribute для зберігання імені клієнта:

CREATE TABLE customer_name_attribute (
    customer_id INT REFERENCES customer_anchor(customer_id),
    name VARCHAR(255),
    valid_from TIMESTAMP,
    valid_to TIMESTAMP,
    PRIMARY KEY (customer_id, valid_from)
);

Зверніть увагу на стовпці valid_from та valid_to. Вони дозволяють відстежувати історію змін атрибутів. Якщо клієнт змінює ім’я або електронну пошту, додається новий запис з відповідним часовим діапазоном дії.

3. Knot (Вузол): представляє кодові значення або довідники, які можуть використовуватися багатьма анкерами або атрибутами.

Приклад: таблиця country_knot для зберігання назв країн:

SQL
CREATE TABLE country_knot (
    country_code CHAR(2) PRIMARY KEY,
    country_name VARCHAR(255) UNIQUE
);


INSERT INTO country_knot (country_code, country_name) VALUES ('UA', 'Україна');
INSERT INTO country_knot (country_code, country_name) VALUES ('US', 'Сполучені Штати Америки');
-- ... інші країни

Атрибут адреси клієнта може посилатися на цю таблицю:

SQL
CREATE TABLE customer_address_attribute (customer_id INT REFERENCES customer_anchor(customer_id),
    street VARCHAR(255),
    city VARCHAR(255),
    country_code CHAR(2) REFERENCES country_knot(country_code),
    postal_code VARCHAR(20),
    valid_from TIMESTAMP,
    valid_to TIMESTAMP,
    PRIMARY KEY (customer_id, valid_from)
);

4. Tie (Зв’язок): представляє зв’язки «багато-до-багатьох» між анкерами.

Приклад: зв’язок між клієнтами та їхніми замовленнями (один клієнт може мати багато замовлень). Припустимо, у нас є анкер order_anchor з order_id. Таблиця зв’язку customer_order_tie буде виглядати так:

SQL
CREATE TABLE customer_order_tie (
    customer_id INT REFERENCES customer_anchor(customer_id),
    order_id INT REFERENCES order_anchor(order_id),
    link_valid_from TIMESTAMP,
    link_valid_to TIMESTAMP,
    PRIMARY KEY (customer_id, order_id, link_valid_from)
);

Ця таблиця фіксує, який клієнт пов’язаний з яким замовленням та в який період часу.

Таким чином:

• customer_anchor є анкером, що ідентифікує кожного клієнта за його customer_id.
• customer_name_attribute, customer_email_attribute, customer_address_attribute є атрибутами, що зберігають різну інформацію про клієнта. Кожен атрибут має власну таблицю та пов’язаний з customer_anchor.
• country_knot є вузлом, що містить перелік країн і використовується в таблиці customer_address_attribute.
• customer_order_tie є зв’язком, що відображає взаємозв’язок між анкерами customer_anchor та (уявною) order_anchor.

На перший погляд така структура може здаватися більш складною через велику кількість таблиць. Втім, при зміні вимог до даних саме вона забезпечить найбільшу гнучкість. Наприклад, якщо нам потрібно додати новий атрибут до клієнта (номер телефону), ми просто створимо нову таблицю атрибутів customer_phone_attribute без необхідності змінювати існуючі таблиці. Це робить Anchor Modeling стійким до розвитку бізнес-домену та джерел даних.

Архітектура

Архітектура сховища даних складається з рівнів, що відповідають за попередню обробку сирих і неструктурованих даних, перетворюючи їх на структуровані. Рівні дозволяють нам зрозуміти, класифікувати статус і тип даних на кожному етапі. Завантаження (data ingestion), попередня обробка (preprocessing) та трансформація (transformation) даних гарантують, що в результаті користувачі отримують якісну інформацію.

Перш ніж ми детально розглянемо рівні архітектури сховища даних, варто розібратися із завантаженням цих даних (ingestion).

Техніки Ingestion

Data ingestion — це процес отримання даних з різноманітних первинних джерел та їхнє переміщення на перший рівень сховища. Саме з цього розпочинається процес трансформації. Існують дві основні техніки завантаження даних:

Пакетне завантаження даних (Batch Data Ingestion) — групи «сирих» даних вилучаються та переміщуються з джерел даних на перший рівень сховища. Пакетна обробка може також виконуватися між рівнями архітектури сховища даних. Це економічно вигідно, адже потребує менше обчислювальних ресурсів. Однак цей процес може бути повільним.

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

Потокове завантаження даних (Streaming Data Ingestion) — дані безперервно передаються з первинних джерел на перший рівень сховища. Потокове завантаження забезпечує точні та актуальні дані для бізнес-аналітики. Однак при завантаженні до сховища даних вони можуть бути трансформовані в пакети.

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

Рівні сховища даних

Розглянемо три основні рівні архітектури сховища даних. Для позначення якості даних їх класифікують як бронзовий (bronze), срібний (silver) та золотий (gold). Чим «вище» рівень, кожен з яких має своє призначення, тим якісніші дані.

Рис. 5 — Рівні сховища даних

Перший рівень

Дані з різноманітних джерел вилучаються, завантажуються та транспортуються на перший рівень. Він відповідає «сирим» даним і класифікується як бронзовий рівень якості. Альтернативні назви: raw layer, source layer. У процесі ETL цей рівень відповідає етапу вилучення (Extraction).

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

Другий рівень

На другому рівні, де дані у проміжній області (staging area) класифікуються як срібні, виконується очищення, збагачення та нормалізація. У процесі ETL цей рівень відповідає етапу трансформації (Transformation).

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

Якщо у вашому середовищі немає озера даних, ви можете застосувати схему Star або Snowflake безпосередньо до даних на цьому рівні. Факти — це зазвичай набори числових значень, які можна агрегувати, а виміри — це групи ієрархій та дескрипторів, що уточнюють факти. На цьому рівні виконується злиття та зіставлення даних, а також проводяться базові перевірки якості (наприклад, актуальність даних та відповідність основним бізнес-правилам).

Рис. 6 — Рівні сховища даних без озера даних

Третій рівень

Дані, до яких вже застосовано схему, завантажуються до сховища даних. На цьому рівні дані класифікуються як золоті.

Тут дані денормалізуються для подальшого зменшення кількості операцій об’єднання (JOIN) при запитах до них. На цьому етапі виконуються повномасштабні перевірки якості даних, зокрема перевіряється точність (data accuracy) та цілісність (data consistency). Також саме на цьому рівні застосовуються Slowly Changing Dimensions. Після цього дані повністю готові для споживачів та аналітики.

Схеми для моделювання за технікою dimensional modeling

Схема дозволяє представити сирі, структуровані дані у зручному для подальшого використання форматі. Такі дані потім застосовують в аналітиці, машинному навчанні, Інтернеті речей тощо. Розглянемо дві популярні схеми для вимірного моделювання: Star і Snowflake. Обидві схеми будуються на основі таблиці фактів і таблиць вимірів.

Зорієнтуємось по термінології, якою тут керуємось:

Таблиця фактів. Факти зазвичай є наборами числових значень, які можна обʼєднати. Таблиця фактів пов’язана з:

• єдиним набором таблиць вимірів (підхід у star schema);
• або таблицями вимірів, які мають багаторівневі зв’язки з додатковими таблицями вимірів (підхід у snowflake schema).

Прикладом таблиці фактів можуть бути дані про продажі магазину, що включають загальну суму продажів, податки, знижки, кількість продажів тощо. Всі ці метрики називаються мірами (measures).

Таблиці вимірів зберігають деталі та атрибути, пов’язані з фактами в таблиці фактів. Наприклад, якщо одиниці житла — один із фактів для демографічних даних, таблиця вимірів могла б включати різні характеристики житла: як будинки, зайняті власниками; орендовані будинки; категорія місячної орендної плати тощо.

Схема Star — це структура бази даних, де таблиця фактів напряму пов’язана з таблицями вимірів. Важливо, що ці таблиці вимірів не мають подальших зв’язків з іншими вимірами. Наприклад, уявіть таблицю фактів зі стовпцями даних про продажі (що продано, в якій кількості тощо). Вона може мати таблиці вимірів з інформацією про місце продажу, дату продажу, конкретну модель товару, продавця, який здійснив продаж, і так далі. Схема Star використовує денормалізовану структуру даних, де дублювання інформації є прийнятним. Це застосовується до всіх таблиць.

Схема Snowflake — структура бази даних, де таблиця фактів пов’язана з кількома таблицями вимірів, що відображають багаторівневі зв’язки. Тобто виміри можуть мати зв’язки з іншими вимірами.

Star

Таблиця фактів містить події, такі як покупка товару, дата покупки, вартість покупки тощо. Кількісні значення або міри (measures) можуть бути, такими як Item_Count (кількість товарів), Tax_Amount (сума податку) та Discount_Amount (сума знижки). Таблиці фактів мають посилання на виміри. Однак ці виміри не мають жодних посилань на інші виміри. Розглянемо на прикладі:

Рис. 7 — Таблиці фактів і таблиці вимірів у схемі Star

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

У цьому прикладі кожен факт має посилання на чотири виміри: DIM_Date_ID, DIM_Location_ID, DIM_Product_ID та DIM_Branch_ID. Вони надають додаткову інформацію щодо кожного з цих елементів. Ці таблиці вимірів визначають розмірність таблиці фактів і містять атрибути, що використовуються для аналізу (наприклад, День, Місяць, Рік).

Snowflake

У Snowflake схемі таблиці фактів пов’язані з кількома таблицями вимірів, які, своєю чергою, теж пов’язані з іншими таблицями вимірів. Так загальна структура нагадує сніжинку. На відміну від Star-схеми, організація даних за схемою Snowflake є складнішою, вимагає більш детального попереднього планування, а дані піддаються більшій нормалізації. Розглянемо на схемі:

Рис. 8 — Таблиці фактів і таблиці вимірів у схемі Snowflake

У нас є три додаткові таблиці вимірів, які пов’язані з таблицями вже існуючих вимірів DIM_Product та DIM_Location. Ці три додаткові таблиці вимірів (DIM_Product_Category, DIM_Brand та DIM_State) мають посилання на свої батьківські таблиці. Однак ми не нормалізуємо таблиці вимірів DIM_Branch або DIM_Date.

Star VS Snowflake

Схеми відрізняються рівнем нормалізації, що застосовується до таблиць. Щоби зрозуміти контекст цих відмінностей, достатньо коротко розібратись у другій нормальній формі (2NF) та третій нормальній формі (3NF).

2NF передбачає денормалізацію баз даних. Це робиться коштом додавання надлишкових даних, що дозволяє покращити швидкість аналізу даних. 3NF використовує нормалізацію для зменшення дублювання даних, уникнення розбіжностей, забезпечення цілісності та спрощення управління даними.

У розглянутій нами схемі Star всі таблиці, крім DIM_Branch та FACT_Sales, знаходяться на рівні 2NF. Таблиці DIM_Branch та FACT_Sales відповідають 3NF.

У схемі ж Snowflake всі таблиці мають 3NF, за винятком DIM_Date, яка знаходиться на рівні 2NF. Таблиця DIM_Branch для Snowflake залишається без змін, оскільки вона вже нормалізована до 3NF. Таблиця DIM_Date також не змінюється, оскільки є штучним статичним виміром, який не потребує оновлень у майбутньому.

То як вибрати ідеальну схему для вашої організації? Я керуюсь наступними чекпоінтами:

Технології для побудови сховища даних

Для побудови архітектури сховища даних доступні дві основні категорії баз даних: орієнтовані на рядки та орієнтовані на колонки. Бази даних, орієнтовані на рядки, підтримуються MS SQL Server (за замовчуванням), MySQL (MyISAM engine), Postgres (за замовчуванням) та Oracle (за замовчуванням).

Побудова сховища даних на основі бази даних, орієнтованої на рядки, де функції баз даних OLTP та OLAP обробляються окремо, є економічно вигідною. Однак щоб досягти оптимальної швидкості аналізу даних, я раджу використовувати колонкові бази даних. Які їхні основні плюси:

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

Наприклад, якщо вам потрібно проаналізувати лише середню ціну проданих товарів за певний період, колонкова база даних прочитає лише стовпці з ціною та датою, ігноруючи інші стовпці (наприклад, ім’я клієнта, адресу доставки).

• Оптимізація для розріджених даних: колонкові бази даних добре оптимізовані для роботи з розрідженими даними (тобто великою кількістю порожніх, або NULL-значень). Завдяки використанню спеціальних алгоритмів вони стискають інформацію значно ефективніше, ніж рядкові.

Припустимо, у вас є таблиця з інформацією про відгуки клієнтів про різні товари. Не кожен клієнт залишає відгук на кожен товар. У стовпці з текстом відгуку буде багато NULL-значень. Колонкова база даних ефективно стисне цей стовпець, зберігаючи лише наявні відгуки.

• Оптимізація для операцій агрегацій: колонкові бази даних чудово підходять для таких операцій як SUM, AVG, COUNT, MIN, MAX. Вони є типовими для аналітичних запитів. Оскільки всі значення для певного показника (стовпця) зберігаються разом, обчислення відбувається значно швидше.

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

Доступні інструменти та платформи

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

• Amazon RedShift — сервіс сховища даних на основі технології масово-паралельної обробки (MPP) від AWS, призначений для обробки великих обсягів даних і міграції баз даних.
• Apache Arrow — незалежний від мови програмування формат колонкової пам’яті для плоских та ієрархічних даних. Він оптимізований для ефективних аналітичних операцій на сучасному обладнанні, що використовує CPU та GPU.
• Apache Druid — Орієнтоване на колонки розподілене сховище даних з відкритим вихідним кодом, написане на Java. Воно забезпечує швидке завантаження великих обсягів даних та низьку затримку при запитах до них.
• Apache Optimized Row Columnar (ORC) — Вільний формат зберігання даних з відкритим вихідним кодом, орієнтований на колонки. Схожий на інші формати колонкового зберігання в екосистемі Hadoop, такі як RC File та Parquet. Цей формат даних використовується у фреймворках обробки даних, таких як Apache Spark, Apache Hive, Apache Flink та Apache Hadoop.
• Apache Parquet — формат файлів з відкритим вихідним кодом, орієнтований на колонки. Його створили для зручного зберігання та швидкого доступу до інформації. Parquet добре стискає дані і має спеціальні способи їх кодування, що дозволяє краще працювати зі складними даними великих обсягів. Цей формат найчастіше обирають в індустрії.
• Azure Synapse Analytics — хмарний сервіс зберігання та аналітики даних, data-as-a-service в середовищі Azure.
• BigQuery — повністю кероване, безсерверне сховище даних від Google, що забезпечує масштабований аналіз петабайтів даних. Це PaaS, який підтримує запити з використанням ANSI SQL та надає вбудовані можливості машинного навчання.
• Delta Lake — рівень зберігання з відкритим вихідним кодом для створення надійних озер даних. Delta Lake підтримує ACID-транзакції, масштабовану обробку метаданих, об’єднує потокову та пакетну обробку даних. Він сумісний з існуючими озерами даних та API Apache Spark.
• Snowflake — хмарний сервіс зберігання та аналітики даних, data-as-a-service. Дозволяє організаціям зберігати та аналізувати дані, використовуючи апаратні та програмні ресурси в хмарі.

Висновки

У цій статті ми розглянули вимоги до сучасного сховища даних, здатного задовольнити різноманітні потреби споживачів даних і застосунків у межах підприємства. Ми визначили важливість стандартизації шляхом розробки канонічної моделі даних і необхідність попереднього планування. Dimensional modeling допоможе підготувати дані для використання в аналітиці, машинному навчанні, IoT та інших сферах. Ми також розглянули схеми Star і Snowflake — два популярні підходи, що забезпечують використання dimensional modeling для сховища даних.

Хочу побажати терпіння тим, хто хоче поглибити свої знання з цієї тематики, оскільки більшість літератури по цій тематиці доволі нудна і об’ємна. Проблема у вивченні сховищ даних полягає у тому, що код і дизайн майже не знайти на таких публічних сайтах як github. Але можна знайти курси на MooC-платформах, таких як Coursera і тому подібних. Шукати курси можна за ключовими словами: DWH, Data Warehouse, Data Lake. Рекомендую також сфокусуватись на одному з хмарних провайдерів (найчастіше клієнти обирають MS Azure або AWS), і підготуватись та здати сертифікацію на Data Engineer.

Аналітичні сховища даних є невід’ємною складовою роботи інженера даних. Більшість практики можна отримати, на жаль, лише на реальних проєктах. Тож побажаю Вам цікавих аналітичних сховищ при роботі з замовниками.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті