Vad är en datasjö? Definition, ArchiTeknik och bästa praxis

Vad är Data Lake?

En Data Lake är ett lagringsarkiv som kan lagra stora mängder strukturerad, semistrukturerad och ostrukturerad data. Det är en plats att lagra alla typer av data i sitt ursprungliga format utan fasta gränser för kontostorlek eller fil. Den erbjuder hög datamängd för att öka analytisk prestanda och integrerad integration.

Data Lake är som en stor container som är väldigt lik riktiga sjöar och floder. Precis som i en sjö har du flera bifloder som kommer in, en datasjö har strukturerad data, ostrukturerad data, maskin till maskin, loggar som flödar igenom i realtid.

Som illustrationen ovan visar, matar många separata strömmar en enda mängd lagrad data. Data Lake demokratiserar data och är ett kostnadseffektivt sätt att lagra all data i en organisation för senare bearbetning. Forskningsanalytiker kan fokusera på att hitta meningsmönster i data och inte i själva data.

Till skillnad från en hierarkisk Datalager där data lagras i filer och mappar, har Data lake en platt arkitektur. Varje dataelement i en Data Lake får en unik identifierare och taggas med en uppsättning metadatainformation.

Varför Data Lake?

Huvudsyftet med att bygga en datasjö är att erbjuda en oraffinerad bild av data till dataforskare.

Skälen till att använda Data Lake är:

• Med uppkomsten av lagringsmotorer som Hadoop Det har blivit enkelt att lagra olika information. Det finns inget behov av att modellera data till ett företagsomfattande schema med en Data Lake.
• Med ökningen av datavolym, datakvalitet och metadata ökar också kvaliteten på analyser.
• Data Lake erbjuder affärsagility
• Maskininlärning och artificiell intelligens kan användas för att göra lönsamma förutsägelser.
• Det erbjuder en konkurrensfördel för den implementerande organisationen.
• Det finns ingen datasilostruktur. Data Lake ger 360 graders vy över kunder och gör analysen mer robust.

datasjö Architecture

Figuren visar arkitekturen för en Business Data Lake. De lägre nivåerna representerar data som mestadels är i vila medan de övre nivåerna visar transaktionsdata i realtid. Dessa data flödar genom systemet med ingen eller liten latens. Följande är viktiga nivåer i Data Lake Architecture:

1. Förtäringsnivå: Nivåerna på vänster sida visar datakällorna. Data kan laddas in i datasjön i partier eller i realtid
2. Insiktsnivå: Nivåerna till höger representerar forskningssidan där insikter från systemet används. SQL, NoSQL-frågor eller till och med Excel kan användas för dataanalys.
3. HDFS är en kostnadseffektiv lösning för både strukturerad och ostrukturerad data. Det är en landningszon för all data som är i vila i systemet.
4. Destillationsnivå tar data från lagringsnivån och konverterar den till strukturerad data för enklare analys.
5. Bearbetningsnivå kör analytiska algoritmer och användarfrågor med varierande realtid, interaktiv, batch för att generera strukturerad data för enklare analys.
6. Unified operations tier styr systemförvaltning och övervakning. Det inkluderar revision och kompetenshantering, datahantering, arbetsflödeshantering.

Key Data Lake Concepts

Följande är Key Data Lake-koncept som man behöver förstå för att helt förstå Data Lake Architecture

Förtäring av data

Datainmatning gör det möjligt för anslutningar att hämta data från en annan datakälla och ladda in i datasjön.

Dataintag stöder:

• Alla typer av strukturerad, halvstrukturerad och ostrukturerad data.
• Flera intag som batch, realtid, engångsladdning.
• Många typer av datakällor som databaser, webbservrar, e-postmeddelanden, IoToch FTP.

Datalagring

Datalagring ska vara skalbar, erbjuda kostnadseffektiv lagring och ge snabb åtkomst till datautforskning. Det bör stödja olika dataformat.

Data Governance

Datastyrning är en process för att hantera tillgänglighet, användbarhet, säkerhet och integritet för data som används i en organisation.

Säkerhet

Säkerhet måste implementeras i varje lager av datasjön. Det börjar med lagring, avgrävning och konsumtion. Det grundläggande behovet är att stoppa åtkomst för obehöriga användare. Det bör stödja olika verktyg för att komma åt data med lättnavigerade GUI och Dashboards.

Autentisering, redovisning, auktorisering och dataskydd är några viktiga funktioner för datasjösäkerhet.

Datakvalitet

Datakvalitet är en viktig del av Data Lake-arkitekturen. Data används för att skapa affärsvärde.tracAtt få insikter från data av dålig kvalitet kommer att leda till insikter av dålig kvalitet.

Upptäckt av data

Data Discovery är ett annat viktigt steg innan du kan börja förbereda data eller analyser. I detta skede används taggningsteknik för att uttrycka dataförståelsen genom att organisera och tolka data som tas in i datasjön.

Datarevision

Två viktiga uppgifter inom datagranskning är tracking ändringar i nyckeldatasetet.

1. Tracking ändringar i viktiga datamängder
2. Fångar hur/ när/ och vem som ändrar till dessa element.

Datarevision hjälper till att utvärdera risker och efterlevnad.

Datalinje

Denna komponent hanterar datas ursprung. Den handlar främst om vart den rör sig över tid och vad som händer med den. Den underlättar felkorrigeringar i en dataanalysprocess från ursprung till destination.

Dataforskning

Det är början av dataanalys. Det hjälper till att identifiera rätt datauppsättning är avgörande innan du startar datautforskning.

Alla givna komponenter måste samarbeta för att spela en viktig roll för att Data Lake-byggandet enkelt kan utvecklas och utforska miljön.

Populära datasjöplattformar

Nivåerna som beskrivs ovan är vanligtvis sammansatta från hanterade molntjänster snarare än byggda från grunden. Plattformarna nedan täcker de lagrings- och katalogiseringslager som de flesta implementeringar börjar med.

• Amazon S3 med AWS-sjöformation: Objektlagring i kombination med en tjänst som registrerar källor, anger behörigheter och bygger datakatalogen. Se AWS-handledning för det bredare ekosystemet.
• Azure Data Lake Storage Gen2: Lägger till ett hierarkiskt namnområde ovanpå Blob Storage, vilket ger säkerhet på katalognivå och snabbare analysåtkomst.
• Google Cloud Lagring med BigLake: Kombinerar objektlagring med ett frågelager som läser öppna tabellformat direkt.
• Apache Hadoop med HDFS: Det ursprungliga lokala alternativet, används fortfarande där data måste förvaras i ett privat datacenter.
• Databricks och Snowflake: Plattformar som lagerlägger tabellformat som Delta Lake och Apache Iceberg över objektlagring för att lägga till transaktioner och versionshantering.

Urvalet följer normalt den molnleverantör som en organisation redan använder, eftersom inmatning och affärsunderrättelseverktyg integreras billigast inom ett enda ekosystem.

Mognadsstadier av Data Lake

Definitionen av Data Lake Mognadsstadier skiljer sig från lärobok till annan. Även om kärnan förblir densamma. Efter mognad är scendefinitionen från lekmannasynpunkt.

Steg 1: Hantera och ta in data i stor skala

Detta första steg av datamognad innebär att förbättra förmågan att transformera och analysera data. Här måste företagare hitta de verktyg som passar deras kompetens för att skaffa mer data och bygga analytiska applikationer.

Steg 2: Bygg den analytiska muskeln

Detta är ett andra steg som innebär att förbättra förmågan att transformera och analysera data. I detta skede använder företag det verktyg som är mest lämpligt för deras kompetens. De börjar skaffa mer data och bygga applikationer. Här används funktionerna i företagets datalager och datasjön tillsammans.

Steg 3: EDW och Data Lake arbetar unisont

Detta steg innebär att få data och analyser i händerna på så många människor som möjligt. I detta skede börjar datasjön och företagets datalager att arbeta i ett fackförbund. Båda spelar sin roll i analysen

Steg 4: Företagskapacitet i sjön

I detta mognadsstadium av datasjön läggs företagskapaciteter till i datasjön. Antagande av informationsstyrning, funktioner för informationslivscykelhantering och metadatahantering. Men väldigt få organisationer kan nå denna mognadsnivå, men denna siffra kommer att öka i framtiden.

Bästa metoder för Data Lake-implementering

• Architekniska komponenter, deras interaktion och identifierade produkter bör stödja inbyggda datatyper
• Design av Data Lake ska drivas av vad som är tillgängligt istället för vad som krävs. Schema- och datakravet definieras inte förrän det har frågats
• Design bör styras av engångskomponenter integrerade med service API.
• Dataupptäckt, intag, lagring, administration, kvalitet, transformation och visualisering bör hanteras oberoende.
• Data Lake-arkitekturen bör skräddarsys för en specifik bransch. Det bör säkerställa att kapacitet som krävs för den domänen är en inneboende del av designen
• Snabbare introduktion av nyupptäckta datakällor är viktigt
• Data Lake hjälper till med anpassad hantering för att extract maximalt värde
• Data Lake bör stödja befintliga tekniker och metoder för företagsdatahantering

Utmaningar med att bygga en datasjö:

• I Data Lake är datavolymen högre, så processen måste vara mer beroende av programmatisk administration
• Det är svårt att hantera glesa, ofullständiga, flyktiga data
• Ett bredare omfång av datauppsättning och källa kräver större datastyrning och stöd

Skillnaden mellan Data Lakes och Data Warehouse

Följande jämförelse sammanfattar var varje butik passar in. En mer detaljerad uppdelning finns tillgänglig i datasjö kontra datalager jämförelse.

Driftparametrar	Datasjöar	Datalager
Data	Datasjöar lagrar allt.	Data Warehouse fokuserar endast på affärsprocesser.
Bearbetning	Data är huvudsakligen obearbetade	Mycket bearbetade data.
Typ av data	Det kan vara ostrukturerat, semistrukturerat och strukturerat.	Det är mestadels i tabellform och struktur.
uppgift	Dela dataförvaltning	Optimerad för datahämtning
Rörlighet	Mycket smidig, konfigurera och konfigurera om efter behov.	Jämfört med Data lake är den mindre smidig och har fast konfiguration.
användare	Data Lake används mest av Data Scientist	Affärsmän använder datalager i stor utsträckning
lagring	Datasjödesign för lågkostnadslagring.	Dyr lagring som ger snabba svarstider används
Säkerhet	Ger mindre kontroll.	Ger bättre kontroll över data.
Byte av EDW	Data lake kan vara källa för EDW	Kompletterande till EDW (inte ersättning)
Schema	Schema vid läsning (inga fördefinierade scheman)	Schema vid skrivning (fördefinierade scheman)
Databehandling	Hjälper till för snabb intag av ny data.	Tidskrävande att introducera nytt innehåll.
Datagranularitet	Data på en låg detaljnivå eller granularitet.	Data på sammanfattning eller aggregerad detaljnivå.
Verktyg	Kan använda öppen källkod/verktyg som Hadoop/ Map Reduce	Mestadels kommersiella verktyg.

Vad är ett datasjöhus?

Jämförelsen ovan förutsätter två separata system. Ett Data Lakehouse slår samman dem till ett, vilket är anledningen till att termen förekommer i de flesta aktuella arkitekturdiskussioner.

Ett sjöhus lagrar råfiler i billig objektlagring och lägger sedan till ett transaktionellt metadatalager genom öppna tabellformat som Delta Lake, Apache Iceberg eller Apache Hudi. Det lagret tillhandahåller de garantier som ett lager erbjuder medan de underliggande filerna förblir öppna.

Capability	datasjö	Data Lakehouse
Transaktioner	Stöds inte	ACID-transaktioner på tabeller
Schemahantering	Schema skrivskyddat	Schematillämpning och utveckling
Huvudanvändare	Datavetare	Analytiker och dataforskare tillsammans
Rapporteringshastighet	Långsam utan ett separat lager	Direktfrågor med indexering och cachning

För lag som redan driver en styrd sjö är det vanligtvis en stegvis uppgradering snarare än en ombyggnad att anta ett tabellformat.

Fördelar och risker med att använda Data Lake

Här är några stora fördelar med att använda en Data Lake:

• Hjälper fullt ut med produktionsanpassning och avancerad analys
• Erbjuder kostnadseffektiv skalbarhet och flexibilitet
• Erbjuder värde från obegränsade datatyper
• Minskar långsiktiga ägandekostnader
• Tillåter ekonomisk lagring av filer
• Snabbt anpassningsbar till förändringar
• Den största fördelen med data lake är centralisering av olika innehållskällor
• Användare, från olika avdelningar, kan vara utspridda över hela världen flexibel åtkomst till datan

Risk med att använda Data Lake:

• Efter en tid kan Data Lake förlora relevans och fart
• Det finns en större risk vid utformningen av Data Lake
• Ostrukturerad data kan leda till ostyrt kaos, oanvändbar data, disparata och komplexa verktyg och svagt samarbete i hela företaget.
• Det ökar också lagrings- och beräkningskostnaderna
• Det finns inget sätt att få insikter från andra som har arbetat med data eftersom det inte finns någon redogörelse för linjen av fynd från tidigare analytiker
• Den största risken med datasjöar är säkerhet och åtkomstkontroll. Ibland kan data placeras i en sjö utan någon tillsyn, eftersom en del av data kan ha integritets- och regleringsbehov

Vanliga frågor