Пояснення семантичної Lakehouse

Перевидано Платоном

читають: 0

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

Традиційна архітектура даних і аналітики

У 2006 році Amazon представила Amazon Web Services (AWS) як новий спосіб перенести локальний центр обробки даних у хмару. Основним сервісом AWS було сховище файлових даних, завдяки чому народилося перше хмарне озеро даних Amazon S3. Після цього інші постачальники хмарних технологій представили б власні версії інфраструктури хмарних озер даних.

Протягом більшої частини свого життя хмарне озеро даних відігравало роль тупого, дешевого зберігання даних - a інсценування область для необроблених даних, поки дані не можна буде обробити у щось корисне. Для аналітики озеро даних слугувало пером для зберігання даних, доки їх не можна було скопіювати та завантажити на оптимізовану аналітичну платформу, як правило, реляційне хмарне сховище даних, що живить куби OLAP, витяги даних із власних інструментів бізнес-аналітики (BI), як-от Tableau Hyper або Power BI Premium або все вищезазначене. У результаті цього шаблону обробки дані потрібно було зберігати принаймні двічі, один раз у необробленому вигляді та один раз у «оптимізованому для аналітики» вигляді.

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

*Зображення 1: Традиційний стек даних і аналітики*

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

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

Враховуючи ці недоліки, ви можете запитати: «Чому архітектори хмарних даних обрали цей шаблон проектування?» Відповідь полягає в вимогах споживачів аналітики. Хоча теоретично озеро даних може обслуговувати аналітичні запити безпосередньо споживачам, на практиці озеро даних працює надто повільно та несумісне з популярними інструментами аналітики.

Якби тільки озеро даних могло забезпечити переваги аналітичного сховища, і ми могли б уникнути подвійного зберігання даних!

Народження Data Lakehouse

Термін «Lakehouse» дебютував у 2020 році з основоположним документом Databricks «Що таке Lakehouse?» Бен Лоріка, Майкл Армбраст, Рейнольд Ксін, Матеї Захарія та Алі Годсі. Автори представили ідею про те, що озеро даних може служити механізмом для надання аналітики, а не просто сховищем статичних файлів.

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

Однак виявилося, що аналітичне сховище виконує інші життєво важливі функції, які не задовольняються лише архітектурою озера даних, зокрема:

Постійна доставка запитів «швидкість думки» (запити менш ніж за 2 секунди) для широкого діапазону запитів.
Представлення зручного для бізнесу семантичного рівня, який дозволяє споживачам задавати запитання без необхідності писати SQL.
Застосування керування та безпеки даних під час запиту.

Отже, щоб сховище даних справді замінило аналітичне сховище, нам потрібно щось інше.

Роль семантичного шару

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

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

Забезпечує «швидкість мисленнєвих запитів» у базі даних за допомогою віртуалізації даних і автоматичного налаштування продуктивності запитів.
Забезпечує зручний для бізнесу семантичний рівень, який замінює власні семантичні представлення, вбудовані в кожен інструмент BI, і дозволяє бізнес-користувачам задавати запитання без необхідності писати запити SQL.
Забезпечує керування даними та безпеку під час запиту.

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

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

*Зображення 2: новий стек Data Lakehouse із семантичним рівнем*

Семантичний Lakehouse: Everybody Wins

З такою архітектурою виграють усі. Споживачі отримують доступ до більш детальних даних без затримок. Команди ІТ та інженерів даних мають менше даних для переміщення та трансформації. Фінанси витрачають менше грошей на витрати на хмарну інфраструктуру.

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