Wdrożenie koncepcji Data Lake wymaga przede wszystkim przygotowania i implementacji szeregu procedur, dzięki którym można kontrolować proces pogłębiania się jeziora w taki sposób, aby nie zamieniło się w bagno danych.
W poprzednich artykułach z serii „Odczarowując Big Data” pisaliśmy o wybranych aspektach związanych z wdrożeniem analityki Big Data w oparciu o Apache Hadoop. Opowiedzieliśmy o historii powstania ekosystemu i staraliśmy się odpowiedzieć czy sama koncepcja wykorzystania tak heterogenicznego środowiska ma sens. Podkreślaliśmy, że jedną z kluczowych przewag ekosystemu Hadoop jest możliwość redundantnego gromadzenia i przetwarzania dużych zbiorów danych, które do tej pory składowane były w systemowych silosach. Dziś chcielibyśmy przyjrzeć się bliżej tej koncepcji tzw. Data Lake.
Hadoop w architekturze korporacyjnej
Niewątpliwie wdrożenie strategii Big Data to znacznie więcej niż tylko uruchomienie platformy Apache Hadoop, zasilenie jej danymi i udostępnienie zespołowi Data Science. Mnogość możliwości jakie daje Hadoop może przytłaczać do tego stopnia, że nie wiadomo od czego zacząć definiując dobre praktyki architektoniczne. W kontekście składowania danych warto zacząć od określenia standardów w zakresie sposobu gromadzenia danych i ich organizowania – w formacie plikowym na HDFS (z różnymi opcjami kompresji i szyfrowania) lub w bazach danych wchodzących w skład ekosystemu (np. Hive, HBase).
Jeżeli chodzi o przetwarzanie danych, kluczowe wybory muszą zapaść w zakresie konkretnych frameworków programistycznych, ale także wykorzystywanych języków programowania i modeli przetwarzania rozproszonego. Mogłoby się wydawać, że po odpowiedzeniu na te pytania organizacja jest już gotowa do korzystania z technologii. Nic bardziej mylnego. Na ogół to dopiero początek drogi, jaką musi przejść, aby skutecznie wdrożyć platformę do przetwarzania dużych zbiorów danych.
Wpisanie Hadoop w architekturę korporacyjną organizacji nierzadko utożsamiane jest z umiejscowieniem w niej koncepcji Data Lake. Termin ten, opisujący – poprzez analogię do rzeczywistego jeziora – elastyczność i pojemność technologii, jest nagminnie wykorzystywane przez licznych dostawców systemów IT w celu zwrócenia uwagi na możliwości implementacji strategii Big Data klientów właśnie poprzez wdrożenie koncepcji Data Lake. Na ogólnym poziomie nie sposób nie zgodzić się ze słusznością takiego podejścia. Dzięki jego wdrożeniu nie ma potrzeby ingerencji w kluczowe procesy przedsiębiorstwa, a dane zgromadzone w jednym miejscu są od ręki dostępne dla analityków. Znacznie skraca to proces przygotowania i uruchomienia modeli analitycznych na skorelowanych danych z różnych źródeł. Utopia? Poniekąd. Dopóki nie skupimy się na aspektach związanych nie tyle z samym przetwarzaniem danych, ale ze sposobami dostępu do nich, ze szczególnym uwzględnieniem korporacyjnych wymagań dotyczących m. in. bezpieczeństwa, jakości danych i Data Governance.
Strzeż się sofizmatów
Dane gromadzone w jeziorze danych – wraz z wynikami realizowanych na nich analiz – z czasem stają się kluczową wartością przedsiębiorstwa. Są więc łakomym kąskiem dla konkurencji, a ich bezpieczeństwo staje się kluczowe. Istniejące polisy dostępu do danych na ogół są niewystarczające w obliczu mnogości interfejsów jakie oferuje Hadoop w celu umożliwienia użytkownikom dostępu do danych. Polisy te – definiowane do tej pory na potrzeby silosowych środowisk – oparte są bowiem o dane jednoznacznie przypisane do konkretnego systemu mającego swojego właściciela.
Dane gromadzone w jeziorze danych stają się kluczową wartością przedsiębiorstwa. Są więc łakomym kąskiem dla konkurencji, a ich bezpieczeństwo staje się kluczowe. Istniejące polisy dostępu do danych na ogół są niewystarczające w obliczu mnogości interfejsów jakie oferuje Hadoop w celu umożliwienia użytkownikom dostępu do danych. Polisy te – definiowane do tej pory na potrzeby silosowych środowisk – oparte są bowiem o dane jednoznacznie przypisane do konkretnego systemu mającego swojego właściciela.
Stąd wdrożenie koncepcji Data Lake na poziomie technologicznym musi iść w parze z opracowaniem procedur dostępu do danych. Dodatkowo, jeżeli są to dane osobowe (np. dane klientów) lub wrażliwe (np. dane medyczne), tworzone na nowo procedury muszą korespondować z aktualnym prawodawstwem w zakresie przechowywania i przetwarzania danych. Dotycz to np. dyrektywy RODO, która wejdzie w życie w 2018 roku.
Jednocześnie nieskrępowany dostęp do możliwości gromadzenia coraz to nowszych zbiorów danych może prowadzić do sytuacji, w której te same dane są lokowane w wielu miejscach ekosystemu przez różne zespoły lub niezależnych analityków pracujących nad swoimi zadaniami. Prowadzi to oczywiście do niepotrzebnego „mętnienia” jeziora danych, a więc przede wszystkim utraty jakości danych, ale także potencjalnego spadku wydajności platformy ze względu na niepotrzebny przyrost ilości danych.
Tak zdefiniowane ryzyka nie mogą zostać zbagatelizowane. „Przed wdrożeniem koncepcji Data Lake koniecznie trzeba odpowiedzieć sobie na pytanie czy korzyści z implementacji jeziora danych – a więc głównie elastyczny dostęp do wszystkich danych zgromadzonych w jednym miejscu – przewyższają koszty związane z przygotowaniem niezbędnych procedur” – podkreśla Adam White, analityk Gartnera w tekście „Gartner Says Beware Of Data Lake Fallacy”. Niewątpliwie wiele zależy od charakterystyki danego biznesu i kultury organizacyjnej przedsiębiorstwa, a także od specyfiki rynku na jakim funkcjonuje. Niemniej jednak kluczowym elementem, który pozwala na minimalizowanie ryzyka i kosztu związanego z wdrożeniem koncepcji Data Lake pozostaje sama technologia, w jakiej ten wzorzec architektoniczny jest implementowany.
Technologia kontratakuje
W szeroko rozumianym aspekcie bezpieczeństwa społeczność skupiona wokół ekosystemu Hadoop niewątpliwie musiała dojrzeć do potrzeb rynkowych. Jeszcze dwa lata temu możliwości praktycznej implementacji mechanizmów związanych z rozliczalnością dostępu do danych w ekosystemie Hadoop była bardzo ograniczona. Wprowadzane poprzez akwizycję firm zewnętrznych oraz rozwijane własnymi siłami mechanizmy centralizujące definiowanie polis, integrację z zewnętrznymi dostawcami poświadczeń (np. Active Directory) oraz audytowanie dostępu do danych w istotny sposób ułatwiły jednak implementację procedur bezpieczeństwa.
Frameworki takie jak Ranger i Knox na stałe weszły do kanonu opcji wymaganych w każdym produkcyjnym wdrożeniu koncepcji Data Lake w oparciu o ekosystem Apache Hadoop. Do tego pojawiły się komponenty Falcon oraz Atlas, które do dzisiaj pozostają nieco niedoceniane, pomimo że umożliwiają realizację przynajmniej kilku wymagań związanych z Data Governance, wprowadzając udogodnienia w postaci mechanizmów retencji danych (także pomiędzy klastrami) oraz zarządzania metadanymi opisującymi zbiory danych.
Nieskrępowany dostęp do możliwości gromadzenia coraz to nowszych zbiorów danych może prowadzić do sytuacji, w której te same dane są lokowane w wielu miejscach ekosystemu przez różne zespoły lub niezależnych analityków pracujących nad swoimi zadaniami. Prowadzi to oczywiście do niepotrzebnego „mętnienia” jeziora danych, a więc przede wszystkim utraty jakości danych, ale także potencjalnego spadku wydajności platformy ze względu na niepotrzebny przyrost ilości danych.
Wymienione możliwości technologiczne oferowane przez ekosystem Hadoop niewątpliwie zmieniły nieco optykę w kontekście oceny bezpieczeństwa i ryzyka z tym związanego oraz ułatwiły implementację koncepcji Data Lake w architekturze korporacyjnej przedsiębiorstw. Praktyczne wdrożenia zaawansowanej analityki w oparciu o ekosystem Hadoop i koncepcję Data Lake pokazują, że architektura ta może być skutecznym sposobem na zbudowanie platformy do przetwarzania dużych zbiorów danych także w realiach polskiego rynku.
Czy wraz z rozwojem ekosystemu Hadoop społeczność skupiona wokół tej technologii będzie kłaść nadal taki sam nacisk na aspekty bezpieczeństwa i Data Governance? Wiele na to wskazuje, ponieważ zagadnienia te podnoszone są na roadmapach największych dystrybucji komercyjnych. Wydaje się więc, że teza, iż koncepcja Data Lake będzie istotnym elementem architektury korporacyjnej pozostanie prawdziwa i oprze się zarzutowi o bycie jedynie marketingowym sofizmatem.
Kamil Folkert, Big Data Expert w SILMINE
