course
Majoritatea discuțiilor despre calitatea datelor se concentrează pe repararea surselor proaste. Dar echipe diferite de date pot construi cinci dashboarduri complet diferite din același sistem sursă, cu cifre de venit diferite pentru același trimestru. Datele sursă nu sunt neapărat problema aici. Fiecare consumator poate curăța, uni, filtra și defini acele date în mod independent, fără un standard comun pentru ce înseamnă „curat”.
Arhitectura medallion abordează această problemă oferind echipelor de date limite explicite pentru a îmbunătăți calitatea datelor fără a pierde datele brute cu care au început. Hai să vedem ce este, cum funcționează și de ce este un concept atât de important în data engineering și MLOps.
Cursoul Understanding Modern Data Architecture acoperă unde se încadrează lakehouse-urile și pipeline-urile stratificate în cadrul stivei de date mai largi. Iar traseul nostru de carieră Data Engineer construiește abilitățile de pipeline necesare pentru ca aceste straturi să fie ușor de întreținut odată ce sunt în producție.
Ce este arhitectura Medallion?
Arhitectura medallion este un pattern de proiectare a datelor pentru a organiza logic datele într-un data lakehouse. Ea definește un set de 3 straturi astfel încât calitatea și structura datelor să se îmbunătățească pe măsură ce acestea le traversează:
- Bronze: Date brute, ingestate. Este copia de siguranță, în caz că se schimbă validările sau logica de business.
- Silver: Date curățate și validate. Sursa unică de adevăr, independentă de cazul de utilizare.
- Gold: Date gata de utilizare în business. Pot fi folosite direct, de exemplu ca sursă de date pentru un dashboard sau ca date de antrenare pentru un model de machine learning.

Arhitectura medallion vs. pipeline-uri ETL tradiționale
În data warehouse-uri cu pipeline-uri extract-transform-load (ETL) tradiționale, trebuie să definești schema datelor din start. Dacă formatul sau schema se schimbă, sistemul va eșua dacă nu o ajustezi manual.
Într-o arhitectură extract-load-transform (ELT) bazată pe medallion, salvezi mai întâi datele în formă brută, în loc să le transformi pe loc și să stochezi datele finale. Această diferență face ca arhitecturile bazate pe medallion să fie atât robuste, cât și flexibile: poți stoca date brute ca atare și poți decide mai târziu cum să le folosești.
Pentru o comparație completă a celor două concepte, îți recomand să citești ghidul nostru ETL vs ELT.
Un alt avantaj al arhitecturii medallion este natura ei agnostică față de platformă. Bronze, Silver și Gold sunt etape logice, nu tehnologii legate de un anumit furnizor. Poți implementa pattern-ul cu diferite sisteme de stocare, motoare de procesare și formate de tabele, în funcție de platforma ta de date și de cerințele de sarcină.
|
Funcționalitate |
Medallion (ELT) |
ETL tradițional |
|
Date brute |
Păstrate |
Pierdute |
|
Schema |
Decizi ulterior, impusă în Silver |
Definită din start la țintă |
|
Reprocesare |
Reprocesezi din datele brute păstrate |
Poate necesita re-extragerea datelor sursă |
|
Momentul transformării |
După încărcare |
Înainte de încărcare |
|
Rafinarea datelor |
Progresivă între straturi |
Mai ales înainte ca datele să ajungă la țintă |
Cum funcționează straturile Bronze, Silver și Gold într-o arhitectură Medallion?
Cele trei straturi medallion urmează logic, fiecare construindu-se pe baza celui anterior.
Stratul Bronze: date brute ca punct de recuperare
Aici ajung datele brute așa cum sunt, fie că provin din baze de date relaționale, aplicații SaaS precum Salesforce, topici Kafka care transportă evenimente în timp real, REST API-uri, exporturi CSV sau fluxuri de la dispozitive IoT. Ingestia este de obicei gestionată de unelte precum Fivetran pentru change data capture sau Databricks Auto Loader pentru fișiere care ajung în object storage.
Datele Bronze conțin de obicei destule erori, inconsistențe și duplicate, așa că nu ar trebui folosite niciodată direct în scopuri de business. Totuși, acest strat este foarte valoros ca punct de recuperare din care poți regenera datele Silver sau Gold.
Importanța stratului stă în amprenta sa: înregistrează și loghează fiecare eveniment de ingestie sau tranzacție. Conține adesea metadate valoroase, precum timestampuri de ingestie, originea datelor și diverse tipuri de identificatori. Scopul este să stochezi datele cât mai brute și complete, astfel încât să poți relua pipeline-urile din aval folosind aceleași date sursă pentru a depana orice bug-uri.
Stratul Silver: stratul contractului
Stratul silver transformă datele brute în date curate, structurate. Câteva exemple de transformări de curățare importante care au loc între nivelurile Bronze și Silver:
- Filtrarea coloanelor inutile
- Deducplicarea înregistrărilor
- Remedierea inconsistențelor
- Gestionarea valorilor lipsă
- Standardizarea datelor
- Join și merge pentru diverse seturi de date
Acest strat include și impunerea schemei, asigurând că datele respectă o structură predefinită și suportă evoluția schemei.
Aici gestionezi și verificările de calitate a datelor. De exemplu, adaugi reguli pentru a marca sau respinge tranzacțiile de business eșuate sau outlierii. Acesta este primul pas pentru a îmbunătăți calitatea datelor pe măsură ce trec prin etape.
Deoarece această etapă implică modificarea datelor, e important să folosești unelte de data lineage precum dbt pentru a urmări cum sunt transformate datele din Bronze în Silver. Verificările de calitate sunt, de obicei, implementate cu teste dbt, Great Expectations sau Soda, iar guvernanța este impusă printr-un catalog de date, precum Databricks Unity Catalog sau Collibra.
Dacă vrei să înveți cum să transformi date dezordonate în seturi de date silver corecte, îți recomand să începi cu cursul nostru Cleaning Data in Python.
Stratul Gold: rezultate gata pentru business
Stratul final al arhitecturii stochează datele la cea mai înaltă calitate posibilă. Aceste date foarte rafinate sunt folosite pentru raportare de business în Power BI, Tableau sau Looker, consumate de aplicații analitice din aval sau servite către modele de machine learning printr-un feature store precum Feast sau Databricks Feature Store.
Deoarece datele sunt deja curățate, această etapă se concentrează pe transformarea lor într-un activ valoros pentru business. În funcție de cazul de utilizare specific avut în minte (gândește-te la rapoarte financiare, dashboarduri de marketing, sisteme de alerte, antrenarea modelelor ML, …), transformările după Silver se asigură că Gold conține exact informațiile necesare pentru sarcina în cauză.
Aici creezi KPI-uri, aplici formule de business personalizate sau agregi la nivel săptămânal, lunar sau trimestrial pentru raportări programate. În timp ce operațiunile Bronze și Silver sunt adesea comune, operațiunile din stratul Gold sunt mai flexibile și personalizate în funcție de modul în care vrei să folosești aceste date.
Cum reconstruiești Silver și Gold din datele Bronze?
Păstrarea datelor brute în Bronze merită doar dacă chiar le poți folosi, iar asta se întâmplă ori de câte ori ceva din amonte sau aval se schimbă. Costul unei schimbări depinde de cât de departe pe lanț se află.
- O schimbare a schemei sursei înseamnă reluarea Bronze prin ambele Silver și Gold.
- O schimbare a unei definiții de business (de ex., o nouă regulă de venit sau o fereastră de agregare diferită) înseamnă doar reconstruirea Gold din Silver, care a fost deja validat.

În niciunul dintre cazuri nu te întorci la sistemul sursă. Asta face posibile corecțiile istorice, deoarece sursa poate să nu mai dețină datele în forma în care le-ai ingerat inițial.
De asemenea, înseamnă că poți schimba definiția unei metrici fără a relansa ingestia, motivul practic pentru care echipele cu mulți consumatori Gold păstrează straturile separate.
Unde se potrivește arhitectura Medallion într-un data lakehouse?
Un data lakehouse îți oferă object storage ieftin ca un data lake, cu garanțiile tranzacționale ale unui warehouse. Nu spune nimic despre cum să aranjezi tabelele în interior. Acel gol îl umple medallion: lakehouse-ul este substratul de stocare, iar Bronze, Silver și Gold sunt modul în care îl împarți în cataloage, scheme și tabele cu garanții de calitate diferite.
În practică, acea împărțire este de obicei fizică. Pe Databricks, ai putea avea trei scheme într-un catalog Unity Catalog, iar în Microsoft Fabric, un lakehouse cu tabele Bronze și Silver care alimentează un warehouse Gold. Același pattern, altă infrastructură.
Formatele deschise de tabele sunt cele care fac straturile să reziste la citiri și scrieri concurente. Delta Lake, Apache Iceberg și Apache Hudi oferă fiecare o combinație de:
- Tranzacții ACID
- Evoluția schemei
- Versiuni ale stării tabelului
- Controale de concurență
- Evoluția partiționării
- Time travel
Versionarea contează cel mai mult pentru comportamentul de reluare despre care tocmai am vorbit. Fișierele Parquet brute îți păstrează bine datele sursă, dar nu îți oferă un istoric tranzacțional la care să revii, așa că un rulaj Silver prost îl suprascrie pe cel bun și nu mai ai cu ce compara. Delta Lake urmărește schimbările într-un transaction log, în timp ce Apache Iceberg reprezintă stările tabelelor ca snapshoturi.
Nimic din toate acestea nu este obligatoriu. Medallion este un pattern logic, și multe echipe îl rulează pe scheme Postgres sau pe simple prefixe S3 cu dbt deasupra. Doar că pierzi rollbackul ieftin.
Arhitectura medallion vs data mesh
Cele două sunt comparate des, de obicei pentru că lumea presupune că sunt în competiție. Ele răspund la întrebări diferite: data mesh decide cine deține datele, iar arhitectura medallion decide cum acel deținător le rafinează.
Data mesh transferă responsabilitatea pentru date către echipele de domeniu precum vânzări, financiar sau supply chain, care își publică datele ca produse și dețin calitatea, descoperibilitatea, lineage-ul și guvernanța acestora. Două lucruri țin asta laolaltă: infrastructura self-service care oferă fiecărui domeniu aceleași unelte și guvernanța federată care stabilește standarde la nivel de organizație fără a lua proprietatea de la domenii.
Arhitectura medallion este ceea ce rulează o echipă de domeniu în partea ei. O echipă de supply chain care deține date despre livrări păstrează evenimentele brute de livrare în Bronze, înregistrările validate în Silver și publică seturi de date despre livrări gata pentru analiză în Gold, pentru a fi consumate de alte domenii. Mesh-ul definește contractul la frontiera Gold; tot ce e în amonte de ea ține de echipa respectivă.
O atenționare înainte să le combini: straturi Bronze pe domenii înseamnă că fiecare domeniu își suportă propriul cost de ingestie și stocare, iar dimensiunile partajate precum clientul sau produsul tind să fie reconstruite în trei locuri. Susținătorii mesh ar spune că acesta e prețul proprietății. Totuși este un cost real și merită estimat înainte să te angajezi.
Care sunt beneficiile și limitările arhitecturii Medallion?
Medallion îți oferă reutilizare și recuperabilitate și te taxează cu stocare, latență și număr de pipeline-uri. Dacă balanța iese bine depinde aproape în totalitate de câți consumatori ai.
|
Beneficiu |
Limitare |
|
Datele brute rămân disponibile pentru reprocesare și recuperare |
Aceleași date există în două sau trei forme, deci stocarea crește |
|
Așteptările de calitate sunt explicite la fiecare frontieră |
Mai multe tabele și joburi de programat, monitorizat și depanat |
|
Multe seturi de date Gold reutilizează un singur set de date Silver curățat |
Fiecare salt adaugă latență între sursă și țintă |
|
Transformările sunt trasabile de la intrarea brută la ieșirea de business |
Greu de justificat pe un singur pipeline simplu |
Latența este cea mai ușor de subestimat. Fiecare strat este, de obicei, propriul job programat, astfel încât un pipeline batch cu trei straturi care rulează din oră în oră poate lăsa Gold cu două ore în urma sistemului sursă. Asta e ok pentru un raport săptămânal de venituri și nu e ok pentru o alertă operațională, motiv pentru care echipele permit adesea citirea de alertare direct din Silver, în loc să aștepte Gold.
Stocarea este costul menționat prima dată de obicei, și de regulă e problema mai mică. Bronze stă în object storage ieftin, iar duplicarea este reală dar limitată. Numărul de pipeline-uri e cel care doare de fapt: trei straturi peste douăzeci de tabele sursă înseamnă șaizeci de lucruri care pot eșua la 3 dimineața.
În contrapondere, calitatea slabă a datelor are și ea factura ei. IBM a raportat în 2026 că 43% dintre COO au numit calitatea datelor drept cea mai importantă prioritate, pe baza unei cercetări din 2025 a Institutului său pentru Valoarea în Afaceri. Peste un sfert dintre organizațiile din acel studiu au raportat pierderi anuale din cauza calității slabe a datelor ce depășesc 5 milioane $.
Așadar, întrebarea nu este dacă implementarea unei arhitecturi medallion costă mai mult decât un singur pipeline, pentru că da. Întrebarea este dacă deja plătești alternativa în ședințe de reconciliere și dashboarduri în care nimeni nu are încredere.
Când ar trebui să folosești arhitectura Medallion?
Medallion își merită locul când aceleași date curățate deservesc mai mult de un consumator. Acesta este cel mai bun predictor, înaintea volumului de date, mărimii echipei sau a câtor surse tragi.
Folosește arhitectura medallion când:
- Mai multe echipe sau workloaduri citesc aceleași date. Curăță și standardizează o singură dată în Silver, apoi construiește câte seturi Gold ai nevoie pentru BI, raportare sau antrenarea de modele.
- Întrebări de business diferite au nevoie de forme diferite ale acelorași date. Finance vrea venituri recunoscute lunar, iar vânzările vor rezervări zilnice pe reprezentant. Ambele vin dintr-un singur tabel Silver, fără a duplica logica de ingestie.
- Sursele tale nu se pun de acord între ele. Silver este locul unde reconciliezi un ID de cont Salesforce cu un ID de client al sistemului de facturare înainte ca cineva din aval să trebuiască să ghicească care este autoritativ.
- Trebuie să răspunzi pentru un număr. Separarea datelor brute, validate și curatoriate înseamnă că poți reconstitui o cifră disputată înapoi prin fiecare transformare, în loc să o derivezi de la zero.
- Logica de transformare se schimbă des. După cum am acoperit mai sus, datele Bronze păstrate sunt ceea ce îți permite să reconstruiești fără a te întoarce la sursă.
Evită când:
- Ai o echipă mică de date și o complexitate limitată a pipeline-ului.
- Datele vin dintr-o singură sursă, cu curățare sau transformare minimă.
- Doar o singură aplicație sau echipă din aval consumă datele.
- Cerințele tale de raportare sunt simple și nu justifică menținerea mai multor straturi de procesare.
Când două straturi sunt suficiente
Diagrama cu trei straturi este un implicit, nu o cerință. Cu un singur caz de utilizare de business, Bronze plus un strat combinat este adesea alegerea corectă: păstrezi datele brute pentru reluare, apoi faci curățarea și logica de business într-un singur pas.
Alege forma care se potrivește consumatorilor tăi. Ce nu ar trebui să comasezi este Bronze, pentru că acela e stratul pe care nu îl poți recrea.
Așa că, dacă ești la mijloc și sincer nu poți decide, construirea a două straturi și adăugarea celui de-al treilea când apare un al doilea consumator este o abordare bună. Adăugarea Gold mai târziu este mult mai ieftină decât montarea Bronze după ce ai tot suprascris datele brute în ultimele șase luni.
Greșeli comune în implementările Medallion
Majoritatea problemelor cu medallion nu sunt arhitecturale. Sunt compromisuri mici, făcute sub presiunea termenelor, care în tăcere elimină motivul pentru care ai construit straturile din capul locului.
Transformarea datelor în Bronze
Întregul argument pentru reluare se bazează pe faptul că Bronze păstrează ceva apropiat de ceea ce a trimis sursa în mod real. Aplică logică de business înainte să le depui și ai pierdut starea originală, ceea ce înseamnă fără reprocesare și fără audit trail.
Asta se întâmplă de obicei din motive bune. Cineva elimină o coloană pe care n-o folosește nimeni ca să economisească spațiu sau forțează un câmp de timestamp dezordonat la ingestie pentru că strică jobul următor. După șase luni, coloana „nefolosită” se dovedește importantă și valorile originale au dispărut. Păstrează Bronze cât mai aproape de sursă pe cât poți gestiona practic și pune remedierile în Silver.
Estomparea graniței dintre Silver și Gold
Silver curăță și standardizează. Gold răspunde la întrebări de business. Când logica unei metrice se scurge în Silver, fiecare set de date Gold moștenește o definiție pe care nu a cerut-o, iar tu te întorci la problema pe care medallion trebuia s-o rezolve.
Testul e simplu: dacă un utilizator de business se ceartă pe acel număr, el aparține în Gold. Deducplicarea e o preocupare de Silver. Ce înseamnă client activ nu este.
Tratarea celor trei straturi ca obligatorii
Arhitectura medallion este un pattern de proiectare logic, nu o cerință ca fiecare pipeline să conțină exact trei straturi fizice. Bronze, Silver și Gold reprezintă etape logice de rafinare a datelor, iar fiecare strat poate fi implementat diferit în funcție de workload.
De exemplu, un strat ar putea folosi tabele materializate, view-uri sau alte abstracții adecvate, mai degrabă decât a necesita o copie fizică separată a datelor. Ideea este să creezi granițe semnificative pe măsură ce datele trec de la starea brută la ceva în care businessul poate avea încredere și folosi, nu să reproduci exact diagrama clasică în trei straturi.
Lăsarea stratului Gold ca loc de depozitare
Asta o văd cel mai des și este discutată cel mai puțin. Seturile de date Gold sunt ieftine de creat și nimeni nu le șterge vreodată, așa că după un an s-ar putea să ai patruzeci de tabele, unsprezece dintre ele variații ale veniturilor lunare și nimeni nu mai ține minte pe care îl urmărește de fapt CFO-ul.
Silver are disciplină naturală pentru că sarcina îi este definită. Gold nu, deci are nevoie de un proprietar per set de date și de disponibilitatea de a șterge. Fără asta, ajungi cu mai multe versiuni concurente ale aceleiași metrici, ceea ce este o problemă pe care straturile trebuiau s-o prevină.
Gânduri finale
Ceea ce îți oferă cu adevărat medallion este un loc spre care să arăți când cineva întreabă de unde a apărut un număr și o copie a datelor originale la care să te întorci când se dovedește că răspunsul e greșit. Merită spațiul în plus și joburile în plus când mai multe echipe citesc aceleași date. Când doar o echipă o face, două straturi s-ar putea să fie soluția mai bună și să-ți economisească mentenanță.
Dacă vrei contextul mai larg despre unde se potrivește acest pattern, cursul nostru Understanding Modern Data Architecture acoperă platformele și tehnologiile din spatele stivelor moderne de date. Traseul nostru de carieră Data Engineer merge mai departe în construirea și întreținerea pipeline-urilor de producție.
Întrebări frecvente despre arhitectura Medallion
Poți folosi arhitectura medallion fără un data lakehouse?
Da. Arhitectura Medallion este un pattern logic de proiectare a datelor și nu este legată în mod inerent de o anumită platformă sau tehnologie de lakehouse. Totuși, lakehouse-urile sunt o potrivire comună pentru că suportă stocarea datelor brute și rafinate, oferind totodată capabilități necesare pentru analytics și procesarea datelor.
Pot fi folosite direct datele Silver pentru analytics?
Da. Gold nu este o poartă obligatorie pentru fiecare interogare. Data engineerii, data scientistii și alți utilizatori tehnici pot lucra direct cu datele Silver validate atunci când au nevoie de înregistrări granulare. Gold este de obicei mai util când consumatorii au nevoie de metrici curatoriate, agregări sau seturi de date specifice businessului.
Ce se întâmplă când se schimbă schema sursei?
Ideal, stratul brut capturează datele care sosesc fără a permite unei schimbări neașteptate de schemă să corupă în tăcere seturile din aval. Silver poate apoi valida și reconcilia noua schemă înainte ca datele schimbate să ajungă la ieșirile orientate spre business. Totuși, comportamentul exact depinde de uneltele de ingestie și de formatul tabelului.
Cine ar trebui să dețină fiecare strat medallion?
Proprietatea nu trebuie să se schimbe la fiecare strat. Un domeniu sau o echipă de date poate deține pipeline-ul capăt la capăt sau responsabilitățile pot fi împărțite între echipele de ingestie, platformă, domeniu și analytics. Important este să existe proprietate explicită pentru calitatea datelor și logica de transformare la fiecare etapă.
Am nevoie de stocare separată pentru Bronze, Silver și Gold?
Nu neapărat. Straturile reprezintă granițe logice, nu sisteme de stocare separate. Ele pot trăi în același object store, lakehouse sau platformă, fiind separate prin cataloage, scheme, tabele sau alte structuri organizaționale.