Data Lake na AWS

Data Lake na AWS-ie. Budowa, problemy i rozwiązania

Czy macie swoje repozytoria kodu? Co z danymi? Jak je zbieracie? Tak, wiemy, to wcale nie takie łatwe. Gdy dane pochodzą z wielu źródeł, powstały w różnych formatach i przychodzą z różną częstotliwością, wtedy trzeba specjalistycznych narzędzi do specjalnych zadań. Narzędzi jest wiele, jednak mamy do opowiedzenia wam o naszym produkcyjnym rozwiązaniu na AWS. Cel był jeden: sprowadzić dane do formy, która pozwoli później targetować reklamy na użytkownikach oglądających filmy na platformie klienta.

Noemi KowalewskaNoemi Kowalewska. Software Developer w Clearcode. Doświadczona programistka, pracująca od paru lat przy projektach związanych z AWS gdzie przetwarzane są ogromne ilości danych. Wielokrotna mentorka warsztatów z Pythona i lutowania. Poza tym uwielbia w wolnych chwilach chodzić po górach, zwiedzać industrialne obiekty i podziemia.

Tomasz KlemensTomasz Klemens. Software Developer w Clearcode. Karierę akademicką z zakresu chemii zmienił na programowanie, dzięki temu w końcu znajduje czas na warzenie piwa. Od ponad 2 lat zajmuje się Pythonem i backendem, chociaż hobbystycznie uczy się też frontendu (React, Typescript). Przez ostatnie kilka miesięcy sporo pracował przy projektach związanych z AWS-em, Big Data i przetwarzaniem danych za pomocą rozwiązań opartych o Apache Spark.


Czym jest Data Lake?

Podstawowe informacje

Na każdy kroku towarzyszą nam dane. Gdy włączamy telefon, laptop czy kupujemy pietruszkę, gdzieś jest zapisywana informacja o tych czynnościach. Trzy razy na sekundę wytwarzamy ilość danych porównywalną z zawartością wszystkich zbiorów biblioteki Kongresu USA – tak twierdzi Nate Silver, znany statystyk, redaktor naczelny FiveThirtyEight. Jednak przy dużej ilości danych pojawiają się problemy, co z nimi robić? Nie bez powodu dane nazywa się ropą XXI wieku, ponieważ można z nich wyciągać ogromną wartość. Najpierw jednak trzeba je uporządkować.

Wyobraźcie sobie korporację, która ma wiele różnych działów i w każdej inny system, przez co ogrom różnych danych w przeróżnych formatach:

  • pliki płaskie (CSV, logs, XML, JSON),
  • nieustrukturyzowane dane (e-maile, dokumenty, PDF-y), 
  • dane binarne (obrazki, dźwięk, video),
  • ustrukturyzowane – bazy danych.

Muszą dzielić się danymi między sobą i jest to straszne skomplikowane. Każdy ma swój sposób dzielenia się nimi, niektóre są już przetworzone, inne surowe. Totalny bałagan. Tutaj właśnie frustracje przechowywania i dzielenia się danymi ratuje Data Lake. Pozwala on na:

  • operacje na danych – odpytywanie, przetwarzanie, 
  • bezpieczeństwo – kontrolę dostępu uprawnionym osobom,
  • analitykę – bez przenoszenia możliwość analizy analitycznej,
  • nieustannych ruch danych – duży przyrost plików to nie problem,
  • łatwe zrozumienie zawartości przez katalogowanie i indeksowanie.

Duża elastyczność w tym rozwiązaniu jest spowodowana tym, że w odróżnieniu od hurtowni danych, gdzie stosuje się podejście Schema-on-Write (już przy zapisie decydujemy o strukturze), tutaj mamy Schema-on-Read (dopiero przy odczycie modelujemy schemat). Od lat 80 powszechnie uważa się  hurtownie danych za podstawowy sposób na wyciąganie wiedzy z dużych zbiorów. Od początku miały także jeden duży minus, jakim są koszty. W przedstawionym rozwiązaniu możemy magazynować tanio bardzo duże ilości danych, dopiero gdy pojawi się potrzeba dostosowania ich do oczekiwanych struktur.

Jeziora różnych dostawców

Azure:

Dane przechowywane są na Azure Blob Storage, z hierarchiczną przestrzenią nazw. Sama analiza i przetwarzanie danych odbywają się za pomocą narzędzi opartych o HDFS (Hadoop Distributed File System – rozproszony system plików Hadoop), takich jak: 

  • Azure Data Factory,
  • Azure HDInsight,
  • Azure Databricks,
  • Azure Synapse Analytics,
  • Azure Data Explorer,
  • Power BI.

Sam Azure Synapse oferuje też możliwość konstrukcji relacyjnych baz danych w formatach kolumnowych. Data Lake na Azure jest silnie związany z Azure Blob Storage, dlatego koszty Data Lake to koszty wykorzystywania usługi Blob Storage. Wykorzystywanie dodatkowych narzędzi do analizy i przetwarzania danych jest rozliczane osobno.

Qubole:

Kładzie bardzo duży nacisk na format OpenSource i brak uzależniania się od dostawcy (vendor lock-in). Dzięki temu oferowane przez Qubole rozwiązanie jest niezależne od chmury i możliwe do przeniesienia do dowolnego dostawcy usług w chmurze. Zintegrowane UI dostosowane jest pod różne role w projekcie (data science, data engineer). Rozwiązanie to dostępne jest na takich platformach jak AWS, Google Cloud, Microsoft Azure i Oracle Cloud. Posiada również sporo integracji z różnymi zewnętrznymi serwisami. Dane przechowywane są w takich formatach jak np. Parquet lub ORC w wybranej przestrzeni magazynowej (w chmurze lub on-premises). 

Do przetwarzania danych mogą zostać wykorzystane takie technologie, jak Apache Spark, z kolei metadane związane z przechowywanymi danymi mogą być przechowywane w katalogu danych, takim jak Apache Hive. Zarządzanie uprawnieniami do danych oraz ich bezpieczeństwem można osiągnąć za pomocą takich technologii jak Apache Ranger, oraz Apache Sentry. W przypadku tego rozwiązania płaci się za wykorzystanie jednostek obliczeniowych Qubole na godzinę, które są skalowane w zależności od wielkości instancji do przetwarzania danych. Za same koszty obliczeniowe wspomnianych instancji, a także networking i magazynowanie danych, trzeba zapłacić osobno wybranemu dostawcy usług w chmurze.

Intelligent Data Lake (Informatica):

ZOBACZ TEŻ:  Proste zasady tworzenia projektów informatycznych od zera

Data Lake jest oparty na takich technologiach jak Apache Hive, Apache HDFS i Apache Hadoop. Posiada możliwość połączenia z różnymi innymi rozwiązaniami do przechowywania danych proponowanymi przez takich dostawców takich jak Microsoft Azure, AWS, Google Cloud Platform, czy Snowflake. Spory nacisk na łatwy w obsłudze interfejs i mało pisania kodu. Informacje o kosztach można uzyskać po kontakcie z działem marketingu.

Infor:

W tym ujęciu Data Lake Infor zapewnia własny katalog metadanych i wewnętrzne zarządzanie tym katalogiem, łącznie z tworzeniem metagrafu obrazującego zależności pomiędzy poszczególnymi źródłami lub zbiorami danych. Solidny monitoring i integracja z innymi usługami oferowanymi przez Infor ma zapewnić bezproblemowe działanie Data Lake. Przykładowa implementacja przedstawiona przez Infor jest oparta o chmurę AWS, jednak wykorzystuje jedynie instancje EC2, budując na nich całe rozwiązanie Infor. Informacje o kosztach można uzyskać po kontakcie z działem marketingu.

Delta Lake (Databricks):

Tutaj mamy twórcę Apache Sparka (platformę do obliczeń rozproszonych), który poza tym, że stworzył swoje rozwiązanie, to jeszcze połączył je z hurtownią danych nazywając Lakehouse. Chwalą się, że ich Delta Lake jest zgodny z zasadami ACID i pozwala na wersjonowanie danych, zmienianie, optymalizacje małych plików oraz walidację danych. Możliwość odpytywania tabel Delta Lake przez silnik Presto do rozproszonych zapytań SQL jest stale rozwijana i sprawia pewne problemy tylko w przypadku tabel z partycjonowanymi danymi. Koszt tego rozwiązania jest zależny od platformy chmurowej, z której się korzysta (dostępne są trzy: AWS, Azure, Google). Płaci się za wykorzystany DBU (Databricks Unit), czyli jednostkę reprezentującą zużycie mocy przetwarzania na platformie Databricks i oczywiście za zasoby chmurowe.

AWS (LakeFormation):

Propozycja AWS-a na Data Lake to połączenie kilku dostępnych na AWS-ie serwisów i zarządzanie pozwoleniami do danych za pomocą usługi AWS LakeFormation. Do przechowywania danych służy usługa S3. AWS Glue jest polecanym rozwiązaniem do katalogowania i przetwarzania danych (za pomocą technologii Apache Hive i Apache Spark). Jako interfejs dla danych używana jest usługa Amazon Athena (rozproszone zapytania SQL-owe oparte o Presto). Integracja z usługą EMR do przetwarzania danych znajduje się obecnie w wersji beta, jednak można jej już używać. Samo wykorzystanie LakeFormation jest bezpłatne, opłaty są natomiast związane z używaniem pozostałych usług AWS. 

AWS Lake Formation i inne, czyli przepis AWS na Data Lake

Dawniej (do sierpnia 2019) w zarządzaniu dostępem do tabel w katalogu metadanych Glue wykorzystywane były osobne pozwolenia IAM do tabel, baz danych i katalogów, nadawane rolom i użytkownikom. LakeFormation miał za zadanie scentralizować zarządzanie tymi dostępami, istnieje jednak opcja wyłączenia LakeFormation na poziomie konta AWS i powrotu do starego sposobu zarządzania dostępami.

Poniżej przykład potrzebnych uprawnień nadawanych użytkownikowi, który ma mieć dostęp do tabeli.

W starym podejściu rola lub użytkownik musi mieć odpowiednie uprawnienia do tabel oraz dostęp do źródła danych, które opisują tabele (np. bucket S3). W przypadku nowego podejścia źródło danych jest rejestrowane jako zasób Data Lake, podczas którego do danego źródła dołączana jest wewnętrzna rola serwisu LakeFormation, która ma do niego odpowiednie uprawnienia. Do tabel czy też baz danych nadawane są pozwolenia dla poszczególnych ról lub użytkowników w sposób bardzo podobny co przyznawanie uprawnień w SQL-owych bazach danych (np. SELECT, INSERT, DROP TABLE). 

W przypadku jakiegokolwiek wykorzystania takiej tabeli np. w trakcie przetwarzania danych, jeżeli dany użytkownik lub rola ma odpowiednie uprawnienia do tabeli, dostęp do źródła danych (np. S3) jest realizowany poprzez wewnętrzną rolę LakeFormation. Dzięki temu osoba pracująca na danych tabelach nie ma bezpośredniego dostępu do danych na S3, a może jedynie wykorzystywać tabele Glue jako interfejs do pracy z danymi.

Ponadto poszczególnym użytkownikom czy rolom można nadawać różne uprawnienia, a także uprawnienia do nadawania uprawnień innym użytkownikom/rolom. Zarządzanie dostępami staje się w tym wypadku wygodne i scentralizowane. Istnieje również możliwość nadawania uprawnień tylko do poszczególnych kolumn tabeli, bardzo ważna w przypadku pracy z wrażliwymi danymi. AWS posiada również kilka predefiniowanych szablonów do pobierania danych z baz relacyjnych 

LakeFormation jako względnie nowy produkt ma niestety swoje minusy. Integracja z usługą EMR znajduje się ciągle w wersji beta, jeśli więc, zamiast Glue wolisz wykorzystać czystego Sparka i zredukować koszty za pomocą wykorzystywania tańszych spotów na EC2, to musisz liczyć się potrzebą zrobienia pewnych obejść w używanej infrastrukturze (głównie jest to potrzeba nadawania bezpośrednich dostępów do bucketów S3). Jeśli EMR ma być wykorzystywany przez zespoły data science lub do analityki danych, EMR pozostaje dobrą opcją, ponieważ integracja z LakeFormation, jeśli użytkownicy korzystają z uwierzytelnienia za pomocą protokołu SAML, działa bez zarzutu.

Innym mankamentem tego rozwiązania jest brak automatyzacji w zarządzaniu samymi tabelami. W przeciwieństwie do rozwiązań DataBricks AWS-owe tabele Glue nie mają zaimplementowanych transakcji ACID oraz automatycznego scalania małych plików w większe, zwiększające wydajność przy odpytywaniu tabel. AWS jednak podchodzi rozwojowo do oferowanego przez siebie Data Lake i w opcji preview dostępne są już tabele typu “governed table”, które wprowadzają wspomniane transakcje ACID i automatyczne scalanie mniejszych plików.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Wysokie wynagrodzenie, a nie ciekawe projekty. Pierwsze wyniki badania specjalistów IT