Розглядаючи платформи даних, може бути трохи складно розглянути всі доступні сервіси та варіанти архітектури.
Платформа корпоративних даних часто складається зі сховищ даних, моделей даних, озер даних і звітів, кожна з яких має певну мету та набір необхідних навичок. Навпаки, протягом останніх кількох років з’явився новий дизайн під назвою data lakehouse.
Універсальність озер даних і управління даними сховища даних об’єднані в революційну архітектуру зберігання даних, яка отримала назву «озеро даних».
У цій публікації ми детально розглянемо Data Lakehouse, зокрема його компоненти, функції, архітектуру та інші аспекти.
Що таке Data Lakehouse?
Як випливає з назви, сховище даних — це новий тип архітектури даних, який поєднує озеро даних із сховищем даних для вирішення недоліків кожного окремо.
По суті, система lakehouse використовує недороге сховище для підтримки величезних обсягів даних у їхній початковій формі, подібно до озер даних. Додавання рівня метаданих поверх сховища також надає структуру даних і розширює можливості інструментів керування даними, подібних до тих, що є в сховищах даних.
Він зберігає величезні обсяги організованих, напівструктурованих і неструктурованих даних, які вони отримують із різних бізнес-додатків, систем і гаджетів, які використовуються в їхній організації.
У більшості випадків озера даних використовують недорогу інфраструктуру зберігання з інтерфейсом програмування файлів (API) для зберігання даних у відкритих загальних форматах файлів.
Це дає змогу багатьом командам отримувати доступ до всіх даних компанії через єдину систему для різноманітних ініціатив, таких як наука про дані, навчання за допомогою машинита бізнес-розвідка.
риси
- Низька вартість зберігання. Озеро даних повинно мати можливість зберігати дані в недорогому сховищі об’єктів, наприклад Google Cloud Сховище, Azure Blob Storage, Amazon Simple Storage Service або оригінальне використання ORC або Parquet.
- Можливість оптимізації даних: оптимізація макета даних, кешування та індексація – це кілька прикладів того, як озерце даних має бути в змозі оптимізувати дані, зберігаючи вихідний формат даних.
- Рівень транзакційних метаданих: на додачу до основного недорогого сховища це забезпечує можливості керування даними, важливі для продуктивності сховища даних.
- Підтримка API Declarative DataFrame: більшість інструментів AI можуть використовувати DataFrames для отримання необроблених даних зі сховища об’єктів. Підтримка Declarative DataFrame API розширює можливості динамічного вдосконалення представлення даних і структури у відповідь на конкретні завдання науки про дані або штучного інтелекту.
- Підтримка транзакцій ACID: абревіатура ACID, що означає атомарність, послідовність, ізоляція та довговічність, є критично важливим компонентом у визначенні транзакції та забезпеченні узгодженості та надійності даних. Такі транзакції раніше були можливі лише в сховищах даних, але lakehouse пропонує можливість використовувати їх з озерами даних так само. З кількома конвеєрами даних, включаючи одночасне читання та запис даних, це вирішує проблему низької якості останніх даних.
Елементи Data Lakehouse
Архітектура бази даних розділена на два основні рівні на високому рівні. Прийом даних рівня зберігання контролюється платформою Lakehouse (тобто озером даних).
Без необхідності завантажувати дані в сховище даних або перетворювати їх у власний формат, рівень обробки може запитувати дані на рівні зберігання безпосередньо за допомогою низки інструментів.
Тоді програми BI, а також технології AI та ML зможуть використовувати дані. Ця конструкція забезпечує економіку озера даних, але оскільки будь-яка система обробки даних може зчитувати ці дані, підприємства мають свободу робити підготовлені дані доступними для аналізу різними системами. Продуктивність і вартість процесора можна покращити, використовуючи цей метод обробки й аналізу.
Завдяки підтримці транзакцій бази даних, які відповідають наступним критеріям ACID (атомність, послідовність, ізоляція та довговічність), архітектура також дозволяє багатьом сторонам отримувати доступ до даних і записувати їх одночасно в системі:
- Атомність стосується того факту, що або повна транзакція, або жодна з них не вдається під час завершення транзакції. У разі переривання процесу це допомагає уникнути втрати або пошкодження даних.
- консистенція гарантії, що транзакції відбуваються передбачуваним і послідовним чином. Він підтримує цілісність даних, гарантуючи, що всі дані є законними відповідно до заздалегідь визначених правил.
- Ізоляція гарантує, що жодна інша транзакція в системі не може вплинути на жодну транзакцію до її завершення. Це дозволяє багатьом сторонам читати та записувати з однієї системи одночасно, не заважаючи одна одній.
- Міцність гарантує, що зміни в даних у системі продовжують існувати після завершення транзакції, навіть у разі збою системи. Будь-які зміни, спричинені транзакцією, зберігаються у файлі назавжди.
Data Lakehouse Architecture
Databricks (новатор і дизайнер своєї концепції Delta Lake) і AWS є двома головними прихильниками концепції data lakehouse. Таким чином, ми будемо покладатися на їхні знання та проникливість, щоб описати архітектурний план озерних будинків.
Система озер даних зазвичай має п’ять рівнів:
- Проковтування шару
- Шар зберігання
- Рівень метаданих
- Рівень API
- Споживчий шар
Проковтування шару
Перший рівень системи відповідає за збір даних із різних джерел і надсилання їх на рівень зберігання. Рівень може використовувати кілька протоколів для підключення до численних внутрішніх і зовнішніх джерел, включаючи комбінування можливостей пакетної та потокової обробки даних, таких як
- бази даних NoSQL,
- файлообмінники
- CRM програми,
- веб-сайти,
- датчики IoT,
- соціальні мережі
- програмне забезпечення як послуга (SaaS), а також
- системи управління реляційними базами даних тощо.
На цьому етапі можна використовувати такі компоненти, як Apache Kafka для потокової передачі даних і Amazon Data Migration Service (Amazon DMS) для імпорту даних із RDBMS і баз даних NoSQL.
Шар зберігання
Архітектура Lakehouse призначена для забезпечення зберігання різних типів даних як об’єктів у недорогих сховищах об’єктів, таких як AWS S3. Використовуючи відкриті формати файлів, інструменти клієнта можуть зчитувати ці елементи безпосередньо зі сховища.
Це дає змогу багатьом API і компонентам рівня споживання отримувати доступ до тих самих даних і використовувати їх. Рівень метаданих зберігає схеми для структурованих і напівструктурованих наборів даних, щоб компоненти могли застосовувати їх до даних, коли вони їх читають.
Наприклад, платформу розподіленої файлової системи Hadoop (HDFS) можна використовувати для створення служб хмарного сховища, які розділяють обчислення та локальне зберігання. Lakehouse ідеально підходить для цих послуг.
Рівень метаданих
Рівень метаданих є основним компонентом озерця даних, який відрізняє цей дизайн. Це єдиний каталог, який пропонує метадані (інформацію про інші частини даних) для всіх елементів, що зберігаються в озері, і дозволяє користувачам використовувати такі можливості адміністрування, як:
- Послідовна версія бази даних відображається в одночасних транзакціях завдяки транзакціям ACID;
- кешування для збереження файлів сховища хмарних об’єктів;
- додавання індексів структури даних за допомогою індексації для прискорення обробки запитів;
- використання клонування без копіювання для дублювання об’єктів даних; і
- для зберігання певних версій даних тощо, використовуйте керування версіями даних.
Крім того, рівень метаданих дає змогу реалізувати керування схемами, використовувати топологію схем DW, як-от схеми зірка/сніжинка, а також надавати можливість керування даними та аудиту безпосередньо в озері даних, підвищуючи цілісність усього конвеєра даних.
Функції для еволюції схеми та примусового виконання включені до керування схемою. Відхиляючи будь-які записи, які не відповідають схемі таблиці, застосування схеми дозволяє користувачам підтримувати цілісність і якість даних.
Еволюція схеми дозволяє модифікувати поточну схему таблиці відповідно до мінливих даних. Завдяки єдиному інтерфейсу адміністрування на вершині озера даних також є можливості контролю доступу та аудиту.
Рівень API
Тепер присутній ще один важливий рівень архітектури, який містить кілька API, які всі кінцеві користувачі можуть використовувати для швидшого виконання завдань і отримання більш складної статистики.
Використання API метаданих полегшує ідентифікацію та доступ до елементів даних, необхідних для певної програми.
Що стосується бібліотек машинного навчання, то деякі з них, наприклад TensorFlow і Spark MLlib, можуть читати відкриті формати файлів, такі як Parquet, і отримувати прямий доступ до рівня метаданих.
У той же час API DataFrame пропонують більше шансів для оптимізації, дозволяючи програмістам організовувати та змінювати розрізнені дані.
Споживчий шар
Power BI, Tableau та інші інструменти та програми розміщені на рівні споживання. Завдяки дизайну lakehouse усі метадані та всі дані, які зберігаються в озері, доступні для клієнтських програм.
Lakehouse може використовуватися всіма користувачами в компанії для виконання всіх видів аналітичні операції, включаючи створення інформаційних панелей бізнес-аналітики та виконання запитів SQL і завдань машинного навчання.
Переваги Data Lakehouse
Організації можуть створити базу даних, щоб уніфікувати свою поточну платформу даних і оптимізувати весь процес керування даними. Завдяки демонтажу силосних бар’єрів, що з’єднують різні джерела, резервуар даних може замінити потребу в окремих рішеннях.
Порівняно з підібраними джерелами даних ця інтеграція забезпечує значно ефективнішу наскрізну процедуру. Це має кілька переваг:
- Менше адміністрування: Замість того, щоб отримувати дані з необроблених даних і готувати їх для використання в сховищі даних, озеро даних дозволяє будь-яким джерелам, пов’язаним з ним, мати свої дані доступними та організованими для використання.
- Підвищення економічної ефективності: Лакехауси даних побудовані з використанням сучасної інфраструктури, яка розділяє обчислення та зберігання, що спрощує розширення сховища без збільшення обчислювальної потужності. Лише використання недорогого сховища даних призводить до економічно ефективної масштабованості.
- Краще управління даними: Лакехауси даних побудовані зі стандартизованою відкритою архітектурою, що забезпечує більше контролю над безпекою, показниками, доступом на основі ролей та іншими важливими компонентами керування. Об’єднуючи ресурси та джерела даних, вони спрощують і покращують управління.
- Спрощені стандарти: Оскільки зв’язок був дуже обмежений у 1980-х роках, коли вперше були розроблені сховища даних, стандарти локалізованих схем часто розроблялися всередині компаній, навіть відділів. Лакехаузи даних використовують той факт, що багато типів даних тепер мають відкриті стандарти для схеми, поглинаючи численні джерела даних уніфікованою схемою, що накладається, для спрощення процедур.
Недоліки Data Lakehouse
Незважаючи на всю галас навколо data lakehouses, важливо мати на увазі, що ця ідея все ще дуже нова. Обов’язково зважте недоліки, перш ніж повністю присвятити себе новому дизайну.
- Монолітна конструкція: Комплексний дизайн будинків на озері пропонує кілька переваг, але також викликає деякі проблеми. Монолітна архітектура часто призводить до поганого обслуговування для всіх користувачів і може бути жорсткою та важкою в обслуговуванні. Як правило, архітекторам і дизайнерам подобається більш модульна архітектура, яку вони можуть налаштувати для різних випадків використання.
- Технологія ще не зовсім готова: кінцева мета передбачає значну кількість машинного навчання та штучного інтелекту. Перш ніж будинки на озері зможуть працювати, як передбачається, ці технології повинні розвиватися далі.
- Незначний прогрес порівняно з існуючими структурами: Все ще існує значний скептицизм щодо того, наскільки більше цінності озерних будинків насправді внесуть. Деякі противники стверджують, що конструкція озера-складу в поєднанні з відповідним автоматизованим обладнанням може досягти порівнянної ефективності.
Виклики Data Lakehouse
Може бути складно застосувати техніку data lakehouse. Через складність його компонентів неправильно розглядати базу даних як всеохоплюючу ідеальну структуру або, наприклад, «одну платформу для всього».
Крім того, у зв’язку з дедалі більшим впровадженням озер даних підприємствам доведеться перенести туди свої поточні сховища даних, покладаючись лише на обіцянку успіху без видимої економічної вигоди.
Якщо під час процесу передачі виникають проблеми із затримкою або збої, це може виявитися дорогим, трудомістким і, можливо, небезпечним.
Бізнес-користувачі повинні використовувати вузькоспеціалізовані технології, згідно з певними постачальниками, які прямо чи неявно продають рішення як бази даних. Вони можуть не завжди працювати з іншими інструментами, пов’язаними з озером даних у центрі системи, що додає проблем.
Крім того, може бути важко забезпечити цілодобову аналітику під час виконання критично важливих для бізнесу робочих навантажень, для чого потрібна інфраструктура з економічно ефективною масштабованістю.
Висновок
Найновішим різновидом дата-центрів останніх років є data lakehouse. Він об’єднує різноманітні галузі, такі як інформаційні технології, програмне забезпечення з відкритим кодом, хмарних обчисленьі протоколи розподіленого зберігання.
Це дозволяє підприємствам централізовано зберігати всі типи даних з будь-якого місця, спрощуючи керування та аналіз. Data Lakehouse — досить інтригуюча концепція.
Будь-яка фірма мала б значну конкурентну перевагу, якби мала доступ до комплексної платформи даних, яка була б такою ж швидкою та ефективною, як сховище даних, а також гнучкою, як озеро даних.
Ідея все ще розвивається і залишається відносно новою. У результаті може знадобитися деякий час, щоб визначити, чи може щось стати масовим.
Нам усім має бути цікаво, в якому напрямку рухається архітектура Lakehouse.
залишити коментар