Raport sprzedaży pokazuje inną kwotę niż eksport z systemu zamówień, a zespół nie wie, której tabeli zaufać. Architektura medallion zwykle porządkuje ten przepływ w warstwy bronze, silver i gold, ale sama kolejność nie naprawi błędnych reguł ani nie ustali, co ma oznaczać „sprzedaż”.
Warstwy mają sens tylko wtedy, gdy każda daje odbiorcy jasną gwarancję
- Bronze zachowuje dane źródłowe wraz z informacją o ich pochodzeniu.
- Silver porządkuje formaty, duplikaty i definicje wspólne dla zespołów.
- Gold udostępnia dane przygotowane pod konkretne raporty i decyzje.
- Granice warstw powinny wynikać z jakości i odbiorców, a nie z samej nazwy.
- Dobór platformy zależy od formatu danych, sposobu przetwarzania i kompetencji zespołu.
Trzy warstwy powinny oznaczać trzy różne obietnice
Wyobraź sobie plik z zamówieniami, w którym data raz ma format ISO, a raz polski zapis, a anulowane transakcje nadal wyglądają jak sprzedaż. Podział na warstwy pomaga oddzielić zapis źródła od danych po walidacji i od tabeli gotowej do raportowania. Microsoft Learn opisuje ten wzorzec jako stopniowe podnoszenie jakości, a nie samą zmianę nazw katalogów.
Bronze przechowuje dane blisko postaci źródłowej, wraz z metadanymi ładowania, takimi jak czas pobrania czy identyfikator systemu. Dzięki temu można odtworzyć dalsze transformacje, gdy zmieni się reguła biznesowa albo wykryjesz błąd w przetwarzaniu. Warstwa silver ujednolica definicje, typy i klucze, a gold podaje wynik w formie dopasowanej do raportu, modelu analitycznego lub aplikacji.
Najważniejsza jest obietnica dla odbiorcy. Silver może być wiarygodnym zbiorem szczegółowym dla analityka, podczas gdy gold może zawierać już agregaty, których nie da się bezpiecznie wykorzystać do każdego pytania. Nie traktuję więc gold jako automatycznie „lepszej tabeli”; to raczej produkt danych z określonym przeznaczeniem.
Przepuszczaj dane dalej dopiero po spełnieniu warunku jakości
Jeśli tabela trafia do kolejnej warstwy mimo błędnych kluczy, brakujących dat lub niezgodnych statusów, problem tylko zyskuje ładniejszą nazwę. Ustal warunki przejścia przed napisaniem pipeline’u: jakie rekordy są poprawne, co trafia do kwarantanny i kto może zatwierdzić wyjątek.
| Sytuacja | Prawdopodobna przyczyna lub skutek | Co zrobić |
|---|---|---|
| W bronze przybywa rekordów, ale silver stoi | Walidacja odrzuca nowe wartości albo zmienił się schemat źródła | Sprawdź log błędów i skieruj rekordy niezgodne z regułą do kwarantanny, zamiast je po cichu usuwać |
| Raport gold ma inną sumę niż system operacyjny | Różnią się definicje statusu, momentu księgowania lub anulowania | Uzgodnij definicję miary w silver, a potem przelicz gold z tej samej reguły |
| Zmiana klienta w systemie nie aktualizuje raportu | Proces przyrostowy nie obsługuje aktualizacji albo usunięć | Dodaj obsługę zmian, na przykład przez upsert, i sprawdź, jak źródło sygnalizuje usunięcie |
| Po ponownym uruchomieniu pipeline’u suma rośnie drugi raz | Ładowanie nie jest idempotentne, czyli ponowne wykonanie dopisuje te same zdarzenia | Ustal stabilny klucz zdarzenia i zapisuj dane tak, by powtórzenie przebiegu dawało ten sam stan |
Praktyczna reguła jest prosta: rekordy poprawne przechodzą dalej, niejednoznaczne trafiają do kwarantanny, a naruszenie kontraktu zatrzymuje publikację gold. Nie każda kontrola musi blokować cały zbiór. Błąd krytyczny, taki jak brak identyfikatora zamówienia, może zatrzymać partię; nietypowy, ale dopuszczalny kod kraju może zostać oznaczony do sprawdzenia.
Przykład: dzienny przyrost zawiera 10 000 zamówień, z czego 12 nie ma identyfikatora klienta. Jeśli raport mierzy przychód według zamówień, możesz dopuścić te rekordy do silver z wartością klienta „nieznany”; jeśli raport wylicza retencję klientów, te same rekordy powinny zostać wyłączone z tej miary. Jeden brak nie musi oznaczać jednego skutku, bo zależy on od przeznaczenia tabeli.
Nie musisz tworzyć osobnego lakehouse dla każdej warstwy
W zespołach łatwo zamienić wzorzec w sztywny przepis: trzy nazwy mają oznaczać trzy osobne systemy. Dokumentacja Microsoftu pokazuje jednak również wariant SQL-first, w którym bronze, silver i gold działają w hurtowniach Fabric, gdy dane są strukturalne i transformacje pozostają w SQL. Wybór magazynu powinien wynikać z obciążenia, a nie z medallionowej etykiety.
Dla danych plikowych, półstrukturalnych, pracy w Spark lub zadań data science naturalnym wyborem może być lakehouse. W Fabric typowy wariant łączy lakehouse dla bronze i silver z hurtownią dla gold, choć możliwe są też inne układy. Gdy źródła i odbiorcy pracują głównie w SQL, hurtownia dla wszystkich warstw może ograniczyć liczbę silników i miejsc utrzymania.
Reguła wyboru: jeśli zespół przetwarza głównie pliki, strumienie lub dane półstrukturalne i potrzebuje Spark, zacznij od lakehouse; jeśli model jest relacyjny, a transformacje i konsumpcja są SQL-owe, rozważ hurtownię. Jeśli masz oba typy obciążeń, rozdziel warstwy według funkcji, nie według mody. W Microsoft Fabric dane w formacie Delta Lake mogą być wykorzystywane przez różne silniki, ale nie zwalnia to z ustalenia, który zespół odpowiada za definicję i jakość tabeli.
Prawdę mówiąc, więcej granic oznacza też więcej konfiguracji, uprawnień i monitorowania. W wąskim projekcie jedna przestrzeń robocza z osobnymi schematami może być łatwiejsza do obsługi; gdy różne zespoły potrzebują odmiennych uprawnień lub cykli wdrożeń, osobne przestrzenie i produkty danych dają czytelniejszy podział. Databricks wskazuje Unity Catalog jako sposób organizowania schematów warstwowych, a Delta Lake jako format wspierający transakcje i śledzenie zmian. To nazwy konkretnych narzędzi, nie wymóg architektury.
Przyrostowe ładowanie wymaga obsługi zmian, nie tylko nowych wierszy
Najczęstsza pułapka pojawia się, gdy „przetwarzanie przyrostowe” oznacza wyłącznie dopisanie nowych rekordów. Aktualizacja istniejącego zamówienia, korekta ceny albo usunięcie klienta może wtedy nie dotrzeć do gold. Przed wyborem strategii ustal, czy źródło wysyła pełne migawki, zdarzenia zmian, czy tylko nowe wiersze.
Załóżmy, że system sprzedażowy wysyła dzienny plik, a zamówienie o identyfikatorze 731 zmienia status z „nowe” na „anulowane”. Jeśli silver tylko dopisuje kolejną wersję, gold może policzyć zamówienie dwa razy albo nadal uwzględniać wcześniejszy status. Wtedy potrzebujesz stabilnego klucza, reguły wyboru aktualnej wersji oraz zapisu typu upsert, który aktualizuje istniejący rekord.
W przypadku historii nie nadpisuj wszystkiego bez namysłu. Jeśli raport ma odpowiadać na pytanie „jaki jest status teraz”, wystarczy aktualny stan. Jeśli ma pokazywać, co wiedziała firma na koniec poprzedniego miesiąca, silver musi zachować wersje i okres ich obowiązywania. Zakres historii powinien wynikać z pytań odbiorców, bo bez tej decyzji aktualizacja może nieodwracalnie usunąć potrzebny kontekst.
Przy planowaniu odtworzenia sprawdź także zależności: czy możesz zbudować silver ponownie z bronze i czy gold nie zależy od ręcznych poprawek poza pipeline’em. W Fabric dokumentacja opisuje między innymi materializowane widoki lakehouse, które mogą automatycznie dobierać odświeżenie przyrostowe lub pełne. Takie funkcje upraszczają orkiestrację, ale nie zastąpią kontroli, czy wynik po zmianie danych nadal spełnia kontrakt.
Zacznij od jednej ścieżki danych i jednego odbiorcy
Rozbudowana mapa warstw wygląda przekonująco na diagramie, lecz pierwsze wdrożenie powinno zamknąć konkretny problem. Wybierz jedno źródło i jedną miarę, której dziś nie da się uzgodnić, na przykład dzienny przychód z zamówień, a potem określ, co oznacza rekord surowy, poprawny i gotowy do raportu.
- W bronze zachowaj źródło oraz metadane pobrania, tak by można było odtworzyć przetwarzanie.
- W silver opisz typy, klucze, duplikaty, statusy oraz zachowanie dla brakujących wartości.
- W gold publikuj tylko miary i agregaty, których definicję zaakceptował odbiorca raportu.
- Monitoruj opóźnienie, liczbę odrzuceń i zgodność sum między warstwami.
Wybór zaczyna się od odbiorcy, nie od liczby katalogów. Ja zacząłbym od tabeli silver z jasnym kontraktem i jednego produktu gold, a kolejne podziały dodał dopiero wtedy, gdy uzasadnią je odmienne uprawnienia, częstotliwość danych albo sposób obliczeń. Dzięki temu pytanie o rozbieżny raport wraca do konkretnej reguły lub etapu, zamiast ginąć między trzema nazwami warstw.
