Wiele zespołów wdraża Medallion, bo tak się robi w Fabric albo Databricks. Rzadziej zastanawia się, co ta architektura faktycznie wymusza i gdzie zaczynają się prawdziwe problemy.
Trzy warstwy to trzy różne kontrakty
Architektura Medallion w swojej istocie nie jest strukturą katalogów ani konwencją nazewniczą. To model odpowiedzialności za jakość danych na każdym etapie ich przetwarzania. Zanim przejdziemy do problemów, ustalmy fundamenty.
Bronze to warstwa surowych danych. Bez transformacji, bez poprawek, bez ingerencji. Jedyna gwarancja jest taka, że dane dotarły i pozostają niezmienione względem źródła. Bronze pełni funkcję archiwum i punktu recovery. Gdy cokolwiek pójdzie nie tak w dalszych warstwach, zawsze możesz wrócić do oryginału.
Silver to dane oczyszczone i ujednolicone. Tutaj egzekwujesz schematy, obsługujesz duplikaty, normalizujesz typy danych i uzupełniasz brakujące wartości według zdefiniowanych reguł. Konsumenci Silver muszą wiedzieć, czego mogą się spodziewać. To jest kontrakt, nie folder z plikami.
Gold to warstwa analityczna i domenowa. Agregaty, metryki biznesowe, tabele faktów i wymiarów. Koszty obliczeń są tutaj najwyższe, więc każda tabela powinna mieć uzasadnienie w konkretnym przypadku użycia biznesowego.
W praktyce spotykam zespoły, które mają pięknie nazwane katalogi Bronze, Silver i Gold, ale dane przepływają między nimi bez żadnej walidacji. To nie jest Medallion. To iluzja architektury.
Pierwsza pułapka: Silver jako prawie Bronze
Najczęstszy błąd, który obserwuję w projektach lakehouse, to traktowanie warstwy Silver jako tymczasowego przystanku. Dane trafiają tam bez egzekwowania schematów, bo na razie nie ma czasu albo bo jeszcze nie wiemy, jak będą wyglądać docelowe struktury.
Problem polega na tym, że Gold budowany na niestabilnym Silver dziedziczy wszystkie jego wady. Agregaty w Gold zaczynają się rozjeżdżać, bo typy danych w Silver nie są spójne. Raporty pokazują różne wyniki w zależności od tego, kiedy zostały uruchomione.
W SQL Server możesz wykorzystać mechanizmy walidacji już na poziomie ładowania do Silver. Constraints, triggers walidacyjne, a w nowszych środowiskach zewnętrzne frameworki do data quality. Kluczowe jest jedno: jeśli dane nie spełniają kontraktu Silver, nie powinny tam trafić. Powinny zostać w Bronze z odpowiednim oznaczeniem do review.
Praktyczne podejście do walidacji Silver
Zdefiniuj explicit schema dla każdej tabeli Silver. Nie chodzi o dokumentację, ale o kod, który będzie egzekwowany przy każdym ładowaniu. W środowisku SQL Server możesz użyć tabel stagingowych z pełną walidacją przed przeniesieniem do docelowych struktur Silver.
Implementuj rejection tables. Rekordy, które nie przeszły walidacji, trafiają do osobnej struktury z informacją o przyczynie odrzucenia. Dzięki temu masz pełną transparentność i możliwość późniejszej naprawy bez utraty danych.
Druga pułapka: duplikowanie logiki transformacji
Jeśli ta sama reguła czyszczenia pojawia się zarówno w procesie ładowania Silver, jak i w transformacjach Gold, to znak, że granica między warstwami została źle poprowadzona.
Typowy przykład: normalizacja kodów krajów. W Silver zamieniasz różne warianty na standard ISO. Ale potem w Gold znowu sprawdzasz i poprawiasz, bo nie ufasz danym z Silver. Efekt jest taki, że masz dwie wersje tej samej logiki, które z czasem zaczynają się rozjeżdżać.
Zasada jest prosta: każda transformacja powinna mieć dokładnie jedno miejsce wykonania. Silver odpowiada za czyszczenie i standaryzację. Gold odpowiada za agregację i modelowanie biznesowe. Jeśli w Gold musisz czyścić dane, to znaczy, że Silver nie spełnia swojego kontraktu.
Duplikacja logiki transformacji to nie jest problem techniczny. To symptom braku jasnych granic odpowiedzialności między warstwami. Rozwiązanie jest organizacyjne, nie narzędziowe.
Trzecia pułapka: late arriving data bez strategii
Bronze przyjmuje wszystko. Dane sprzed tygodnia, korekty faktur z poprzedniego miesiąca, opóźnione zdarzenia z systemów zewnętrznych. Problem pojawia się później: jak propagować te korekty przez Silver do Gold bez przebudowy całego pipeline?
W tradycyjnym podejściu batch processing każde przeładowanie oznacza pełne przeliczenie. W skali enterprise to może oznaczać godziny przetwarzania i okna niedostępności raportów.
Tutaj Delta Lake albo podobne rozwiązania z obsługą upsertów przestają być opcją i stają się koniecznością. Mechanizm MERGE pozwala na atomowe aktualizacje bez przebudowy całych partycji. Change Data Capture umożliwia śledzenie, które rekordy wymagają propagacji.
Strategia dla late arriving data w SQL Server
Implementuj kolumny techniczne śledzące czas przybycia danych oraz czas ich przetworzenia w każdej warstwie. Dzięki temu możesz łatwo zidentyfikować rekordy wymagające reprocessingu.
Rozważ podział Gold na warstwy hot i cold. Hot zawiera dane z ostatnich N dni i jest przeliczany częściej. Cold zawiera dane historyczne i jest aktualizowany tylko gdy wykryjesz korekty w Bronze.
Warto też przemyśleć idempotentność procesów. Pipeline, który można bezpiecznie uruchomić wielokrotnie z tym samym wynikiem, znacząco upraszcza obsługę korekt i reruns.
Ownership i monitorowanie: bez tego Medallion nie działa
Architektura Medallion wymaga jasnego ownership na każdej warstwie. Kto jest odpowiedzialny za jakość Bronze? Kto definiuje kontrakt Silver? Kto decyduje, które agregaty trafiają do Gold?
W praktyce spotykam dwa modele. Pierwszy to ownership wertykalny, gdzie jeden zespół odpowiada za cały przepływ danych od źródła do Gold. Drugi to ownership horyzontalny, gdzie różne zespoły zarządzają różnymi warstwami.
Oba modele mogą działać, ale wymagają różnych mechanizmów koordynacji. Model wertykalny jest prostszy organizacyjnie, ale utrudnia standaryzację między domenami. Model horyzontalny wymusza standaryzację, ale komplikuje debugging i rozwiązywanie problemów.
Monitorowanie odchyleń od kontraktu
Każda warstwa powinna mieć zdefiniowane metryki jakości i automatyczne alerty przy ich przekroczeniu. Dla Silver typowe metryki to: procent rekordów odrzuconych, liczba duplikatów, kompletność kluczowych pól. Dla Gold: spójność agregatów z poprzednim okresem, pokrycie wymiarów, czas odświeżenia.
W SQL Server możesz wykorzystać Database Mail w połączeniu z jobami sprawdzającymi, Extended Events do śledzenia anomalii, albo zewnętrzne narzędzia do observability.
Kiedy Medallion ma sens, a kiedy to przerost formy
Medallion sprawdza się gdy masz wiele źródeł danych o różnej jakości, wielu konsumentów o różnych potrzebach oraz wymóg audytowalności i możliwości odtworzenia historii transformacji.
Medallion to przerost formy gdy masz jedno źródło danych, jednego konsumenta i proste transformacje. W takim przypadku dodatkowe warstwy to tylko overhead operacyjny i storage.
Nie wdrażaj Medallion, bo tak się robi. Wdrażaj, bo rozwiązuje konkretny problem w twoim środowisku. A jeśli wdrażasz, traktuj to poważnie. Zdefiniuj kontrakty, wyznacz właścicieli, monitoruj jakość.