Wybór między Lakehouse a Data Warehouse to klasyczny fałszywy dylemat. Po 30 latach pracy z danymi wiem jedno: kto zaczyna od technologii, kończy z chaosem.
Fałszywy dylemat, który kosztuje miliony
Przez ostatnie dwa lata przeprowadziłem audyty architektur danych w kilkunastu organizacjach. W większości przypadków spotkałem ten sam schemat: zespół rozpoczął projekt od pytania "Lakehouse czy Warehouse?" i wybrał jedno rozwiązanie do wszystkiego. Efekt? Frustracja analityków, rosnące koszty utrzymania i dane, którym nikt nie ufa.
Problem tkwi w samym pytaniu. Zakłada ono, że Lakehouse i Data Warehouse to alternatywy pełniące tę samą funkcję. Tymczasem są to różne warstwy architektury danych, każda z własnym zakresem odpowiedzialności. To tak, jakby pytać: "Kuchnia czy jadalnia?" podczas projektowania restauracji. Potrzebujesz obu, a kluczowe jest zaprojektowanie przepływu między nimi.
Czym naprawdę jest Data Warehouse
Data Warehouse to środowisko, w którym dane osiągnęły stan dojrzałości. Zostały przekształcone, oczyszczone, zwalidowane i ułożone w struktury odpowiadające potrzebom biznesu. To nie jest miejsce na eksperymenty ani surowe logi z systemów źródłowych.
W klasycznym ujęciu Data Warehouse opiera się na modelach analitycznych. Najczęściej spotykam schematy gwiazdy (star schema) lub płatka śniegu (snowflake schema). Tabele faktów zawierają miary biznesowe, tabele wymiarów dostarczają kontekstu. Wszystko jest zoptymalizowane pod kątem zapytań SQL i przewidywalnych wzorców dostępu.
Kluczowe cechy warstwy Warehouse
- Spójność definicji biznesowych; przychód oznacza to samo w każdym raporcie
- Kontrola jakości danych z walidacją przed załadowaniem
- Optymalizacja pod SQL i narzędzia BI (Power BI, Tableau, Looker)
- Przewidywalna wydajność zapytań dzięki indeksom i statystykom
- Governance i audytowalność zmian
W architekturze medalion Data Warehouse odpowiada warstwie gold. To dane gotowe do konsumpcji, jednoznaczne i zaufane z perspektywy całej organizacji. Kiedy CFO pyta o przychód za ostatni kwartał, odpowiedź pochodzi właśnie stąd.
Przez lata obserwuję tę samą prawidłowość: organizacje, które traktują Data Warehouse jako "jeszcze jedno miejsce na dane", nigdy nie osiągają single source of truth. Warehouse to nie storage. To warstwa zaufania.
Czym naprawdę jest Lakehouse
Lakehouse to stosunkowo nowa koncepcja, która łączy elastyczność Data Lake z niektórymi cechami Data Warehouse. Jednak w praktyce jego rola w architekturze jest fundamentalnie inna niż rola Warehouse.
Lakehouse to przestrzeń pracy na danych. Tutaj trafiają surowe dane z systemów źródłowych: logi aplikacji, pliki CSV od partnerów, streamy z IoT, eksporty z systemów legacy. Formaty są różne (JSON, Parquet, Delta, CSV), jakość bywa wątpliwa, a schematy ewoluują.
Co dzieje się w warstwie Lakehouse
- Ingestion danych z różnych źródeł bez wymuszania schematu
- Transformacje i czyszczenie (obsługa nulli, duplikatów, błędnych typów)
- Agregacje i przygotowanie danych pod zaawansowaną analitykę
- Eksperymentowanie z nowymi źródłami danych
- Przetwarzanie Machine Learning i feature engineering
W architekturze medalion Lakehouse obejmuje warstwy bronze i silver. Bronze to dane surowe, zapisane tak jak przyszły ze źródła. Silver to dane po pierwszych transformacjach: deduplikacji, standaryzacji formatów, wzbogaceniu o metadane. To tutaj zachodzi cała "brudna robota" inżynierii danych.
Architektura medalion w praktyce
Architektura medalion (bronze, silver, gold) to nie wymysł marketingowy. To sprawdzony wzorzec projektowy, który jasno definiuje odpowiedzialność każdej warstwy i przepływ danych między nimi.
Warstwa Bronze
Dane surowe, niemodyfikowane. Zachowujemy je w oryginalnej postaci jako audit trail i punkt wyjścia do reprzetworzenia. Format często to Delta Lake lub Parquet z partycjonowaniem po dacie ingestion. Retencja zależy od wymagań compliance; czasem 7 lat, czasem 90 dni.
Warstwa Silver
Dane oczyszczone i ustandaryzowane. Usunięte duplikaty, obsłużone nulle, spójne typy danych. To warstwa, z której korzystają data scientists i zaawansowani analitycy. Jeszcze nie ma tu logiki biznesowej, ale dane są już używalne.
Warstwa Gold
Modele analityczne gotowe do konsumpcji. Tutaj żyją definicje biznesowe: co to jest "aktywny klient", jak liczymy "przychód netto", jaka jest formuła churn rate. To warstwa dla narzędzi BI i raportów operacyjnych.
Przepływ jest zawsze jednokierunkowy: bronze → silver → gold. Każda transformacja jest udokumentowana, wersjonowana i odtwarzalna. Gdy pojawia się błąd w warstwie gold, mogę wrócić do bronze i przeprocesować dane od nowa.
Typowe błędy architektoniczne
Przez lata widziałem dziesiątki nieudanych wdrożeń. Większość wynikała z jednego z dwóch błędów.
Błąd pierwszy: Lakehouse jako źródło raportowe
Zespół buduje Lakehouse, ładuje dane, a następnie podłącza Power BI bezpośrednio do warstwy silver. Na początku działa. Po sześciu miesiącach mamy chaos: pięć różnych definicji przychodu w pięciu raportach, zapytania działające minutami zamiast sekund, analitycy tworzący własne "poprawki" w Power Query.
Lakehouse nie jest zoptymalizowany pod wzorce dostępu BI. Brakuje indeksów kolumnowych, agregacji, materializowanych widoków. Brakuje też warstwy semantycznej, która wymusza spójność definicji.
Błąd drugi: Warehouse jako miejsce przetwarzania
Organizacja ma Data Warehouse i próbuje w nim realizować całą inżynierię danych. Procedury składowane rosną do tysięcy linii, ETL trwa godzinami, każda zmiana w źródle wymaga modyfikacji skomplikowanej logiki. Elastyczność spada do zera, a zespół boi się dotykać czegokolwiek.
Data Warehouse nie jest zaprojektowany do eksperymentowania. Wymuszanie schematu przy zapisie (schema-on-write) utrudnia pracę z nowymi źródłami. Koszt storage jest wyższy niż w Lakehouse. Przetwarzanie równoległe na dużą skalę jest ograniczone.
Najdroższy błąd architektoniczny to nie zły wybór technologii. To brak jasnego podziału odpowiedzialności między warstwami. Kiedy wszystko może być wszędzie, nic nie jest nigdzie wiarygodne.
Microsoft Fabric jako przykład integracji
Microsoft Fabric to platforma, która dobrze ilustruje właściwy podział odpowiedzialności. Nie dlatego, że jest jedyną opcją, ale dlatego, że architektura jest w niej wyraźnie zarysowana.
Lakehouse w Fabric wspiera przetwarzanie Spark, obsługuje różne formaty plików, integruje się z notebookami do eksploracji danych. To tutaj data engineer buduje pipeline'y, czyści dane, przygotowuje je do dalszego użycia.
Warehouse w Fabric to środowisko T-SQL, zoptymalizowane pod zapytania analityczne. Automatyczne indeksowanie, optymalizator zapytań, integracja z Power BI przez DirectLake. To tutaj analityk biznesowy buduje raporty, mając pewność, że dane są spójne i wydajnie dostępne.
Oba komponenty współdzielą OneLake jako warstwę storage. Dane zapisane w Lakehouse mogą być eksponowane do Warehouse przez skróty (shortcuts) bez kopiowania. Przepływ bronze → silver → gold jest naturalny i wspierany przez platformę.
Jak zaprojektować przepływ danych
Zamiast pytać "które wybrać", zadaj sobie inne pytania:
- Jakie są źródła danych i w jakich formatach dostarczają dane?
- Kto będzie konsumentem danych i jakie ma wymagania?
- Jakie transformacje są potrzebne między surowym a gotowym stanem?
- Gdzie powinna leżeć logika biznesowa i kto ją utrzymuje?
- Jakie są wymagania dotyczące wydajności, retencji i compliance?
Odpowiedzi na te pytania wskażą, jak podzielić odpowiedzialność między warstwy. Lakehouse dla ingestion i transformacji. Warehouse dla konsumpcji i governance. A między nimi jasno zdefiniowane kontrakty danych.
Dług techniczny w architekturze danych
Źle zaprojektowana architektura generuje dług techniczny, który rośnie wykładniczo. Po roku masz dziesiątki raportów opartych na niespójnych źródłach. Po dwóch latach nikt nie wie, która wersja danych jest poprawna. Po trzech latach projekt modernizacji kosztuje więcej niż budowa od zera.
Widziałem organizacje, które wydały miliony na platformy danych, a nadal eksportują dane do Excela, bo "tylko tam się zgadza". To nie jest problem technologii. To problem braku architektury.