Czy potrzebujemy jeziora danych? A co z magazynem danych?

To jest artykuł będący tłumaczeniem mojego tekstu na medium — Wprowadzenie do Data Lake, który okazał się dość popularny, prawdopodobnie z powodu swojej prostoty. Dlatego postanowiłem napisać go w języku polskim i trochę rozbudować, aby przeciętny człowiek, który nie jest specjalistą od danych, zrozumiał, czym jest hurtownia danych (DW), a czym jest jezioro danych (Data Lake) i jak obie te koncepcje współżyją.

Dlaczego chciałem napisać o jeziorze danych? Pracuję z danymi i analityką od ponad 10 lat, a obecnie pracuję z wielkimi danymi w Amazon Alexa AI w Cambridge, które znajdują się w Bostonie, chociaż sam mieszkam na wyspie Vancouver w Victorii i często bywają w Bostonie, Seattle oraz Vancouver, a czasem nawet w Moskwie na konferencjach. Czasami piszę, ale głównie po angielsku, napisałem już kilka książek, mam też potrzebę dzielenia się trendami analitycznymi z Ameryki Północnej i czasami piszę w Telegramie.

Zawsze pracowałem z hurtowniami danych, a od 2015 roku intensywnie pracuję z Amazon Web Services, a w ogóle przeszedłem na chmurę analityczną (AWS, Azure, GCP). Obserwowałem ewolucję rozwiązań analitycznych od 2007 roku, a nawet pracowałem w firmie dostarczającej hurtownie danych Teradata, wdrażając je w Sberbanku, wtedy wszyscy zaczęli mówić, że era hurtowni się skończyła i teraz wszyscy są na Hadoopie, a potem zaczęli mówić o jeziorze danych, że to już na pewno koniec hurtowni danych. Ale na szczęście (może dla niektórych nieszczęście, którzy zarabiali dużo na konfigurowaniu Hadoop), hurtownie danych nie zniknęły.

W tym artykule przyjrzymy się, czym jest jezioro danych. Artykuł jest skierowany do osób, które mają małe doświadczenie z hurtowniami danych lub w ogóle go nie mają.

Na zdjęciu jezioro Bled, to jedno z moich ulubionych jezior, chociaż byłem tam tylko raz, ale zapamiętałem je na całe życie. Ale porozmawiajmy o innym rodzaju jeziora — jeziorze danych. Być może wielu z Was już nieraz słyszało ten termin, ale dodatkowa definicja nie zaszkodzi.

Przede wszystkim oto najpopularniejsze definicje Jeziora Danych:

"pliki przechowujące wszystkie rodzaje surowych danych, które są dostępne do analizy przez kogokolwiek w organizacji" — Martin Fowler.

„Jeśli myślisz, że jezioro danych to butelka wody — oczyszczonej, zapakowanej i rozłożonej do wygodnego użycia, to jezioro danych to ogromny zbiornik wody w jej naturalnej formie. Użytkownicy mogą nabierać wodę dla siebie, nurkować w głąb, badać” — James Dickson.

Teraz na pewno wiemy, że jezioro danych to kwestia analityki, pozwala nam przechowywać duże ilości danych w ich pierwotnej formie i mamy do nich niezbędny oraz wygodny dostęp.

Często lubię upraszczać rzeczy; jeśli mogę wyjaśnić skomplikowany termin prostymi słowami, to znaczy, że zrozumiałem, jak to działa i po co to jest potrzebne. Kiedyś grzebałem w iPhonie w galerii zdjęć, i nasunęło mi się, że to właśnie prawdziwe jezioro danych. Zrobiłem nawet slajd na konferencje:

To bardzo proste. Robimy zdjęcie telefonem, zdjęcie zapisuje się w telefonie i może być przechowywane w iCloud (przechowalnia plików w chmurze). Telefon zbiera również metadane zdjęcia: co jest przedstawione, geotag, czas. W rezultacie możemy korzystać z wygodnego interfejsu iPhone'a, aby znaleźć nasze zdjęcie i przy tym widzimy nawet dane, na przykład, gdy szukam zdjęć słowem ogień (fire), znajduję 3 zdjęcia przedstawiające ognisko. Dla mnie to jak narzędzie Business Intelligence, które działa bardzo szybko i precyzyjnie.

I oczywiście nie możemy zapominać o bezpieczeństwie (autoryzacji i uwierzytelnianiu), w przeciwnym razie nasze dane mogą łatwo trafić do publicznego dostępu. Jest wiele wiadomości o dużych firmach i startupach, których dane trafiły do publicznego dostępu z powodu niedbalstwa programistów i nieprzestrzegania prostych zasad.

Nawet taki prosty obrazek pomaga nam wyobrazić sobie, czym jest jezioro danych, jego różnice w porównaniu do tradycyjnego magazynu danych oraz jego główne elementy:

1. Ładowanie danych (Ingestion) — kluczowy składnik jeziora danych. Dane mogą trafiać do magazynu danymi na dwa sposoby — batch (ładowanie w interwałach) oraz streaming (strumień danych).
2. Magazyn plików (Storage) — główny składnik Jeziora Danych. Musimy mieć zapewnione, że magazyn jest łatwo skalowalny, niezwykle niezawodny i ma niskie koszty. Na przykład w AWS to S3.
3. Katalog i Wyszukiwanie (Katalog i Wyszukiwanie) — aby uniknąć Bagna Danych (kiedy wszystkie dane są wrzucane w jedno miejsce, co później uniemożliwia ich przetwarzanie), musimy stworzyć warstwę metadanych do klasyfikacji danych, aby użytkownicy mogli łatwo znaleźć potrzebne informacje do analizy. Dodatkowo można zastosować inne rozwiązania do wyszukiwania, na przykład ElasticSearch. Wyszukiwanie umożliwia użytkownikowi odnalezienie potrzebnych danych za pomocą przyjaznych interfejsów.
4. Przetwarzanie (Proces) — ten krok odpowiada za przetwarzanie i transformację danych. Możemy przekształcać dane, zmieniać ich struktury, oczyszczać je i wiele więcej.
5. Bezpieczeństwo (Bezpieczeństwo) — ważne jest, aby poświęcić czas na projektowanie bezpieczeństwa rozwiązania. Na przykład szyfrowanie danych podczas przechowywania, przetwarzania i ładowania. Kluczowe jest stosowanie metod autoryzacji i uwierzytelniania. Podsumowując, potrzebne są narzędzia do audytu.

Z praktycznego punktu widzenia możemy scharakteryzować jezioro danych trzema atrybutami:

1. Zbieraj i przechowuj cokolwiek — jezioro danych zawiera wszystkie dane, zarówno surowe, nieprzetworzone dane z dowolnego okresu, jak i przetworzone / oczyszczone dane.
2. Głęboka analiza — jezioro danych umożliwia użytkownikom badanie i analizowanie danych.
3. Elastyczny dostęp — jezioro danych zapewnia elastyczny dostęp do różnych danych i różnych scenariuszy.

Teraz można porozmawiać o różnicy między magazynem danych a jeziorem danych. Zazwyczaj ludzie pytają:

• A co z magazynem danych?
• Czy zastępujemy magazyn danych jeziorem danych, czy go rozszerzamy?
• Czy można jednak obejść się bez jeziora danych?

Krótko mówiąc, nie ma jednoznacznej odpowiedzi. Wszystko zależy od konkretnej sytuacji, umiejętności w zespole i budżetu. Na przykład migracja magazynu danych z Oracle do AWS i stworzenie jeziora danych przez spółkę córkę Amazona — Woot — Nasza historia jeziora danych: Jak Woot.com zbudowało bezserwerowe jezioro danych na AWS.

Z drugiej strony, dostawca Snowflake twierdzi, że nie musisz już myśleć o jeziorze danych, ponieważ ich platforma danych (do 2020 roku było to magazyn danych) pozwala na połączenie jeziora danych z magazynem danych. Pracowałem nieco ze Snowflake i to naprawdę unikalny produkt, który to potrafi. Cena to inna kwestia.

Podsumowując, moim osobistym zdaniem, nadal potrzebujemy hurtowni danych jako głównego źródła danych do naszych raportów, a wszystko, co się nie zmieści, przechowujemy w jeziorze danych. Główna rola analityki to zapewnienie biznesowi wygodnego dostępu do podejmowania decyzji. Biznesowi użytkownicy pracują efektywniej z hurtownią danych niż z jeziorem danych; na przykład, w Amazonie są Redshift (hurtownia danych analitycznych) oraz Redshift Spectrum/Athena (interfejs SQL do jeziora danych w S3 oparty na Hive/Presto). To samo dotyczy innych nowoczesnych hurtowni danych analitycznych.

Przyjrzyjmy się typowej architekturze hurtowni danych:

To klasyczne rozwiązanie. Mamy systemy źródłowe, a za pomocą ETL/ELT kopiujemy dane do hurtowni danych analitycznych i łączymy je z rozwiązaniem Business Intelligence (moje ulubione to Tableau, a jakie jest twoje?).

Takie rozwiązanie ma następujące wady:

• Operacje ETL/ELT wymagają czasu i zasobów.
• Zazwyczaj pamięć do przechowywania danych w hurtowni danych analitycznych nie jest tania (na przykład Redshift, BigQuery, Teradata), ponieważ musimy kupić cały klaster.
• Biznesowi użytkownicy mają dostęp do oczyszczonych i często agregowanych danych i nie mają możliwości uzyskania surowych danych.

Oczywiście, wszystko zależy od twojego przypadku. Jeśli nie masz problemów ze swoją hurtownią danych, to zupełnie nie potrzebujesz jeziora danych. Ale gdy pojawiają się problemy z brakiem miejsca, mocy lub cena ma kluczowe znaczenie, warto rozważyć opcję jeziora danych. Dlatego jezioro danych jest bardzo popularne. Oto przykład architektury jeziora danych:

Stosując podejście jeziora danych, ładujemy surowe dane do naszego jeziora danych (wsadowo lub strumieniowo), a następnie przetwarzamy dane w razie potrzeby. Jezioro danych pozwala biznesowym użytkownikom tworzyć własne transformacje danych (ETL/ELT) lub analizować dane w rozwiązaniach Business Intelligence (jeśli jest odpowiedni sterownik).

Celem każdego rozwiązania analitycznego jest służenie użytkownikom biznesowym. Dlatego zawsze musimy działać zgodnie z wymaganiami biznesu. (W Amazonie to jedna z zasad — working backwards).

Pracując zarówno z hurtownią danych, jak i z jeziorem danych, możemy porównać oba rozwiązania:

Główny wniosek, który można wysunąć, to że hurtownia danych wcale nie konkuruje z jeziorem danych, a raczej je uzupełnia. To zawsze wy zależy, co jest odpowiednie dla waszego przypadku. Zawsze warto spróbować samodzielnie i wyciągnąć właściwe wnioski.

Chciałbym również opowiedzieć o jednym przypadku, w którym zacząłem używać podejścia jeziora danych. Wszystko jest dość banalne; próbowałem użyć narzędzia ELT (mieliśmy Matillion ETL) oraz Amazon Redshift, moje rozwiązanie działało, ale nie spełniało wszystkich wymogów.

Musiałem wziąć logi z sieci, przekształcić je i zgrupować, aby dostarczyć dane dla dwóch przypadków:

1. Zespół marketingowy chciał analizować aktywność botów pod kątem SEO
2. IT chciało oglądać metryki dotyczące działania stron internetowych

Bardzo proste, bardzo proste logi. Oto przykład:

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" "-" "-"

Jeden plik ważył od 1 do 4 megabajtów.

Ale napotkałem jeden problem. Mieliśmy 7 domen na całym świecie, a w ciągu jednego dnia tworzono 7000 plików. To nie był ogromny wolumen, zaledwie 50 gigabajtów. Ale rozmiar naszego klastra Redshift był również niewielki (4 węzły). Ładowanie jednego pliku tradycyjną metodą zajmowało około minuty. To znaczy, zadanie nie mogło być rozwiązane w trybie od razu. I to był ten przypadek, w którym zdecydowałem się na podejście jeziora danych. Rozwiązanie wyglądało mniej więcej tak:

Jest dość proste (chcę zaznaczyć, że zaletą pracy w chmurze jest prostota). Użyłem:

• AWS Elastic Map Reduce (Hadoop) jako moc obliczeniowa
• AWS S3 jako magazyn plików z możliwością szyfrowania danych i ograniczania dostępu
• Spark jako moc obliczeniowa InMemory oraz PySpark do logiki i transformacji danych
• Parquet jako wynik pracy Sparka
• AWS Glue Crawler jako zbieracz metadanych o nowych danych i partycjach
• Redshift Spectrum jako interfejs SQL do jeziora danych dla istniejących użytkowników Redshift

Najmniejszy klaster EMR+Spark przetwarzał całą partię plików w 30 minut. Istnieją również inne przypadki dla AWS, szczególnie wiele związanych z Alexą, gdzie danych jest bardzo dużo.

Ostatnio dowiedziałem się o jednym z wad jeziora danych — to RODO. Problem polega na tym, że gdy klient prosi o ich usunięcie, a dane znajdują się w jednym z plików, nie możemy użyć języka manipulacji danymi i operacji DELETE jak w bazie danych.

Mam nadzieję, że artykuł wyjaśnił różnicę między magazynem danych a jeziorem danych. Jeśli było ciekawie, mogę przetłumaczyć jeszcze moje artykuły lub artykuły profesjonalistów, których czytam. Mogę również opowiedzieć o rozwiązaniach, z którymi pracuję, oraz ich architekturze.

Źródło: habr.com