Det kan vara lite svårt att överväga alla tillgängliga tjänster och arkitektoniska alternativ när man tänker på dataplattformar.
En företagsdataplattform består ofta av datalager, datamodeller, datasjöar och rapporter, var och en med ett specifikt syfte och en uppsättning färdigheter som behövs. Däremot har en ny design kallad data lakehouse dykt upp under de senaste åren.
Mångsidigheten hos datasjöar och datalagringsdatahantering kombineras i en revolutionerande datalagringsarkitektur som kallas ett "datasjöhus".
Vi kommer att undersöka data Lakehouse på djupet i det här inlägget, inklusive dess komponenter, funktioner, arkitektur och andra aspekter.
Vad är Data Lakehouse?
Som namnet antyder är ett datasjöhus en ny typ av dataarkitektur som kombinerar en datasjö med ett datalager för att lösa bristerna hos varje separat.
I huvudsak använder lakehouse-systemet billig lagring för att upprätthålla enorma mängder data i sina ursprungliga former, ungefär som datasjöar. Att lägga till metadatalagret ovanpå butiken ger också datastruktur och ger datahanteringsverktyg som de som finns i datalager.
Den lagrar de enorma volymerna av organiserad, semistrukturerad och ostrukturerad data som de får från olika affärsapplikationer, system och prylar som används i hela organisationen.
Merparten av tiden använder datasjöar lågkostnadslagringsinfrastruktur med ett filapplikationsprogrammeringsgränssnitt (API) för att lagra data i öppna, generiska filformat.
Detta gör det möjligt för många team att få tillgång till all företagsdata genom ett enda system för en mängd olika initiativ, såsom datavetenskap, maskininlärningoch business intelligence.
Funktioner
- Lågkostnadsförvaring. Ett datasjöhus ska kunna lagra data i billig objektlagring, som t.ex Google Cloud Storage, Azure Blob Storage, Amazon Simple Storage Service eller inbyggt med ORC eller Parkett.
- Möjlighet för dataoptimering: Datalayoutoptimering, cachning och indexering är några exempel på hur ett datasjöhus måste kunna optimera datan samtidigt som datans ursprungliga format bibehålls.
- Ett lager av transaktionsmetadata: Utöver den väsentliga lågkostnadslagringen möjliggör detta datahanteringsfunktioner som är avgörande för datalagerprestanda.
- Stöd för Declarative DataFrame API: De flesta AI-verktyg kan använda DataFrames för att hämta rådata för objektlagring. Stöd för Declarative DataFrame API ökar möjligheten att dynamiskt förbättra datas presentation och struktur som svar på en viss datavetenskap eller AI-uppgift.
- Stöd för ACID-transaktioner: Förkortningen ACID, som står för atomicitet, konsistens, isolering och hållbarhet, är en kritisk komponent för att definiera en transaktion och säkerställa konsistensen och tillförlitligheten hos data. Sådana transaktioner var tidigare endast möjliga i datalager, men lakehouse erbjuder möjligheten att använda dem med datasjöar också. Med flera datapipelines inklusive samtidiga dataläsningar och skrivningar, löser detta problemet med låg datakvalitet hos de senare.
Element av Data Lakehouse
Datasjöhusets arkitektur är uppdelad i två huvudnivåer på hög nivå. Lagringsskiktets dataintag styrs av Lakehouse-plattformen (dvs. datasjön).
Utan att behöva ladda data till ett datalager eller konvertera det till ett proprietärt format, kan bearbetningsskiktet sedan fråga data i lagringslagret direkt med hjälp av en rad verktyg.
Sedan kan BI-appar, såväl som AI- och ML-tekniker, använda data. Ekonomin för en datasjö tillhandahålls av denna design, men eftersom alla bearbetningsmotorer kan läsa dessa data har företag friheten att göra den förberedda informationen tillgänglig för analys av en rad olika system. Processorprestanda och kostnad kan båda förbättras genom att använda denna metod för bearbetning och analys.
På grund av dess stöd för databastransaktioner som följer följande ACID-kriterier (atomicitet, konsistens, isolering och hållbarhet), gör arkitekturen också att många parter kan komma åt och skriva data samtidigt i systemet:
- Atomicitet hänvisar till det faktum att antingen hela transaktionen eller inget av den lyckas när en transaktion genomförs. I händelse av att en process avbryts hjälper detta till att undvika dataförlust eller korruption.
- Konsistens garanterar att transaktioner sker på ett förutsägbart och konsekvent sätt. Den upprätthåller integriteten för uppgifterna genom att säkerställa att alla uppgifter är legitima i enlighet med förutbestämda regler.
- Isolering säkerställer att ingen transaktion kan påverkas av någon annan transaktion i systemet tills den är klar. Detta gör att många parter kan läsa och skriva från samma system samtidigt utan att störa varandra.
- Hållbarhet garanterar att ändringar av data i ett system fortsätter att existera efter att en transaktion är avslutad, även i händelse av ett systemfel. Eventuella ändringar som orsakas av en transaktion sparas för alltid.
Data Lakehouse-arkitektur
Databricks (innovatören och designern av deras Delta Lake-koncept) och AWS är de två främsta förespråkarna för konceptet med ett datasjöhus. Vi ska därför förlita oss på deras kunskap och insikt för att beskriva den arkitektoniska utformningen av sjöhus.
Ett datasjöhussystem har vanligtvis fem lager:
- Förtäringslager
- Lagringslager
- Metadatalager
- API-lager
- Konsumtionslager
Förtäringslager
Systemets första lager ansvarar för att samla in data från olika källor och skicka det till lagringslagret. Lagret kan använda flera protokoll för att ansluta till många interna och externa källor, inklusive att kombinera batch- och strömmande databehandlingsfunktioner, som t.ex.
- NoSQL-databaser,
- filresurser
- CRM-applikationer,
- webbplatser,
- IoT-sensorer,
- sociala medier,
- Software as a Service (SaaS)-applikationer, och
- relationsdatabashanteringssystem etc.
Vid denna tidpunkt kan komponenter som Apache Kafka för dataströmning och Amazon Data Migration Service (Amazon DMS) för import av data från RDBMS och NoSQL-databaser användas.
Lagringslager
Lakehouse-arkitekturen är tänkt att möjliggöra lagring av olika typer av data som objekt i billiga objektbutiker, som AWS S3. Med hjälp av öppna filformat kan klientverktygen sedan läsa dessa artiklar direkt från butiken.
Detta gör det möjligt för många API:er och konsumtionslagerkomponenter att komma åt och använda samma data. Metadatalagret lagrar scheman för strukturerade och semistrukturerade datauppsättningar så att komponenterna kan tillämpa dem på data när de läser den.
Hadoop Distributed File System (HDFS)-plattformen kan till exempel användas för att konstruera molnlagringstjänster som delar upp datoranvändning och lagring på plats. Lakehouse är idealiskt lämpad för dessa tjänster.
Metadatalager
Metadatalagret är den grundläggande komponenten i ett datasjöhus som särskiljer denna design. Det är en enda katalog som erbjuder metadata (information om andra datadelar) för alla föremål som lagras i sjön och tillåter användare att använda administrationsfunktioner som:
- En konsekvent version av databasen ses av samtidiga transaktioner tack vare ACID-transaktioner;
- cachelagring för att spara molnobjektlagringsfiler;
- lägga till datastrukturindex med hjälp av indexering för att påskynda frågebehandlingen;
- använda noll-copy kloning för att duplicera dataobjekt; och
- för att lagra vissa versioner av data, etc., använd dataversionering.
Dessutom möjliggör metadatalagret implementering av schemahantering, användning av DW-schematopologier som stjärn-/snöflingascheman och tillhandahållande av datastyrning och revisionskapacitet direkt på datasjön, vilket förbättrar integriteten för hela datapipeline.
Funktioner för schemautveckling och tillämpning ingår i schemahantering. Genom att avvisa alla skrivningar som inte uppfyller tabellens schema, gör schematillämpning det möjligt för användare att upprätthålla dataintegritet och kvalitet.
Schemautveckling gör att tabellens nuvarande schema kan modifieras för att anpassas till ändrade data. På grund av ett enda administrationsgränssnitt ovanpå datasjön finns det även åtkomstkontroll och revisionsmöjligheter.
API-lager
Ett annat avgörande lager av arkitekturen finns nu, som är värd för ett antal API:er som alla slutanvändare kan använda för att utföra jobb snabbare och få mer sofistikerad statistik.
Användningen av metadata-API:er gör det lättare att identifiera och komma åt de dataobjekt som behövs för en given applikation.
När det gäller maskininlärningsbibliotek kan några av dem, som TensorFlow och Spark MLlib, läsa öppna filformat som Parquet och få direkt tillgång till metadatalagret.
Samtidigt erbjuder DataFrame API:er större möjligheter till optimering, vilket gör det möjligt för programmerare att organisera och ändra spridd data.
Konsumtionslager
Power BI, Tableau och andra verktyg och appar finns under förbrukningslagret. Med lakehouse-designen är all metadata och all data som förvaras i en sjö tillgängliga för klientapparna.
Sjöhuset kan användas av alla användare inom ett företag för att utföra alla typer av analysverksamhet, inklusive att skapa instrumentpaneler för business intelligence och köra SQL-frågor och maskininlärningsuppgifter.
Fördelar med Data Lakehouse
Organisationer kan skapa ett datasjöhus för att förena sin nuvarande dataplattform och optimera hela sin datahanteringsprocess. Genom att demontera silobarriärerna som förbinder olika källor kan ett datasjöhus ersätta behovet av distinkta lösningar.
Jämfört med kurerade datakällor ger denna integration en betydligt effektivare end-to-end-procedur. Detta har flera fördelar:
- Mindre administration: I stället för att extrahera data från rådata och förbereda dem för användning i ett datalager tillåter ett datasjöhus alla källor som är länkade till det att ha sina data tillgängliga och organiserade för användning.
- Ökad kostnadseffektivitet: Datasjöhus är konstruerade med modern infrastruktur som delar beräkning och lagring, vilket gör det enkelt att utöka lagring utan att öka beräkningskraften. Bara användningen av billig datalagring resulterar i skalbarhet som är kostnadseffektiv.
- Bättre datastyrning: Datasjöhus är konstruerade med standardiserad öppen arkitektur, vilket möjliggör mer kontroll över säkerhet, mätvärden, rollbaserad åtkomst och andra viktiga hanteringskomponenter. Genom att förena resurser och datakällor förenklar och förbättrar de styrningen.
- Förenklade standarder: Eftersom anslutningen var mycket begränsad på 1980-talet, när datalager först utvecklades, utvecklades ofta lokala schemastandarder inom företag, till och med avdelningar. Data lakehouses använder sig av det faktum att många typer av data nu har öppna standarder för schema genom att ta in många datakällor med det överlappande enhetliga schemat för att effektivisera procedurer.
Nackdelar med Data Lakehouse
Trots allt tumult kring datasjöhus är det viktigt att komma ihåg att idén fortfarande är väldigt ny. Var noga med att överväga nackdelarna innan du bestämmer dig för denna nya design.
- Monolitisk struktur: Ett sjöhuss allomfattande design erbjuder flera fördelar, men det väcker också vissa problem. Monolitisk arkitektur leder ofta till dålig service för alla användare och kan vara stel och svår att underhålla. Vanligtvis gillar arkitekter och designers en mer modulär arkitektur som de kan anpassa för olika användningsfall.
- Tekniken är inte riktigt där än: det slutliga målet innebär en betydande mängd maskininlärning och artificiell intelligens. Innan sjöhus kan prestera som man tänkt sig måste dessa tekniker utvecklas ytterligare.
- Inte ett betydande framsteg jämfört med befintliga strukturer: Det finns fortfarande stor skepsis över hur mycket mer värde sjöhus faktiskt kommer att bidra med. Vissa belackare hävdar att en sjölagerdesign i kombination med lämplig automatiserad utrustning kan uppnå jämförbar effektivitet.
Data Lakehouses utmaningar
Det kan vara svårt att använda data lakehouse-tekniken. På grund av dess invecklade delar är det felaktigt att se datasjöhuset som en allomfattande ideal struktur eller "en plattform för allt", för en.
Dessutom, på grund av den ökande användningen av datasjöar, kommer företag att behöva flytta sina nuvarande datalager till dem, endast förlita sig på ett löfte om framgång utan några påvisbara ekonomiska fördelar.
Om det finns några latensproblem eller avbrott under hela överföringsprocessen kan detta bli dyrt, tidskrävande och kanske osäkert.
Affärsanvändare måste anamma högspecialiserad teknik, enligt vissa leverantörer som uttryckligen eller implicit marknadsför lösningar som datasjöhus. Dessa kanske inte alltid fungerar med andra verktyg kopplade till datasjön i centrum av systemet, vilket ökar problemen.
Dessutom kan det vara svårt att tillhandahålla 24/7-analys när man kör affärskritiska arbetsbelastningar, vilket kräver infrastruktur med kostnadseffektiv skalbarhet.
Slutsats
Den senaste sorten av datacenter de senaste åren är data lakehouse. Den integrerar en mängd olika områden, såsom informationsteknik, programvara med öppen källkod, cloud computingoch distribuerade lagringsprotokoll.
Det gör det möjligt för företag att centralt lagra alla typer av data från vilken plats som helst, vilket förenklar hantering och analys. Data Lakehouse är ett ganska spännande koncept.
Varje företag skulle ha en betydande konkurrensfördel om det hade tillgång till en allt-i-ett-dataplattform som var lika snabb och effektiv som ett datalager samtidigt som den var lika flexibel som en datasjö.
Idén är fortfarande under utveckling och är fortfarande relativt ny. Som ett resultat kan det ta lite tid att avgöra om något kan bli utbrett eller inte.
Vi borde alla vara nyfikna på riktningen som Lakehouse-arkitekturen är på väg.
Kommentera uppropet