A szemantikus tóház magyarázata

Adattavak és szemantikai rétegek már régóta léteznek – mindegyik a saját fallal körülvett kertjében él, szorosan összekapcsolva a meglehetősen szűk használati esetekkel. Ahogy az adat- és elemzési infrastruktúra a felhőbe vándorol, sokan kihívás elé állítják, hogyan illeszkednek ezek az alapvető technológiai összetevők a modern adat- és elemzési halmazba. Ebben a cikkben belemerülünk abba, hogy egy adattóház és egy szemantikai réteg együttesen hogyan fejti fel az adattavak és az elemzési infrastruktúra közötti hagyományos kapcsolatot. Megtanuljuk, hogyan egyszerűsödhet le drámaian egy szemantikus tóház felhő adatarchitektúrák, kiküszöböli a szükségtelen adatmozgatást, és csökkenti az értékteremtési időt és a felhőalapú költségeket.

A hagyományos adat- és elemzési architektúra

2006-ban az Amazon bemutatta az Amazon Web Services (AWS) szolgáltatást, amely a helyszíni adatközpont felhőbe való feltöltésének új módja. Az AWS alapszolgáltatása a fájladattár volt, és ezzel megszületett az első felhőalapú adattó, az Amazon S3. Más felhőszolgáltatók ezt követően bevezetnék a felhőalapú adattó-infrastruktúra saját verzióit.

Életének nagy részében a felhőadat-tó a buta, olcsó szerepét töltötte vissza adattárolás - a színpadra állítás a nyers adatok területét, amíg az adatok hasznossá nem válnak. Az analitika szempontjából a Data Lake az adatok tárolására szolgáló tollként szolgált mindaddig, amíg át nem lehetett másolni és betölteni egy optimalizált analitikai platformba, jellemzően egy relációs felhő adattárházba, amely vagy OLAP-kockákat, vagy saját fejlesztésű üzleti intelligencia (BI) adatkivonatokat, például Tableau Hypert vagy Power BI Premium, vagy a fentiek mindegyike. Ennek a feldolgozási mintának köszönhetően az adatokat legalább kétszer kellett tárolni, egyszer nyers formában, egyszer pedig „analitikailag optimalizált” formában. 

Nem meglepő, hogy a legtöbb hagyományos felhőelemző architektúra az alábbi diagramhoz hasonlóan néz ki:

Amint láthatja, az „analitikai raktár” felelős a fogyasztók számára elemzést szolgáltató funkciók többségéért. A probléma ezzel az architektúrával a következő:

1. Az adatokat kétszer tárolják, ami növeli a költségeket és bonyolultabbá teszi a működést.
2. Az analitikai raktárban lévő adatok pillanatfelvételek, ami azt jelenti, hogy az adatok azonnal elavultak.
3. Az analitikai raktárban lévő adatok jellemzően az adattóban lévő adatok egy részhalmazát képezik, ami korlátozza a fogyasztók által feltehető kérdéseket.
4. Az analitikai raktár a felhőalapú adatplatformtól eltérően skálázódik, ami további költségeket, biztonsági aggályokat és működési összetettséget jelent.

Tekintettel ezekre a hátrányokra, felteheti a kérdést: „Miért választanák a felhőalapú adatok építészei ezt a tervezési mintát?” A válasz az analitikai fogyasztók igényeiben rejlik. Míg a Data Lake elméletileg közvetlenül kiszolgálhatja az analitikai lekérdezéseket a fogyasztóknak, a gyakorlatban a Data Lake túl lassú és nem kompatibilis a népszerű elemző eszközökkel. 

Bárcsak az adattó ki tudná nyújtani az analitikai raktár előnyeit, és elkerülhetnénk az adatok kétszeri tárolását!

A Data Lakehouse születése

A „Lakehouse” kifejezés 2020-ban debütált a Databricks alapvető fehér könyvével. – Mi az a Lakehouse? írta: Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia és Ali Ghodsi. A szerzők bevezették azt az ötletet, hogy az adattó nemcsak statikus fájltárolóként, hanem az elemzések szállításának motorjaként is szolgálhat.

A Data Lakehouse szállítói megvalósították elképzeléseiket a nagy sebességű, méretezhető lekérdezőmotorok bevezetésével, amelyek a Data Lake-ben lévő nyers adatfájlokon dolgoznak, és egy ANSI szabványos SQL interfészt tesznek elérhetővé. Ezzel a kulcsfontosságú újítással az architektúra támogatói azzal érvelnek, hogy az adatforrások analitikai raktárként viselkedhetnek anélkül, hogy szükség lenne az adatok megkettőzésére.

Kiderült azonban, hogy az analitikai raktár más olyan létfontosságú funkciókat is ellát, amelyeket a Data Lakehouse architektúra önmagában nem elégít ki, például:

1. „Gondolatgyorsaságú” lekérdezések (lekérdezések 2 másodperc alatt) következetesen a lekérdezések széles körében.
2. Vállalkozásbarát szemantikai réteg bemutatása, amely lehetővé teszi a fogyasztók számára, hogy kérdéseket tegyenek fel anélkül, hogy SQL-t kellene írniuk.
3. Adatkezelés és adatbiztonság alkalmazása lekérdezéskor.

Tehát ahhoz, hogy egy Data Lakehouse valóban leválthassa az analitikai raktárt, valami másra van szükségünk.

A szemantikai réteg szerepe

Sokat írtam a szerepéről szemantikai réteg a modern adathalmazban. Összefoglalva, a szemantikai réteg az üzleti adatok logikai nézete, amely az adatvirtualizációs technológiát használja fel, hogy lekérdezéskor a fizikai adatokat vállalkozásbarát adatokká alakítsa. 

Ha egy szemantikai réteg platformot adunk egy adattóház tetejére, akkor teljesen megszüntethetjük az analitikai raktár funkciókat, mivel a szemantikus réteg platform:

1. Az adatvirtualizáció és az automatikus lekérdezésteljesítmény-hangolás segítségével „gondolati sebességű lekérdezéseket” biztosít az adattóházban.
2. Vállalkozásbarát szemantikai réteget biztosít, amely felváltja az egyes BI-eszközökbe beágyazott saját szemantikai nézeteket, és lehetővé teszi az üzleti felhasználók számára, hogy kérdéseket tegyenek fel anélkül, hogy SQL-lekérdezéseket kellene írniuk.
3. Adatkezelést és biztonságot nyújt a lekérdezés idején.

Egy szemantikus rétegplatform szállítja azokat a hiányzó részeket, amelyek az adattóházból hiányoznak. Ha egy szemantikai réteget egy adattóházzal kombinálnak, a szervezetek:

1. Az adatmásolatok megszüntetése és az adatfolyamok egyszerűsítése.
2. Konszolidálja az adatkezelést és a biztonságot.
3. Biztosítson „egyetlen igazságforrást” az üzleti mutatók számára.
4. Csökkentse a műveleti bonyolultságot azáltal, hogy az adatokat az adattóban tartja.
5. Hozzáférés biztosítása több adathoz és időszerűbb adatokhoz az elemzési fogyasztók számára.

The Semantic Lakehouse: Mindenki nyer

Ezzel az architektúrával mindenki nyer. A fogyasztók késleltetés nélkül férhetnek hozzá a finomabb adatokhoz. Az informatikai és adatmérnöki csapatok kevesebb adatot tudnak áthelyezni és átalakítani. A pénzügyek kevesebb pénzt költenek a felhő infrastruktúra költségeire. 

Amint látható, egy szemantikai réteg és egy adattóház kombinálásával a szervezetek egyszerűsíthetik adat- és elemzési műveleteiket, és több adatot szállíthatnak gyorsabban, több fogyasztóhoz, kevesebb költséggel.

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. Hozzáférés itt.
• Forrás: https://www.dataversity.net/the-semantic-lakehouse-explained/