Den här artikeln är en översättning av min artikel om medium - , som visade sig vara ganska populär, förmodligen på grund av sin enkelhet. Därför bestämde jag mig för att skriva det på ryska och lägga till lite för att göra det klart för en vanlig person som inte är en dataspecialist vad ett datalager (DW) är och vad en datasjö är (Data Lake), och hur de komma överens.
Varför ville jag skriva om datasjön? Jag har arbetat med data och analys i över 10 år, och nu jobbar jag definitivt med big data på Amazon Alexa AI i Cambridge, som ligger i Boston, även om jag bor i Victoria på Vancouver Island och ofta besöker Boston, Seattle , och I Vancouver, och ibland till och med i Moskva, talar jag på konferenser. Jag skriver också då och då, men jag skriver främst på engelska, och jag har redan skrivit , Jag har också ett behov av att dela analytiska trender från Nordamerika, och jag skriver ibland in .
Jag har alltid arbetat med datalager, och sedan 2015 började jag arbeta nära Amazon Web Services, och övergick generellt till molnanalys (AWS, Azure, GCP). Jag har observerat utvecklingen av analyslösningar sedan 2007 och till och med arbetat för datavarehusleverantören Teradata och implementerat det på Sberbank, och det var då Big Data med Hadoop dök upp. Alla började säga att lagringens era passerat och nu var allt på Hadoop, och sedan började de prata om Data Lake, igen, att nu hade slutet för datalagret definitivt kommit. Men lyckligtvis (kanske tyvärr för en del som tjänade mycket pengar på att sätta upp Hadoop) försvann inte datalagret.
I den här artikeln ska vi titta på vad en datasjö är. Den här artikeln är avsedd för personer som har liten eller ingen erfarenhet av datalager.
På bilden är Lake Bled, det här är en av mina favoritsjöar, fast jag var där bara en gång, jag kom ihåg den för resten av mitt liv. Men vi kommer att prata om en annan typ av sjö - en datasjö. Kanske har många av er redan hört talas om denna term mer än en gång, men ytterligare en definition kommer inte att skada någon.
Först och främst, här är de mest populära definitionerna av en Data Lake:
"en fillagring av alla typer av rådata som är tillgänglig för analys av alla i organisationen" - Martin Fowler.
"Om du tror att en datamart är en flaska vatten - renad, förpackad och förpackad för bekväm konsumtion, då är en datasjö en enorm reservoar av vatten i sin naturliga form. Användare, jag kan samla vatten till mig själv, dyka djupt, utforska” - James Dixon.
Nu vet vi med säkerhet att en datasjö handlar om analys, den tillåter oss att lagra stora mängder data i sin ursprungliga form och vi har den nödvändiga och bekväma tillgången till datan.
Jag gillar ofta att förenkla saker, om jag kan förklara en komplex term med enkla ord så förstår jag själv hur det fungerar och vad det behövs till. En dag letade jag runt i iPhones fotogalleri och det gick upp för mig, det här är en riktig datasjö, jag gjorde till och med en bild för konferenser:
Allt är väldigt enkelt. Vi tar ett foto på telefonen, bilden sparas på telefonen och kan sparas till iCloud (molnfillagring). Telefonen samlar också in fotometadata: vad som visas, geotagg, tid. Som ett resultat kan vi använda det användarvänliga gränssnittet på iPhone för att hitta vårt foto och vi ser till och med indikatorer, till exempel när jag söker efter foton med ordet brand hittar jag 3 foton med en bild av en brand. För mig är detta precis som ett Business Intelligence-verktyg som fungerar väldigt snabbt och tydligt.
Och självklart får vi inte glömma säkerheten (auktorisering och autentisering), annars kan vår data lätt hamna i det offentliga området. Det finns många nyheter om stora företag och startups vars data blev allmänt tillgänglig på grund av försumlighet från utvecklare och underlåtenhet att följa enkla regler.
Även en sådan enkel bild hjälper oss att föreställa oss vad en datasjö är, dess skillnader från ett traditionellt datalager och dess huvudelement:
- Laddar data (Intag) är en nyckelkomponent i datasjön. Data kan komma in i datalagret på två sätt - batch (laddning med intervaller) och streaming (dataflöde).
- Fillagring (Storage) är huvudkomponenten i Data Lake. Vi behövde att lagringen skulle vara lätt skalbar, extremt pålitlig och låg kostnad. Till exempel, i AWS är det S3.
- Katalog och Sök (Katalog och sökning) - för att vi ska undvika dataträsket (det är när vi dumpar all data i en hög och sedan är det omöjligt att arbeta med det), måste vi skapa ett metadatalager för att klassificera datan så att användarna enkelt kan hitta den data som de behöver för analys. Dessutom kan du använda ytterligare söklösningar som ElasticSearch. Sökning hjälper användaren att hitta den information som krävs genom ett användarvänligt gränssnitt.
- Bearbetning (Process) - detta steg är ansvarigt för bearbetning och omvandling av data. Vi kan transformera data, ändra dess struktur, rensa den och mycket mer.
- Безопасность (Säkerhet) – Det är viktigt att lägga tid på säkerhetsdesignen av lösningen. Till exempel datakryptering under lagring, bearbetning och laddning. Det är viktigt att använda autentiserings- och auktoriseringsmetoder. Slutligen behövs ett revisionsverktyg.
Ur praktisk synvinkel kan vi karakterisera en datasjö med tre attribut:
- Samla och förvara vad som helst — datasjön innehåller all data, både obearbetad obearbetad data för en viss tidsperiod och bearbetad/rensad data.
- Deep Scan — en datasjö tillåter användare att utforska och analysera data.
- Flexibel åtkomst — Datasjön ger flexibel åtkomst för olika data och olika scenarier.
Nu kan vi prata om skillnaden mellan ett datalager och en datasjö. Vanligtvis frågar folk:
- Hur är det med datalagret?
- Byter vi ut datalagret med en datasjö eller utökar vi det?
- Är det fortfarande möjligt att klara sig utan en datasjö?
Kort sagt, det finns inget klart svar. Allt beror på den specifika situationen, lagets kompetens och budgeten. Till exempel, migrera ett datalager till Oracle till AWS och skapa en datasjö av ett Amazon-dotterbolag - Woot - .
Å andra sidan säger leverantören Snowflake att du inte längre behöver tänka på en datasjö, eftersom deras dataplattform (fram till 2020 var det ett datalager) låter dig kombinera både en datasjö och ett datalager. Jag har inte jobbat mycket med Snowflake, och det är verkligen en unik produkt som kan göra detta. Priset på frågan är en annan sak.
Sammanfattningsvis är min personliga åsikt att vi fortfarande behöver ett datalager som den huvudsakliga datakällan för vår rapportering, och det som inte passar lagrar vi i en datasjö. Hela analysens roll är att ge enkel tillgång för företag att fatta beslut. Vad man än kan säga så arbetar affärsanvändare mer effektivt med ett datalager än en datasjö, till exempel i Amazon – det finns Redshift (analytiskt datalager) och det finns Redshift Spectrum/Athena (SQL-gränssnitt för en datasjö i S3 baserat på Hive/Presto). Detsamma gäller andra moderna analytiska datalager.
Låt oss titta på en typisk datalagerarkitektur:
Detta är en klassisk lösning. Vi har källsystem, med ETL/ELT kopierar vi data till ett analytiskt datalager och ansluter det till en Business Intelligence-lösning (min favorit är Tableau, hur är det med din?).
Denna lösning har följande nackdelar:
- ETL/ELT-verksamhet kräver tid och resurser.
- Som regel är minne för att lagra data i ett analytiskt datalager inte billigt (till exempel Redshift, BigQuery, Teradata), eftersom vi behöver köpa ett helt kluster.
- Företagsanvändare har tillgång till rensad och ofta aggregerad data och har inte tillgång till rådata.
Naturligtvis beror allt på ditt fall. Om du inte har problem med ditt datalager så behöver du ingen datasjö alls. Men när problem uppstår med brist på utrymme, ström eller pris spelar en nyckelroll, då kan du överväga alternativet med en datasjö. Det är därför datasjön är väldigt populär. Här är ett exempel på en datasjöarkitektur:
Med hjälp av datasjömetoden laddar vi in rådata i vår datasjö (batch eller streaming), sedan bearbetar vi data efter behov. Datasjön tillåter företagsanvändare att skapa sina egna datatransformationer (ETL/ELT) eller analysera data i Business Intelligence-lösningar (om den nödvändiga drivrutinen finns tillgänglig).
Målet med alla analyslösningar är att tjäna affärsanvändare. Därför måste vi alltid arbeta efter affärsmässiga krav. (På Amazon är detta en av principerna - att arbeta baklänges).
Genom att arbeta med både ett datalager och en datasjö kan vi jämföra båda lösningarna:
Den huvudsakliga slutsatsen som kan dras är att datalagret inte konkurrerar med datasjön, utan snarare kompletterar den. Men det är upp till dig att avgöra vad som är rätt för ditt fall. Det är alltid intressant att prova själv och dra de rätta slutsatserna.
Jag skulle också vilja berätta om ett av fallen när jag började använda datasjömetoden. Allt är ganska trivialt, jag försökte använda ett ELT-verktyg (vi hade Matillion ETL) och Amazon Redshift, min lösning fungerade, men passade inte kraven.
Jag behövde ta webbloggar, transformera dem och aggregera dem för att tillhandahålla data för 2 fall:
- Marknadsföringsteamet ville analysera botaktivitet för SEO
- IT ville titta på webbplatsens prestandastatistik
Mycket enkla, mycket enkla loggar. Här är ett exempel:
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 vägde 1-4 megabyte.
Men det fanns en svårighet. Vi hade 7 domäner runt om i världen och 7000 50 tusen filer skapades på en dag. Det här är inte mycket mer volym, bara 4 gigabyte. Men storleken på vårt Redshift-kluster var också liten (XNUMX noder). Att ladda en fil på traditionellt sätt tog ungefär en minut. Det vill säga att problemet inte löstes direkt. Och detta var fallet när jag bestämde mig för att använda datasjömetoden. Lösningen såg ut ungefär så här:
Det är ganska enkelt (jag vill notera att fördelen med att arbeta i molnet är enkelheten). Jag använde:
- AWS Elastic Map Reduce (Hadoop) för Compute Power
- AWS S3 som fillagring med möjlighet att kryptera data och begränsa åtkomst
- Spark som InMemory datorkraft och PySpark för logik och datatransformation
- Parkett till följd av Spark
- AWS Glue Crawler som en metadatasamlare om ny data och partitioner
- Redshift Spectrum som ett SQL-gränssnitt till datasjön för befintliga Redshift-användare
Det minsta EMR+Spark-klustret bearbetade hela stapeln med filer på 30 minuter. Det finns andra fall för AWS, särskilt många relaterade till Alexa, där det finns mycket data.
Nyligen lärde jag mig att en av nackdelarna med en datasjö är GDPR. Problemet är när klienten ber om att ta bort det och data finns i en av filerna, kan vi inte använda Data Manipulation Language och DELETE-operation som i en databas.
Jag hoppas att den här artikeln har klargjort skillnaden mellan ett datalager och en datasjö. Om du var intresserad kan jag översätta fler av mina artiklar eller artiklar från professionella jag läst. Och berätta även om de lösningar jag jobbar med och deras arkitektur.
Källa: will.com