Згідно з Gartner, 80% успішних головних директорів з обробки даних (CDO) до 2021 року мають в статуті створення вартості чи генерації доходів як своє головне завдання № 1.
Для максимізації вартості ландшафту даних організації традиційні архітектурні моделі систем підтримки прийняття рішень вже не є відповідними. Необхідно розробляти нові архітектурні шаблони для використання потужності даних. Для повного використання переваг використання великих обсягів даних підприємствам потрібні гнучкі архітектури даних, які дозволяють отримувати максимальну вартість з їхнього екосистеми даних.
Концепція Озера даних існує вже деякий час. Однак я помітив, що багато організацій мають труднощі з розумінням цієї концепції, оскільки багато з них все ще укладені в старий парадигму Підприємницьких Даних (Enterprise Data Warehouses).
У цій статті я розгляну концептуальні структури патернів архітектури Озера даних і викладу архітектурні шаблони.
Почнемо із відомого:
Традиційна архітектура сховища даних (DWH):
Традиційна архітектура Підприємницького Сховища Даних (DWH/EDW) використовується протягом багатьох років. Існують джерела даних, дані вилучаються, перетворюються і завантажуються (ETL), і в процесі ми проводимо певні види структуризації, очищення тощо. Ми наперед визначаємо модель даних у EDW (розмірна модель або модель 3NF) і потім створюємо відділові data-marts для звітності, OLAP-куби для аналізу та самообслугову BI.
Цей патерн досить поширений і служив нам довгий час.
Проте є деякі вбудовані в цей патерн виклики, які не можуть масштабуватися в епоху Великих Даних. Давайте розглянемо кілька з них:
- По-перше, філософія, з якою ми працюємо, полягає в тому, що нам потрібно спочатку зрозуміти дані. Яка структура системи джерела, які дані вона містить, яка кардинальність, як ми повинні моделювати її на основі бізнес-вимог, чи є аномалії в даних і так далі. Це рутинна і складна робота. Я витрачав принаймні 2-3 місяці на фазу аналізу вимог і аналізу даних. Проекти EDW тривають від кількох місяців до кількох років. І все це ґрунтується на припущенні, що бізнес знає свої вимоги.
- Ми також повинні робити вибори і компроміси щодо того, які дані зберігати і які дані відкидати. Значна кількість часу витрачається спочатку на вирішення питань, що вносити, як вносити, як зберігати, як перетворювати і так далі. Менше часу витрачається на саме виявлення даних, розкриття патернів або створення нових гіпотез для додавання бізнес-вартості.
Поняття Даних (Data Definition)
Давайте тепер коротко обговоримо, як змінилося визначення даних.
Чотири основні характеристики великих даних (4 Vs) вже дуже відомі: обсяг, швидкість, різноманітність і достовірність. Дозвольте мені додати деякий контекст цим поняттям:
- Обсяг даних вибухнув після революції iPhone. Існує 6 мільярдів смартфонів, і щороку створюється майже 1 петабайт даних.
- Дані не лише в стані спокою. Є стрімінгові дані, пристрої, підключені до Інтернету речей (IoT). Велика кількість даних надходить з багатьох напрямів.
- Також важлива різноманітність даних. Відеопотоки, фотографії – це тепер також дані, які вимагають аналізу та використання.
- З вибухом даних також приходить виклик якості даних. Які дані можна довіряти, а які ні, – це великий виклик в світі великих даних(BigData).
Загалом, визначення даних, які можна аналізувати, змінилося. Це вже не лише структуровані корпоративні дані, але всі види даних. Виклик полягає в тому, щоб поєднувати їх разом і зрозуміло аналізувати.
Закон Мура:
З 2000 року відбулися значні зміни в потужності обробки, зберіганні та відповідній структурі витрат. Це підпадає під те, що ми називаємо законом Мура. Основні моменти:
- Потужність обробки зросла приблизно в 10 000 разів з 2000 року. Це означає, що можливість ефективного аналізу більшого обсягу даних зросла.
- Вартість зберігання також значно знизилася. З 2000 року вартість зберігання знизилася більш ніж в 1000 разів.
Аналогія Озера даних (Data Lake):
Дозвольте мені пояснити концепцію Озера даних за допомогою аналогії.
Відвідування великого озера завжди приносить дуже приємні відчуття. Вода в озері знаходиться в своїй найчистішій формі, і на озері різні люди займаються різними видами діяльності. Деякі люди ловлять рибу, деякі насолоджуються поїздкою на човні, а це озеро також постачає питну воду для жителів Онтаріо. Загалом, це саме озеро використовується для різних цілей.
Зі змінами в парадигмі обробки даних виникла нова архітектурна модель. Її називають архітектурою Озера даних. Подібно до води в озері, дані в озері даних знаходяться в найчистішій можливій формі. Так само, як озеро обслуговує потреби різних людей, тих, хто хоче ловити рибу, або тих, хто хоче поїздити на човні, або тих, хто хоче отримувати питну воду з нього, архітектура Озера даних обслуговує різні ролі. Вона надає можливість досліджувати дані та створювати гіпотези для науковців-даних. Вона надає можливість бізнес-користувачам досліджувати дані. Вона надає можливість аналізувати дані та знаходити закономірності для аналітиків даних. Вона надає можливість створювати звіти та представляти їх зацікавленим сторонам аналітикам звітності.
Те, як я порівнюю Озеро даних із Сховищем даних або Даними магазинами, виглядає так:
Озеро даних зберігає дані в найчистішій формі, обслуговує різних зацікавлених сторін та може використовуватися для упаковки даних у формі, яку можна споживати кінцевими користувачами. З іншого боку, Сховище даних вже дистильоване і упаковане для визначених цілей.
Концептуальна архітектура Озера даних:
Після пояснення концепції дозвольте мені розповісти вам про концептуальну архітектуру озера даних. Ось основні компоненти архітектури озера даних. У нас є джерела даних, які можуть бути структурованими і неструктурованими. Вони всі інтегруються у сховище сирих даних, яке споживає дані в найчистішій формі, тобто без жодних перетворень. Це недороге постійне сховище, яке може зберігати дані в масштабах. Потім у нас є аналітична пісочниця, яку використовують для розуміння даних, створення прототипів, проведення досліджень даних і виявлення нових гіпотез та використання.
Потім у нас є механізм пакетної обробки, який обробляє сирі дані в щось, що може бути споживане користувачами, тобто в структуру, яка може бути використана для звітності кінцевим користувачам. Ми називаємо це сховищем оброблених даних. Є також механізм обробки в реальному часі, який бере стрімінгові дані та обробляє їх також. Усі дані в цій архітектурі каталогізуються та піддаються кураторству.
Дозвольте мені розповісти вам про кожну групу компонентів у цій архітектурі.
Лямбда (Lambda):
Перша група компонентів обробляє дані. Вона використовує архітектурний патерн, який називається архітектурою Lambda. Основна ідея архітектури Lambda полягає в тому, що вона використовує два шляхи обробки: пакетний(Batch layer) та швидкісний шар(Speed/Stream Layer). Пакетний шар зберігає дані у найсирішій формі, тобто в сховище сирих даних, а швидкісний шар обробляє дані поблизу реального часу. Швидкісний шар також зберігає дані у сховищі сирих даних і може зберігати тимчасові дані перед завантаженням у сховища оброблених даних.
Аналітичні пісочниці (Sandbox):
Аналітичні пісочниці є одними з ключових компонентів архітектури озера даних. Це області для досліджень для науковців-даних, де вони можуть розробляти та тестувати нові гіпотези, об’єднувати та досліджувати дані для створення нових сценаріїв використання, створювати швидкі прототипи для перевірки цих сценаріїв використання та визначати, як можна видобути вартість для бізнесу.
Це місце, де DataScience можуть відкривати дані, видобувати вартість та допомагати трансформувати бізнес.
Каталогізація та управління(Cataloging and Governance):
Каталогізація даних є важливим принципом, який постійно ігнорується в традиційному бізнес-інтелекті. У сфері великих даних каталогізація є найважливішим аспектом, на який варто звернути увагу. Дозвольте мені спочатку навести аналогію, щоб пояснити, що таке каталогізація. Я проводжу це вправу з моїми клієнтами, щоб донести суть каталогізації.
Коли я питаю своїх клієнтів вгадати можливу вартість картини без надання інформації з каталогу, відповіді варіюються від $100 до $100 000 доларів. Відповідь стає набагато ближчою до реальної, коли я надаю інформацію з каталогу. До речі, ця картина називається “Старий гітарист” Пабло Пікассо, створена в 1903 році. Її оцінювана вартість перевищує $100 мільйонів.
Даний каталог дуже схожий. Різні дані мають різну вартість, і ця вартість залежить від походження даних, якості даних, джерела створення тощо. Дані потрібно каталогізувати, щоб аналітик даних або науковець-данік самостійно могли вирішити, який дані точку використовувати для певного аналізу.
Карта каталогу (Catalog Map):
Карта каталогу надає потенційні метадані, які можна каталогізувати. Каталогізація – це процес збору цінних метаданих, щоб їх можна було використовувати для визначення характеристик даних і прийняття рішення про їх використання чи ні. В основному існують два типи метаданих: бізнесові та технічні. Бізнес-метадані більше пов’язані з визначеннями, логічними моделями даних, логічними сутностями і так далі, тоді як технічні метадані призначені для збору метаданих, пов’язаних з фізичною реалізацією структури даних. Сюди входять такі речі, як база даних, оцінка якості, стовпці, схема і таке інше.
На основі інформації з каталогу аналітик може вибрати конкретну точку даних в відповідному контексті. Дозвольте мені навести приклад. Припустимо, що науковець-даних (DataScience) хоче провести дослідницький аналіз оборотності запасів, як це визначено в системі ERP, але в системі обліку запасів вони різні . Якщо термін внесений до каталогу, то науковець-даних (DataScience) може вирішити використовувати стовпець з системи ERP або з системи обліку запасів в залежності від контексту.
Основна різниця між Озером даних і Сховищем даних підприємства (Data Lake and EDW):
Ось якісний слайд, який намагається пояснити різницю.
По-перше, філософія різна. У архітектурі озера даних ми спершу завантажуємо дані в сиру форму і вирішуємо, що нам з ним робити. У традиційній архітектурі Сховища даних підприємства ми спершу повинні розуміти дані, моделювати їх, а потім завантажувати.
Дані в озері даних зберігаються в сирий формі, в той час як дані в Сховищі даних підприємства зберігаються у вигляді структурованих даних. Пам’ятайте озеро та дистильовану воду.
Озеро даних підтримує всіх видів користувачів.
Проекти аналітики є дійсно гнучкими проектами. Сутність цих проектів полягає в тому, що, якщо ви бачите результат, ви думаєте більше і хочете більше. Озера даних природно гнучкі. Оскільки вони зберігають всі дані з їх каталогами, це гарантує, що в разі виникнення нових вимог їх можна легко адаптувати.
Архітектура озера даних на платформі Azure:
Хмарні платформи найкраще підходять для реалізації архітектури озера даних. Вони мають ряд складових служб, які можна поєднувати між собою, щоб досягти необхідного масштабованості. Складові Cortana Intelligence Suite від Microsoft надають один чи кілька компонентів, які можна використовувати для реалізації архітектури озера даних.
Основні висновки:
- Озеро даних – це нова парадигма для архітектури великих даних.
- Озера даних обслуговують всі види даних, зберігають дані у сирий формі, підтримують різноманітних користувачів та дозволяють отримувати швидкі інсайти.
- Ретельна каталогізація та управління даними є ключовими для успішної реалізації озера даних.
- Хмарні платформи пропонують комплексні рішення для реалізації архітектури озера даних економічним та масштабованим способом.
ОРИГІНАЛ СТАТІ:Demystifying Data Lake Architecture
АВТОРИ СТАТІ: Pradeep Menon
Додавайтесь до нашої спільноти Telegram
ANALYST UA
ANALYST GROUP UA
DATA ENGINEERING UA