Hvad er en datasø? Definition, ArchiTekstur og bedste praksis

Hvad er Data Lake?

En Data Lake er et lagerlager, der kan gemme store mængder strukturerede, semistrukturerede og ustrukturerede data. Det er et sted at gemme alle typer data i dets oprindelige format uden faste grænser for kontostørrelse eller fil. Det tilbyder høj datamængde for at øge analytisk ydeevne og native integration.

Data Lake er som en stor container, der minder meget om rigtige søer og floder. Ligesom i en sø har du flere bifloder, der kommer ind, en datasø har strukturerede data, ustrukturerede data, maskine til maskine, logfiler, der flyder igennem i realtid.

Som illustrationen ovenfor viser, føder mange separate strømme en enkelt mængde lagret data. Datasøen demokratiserer data og er en omkostningseffektiv måde at lagre alle en organisations data til senere behandling. Forskningsanalytikere kan fokusere på at finde meningsmønstre i data og ikke i selve dataene.

I modsætning til en hierarkisk Data varehus hvor data er gemt i filer og mappe, har Data lake en flad arkitektur. Hvert dataelement i en Data Lake får en unik identifikator og tagges med et sæt metadataoplysninger.

Hvorfor Data Lake?

Hovedformålet med at bygge en datasø er at tilbyde et uraffineret syn på data til dataforskere.

Årsager til at bruge Data Lake er:

• Med begyndelsen af ​​lagermotorer som Hadoop lagring af forskellig information er blevet let. Der er ingen grund til at modellere data til et virksomhedsdækkende skema med en Data Lake.
• Med stigningen i datamængde, datakvalitet og metadata øges kvaliteten af ​​analyser også.
• Data Lake tilbyder business agility
• Maskinelæring og kunstig intelligens kan bruges til at lave rentable forudsigelser.
• Det giver en konkurrencefordel til den implementerende organisation.
• Der er ingen datasilostruktur. Data Lake giver 360 graders visning af kunder og gør analysen mere robust.

Data Lake Architecture

Figuren viser arkitekturen af ​​en Business Data Lake. De nederste niveauer repræsenterer data, der for det meste er i hvile, mens de øverste niveauer viser transaktionsdata i realtid. Disse data strømmer gennem systemet med ingen eller lille latens. Følgende er vigtige niveauer i Data Lake Archilære:

1. Indtagelsesniveau: Lagene i venstre side viser datakilderne. Dataene kan indlæses i datasøen i batches eller i realtid
2. Indsigtsniveau: Lagene til højre repræsenterer forskningssiden, hvor indsigt fra systemet bruges. SQL, NoSQL-forespørgsler eller endda excel kunne bruges til dataanalyse.
3. HDFS er en omkostningseffektiv løsning til både strukturerede og ustrukturerede data. Det er en landingszone for alle data, der er i ro i systemet.
4. Destillationstrin tager data fra lagerniveauet og konverterer dem til strukturerede data for nemmere analyse.
5. Behandlingstrin køre analytiske algoritmer og brugerforespørgsler med varierende realtid, interaktiv batch for at generere strukturerede data for lettere analyse.
6. Samlet operationsniveau styrer systemstyring og overvågning. Det omfatter revision og kompetencestyring, datastyring, styring af arbejdsgang.

Key Data Lake Concepts

Følgende er Key Data Lake-koncepter, som man skal forstå for fuldstændigt at forstå Data Lake Architecture

Dataindtagelse

Dataindtagelse gør det muligt for connectorer at hente data fra en anden datakilde og indlæse i datasøen.

Dataindtagelse understøtter:

• Alle typer af strukturerede, semi-strukturerede og ustrukturerede data.
• Flere indtagelser som Batch, Real-Time, One-time load.
• Mange typer datakilder som databaser, webservere, e-mails, IoTog FTP.

Datalagring

Datalagring skal være skalerbar, tilbyde omkostningseffektiv lagring og give hurtig adgang til dataudforskning. Det skal understøtte forskellige dataformater.

Data Governance

Datastyring er en proces til styring af tilgængelighed, brugervenlighed, sikkerhed og integritet af data, der bruges i en organisation.

Sikkerhed

Sikkerhed skal implementeres i hvert lag af datasøen. Det starter med opbevaring, udgravning og forbrug. Det grundlæggende behov er at stoppe adgangen for uautoriserede brugere. Det bør understøtte forskellige værktøjer til at få adgang til data med let at navigere i GUI og Dashboards.

Autentificering, regnskab, autorisation og databeskyttelse er nogle vigtige funktioner i datasø-sikkerhed.

Datakvalitet

Datakvalitet er en essentiel komponent i Data Lake-arkitekturen. Data bruges til at skabe forretningsværdi. F.eks.tracAt få indsigt fra data af dårlig kvalitet vil føre til indsigt af dårlig kvalitet.

Dataopdagelse

Dataopdagelse er en anden vigtig fase, før du kan begynde at forberede data eller analyser. I denne fase bruges tagging-teknik til at udtrykke dataforståelsen ved at organisere og fortolke de data, der er indtaget i datasøen.

Datarevision

To vigtige datarevisionsopgaver er tracking ændringer i nøgledatasættet.

1. Tracking ændringer i vigtige datasætelementer
2. Fanger hvordan/ hvornår/ og hvem der ændrer til disse elementer.

Datarevision hjælper med at evaluere risiko og compliance.

Dataafstamning

Denne komponent omhandler datas oprindelse. Den beskæftiger sig primært med, hvor de bevæger sig hen over tid, og hvad der sker med dem. Den letter fejlrettelser i en dataanalyseproces fra oprindelse til destination.

Dataudforskning

Det er begyndelsen af ​​dataanalysen. Det hjælper med at identificere det rigtige datasæt er afgørende, før du starter Data Exploration.

Alle givne komponenter skal arbejde sammen for at spille en vigtig rolle i, at Data Lake-bygning nemt kan udvikle sig og udforske miljøet.

Populære Data Lake-platforme

De ovenfor beskrevne niveauer er normalt samlet fra administrerede cloudtjenester i stedet for at blive bygget fra bunden. Platformene nedenfor dækker de lagrings- og katalogiseringslag, som de fleste implementeringer starter med.

• Amazon S3 med AWS-søformation: Objektlagring parret med en tjeneste, der registrerer kilder, angiver tilladelser og opbygger datakataloget. Se AWS-vejledning for det bredere økosystem.
• Azure Data Lake Storage Gen2: Tilføjer et hierarkisk navneområde oven på Blob Storage, hvilket giver sikkerhed på mappeniveau og hurtigere adgang til analyser.
• Google Cloud Opbevaring med BigLake: Kombinerer objektlagring med et forespørgselslag, der læser åbne tabelformater direkte.
• Apache Hadoop med HDFS: Den oprindelige lokale løsning, der stadig bruges, hvor data skal forblive i et privat datacenter.
• Databricks og Snowflake: Platforme, der lægger tabelformater i lag, f.eks. Delta Lake og Apache Iceberg over objektlagring for at tilføje transaktioner og versionsstyring.

Udvælgelsen følger normalt den cloududbyder, som organisationen allerede bruger, da indtagelse og business intelligence -værktøjer integreres billigst i et enkelt økosystem.

Modenhedsstadier af Data Lake

Definitionen af ​​datasøens modenhedsstadier er forskellig fra lærebog til anden. Selvom kernen forbliver den samme. Efter modenhed er scenedefinitionen fra et lægmandssynspunkt.

Trin 1: Håndter og indtag data i skala

Denne første fase af datamodenhed involverer forbedring af evnen til at transformere og analysere data. Her skal virksomhedsejere finde værktøjerne i overensstemmelse med deres færdigheder til at indhente mere data og bygge analytiske applikationer.

Trin 2: Opbygning af den analytiske muskel

Dette er en anden fase, som involverer forbedring af evnen til at transformere og analysere data. I denne fase bruger virksomheder det værktøj, der passer bedst til deres kompetencer. De begynder at anskaffe flere data og bygge applikationer. Her bruges funktionerne i virksomhedens datavarehus og datasø sammen.

Trin 3: EDW og Data Lake arbejder sammen

Dette trin involverer at få data og analyser i hænderne på så mange mennesker som muligt. I denne fase begynder datasøen og virksomhedens datavarehus at arbejde i en fagforening. Begge spiller deres rolle i analyser

Trin 4: Virksomhedskapacitet i søen

I denne modenhedsfase af datasøen føjes virksomhedsfunktioner til datasøen. Vedtagelse af informationsstyring, informationslivscyklusstyringskapaciteter og metadatastyring. Men meget få organisationer kan nå dette modenhedsniveau, men dette tal vil stige i fremtiden.

Bedste praksis for Data Lake-implementering

• Architektoniske komponenter, deres interaktion og identificerede produkter bør understøtte native datatyper
• Design af Data Lake bør være drevet af, hvad der er tilgængeligt i stedet for, hvad der kræves. Skemaet og datakravet er ikke defineret, før det er forespurgt
• Design bør styres af engangskomponenter integreret med service API.
• Dataopdagelse, indtagelse, lagring, administration, kvalitet, transformation og visualisering bør administreres uafhængigt.
• Data Lake-arkitekturen bør skræddersyes til en specifik branche. Det bør sikre, at de nødvendige muligheder for det pågældende domæne er en iboende del af designet
• Hurtigere on-boarding af nyopdagede datakilder er vigtigt
• Data Lake hjælper med skræddersyet administration til f.eks.tract maksimal værdi
• Data Lake bør understøtte eksisterende virksomhedsdatahåndteringsteknikker og -metoder

Udfordringer ved at bygge en datasø:

• I Data Lake er datavolumen højere, så processen skal være mere afhængig af programmatisk administration
• Det er svært at håndtere sparsomme, ufuldstændige, flygtige data
• Større omfang af datasæt og kilde kræver større datastyring og support

Forskellen mellem Data Lakes og Data Warehouse

Følgende sammenligning opsummerer, hvor hver butik passer ind. En mere detaljeret oversigt er tilgængelig i data sø vs data warehouse sammenligning.

Driftsparametre	Data Lakes	Data varehus
Data	Datasøer gemmer alt.	Data Warehouse fokuserer kun på forretningsprocesser.
Behandles	Data er hovedsageligt ubehandlede	Højt behandlede data.
Datatype	Det kan være ustruktureret, semistruktureret og struktureret.	Det er for det meste i tabelform og struktur.
Opgaver	Del dataforvaltning	Optimeret til datahentning
Agility	Meget smidig, konfigurer og omkonfigurer efter behov.	Sammenlignet med Data Lake er den mindre agil og har fast konfiguration.
Brugere	Data Lake bruges mest af Data Scientist	Erhvervsprofessionelle bruger i vid udstrækning data Warehouse
Opbevaring	Data søer-design til lavpris lagring.	Der bruges dyrt lager, der giver hurtige svartider
Sikkerhed	Giver mindre kontrol.	Giver bedre kontrol over dataene.
Udskiftning af EDW	Datasø kan være kilde til EDW	Komplementær til EDW (ikke erstatning)
Planlæg	Skema ved læsning (ingen foruddefinerede skemaer)	Skema ved skrivning (foruddefinerede skemaer)
Databehandling	Hjælper til hurtig indtagelse af nye data.	Tidskrævende at introducere nyt indhold.
Datagranularitet	Data på et lavt detaljerings- eller granularitetsniveau.	Data på oversigts- eller aggregeret detaljeringsniveau.
Værktøjer	Kan bruge open source/værktøjer som Hadoop/ Map Reduce	Mest kommercielle værktøjer.

Hvad er et Data Lakehouse?

Sammenligningen ovenfor forudsætter to separate systemer. Et Data Lakehouse fusionerer dem til ét, hvilket er grunden til, at udtrykket optræder i de fleste aktuelle arkitekturdiskussioner.

Et søhus opbevarer råfiler i billig objektlagring og tilføjer derefter et transaktionelt metadatalag gennem åbne tabelformater som f.eks. Delta Lake, Apache Iceberg eller Apache Hudi. Dette lag leverer de garantier, som et lager giver, mens de underliggende filer forbliver åbne.

Capability	Data Lake	Data Lakehouse
Transaktioner	Ikke understøttet	ACID-transaktioner på tabeller
Skemahåndtering	Skema på skrivebeskyttet	Skemahåndhævelse og -udvikling
Primære brugere	Dataforskere	Analytikere og dataforskere sammen
Rapporteringshastighed	Langsom uden et separat lager	Direkte forespørgsler med indeksering og caching

For hold, der allerede driver en styret sø, er indførelsen af ​​et tabelformat normalt en trinvis opgradering snarere end en genopbygning.

Fordele og risici ved at bruge Data Lake

Her er nogle store fordele ved at bruge en Data Lake:

• Hjælper fuldt ud med produktionsstyring og avanceret analyse
• Tilbyder omkostningseffektiv skalerbarhed og fleksibilitet
• Tilbyder værdi fra ubegrænsede datatyper
• Reducerer langsigtede ejeromkostninger
• Tillader økonomisk lagring af filer
• Hurtigt tilpasset ændringer
• Den største fordel ved data lake er centralisering af forskellige indholdskilder
• Brugere, fra forskellige afdelinger, kan være spredt over hele kloden kan have fleksibel adgang til dataene

Risiko ved at bruge Data Lake:

• Efter nogen tid kan Data Lake miste relevans og momentum
• Der er en større risiko involveret under design af Data Lake
• Ustrukturerede data kan føre til ustyrligt kaos, ubrugelige data, forskellige og komplekse værktøjer og svagt samarbejde på tværs af virksomheden.
• Det øger også lager- og beregningsomkostninger
• Der er ingen måde at få indsigt fra andre, der har arbejdet med dataene, fordi der ikke er nogen redegørelse for rækken af ​​resultater fra tidligere analytikere
• Den største risiko ved datasøer er sikkerhed og adgangskontrol. Nogle gange kan data placeres i en sø uden nogen form for tilsyn, da nogle af dataene kan have privatliv og lovgivningsmæssige behov

Ofte Stillede Spørgsmål