It kin in bytsje lestich wêze om alle beskikbere tsjinsten en arsjitektoanyske opsjes te beskôgjen as jo tinke oan gegevensplatfoarms.
In bedriuwsgegevensplatfoarm bestiet faak út gegevenspakhuzen, gegevensmodellen, gegevensmarren en rapporten, elk mei in spesifyk doel en set fan feardigens dy't nedich binne. Yn tsjinstelling, in nij ûntwerp neamd it data lakehouse is ûntstien yn 'e lêste jierren.
De veelzijdigheid fan gegevensmarren en gegevensbehear fan gegevenspakhús wurde kombineare yn in revolúsjonêre arsjitektuer foar gegevensopslach dy't in "gegevensmarehouse" neamd wurdt.
Wy sille gegevens Lakehouse yngeand ûndersykje yn dit post, ynklusyf de komponinten, funksjes, arsjitektuer en oare aspekten.
Wat is Data Lakehouse?
Lykas de namme al fermoeden docht, is in gegevensmarehouse in nij soarte gegevensarsjitektuer dy't in gegevensmar kombinearret mei in gegevenspakhús om de tekoarten fan elk apart op te lossen.
Yn essinsje brûkt it lakehouse-systeem goedkeape opslach om enoarme hoemannichten gegevens yn har orizjinele foarmen te behâlden, krekt as gegevensmarren. It tafoegjen fan de metadatalaach boppe op 'e winkel jout ek gegevensstruktuer en machtigje ark foar gegevensbehear lykas dy fûn yn gegevenspakhuzen.
It bewarret de enoarme folumes fan organisearre, semi-strukturearre en net-strukturearre gegevens dy't se krije fan 'e ferskate saaklike applikaasjes, systemen en gadgets dy't yn har organisaasje wurde brûkt.
De mearderheid fan 'e tiid brûke gegevensmarren goedkeape opslachynfrastruktuer mei in programmearynterface foar bestânapplikaasje (API) om gegevens op te slaan yn iepen, generike bestânsformaten.
Dit makket it mooglik foar in protte teams om tagong te krijen ta alle bedriuwsgegevens fia ien systeem foar in ferskaat oan inisjativen, lykas gegevenswittenskip, masine learen, en saaklike yntelliginsje.
Features
- Lege kosten opslach. In data lakehouse moat by steat wêze om te bewarjen gegevens yn goedkeape objekt opslach, lykas Google Cloud Storage, Azure Blob Storage, Amazon Simple Storage Service, of native gebrûk fan ORC of Parquet.
- Mooglikheid foar gegevensoptimalisaasje: Optimalisaasje fan gegevensyndieling, caching en yndeksearring binne in pear foarbylden fan hoe't in gegevenslaehouse de gegevens moat kinne optimalisearje by it behâld fan it orizjinele formaat fan 'e gegevens.
- In laach fan transaksjonele metadata: Boppe op 'e essensjele opslach mei lege kosten, makket dit mooglikheden foar gegevensbehear mooglik krúsjaal foar prestaasjes fan gegevenspakhús.
- Stipe foar de Declarative DataFrame API: De mearderheid fan AI-ark kin DataFrames brûke om rauwe objektwinkelgegevens op te heljen. Stipe foar Declarative DataFrame API fergruttet de mooglikheid om de presintaasje en struktuer fan 'e gegevens dynamysk te ferbetterjen yn reaksje op bepaalde gegevenswittenskip as AI-taak.
- Stipe foar ACID-transaksjes: It akronym ACID, dat stiet foar atomiteit, konsistinsje, isolaasje en duorsumens, is in krityske komponint by it definiearjen fan in transaksje en it garandearjen fan de konsistinsje en betrouberens fan gegevens. Sokke transaksjes wiene earder allinnich mooglik yn data warehouses, mar de lakehouse biedt de opsje om se te brûken mei gegevensmarren lykas. Mei ferskate gegevenspipelines ynklusyf tagelyk lêzen en skriuwen fan gegevens, lost dit it probleem fan lege gegevenskwaliteit fan 'e lêste op.
Eleminten fan Data Lakehouse
De arsjitektuer fan it data lakehouse is ferdield yn twa haadnivo's op in heech nivo. De gegevensopname fan 'e opslachlaach wurdt regele troch it Lakehouse-platfoarm (dat wol sizze, de gegevensmar).
Sûnder de needsaak om de gegevens yn in gegevenspakhûs te laden of te konvertearjen yn in proprietêr formaat, is de ferwurkingslaach dan yn steat om de gegevens yn 'e opslachlaach direkt te freegjen mei in ferskaat oan ark.
Dan kinne BI-apps, lykas AI- en ML-technologyen, de gegevens brûke. De ekonomy fan in gegevensmar wurdt fersoarge troch dit ûntwerp, mar om't elke ferwurkingsmotor dizze gegevens kin lêze, hawwe bedriuwen de frijheid om de taret gegevens tagonklik te meitsjen foar analyse troch in ferskaat oan systemen. Prozessorprestaasjes en kosten kinne beide wurde ferbettere troch dizze metoade te brûken foar ferwurking en analyse.
Troch syn stipe foar databanktransaksjes dy't har folgje oan 'e folgjende ACID-kritearia (atomiciteit, konsistinsje, isolaasje en duorsumens), stelt de arsjitektuer ek in protte partijen yn steat om tagelyk tagong te krijen en gegevens te skriuwen binnen it systeem:
- Atomisiteit ferwiist nei it feit dat of de folsleine transaksje of net ien dêrfan, slagget by it foltôgjen fan in transaksje. Yn it gefal dat in proses wurdt ûnderbrutsen, helpt dit gegevensferlies of korrupsje te foarkommen.
- Konsistinsje garandearret dat transaksjes op in foarsisbere, konsekwinte manier foarkomme. It behâldt de yntegriteit fan 'e gegevens troch te garandearjen dat elke gegevens legitim is yn oerienstimming mei foarbepaalde regels.
- isolaasje soarget derfoar dat, oant it klear is, gjin transaksje kin wurde beynfloede troch in oare transaksje binnen it systeem. Hjirmei kinne ferskate partijen tagelyk fan itselde systeem lêze en skriuwe sûnder inoar te bemuoien.
- Duorsumens garandearret dat feroarings oan de gegevens yn in systeem bliuwt bestean nei in transaksje is klear, sels yn it gefal fan in systeem flater. Alle feroarings dy't troch in transaksje brocht wurde, wurde foar altyd bewarre.
Data Lakehouse Architecture
Databricks (de fernijer en ûntwerper fan har Delta Lake-konsept) en AWS binne de twa wichtichste foarfjochters foar it konsept fan in datamarehouse. Wy sille dus op har kennis en ynsjoch fertrouwe om de arsjitektoanyske yndieling fan marrenhuzen te beskriuwen.
In data lakehouse-systeem sil typysk fiif lagen hawwe:
- Ingestion laach
- Opslach laach
- Metadata laach
- API laach
- Konsumpsje laach
Ingestion laach
De earste laach fan it systeem is ferantwurdlik foar it sammeljen fan gegevens út ferskate boarnen en it ferstjoeren nei de opslachlaach. De laach kin ferskate protokollen brûke om te ferbinen mei ferskate ynterne en eksterne boarnen, ynklusyf it kombinearjen fan batch- en streaminggegevensferwurkingsmooglikheden, lykas
- NoSQL databases,
- triem oandielen
- CRM applikaasjes,
- websites,
- IoT sensors,
- sosjale media,
- Software as in tsjinst (SaaS) applikaasjes, en
- relasjonele databasebehearsystemen, ensfh.
Op dit punt kinne komponinten lykas Apache Kafka foar gegevensstreaming en Amazon Data Migration Service (Amazon DMS) foar it ymportearjen fan gegevens fan RDBMS's en NoSQL-databases brûkt wurde.
Opslach laach
De lakehouse-arsjitektuer is bedoeld om de opslach fan ferskate soarten gegevens mooglik te meitsjen as objekten yn goedkeape objektwinkels, lykas AWS S3. Mei it brûken fan iepen bestânsformaten kinne de client-ark dizze items dan direkt fan 'e winkel lêze.
Dit makket it mooglik foar in protte API's en komponinten fan konsumpsjelaach om tagong te krijen ta en te brûken deselde gegevens. De metadata-laach bewarret de skema's foar strukturearre en semi-strukturearre datasets, sadat de komponinten se kinne tapasse op de gegevens as se it lêze.
It platfoarm Hadoop Distributed File System (HDFS) kin bygelyks brûkt wurde om tsjinsten foar wolkrepository te konstruearjen dy't komputer en opslach op it terrein splitst. Lakehouse is by útstek geskikt foar dizze tsjinsten.
Metadata laach
De metadatalaach is de fûnemintele komponint fan in data lakehouse dat dit ûntwerp ûnderskiedt. It is in inkele katalogus dy't metadata (ynformaasje oer oare gegevensstikken) biedt foar alle items opslein yn 'e mar en lit brûkers administraasjemooglikheden brûke lykas:
- In konsekwinte ferzje fan de databank wurdt sjoen troch tagelyk transaksjes tank oan ACID transaksjes;
- caching om wolkobjektwinkelbestannen op te slaan;
- it tafoegjen fan datastruktueryndeksen mei yndeksearring om queryferwurking te fersnellen;
- it brûken fan nul-kopy-kloning om gegevensobjekten te duplikearjen; en
- om bepaalde ferzjes fan 'e gegevens op te slaan, ensfh., brûke gegevensferzjebewurking.
Derneist makket de metadata-laach de ymplemintaasje fan skemabehear mooglik, it brûken fan DW-skematopologyen lykas stjer- / snieflokskema's, en it leverjen fan gegevensbestjoer en kontrôlemooglikheden direkt op 'e gegevensmar, wêrtroch't de yntegriteit fan' e heule gegevenspipeline ferbetteret.
Funksjes foar skema-evolúsje en hanthavening binne opnommen yn skemabehear. Troch it ôfwizen fan alle skriuwingen dy't net foldogge oan it skema fan 'e tabel, stelt skema hanthavenjen brûkers yn steat om gegevensintegriteit en kwaliteit te behâlden.
Skema-evolúsje lit it hjoeddeistige skema fan 'e tabel wurde wizige om wikseljende gegevens oan te passen. Troch in inkele administraasje-ynterface boppe op 'e gegevensmar binne d'r ek tagongskontrôle en kontrôlemooglikheden.
API laach
In oare krúsjale laach fan 'e arsjitektuer is no oanwêzich, hosting in oantal API's dy't alle ein brûkers kinne brûke om banen flugger út te fieren en mear ferfine statistiken te krijen.
It brûken fan metadata APIs makket it makliker te identifisearjen en tagong ta de gegevens items nedich foar in opjûne applikaasje.
Wat biblioteken foar masine-learen oanbelanget, kinne guon fan har, lykas TensorFlow en Spark MLlib, iepen bestânsformaten lykas Parquet lêze en direkt tagong krije ta de metadata-laach.
Tagelyk biede DataFrame API's gruttere kânsen foar optimisaasje, wêrtroch programmeurs ferspraat gegevens kinne organisearje en feroarje.
Konsumpsje laach
Power BI, Tableau, en oare ark en apps wurde hosted ûnder de konsumpsjelaach. Mei it lakehouse-ûntwerp binne alle metadata en alle gegevens dy't yn in mar bewarre wurde tagonklik foar de kliïntapps.
De lakehouse kin brûkt wurde troch alle brûkers binnen in bedriuw te fieren allerhanne analytyske operaasjes, ynklusyf it meitsjen fan dashboards foar saaklike yntelliginsje en it útfieren fan SQL-fragen en taken foar masine-learen.
Foardielen fan Data Lakehouse
Organisaasjes kinne in data lakehouse oanmeitsje om har hjoeddeistige gegevensplatfoarm te ferienigjen en har hiele gegevensbehearproses te optimalisearjen. Troch it ûntmanteljen fan de silo-barriêres dy't ferskate boarnen ferbine, kin in datamarehouse de needsaak foar ûnderskate oplossingen ferfange.
Yn ferliking mei curated gegevens boarnen, dizze yntegraasje produsearret in signifikant effektiver end-to-end proseduere. Dit hat ferskate foardielen:
- Minder administraasje: Yn stee fan it ekstrahearjen fan gegevens út rauwe gegevens en tariede se foar gebrûk binnen in gegevens warehouse, in gegevens lakehouse kinne alle boarnen keppele oan it te hawwen harren gegevens beskikber en organisearre foar benutten.
- Ferhege kosten-effektiviteit: Data lakehouses wurde oanlein mei help fan hjoeddeiske ynfrastruktuer dy't dielt berekkening en opslach, wêrtroch't it simpel te wreidzjen opslach sûnder tanimmende computing macht. Allinich it brûken fan goedkeape gegevens opslach resultearret yn skalberens dy't kosten-effektyf is.
- Better gegevensbestjoer: Data lakehouses wurde konstruearre mei standerdisearre iepen arsjitektuer, wêrtroch mear kontrôle oer feiligens, metriken, rol-basearre tagong, en oare wichtige behear komponinten. Troch boarnen en gegevensboarnen te ferienigjen, ferienfâldigje en ferbetterje se bestjoer.
- Simplified noarmen: Sûnt de ferbining wie tige beheind yn de jierren 1980, doe't gegevens warehouses waarden earst ûntwikkele, lokale skema noarmen waarden faak ûntwikkele binnen bedriuwen, sels ôfdielings. Data lakehouses meitsje gebrûk fan it feit dat in protte soarten gegevens no iepen noarmen hawwe foar skema troch it opnimmen fan ferskate gegevensboarnen mei it oerlappende unifoarme skema om prosedueres te streamlynjen.
Neidielen fan Data Lakehouse
Nettsjinsteande alle hoopla omlizzende gegevensmarehouses, is it wichtich om te hâlden dat it idee noch heul nij is. Wês der wis fan dat jo de neidielen weagje foardat jo folslein ynsette foar dit nije ûntwerp.
- Monolityske struktuer: In lakehouse syn all-inclusive design biedt ferskate foardielen, mar it ropt ek wat problemen. Monolityske arsjitektuer liedt faak ta minne tsjinst foar alle brûkers en kin stiif en lestich wêze om te ûnderhâlden. Typysk hâlde arsjitekten en ûntwerpers fan in mear modulêre arsjitektuer dy't se kinne oanpasse foar ferskate gebrûksgefallen.
- De technology is der noch net hielendal: it definitive doel omfettet in signifikante hoemannichte masine learen en keunstmjittige yntelliginsje. Foardat marrenhuzen kinne prestearje lykas foarsjoen, moatte dizze technologyen fierder ûntwikkelje.
- Net in wichtige foarútgong oer besteande struktueren: Der is noch in soad skepsis oer hoefolle mear wearde marrenhuzen sille eins bydrage. Guon detractors beweare dat in mar-pakhúsûntwerp keppele mei de passende automatisearre apparatuer ferlykbere effisjinsje kin berikke.
Útdagings fan Data Lakehouse
It kin lestich wêze om de data lakehouse-technyk oan te nimmen. Fanwegen de yngewikkeldheid fan har ûnderdielen is it ferkeard om it data Lakehouse te besjen as in alles omfiemjende ideale struktuer as "ien platfoarm foar alles", foar ien.
Derneist, fanwegen de tanimmende oanname fan gegevensmarren, sille bedriuwen har hjoeddeistige gegevenspakhuzen nei har moatte ferpleatse, allinich fertrouwe op in belofte fan sukses sûnder oannimlik ekonomysk foardiel.
As d'r wachttiidproblemen of ûnderbrekkingen binne yn it heule oerdrachtproses, kin dit djoer, tiidslinend en miskien ûnfeilich wêze.
Bedriuwsbrûkers moatte heul spesjalisearre technologyen omearmje, neffens bepaalde leveransiers dy't útdruklik as ymplisyt oplossingen as datamarehouses ferkeapje. Dizze wurkje miskien net altyd mei oare ark keppele oan it gegevensmar yn it sintrum fan it systeem, wat taheakket oan de problemen.
Derneist kin it lestich wêze om 24/7-analytyk te leverjen by it útfieren fan saaklike krityske wurkloads, wat freget om ynfrastruktuer mei kosten-effektive skalberens.
Konklúzje
It nijste ferskaat oan datasintra yn 'e lêste jierren is it data lakehouse. It yntegreart in ferskaat oan fjilden, lykas ynformaasjetechnology, iepen boarne software, wolk Computing, en ferspraat opslachprotokollen.
It stelt bedriuwen yn steat om alle gegevenssoarten fan elke lokaasje sintraal op te slaan, wat behear en analyse ferienfâldigje. Data Lakehouse is in aardich yntrigearjend konsept.
Elk bedriuw soe in wichtige konkurrinsjefoardiel hawwe as it tagong hie ta in alles-yn-ien gegevensplatfoarm dat sa rap en effisjint wie as in gegevenspakhús, wylst it ek sa fleksibel wie as in gegevensmar.
It idee is noch yn ûntwikkeling en bliuwt relatyf nij. Dêrtroch kin it wat tiid duorje om te bepalen oft wat al of net wiidferspraat wurde kin.
Wy moatte allegear nijsgjirrich wêze oer de rjochting dy't Lakehouse-arsjitektuer rjochtet.
Leave a Reply