Wyjaśnienie semantycznego domku nad jeziorem

Opublikowane ponownie przez Plato

Obserwuje: 0

Jeziora danych i warstwy semantyczne istnieją od dawna – każdy mieszka we własnych, otoczonych murem ogrodach, ściśle powiązanych z dość wąskimi przypadkami użycia. Wraz z migracją infrastruktury danych i analiz do chmury wiele osób zastanawia się, jak te podstawowe komponenty technologiczne pasują do nowoczesnego stosu danych i analiz. W tym artykule przyjrzymy się, w jaki sposób data lakehouse i warstwa semantyczna razem wywracają do góry nogami tradycyjną relację między data lakes a infrastrukturą analityczną. Dowiemy się, jak semantyczny domek nad jeziorem może znacznie uprościć architektury danych w chmurze, wyeliminuj niepotrzebne przenoszenie danych i skróć czas do uzyskania wartości oraz koszty chmury.

Tradycyjna architektura danych i analiz

W 2006 roku Amazon wprowadził Amazon Web Services (AWS) jako nowy sposób przeniesienia lokalnego centrum danych do chmury. Podstawową usługą AWS był magazyn danych plików, a wraz z nim narodziło się pierwsze jezioro danych w chmurze, Amazon S3. Później inni dostawcy usług chmurowych wprowadziliby własne wersje infrastruktury jezior danych w chmurze.

Przez większość swojego życia jezioro danych w chmurze odgrywało rolę głupiego, taniego przechowywanie danych - a inscenizacja obszar dla surowych danych, dopóki dane nie będą mogły zostać przetworzone w coś użytecznego. W przypadku analityki jezioro danych służyło jako magazyn danych, dopóki nie można ich było skopiować i załadować do zoptymalizowanej platformy analitycznej, zwykle relacyjnej hurtowni danych w chmurze, która dostarcza albo kostki OLAP, albo zastrzeżone wyciągi danych z narzędzi analizy biznesowej (BI), takie jak Tableau Hyper lub Power BI Premium lub wszystkie powyższe. W wyniku tego schematu przetwarzania dane musiały być przechowywane co najmniej dwukrotnie, raz w postaci nieprzetworzonej i raz w formie „zoptymalizowanej pod kątem analityki”.

Nic dziwnego, że większość tradycyjnych architektur analityki w chmurze wygląda jak na poniższym diagramie:

*Obraz 1: Tradycyjny stos danych i analiz*

Jak widać, „hurtownia analityczna” odpowiada za większość funkcji dostarczających analitykę konsumentom. Problem z tą architekturą jest następujący:

Dane są przechowywane dwukrotnie, co zwiększa koszty i powoduje złożoność operacyjną.
Dane w magazynie analitycznym to migawka, co oznacza, że dane są natychmiast nieaktualne.
Dane w magazynie analitycznym są zazwyczaj podzbiorem danych w jeziorze danych, co ogranicza liczbę pytań, które mogą zadawać konsumenci.
Magazyn analityczny skaluje się oddzielnie i inaczej niż platforma danych w chmurze, co wiąże się z dodatkowymi kosztami, problemami z bezpieczeństwem i złożonością operacyjną.

Biorąc pod uwagę te wady, możesz zapytać: „Dlaczego architekci danych w chmurze wybrali ten wzorzec projektowy?” Odpowiedź leży w wymaganiach konsumentów analityki. Chociaż jezioro danych mogłoby teoretycznie obsługiwać zapytania analityczne bezpośrednio dla konsumentów, w praktyce jest ono zbyt wolne i niekompatybilne z popularnymi narzędziami analitycznymi.

Gdyby tylko jezioro danych mogło dostarczać korzyści z hurtowni analitycznej i moglibyśmy uniknąć podwójnego przechowywania danych!

Narodziny Data Lakehouse

Termin „Lakehouse” zadebiutował w 2020 roku wraz z przełomową białą księgą Databricks „Co to jest domek nad jeziorem?” autorstwa Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia i Ali Ghodsi. Autorzy przedstawili pomysł, aby jezioro danych mogło służyć jako silnik do dostarczania analiz, a nie tylko statyczny magazyn plików.

Dostawcy usługi Data Lakehouse zrealizowali swoją wizję, wprowadzając szybkie, skalowalne silniki zapytań, które działają na nieprzetworzonych plikach danych w usłudze Data Lake i udostępniają standardowy interfejs SQL ANSI. Dzięki tej kluczowej innowacji zwolennicy tej architektury argumentują, że jeziora danych mogą zachowywać się jak hurtownie analityczne, bez potrzeby powielania danych.

Okazuje się jednak, że hurtownia analityczna pełni inne ważne funkcje, których nie spełnia sama architektura data lakehouse, w tym:

Dostarczanie zapytań z „szybkością myślenia” (zapytania w mniej niż 2 sekundy) konsekwentnie w szerokim zakresie zapytań.
Prezentacja przyjaznej dla biznesu warstwy semantycznej, która pozwala konsumentom zadawać pytania bez konieczności pisania SQL.
Stosowanie ładu i bezpieczeństwa danych w czasie zapytania.

Tak więc, aby data lakehouse rzeczywiście zastąpiło hurtownię analityczną, potrzebujemy czegoś innego.

Rola warstwy semantycznej

Dużo pisałem o roli tzw warstwa semantyczna w nowoczesnym stosie danych. Podsumowując, warstwa semantyczna to logiczny widok danych biznesowych, który wykorzystuje technologię wirtualizacji danych do przekształcania danych fizycznych na dane przyjazne dla biznesu w czasie wykonywania zapytania.

Dodając platformę warstwy semantycznej do jeziora danych, możemy całkowicie wyeliminować funkcje hurtowni analitycznej, ponieważ platforma warstwy semantycznej:

Zapewnia „szybkość przemyślanych zapytań” w Data Lakehouse dzięki wirtualizacji danych i zautomatyzowanemu dostrajaniu wydajności zapytań.
Zapewnia przyjazną dla biznesu warstwę semantyczną, która zastępuje zastrzeżone widoki semantyczne wbudowane w każde narzędzie BI i umożliwia użytkownikom biznesowym zadawanie pytań bez konieczności pisania zapytań SQL.
Zapewnia zarządzanie danymi i bezpieczeństwo w czasie zapytania.

Platforma warstwy semantycznej dostarcza brakujące elementy, których brakuje w Data Lakehouse. Łącząc warstwę semantyczną z jeziorem danych, organizacje mogą:

Wyeliminuj kopie danych i uprość potoki danych.
Skonsoliduj zarządzanie danymi i bezpieczeństwo.
Zapewnij „pojedyncze źródło prawdy” dla wskaźników biznesowych.
Zmniejsz złożoność operacyjną, przechowując dane w jeziorze danych.
Zapewnij dostęp do większej ilości danych i bardziej aktualnych danych konsumentom analiz.

*Obraz 2: Nowy stos Data Lakehouse z warstwą semantyczną*

Semantyczny Lakehouse: Wszyscy wygrywają

Z tą architekturą wszyscy wygrywają. Konsumenci uzyskują dostęp do bardziej szczegółowych danych bez opóźnień. Zespoły IT i inżynierii danych mają mniej danych do przenoszenia i przekształcania. Finanse wydają mniej pieniędzy na koszty infrastruktury chmurowej.

Jak widać, łącząc warstwę semantyczną z jeziorem danych, organizacje mogą uprościć swoje operacje związane z danymi i analizami oraz dostarczać więcej danych, szybciej, większej liczbie konsumentów przy niższych kosztach.