Software Development / BI

Architektura Lakehouse, koncepcja Delta Lake w usłudze DataBricks

6 października, 2021 0
Podziel się:

Firmy posiadają coraz więcej źródeł danych: systemy CRM, dane transakcyjne, ewidencje czasu pracy, wiadomości e-mail oraz posty z portali społecznościowych. Wszystkie te systemy generują ogromne ilości danych, które trzeba przetwarzać, magazynować i aktualizować. Popularną praktyką jest budowanie hurtowni danych, do których ładowane są dane uprzednio oczyszczone, uporządkowane i skatalogowane. Użytkownicy mają łatwy dostęp do zgromadzonych tam informacji przy użyciu prostych narzędzi. Pojawiają się jednak pewne wątpliwości: czy hurtownie danych odpowiadają na wszystkie potrzeby i co zrobić, kiedy taka koncepcja okaże się niewystarczająca? Odpowiedź wydaje się oczywista – trzeba poszukać innego, bardziej złożonego i umożliwiającego przetworzenie większej ilości danych rozwiązania. Jednym z takich rozwiązań jest Data Lake.

Koncepcja Data Lake

Data Lake to w dosłownym tłumaczeniu jezioro danych. Definicja wskazuje, że w Data Lake gromadzi się dane z wielu źródeł w swojej naturalnej formie – pliki płaskie, tabele, dokumenty, pliki blob (binary large object, czyli pliki binarne znacznej objętości tj. filmy, pliki muzyczne, grafiki). Sam termin Data Lake został zaproponowany przez Jamesa Dixona. James, ówczesny dyrektor ds. technologii w Pentaho, ukuł ten termin, aby zbudować kontrast w stosunku do data martów, które są mniejszym repozytorium atrybutów pochodzących z surowych danych.

W ostatnich latach znacząco wzrosło zapotrzebowanie na systemy przetwarzania danych. Każda firma chce użyć danych, które posiada, aby dowiedzieć się więcej o zwyczajach klientów, trendach w branży oraz o nowych kierunkach rozwoju. Zajmują się tym systemy analityczne oraz algorytmy uczenia maszynowego.

Termin Data Lake opisuje strategię przechowywania danych – nie jest to zdefiniowana technologia. Podobnie, termin hurtownia danych opisuje strategię możliwą do osiągnięcia przy użyciu różnych platform. Data Lake często występuje w parze jako element platformy Hadoop, jednakże implementacja tego typu rozwiązania jest możliwa również w innych środowiskach (Amazon S3, Azure Data Lake Storage).

Główną różnicą między hurtownią danych a Data Lake jest forma przechowywania danych oraz ich schemat. W hurtowni dane trzymane są w tabelach relacyjnych oraz kostkach OLAP i posiadają schemat, do którego muszą pasować zapisywane rekordy (schema-on-write). Jeżeli zabraknie atrybutów lub ich wartość będzie spoza przewidzianego zakresu, to próba zapisu zakończy się niepowodzeniem.

W Data Lake dane zapisywane są w swoich oryginalnych formatach, bez określonego schematu. Zdefiniowanie schematu wymagane jest dopiero, gdy chcemy je odczytać lub zapisać w tabelach (schema-on-read). Pozwala to zaoszczędzić czas podczas zapisu, jednakże powoduje ryzyko utraty jakości danych przy odczycie, gdyż poprawność danych nie jest sprawdzana w momencie zapisywania.

Przykłady zastosowania Data Lake

Jako prosty przykład Data Lake można wskazać chmurową usługę zapisywania zdjęć (iCloud, Google Photos itp.). Dodajemy zdjęcia na serwerze, system zbiera metadane o fotografii (czas wykonania, dane aparatu, lokalizację itp). Jako wynik tych działań otrzymujemy możliwość nie tylko wyszukiwania zdjęcia po dacie wykonania, ale też po lokalizacji, godzinie, dominującym kolorze i osobach, które są na zdjęciach. Idąc dalej, bardziej skomplikowanym przykładem jest potrzeba przeanalizowania zestawu plików będących zdjęciami, filmami, notatkami głosowymi i plikami tekstowymi. Aby je poprawnie przeanalizować, dla każdego typu danych trzeba stworzyć zestaw atrybutów, które, bazując na metadanych, pozwalałyby na przetwarzanie takich plików. Wydobywaniem i analizą tych oraz wielu innych szczegółów zajmują się algorytmy uczenia maszynowego.

Przepływ danych w Data Lake

  1. Na powyższych przykładach możemy wyodrębnić klika etapów, przez które przechodzą dane zgromadzone w Data Lake:
  2. Ładowanie danych – pojedyncze pliki binarne, płaskie lub dane strumieniowe.
  3. Zapis – zapewnienie trwałości zapisu przy niskim koszcie przechowywania.
  4. Katalogowanie – klasyfikowanie danych ułatwia ich przeszukiwanie.
  5. Przetwarzanie – umożliwienie analizy zgromadzonych danych przy użyciu specjalnych języków zapytań, np. SQL, Scala, Python i określonych narzędzi, np. Spark, Hive, Impala.
  6. Zabezpieczanie – bezpieczeństwo zgromadzanych danych jest elementem wieńczącym dany proces.

Korzyści i zagrożenia dodawania danych do Data Lake

Takie podejście do ładowania danych ma swoje dobre i złe strony. Do Data Lake można załadować wszystko bardzo szybko. W momencie, kiedy zbieramy dane nieprzydatne, tworzymy bagno danych – Data Swamp. Dane są dostępne, ale trudne do analizy, często bezużyteczne.

Pomimo swoich niedoskonałości odpowiednie rozwijanie i utrzymywanie takiej struktury, niesie za sobą olbrzymie możliwości analityczne. Koncepcja Data Lake jest bardzo szeroko stosowana. Poprzez swoją popularność i niezawodność ewolucja Data Lake w ciekawsze i bardziej zaawansowane implementacje to tylko kwestia czasu.

Koncepcja Lakehouse

Lakehouse to stosunkowo nowy termin w paradygmacie architektury platform do przetwarzania danych. Jest to rozwiązanie, które implementuje elementy z koncepcji data warehouse oraz Data Lake. Na rynku są dostępne narzędzia, które pozwalają skorzystać z tej koncepcji: Apache Drill – silnik obsługujący zapytania niezależne od schematu bazy danych oraz Amazon Athena – umożliwia użytkownikowi zapytanie o dane bezpośrednio z S3 po utworzeniu definicji schematu.

Różnice pomiędzy Data Lake a Lakehouse

W stosunku do Data Lake, Lakehouse cechuje się takimi możliwościami:

  • Transakcje ACID (atomicity, consistency, isolation, durability) – dzięki serializowanym poziomom izolacji zyskujemy pewność, że użytkownik nie dostanie niespójnych danych.
  • Wymaganie schematu przy zapisie danych. Jest to dodatkowy mechanizm przeciwdziałający zapisywaniu niepasujących danych.
  • Wersjonowanie danych umożliwia wycofanie zmian wprowadzonych do bazy.
  • Bezpośredni dostęp do danych dla narzędzi BI. Przyspiesza to ładowanie danych do raportów i likwiduje potrzebę kopiowania danych z Data Lake do hurtowni danych.
  • Otwartość na udostępnianie danych poprzez obsługę zapytań przez API.
  • Odseparowanie danych od mechanizmów ich przetwarzania. Oznacza to, że klaster danych jest oddzielony od klastra obliczeniowego. Dzięki takiemu rozwiązaniu klastry są skalowalne niezależnie od siebie.
  • Wsparcie różnych źródeł danych: plików tekstowych, obrazów i plików video.
  • Obsługa streamingu od źródła danych aż do udostępnienia danych na raporcie. Nie trzeba utrzymywać osobnego systemu obsługującego dane strumieniowe.

Zastosowanie Delta Lake

Najpopularniejszym narzędziem implementującym architekturę Lakehouse jest zaproponowana przez firmę Databricks usługa nazwana Delta Lake. Zapewnia ono następujące funkcje:

  • transakcje ACID,
  • wersjonowanie,
  • jednoczesny odczyt i zapis danych,
  • bezpośredni dostęp do danych zgromadzonych w Delta Lake,
  • separacja klastra danych i klastra obliczeniowego,
  • wsparcie plików z danymi ustrukturyzowanymi i nieustrukturyzowanymi w tym IoT,
  • wsparcie streamingu danych.

Zastosowanie tej koncepcji znacznie ułatwia dodawanie źródeł danych i administrowanie już istniejącymi tabelami. Za umożliwienie tych operacji odpowiada zastosowanie logu transakcji, do którego jest zapisywana każda operacja w Delta Lake.

Każdy zapis, modyfikacja i usunięcie tabeli są odnotowane w logu. Można go podejrzeć, sprawdzić, jakie działania zostały wykonane i w razie potrzeby przywrócić konkretną wersję.

Delta Lake jako koncepcja chmurowa

Koncepcja Delta Lake jest koncepcją chmurową, dostępną dla chmur: AWS, GCP oraz Azure. Poniżej przedstawiam krótki opis tego, jak połączono funkcjonalności dla poszczególnych rozwiązań.

AWS i Azure

Dla AWS i Azure implementacja Delta Lake składa się z dwóch platform: kontroli (control plane) i danych (data plane):

  • Platforma kontroli obejmuje usługi backendowe, którymi Databricks zarządza na własnym koncie AWS bądź Azure. Zapisana jest tam konfiguracja i skrypty użytkownika.
  • Platforma danych jest zarządzana przez użytkownika i tam fizycznie zapisane są dane. Można użyć łączników Databricks, aby łączyć się z zewnętrznymi źródłami danych spoza konta AWS użytkownika. Istnieje również możliwość pozyskiwania danych z zewnętrznych źródeł typu strumieniowego, takich jak: dane zdarzeń (events), dane przesyłania strumieniowego (streaming data), dane IoT i inne.

Dane zawsze znajdują się na koncie platformy Azure na płaszczyźnie danych i we własnych źródłach użytkownika, a nie na płaszczyźnie sterowania, dzięki czemu pliki źródłowe i dostęp do danych jest kontrolowany przez użytkownika.

Google Cloud Plarform

Podobne podejście zastosowane jest w integracji Databricks i Google Cloud Platform. Korzystanie z Databricks jest dostępne przez Google Kubernetes Engine.

Databricks w Google Cloud jest silnie zintegrowany z Google BigQuery. Dzięki tej integracji developerzy mogą rozszerzyć istniejące możliwości Databricks Lakehouse, które działają w Google Cloud. Mają możliwość wykorzystania Google BigQuery do celów analitycznych, ostatecznie upraszczając przetwarzanie danych, zwiększając wykorzystanie oraz tworząc nowe modele biznesowe.

Podsumowanie

Koncepcja Lakehouse będzie coraz bardziej zyskiwać na popularności. Łączy w sobie najlepsze praktyki związane z hurtowniami danych i rozwiązaniami klasy Big Data. Lakehouse umożliwia implementowanie struktur danych i zarządzanie nimi w sposób znany z hurtowni danych, wykorzystując tanią i skalowalną pamięć masową w Data Lake.

Może ona uprościć przepływ danych poprzez nałożenie wymagań dotyczących zapisu. Chodzi tu o konkretne typy danych, wielkości tabel i wstępne czyszczenie danych już na wczesnym etapie przetwarzania. Zapisywane dane będą już w takim momencie gotowe, aby umożliwić konsumentom danych (analitykom i naukowcom) bezpośrednie połączenie do pamięci masowej (np. AWS S3, Azure Blob) i uruchamianie na niej konkretnych zapytań.

Komercyjne rozwiązanie zaproponowane przez Databricks są dostępne na wszystkich dużych platformach chmurowych (AWS, Azure, GCP). Wszyscy zainteresowani mogą przetestować to rozwiązania za darmo przez okres 14 dni (Databricks Platform dla biznesu i rozwiązań komercyjnych) lub skorzystać z nielimitowanego dostępu do Databricks Community (w celach edukacyjnych nałożono ograniczenia dotyczące ilości przetwarzania danych).

Kategorie: Software Development, BI
Michał Schatt
Autor: Michał Schatt
Software Engineer w Sii. Ma 7-letnie doświadczenie w obszarze Business Intelligence. Od 3 lat pracuje z rozwiązaniami klasy BigData. Po pracy lubi jeździć na rowerze lub pieszo przemierzać górskie szlaki.

    Imię i nazwisko (wymagane)

    Adres email (wymagane)

    Temat

    Treść wiadomości

    Zostaw komentarz