Prędzej czy później na zarządzie pada pytanie: budujemy hurtownię, jezioro danych czy lakehouse? Zwykle zadaje je ktoś, kto właśnie wrócił z konferencji albo dostał trzy oferty, każdą z innym rysunkiem architektury. Odpowiedź rzadko zależy od technologii. Częściej od tego, jakie decyzje ma wspierać Twoja firma i kto będzie to utrzymywał.
Poniżej porządkujemy pojęcia i pokazujemy, skąd bierze się rachunek. Na koniec podpowiadamy, jak wybrać tak, żeby nie płacić za platformę, której nikt nie używa.
Trzy pojęcia, jedno zamieszanie
Hurtownia danych to baza zaprojektowana pod analitykę. Dane są uporządkowane w tabelach, mają ustalony schemat, a raporty i dashboardy działają szybko także wtedy, gdy korzysta z nich kilkadziesiąt osób naraz. To sprawdzony model, dobry dla finansów i sprzedaży. Słabiej radzi sobie z surowymi plikami, logami, obrazami czy dokumentami, a przy dużych ilościach danych potrafi być droga.
Data lake, czyli jezioro danych, to tani magazyn plików (zwykle w chmurowym storage'u obiektowym), do którego wrzuca się wszystko w oryginalnej postaci. Schemat nadaje się dopiero przy odczycie. Elastyczność jest ogromna, ale bez dyscypliny jezioro szybko zamienia się w bagno: nikt nie wie, co jest aktualne, kto jest właścicielem danych i czy dwa raporty liczą to samo.
Lakehouse łączy cechy obu. Dane leżą w taniej, otwartej warstwie plików, a na wierzchu dostają warstwę tabel i katalog, które dają transakcje, historię zmian i kontrolę dostępu. Autorzy koncepcji opisywali ją jako odpowiedź na uciążliwy układ dwóch osobnych systemów, gdzie dane trzeba kopiować z jeziora do hurtowni i pilnować, żeby obie kopie się zgadzały.
W praktyce granice się zacierają. Hurtownie potrafią dziś czytać pliki z jeziora, a platformy lakehouse oferują SQL i dashboardy. Dlatego pytanie "co jest czym" jest mniej ważne niż "co mam zrobić z danymi".
Formaty Iceberg i Delta: dlaczego są ważne dla portfela
Sercem lakehouse'u są otwarte formaty tabel. Dwa najczęściej spotykane to Apache Iceberg i Delta Lake. Oba dodają do zwykłych plików rzeczy, które znamy z baz danych: bezpieczne zapisy, zmiany schematu bez przepisywania całej tabeli oraz "podróże w czasie", czyli odczyt tabeli sprzed tygodnia albo cofnięcie błędnego załadowania.
Dla zarządu liczy się jedno: dane w otwartym formacie nie są zamknięte w jednym produkcie. Można je czytać różnymi silnikami. Iceberg obsługują między innymi Spark, Trino i Flink, a Delta Lake, rozwijany pod egidą Linux Foundation, współpracuje z szeroką listą silników, w tym Snowflake, BigQuery, Athena i Microsoft Fabric. Więksi dostawcy chmurowi i platformowi wspierają dziś Iceberg w mniejszym lub większym stopniu, a Delta oferuje tryb UniForm, który pozwala klientom Iceberga czytać tabele Delty. Stan wsparcia zmienia się szybko i bywa niejednolity (zwłaszcza w funkcjach zapisu), więc przed zakupem sprawdź dokumentację konkretnego dostawcy, a nie slajd z prezentacji.
To nie znaczy, że otwarty format likwiduje uzależnienie od dostawcy. Zostaje jeszcze katalog, uprawnienia, narzędzia do orkiestracji i wiedza zespołu. Format zmniejsza koszt wyjścia, ale go nie zeruje.
Skąd się bierze rachunek
W większości chmurowych rozwiązań płacisz osobno za przechowywanie i za moc obliczeniową. Storage jest tani. Rachunek robi compute.
Są dwa popularne modele. W pierwszym, jak w Snowflake, uruchamiasz wirtualne magazyny obliczeniowe, które zużywają kredyty za czas pracy. Największą dźwignią kosztową jest tu bezczynność: klaster, który stoi włączony w weekend, kosztuje tyle samo co ten, który liczy. W drugim, jak w BigQuery w trybie na żądanie, płacisz za ilość przeskanowanych danych, więc jedno źle napisane zapytanie bez filtra po dacie potrafi kosztować więcej niż cały dzień normalnej pracy. BigQuery oferuje też rezerwację mocy w modelu slotów, która daje przewidywalność kosztem elastyczności.
Trzeci składnik to transfer. Ładowanie danych do chmury zwykle jest darmowe, ale wyprowadzanie ich poza region lub do innego dostawcy już nie. Przy dużych wolumenach opłaty egress mogą zmienić wynik porównania ofert. Dlatego pytanie "gdzie fizycznie leżą dane i kto je będzie czytał" należy zadać przed podpisaniem umowy, nie po pierwszej fakturze.
Aktualne cenniki podają wprost sami dostawcy, a opracowania trzecie (jak przegląd kosztów Snowflake, BigQuery i Redshift) pokazują, ile naprawdę wynosi całkowity koszt posiadania. Liczby w prezentacjach handlowych rzadko uwzględniają bezczynność, pracę zespołu i migrację.
Kiedy wystarczy zwykły Postgres
Mniej efektowna, ale uczciwa odpowiedź: bardzo często wystarczy Postgres. Jeśli łączna ilość danych analitycznych mieści się w setkach gigabajtów, raportuje kilka osób, a źródła to dwa-trzy systemy, osobna platforma danych to przerost formy. Do tego dochodzą narzędzia takie jak DuckDB, które szybko liczą analitykę na pojedynczej maszynie, oraz rozszerzenia, które wbudowują ten silnik w Postgresa.
Warto jednak pamiętać, że hasło "big data is dead" pochodzi w dużej mierze od firm, które sprzedają narzędzia dla małych i średnich zbiorów danych. Teza jest rozsądna dla wielu zespołów, ale nie jest prawem natury. Granica, powyżej której Postgres przestaje wystarczać, zależy od współbieżności, rodzaju zapytań i tego, czy chcesz łączyć dane ustrukturyzowane z plikami i strumieniami.
Sygnały, że czas wyjść poza Postgresa: raporty obciążają bazę produkcyjną, zapytania liczą się godzinami, potrzebujesz historii zmian na dużą skalę albo dane przychodzą w formatach, które nie mieszczą się w tabelach.
Porównanie w jednej tabeli
| Hurtownia | Data lake | Lakehouse | Postgres (+ DuckDB) | |
|---|---|---|---|---|
| Typ danych | Ustrukturyzowane | Dowolne pliki | Ustrukturyzowane i pliki | Ustrukturyzowane |
| Dla kogo | Analitycy, BI | Data scientists, inżynierowie | Obie grupy | Mały zespół |
| Współbieżny BI | Bardzo dobry | Słaby bez dodatków | Dobry, zależy od silnika | Dobry do skali średniej |
| Koszt storage | Średni | Niski | Niski | Niski |
| Koszt compute | Zależy od modelu | Zależy od silnika | Zależy od silnika | Stały, przewidywalny |
| Wymagania dla zespołu | Umiarkowane | Wysokie | Wysokie | Niskie |
| Ryzyko uzależnienia | Średnie do wysokiego | Niskie | Niskie do średniego | Niskie |
To uproszczenie, a nie wyrok. Konkretny produkt może wyglądać inaczej niż jego kategoria.
Pytania, które rozstrzygają wybór
Zamiast pytać "która technologia jest najlepsza", odpowiedz na pięć pytań.
- Wolumen: ile danych jest dziś i ile będzie za dwa lata? Gigabajty to inna rozmowa niż dziesiątki terabajtów.
- Opóźnienie: czy raport na poniedziałek rano wystarczy, czy potrzebujesz decyzji w ciągu sekund, na przykład w logistyce albo energetyce?
- Zespół: kto to będzie utrzymywał? Platforma, która wymaga czterech inżynierów, a masz jednego, jest błędem niezależnie od jej zalet.
- Zgodność: gdzie muszą leżeć dane, kto ma do nich dostęp i co z danymi osobowymi? W ochronie zdrowia i finansach to często pierwsze kryterium, nie ostatnie.
- Uzależnienie od dostawcy: jak trudno i drogo byłoby wyjść? Otwarte formaty i standardowy SQL pomagają, ale warto sprawdzić to w praktyce, na małej próbie.
Jeśli na większość pytań odpowiedź brzmi "mało, wolno, mały zespół", zacznij od prostego rozwiązania. Jeśli masz dane z wielu systemów, strumienie, pliki i potrzeby AI obok klasycznego BI, lakehouse zaczyna mieć sens.
Typowe błędy
Pierwszy: budowanie platformy przed przypadkiem użycia. Firma kupuje licencje, zatrudnia zespół, buduje architekturę na papierze, a po roku okazuje się, że żaden dział nie ma pilnego pytania, na które ta platforma odpowiada. Infrastruktura bez odbiorcy to koszt, nie aktywo.
Drugi: brak governance. Bez katalogu danych, właścicieli zbiorów i jasnych definicji metryk każda architektura, także najnowocześniejsza, kończy jako zbiór sprzecznych liczb. Governance nie jest etapem na później. Wystarczy zacząć skromnie: lista kluczowych zbiorów, nazwany właściciel każdego z nich, jedna definicja przychodu.
Trzeci: koszt nieużywanych klastrów. Środowiska testowe działające całą dobę, zbyt duże magazyny obliczeniowe "na wszelki wypadek", brak automatycznego wyłączania. W projektach, które prowadzimy, to najczęstsze źródło niepotrzebnych wydatków i najłatwiejsze do naprawienia: limity budżetowe, alerty i automatyczne zatrzymywanie po kilku minutach bezczynności.
Czwarty: migracja wszystkiego naraz. Przenoszenie całej hurtowni w jednym projekcie kończy się zwykle opóźnieniem, a czasem zerwanym zaufaniem biznesu do danych.
Rekomendacja: zacznij od jednego przypadku użycia
Wybierz jedno konkretne pytanie biznesowe, na które odpowiedź ma wartość w pieniądzach. Na przykład: które zamówienia są opóźnione i dlaczego, jaki jest rzeczywisty margines na produkcie po kosztach logistyki, kiedy zużycie energii przekracza próg kontraktowy.
Potem zrób na tym trzy rzeczy. Zbierz tylko te dane, które są potrzebne. Wybierz najprostszą architekturę, która to obsłuży, nawet jeśli to Postgres. Ustal metryki sukcesu i koszt miesięczny z limitem. Po dwóch-trzech miesiącach masz działający wynik, realne liczby kosztów i wiedzę, czego brakuje. Dopiero wtedy decyzja o lakehousie, hurtowni czy czymś pośrodku opiera się na faktach z Twojej firmy, a nie na prezentacjach dostawców.
Otwarte formaty danych i oddzielenie przechowywania od obliczeń pozwalają dołożyć kolejne przypadki użycia bez przebudowy fundamentów. Jeśli chcesz porozmawiać o tym, od którego przypadku zacząć u Ciebie, chętnie usiądziemy nad konkretami.
Źródła
- Apache Iceberg, dokumentacja projektu
- Delta Lake, strona projektu
- Armbrust i in., Lakehouse: A New Generation of Open Platforms (CIDR 2021)
- MotherDuck, The Data Warehouse TCO: Snowflake, BigQuery, Redshift
- Google Cloud, cennik BigQuery
- DS Stream, Data Warehouse vs. Data Lake vs. Lakehouse
- GraphScope, Why DuckDB Is Such A Good Database Product
