Ten artykuł jest tłumaczeniem mojego artykułu na temat nośnika - , który okazał się dość popularny, prawdopodobnie ze względu na swoją prostotę. Dlatego zdecydowałem się napisać to po rosyjsku i trochę dodać, aby zwykłemu człowiekowi niebędącemu specjalistą danych było jasne, czym jest hurtownia danych (DW), a czym jest jezioro danych (Data Lake) i w jaki sposób działają dogadywać się razem.
Dlaczego chciałem napisać o jeziorze danych? Zajmuję się danymi i analityką od ponad 10 lat, a teraz na pewno pracuję z big data w Amazon Alexa AI w Cambridge, czyli w Bostonie, chociaż mieszkam w Victorii na wyspie Vancouver i często odwiedzam Boston, Seattle i W Vancouver, a czasem nawet w Moskwie, przemawiam na konferencjach. Ja też od czasu do czasu piszę, ale piszę głównie po angielsku i już pisałam , muszę też podzielić się trendami analitycznymi z Ameryki Północnej i czasami do nich piszę .
Zawsze współpracowałem z hurtowniami danych, a od 2015 roku zacząłem ściśle współpracować z Amazon Web Services i ogólnie przerzuciłem się na analitykę chmurową (AWS, Azure, GCP). Od 2007 roku obserwuję ewolucję rozwiązań analitycznych, a nawet pracowałem dla dostawcy hurtowni danych Teradata i wdrażałem je w Sberbanku i wtedy pojawił się Big Data z Hadoop. Wszyscy zaczęli mówić, że era przechowywania danych minęła i teraz wszystko jest na Hadoopie, a potem znowu zaczęto mówić o Data Lake, że teraz definitywnie nadszedł koniec hurtowni danych. Ale na szczęście (może niestety dla niektórych, którzy zarobili dużo pieniędzy, konfigurując Hadoopa), hurtownia danych nie zniknęła.
W tym artykule przyjrzymy się, czym jest jezioro danych. Ten artykuł jest przeznaczony dla osób, które mają niewielkie lub żadne doświadczenie z hurtowniami danych.
Na zdjęciu jezioro Bled, jest to jedno z moich ulubionych jezior, chociaż byłam tam tylko raz, zapamiętałam je do końca życia. Ale porozmawiamy o innym typie jeziora - jeziorze danych. Być może wielu z Was słyszało już o tym określeniu nie raz, ale jeszcze jedna definicja nikomu nie zaszkodzi.
Na początek przytoczę najpopularniejsze definicje Data Lake:
„plik przechowujący wszelkiego rodzaju surowe dane, który jest dostępny do analizy przez dowolną osobę w organizacji” – Martin Fowler.
„Jeśli uważasz, że baza danych to butelka wody – oczyszczonej, zapakowanej i zapakowanej w celu wygodnej konsumpcji, to jezioro danych to ogromny zbiornik wody w jej naturalnej postaci. Użytkownicy, mogę zbierać dla siebie wodę, nurkować głęboko, eksplorować” – James Dixon.
Teraz już wiemy na pewno, że data Lake to przede wszystkim analityka, która pozwala na przechowywanie dużych ilości danych w ich oryginalnej formie oraz że mamy do nich niezbędny i wygodny dostęp.
Często lubię upraszczać sprawy, jeśli uda mi się wyjaśnić skomplikowany termin prostymi słowami, to sam rozumiem, jak to działa i do czego jest potrzebne. Pewnego dnia szperałem w galerii zdjęć iPhone'a i dotarło do mnie, że to prawdziwe jezioro danych, zrobiłem nawet slajd na konferencje:
Wszystko jest bardzo proste. Robimy zdjęcie telefonem, zdjęcie jest zapisywane na telefonie i można je zapisać w iCloud (przechowywanie plików w chmurze). Telefon zbiera także metadane zdjęć: to, co jest wyświetlane, znacznik geograficzny, czas. Dzięki temu możemy skorzystać z przyjaznego interfejsu iPhone'a, aby znaleźć nasze zdjęcie, a nawet zobaczyć wskaźniki, np. Gdy szukam zdjęć ze słowem ogień, znajduję 3 zdjęcia z obrazem ognia. Dla mnie jest to coś w rodzaju narzędzia Business Intelligence, które działa bardzo szybko i przejrzyście.
No i oczywiście nie możemy zapominać o bezpieczeństwie (autoryzacji i uwierzytelnianiu), w przeciwnym razie nasze dane mogą łatwo trafić do domeny publicznej. Dużo doniesień jest o dużych korporacjach i startupach, których dane stały się publicznie dostępne na skutek zaniedbań deweloperów i nieprzestrzegania prostych zasad.
Nawet tak prosty obraz pomaga nam wyobrazić sobie, czym jest jezioro danych, czym różni się od tradycyjnej hurtowni danych i jej głównych elementów:
- Ładowanie danych (Pozyskiwanie) jest kluczowym elementem jeziora danych. Dane mogą trafiać do hurtowni danych na dwa sposoby – wsadowo (ładowanie w odstępach czasu) i strumieniowo (przepływ danych).
- Nośnik danych (Magazyn) to główny składnik Data Lake. Zależało nam na tym, aby pamięć masowa była łatwo skalowalna, wyjątkowo niezawodna i tania. Na przykład w AWS jest to S3.
- Katalog i wyszukiwanie (Katalog i wyszukiwanie) - aby uniknąć Data Swamp (to wtedy zrzucamy wszystkie dane na jeden stos i wtedy nie da się z nimi pracować), musimy stworzyć warstwę metadanych, która będzie klasyfikować dane dzięki czemu użytkownicy mogą łatwo znaleźć dane potrzebne do analizy. Dodatkowo możesz skorzystać z dodatkowych rozwiązań wyszukiwania takich jak ElasticSearch. Wyszukiwanie pomaga użytkownikowi znaleźć potrzebne dane za pośrednictwem przyjaznego interfejsu.
- Przetwarzanie (Proces) – ten krok odpowiada za przetwarzanie i przekształcanie danych. Możemy przekształcać dane, zmieniać ich strukturę, czyścić i wiele więcej.
- bezpieczeństwo (Bezpieczeństwo) — ważne jest, aby poświęcić czas na projektowanie zabezpieczeń rozwiązania. Na przykład szyfrowanie danych podczas przechowywania, przetwarzania i ładowania. Ważne jest, aby stosować metody uwierzytelniania i autoryzacji. Wreszcie potrzebne jest narzędzie audytowe.
Z praktycznego punktu widzenia jezioro danych możemy scharakteryzować trzema atrybutami:
- Zbieraj i przechowuj wszystko — jezioro danych zawiera wszystkie dane, zarówno surowe, nieprzetworzone dane z dowolnego okresu, jak i dane przetworzone/wyczyszczone.
- Głębokie skanowanie — jezioro danych umożliwia użytkownikom eksplorację i analizę danych.
- Elastyczny dostęp — Jezioro danych zapewnia elastyczny dostęp do różnych danych i różnych scenariuszy.
Teraz możemy porozmawiać o różnicy między hurtownią danych a jeziorem danych. Zwykle ludzie pytają:
- A co z hurtownią danych?
- Czy zastępujemy hurtownię danych jeziorem danych, czy ją rozbudowujemy?
- Czy nadal można obejść się bez jeziora danych?
Krótko mówiąc, nie ma jednoznacznej odpowiedzi. Wszystko zależy od konkretnej sytuacji, umiejętności zespołu i budżetu. Na przykład migracja hurtowni danych z Oracle do AWS i utworzenie jeziora danych przez spółkę zależną Amazon – Woot – .
Z drugiej strony dostawca Snowflake twierdzi, że nie trzeba już myśleć o jeziorze danych, ponieważ ich platforma danych (do 2020 r. była to hurtownia danych) umożliwia połączenie jeziora danych i hurtowni danych. Nie pracowałem zbyt wiele ze Snowflake, a to naprawdę wyjątkowy produkt, który może to zrobić. Cena emisji to inna sprawa.
Podsumowując, moim osobistym zdaniem nadal potrzebujemy hurtowni danych jako głównego źródła danych do naszych raportów, a wszystko, co nie pasuje, przechowujemy w jeziorze danych. Cała rola analityki polega na zapewnieniu biznesowi łatwego dostępu do podejmowania decyzji. Co by nie mówić, użytkownicy biznesowi pracują wydajniej z hurtownią danych niż z jeziorem danych, na przykład w Amazonie – jest Redshift (hurtownia danych analitycznych) i jest Redshift Spectrum/Athena (interfejs SQL dla jeziora danych w S3 oparty na Ula/Presto). To samo dotyczy innych nowoczesnych hurtowni danych analitycznych.
Przyjrzyjmy się typowej architekturze hurtowni danych:
To klasyczne rozwiązanie. Dysponujemy systemami źródłowymi, wykorzystując ETL/ELT kopiujemy dane do hurtowni danych analitycznych i podłączamy je do rozwiązania Business Intelligence (moim ulubionym jest Tableau, a Waszym?).
To rozwiązanie ma następujące wady:
- Operacje ETL/ELT wymagają czasu i zasobów.
- Z reguły pamięć do przechowywania danych w analitycznej hurtowni danych nie jest tania (np. Redshift, BigQuery, Teradata), gdyż musimy kupić cały klaster.
- Użytkownicy biznesowi mają dostęp do oczyszczonych i często zagregowanych danych, ale nie mają dostępu do danych surowych.
Oczywiście wszystko zależy od Twojego przypadku. Jeśli nie masz problemów z hurtownią danych, to jezioro danych w ogóle nie jest Ci potrzebne. Jeśli jednak pojawią się problemy związane z brakiem miejsca, mocą lub ceną, można rozważyć opcję jeziora danych. Właśnie dlatego jezioro danych jest bardzo popularne. Oto przykład architektury jeziora danych:
Stosując podejście do jeziora danych, ładujemy surowe dane do naszego jeziora danych (wsadowo lub strumieniowo), a następnie przetwarzamy dane w razie potrzeby. Jezioro danych pozwala użytkownikom biznesowym tworzyć własne transformacje danych (ETL/ELT) lub analizować dane w rozwiązaniach Business Intelligence (jeśli dostępny jest niezbędny sterownik).
Celem każdego rozwiązania analitycznego jest obsługa użytkowników biznesowych. Dlatego zawsze musimy pracować zgodnie z wymogami biznesowymi. (W Amazonie jest to jedna z zasad – praca wstecz).
Pracując zarówno z hurtownią danych, jak i jeziorem danych, możemy porównać oba rozwiązania:
Główny wniosek, jaki można wyciągnąć, jest taki, że hurtownia danych nie konkuruje z jeziorem danych, a raczej je uzupełnia. Ale to Ty decydujesz, co jest właściwe w Twoim przypadku. Zawsze ciekawie jest spróbować samemu i wyciągnąć właściwe wnioski.
Chciałbym Wam również opowiedzieć o jednym z przypadków, kiedy zacząłem stosować podejście Data Lake. Wszystko jest dość banalne, próbowałem użyć narzędzia ELT (mieliśmy Matillion ETL) i Amazon Redshift, moje rozwiązanie zadziałało, ale nie spełniło wymagań.
Musiałem pobrać dzienniki internetowe, przekształcić je i zagregować, aby dostarczyć dane dla 2 przypadków:
- Zespół marketingowy chciał przeanalizować aktywność botów pod kątem SEO
- Dział IT chciał przyjrzeć się wskaźnikom wydajności witryny
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ł 1-4 megabajty.
Ale była jedna trudność. Mieliśmy 7 domen na całym świecie, a jednego dnia powstało 7000 50 tysięcy plików. To niewiele więcej, tylko 4 gigabajtów. Ale rozmiar naszego klastra przesunięcia ku czerwieni był również niewielki (XNUMX węzły). Wczytanie jednego pliku w tradycyjny sposób trwało około minuty. Oznacza to, że problem nie został rozwiązany od razu. I tak właśnie było, gdy zdecydowałem się zastosować podejście jeziora danych. Rozwiązanie wyglądało mniej więcej tak:
Jest to dość proste (zaznaczam, że zaletą pracy w chmurze jest prostota). Użyłem:
- Zmniejszenie elastycznej mapy AWS (Hadoop) w celu uzyskania mocy obliczeniowej
- AWS S3 jako magazyn plików z możliwością szyfrowania danych i ograniczania dostępu
- Spark jako moc obliczeniowa InMemory i PySpark do transformacji logiki i danych
- Parkiet w wyniku Sparka
- AWS Glue Crawler jako moduł zbierający metadane o nowych danych i partycjach
- Redshift Spectrum jako interfejs SQL do jeziora danych dla istniejących użytkowników Redshift
Najmniejszy klaster EMR+Spark przetworzył cały stos plików w 30 minut. Istnieją inne przypadki dla AWS, szczególnie wiele związanych z Alexą, gdzie jest dużo danych.
Niedawno dowiedziałem się, że jedną z wad jeziora danych jest 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 ten artykuł wyjaśnił różnicę między hurtownią danych a jeziorem danych. Jeśli jesteś zainteresowany, mogę przetłumaczyć więcej moich artykułów lub artykułów profesjonalistów, których czytam. A także opowiem o rozwiązaniach, z którymi pracuję i ich architekturze.
Źródło: www.habr.com