Denne artikel er en oversĂŠttelse af min artikel pĂ„ Medium â , som viste sig at vĂŠre ret populĂŠr, mĂ„ske pĂ„ grund af sin enkelhed. Derfor besluttede jeg at skrive den pĂ„ dansk og tilfĂžje lidt, sĂ„ almindelige mennesker, der ikke er eksperter i databehandling, kan forstĂ„, hvad et datalager (DW) er, hvad et Data Lake er, og hvordan de to eksisterer sammen.
Hvorfor ville jeg skrive om Data Lakes? Jeg har arbejdet med data og analyser i over 10 Är, og i Þjeblikket arbejder jeg bestemt med store data i Amazon Alexa AI i Cambridge, der ligger i Boston, selvom jeg bor pÄ Vancouver Island i Victoria og ofte besÞger bÄde Boston, Seattle og Vancouver, og nogle gange endda taler til konferencer i Moskva. Jeg skriver ogsÄ fra tid til anden, men jeg skriver primÊrt pÄ engelsk, og jeg har allerede skrevet , jeg har ogsÄ et behov for at dele analyserelaterede trends fra Nordamerika, og jeg skriver nogle gange pÄ .
Jeg har altid arbejdet med datalagre, og siden 2015 har jeg arbejdet intensivt med Amazon Web Services, og jeg er generelt gÄet over til cloud-analyse (AWS, Azure, GCP). Jeg har overvÄget udviklingen af analyse-lÞsninger siden 2007 og har endda arbejdet hos en leverandÞr af datalagre, Teradata, og implementeret det i Sberbank, det var dengang Big Data med Hadoop kom frem. Alle begyndte at sige, at Êraen for datalagre var forbi, og nu var det hele pÄ Hadoop, og derefter begyndte man at tale om Data Lakes, igen med pÄstanden om, at nu var datalagerets tid virkelig forbi. Men heldigvis (mÄske desvÊrre for dem, der tjente mange penge pÄ at sÊtte Hadoop op) er datalageret ikke forsvundet.
I denne artikel vil vi se pÄ, hvad et Data Lake er. Artiklen er rettet mod mennesker, der har lidt eller ingen erfaring med datalagre.
PĂ„ billedet er Lake Bled, det er en af mine yndlingssĂžer, selvom jeg kun har vĂŠret der Ă©n gang, men jeg husker det for livet. Men vi skal tale om en anden type sĂž â data lake. MĂ„ske har mange af jer allerede hĂžrt om dette begreb flere gange, men endnu en definition vil ikke skade.
FĂžrst og fremmest er her de mest populĂŠre definitioner af Data Lake:
«et filsystem til alle typer rĂ„ data, der er tilgĂŠngelige for analyse af hvem som helst i organisationen» â Martin Fowler.
«Hvis du tror, at et datavarehus er som en flaske vand â renset, pakket og portioneret til nem forbrug, sĂ„ er et datalake vores enorme reservoir med vand i sin naturlige tilstand. Brugere kan hente vand til sig selv, dykke ned i dybden og udforske» â James Dickson.
Nu ved vi prĂŠcist, at et datalake handler om analyse; det gĂžr det muligt for os at opbevare store mĂŠngder data i deres oprindelige form, og vi har nem adgang til dataene.
Jeg elsker ofte at forenkle ting, hvis jeg kan forklare et komplekst begreb med simple ord, sÄ har jeg for mig selv forstÄet, hvordan det fungerer, og hvad det er nÞdvendigt for. For eksempel, jeg fandt pÄ at undersÞge iPhone i fotogalleriet, og jeg indsÄ, at det er et rigtigt datalake; jeg lavede endda et slide til konferencer:
Det er meget enkelt. Vi tager et billede med telefonen, billedet gemmes pÄ telefonen og kan ogsÄ gemmes i iCloud (cloud-lager). Telefonen indsamler ogsÄ metadata om billedet: hvad der er afbilledet, geotag, tidspunkt. Som resultat kan vi bruge det praktiske interface pÄ iPhone til at finde vores billede, og vi kan endda se indikatorer; for eksempel nÄr jeg sÞger efter billeder med ordet ild (fire), finder jeg 3 billeder af et bÄl. For mig er det ligesom et Business Intelligence-vÊrktÞj, der fungerer meget hurtigt og prÊcist.
Og selvfÞlgelig mÄ vi ikke glemme sikkerhed (autorisation og autentifikation), ellers kan vores data nemt blive offentliggjort. Der er mange nyheder om store virksomheder og startups, som har fÄet deres data offentliggjort pÄ grund af udvikleres forsÞmmelighed og manglende overholdelse af enkle regler.
Selv et sÄ simpelt billede hjÊlper os med at forstÄ, hvad et datalake er, dets forskelle fra traditionelle datalagre og dets vigtigste elementer:
- IndlĂŠsning af data (Ingestion) â en nĂžglekomponent i et datalake. Data kan komme ind i datalageret pĂ„ to mĂ„der â batch (overfĂžrsel med intervaller) og streaming (dataflow).
- Cloud-lager (Storage) â hovedkomponenten i Datalake. Vi har brug for, at lageret er let skalerbart, ekstremt pĂ„lideligt og omkostningseffektivt. For eksempel er det S3 i AWS.
- Katalog og SĂžgning (Katalog og sĂžgning) â for at undgĂ„ datasyge (som er nĂ„r vi samler alle data i Ă©n bunke, og derefter er det umuligt at arbejde med dem), er vi nĂždt til at oprette et lag med metadata til klassificering af data, sĂ„ brugerne nemt kan finde de data, de har brug for til analyse. Derudover kan der anvendes ekstra sĂžgningslĂžsninger, som for eksempel ElasticSearch. SĂžgning hjĂŠlper brugeren med at finde de nĂždvendige data gennem en brugervenlig grĂŠnseflade.
- Behandling (Proces) â dette skridt ansvarer for behandling og transformation af data. Vi kan transformere data, ĂŠndre deres strukturer, rense dem og meget mere.
- Sikkerhed (Sikkerhed) â det er vigtigt at bruge tid pĂ„ at designe sikkerheden i lĂžsningen. For eksempel kryptering af data under opbevaring, behandling og overfĂžrsel. Det er vigtigt at anvende autentificerings- og autorisationsmetoder. Afslutningsvis er et revisionsvĂŠrktĂžj nĂždvendigt.
Fra et praktisk synspunkt kan vi karakterisere datalageret med tre attributter:
- Indsaml og opbevar hvad som helst â datalageret indeholder alle data, bĂ„de rĂ„, ubehandlede data fra enhver tidsperiode samt behandlede/rensede data.
- DybtgĂ„ende analyse â datalageret gĂžr det muligt for brugerne at udforske og analysere data.
- Fleksibel adgang â datalageret giver fleksibel adgang til forskellige data og forskellige scenarier.
Nu kan vi tale om forskellen mellem datalager og datalager. Folk spĂžrger ofte:
- Hvad med datalageret?
- Er vi pÄ vej til at erstatte datalageret med datalageret, eller udvider vi det?
- Kan vi overhovedet klare os uden datalager?
Kort sagt, der er ikke et klart svar. Det afhĂŠnger af den specifikke situation, fĂŠrdighederne i teamet og budgettet. For eksempel migration af datalageret til Oracle i AWS og oprettelse af et datalager af Amazons datterselskab â Woot â .
PÄ den anden side hÊvder leverandÞren Snowflake, at du ikke lÊngere behÞver at tÊnke pÄ datalager, da deres dataplatform (indtil 2020 var det datalager) gÞr det muligt at kombinere bÄde datalager og datalager. Jeg har arbejdet lidt med Snowflake, og det er virkelig et unikt produkt, der kan gÞre det. Prisen er et andet spÞrgsmÄl.
Afslutningsvis mener jeg, at vi stadig har behov for et datalager som den primÊre datakilde til vores rapportering, og alt hvad der ikke passer ind, opbevarer vi i datalaget. Hele formÄlet med analytik er at give nem adgang til forretningen for at trÊffe beslutninger. Uanset hvordan man ser pÄ det, arbejder forretningsbrugere mere effektivt med et datalager end med et datalag; for eksempel i Amazon findes der Redshift (et analytisk datalager) og Redshift Spectrum/Athena (SQL-interface til datalaget i S3 baseret pÄ Hive/Presto). Det samme gÊlder for andre moderne analytiske datalager.
Lad os se pÄ en typisk datalagerarkitektur:
Dette er en klassisk lĂžsning. Vi har kildesystemer, og ved hjĂŠlp af ETL/ELT kopierer vi data til det analytiske datalager og forbinder det til Business Intelligence-lĂžsningen (min favorit er Tableau, hvad med din?).
Denne lĂžsning har fĂžlgende ulemper:
- ETL/ELT-operationer krĂŠver tid og ressourcer.
- Som regel er opbevaring af data i det analytiske datalager ikke billigt (for eksempel Redshift, BigQuery, Teradata), da vi skal kĂžbe et helt cluster.
- Forretningsbrugere har adgang til rensede og ofte aggregerede data, og de har ikke mulighed for at fÄ rÄ data.
SelvfÞlgelig afhÊnger alt af din case. Hvis du ikke har problemer med dit datalager, sÄ har du slet ikke brug for et datalag. Men nÄr der opstÄr problemer med mangel pÄ plads, kapacitet eller omkostningerne er afgÞrende, kan det vÊre vÊrd at overveje et datalag. Derfor er datalag meget populÊrt. Her er et eksempel pÄ arkitekturen for et datalag:
Ved at bruge datalagtilgangen indlÊser vi rÄ data i vores datalag (batch eller streaming), hvorefter vi behandler dataene efter behov. Datalaget giver forretningsbrugere mulighed for at oprette deres egne datatransformationer (ETL/ELT) eller analysere data i Business Intelligence-lÞsninger (hvis der er den nÞdvendige driver).
MĂ„let med enhver analytisk lĂžsning er at tjene forretningsbrugerne. Derfor skal vi altid arbejde ud fra forretningskravene. (Hos Amazon er dette et af principperne â working backwards).
Ved at arbejde med bÄde datalager og datalag kan vi sammenligne begge lÞsninger:
Den vigtigste konklusion, man kan drage, er, at datalagring ikke konkurrerer med datalogen, men snarere supplerer den. Men det er op til dig at beslutte, hvad der passer til dit tilfĂŠlde. Det er altid interessant at prĂžve selv og drage de rigtige konklusioner.
Jeg vil ogsÄ gerne fortÊlle om et af de tilfÊlde, hvor jeg begyndte at bruge dataloge-tilgangen. Det er ret banalt, jeg forsÞgte at bruge et ELT-vÊrktÞj (vi havde Matillion ETL) og Amazon Redshift; min lÞsning fungerede, men levede ikke op til kravene.
Jeg havde brug for at tage web-logs, transformere dem og aggregere dem for at levere data til 2 tilfĂŠlde:
- Marketingteamet Ăžnskede at analysere bot-aktivitet for SEO
- IT ville gerne se metrikker omkring webstedsydelse
Meget enkle, meget simple logs. Her er et eksempel:
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"En fil vejede 1-4 megabyte.
Men der var én udfordring. Vi havde 7 domÊner verden over, og der blev skabt 7000 filer pÄ én dag. Det er ikke sÄ stort, i alt 50 gigabyte. Men stÞrrelsen pÄ vores Redshift-kluster var ogsÄ lille (4 noder). IndlÊsningen af en fil pÄ den traditionelle mÄde tog ca. et minut. SÄledes blev opgaven ikke lÞst direkte. Og det var i denne situation, at jeg besluttede at bruge dataloge-tilgangen. LÞsningen sÄ omtrent sÄdan ud:
Den er ret simpel (jeg vil bemĂŠrke, at fordelen ved at arbejde i skyen er enkeltheden). Jeg brugte:
- AWS Elastic Map Reduce (Hadoop) som beregningskraft
- AWS S3 som filopbevaring med mulighed for datakryptering og adgangsbegrĂŠnsning
- Spark som InMemory beregningskraft og PySpark til logik og datatransformation
- Parquet som resultat af Sparks arbejde
- AWS Glue Crawler som metadata indsamler om nye data og partitioner
- Redshift Spectrum som SQL-interface til datalogen for eksisterende Redshift-brugere
Det mindste EMR+Spark-kluster behandlede alle filerne pÄ 30 minutter. Der er ogsÄ andre tilfÊlde for AWS, isÊr mange relateret til Alexa, hvor der er meget data.
For nylig blev jeg opmĂŠrksom pĂ„ en af ulemperne ved datalakes â GDPR. Problemet opstĂ„r, nĂ„r en kunde beder om at fĂ„ sine data slettet, og dataene er gemt i en af filerne, hvor vi ikke kan bruge Data Manipulation Language og DELETE-kommandoen, som vi ville gĂžre med en database.
Jeg hÄber, at artiklen har afklaret forskellen mellem datalagre og datalakes. Hvis den var interessant, kan jeg oversÊtte flere af mine artikler eller artikler fra professionelle skribenter, jeg fÞlger. Jeg kan ogsÄ fortÊlle om de lÞsninger, jeg arbejder med, og deres arkitektur.
Kilde: habr.com
