The Semantic Lakehouse Explained

Republicat de Platon

Urmaritori: 0

Lacuri de date și straturi semantice există de mult timp – fiecare trăiește în propriile grădini cu ziduri, strâns cuplate cu cazuri de utilizare destul de înguste. Pe măsură ce infrastructura de date și analiză migrează în cloud, mulți provoacă modul în care aceste componente tehnologice de bază se potrivesc în stiva modernă de date și analize. În acest articol, ne vom scufunda în modul în care un lac de date și un strat semantic schimbă împreună relația tradițională dintre lacurile de date și infrastructura de analiză. Vom învăța cum se poate simplifica în mod dramatic un lac semantic arhitecturi de date cloud, eliminați mișcarea inutilă a datelor și reduceți timpul de generare a valorii și costurile cloud.

Arhitectura tradițională de date și analiză

În 2006, Amazon a introdus Amazon Web Services (AWS) ca o nouă modalitate de a descărca centrul de date on-premise în cloud. Un serviciu de bază AWS a fost depozitul său de date de fișiere și odată cu acesta, s-a născut primul lac de date în cloud, Amazon S3. Alți furnizori de cloud își vor introduce propriile versiuni ale infrastructurii cloud data lake ulterior.

Pentru cea mai mare parte a vieții sale, lacul de date cloud a fost retrogradat să joace rolul de prost, ieftin stocare a datelor - A înscenare zonă pentru date brute, până când datele ar putea fi procesate în ceva util. Pentru analiză, lacul de date a servit ca un stilou de stocare pentru date până când a putut fi copiat și încărcat într-o platformă de analiză optimizată, de obicei un depozit de date relațional în cloud, care alimenta fie cuburi OLAP, extrase de date ale instrumentelor de business intelligence (BI), precum Tableau Hyper sau Power BI Premium sau toate cele de mai sus. Ca rezultat al acestui tipar de procesare, datele trebuiau stocate de cel puțin două ori, o dată în forma sa brută și o dată în forma sa „optimizată pentru analiză”.

Deloc surprinzător, majoritatea arhitecturilor tradiționale de analiză în cloud arată ca diagrama de mai jos:

*Imaginea 1: Stack tradițional de date și analize*

După cum puteți vedea, „depozitul de analiză” este responsabil pentru majoritatea funcțiilor care furnizează analize consumatorilor. Problema cu această arhitectură este următoarea:

Datele sunt stocate de două ori, ceea ce crește costurile și creează complexitate operațională.
Datele din depozitul de analize sunt un instantaneu, ceea ce înseamnă că datele sunt instantaneu învechite.
Datele din depozitul de analize sunt de obicei un subset al datelor din lacul de date, ceea ce limitează întrebările pe care consumatorii le pot pune.
Depozitul de analiză se scalează separat și diferit de platforma de date cloud, introducând costuri suplimentare, preocupări de securitate și complexitate operațională.

Având în vedere aceste dezavantaje, ați putea să vă întrebați „De ce ar alege arhitecții de date în cloud acest model de design?” Răspunsul constă în cerințele consumatorilor de analize. În timp ce lacul de date ar putea, teoretic, să servească interogări analitice direct consumatorilor, în practică, lacul de date este prea lent și incompatibil cu instrumentele de analiză populare.

Dacă lacul de date ar putea oferi beneficiile unui depozit de analiză și am putea evita stocarea datelor de două ori!

Nașterea Data Lakehouse

Termenul „Lakehouse” și-a văzut debutul în 2020, cu lucrarea albă Databricks „Ce este un Lakehouse?” de Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia și Ali Ghodsi. Autorii au introdus ideea că lacul de date ar putea servi ca un motor pentru furnizarea de analize, nu doar un depozit de fișiere static.

Furnizorii de data lakehouse și-au îndeplinit viziunea introducând motoare de interogare scalabile, de mare viteză, care funcționează pe fișiere de date brute din data lake și expun o interfață SQL standard ANSI. Cu această inovație cheie, susținătorii acestei arhitecturi susțin că lacurile de date se pot comporta ca un depozit de analiză, fără a fi nevoie de duplicarea datelor.

Cu toate acestea, se dovedește că depozitul de analiză îndeplinește și alte funcții vitale care nu sunt satisfăcute numai de arhitectura data Lakehouse, inclusiv:

Furnizarea de interogări „viteza gândirii” (interogări în mai puțin de 2 secunde) în mod constant pentru o gamă largă de interogări.
Prezentarea unui strat semantic prietenos pentru afaceri, care permite consumatorilor să pună întrebări fără a fi nevoie să scrie SQL.
Aplicarea guvernanței și securității datelor la momentul interogării.

Deci, pentru ca un lac de date să înlocuiască cu adevărat depozitul de analiză, avem nevoie de altceva.

Rolul stratului semantic

Am scris multe despre rolul lui stratul semantic în stiva modernă de date. Pentru a rezuma, un strat semantic este o vedere logică a datelor de afaceri care folosește tehnologia de virtualizare a datelor pentru a traduce datele fizice în date prietenoase pentru afaceri în momentul interogării.

Adăugând o platformă de strat semantic deasupra unui lac de date, putem elimina complet funcțiile depozitului de analiză deoarece platforma stratului semantic:

Oferă „interogări cu viteză de gândire” în data lakehouse folosind virtualizarea datelor și reglarea automată a performanței interogărilor.
Oferă un strat semantic prietenos pentru afaceri care înlocuiește vederile semantice proprietare care sunt încorporate în fiecare instrument BI și le permite utilizatorilor de afaceri să pună întrebări fără a fi nevoie să scrie interogări SQL.
Oferă guvernanță și securitate a datelor în timpul interogării.

O platformă cu strat semantic furnizează piesele care lipsesc din data Lakehouse. Prin combinarea unui strat semantic cu un lac de date, organizațiile pot:

Eliminați copiile de date și simplificați conductele de date.
Consolidați guvernanța și securitatea datelor.
Oferiți o „sursă unică de adevăr” pentru valorile de afaceri.
Reduceți complexitatea operațională prin păstrarea datelor în lacul de date.
Oferiți acces la mai multe date și date mai oportune consumatorilor de analize.

*Imaginea 2: Noua stivă de date Lakehouse cu un strat semantic*

The Semantic Lakehouse: Toată lumea câștigă

Toată lumea câștigă cu această arhitectură. Consumatorii au acces la date mai precise, fără latență. Echipele IT și de inginerie a datelor au mai puține date de mutat și transformat. Finanțe cheltuiesc mai puțini bani pe costurile infrastructurii cloud.

După cum puteți vedea, combinând un strat semantic cu un lac de date, organizațiile își pot simplifica operațiunile de date și analiză și pot furniza mai multe date, mai rapid, mai multor consumatori, cu costuri mai mici.