Czym jest architektura medaliowa? Wyjaśnienie warstw Bronze, Silver i Gold

Architektura medaliowa vs tradycyjne potoki ETL

W hurtowniach danych z tradycyjnymi potokami extract-transform-load (ETL) musisz z góry zdefiniować schemat danych. Jeśli format lub schemat się zmieni, system się wyłoży, chyba że ręcznie go dostosujesz. 

W architekturze extract-load-transform (ELT) opartej na medaliach najpierw zapisujesz dane w surowej postaci, zamiast przekształcać je w locie i przechowywać efekt końcowy. Ta różnica sprawia, że architektury medaliowe są zarazem odporne i elastyczne: możesz przechowywać surowe dane „jak leci” i zdecydować później, jak ich użyć. 

Pełne porównanie obu koncepcji znajdziesz w naszym przewodniku ETL vs ELT.

Kolejną zaletą architektury medaliowej jest jej niezależność od platformy. Bronze, Silver i Gold to etapy logiczne, a nie technologie związane z konkretnym dostawcą. Wzorzec można wdrożyć z użyciem różnych systemów przechowywania, silników przetwarzania i formatów tabel, w zależności od platformy danych i wymagań dotyczących obciążeń.

Jak działają warstwy Bronze, Silver i Gold w architekturze medaliowej?

Trzy warstwy medaliowe tworzą logiczną sekwencję, z których każda buduje na poprzedniej.

Warstwa Bronze: surowe dane jako punkt odtworzeniowy

Tu trafiają surowe dane „jak są”, niezależnie czy to relacyjne bazy danych, aplikacje SaaS jak Salesforce, tematy Kafki niosące zdarzenia w czasie rzeczywistym, REST API, eksporty CSV czy strumienie z urządzeń IoT. Ingestią zwykle zajmują się narzędzia takie jak Fivetran do przechwytywania zmian (CDC) lub Databricks Auto Loader dla plików trafiających do storage’u obiektowego.

Dane Bronze zwykle zawierają sporo błędów, niespójności i duplikatów, więc nigdy nie powinny być używane bezpośrednio do celów biznesowych. Mimo to warstwa ta jest bardzo cenna jako punkt odtworzeniowy, z którego możesz odtworzyć dane Silver lub Gold.

Znaczenie warstwy wynika z jej śladu: rejestruje i loguje każde zdarzenie lub transakcję ingestii. Często zawiera cenne metadane, takie jak znaczniki czasu ingestii, pochodzenie danych i różnego rodzaju identyfikatory. Celem jest przechowywanie danych w możliwie surowej i kompletnej formie, aby można było odtwarzać dalsze potoki na tych samych danych źródłowych w celu debugowania błędów.

Warstwa Silver: warstwa kontraktu

Warstwa Silver przekształca surowe dane w czyste, ustrukturyzowane dane. Oto kilka przykładów ważnych transformacji czyszczących realizowanych między poziomami Bronze i Silver:

• Filtrowanie zbędnych kolumn
• Usuwanie duplikatów rekordów
• Naprawa niespójności
• Obsługa braków danych
• Standaryzacja danych
• Łączenie i scalanie różnych zbiorów danych

Ta warstwa zawiera też egzekwowanie schematu, zapewniając, że dane spełniają z góry zdefiniowaną strukturę i wspierają ewolucję schematu. 

Tu też przeprowadzasz kontrole jakości danych. Na przykład dodajesz reguły flagujące lub odrzucające nieudane transakcje biznesowe czy wartości odstające. To pierwszy krok do poprawy jakości danych w miarę przechodzenia przez kolejne etapy.

Ponieważ na tym etapie modyfikujesz dane, ważne jest używanie narzędzi do linii danych (data lineage), takich jak dbt, aby śledzić, jak dane są przekształcane z Bronze do Silver. Kontrole jakości zwykle wdraża się testami dbt, Great Expectations lub Soda, a ład nadzorczy egzekwuje się poprzez katalog danych, taki jak Databricks Unity Catalog lub Collibra.

Jeśli chcesz nauczyć się, jak zamieniać chaotyczne dane w porządne zbiory silver, polecam zacząć od naszego kursu Cleaning Data in Python.

Warstwa Gold: wyjścia gotowe dla biznesu

Ostatnia warstwa przechowuje dane o najwyższej możliwej jakości. Te silnie dopracowane dane są używane do raportowania w Power BI, Tableau lub Lookerze, konsumowane przez aplikacje analityczne downstream lub serwowane do modeli ML przez feature store, taki jak Feast lub Databricks Feature Store.

Ponieważ dane są już oczyszczone, ten etap skupia się na zamianie ich w wartościowy zasób biznesowy. W zależności od konkretnego przypadku użycia (pomyśl o raportach finansowych, dashboardach marketingowych, systemach alertów, treningu modeli ML, …), transformacje po Silver zapewniają, że Gold zawiera dokładnie te informacje, które są potrzebne do wykonania zadania.

Tutaj tworzysz KPI, stosujesz niestandardowe formuły biznesowe lub agregujesz do danych tygodniowych, miesięcznych czy kwartalnych na potrzeby raportów cyklicznych. Operacje w Bronze i Silver są często wspólne, a w Gold — bardziej elastyczne i dopasowane do sposobu użycia danych.

Jak odbudować Silver i Gold z danych Bronze?

Zachowywanie surowych danych w Bronze ma sens tylko wtedy, gdy faktycznie możesz ich użyć — dzieje się tak za każdym razem, gdy coś zmienia się w górę lub w dół strumienia. Koszt zmiany zależy od tego, jak daleko w łańcuchu ona leży. 

• Zmiana schematu źródła oznacza odtworzenie Bronze przez Silver i Gold. 
• Zmiana definicji biznesowej (np. nowa reguła przychodu lub inny horyzont agregacji) oznacza jedynie odbudowę Gold z już zwalidowanego Silver.

W żadnym z tych przypadków nie wracasz do systemu źródłowego. To właśnie umożliwia historyczne korekty, ponieważ źródło może już nie przechowywać danych w formie, w jakiej pierwotnie je zassałeś. 

Oznacza to też, że możesz zmienić definicję metryki bez ponownego uruchamiania ingestii — i to jest praktyczny powód, dla którego zespoły z wieloma odbiorcami Gold trzymają warstwy oddzielnie.

Gdzie architektura medaliowa mieści się w data lakehouse?

A data lakehouse daje tani storage obiektowy jak jezioro danych oraz gwarancje transakcyjne jak w hurtowni. Nie mówi jednak, jak ułożyć tabele w środku. Tu wchodzi medaliowa: lakehouse to podłoże magazynujące, a Bronze, Silver i Gold to sposób podziału na katalogi, schematy i tabele z różnymi gwarancjami jakości.

W praktyce ten podział zwykle jest fizyczny. W Databricks możesz mieć trzy schematy w katalogu Unity Catalog, a w Microsoft Fabric — lakehouse z tabelami Bronze i Silver zasilającymi magazyn Gold. Ten sam wzorzec, inna hydraulika.

Otwarte formaty tabel sprawiają, że warstwy wytrzymują jednoczesne odczyty i zapisy. Delta Lake, Apache Iceberg i Apache Hudi oferują w różnych kombinacjach:

• Transakcje ACID
• Ewolucję schematu
• Wersjonowanie stanu tabeli
• Kontrole współbieżności
• Ewolucję partycjonowania
• Time travel

Wersjonowanie jest najważniejsze dla zachowania możliwości odtwarzania, o którym właśnie mówiliśmy. Surowe pliki Parquet dobrze zachowują dane źródłowe, ale nie dają historii transakcyjnej do odtworzenia, więc zły przebieg Silver nadpisuje dobry i nie masz do czego porównać. Delta Lake śledzi zmiany w dzienniku transakcji, a Apache Iceberg reprezentuje stany tabel jako migawki.

Żadne z tego nie jest obowiązkowe. Medaliowa to wzorzec logiczny i wiele zespołów uruchamia go na schematach Postgresa lub zwykłych prefiksach S3 z dbt na wierzchu. Po prostu tracisz tani rollback.

Architektura medaliowa vs data mesh

Te dwie rzeczy często się porównuje, zwykle dlatego, że ludzie zakładają, iż konkurują. Odpowiadają jednak na różne pytania: data mesh decyduje, kto jest właścicielem danych, a architektura medaliowa decyduje, jak ten właściciel je dopracowuje.

Data mesh przekazuje odpowiedzialność za dane zespołom domenowym, jak sprzedaż, finanse czy łańcuch dostaw, które publikują swoje dane jako produkty i odpowiadają za ich jakość, odkrywalność, linię danych i ład korporacyjny. Spaja to dwoje: infrastruktura samoobsługowa dająca każdej domenie te same narzędzia oraz federacyjny ład, który ustala standardy na poziomie organizacji bez odbierania własności domenom.

Architektura medaliowa to to, co zespół domenowy uruchamia w swojej części. Zespół łańcucha dostaw, który posiada dane o wysyłkach, trzyma surowe zdarzenia wysyłek w Bronze, zwalidowane rekordy w Silver i publikuje w Gold zbiory wysyłkowe gotowe do analizy, które inne domeny mogą konsumować. Mesh definiuje kontrakt na granicy Gold; wszystko powyżej to sprawa tego zespołu.

Jedno zastrzeżenie, zanim je połączysz: domenowe warstwy Bronze oznaczają, że każda domena ponosi własny koszt ingestii i storage’u, a wspólne wymiary, jak klient czy produkt, mają tendencję do bycia odtwarzanymi w trzech miejscach. Zwolennicy mesh powiedzą, że to cena własności. To nadal realny koszt, warty policzenia, zanim się zobowiążesz.

Jakie są zalety i ograniczenia architektury medaliowej?

Medaliowa daje ci ponowne użycie i możliwość odtworzenia, a kosztuje storage, opóźnienie i liczbę potoków. Czy ten trade-off się opłaca, zależy niemal wyłącznie od tego, ilu masz odbiorców.

Opóźnienie najłatwiej zlekceważyć. Każda warstwa to zwykle osobne zadanie harmonogramowane, więc trójwarstwowy potok wsadowy uruchamiany co godzinę może zostawiać Gold dwie godziny za systemem źródłowym. To w porządku dla tygodniowego raportu przychodów i nie w porządku dla alertu operacyjnego — dlatego zespoły często pozwalają alertom czytać bezpośrednio z Silver, zamiast czekać na Gold.

Storage to koszt, o którym ludzie mówią najpierw, a zwykle jest mniejszym problemem. Bronze siedzi w tanim storage’u obiektowym, a duplikacja jest realna, ale ograniczona. Prawdziwie boli liczba potoków: trzy warstwy na dwadzieścia tabel źródłowych to sześćdziesiąt rzeczy, które mogą się wywalić o 3 nad ranem.

Z drugiej strony słaba jakość danych też ma swój rachunek. IBM raportował w 2026 r., że 43% COO wskazało jakość danych jako swój najważniejszy priorytet danych, na podstawie badań z 2025 roku z Institute for Business Value. Ponad jedna czwarta organizacji z tego badania zgłosiła roczne straty przekraczające 5 mln USD z powodu złej jakości danych.

Pytanie więc nie brzmi, czy wdrożenie architektury medaliowej kosztuje więcej niż pojedynczy potok — bo kosztuje. Pytanie brzmi, czy i tak nie płacisz już za alternatywę w postaci spotkań pojednawczych i pulpitów, którym nikt nie ufa.

Kiedy używać architektury medaliowej?

Medaliowa zwraca się, gdy te same oczyszczone dane służą więcej niż jednemu odbiorcy. To najlepszy predyktor — ważniejszy niż wolumen danych, rozmiar zespołu czy liczba źródeł.

Używaj architektury medaliowej, gdy:

• Wiele zespołów lub obciążeń czyta te same dane. Wyczyść i zestandaryzuj raz w Silver, a potem zbuduj tyle zbiorów Gold, ile potrzebujesz do BI, raportowania czy trenowania modeli.
• Różne pytania biznesowe wymagają różnych kształtów tych samych danych. Finanse chcą miesięcznego przychodu rozpoznanego, a sprzedaż — dziennych rezerwacji wg przedstawiciela. Oba pochodzą z jednej tabeli Silver, bez duplikowania logiki ingestii.
• Twoje źródła nie zgadzają się ze sobą. Silver to miejsce, gdzie uzgadniasz ID konta z Salesforce z ID klienta w systemie rozliczeniowym, zanim ktoś downstream będzie musiał zgadywać, które jest autorytatywne.
• Musisz się wytłumaczyć z liczby. Oddzielenie danych surowych, zwalidowanych i kuratowanych pozwala cofnąć się do każdej transformacji, zamiast wyprowadzać sporną wartość od zera.
• Logika transformacji często się zmienia. Jak wyżej: zachowane dane Bronze pozwalają na odbudowę bez wracania do źródła.

Pomiń, gdy:

• Masz mały zespół danych i ograniczoną złożoność potoków.
• Dane pochodzą z jednego źródła i wymagają minimalnego czyszczenia lub transformacji.
• Dane konsumuje tylko jedna aplikacja lub zespół downstream.
• Twoje wymagania raportowe są proste i nie uzasadniają utrzymywania wielu warstw przetwarzania.

Gdy dwie warstwy wystarczą

Diagram trzech warstw to domyślna opcja, nie wymóg. Przy jednym biznesowym przypadku użycia, Bronze plus jedna warstwa łączona to często najlepszy wybór: zachowaj surowe dane do odtworzenia, a potem zrób czyszczenie i logikę biznesową w jednym kroku.

Dobierz kształt do swoich odbiorców. Czego nie powinieneś scalać, to Bronze — tej warstwy nie odtworzysz.

Jeśli więc jesteś pośrodku i szczerze nie wiesz, budowa dwóch warstw i dodanie trzeciej, gdy pojawi się drugi odbiorca, to dobry kierunek. Dodanie Gold później jest dużo tańsze niż dobudowa Bronze po pół roku nadpisywania surowych danych.

Najczęstsze błędy przy wdrożeniach medaliowych

Większość problemów medaliowych nie jest architektoniczna. To drobne kompromisy pod presją terminów, które po cichu odbierają powód, dla którego zbudowałeś warstwy.

Transformacje danych w Bronze

Cały argument o odtwarzaniu opiera się na tym, że Bronze trzyma coś bliskiego temu, co faktycznie wysłało źródło. Jeśli zastosujesz logikę biznesową przed lądowaniem danych, tracisz stan oryginalny — a więc brak możliwości ponownego przetworzenia i brak ścieżki audytu.

To zwykle dzieje się z dobrych powodów. Ktoś usuwa nieużywaną kolumnę, by oszczędzić miejsce, albo konwertuje problematyczne pole znacznika czasu przy ingestii, bo psuje kolejne zadanie. Sześć miesięcy później „nieużywana” kolumna okazuje się ważna — a oryginalne wartości zniknęły. Trzymaj Bronze jak najbliżej źródła, jak to praktycznie możliwe, a poprawki rób w Silver.

Zacieranie granicy między Silver i Gold

Silver czyści i standaryzuje. Gold odpowiada na pytania biznesowe. Gdy logika metryk przecieka do Silver, każdy zbiór Gold dziedziczy definicję, o którą nie prosił — i wracasz do problemu, który medaliowa miała rozwiązać.

Test jest prosty: jeśli użytkownik biznesowy spiera się o liczbę, to należy do Gold. Deduplikacja to kwestia Silver. To, co liczy się jako aktywny klient — nie.

Traktowanie trzech warstw jako obowiązkowych

Architektura medaliowa to wzorzec projektowy, a nie wymóg, by każdy potok miał dokładnie trzy fizyczne warstwy. Bronze, Silver i Gold reprezentują logiczne etapy udoskonalania danych i każdą warstwę można wdrożyć inaczej w zależności od obciążenia. 

Na przykład warstwa może używać zmaterializowanych tabel, widoków lub innych odpowiednich abstrakcji, zamiast wymagać osobnej fizycznej kopii danych. Chodzi o stworzenie sensownych granic w miarę przechodzenia danych ze stanu surowego do czegoś, czemu biznes może ufać i używać — a nie o wierne odtwarzanie klasycznego diagramu trzech warstw. 

Zostawianie Gold jako składowiska

To widzę najczęściej i najmniej się o tym mówi. Zbiory Gold są tanie w tworzeniu i nikt ich nigdy nie usuwa, więc po roku możesz mieć czterdzieści tabel, jedenaście z nich to wariacje miesięcznego przychodu — i nikt nie pamięta, na którą faktycznie patrzy CFO.

Silver ma naturalną dyscyplinę, bo jej rola jest zdefiniowana. Gold nie, więc potrzebuje właściciela dla każdego zbioru i gotowości do usuwania. Bez tego skończysz z kilkoma konkurującymi wersjami tej samej metryki — czyli problemem, któremu warstwy miały zapobiegać.

Na koniec

To, co medaliowa naprawdę daje, to miejsce, w które możesz wskazać, gdy ktoś zapyta, skąd wzięła się liczba, oraz kopia oryginalnych danych, do której możesz wrócić, gdy odpowiedź okaże się błędna. To warte dodatkowego storage’u i dodatkowych zadań, gdy te same dane czyta kilka zespołów. Gdy czyta je tylko jeden — dwie warstwy mogą być lepszym rozwiązaniem i oszczędzić ci utrzymania.

Jeśli chcesz szerszego kontekstu, gdzie ten wzorzec się mieści, nasz kurs Understanding Modern Data Architecture omawia platformy i technologie za współczesnymi stosami danych. Nasza ścieżka kariery Data Engineer idzie dalej w budowę i utrzymanie potoków produkcyjnych.