Większość firm nie potrzebuje rozproszonej platformy danych. Ich dane bez trudu mieszczą się w jednej, dobrze skonfigurowanej bazie, a prawdziwe kłopoty dotyczą raczej jakości danych i procesów niż ich ilości. Taka platforma przydaje się dopiero wtedy, gdy pojedyncza maszyna przestaje nadążać, a opóźnienie w danych zaczyna kosztować realne pieniądze.
O Big Data mówi się od ponad dwudziestu lat i przez ten czas termin stał się czymś w rodzaju znaku rozpoznawczego nowoczesnej firmy. Dlatego decyzje o budowie platformy danych zapadają często przez porównanie z konkurencją albo z polecenia dostawcy, a nie na podstawie liczb. Tymczasem pierwsze pytanie powinno być znacznie prostsze: jakie dane mamy, ile ich jest i co właściwie z nimi robimy?
Co właściwie znaczy „duża skala”
Termin ma konkretny rodowód. W lutym 2001 roku Doug Laney, analityk META Group (firmy przejętej później przez Gartnera), opisał trzy wymiary, w których rośnie złożoność pracy z danymi: wolumen (volume), szybkość (velocity) i różnorodność (variety). Tak narodziła się znana formuła „3V”*.
Wolumen to ilość danych, które trzeba przechowywać i przetwarzać. Szybkość mówi o tym, jak prędko dane napływają i jak szybko trzeba na nie reagować. Różnorodność oznacza mnogość źródeł i formatów: tabele, pliki JSON, logi, teksty, obrazy.
Z czasem do modelu dopisano kolejne „V”, najczęściej wiarygodność (veracity) i wartość (value). Z biznesowego punktu widzenia są one nawet ważniejsze od pierwszej trójki, bo ogromne, ale niewiarygodne dane potrafią wyrządzić więcej szkody niż pożytku.
W praktyce wygodniej posługiwać się prostym kryterium: dane stają się „duże” wtedy, gdy obciążenia nie da się już rozsądnie obsłużyć na jednej maszynie. To uczciwsza miara niż sztywny próg w terabajtach, ponieważ pojedynczy serwer z roku na rok radzi sobie z coraz większymi ilościami danych.
Ile danych firmy mają tak naprawdę
Większość organizacji ma danych mniej, niż się powszechnie sądzi. Jordan Tigani, jeden z pierwszych inżynierów Google BigQuery, opisał w 2023 roku swoje obserwacje z lat pracy z klientami tej usługi. Według jego relacji zdecydowana większość klientów BigQuery przechowywała łącznie mniej niż terabajt danych, a wśród tych, którzy korzystali z usługi intensywnie, mediana wynosiła wyraźnie poniżej 100 GB. Z jego obserwacji wynikało również, że 90% zapytań przetwarzało mniej niż 100 MB. Gdy jeden z inwestorów zapytał o to spółki ze swojego portfela, okazało się, że największe firmy B2B miały około terabajta danych analitycznych, a największe firmy B2C — około dziesięciu.
Trzeba tu zrobić jedno zastrzeżenie. Tigani kieruje dziś firmą MotherDuck, która sprzedaje rozwiązania właśnie dla „małych” danych, i sam przyznaje, że podaje liczby z pamięci. Jego obserwacje nie są więc reprezentatywnym badaniem całego rynku. Ogólny obraz pokrywa się jednak z doświadczeniem wielu praktyków: nawet jeśli firma przechowuje dużo danych, zapytania zwykle dotyczą niewielkiego, świeżego wycinka — ostatniego dnia, tygodnia czy miesiąca.
Jednocześnie pojedyncza maszyna stała się nieporównanie mocniejsza. Gdy w 2006 roku ruszyło AWS EC2, do wyboru był jeden typ serwera: jeden rdzeń i 1,75 GB pamięci. Dziś w tej samej chmurze można wynająć maszynę z 32 TiB pamięci operacyjnej. To przypadek skrajny, ale dobrze pokazuje, jak przesunęła się granica: to, co w 2010 roku wymagało klastra Hadoop, dziś często mieści się na jednym serwerze z PostgreSQL, ClickHouse albo DuckDB.
Skąd biorą się chybione decyzje
Platformę „na wyrost” kupuje się zwykle nie z powodu danych, lecz z powodu oczekiwań. Najczęściej firma porównuje się z gigantami: Netflix czy Uber budowały rozproszone systemy z myślą o miliardach zdarzeń dziennie, ale przedsiębiorstwu, które obsługuje tysiąc zamówień na dobę, ich architektura do niczego się nie przyda. Do tego dochodzą dostawcy, którym opłaca się sprzedać platformę liczoną w petabajtach nawet klientowi mającemu sto gigabajtów.
Równie często brakuje konkretnego pytania, na które dane mają odpowiedzieć. Zbiera się je „na wszelki wypadek”, a potem nikt nie wie, co z nimi zrobić. Myli się też ilość z wartością: terabajt logów, do których nikt nie zagląda, jest dla biznesu mniej użyteczny niż porządnie prowadzona tabela sprzedaży. Wreszcie projekt bywa traktowany jako czysto techniczne zadanie działu IT, bez właściciela po stronie biznesu.
Efekt jest za każdym razem podobny: drogi w utrzymaniu system, który pochłania czas zespołu, a na pytania biznesowe odpowiada równie wolno jak stara baza danych.
Kiedy skala jest naprawdę potrzebna
Potrzebę rozproszonej architektury zdradzają zwykle konkretne objawy, a nie moda. Zanim jednak firma kupi nową platformę, warto sprawdzić, czy problemu nie da się rozwiązać prościej: indeksami, partycjonowaniem, agregatami, kolumnową bazą analityczną albo po prostu mocniejszym serwerem.
O realnej potrzebie świadczą przede wszystkim cztery sygnały. Po pierwsze, kluczowe zapytania nie mieszczą się w wymaganym czasie nawet po optymalizacji i przejściu na większą maszynę. Po drugie, regularnie trzeba przetwarzać naraz setki gigabajtów czy terabajty — nie wszystko, co się przechowuje, lecz właśnie tyle w jednym zadaniu. Po trzecie, dane napływają nieprzerwanym strumieniem, tysiącami zdarzeń na sekundę, z aplikacji, logów, czujników IoT czy systemów płatności, i trzeba je przetwarzać bez gubienia zdarzeń. Po czwarte, wiele niepowiązanych źródeł trzeba łączyć w spójny obraz, który aktualizuje się w ciągu minut, a nie dni.
Jeśli pasuje jeden czy dwa z tych opisów, zwykle wystarczy rozwiązanie punktowe. Jeśli niemal wszystkie — czas poważnie zaprojektować platformę danych.
Przetwarzanie wsadowe czy strumieniowe
Szybkość przetwarzania należy dobierać do tempa, w jakim zapadają decyzje. Jeśli raport ogląda się raz dziennie, dane w czasie rzeczywistym niczego nie wniosą, a zapłacić za nie trzeba złożonością systemu.
Przetwarzanie wsadowe (tzwn. batch) sprawdza się wszędzie tam, gdzie decyzje zapadają raz na godzinę, dzień czy tydzień: w sprawozdawczości finansowej, planowaniu zakupów albo analityce marketingowej. Jest prostsze w utrzymaniu, bo łatwiej je testować, ponawiać i poprawiać, a przy tym jest tańsze, ponieważ zasoby pracują tylko według harmonogramu.
Przetwarzanie strumieniowe (streaming) ma sens dopiero wtedy, gdy opóźnienie rzędu kilku sekund czy minut przekłada się na straty finansowe albo ryzyko dla bezpieczeństwa. Tak jest przy wykrywaniu nadużyć w płatnościach, monitorowaniu urządzeń i infrastruktury czy rekomendacjach dopasowanych do klienta w danej chwili. Ceną jest jednak znacznie większa złożoność: trzeba pilnować kolejności zdarzeń, duplikatów i danych, które przychodzą z opóźnieniem, a system wymaga infrastruktury i dyżurów przez całą dobę.
Dla wielu firm dobrym kompromisem jest przetwarzanie w mikro partiach (micro-batch), czyli odświeżanie danych co 5–15 minut. To wystarcza do operacyjnych pulpitów analitycznych, a nie wprowadza złożoności, jaką niesie ze sobą system strumieniowy.
Hurtownia, jezioro czy lakehouse
Model przechowywania wybiera się na podstawie charakteru danych i zadań, a nie tego, o czym akurat najwięcej się pisze.
Hurtownia danych (data warehouse) przechowuje dane ustrukturyzowane i oczyszczone, a ich schemat określa się już przy ładowaniu. Dzięki temu świetnie nadaje się do stabilnej, szybkiej sprawozdawczości i narzędzi BI. Jej słabością jest koszt: trzymanie w niej „wszystkiego na wszelki wypadek” szybko staje się drogie.
Jezioro danych (data lake) przyjmuje dane w dowolnej postaci, także surowe i nieustrukturyzowane, a strukturę danych określa się dopiero przy odczycie. To tani sposób na przechowywanie dużych wolumenów, przydatny w uczeniu maszynowym i eksploracji danych. Bez katalogu i właścicieli jezioro bardzo łatwo jednak zamienia się w bagno.
Lakehouse próbuje połączyć zalety obu podejść. Dane leżą w otwartych formatach, ale nad plikami działają tabele z transakcjami i schematem, dzięki czemu jedna kopia danych służy zarówno raportowaniu, jak i uczeniu maszynowemu. Wymaga to jednak dojrzałego zespołu i sporej dyscypliny.
Podejście lakehouse formalnie opisali inżynierowie Databricks w artykule z 2021 roku. Chodzi o to, by trzymać dane w tanim magazynie obiektowym i w otwartych formatach (Parquet, a nad nim Delta Lake, Apache Iceberg lub Apache Hudi), a zarazem zapewnić im transakcje i zarządzanie znane z hurtowni.
Dla większości średnich firm rozsądnym punktem wyjścia jest hurtownia danych, w chmurze lub we własnej infrastrukturze. Jezioro albo lakehouse warto dołożyć wtedy, gdy pojawiają się duże ilości surowych lub nieustrukturyzowanych danych, na przykład na potrzeby uczenia maszynowego. Pomyłka na tym etapie słono kosztuje: miesiące pracy idą na migrację zamiast na analizę.
Bez procesów platforma nie zadziała
Nawet trafnie dobrana architektura nie przyniesie efektów, jeśli wokół danych panuje bałagan. Według szacunków Gartnera niska jakość danych kosztuje organizacje średnio co najmniej 12,9 mln dolarów rocznie, a 59% z nich w ogóle tej jakości nie mierzy. Liczba ta pochodzi z badania przeprowadzonego w 2020 roku wśród dużych przedsiębiorstw, więc w mniejszej firmie będzie odpowiednio niższa. Kierunek jest jednak jasny: złe dane kosztują więcej, niż się wydaje.
Zanim uruchomi się platformę, warto zadbać o kilka podstaw. Każdy zbiór danych powinien mieć właściciela, czyli konkretną osobę, która odpowiada za to, by dane były poprawne i zrozumiałe. Jakość dobrze jest sprawdzać automatycznie, testując kompletność, duplikaty i dopuszczalne wartości przy każdym ładowaniu. Dostęp musi być jasno uregulowany, zwłaszcza w przypadku danych osobowych i wymogów RODO. Koszty przechowywania i zapytań powinny być widoczne w podziale na zespoły i projekty. Przyda się też katalog danych, w którym łatwo znaleźć potrzebną tabelę i zrozumieć, co zawiera.
Bez tego nawet najdroższa platforma szybko zamienia się w bagno danych (data swamp): danych jest mnóstwo, ale nikt nie wie, którym z nich można ufać.
Wartość tworzą ludzie, nie infrastruktura
Platforma danych jest tylko narzędziem. Korzyści dla biznesu przynoszą ludzie, którzy potrafią zadać danym właściwe pytanie i rozumieją, skąd te dane się biorą.
W praktyce oznacza to trzy rzeczy. Inżynierowie danych muszą znać nie tylko Sparka czy Kafkę, lecz także proces biznesowy, z którego dane powstają. Analitycy powinni pracować ramię w ramię z osobami podejmującymi decyzje, a nie jedynie przygotowywać raporty na zamówienie. Za architekturę zaś powinien odpowiadać ktoś, kto potrafi powiedzieć „tego jeszcze nie potrzebujemy” — i poprzeć to liczbami.
Jeśli takich osób w zespole brakuje, warto je znaleźć albo wykształcić, zanim kupi się platformę. Skomplikowany system obsługiwany przez nieprzygotowany zespół kosztuje więcej niż prosty system utrzymywany przez doświadczonych ludzi.
Podsumowanie
Big Data nie jest złym pomysłem. Złym pomysłem jest budowanie platformy na dużą skalę bez sprawdzenia, czy rzeczywiście jest potrzebna. Decyzja powinna opierać się na liczbach: ile jest danych, jak szybko napływają, jaka ich część jest naprawdę używana i jakie decyzje od nich zależą.
Przed startem projektu warto uczciwie odpowiedzieć sobie na pięć pytań:
- Ile danych przetwarzamy w typowym zapytaniu — nie przechowujemy, lecz właśnie przetwarzamy?
- Czy faktycznie dochodzimy do granic możliwości jednego, dobrze skonfigurowanego serwera?
- Które decyzje straciłyby na wartości, gdyby dane odświeżały się nie w ciągu sekund, lecz co kwadrans albo raz na dobę?
- Kto jest właścicielem każdego kluczowego zbioru danych i jak sprawdzamy jego jakość? Czy mamy w zespole ludzi, którzy będą w stanie utrzymać nowy system? Jeśli na większość tych pytań odpowiedź brzmi „jeszcze nie”, najlepszą inwestycją nie będzie nowa platforma, lecz uporządkowanie danych, które firma już ma. A kiedy odpowiedzi zaczną brzmieć “tak” — warto rozważyć konkretne kompetencje w zespole, np. poprzez szkolenia z obszaru Big Data.
- Laney D., 3D Data Management: Controlling Data Volume, Velocity and Variety, META Group, 6 lutego 2001.
