Det kan være lidt svært at overveje alle de tilgængelige tjenester og arkitektoniske muligheder, når man tænker på dataplatforme.
En virksomhedsdataplatform består ofte af datavarehuse, datamodeller, datasøer og rapporter, hver med et specifikt formål og et sæt af nødvendige færdigheder. I modsætning hertil er et nyt design kaldet datasøhuset dukket op i løbet af de sidste par år.
Alsidigheden af data lakes og data warehouse data management er kombineret i en revolutionerende datalagringsarkitektur kaldet et "data lakehouse".
Vi vil undersøge data Lakehouse i dybden i dette indlæg, herunder dets komponenter, funktioner, arkitektur og andre aspekter.
Hvad er Data Lakehouse?
Som navnet antyder, er et datalakehouse en ny type dataarkitektur, der kombinerer en datasø med et datavarehus for at løse manglerne ved hver enkelt.
I det væsentlige bruger lakehouse-systemet billig lagring til at vedligeholde enorme mængder data i deres originale former, ligesom datasøer. Tilføjelse af metadatalaget oven på butikken giver også datastruktur og giver datastyringsværktøjer som dem, der findes i datavarehuse.
Det gemmer de enorme mængder af organiserede, semistrukturerede og ustrukturerede data, som de får fra de forskellige forretningsapplikationer, systemer og gadgets, der bruges i hele deres organisation.
Størstedelen af tiden bruger datasøer billig lagringsinfrastruktur med en filapplikationsprogrammeringsgrænseflade (API) til at gemme data i åbne, generiske filformater.
Dette gør det muligt for mange teams at få adgang til alle virksomhedens data gennem et enkelt system til en række initiativer, såsom data science, machine learningog business intelligence.
Funktionalitet
- Lavpris opbevaring. Et datasøhus skal kunne opbevare data i billigt objektlager, som f.eks Google Cloud Storage, Azure Blob Storage, Amazon Simple Storage Service eller indbygget brug af ORC eller Parket.
- Mulighed for dataoptimering: Datalayoutoptimering, caching og indeksering er et par eksempler på, hvordan et datasøhus skal være i stand til at optimere dataene og samtidig bevare dataens originale format.
- Et lag af transaktionsmetadata: Ud over den essentielle lavprislagring muliggør dette datastyringsfunktioner, der er afgørende for datavarehusets ydeevne.
- Understøttelse af Declarative DataFrame API: De fleste AI-værktøjer kan bruge DataFrames til at hente rå objektlagerdata. Understøttelse af Declarative DataFrame API øger muligheden for dynamisk at forbedre dataens præsentation og struktur som svar på en bestemt datavidenskab eller AI-opgave.
- Understøttelse af ACID-transaktioner: Akronymet ACID, som står for atomicitet, konsistens, isolation og holdbarhed, er en kritisk komponent til at definere en transaktion og sikre dataenes konsistens og pålidelighed. Sådanne transaktioner var tidligere kun mulige i datavarehuse, men de lakehouse giver mulighed for at udnytte dem med datasøer såvel. Med flere datapipelines, der inkluderer samtidige datalæsninger og -skrivninger, løser dette problemet med lav datakvalitet for sidstnævnte.
Elementer af Data Lakehouse
Arkitekturen i datasøhuset er opdelt i to hovedlag på et højt niveau. Lagerlagets dataindtag styres af Lakehouse-platformen (dvs. datasøen).
Uden at skulle indlæse dataene i et datavarehus eller konvertere dem til et proprietært format, er behandlingslaget derefter i stand til at forespørge dataene i lagerlaget direkte ved hjælp af en række værktøjer.
Derefter kan BI-apps samt AI- og ML-teknologier bruge dataene. Økonomien ved en datasø er givet af dette design, men fordi enhver behandlingsmotor kan læse disse data, har virksomheder frihed til at gøre de forberedte data tilgængelige for analyse af en række systemer. Processorens ydeevne og omkostninger kan begge forbedres ved at bruge denne metode til behandling og analyse.
På grund af sin understøttelse af databasetransaktioner, der overholder følgende ACID-kriterier (atomicitet, konsistens, isolation og holdbarhed), giver arkitekturen også mange parter mulighed for at få adgang til og skrive data samtidigt i systemet:
- Atomicitet henviser til det faktum, at enten hele transaktionen eller intet af den lykkes, mens en transaktion gennemføres. I tilfælde af at en proces afbrydes, hjælper dette med at undgå datatab eller korruption.
- Sammenhæng garanterer, at transaktioner foregår på en forudsigelig, konsekvent måde. Det opretholder dataenes integritet ved at sikre, at alle data er legitime i overensstemmelse med forudbestemte regler.
- Isolation sikrer, at, indtil den er afsluttet, ingen transaktion kan blive påvirket af nogen anden transaktion i systemet. Dette gør det muligt for adskillige parter at læse og skrive fra det samme system samtidigt uden at forstyrre hinanden.
- Holdbarhed garanterer, at ændringer af data i et system fortsætter med at eksistere efter en transaktion er afsluttet, selv i tilfælde af systemfejl. Eventuelle ændringer forårsaget af en transaktion opbevares for evigt.
Data Lakehouse-arkitektur
Databricks (innovator og designer af deres Delta Lake-koncept) og AWS er de to vigtigste fortalere for konceptet med et datasøhus. Vi vil derfor stole på deres viden og indsigt til at beskrive søhuses arkitektoniske indretning.
Et data Lakehouse-system vil typisk have fem lag:
- Indtagelseslag
- Opbevaringslag
- Metadata lag
- API-lag
- Forbrugslag
Indtagelseslag
Systemets første lag er ansvarlig for at indsamle data fra forskellige kilder og sende dem til lagerlaget. Laget kan bruge flere protokoller til at oprette forbindelse til adskillige interne og eksterne kilder, herunder kombination af batch- og streaming-databehandlingsfunktioner, som f.eks.
- NoSQL databaser,
- fildelinger
- CRM applikationer,
- hjemmesider,
- IoT-sensorer,
- sociale medier,
- Software as a Service (SaaS) applikationer, og
- relationelle databasestyringssystemer mv.
På dette tidspunkt kan komponenter som Apache Kafka til datastreaming og Amazon Data Migration Service (Amazon DMS) til import af data fra RDBMS'er og NoSQL-databaser anvendes.
Opbevaringslag
Lakehouse-arkitekturen er beregnet til at muliggøre lagring af forskellige typer data som objekter i billige objektbutikker, såsom AWS S3. Ved at bruge åbne filformater kan klientværktøjerne derefter læse disse varer direkte fra butikken.
Dette gør det muligt for mange API'er og forbrugslagskomponenter at få adgang til og bruge de samme data. Metadatalaget gemmer skemaerne for strukturerede og semistrukturerede datasæt, så komponenterne kan anvende dem på dataene, mens de læser dem.
Hadoop Distributed File System (HDFS)-platformen kan for eksempel bruges til at konstruere cloud repository-tjenester, der opdeler databehandling og lagring på stedet. Lakehouse er ideelt egnet til disse tjenester.
Metadata lag
Metadatalaget er den grundlæggende komponent i et datasøhus, der adskiller dette design. Det er et enkelt katalog, der tilbyder metadata (information om andre datastykker) for alle elementer, der er gemt i søen og giver brugerne mulighed for at anvende administrationsfunktioner som:
- En konsistent version af databasen ses af samtidige transaktioner takket være ACID-transaktioner;
- caching for at gemme cloud-objektlagerfiler;
- tilføjelse af datastrukturindekser ved hjælp af indeksering for at fremskynde forespørgselsbehandlingen;
- brug af nul-kopi-kloning til at duplikere dataobjekter; og
- for at gemme visse versioner af data osv., skal du bruge dataversionering.
Derudover muliggør metadatalaget implementeringen af skemastyring, brugen af DW-skematopologier som stjerne-/snefnug-skemaer og levering af datastyring og revisionskapacitet direkte på datasøen, hvilket forbedrer integriteten af hele datapipelinen.
Funktioner til skemaudvikling og håndhævelse er inkluderet i skemastyring. Ved at afvise skrivninger, der ikke opfylder tabellens skema, gør skemahåndhævelse det muligt for brugere at opretholde dataintegritet og kvalitet.
Skema-evolution gør det muligt at ændre tabellens nuværende skema for at imødekomme skiftende data. På grund af en enkelt administrationsgrænseflade oven på datasøen er der også adgangskontrol og revisionsmuligheder.
API-lag
Et andet afgørende lag af arkitekturen er nu til stede, som hoster en række API'er, som alle slutbrugere kan bruge til at udføre job hurtigere og få mere sofistikeret statistik.
Brugen af metadata API'er gør det nemmere at identificere og få adgang til de dataelementer, der er nødvendige for en given applikation.
Med hensyn til maskinlæringsbiblioteker kan nogle af dem, såsom TensorFlow og Spark MLlib, læse åbne filformater som Parquet og få direkte adgang til metadatalaget.
Samtidig giver DataFrame API'er større chancer for optimering, hvilket gør det muligt for programmører at organisere og ændre spredte data.
Forbrugslag
Power BI, Tableau og andre værktøjer og apps hostes under forbrugslaget. Med søhusets design er alle metadata og alle data, der opbevares i en sø, tilgængelige for klientapps.
Søhuset kan bruges af alle brugere indenfor en virksomhed til at udføre alle former for analytiske operationer, herunder oprettelse af business intelligence-dashboards og kørsel af SQL-forespørgsler og maskinlæringsopgaver.
Fordele ved Data Lakehouse
Organisationer kan oprette et datasøhus for at forene deres nuværende dataplatform og optimere hele deres datahåndteringsproces. Ved at afmontere silobarriererne, der forbinder forskellige kilder, kan et datasøhus erstatte behovet for særskilte løsninger.
Sammenlignet med kuraterede datakilder giver denne integration en betydeligt mere effektiv end-to-end procedure. Dette har flere fordele:
- Mindre administration: I stedet for at udtrække data fra rådata og forberede dem til brug i et datavarehus, tillader et datasøhus alle kilder, der er knyttet til det, at have deres data tilgængelige og organiseret til brug.
- Øget omkostningseffektivitet: Datasøhuse er konstrueret ved hjælp af moderne infrastruktur, der opdeler beregning og lagring, hvilket gør det nemt at udvide lagring uden at øge computerkraften. Alene brugen af billig datalagring resulterer i skalerbarhed, der er omkostningseffektiv.
- Bedre datastyring: Data Lakehouses er konstrueret med standardiseret åben arkitektur, hvilket giver mulighed for mere kontrol over sikkerhed, metrikker, rollebaseret adgang og andre vigtige administrationskomponenter. Ved at forene ressourcer og datakilder forenkler og forbedrer de styring.
- Forenklede standarder: Da forbindelsen var stærkt begrænset i 1980'erne, da datavarehuse først blev udviklet, blev lokaliserede skemastandarder ofte udviklet i virksomheder, selv afdelinger. Data Lakehouses gør brug af det faktum, at mange typer data nu har åbne standarder for skemaer ved at indtage adskillige datakilder med det overlappende ensartede skema for at strømline procedurer.
Ulemper ved Data Lakehouse
På trods af alt det tumult omkring datasøhuse, er det vigtigt at huske på, at ideen stadig er meget ny. Sørg for at afveje ulemperne, før du forpligter dig fuldt ud til dette nye design.
- Monolitisk struktur: Et søhuss altomfattende design giver flere fordele, men det rejser også nogle problemer. Monolitisk arkitektur fører ofte til dårlig service for alle brugere og kan være stiv og svær at vedligeholde. Typisk kan arkitekter og designere lide en mere modulær arkitektur, som de kan tilpasse til forskellige anvendelsessager.
- Teknologien er der ikke helt endnu: det endelige mål indebærer en betydelig mængde maskinlæring og kunstig intelligens. Før søhuse kan fungere som forventet, skal disse teknologier udvikles yderligere.
- Ikke et væsentligt fremskridt i forhold til eksisterende strukturer: Der er stadig stor skepsis over, hvor meget mere værdi søhuse rent faktisk vil bidrage med. Nogle kritikere hævder, at et sø-lagerdesign parret med det passende automatiserede udstyr kan opnå sammenlignelig effektivitet.
Udfordringer ved Data Lakehouse
Det kan være svært at anvende data Lakehouse-teknikken. På grund af forviklingen af dets komponentdele er det forkert at se datasøhuset som en altomfattende ideel struktur eller "én platform for alt", for én.
På grund af den stigende anvendelse af datasøer bliver virksomheder desuden nødt til at flytte deres nuværende datavarehuse til dem og kun stole på et løfte om succes uden påviselig økonomisk fordel.
Hvis der er nogen latensproblemer eller udfald under overførselsprocessen, kan dette ende med at blive dyrt, tidskrævende og måske usikkert.
Forretningsbrugere skal omfavne højt specialiserede teknologier, ifølge visse leverandører, der udtrykkeligt eller implicit markedsfører løsninger som datasøer. Disse fungerer muligvis ikke altid med andre værktøjer, der er knyttet til datasøen i midten af systemet, hvilket øger problemerne.
Derudover kan det være svært at levere 24/7-analyse, mens du kører forretningskritiske arbejdsbelastninger, hvilket kræver infrastruktur med omkostningseffektiv skalerbarhed.
Konklusion
Det nyeste udvalg af datacentre i de seneste år er data lakehouse. Det integrerer en række forskellige områder, såsom informationsteknologi, open source-software, cloud computing, og distribuerede lagringsprotokoller.
Det gør det muligt for virksomheder at gemme alle datatyper centralt fra ethvert sted, hvilket forenkler administration og analyse. Data Lakehouse er et ret spændende koncept.
Enhver virksomhed ville have en betydelig konkurrencefordel, hvis den havde adgang til en alt-i-en dataplatform, der var lige så hurtig og effektiv som et datavarehus, samtidig med at den var så fleksibel som en datasø.
Idéen er stadig under udvikling og er stadig relativt ny. Som følge heraf kan det tage lidt tid at afgøre, om noget kan blive udbredt eller ej.
Vi burde alle være nysgerrige efter, hvilken retning Lakehouse-arkitekturen er på vej.
Giv en kommentar