Det kan være litt vanskelig å vurdere alle tilgjengelige tjenester og arkitektoniske alternativer når du tenker på dataplattformer.
En bedriftsdataplattform består ofte av datavarehus, datamodeller, datainnsjøer og rapporter, hver med et spesifikt formål og sett med ferdigheter som trengs. Derimot har et nytt design kalt data lakehouse dukket opp i løpet av de siste årene.
Allsidigheten til datainnsjøer og datavarehusdatabehandling er kombinert i en revolusjonerende datalagringsarkitektur kalt et "datalakehouse".
Vi vil undersøke data Lakehouse i dybden i dette innlegget, inkludert dets komponenter, funksjoner, arkitektur og andre aspekter.
Hva er Data Lakehouse?
Som navnet tilsier, er et datainnsjøhus en ny type dataarkitektur som kombinerer en datainnsjø med et datavarehus for å løse manglene til hver enkelt.
I hovedsak bruker lakehouse-systemet rimelig lagring for å opprettholde enorme mengder data i sine opprinnelige former, omtrent som datainnsjøer. Å legge til metadatalaget på toppen av butikken gir også datastruktur og gir dataadministrasjonsverktøy som de som finnes i datavarehus.
Den lagrer de enorme volumene av organiserte, semistrukturerte og ustrukturerte data som de får fra de forskjellige forretningsapplikasjonene, systemene og gadgetene som brukes i hele organisasjonen.
Mesteparten av tiden bruker datainnsjøer rimelig lagringsinfrastruktur med et filapplikasjonsprogrammeringsgrensesnitt (API) for å lagre data i åpne, generiske filformater.
Dette gjør det mulig for mange team å få tilgang til alle bedriftsdataene gjennom ett enkelt system for en rekke initiativer, for eksempel datavitenskap, maskinlæring, og business intelligence.
Egenskaper
- Lavpris lagring. Et datalakehouse må kunne lagre data i rimelig objektlagring, som f.eks Google Cloud Lagring, Azure Blob Storage, Amazon Simple Storage Service eller naturlig bruk av ORC eller Parkett.
- Mulighet for dataoptimalisering: Datalayoutoptimalisering, caching og indeksering er noen få eksempler på hvordan et datainnsjøhus må kunne optimalisere dataene samtidig som dataenes opprinnelige format opprettholdes.
- Et lag med transaksjonsmetadata: I tillegg til den essensielle lavkostnadslagringen, muliggjør dette dataadministrasjonsfunksjoner som er avgjørende for datavarehusytelsen.
- Støtte for Declarative DataFrame API: De fleste AI-verktøy kan bruke DataFrames for å hente rå objektlagerdata. Støtte for Declarative DataFrame API øker muligheten til dynamisk å forbedre dataenes presentasjon og struktur som svar på en bestemt datavitenskap eller AI-oppgave.
- Støtte for ACID-transaksjoner: Akronymet ACID, som står for atomitet, konsistens, isolasjon og holdbarhet, er en kritisk komponent for å definere en transaksjon og sikre konsistensen og påliteligheten til data. Slike transaksjoner var tidligere bare mulig i datavarehus, men lakehouse tilbyr muligheten til å bruke dem med datainnsjøer også. Med flere datapipelines inkludert samtidige datalesing og -skriving, løser dette problemet med lav datakvalitet for sistnevnte.
Elementer av Data Lakehouse
Arkitekturen til datainnsjøhuset er delt inn i to hovednivåer på et høyt nivå. Lagringslagets datainntak kontrolleres av Lakehouse-plattformen (dvs. datainnsjøen).
Uten å måtte laste inn dataene i et datavarehus eller konvertere dem til et proprietært format, kan prosesseringslaget spørre dataene i lagringslaget direkte ved hjelp av en rekke verktøy.
Deretter kan BI-apper, samt AI- og ML-teknologier, bruke dataene. Økonomien til en datainnsjø er gitt av dette designet, men fordi enhver prosesseringsmotor kan lese disse dataene, har bedrifter friheten til å gjøre de forberedte dataene tilgjengelige for analyse av en rekke systemer. Både prosessorytelse og kostnad kan forbedres ved å bruke denne metoden for prosessering og analyse.
På grunn av støtten for databasetransaksjoner som overholder følgende ACID-kriterier (atomisitet, konsistens, isolasjon og holdbarhet), lar arkitekturen også mange parter få tilgang til og skrive data samtidig i systemet:
- Atomisitet refererer til det faktum at enten hele transaksjonen eller ingenting av den, lykkes mens en transaksjon fullføres. I tilfelle en prosess blir avbrutt, bidrar dette til å unngå tap av data eller korrupsjon.
- Konsistens garanterer at transaksjoner skjer på en forutsigbar, konsistent måte. Den opprettholder integriteten til dataene ved å sikre at alle data er legitime i samsvar med forhåndsbestemte regler.
- Isolasjon sikrer at ingen transaksjoner kan påvirkes av andre transaksjoner i systemet frem til den er fullført. Dette gjør at mange parter kan lese og skrive fra samme system samtidig uten å forstyrre hverandre.
- Holdbarhet garanterer at endringer i dataene i et system fortsetter å eksistere etter at en transaksjon er fullført, selv i tilfelle systemfeil. Eventuelle endringer forårsaket av en transaksjon lagres for alltid.
Data Lakehouse-arkitektur
Databricks (innovatøren og designeren av deres Delta Lake-konsept) og AWS er de to viktigste talsmennene for konseptet med et datainnsjøhus. Vi skal derfor stole på deres kunnskap og innsikt for å beskrive den arkitektoniske utformingen av innsjøhus.
Et datainnsjøsystem vil typisk ha fem lag:
- Svelgingslag
- Lagringslag
- Metadatalag
- API-lag
- Forbrukslag
Svelgingslag
Systemets første lag er ansvarlig for å samle inn data fra ulike kilder og sende dem til lagringslaget. Laget kan bruke flere protokoller for å koble til en rekke interne og eksterne kilder, inkludert å kombinere batch- og streamingdatabehandlingsfunksjoner, som f.eks.
- NoSQL-databaser,
- fildelinger
- CRM-applikasjoner,
- nettsteder,
- IoT-sensorer,
- sosiale medier,
- Software as a Service (SaaS)-applikasjoner, og
- styringssystemer for relasjonsdatabaser, etc.
På dette tidspunktet kan komponenter som Apache Kafka for datastrømming og Amazon Data Migration Service (Amazon DMS) for import av data fra RDBMS-er og NoSQL-databaser brukes.
Lagringslag
Lakehouse-arkitekturen er ment å muliggjøre lagring av ulike typer data som objekter i rimelige objektlagre, slik som AWS S3. Ved å bruke åpne filformater kan klientverktøyene deretter lese disse varene direkte fra butikken.
Dette gjør det mulig for mange APIer og forbrukslagskomponenter å få tilgang til og bruke de samme dataene. Metadatalaget lagrer skjemaene for strukturerte og semistrukturerte datasett slik at komponentene kan bruke dem på dataene mens de leser dem.
Hadoop Distributed File System (HDFS)-plattformen kan for eksempel brukes til å konstruere skydepottjenester som deler databehandling og lagring på stedet. Lakehouse er ideelt egnet for disse tjenestene.
Metadatalag
Metadatalaget er den grunnleggende komponenten i et datainnsjøhus som skiller dette designet. Det er en enkelt katalog som tilbyr metadata (informasjon om andre datadeler) for alle elementer som er lagret i innsjøen og lar brukere bruke administrasjonsfunksjoner som:
- En konsistent versjon av databasen ses av samtidige transaksjoner takket være ACID-transaksjoner;
- caching for å lagre skyobjektlagerfiler;
- legge til datastrukturindekser ved å bruke indeksering for å øke hastigheten på spørringsbehandlingen;
- bruk av kloning uten kopier for å duplisere dataobjekter; og
- for å lagre visse versjoner av dataene, etc., bruk dataversjon.
I tillegg muliggjør metadatalaget implementering av skjemaadministrasjon, bruk av DW-skjematopologier som stjerne-/snøfnuggskjemaer, og levering av datastyring og revisjonsevne direkte på datasjøen, noe som forbedrer integriteten til hele datapipelinen.
Funksjoner for skjemautvikling og håndhevelse er inkludert i skjemaadministrasjon. Ved å avvise skrivinger som ikke oppfyller tabellens skjema, gjør skjemahåndhevelse det mulig for brukere å opprettholde dataintegritet og kvalitet.
Skjemaevolusjon gjør at tabellens nåværende skjema kan modifiseres for å imøtekomme endrede data. På grunn av et enkelt administrasjonsgrensesnitt på toppen av datasjøen, er det også tilgangskontroll og revisjonsmuligheter.
API-lag
Et annet viktig lag av arkitekturen er nå til stede, som er vert for en rekke APIer som alle sluttbrukere kan bruke for å utføre jobber raskere og få mer sofistikert statistikk.
Bruken av metadata-APIer gjør det lettere å identifisere og få tilgang til dataelementene som trengs for en gitt applikasjon.
Når det gjelder maskinlæringsbiblioteker, kan noen av dem, som TensorFlow og Spark MLlib, lese åpne filformater som Parquet og få direkte tilgang til metadatalaget.
Samtidig gir DataFrame API-er større muligheter for optimalisering, og gjør det mulig for programmerere å organisere og endre spredte data.
Forbrukslag
Power BI, Tableau og andre verktøy og apper er vert under forbrukslaget. Med lakehouse-designet er alle metadataene og alle dataene som lagres i en innsjø tilgjengelig for klientappene.
Lakehouse kan brukes av alle brukere i en bedrift til å utføre alle slags analytiske operasjoner, inkludert å lage business intelligence-dashboard og kjøre SQL-spørringer og maskinlæringsoppgaver.
Fordeler med Data Lakehouse
Organisasjoner kan opprette et datainnsjø for å forene deres nåværende dataplattform og optimalisere hele databehandlingsprosessen. Ved å demontere silobarrierene som forbinder ulike kilder, kan et datainnsjøhus erstatte behovet for distinkte løsninger.
Sammenlignet med kurerte datakilder gir denne integrasjonen en betydelig mer effektiv ende-til-ende-prosedyre. Dette har flere fordeler:
- Mindre administrasjon: I stedet for å trekke ut data fra rådata og forberede dem for bruk i et datavarehus, lar et datainnsjøhus alle kilder som er koblet til det, ha dataene sine tilgjengelige og organisert for bruk.
- Økt kostnadseffektivitet: Datainnsjøhus er konstruert ved hjelp av moderne infrastruktur som deler beregning og lagring, noe som gjør det enkelt å utvide lagring uten å øke datakraften. Bare bruken av rimelig datalagring resulterer i skalerbarhet som er kostnadseffektiv.
- Bedre datastyring: Datainnsjøhus er konstruert med standardisert åpen arkitektur, noe som gir mer kontroll over sikkerhet, beregninger, rollebasert tilgang og andre viktige administrasjonskomponenter. Ved å forene ressurser og datakilder forenkler og forbedrer de styringen.
- Forenklede standarder: Siden tilkoblingen var svært begrenset på 1980-tallet, da datavarehus først ble utviklet, ble lokaliserte skjemastandarder ofte utviklet i bedrifter, til og med avdelinger. Data Lakehouses benytter seg av det faktum at mange typer data nå har åpne standarder for skjema ved å ta inn en rekke datakilder med det overlappende enhetlige skjemaet for å strømlinjeforme prosedyrer.
Ulemper med Data Lakehouse
Til tross for alt det tullete rundt datainnsjøer, er det viktig å huske på at ideen fortsatt er veldig ny. Pass på å veie ulempene før du forplikter deg fullt ut til dette nye designet.
- Monolittisk struktur: Et innsjøhuss altomfattende design gir flere fordeler, men det reiser også noen problemer. Monolittisk arkitektur fører ofte til dårlig service for alle brukere og kan være rigid og vanskelig å vedlikeholde. Vanligvis liker arkitekter og designere en mer modulær arkitektur som de kan tilpasse for ulike brukstilfeller.
- Teknologien er ikke helt der ennå: det endelige målet innebærer en betydelig mengde maskinlæring og kunstig intelligens. Før innsjøhus kan fungere som forutsatt, må disse teknologiene utvikles videre.
- Ikke et betydelig fremskritt i forhold til eksisterende strukturer: Det er fortsatt betydelig skepsis til hvor mye mer verdi innsjøer faktisk vil bidra med. Noen kritikere hevder at en innsjø-lagerdesign sammen med riktig automatisert utstyr kan oppnå sammenlignbar effektivitet.
Utfordringer ved Data Lakehouse
Det kan være vanskelig å ta i bruk data Lakehouse-teknikken. På grunn av intrikatheten til komponentdelene, er det feil å se datainnsjøhuset som en altomfattende ideell struktur eller "én plattform for alt", for én.
I tillegg, på grunn av den økende bruken av datainnsjøer, vil bedrifter måtte flytte sine nåværende datavarehus til dem, kun stole på et løfte om suksess uten noen påviselig økonomisk fordel.
Hvis det er noen latensproblemer eller avbrudd gjennom hele overføringsprosessen, kan dette ende opp med å bli dyrt, tidkrevende og kanskje utrygt.
Bedriftsbrukere må omfavne høyspesialiserte teknologier, ifølge visse leverandører som eksplisitt eller implisitt markedsfører løsninger som datainnsjøer. Disse fungerer kanskje ikke alltid med andre verktøy knyttet til datainnsjøen i sentrum av systemet, noe som øker problemene.
I tillegg kan det være vanskelig å levere 24/7-analyse mens du kjører forretningskritiske arbeidsbelastninger, noe som krever infrastruktur med kostnadseffektiv skalerbarhet.
konklusjonen
Den nyeste typen datasentre de siste årene er datainnsjøhuset. Den integrerer en rekke felt, for eksempel informasjonsteknologi, åpen kildekode-programvare, cloud computing, og distribuerte lagringsprotokoller.
Det gjør det mulig for bedrifter å sentralt lagre alle datatyper fra alle steder, noe som forenkler administrasjon og analyse. Data Lakehouse er et ganske spennende konsept.
Ethvert firma ville ha et betydelig konkurransefortrinn hvis det hadde tilgang til en alt-i-ett-dataplattform som var like rask og effektiv som et datavarehus, samtidig som den var like fleksibel som en datainnsjø.
Ideen er fortsatt under utvikling og er fortsatt relativt ny. Som et resultat kan det ta litt tid å finne ut om noe kan bli utbredt eller ikke.
Vi burde alle være nysgjerrige på retningen som Lakehouse-arkitekturen er på vei.
Legg igjen en kommentar