Dit kan 'n bietjie moeilik wees om al die beskikbare dienste en argitektoniese opsies te oorweeg wanneer jy aan dataplatforms dink.
'n Ondernemingsdataplatform bestaan dikwels uit datapakhuise, datamodelle, datamere en verslae, elk met 'n spesifieke doel en stel vaardighede wat benodig word. Daarteenoor het 'n nuwe ontwerp genaamd die data-meerhuis gedurende die laaste paar jaar na vore gekom.
Die veelsydigheid van data-mere en datapakhuis-databestuur word gekombineer in 'n revolusionêre databergingsargitektuur wat 'n "datameerhuis" genoem word.
Ons sal data-meerhuis in diepte in hierdie pos ondersoek, insluitend die komponente, kenmerke, argitektuur en ander aspekte daarvan.
Wat is Data Lakehouse?
Soos die naam aandui, is 'n data-meerhuis 'n nuwe tipe data-argitektuur wat 'n datameer met 'n datapakhuis kombineer om die tekortkominge van elkeen afsonderlik op te los.
In wese gebruik die meerhuisstelsel goedkoop berging om groot hoeveelhede data in hul oorspronklike vorm te onderhou, net soos datamere. Die byvoeging van die metadatalaag bo-op die winkel gee ook datastruktuur en bemagtig databestuurnutsmiddels soos dié wat in datapakhuise voorkom.
Dit stoor die enorme volumes georganiseerde, semi-gestruktureerde en ongestruktureerde data wat hulle kry van die verskillende besigheidstoepassings, -stelsels en -toestelle wat regdeur hul organisasie gebruik word.
Die meeste van die tyd gebruik data-mere laekoste-berging-infrastruktuur met 'n lêertoepassingsprogrammeringskoppelvlak (API) om data in oop, generiese lêerformate te stoor.
Dit maak dit vir baie spanne moontlik om toegang te verkry tot al die maatskappydata deur 'n enkele stelsel vir 'n verskeidenheid inisiatiewe, soos datawetenskap, machine learning, en sake-intelligensie.
Kenmerke
- Laekoste berging. 'n Datameerhuis moet data in goedkoop voorwerpberging kan stoor, soos Google Wolk Berging, Azure Blob-berging, Amazon Simple Storage Service, of oorspronklik met behulp van ORC of Parket.
- Vermoë vir data-optimalisering: Data-uitlegoptimalisering, cache en indeksering is 'n paar voorbeelde van hoe 'n datameerhuis in staat moet wees om die data te optimaliseer terwyl die data se oorspronklike formaat behou word.
- ’n Laag transaksionele metadata: Benewens die noodsaaklike laekosteberging, maak dit databestuurvermoëns moontlik wat noodsaaklik is vir datapakhuisprestasie.
- Ondersteuning vir die Verklarende DataFrame API: Die meerderheid KI-nutsgoed kan DataFrames gebruik om rou objekstoordata te herwin. Ondersteuning vir Verklarende DataFrame API verhoog die vermoë om die data se aanbieding en struktuur dinamies te verbeter in reaksie op spesifieke datawetenskap of KI-taak.
- Ondersteuning vir ACID-transaksies: Die akroniem ACID, wat staan vir atomiteit, konsekwentheid, isolasie en duursaamheid, is 'n kritieke komponent in die definisie van 'n transaksie en om die konsekwentheid en betroubaarheid van data te verseker. Sulke transaksies was voorheen net moontlik in datapakhuise, maar die lakehouse bied die opsie om dit met data-mere te gebruik ook. Met verskeie datapyplyne wat gelyktydige data lees en skryf, los dit die probleem van lae datakwaliteit van laasgenoemde op.
Elemente van Data Lakehouse
Die argitektuur van die datameerhuis is op 'n hoë vlak in twee hoofvlakke verdeel. Die stoorlaag se data-inname word beheer deur die Lakehouse-platform (dws die datameer).
Sonder dat dit nodig is om die data in 'n datapakhuis te laai of dit in 'n eie formaat om te skakel, kan die verwerkingslaag dan die data in die stoorlaag direk navraag doen deur 'n reeks gereedskap te gebruik.
Dan kan BI-toepassings, sowel as KI- en ML-tegnologie, die data gebruik. Die ekonomie van 'n datameer word deur hierdie ontwerp verskaf, maar omdat enige verwerkingsenjin hierdie data kan lees, het besighede die vryheid om die voorbereide data toeganklik te maak vir ontleding deur 'n reeks stelsels. Verwerkerprestasie en koste kan beide verbeter word deur hierdie metode vir verwerking en analise te gebruik.
As gevolg van sy ondersteuning vir databasistransaksies wat aan die volgende ACID (atomisiteit, konsekwentheid, isolasie en duursaamheid) kriteria voldoen, stel die argitektuur ook baie partye in staat om toegang tot data te verkry en gelyktydig binne die stelsel te skryf:
- atomiciteit verwys na die feit dat óf die volle transaksie óf niks daarvan, slaag terwyl 'n transaksie voltooi word nie. In die geval dat 'n proses onderbreek word, help dit om dataverlies of korrupsie te voorkom.
- Konsekwentheid waarborg dat transaksies op 'n voorspelbare, konsekwente wyse plaasvind. Dit handhaaf die integriteit van die data deur te verseker dat elke data wettig is in ooreenstemming met voorafbepaalde reëls.
- Isolasie verseker dat, totdat dit voltooi is, geen transaksie deur enige ander transaksie binne die stelsel beïnvloed kan word nie. Dit laat talle partye toe om gelyktydig vanaf dieselfde stelsel te lees en te skryf sonder om met mekaar in te meng.
- Duursaamheid waarborg dat veranderinge aan die data in 'n stelsel bly bestaan nadat 'n transaksie voltooi is, selfs in die geval van 'n stelselfout. Enige veranderings wat deur 'n transaksie teweeggebring word, word vir ewig op lêer gehou.
Data Lakehouse-argitektuur
Databricks (die innoveerder en ontwerper van hul Delta Lake-konsep) en AWS is die twee vernaamste voorstanders vir die konsep van 'n datameerhuis. Ons sal dus op hul kennis en insig staatmaak om die argitektoniese uitleg van meerhuise te beskryf.
'n Datameerhuisstelsel sal tipies vyf lae hê:
- Inname laag
- Berging laag
- Metadatalaag
- API-laag
- Verbruik laag
Inname laag
Die stelsel se eerste laag is in beheer van die insameling van data uit verskeie bronne en stuur dit na die bergingslaag. Die laag kan verskeie protokolle gebruik om aan talle interne en eksterne bronne te koppel, insluitend die kombinasie van bondel- en stroomdataverwerkingsvermoëns, soos
- NoSQL databasisse,
- lêeraandele
- CRM toepassings,
- webtuistes,
- IoT-sensors,
- sosiale media,
- Sagteware as 'n diens (SaaS) toepassings, en
- relasionele databasisbestuurstelsels, ens.
Op hierdie stadium kan komponente soos Apache Kafka vir datastroom en Amazon Data Migration Service (Amazon DMS) vir die invoer van data vanaf RDBMS'e en NoSQL-databasisse gebruik word.
Berging laag
Die lakehouse-argitektuur is bedoel om die berging van verskeie tipes data moontlik te maak as voorwerpe in goedkoop voorwerpwinkels, soos AWS S3. Deur oop lêerformate te gebruik, kan die kliëntnutsgoed dan hierdie items direk vanaf die winkel lees.
Dit maak dit vir baie API's en verbruikslaagkomponente moontlik om toegang tot dieselfde data te verkry en te gebruik. Die metadatalaag stoor die skemas vir gestruktureerde en semi-gestruktureerde datastelle sodat die komponente dit op die data kan toepas terwyl hulle dit lees.
Die Hadoop Distributed File System (HDFS)-platform kan byvoorbeeld gebruik word om wolkbewaardienste te bou wat rekenaars en berging op die perseel verdeel. Lakehouse is ideaal vir hierdie dienste.
Metadatalaag
Die metadatalaag is die fundamentele komponent van 'n datameerhuis wat hierdie ontwerp onderskei. Dit is 'n enkele katalogus wat metadata (inligting oor ander datastukke) bied vir alle items wat in die meer gestoor is en gebruikers in staat stel om administrasievermoëns te gebruik soos:
- 'n Konsekwente weergawe van die databasis word gesien deur gelyktydige transaksies danksy ACID-transaksies;
- kas om wolkvoorwerpstoorlêers te stoor;
- byvoeging van datastruktuurindekse deur gebruik te maak van indeksering om navraagverwerking te bespoedig;
- die gebruik van nulkopie-kloning om data-objekte te dupliseer; en
- om sekere weergawes van die data, ens. te stoor, gebruik dataweergawe.
Boonop maak die metadatalaag die implementering van skemabestuur moontlik, die gebruik van DW-skematopologieë soos ster-/sneeuvlokskemas, en die verskaffing van databeheer- en ouditvermoë direk op die datameer, wat die integriteit van die hele datapyplyn verbeter.
Kenmerke vir skema-evolusie en afdwinging is ingesluit in skemabestuur. Deur enige skryfstukke te verwerp wat nie aan die tabel se skema voldoen nie, stel skema-afdwinging gebruikers in staat om data-integriteit en kwaliteit te handhaaf.
Skema-evolusie laat toe dat die tabel se huidige skema gewysig kan word om veranderende data te akkommodeer. As gevolg van 'n enkele administrasie-koppelvlak bo-op die datameer, is daar ook toegangsbeheer en ouditeringsmoontlikhede.
API-laag
Nog 'n belangrike laag van die argitektuur is nou teenwoordig, wat 'n aantal API's huisves wat alle eindgebruikers kan gebruik om take vinniger te verrig en meer gesofistikeerde statistieke te kry.
Die gebruik van metadata-API's maak dit makliker om die data-items wat nodig is vir 'n gegewe toepassing te identifiseer en toegang te verkry.
Wat masjienleerbiblioteke betref, kan sommige van hulle, soos TensorFlow en Spark MLlib, oop lêerformate soos Parquet lees en direk toegang tot die metadatalaag verkry.
Terselfdertyd bied DataFrame API's groter kanse vir optimalisering, wat programmeerders in staat stel om verspreide data te organiseer en te verander.
Verbruik laag
Power BI, Tableau en ander nutsgoed en toepassings word onder die verbruikslaag gehuisves. Met die Lakehouse-ontwerp is al die metadata en al die data wat in 'n meer gehou word, toeganklik vir die kliënttoepassings.
Die meerhuis kan deur alle gebruikers binne 'n maatskappy gebruik word om allerhande soorte uit te voer analitiese bedrywighede, insluitend die skep van besigheidsintelligensie-kontroleskerms en die uitvoer van SQL-navrae en masjienleertake.
Voordele van Data Lakehouse
Organisasies kan 'n data-meerhuis skep om hul huidige dataplatform te verenig en hul hele databestuursproses te optimaliseer. Deur die silo-versperrings wat verskeie bronne verbind, uitmekaar te haal, kan 'n datameerhuis die behoefte aan duidelike oplossings vervang.
In vergelyking met saamgestelde databronne, lewer hierdie integrasie 'n aansienlik meer effektiewe end-tot-end-prosedure. Dit het verskeie voordele:
- Minder administrasie: Eerder as om data uit rou data te onttrek en dit voor te berei vir gebruik binne 'n datapakhuis, laat 'n datameerhuis enige bronne wat daaraan gekoppel is, toe om hul data beskikbaar en georganiseer te hê vir gebruik.
- Verhoogde koste-effektiwiteit: Datameerhuise word gebou met behulp van kontemporêre infrastruktuur wat berekening en berging verdeel, wat dit maklik maak om berging uit te brei sonder om rekenaarkrag te verhoog. Net die gebruik van goedkoop databerging lei tot skaalbaarheid wat koste-effektief is.
- Beter databestuur: Datameerhuise word gebou met gestandaardiseerde oop argitektuur, wat meer beheer oor sekuriteit, metrieke, rolgebaseerde toegang en ander belangrike bestuurskomponente moontlik maak. Deur hulpbronne en databronne te verenig, vereenvoudig en verbeter dit bestuur.
- Vereenvoudigde standaarde: Aangesien die verbinding hoogs beperk was in die 1980's, toe datapakhuise die eerste keer ontwikkel is, is gelokaliseerde skemastandaarde gereeld binne besighede, selfs departemente, ontwikkel. Datameerhuise maak gebruik van die feit dat baie tipes data nou oop standaarde vir skema het deur talle databronne met die oorvleuelende eenvormige skema in te neem om prosedures te stroomlyn.
Nadele van Data Lakehouse
Ten spyte van al die hoopla rondom datameerhuise, is dit belangrik om in gedagte te hou dat die idee nog baie nuut is. Maak seker dat u die nadele opweeg voordat u ten volle tot hierdie nuwe ontwerp verbind.
- Monolitiese struktuur: 'n Lakehouse se alles-insluitende ontwerp bied verskeie voordele, maar dit bring ook 'n paar probleme. Monolitiese argitektuur lei dikwels tot swak diens vir alle gebruikers en kan rigied en moeilik wees om in stand te hou. Tipies hou argitekte en ontwerpers van 'n meer modulêre argitektuur wat hulle vir verskillende gebruiksgevalle kan aanpas.
- Die tegnologie is nog nie heeltemal daar nie: die finale doelwit behels 'n aansienlike hoeveelheid masjienleer en kunsmatige intelligensie. Voordat meerhuise kan presteer soos beoog, moet hierdie tegnologieë verder ontwikkel.
- Nie 'n beduidende vordering bo bestaande strukture nie: Daar is steeds aansienlike skeptisisme oor hoeveel meer waarde meerhuise werklik sal bydra. Sommige teenstanders voer aan dat 'n meerpakhuisontwerp, gepaard met die toepaslike outomatiese toerusting, vergelykbare doeltreffendheid kan bereik.
Uitdagings van Data Lakehouse
Dit kan moeilik wees om die data lakehouse-tegniek aan te neem. As gevolg van die ingewikkeldheid van sy komponente, is dit verkeerd om die datameerhuis as 'n allesomvattende ideale struktuur of "een platform vir alles" vir een te beskou.
Boonop, as gevolg van die toenemende aanvaarding van data-mere, sal besighede hul huidige datapakhuise na hulle moet skuif, en slegs staatmaak op 'n belofte van sukses met geen aantoonbare ekonomiese voordeel nie.
As daar enige vertragingsprobleme of onderbrekings gedurende die oordragproses is, kan dit duur, tydrowend en dalk onveilig wees.
Besigheidsgebruikers moet hoogs gespesialiseerde tegnologieë omhels, volgens sekere verskaffers wat uitdruklik of implisiet oplossings as datameerhuise bemark. Dit werk dalk nie altyd saam met ander nutsgoed wat aan die datameer in die middel van die stelsel gekoppel is nie, wat bydra tot die probleme.
Boonop kan dit moeilik wees om 24/7-ontledings te verskaf terwyl besigheidskritiese werkladings uitgevoer word, wat infrastruktuur met kostedoeltreffende skaalbaarheid vereis.
Gevolgtrekking
Die nuutste verskeidenheid datasentrums die afgelope paar jaar is die datameerhuis. Dit integreer 'n verskeidenheid velde, soos inligtingstegnologie, oopbronsagteware, cloud computing, en verspreide stoorprotokolle.
Dit stel besighede in staat om alle datasoorte vanaf enige plek sentraal te stoor, wat bestuur en ontleding vereenvoudig. Data Lakehouse is 'n redelik intrige konsep.
Enige firma sou 'n beduidende mededingende voordeel hê as dit toegang het tot 'n alles-in-een-dataplatform wat so vinnig en doeltreffend soos 'n datapakhuis was, terwyl dit ook so buigsaam soos 'n datameer was.
Die idee ontwikkel steeds en bly relatief nuut. Gevolglik kan dit 'n rukkie neem om te bepaal of iets wydverspreid kan raak of nie.
Ons behoort almal nuuskierig te wees oor die rigting wat Lakehouse-argitektuur inslaan.
Lewer Kommentaar