Архітектура даних є критично важливим аспектом успішної інженерії даних. Вона закладає основу для того, як дані збираються, зберігаються, обробляються та використовуються в організації. Завдяки добре розробленій архітектурі даних компанії можуть досягти безперешкодної інтеграції даних, високої продуктивності, масштабованості та ефективного управління даними.
У цій статті я розповім про основні принципи хорошої архітектури даних, обговорю ключові архітектурні концепції та заглиблюся в різні патерни архітектури даних, щоб допомогти вам у розробці надійних і масштабованих систем даних.
Що таке архітектура даних?
Архітектура даних – це структурована система, яка визначає, як дані збираються, зберігаються, управляються та використовуються в організації. Вона визначає потоки даних, моделі даних і технології, що використовуються для обробки даних. Надійна архітектура даних забезпечує доступність, надійність і релевантність даних для різних бізнес-потреб, що сприяє ефективному прийняттю рішень і підвищенню операційної ефективності.
Архітектура даних є частиною архітектури підприємства, яка охоплює всю ІТ-інфраструктуру та процеси організації. Архітектура підприємства включає різні компоненти, такі як бізнес-архітектура, архітектура додатків, технічна архітектура та архітектура даних. Розуміння ширшого контексту архітектури підприємства допомагає визначити роль і значення архітектури даних у загальній стратегії організації.
Еволюція архітектури даних
За останні десятиліття архітектура даних зазнала значних змін, зумовлених зростаючою потребою в ефективній аналітиці даних та модернізації стратегій використання даних для отримання вигоди для бізнесу. Ця еволюція відзначається кількома ключовими етапами, кожен з яких характеризується окремими архітектурними практиками та технологіями.
До 2000 року: Епоха корпоративних сховищ даних (EDW)
У цей період основна увага була зосереджена на успіху та впровадженні корпоративних сховищ даних (Enterprise Data Warehouses, EDWs). Організації прагнули створити централізовані сховища, де можна було б зберігати, управляти та аналізувати дані з різних джерел. Основна мета полягала в підтримці потреб бізнес-аналітики та звітності за допомогою структурованого та узгодженого зберігання даних.
Характеристики:
- Централізоване зберігання даних
- Структуровані дані з чітко визначеними схемами
- Зосередьтеся на бізнес-аналітиці та звітності
Обмеження:
- Високі витрати на впровадження та обслуговування
- Проблеми масштабованості зі зростанням обсягів даних
- Труднощі в інтеграції різних джерел даних
2000-2010 роки: Епоха пост-EDW
У цей період відбувся зсув у бік подолання обмежень традиційних сховищ даних. Організації зіткнулися з проблемами фрагментарних даних і «силосів» даних, що призводило до непослідовного і фрагментарного аналізу. Вітрини даних стали популярними, оскільки дозволили відділам керувати власними даними, але це призвело до подальшої фрагментації.
Характеристики:
- Покладання на сховища та вітрини даних
- Аналіз фрагментованих даних
- Поява сховищ даних
Обмеження:
- Неузгоджений аналіз даних між відділами
- Труднощі з консолідацією даних для отримання інсайтів для всього підприємства
- Постійні високі витрати на підтримку декількох систем даних
2010-2020 роки: The logical data warehouse (LDW)
The logical data warehouse (LDW) з’явилося як рішення для фрагментованого ландшафту даних. Воно запровадило спільний семантичний рівень, який уніфікував доступ до даних у різних системах зберігання, включаючи сховища даних, вітрини даних та озера даних. Такий підхід уможливив більш уніфікований аналіз даних та покращив їхню доступність.
Характеристики:
- Уніфікований доступ до даних через спільний семантичний шар
- Інтеграція сховищ даних, вітрин даних та озер даних
- Розширені можливості аналізу даних
Переваги:
- Покращена узгодженість та інтеграція даних
- Покращена масштабованість і гнучкість
- Краща підтримка великих даних і розширеної аналітики
Обмеження:
- Постійна залежність від декількох систем зберігання даних
- Складність в управлінні семантичним шаром
- Потреба в спеціалізованих навичках для впровадження та підтримки ПЗЗ
2020 рік і далі: Ера розширеної аналітики даних та активних метаданих
Нинішній і майбутній етап розвитку архітектури даних позначений розвитком розширеної аналітики даних, що базується на передових технологіях, таких як штучний інтелект, машинне навчання та оркестрування даних. Ця ера зосереджена на демократизації доступу до даних і забезпеченні аналітики самообслуговування на основі активних метаданих.
Характеристики:
- Розширена аналітика даних за допомогою штучного інтелекту та машинного навчання
- Самообслуговування даних на основі метаданих
- Удосконалені механізми оркестрування даних та рекомендацій
- Адаптивні практики та активний аналіз метаданих
Переваги:
- Покращений доступ до даних та можливості самообслуговування
- Покращене прийняття рішень завдяки розширеній аналітиці
- Більша гнучкість в адаптації до мінливих потреб бізнесу
Активні метадані: Метадані відіграють вирішальну роль у сучасному світі, описуючи різні аспекти даних і забезпечуючи інтелектуальне управління даними. Існує чотири типи метаданих:
- Технічні метадані: Інформація про зберігання, структуру та обробку даних.
- Операційні метадані: Дані про робочі потоки, процеси та використання даних.
- Бізнес-метадані: Контекстна інформація про бізнес-значення та використання даних.
- Соціальні метадані: Інформація, отримана на основі взаємодії даних та моделей використання.
Активні метадані не лише описують дані, але й визначають дії в різних системах, сприяючи більш динамічним та інтелектуальним операціям з даними.
Приклади використання:
- Управління основними даними
- Обмін даними між підприємствами
- Інтеграція даних додатків
- Обмін даними про партнерів
Еволюція до активних метаданих і розширеної аналітики розширює можливості архітектури даних за межі традиційних практик, дозволяючи більш складне управління даними та їх аналіз у різних сценаріях використання.
Ключові архітектурні принципи та концепції
Розуміння основних архітектурних принципів і концепцій має вирішальне значення для розробки ефективної архітектури даних. Ці принципи формують фундамент, на якому будуються надійні, масштабовані та гнучкі системи даних.
Принципи від провідних підприємств
Великі підприємства дотримуються власних архітектурних принципів, щоб забезпечити ефективність та результативність своїх систем. Наприклад:
Добре збудована структура AWS складається з шести компонентів:
- Операційна досконалість
- Безпека
- Надійність
- Ефективність роботи
- Оптимізація витрат
- Сталий розвиток
П’ять принципів хмарної архітектури Google Cloud такі:
- Дизайн для автоматизації.
- Be smart with state.
- Надавайте перевагу керованим послугам.
- Практикуйте глибокий захист.
- Завжди будьте архітектором.
Черпаючи натхнення з цих фреймворків та інших ресурсів, таких як «Основи інженерії даних», ось деякі систематизовані принципи та концепції, необхідні для розробки хорошої архітектури даних:
Домени та послуги
Домен – це конкретна сфера бізнесу або знань, яку підтримує ваша архітектура даних. Сервіси – це функціональні можливості, які виконують конкретні завдання в межах домену.
Приклад: У компанії, що займається роздрібною торгівлею, домени можуть включати продажі, інвентаризацію та обслуговування клієнтів. Послуги в домені продажів можуть включати обробку замовлень, виставлення рахунків та управління клієнтами.
Переваги:
- Організаційна ясність: Чітко визначені домени та сервіси допомагають організувати дані та процеси.
- Сфокусований розвиток: Команди можуть зосередитися на конкретних послугах, підвищуючи ефективність та експертизу.
Розподілені системи
Розподілені системи – це системи, в яких компоненти, розташовані на різних комп’ютерах, об’єднаних у мережу, взаємодіють і координують свою роботу для досягнення спільної мети. Вони необхідні для побудови масштабованих і відмовостійких архітектур даних.
Приклад: Платформа соціальних мереж використовує розподілені системи для обробки мільярдів взаємодій користувачів у різних центрах обробки даних по всьому світу.
Переваги:
- Масштабованість: Легко справляйтеся зі збільшеним навантаженням, додаючи більше вузлів.
- Надійність: Резервні вузли забезпечують доступність системи, навіть якщо деякі з них вийдуть з ладу.
Масштабованість та еластичність
Масштабованість – це здатність системи обробляти зростаючі обсяги роботи шляхом додавання ресурсів. Еластичність – це здатність динамічно збільшувати або зменшувати ресурси залежно від попиту.
Приклад: Платформа електронної комерції масштабує інфраструктуру бази даних під час подій з високим трафіком, таких як Чорна п’ятниця, а потім зменшує масштаби, щоб заощадити витрати.
Переваги:
- Економічна ефективність: Платіть лише за ті ресурси, які ви використовуєте.
- Оптимізація продуктивності: Підтримуйте продуктивність під час пікових навантажень та оптимізуйте витрати в періоди низької завантаженості.
Доступність та надійність
Доступність – це відсоток часу, протягом якого система функціонує і є доступною. Надійність – це здатність системи функціонувати правильно і послідовно протягом певного часу.
Ключові показники:
- Час безвідмовної роботи: Відсоток часу, протягом якого система працює.
- Середній час напрацювання на відмову (MTBF): Середній час між відмовами системи.
- Середній час ремонту (MTTR): Середній час ремонту системи, що вийшла з ладу.
Стратегії:
- Резервування: Впровадження дублюючих систем для заміни в разі збою.
- Механізми відмовостійкості: Автоматичне перемикання на резервну систему в разі збою.
Архітектура, керована подіями
Подієво-керована архітектура – це парадигма проектування, в якій система реагує на події або зміни стану. Цей підхід має високу ступінь відокремленості, що сприяє гнучкості та масштабованості.
Приклади використання:
- Аналітика в реальному часі
- IoT-системи
- Системи сповіщення
Приклад: Банківський додаток використовує архітектуру, керовану подіями, щоб запускати сповіщення про транзакції на рахунку, попередження про шахрайство та оновлення балансу.
Доступ користувачів: Однокористувацький vs. багатокористувацький
В однокористувацьких архітектурах кожному клієнту виділяється окремий екземпляр програмного забезпечення та бази даних, тоді як в багатокористувацьких архітектурах ресурси розподіляються між кількома клієнтами.
Міркування:
- Продуктивність: Оренда з одним орендарем може забезпечити кращу продуктивність, але оренда з кількома орендарями є більш економічно вигідною.
- Безпека: Багатокористувацькі системи повинні забезпечувати ізоляцію та безпеку даних для різних клієнтів.
- Обслуговування: Багатокористувацькі системи легше обслуговувати та оновлювати централізовано.
Приклад: Постачальник SaaS використовує багатокористувацьку архітектуру для обслуговування декількох клієнтів з одного екземпляра програмного забезпечення, забезпечуючи економічну ефективність і централізоване управління.
Дотримуючись цих принципів і розуміючи ці концепції, ми можемо розробити архітектуру даних, яка відповідає вимогам сучасного бізнес-середовища, будучи при цьому масштабованою, надійною та економічно ефективною.
Ключові патерни архітектури даних
Протягом десятиліть в архітектурі даних сформувалося кілька ключових патернів, необхідних для ефективного управління та використання даних. Кожен патерн має свої сильні та слабкі сторони, а також ідеальні випадки використання. У цій статті я коротко розгляну ці патерни, щоб проілюструвати, як і де їх можна застосувати в різних контекстах.
1. Сховища даних
Сховища даних – це централізовані репозиторії, призначені для зберігання структурованих даних для звітності та аналізу. Вони оптимізовані для виконання запитів і агрегації даних, що робить їх ідеальними для додатків бізнес-аналітики.
Характеристики:
- Централізоване сховище: Зберігає дані з декількох джерел в одному місці.
- Структуровані дані: Дані є високоорганізованими і, як правило, відповідають певній схемі.
- Оптимізовано для аналітики: Призначений для швидкого створення запитів і пошуку даних.
Переваги:
- Висока продуктивність: Оптимізовано для складних запитів та аналізу даних.
- Інтеграція даних: Консолідує дані з різних джерел, надаючи єдине уявлення.
- Узгодженість: Забезпечує якість та узгодженість даних завдяки застосуванню схем.
Приклади використання:
- Бізнес-аналітика та звітність
- Аналіз історичних даних
- Консолідація даних з декількох систем
Приклад: Компанія, що займається роздрібною торгівлею, використовує хмарне сховище даних, наприклад, Amazon Redshift, для аналізу даних про продажі в різних регіонах і створення детальних звітів для прийняття бізнес-рішень.
2. Озера даних
Озера даних зберігають величезні обсяги необроблених, неструктурованих і напівструктурованих даних. На відміну від сховищ даних, озера даних не накладають на дані сувору схему, що забезпечує більшу гнучкість у прийомі та зберіганні даних.
Характеристики:
- Зберігання сирих даних: Зберігає дані у власному форматі.
- Масштабованість: Може обробляти великі обсяги даних.
- Схема при зчитуванні: схема застосовується при зчитуванні даних, а не при їх збереженні.
Переваги:
- Гнучкість: Може зберігати різні типи даних, включаючи структуровані, неструктуровані та напівструктуровані дані.
- Масштабованість: Підходить для роботи з великими обсягами даних.
- Економічна ефективність: Часто дешевше зберігати великі обсяги даних порівняно зі сховищами даних.
Виклики:
- Управління даними: Без належного управління озера даних можуть перетворитися на інформаційні болота.
- Продуктивність: Продуктивність запитів може бути нижчою порівняно зі сховищами даних.
Приклади використання:
- Аналітика великих даних
- Машинне навчання та наука про дані
- Зберігання даних журналів та подій
Приклад: Медичний заклад використовує озеро даних для зберігання записів про пацієнтів, медичних зображень і даних з датчиків, що дозволяє проводити комплексний аналіз і дослідження.
3. Сучасний стек даних
Сучасний стек даних – це набір модульних хмарних інструментів, які полегшують інтеграцію, трансформацію, зберігання та аналіз даних. Цей підхід наголошує на гнучкості, масштабованості та простоті використання.
Компоненти:
- Поглинання даних: Інструменти на кшталт Fivetran або Stitch для вилучення та завантаження даних.
- Трансформація даних: Інструменти, такі як dbt (інструмент побудови даних) для перетворення даних у сховищі.
- Зберігання даних: Хмарні сховища даних, такі як Snowflake або Google BigQuery.
- Візуалізація даних: Інструменти на кшталт Looker, Tableau або Mode для дослідження та візуалізації даних.
Переваги:
- Модульність: Гнучкі компоненти, які можна легко замінити або модернізувати.
- Масштабованість: Хмарні рішення, які масштабуються залежно від обсягу даних та їх використання.
- Простота використання: Зручні інтерфейси та автоматизація зменшують потребу в глибоких технічних знаннях.
Приклади використання:
- Швидке розгортання рішень для аналізу даних
- Гнучке управління даними та їх трансформація
- Самостійна аналітика та звітність
Приклад: Технологічний стартап використовує сучасний стек даних для швидкого налаштування інфраструктури даних, інтегруючи дані з різних SaaS-додатків, трансформуючи їх за допомогою dbt та візуалізуючи інсайти за допомогою Looker.
4. Уніфіковані пакетні та потокові архітектури
Уніфіковані архітектури для пакетної та потокової обробки даних мають на меті обробляти як дані в реальному часі, так і пакетні дані в єдиному фреймворку. Такий підхід спрощує конвеєр обробки даних і зменшує складність, пов’язану з управлінням окремими системами для пакетних і потокових даних.
Ключова архітектура:
- Лямбда-архітектура: Поєднує пакетну та потокову обробку, розділяючи потоки даних на окремі шляхи.
- Каппа-архітектура: Спрощує лямбда-архітектуру, розглядаючи всі дані як потоки.
Lambda Architecture:
- Пакетний шар: Обробляє великі обсяги історичних даних.
- Швидкісний рівень: Обробляє дані в реальному часі для отримання миттєвих інсайтів.
- Обслуговуючий рівень: Об’єднує результати з пакетного та швидкісного шарів для отримання уніфікованих результатів.
Переваги:
- Комплексна обробка даних: Обробляє як історичні дані, так і дані в реальному часі.
- Відмовостійкість: Забезпечує точність даних завдяки пакетній обробці.
Виклики:
- Складність: Керування окремими системами пакетної та потокової передачі може бути складним завданням.
Kappa Architecture:
- Уніфікована обробка потоків: Розглядає всі дані як потоки, спрощуючи архітектуру.
- Переробка: Дозволяє переробляти потоки даних для історичного аналізу.
Переваги:
- Простота: Зменшує складність завдяки використанню єдиної моделі обробки даних.
- Гнучкість: Легше керувати та масштабувати.
Приклад: Фінансова компанія використовує Apache Kafka для потокової передачі даних в реальному часі та Apache Flink для уніфікованої пакетної та потокової обробки, що дозволяє їм обробляти транзакції в реальному часі та виконувати історичний аналіз на одній платформі даних.
5. Data Lakehouse
Озерне сховище даних поєднує в собі особливості озер даних і сховищ даних, забезпечуючи гнучкість озера даних з продуктивністю і можливостями управління сховища даних.
Характеристики:
- Уніфіковане сховище: Зберігає як структуровані, так і неструктуровані дані.
- ACID-транзакції: Підтримує атомарність, узгодженість, ізоляцію та довговічність операцій з даними.
- Впровадження схеми: Дозволяє схему при читанні та схему при записі.
Переваги:
- Гнучкість: Може працювати з різними типами даних і робочими навантаженнями.
- Продуктивність: Оптимізовано для високопродуктивних запитів і керування даними.
- Управління даними: Забезпечує надійне управління даними та функції управління.
Приклади використання:
- Єдина аналітика даних та звітність
- Машинне навчання та робочі навантаження ШІ
- Обробка даних у реальному часі та пакетна обробка даних
Приклад: Медіа-компанія використовує сховище даних для зберігання та аналізу потокових даних, взаємодії з клієнтами та метаданих контенту, що дозволяє надавати персоналізовані рекомендації та інсайти.
6. Data Mesh
Data mesh – це децентралізований підхід до архітектури даних, який застосовує принципи доменно-орієнтованого проектування для управління даними. Це перехід від централізованого озера даних або сховища до більш розподіленої моделі, де право власності та відповідальність за дані узгоджуються з конкретними бізнес-доменами.
Характеристики:
- Орієнтований на домен: Дані управляються доменом, який знає їх найкраще.
- Дані як продукт: Кожен домен ставиться до своїх даних як до продукту, забезпечуючи якість і зручність використання.
- Інфраструктура самообслуговування даних: Надає необхідні інструменти та платформи, що дозволяють доменам самостійно керувати своїми даними.
- Федеративне управління: Централізована політика та стандарти впроваджуються децентралізовано.
Переваги:
- Масштабованість: Дозволяє організаціям масштабувати свою архітектуру даних у міру зростання бізнесу.
- Спритність: Дозволяє швидше та гнучкіше керувати даними та аналізувати їх.
- Власність: Сприяє володінню даними та підзвітності в межах доменів.
Приклади використання:
- Великі організації з різноманітними потребами в даних
- Компанії, які прагнуть покращити управління даними та їхню якість
- Організації, які прагнуть масштабувати свою інфраструктуру обробки даних
Приклад: Транснаціональна корпорація впроваджує масив даних для управління даними в різних відділах, таких як маркетинг, продажі та фінанси, що дозволяє кожному відділу обробляти свої дані, дотримуючись при цьому загальної політики управління.
7. Data Fabric
Data fabric – це архітектурний підхід, який створює єдине середовище даних, об’єднуючи розрізнені джерела даних і додатки в локальних і хмарних середовищах. Він спрямований на забезпечення безперешкодного доступу та інтеграції даних, забезпечуючи узгоджене управління даними та управління ними.
Характеристики:
- Уніфікований доступ: Забезпечує єдину точку доступу до всіх джерел даних.
- Інтеграція: Об’єднує різні середовища даних, забезпечуючи переміщення та інтеграцію даних.
- Автоматизація: Використовує штучний інтелект і машинне навчання для автоматизації завдань управління даними.
- Управління: Забезпечує якість, безпеку та відповідність даних у всьому ландшафті даних.
Переваги:
- Узгодженість: Забезпечує узгодженість даних в організації.
- Ефективність: Зменшує кількість даних та спрощує доступ до них.
- Спритність: Сприяє швидкій інтеграції та переміщенню даних.
Приклади використання:
- Організації з гібридними середовищами даних
- Компанії, які прагнуть покращити інтеграцію та управління даними
- Компанії, які потребують забезпечення управління даними та дотримання нормативних вимог
Приклад: Фінансова установа використовує структуру даних для інтеграції даних з локальних баз даних і хмарних додатків, забезпечуючи єдине уявлення для регуляторної звітності та бізнес-аналітики.
Додаткові ресурси
- «Відокремлення корисності від доданої вартості» Росс Петтіт
- «Шість принципів сучасної архітектури даних» Джошуа Клар
- Веб-сторінка Snowflake «Що таке архітектура сховища даних»
- «Інфраструктура програмного забезпечення 2.0: Список бажань» Ерік Бернхардссон
- «Залишаючись попереду інформаційного боргу», Етай Мізрахі
- «Тактика проти стратегії: SOA і тарпіт іррелевантності» Ніл Форд
- «Якість тестових даних при масштабуванні за допомогою Deequ», Дастін Ланге та ін.
- «Трирівнева архітектура» від IBM Education
- Веб-сайт «TOGAF framework»
- «Топ-5 трендів даних для ОКУ, на які слід звернути увагу у 2021 році» від Prukalpa
- «240 таблиць і жодної документації?», Олексій Махоткін
- «Кінцевий контрольний список спостережуваності даних» Моллі Ворверк (Molly Vorwerck)
- «Об’єднана аналітика: Де об’єднуються пакетна та потокова обробка; SQL і не тільки» Apache Flink Roadmap
- «Корисність vs стратегічна дихотомія», Мартін Фаулер
- «Що таке сховище даних?», Бен Лоріка та ін.
- «Що таке архітектура даних? Фреймворк для управління даними», Тор Олавсруд
- «Що таке екосистема відкритих даних і чому вона має залишитися», Касбер Ванг
- «Що не так з MLOps?», Ласло Срагнер
- «Що таке сітка даних», Кріс Ріккоміні
- «Кому потрібен архітектор» Мартіна Фаулера
- «Фреймворк Закмана» сторінка у Вікіпедії
- «Будівельні блоки сучасної платформи даних» від Prukalpa
- «Як перейти від монолітного озера даних до розподіленої сітки даних», Жамак Дехгані
- «Принципи Data Mesh та логічна архітектура», Жамак Дехгані
- «Короткий вступ до двох архітектур обробки даних – Lambda та Kappa для великих даних», Іман Самізаде
- «Принципова інженерія даних, частина I: Огляд архітектури» Хуссейн Даніш
- «Журнал: Що кожен інженер-програміст повинен знати про об’єднуючу абстракцію даних у реальному часі», Джей Крепс
Ось деякі з ресурсів, з якими я ознайомився під час написання цієї статті. Вони можуть надати вам більше інформації та поглибити ваше розуміння концепцій та найкращих практик в архітектурі даних.
Підбиваємо підсумки
У цьому дописі блогу я виклав деякі з основних принципів архітектури даних, з якими я зіткнувся під час навчання, і коротко обговорив ключові патерни архітектури даних.
Розуміючи ці детальні патерни архітектури даних, ми можемо приймати обґрунтовані рішення про те, яка архітектура найкраще відповідає потребам організації та як її ефективно впровадити.
Будь ласка, дайте мені знати, якщо моє розуміння будь-якого принципу або архітектури є хибним, я буду радий дізнатися.
ОРИГІНАЛ СТАТТІ:Data Architecture : A Brief Overview
АВТОР СТАТІ:Jayant Nehra
🚀Долучайтесь до нашої спільноти Telegram:
🚀Долучайтесь до нашої спільноти FaceBook:
🚀Долучайтесь до нашої спільноти Twiter X: