Denne artikel er en oversættelse af min artikel om medium - , som viste sig at være ret populær, sandsynligvis på grund af sin enkelhed. Derfor besluttede jeg at skrive det på russisk og tilføje lidt for at gøre det klart for en almindelig person, der ikke er dataspecialist, hvad et datavarehus (DW) er, og hvad en datasø er (Data Lake), og hvordan de tage sig sammen.
Hvorfor ville jeg skrive om datasøen? Jeg har arbejdet med data og analyser i over 10 år, og nu arbejder jeg bestemt med big data hos Amazon Alexa AI i Cambridge, som ligger i Boston, selvom jeg bor i Victoria på Vancouver Island og ofte besøger Boston, Seattle , og I Vancouver, og nogle gange endda i Moskva, taler jeg til konferencer. Jeg skriver også fra tid til anden, men jeg skriver hovedsageligt på engelsk, og jeg har allerede skrevet , Jeg har også et behov for at dele analytiske tendenser fra Nordamerika, og jeg skriver nogle gange ind .
Jeg har altid arbejdet med datavarehuse, og siden 2015 begyndte jeg at arbejde tæt sammen med Amazon Web Services, og gik generelt over til cloud analytics (AWS, Azure, GCP). Jeg har observeret udviklingen af analyseløsninger siden 2007 og har endda arbejdet for datavarehusleverandøren Teradata og implementeret det hos Sberbank, og det var da Big Data med Hadoop dukkede op. Alle begyndte at sige, at æraen med opbevaring var forbi, og nu var alt på Hadoop, og så begyndte de igen at tale om Data Lake, at nu var enden på datavarehuset helt sikkert kommet. Men heldigvis (måske desværre for nogle, der tjente mange penge på at oprette Hadoop), forsvandt datavarehuset ikke.
I denne artikel vil vi se på, hvad en datasø er. Denne artikel er beregnet til personer, der har ringe eller ingen erfaring med datavarehuse.
På billedet ses Bled-søen, dette er en af mine yndlingssøer, selvom jeg kun var der én gang, huskede jeg den resten af mit liv. Men vi vil tale om en anden type sø - en datasø. Måske har mange af jer allerede hørt om dette udtryk mere end én gang, men endnu en definition vil ikke skade nogen.
Først og fremmest er her de mest populære definitioner af en Data Lake:
"en fillagring af alle typer rådata, der er tilgængelig for analyse af alle i organisationen" - Martin Fowler.
"Hvis du tror, at en datamart er en flaske vand - renset, pakket og pakket til bekvemt forbrug, så er en datasø et enormt reservoir af vand i sin naturlige form. Brugere, jeg kan samle vand til mig selv, dykke dybt, udforske” - James Dixon.
Nu ved vi med sikkerhed, at en datasø handler om analyse, den giver os mulighed for at gemme store mængder data i sin oprindelige form, og vi har den nødvendige og bekvemme adgang til dataene.
Jeg kan ofte godt lide at forenkle tingene, hvis jeg kan forklare et komplekst begreb med enkle ord, så forstår jeg selv, hvordan det fungerer, og hvad det skal bruges til. En dag kiggede jeg rundt i iPhone-fotogalleriet, og det gik op for mig, det her er en rigtig datasø, jeg lavede endda et dias til konferencer:
Alt er meget enkelt. Vi tager et billede på telefonen, billedet gemmes på telefonen og kan gemmes i iCloud (cloud file storage). Telefonen indsamler også fotometadata: hvad der vises, geo-tag, tid. Som et resultat kan vi bruge den brugervenlige grænseflade på iPhone til at finde vores foto, og vi ser endda indikatorer, for eksempel, når jeg søger efter billeder med ordet brand, finder jeg 3 billeder med et billede af en brand. For mig er dette ligesom et Business Intelligence-værktøj, der fungerer meget hurtigt og klart.
Og selvfølgelig må vi ikke glemme sikkerheden (autorisation og autentificering), ellers kan vores data nemt ende i det offentlige domæne. Der er mange nyheder om store virksomheder og startups, hvis data blev offentligt tilgængelige på grund af uagtsomhed fra udviklere og manglende overholdelse af simple regler.
Selv et så simpelt billede hjælper os med at forestille os, hvad en datasø er, dens forskelle fra et traditionelt datavarehus og dets hovedelementer:
- Indlæser data (Indtagelse) er en nøglekomponent i datasøen. Data kan komme ind i datavarehuset på to måder - batch (indlæsning med intervaller) og streaming (dataflow).
- Fillagring (Lagring) er hovedkomponenten i Data Lake. Vi havde brug for, at lageret var let skalerbart, ekstremt pålideligt og lave omkostninger. For eksempel i AWS er det S3.
- Katalog og søgning (Katalog og søgning) - for at vi kan undgå datasumpen (det er når vi dumper alle data i én bunke, og så er det umuligt at arbejde med det), skal vi oprette et metadatalag til at klassificere dataene så brugerne nemt kan finde de data, de skal bruge til analyse. Derudover kan du bruge yderligere søgeløsninger såsom ElasticSearch. Søgning hjælper brugeren med at finde de nødvendige data gennem en brugervenlig grænseflade.
- Behandling (Proces) - dette trin er ansvarlig for behandling og transformation af data. Vi kan transformere data, ændre deres struktur, rense dem og meget mere.
- Безопасность (Sikkerhed) - Det er vigtigt at bruge tid på sikkerhedsdesignet af løsningen. For eksempel datakryptering under lagring, behandling og indlæsning. Det er vigtigt at bruge godkendelses- og godkendelsesmetoder. Endelig er der brug for et revisionsværktøj.
Fra et praktisk synspunkt kan vi karakterisere en datasø ved tre attributter:
- Saml og opbevar hvad som helst — datasøen indeholder alle data, både rå ubehandlede data for enhver tidsperiode og behandlede/rensede data.
- Dyb scanning — en datasø giver brugerne mulighed for at udforske og analysere data.
- Fleksibel adgang — Datasøen giver fleksibel adgang til forskellige data og forskellige scenarier.
Nu kan vi tale om forskellen mellem et datavarehus og en datasø. Normalt spørger folk:
- Hvad med datavarehuset?
- Erstatter vi datavarehuset med en datasø eller udvider vi det?
- Er det stadig muligt at undvære en datasø?
Kort sagt er der ikke noget klart svar. Det hele afhænger af den specifikke situation, holdets færdigheder og budgettet. For eksempel migrering af et datavarehus til Oracle til AWS og oprettelse af en datasø af et Amazon-datterselskab - Woot - .
På den anden side siger leverandøren Snowflake, at du ikke længere behøver at tænke på en datasø, da deres dataplatform (indtil 2020 var det et datavarehus) giver dig mulighed for at kombinere både en datasø og et datavarehus. Jeg har ikke arbejdet meget med Snowflake, og det er virkelig et unikt produkt, der kan gøre dette. Prisen på spørgsmålet er en anden sag.
Afslutningsvis er min personlige mening, at vi stadig har brug for et datavarehus som hovedkilden til data til vores rapportering, og hvad end der ikke passer, gemmer vi i en datasø. Hele analysens rolle er at give forretning let adgang til at træffe beslutninger. Uanset hvad man kan sige, så arbejder forretningsbrugere mere effektivt med et datavarehus end en datasø, for eksempel i Amazon – der er Redshift (analytisk datavarehus) og der er Redshift Spectrum/Athena (SQL interface til en datasø i S3 baseret på Hive/Presto). Det samme gælder andre moderne analytiske datavarehuse.
Lad os se på en typisk datavarehusarkitektur:
Dette er en klassisk løsning. Vi har kildesystemer, ved hjælp af ETL/ELT kopierer vi data ind i et analytisk datavarehus og forbinder det til en Business Intelligence-løsning (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 hukommelse til lagring af data i et analytisk datavarehus ikke billig (for eksempel Redshift, BigQuery, Teradata), da vi skal købe en hel klynge.
- Erhvervsbrugere har adgang til rensede og ofte aggregerede data og har ikke adgang til rådata.
Det afhænger selvfølgelig af din sag. Hvis du ikke har problemer med dit datavarehus, så behøver du slet ikke en datasø. Men når der opstår problemer med pladsmangel, strøm eller pris spiller en nøglerolle, så kan du overveje muligheden for en datasø. Derfor er datasøen meget populær. Her er et eksempel på en datasø-arkitektur:
Ved hjælp af data lake-tilgangen indlæser vi rådata i vores datasø (batch eller streaming), derefter behandler vi dataene efter behov. Datasøen giver forretningsbrugere mulighed for at skabe deres egne datatransformationer (ETL/ELT) eller analysere data i Business Intelligence-løsninger (hvis den nødvendige driver er tilgængelig).
Målet med enhver analyseløsning er at tjene forretningsbrugere. Derfor skal vi altid arbejde efter forretningsmæssige krav. (Hos Amazon er dette et af principperne - at arbejde baglæns).
Ved at arbejde med både et datavarehus og en datasø kan vi sammenligne begge løsninger:
Hovedkonklusionen, der kan drages, er, at datavarehuset ikke konkurrerer med datasøen, men derimod komplementerer den. Men det er op til dig at beslutte, hvad der er rigtigt for din sag. Det er altid interessant at prøve det selv og drage de rigtige konklusioner.
Jeg vil også gerne fortælle dig et af de tilfælde, hvor jeg begyndte at bruge data sø-tilgangen. Alt er ret trivielt, jeg prøvede at bruge et ELT-værktøj (vi havde Matillion ETL) og Amazon Redshift, min løsning virkede, men passede ikke til kravene.
Jeg var nødt til at tage weblogs, transformere dem og samle dem for at levere data til 2 tilfælde:
- Marketingteamet ønskede at analysere botaktivitet for SEO
- IT ønskede at se på hjemmesidens ydeevnemålinger
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 en vanskelighed. Vi havde 7 domæner rundt om i verden, og 7000 tusind filer blev oprettet på én dag. Dette er ikke meget mere volumen, kun 50 gigabyte. Men størrelsen på vores Redshift-klynge var også lille (4 noder). Indlæsning af en fil på traditionel vis tog omkring et minut. Det vil sige, at problemet ikke blev løst direkte. Og dette var tilfældet, da jeg besluttede mig for at bruge datasø-tilgangen. Løsningen så nogenlunde sådan ud:
Det er ret simpelt (jeg vil bemærke, at fordelen ved at arbejde i skyen er enkelhed). Jeg brugte:
- AWS Elastic Map Reduce (Hadoop) til Compute Power
- AWS S3 som fillager med mulighed for at kryptere data og begrænse adgang
- Spark som InMemory computerkraft og PySpark til logik og datatransformation
- Parket som følge af Spark
- AWS Glue Crawler som metadataindsamler om nye data og partitioner
- Redshift Spectrum som en SQL-grænseflade til datasøen for eksisterende Redshift-brugere
Den mindste EMR+Spark-klynge behandlede hele stakken af filer på 30 minutter. Der er andre sager til AWS, især mange relateret til Alexa, hvor der er meget data.
For nylig har jeg lært, at en af ulemperne ved en datasø er GDPR. Problemet er, at når klienten beder om at slette det, og dataene er i en af filerne, kan vi ikke bruge Data Manipulation Language og DELETE operation som i en database.
Jeg håber, at denne artikel har klarlagt forskellen mellem et datavarehus og en datasø. Hvis du var interesseret, kan jeg oversætte flere af mine artikler eller artikler fra fagfolk, jeg læser. Og også fortælle om de løsninger jeg arbejder med og deres arkitektur.
Kilde: www.habr.com