Analityka

Data lake (jezioro danych) - co to jest?

5 min czytania

Firmy gromadzą dziś więcej danych niż kiedykolwiek: z aplikacji, stron internetowych, czujników IoT, systemów CRM, platform reklamowych, a to i tak tylko wierzchołek tej góry lodowej. Gdybyśmy chcieli przechowywać te dane w tradycyjnej bazie, musielibyśmy najpierw zdecydować, jak je poukładamy. A co, jeśli na etapie zbierania danych jeszcze nie wiemy, w jaki sposób chcemy je w przyszłości wykorzystać? Wtedy najbezpieczniej przechowywać je w data lake. Poniżej wyjaśnimy, co to jest „jezioro danych”, jak działa ta koncepcja i gdzie w praktyce się ją stosuje. 

Data lake – co to? Krótkie wyjaśnienie

Data lake (jezioro danych) to scentralizowane repozytorium, w którym przechowuje się dane w ich surowej, oryginalnej postaci – mogą być w dowolnym formacie, nie muszą być nawet w żaden sposób uporządkowane. 

Do jeziora można „wlewać” wszystkie typy danych:

  • ustrukturyzowane – czyli uporządkowane w wiersze i kolumny, jak tabele z relacyjnych baz danych czy pliki CSV;
  • półustrukturyzowane – które mają pewną strukturę, ale nie tak sztywną; mówimy np. o plikach JSON i XML czy logach serwera;
  • nieustrukturyzowane – a więc te, które nie da się wpisać w żadną tabelę, tak jak zdjęcia, pliki wideo i audio, dokumenty tekstowe, e-maile, posty z mediów społecznościowych i tak dalej.

O tym, jak interpretować te informacje i czy chcemy je w jakiś sposób ustrukturyzować, decydujemy dopiero w momencie, gdy faktycznie będziemy tych danych potrzebowali. Taki model nazywa się schema-on-read

To też jest największa różnica między data lakes a tradycyjnymi bazami danych. W klasycznym podejściu – które stosuje się np. w przypadku baz opartych na SQL – najpierw projektuje się strukturę bazy, a potem wypełnia się ją danymi, które muszą pasować do narzuconej struktury. Natomiast gdy tworzymy jezioro danych, zbieramy wszystkie informacje, które możemy, a porządkujemy je później, w razie potrzeby.

Jak zbudowane są jeziora danych? Architektura data lakes

Nawet jeśli dane w jeziorze są przechowywane w różnych postaciach, samo data lake – dobrze zaprojektowane – powinno mieć swoją wewnętrzną strukturę.

Data lakes dzieli się więc na warstwy, czasem nazywane strefami. W uproszczeniu wyglądają one tak:

  1. Warstwa raw – tutaj trafiają dane dokładnie w takiej postaci, w jakiej zostały zapisane w systemie źródłowym. W tej warstwie nic się z nimi nie robi, po to, aby w każdej chwili można było wrócić do oryginałów; nie usuwa się nawet błędów czy duplikatów.
  2. Warstwa cleansed – dopiero w tej warstwie przeprowadza się walidację danych, usuwa duplikaty oraz, co najważniejsze, łączy ze sobą informacje z różnych źródeł (co wymaga doprowadzenia ich do wspólnego formatu).
  3. Warstwa curated – w tej strefie przechowuje się już dane gotowe do użytku, czyli przetworzone, zagregowane i opisane tak, aby każdy mógł po nie sięgnąć, na przykład w formie raportu.

W niektórych narzędzi do budowania data lakes spotyka się też analogiczny podział na strefy bronze, silver oraz gold, od kolorów medali.

Większe jeziora danych często mają też dodatkową, wydzieloną strefę – sandbox, czyli… piaskownicę – w której analitycy i data scientists mogą swobodnie eksperymentować na danych bez ryzyka, że coś zepsują.

Zalety i wady modelu data lake

Cała koncepcja data lake ma zdecydowanie więcej zalet niż wad, choć o tych drugich też można sporo powiedzieć. 

Jeżeli firma decyduje się przechowywać swoje dane w „jeziorze”, to zazwyczaj ze względu na:

  • elastyczność – w data lake możemy umieścić dowolny typ danych, bez ograniczania się tylko do tych już wcześniej uporządkowanych. A warto zdawać sobie sprawę z tego, że dane nieustrukturyzowane stanowią w większości organizacji 80-90% wszystkich zasobów;
  • skalowalność – jeziora danych zazwyczaj działają w chmurze, bardzo rzadko hostuje się je na własnych serwerach. Skoro tak, ich pojemność można zwiększać niemal w nieskończoność, wraz z potrzebami firmy;
  • stosunkowo niskie koszty architektury – jezioro danych można zbudować na najprostszych magazynach obiektowych, do których dostęp praktycznie zawsze jest tańszy niż do magazynów o architekturze file- lub block-storage; co więcej, w tego typu rozwiązaniach koszt przechowywania danych z reguły jest oddzielony od kosztów ich przetwarzania – płacisz osobno za to, że Twoje dane „leżą” w magazynie i osobno wykonywane na nich operacje. Dzięki temu można trzymać terabajty danych „na zapas” bez obaw o koszty;
  • szybki start – skoro nie musisz najpierw projektować całej struktury, dane możesz zacząć zbierać od ręki. A to spora przewaga, jeśli zależy Ci na czasie – powiedzmy, chcesz jak najszybciej zacząć gromadzić informacje o zachowaniu użytkowników, a dopiero później na spokojnie zdecydować, jak je przeanalizować.

Jednak rozwiązania idealne, rzecz jasna, nie istnieją. 

Największym problemem jest to, że bardzo łatwo zmienić „data lake” w „data swamp”, czyli w… bagno danych. Tak mówi się o jeziorach, które są zaniedbane – nikt nie dba o przygotowanie metadanych do opisu informacji, o ich katalogowanie, więc z bezcennego dla organizacji zasobu tworzy się de facto śmietnik, w którym trudno cokolwiek znaleźć. Taki scenariusz jest niestety realny, jeżeli do data lake trafiają dane bez żadnej kontroli. Dlatego też przy wdrożeniu takiego modelu przechowywania danych zawsze trzeba:

  • zbudować zespół inżynierów i analityków danych, którzy potrafią pracować w takim środowisku – a specjalistów na rynku cały czas brakuje, więc nie jest to tanie;
  • opracować zasady zarządzania danymi (data governance) – opisywania ich metadanymi, katalogowania, dokumentowania źródeł, podejścia do błędów, duplikatów oraz niespójności w danych;
  • zadbać o bezpieczeństwo – skoro w jednym miejscu znajdzie się ogrom wrażliwych informacji, trzeba bardzo precyzyjnie zarządzać tym, kto i co może zobaczyć.

Kiedy model data lake sprawdza się najlepiej?

Koncepcja data lake bardzo mocno zyskała w ostatnich latach na popularności z jednego powodu. Chodzi, oczywiście, o machine learning. Do rozwoju dużych modeli językowych (jak GPT czy Gemini), systemów rekomendacji (tych, które polecają Ci filmy na Netflixie albo produkty w sklepach) czy modeli do analizy ryzyka i wykrywania potencjalnych oszustw finansowych (z których korzysta każdy bank) potrzebne są ogromne ilości danych. Najlepiej, żeby były to dane surowe – często są przy tym nieustrukturyzowane. Jeziora danych idealnie nadają się do zarządzania nimi, plus są dobrym narzędziem dla inżynierów danych, którzy mogą np. samodzielnie opisywać cechy danych i mają dzięki temu większy wpływ na trening modeli. 

Pomijając jednak rozwój AI, data lakes mają też swoje miejsce w analityce, zwłaszcza przy dużych wolumenach danych (big data) albo przy przetwarzaniu strumieni informacji spływających do nas „na żywo” – na przykład z systemów IoT. Jeziora danych wykorzystuje się choćby jako zaplecze do monitorowania pracy maszyn w największych fabrykach i wychwytywania sygnałów awarii, zanim faktycznie do nich dojdzie. Zresztą, na tej samej zasadzie można byłoby je zastosować w marketingu, czy to do analizy danych behawioralnych ze stron i aplikacji, czy zbierania surowych danych z narzędzi SEO – powiedzmy, z Ahrefs. 

Czasem jednak chodzi po prostu o to, żeby mieć wszystko w jednym miejscu. Zamiast trzymać dane rozsiane po kilkunastu systemach, można je scentralizować w data lake. A że składowanie informacji w jeziorze jest dosyć tanie, równie dobrze sprawdzi się w celu archiwizacji danych; takich, które dziś niespecjalnie są potrzebne, ale za rok czy dwa mogą się przydać, nawet ze względu na wymogi prawne (niektóre informacje firmy muszą przecież przechowywać latami).

Data lake, czyli inny sposób na przechowywanie danych

Data lake to potężne narzędzie dla firm, które chcą gromadzić dane – nie tylko te ustrukturyzowane, jak w bazach SQL – na zapas i wykorzystywać je do analityki czy w projektach wspieranych przez AI. Daje ogromną elastyczność i jest tańsze w utrzymaniu niż klasyczne hurtownie danych, choć oczywiście, wymaga dyscypliny, bo bez tego szybko zamieni się w bezużyteczne „bagno danych”.

A jeśli zainteresował Cię ten temat – zachęcamy do lektury innych wpisów w naszym słowniku!

tło banera
Genialne firmy mnożą
swój potencjał z
Ocena Clutch
5.0
Ocena Google
4.8
tło banera
Bądź widoczny w Google i wyszukiwarkach przyszłości (ChatGPT, Gemini, Perplexity i inne)
Zostaw adres e-mail — porozmawiamy o widoczności Twojej strony w AI.
Dane przetwarzamy w celu kontaktu, zgodnie z naszą
polityką prywatności
Marcin Stypuła
Zespół Semcore odpowiedzialny za tworzenie wartościowego contentu na temat marketingu internetowego. Część treści tworzymy wspólnie, rozmawiając o nich i pozyskując wiedzę od ekspertów ze wszystkich działów. W artykułach blogowych przedstawiamy między innymi: aktualne informacje dotyczące: SEO, UX, tworzenia i optymalizacji płatnych kampanii reklamowych, zarządzania sklepami internetowymi. Pokazujemy w jaki sposób można samodzielnie dokonać zmian na własnej stronie, przedstawiamy także ważne argumenty przemawiające na korzyść nowoczesnych rozwiązań.

Udostępnij

Oceń tekst

Średnia ocen 0 / 5. Liczba głosów: 0

Brak głosów - oceń jako pierwszy!

Zapytaj o ofertę SEO
Dołącz do newslettera
Powiązane artykuły Najnowsze Popularne

Zbuduj Twój potencjał SEO

Skonsultuj z nami Twoją sytuację w wyszukiwarce. Porozmawiajmy o Twoich celach i możliwościach współpracy