Dit artikel is een vertaling van mijn artikel op medium - , dat behoorlijk populair bleek te zijn, waarschijnlijk vanwege zijn eenvoud. Daarom besloot ik het in het Russisch te schrijven en er een beetje aan toe te voegen om aan een gewoon persoon, die geen dataspecialist is, duidelijk te maken wat een datawarehouse (DW) is, en wat een datameer is (Data Lake), en hoe ze met elkaar op kunnen schieten .
Waarom wilde ik over het datameer schrijven? Ik werk al meer dan tien jaar met data en analyses, en nu werk ik zeker met big data bij Amazon Alexa AI in Cambridge, in Boston, hoewel ik in Victoria op Vancouver Island woon en vaak Boston, Seattle bezoek , en In Vancouver, en soms zelfs in Moskou, spreek ik op conferenties. Ik schrijf ook van tijd tot tijd, maar ik schrijf voornamelijk in het Engels, en ik heb al geschreven , Ik heb ook behoefte om analysetrends uit Noord-Amerika te delen, en ik schrijf daar soms in .
Ik heb altijd met datawarehouses gewerkt en sinds 2015 begon ik nauw samen te werken met Amazon Web Services en schakelde ik over het algemeen over naar cloudanalyses (AWS, Azure, GCP). Ik heb de evolutie van analyseoplossingen sinds 2007 geobserveerd en heb zelfs voor de datawarehouse-leverancier Teradata gewerkt en deze bij Sberbank geïmplementeerd, en toen verscheen Big Data met Hadoop. Iedereen begon te zeggen dat het tijdperk van opslag voorbij was en dat alles nu op Hadoop stond, en toen begonnen ze weer over Data Lake te praten, dat nu definitief het einde van het datawarehouse was gekomen. Maar gelukkig (misschien helaas voor sommigen die veel geld verdienden met het opzetten van Hadoop) verdween het datawarehouse niet.
In dit artikel gaan we kijken naar wat een data lake is. Dit artikel is bedoeld voor mensen die weinig of geen ervaring hebben met datawarehouses.
Op de foto staat het meer van Bled, dit is een van mijn favoriete meren, hoewel ik er maar één keer was, heb ik het de rest van mijn leven onthouden. Maar we zullen het hebben over een ander type meer: een datameer. Misschien hebben velen van jullie al meer dan eens over deze term gehoord, maar nog een definitie zal niemand kwaad doen.
Allereerst zijn hier de meest populaire definities van een Data Lake:
“een bestandsopslag van alle soorten ruwe gegevens die beschikbaar zijn voor analyse door iedereen in de organisatie” - Martin Fowler.
“Als je denkt dat een datamart een fles water is – gezuiverd, verpakt en verpakt voor gemakkelijk gebruik, dan is een datameer een enorm reservoir met water in zijn natuurlijke vorm. Gebruikers, ik kan water voor mezelf verzamelen, diep duiken, verkennen” - James Dixon.
Nu we zeker weten dat een data lake over analytics gaat, kunnen we grote hoeveelheden data in de oorspronkelijke vorm opslaan en hebben we de noodzakelijke en gemakkelijke toegang tot de data.
Ik hou er vaak van om dingen te vereenvoudigen, als ik een complexe term in eenvoudige woorden kan uitleggen, dan begrijp ik voor mezelf hoe het werkt en waarvoor het nodig is. Op een dag snuffelde ik rond in de iPhone-fotogalerij en het drong tot me door: dit is een echt datameer, ik heb zelfs een dia gemaakt voor conferenties:
Alles is heel eenvoudig. We maken een foto op de telefoon, de foto wordt op de telefoon opgeslagen en kan worden opgeslagen in iCloud (bestandsopslag in de cloud). De telefoon verzamelt ook metagegevens van foto's: wat wordt weergegeven, geotag, tijd. Hierdoor kunnen we de gebruiksvriendelijke interface van de iPhone gebruiken om onze foto te vinden en zien we zelfs indicatoren. Als ik bijvoorbeeld naar foto's zoek met het woord vuur, vind ik 3 foto's met een afbeelding van een brand. Voor mij is dit net een Business Intelligence-tool die heel snel en accuraat werkt.
En natuurlijk mogen we de beveiliging (autorisatie en authenticatie) niet vergeten, anders kunnen onze gegevens gemakkelijk in het publieke domein terechtkomen. Er is veel nieuws over grote bedrijven en startups waarvan de gegevens publiekelijk beschikbaar zijn geworden vanwege de nalatigheid van ontwikkelaars en het niet volgen van eenvoudige regels.
Zelfs zo'n eenvoudig beeld helpt ons ons voor te stellen wat een datameer is, de verschillen met een traditioneel datawarehouse en de belangrijkste elementen ervan:
- Data laden (Ingestie) is een belangrijk onderdeel van het datameer. Gegevens kunnen op twee manieren het datawarehouse binnenkomen: batch (laden met tussenpozen) en streaming (gegevensstroom).
- Bestandsopslag (Storage) is het hoofdbestanddeel van het Data Lake. We wilden dat de opslag gemakkelijk schaalbaar, uiterst betrouwbaar en goedkoop moest zijn. In AWS is dit bijvoorbeeld S3.
- Catalogus en zoeken (Catalogus en zoeken) - om het gegevensmoeras te vermijden (dit is wanneer we alle gegevens op één stapel dumpen, en dan is het onmogelijk om ermee te werken), moeten we een metagegevenslaag maken om de gegevens te classificeren zodat gebruikers gemakkelijk de gegevens kunnen vinden die ze nodig hebben voor analyse. Daarnaast kunt u aanvullende zoekoplossingen gebruiken, zoals ElasticSearch. Zoeken helpt de gebruiker de benodigde gegevens te vinden via een gebruiksvriendelijke interface.
- Verwerking (Proces) - deze stap is verantwoordelijk voor het verwerken en transformeren van gegevens. We kunnen gegevens transformeren, de structuur ervan veranderen, deze opschonen en nog veel meer.
- veiligheid (Beveiliging) - Het is belangrijk om tijd te besteden aan het beveiligingsontwerp van de oplossing. Bijvoorbeeld gegevensversleuteling tijdens opslag, verwerking en laden. Het is belangrijk om authenticatie- en autorisatiemethoden te gebruiken. Ten slotte is er behoefte aan een audittool.
Vanuit praktisch oogpunt kunnen we een datameer karakteriseren aan de hand van drie kenmerken:
- Verzamel en bewaar alles — het datameer bevat alle gegevens, zowel onbewerkte, onverwerkte gegevens voor een bepaalde periode als verwerkte/opgeschoonde gegevens.
- Diepe scan — een datameer stelt gebruikers in staat gegevens te verkennen en te analyseren.
- Flexibele toegang — Het datameer biedt flexibele toegang voor verschillende gegevens en verschillende scenario's.
Nu kunnen we het hebben over het verschil tussen een datawarehouse en een datameer. Meestal vragen mensen:
- Hoe zit het met het datawarehouse?
- Vervangen we het datawarehouse door een datameer of breiden we het uit?
- Is het nog mogelijk om zonder data lake te werken?
Kortom: er is geen duidelijk antwoord. Het hangt allemaal af van de specifieke situatie, de vaardigheden van het team en het budget. Bijvoorbeeld het migreren van een datawarehouse naar Oracle naar AWS en het creëren van een datameer door een dochteronderneming van Amazon - Woot - .
Aan de andere kant zegt leverancier Snowflake dat je niet meer aan een datameer hoeft te denken, omdat je met hun dataplatform (tot 2020 was het een datawarehouse) zowel een datameer als een datawarehouse kunt combineren. Ik heb niet veel met Snowflake gewerkt en het is echt een uniek product dat dit kan. De prijs van de uitgifte is een andere zaak.
Concluderend is mijn persoonlijke mening dat we nog steeds een datawarehouse nodig hebben als de belangrijkste gegevensbron voor onze rapportage, en wat daar niet bij past, slaan we op in een datameer. De hele rol van analytics is om bedrijven gemakkelijke toegang te bieden om beslissingen te nemen. Wat je ook zegt, zakelijke gebruikers werken efficiënter met een datawarehouse dan met een datameer, bijvoorbeeld in Amazon - er is Redshift (analytisch datawarehouse) en er is Redshift Spectrum/Athena (SQL-interface voor een datameer in S3 gebaseerd op Bijenkorf/Presto). Hetzelfde geldt voor andere moderne analytische datawarehouses.
Laten we eens kijken naar een typische datawarehouse-architectuur:
Dit is een klassieke oplossing. We hebben bronsystemen, met behulp van ETL/ELT kopiëren we gegevens naar een analytisch datawarehouse en koppelen deze aan een Business Intelligence-oplossing (mijn favoriet is Tableau, hoe zit het met die van jou?).
Deze oplossing heeft de volgende nadelen:
- ETL/ELT-bewerkingen vereisen tijd en middelen.
- In de regel is geheugen voor het opslaan van gegevens in een analytisch datawarehouse niet goedkoop (bijvoorbeeld Redshift, BigQuery, Teradata), omdat we een heel cluster moeten kopen.
- Zakelijke gebruikers hebben toegang tot opgeschoonde en vaak geaggregeerde gegevens en hebben geen toegang tot ruwe gegevens.
Het hangt natuurlijk allemaal af van uw geval. Als je geen problemen hebt met je datawarehouse, dan heb je helemaal geen data lake nodig. Maar wanneer er zich problemen voordoen waarbij ruimtegebrek, stroomvoorziening of prijs een sleutelrol spelen, dan kunt u de optie van een datameer overwegen. Daarom is het datameer erg populair. Hier is een voorbeeld van een data lake-architectuur:
Met behulp van de data lake-aanpak laden we onbewerkte gegevens in ons datameer (batch of streaming) en verwerken we de gegevens vervolgens indien nodig. Met het datameer kunnen zakelijke gebruikers hun eigen datatransformaties (ETL/ELT) creëren of data analyseren in Business Intelligence-oplossingen (als de benodigde driver beschikbaar is).
Het doel van elke analyseoplossing is om zakelijke gebruikers te bedienen. Daarom moeten we altijd werken volgens de zakelijke vereisten. (Bij Amazon is dit een van de principes: achteruit werken).
Door met zowel een datawarehouse als een datameer te werken, kunnen we beide oplossingen vergelijken:
De belangrijkste conclusie die getrokken kan worden is dat het datawarehouse niet concurreert met het datameer, maar juist een aanvulling daarop is. Maar het is aan u om te beslissen wat geschikt is voor uw geval. Het is altijd interessant om het zelf te proberen en de juiste conclusies te trekken.
Ik wil u ook graag een van de gevallen vertellen waarin ik de data lake-aanpak begon te gebruiken. Alles is vrij triviaal, ik probeerde een ELT-tool te gebruiken (we hadden Matillion ETL) en Amazon Redshift, mijn oplossing werkte, maar voldeed niet aan de vereisten.
Ik moest weblogs maken, deze transformeren en samenvoegen om gegevens voor twee gevallen te verkrijgen:
- Het marketingteam wilde botactiviteit analyseren voor SEO
- IT wilde kijken naar de prestatiestatistieken van websites
Heel eenvoudig, heel eenvoudige logboeken. Hier is een voorbeeld:
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" "-" "-"Eén bestand woog 1-4 megabytes.
Maar er was één moeilijkheid. We hadden zeven domeinen over de hele wereld en er werden op één dag 7 bestanden aangemaakt. Dit is niet veel meer volume, slechts 7000 gigabyte. Maar de omvang van ons Roodverschuivingscluster was ook klein (50 knooppunten). Het laden van één bestand op de traditionele manier duurde ongeveer een minuut. Dat wil zeggen dat het probleem niet frontaal werd opgelost. En dit was het geval toen ik besloot de data lake-aanpak te gebruiken. De oplossing zag er ongeveer zo uit:
Het is vrij eenvoudig (ik wil opmerken dat het voordeel van werken in de cloud de eenvoud is). Ik gebruikte:
- AWS Elastic Map Reduce (Hadoop) voor rekenkracht
- AWS S3 als bestandsopslag met de mogelijkheid om gegevens te versleutelen en de toegang te beperken
- Spark als InMemory-rekenkracht en PySpark voor logica en datatransformatie
- Parket als resultaat van Spark
- AWS Glue Crawler als metadataverzamelaar over nieuwe gegevens en partities
- Redshift Spectrum als SQL-interface naar het datameer voor bestaande Redshift-gebruikers
Het kleinste EMR+Spark-cluster verwerkte de volledige stapel bestanden in 30 minuten. Er zijn andere gevallen voor AWS, vooral veel gerelateerd aan Alexa, waar veel gegevens zijn.
Onlangs leerde ik dat een van de nadelen van een datameer de AVG is. Het probleem is dat wanneer de klant vraagt om de gegevens te verwijderen en de gegevens zich in een van de bestanden bevinden, we de Data Manipulation Language en DELETE-bewerking niet kunnen gebruiken zoals in een database.
Ik hoop dat dit artikel het verschil tussen een datawarehouse en een datameer heeft verduidelijkt. Als je geïnteresseerd bent, kan ik meer van mijn artikelen of artikelen van professionals die ik lees, vertalen. En vertel ook over de oplossingen waarmee ik werk en hun architectuur.
Bron: www.habr.com