Medallion-arkkitehtuuri

Kirjoittanut Samu Lahdenperä · Julkaistu 3.8.2026

Medallion-arkkitehtuuri on apuväline datan jalostamiseen tietovarastointiarkkitehtuurissa: se jakaa datan kulun kolmeen kerrokseen — Bronze, Silver ja Gold — joissa data muuttuu joka tasolla vähemmän raa'aksi ja enemmän liiketoiminnan käyttöön valmiiksi. Tällä sivulla käydään läpi mistä malli tulee, mitä se tarkoittaa, miksi se kannattaa ottaa käyttöön, missä sitä käytetään, miten se rakennetaan käytännössä ja milloin se on ylimitoitettu ratkaisu.

Mitä Medallion-arkkitehtuuri on?

Medallion-arkkitehtuurin keksi Databricks osana lakehouse-alustaansa 2020-luvun alussa, ja yhtiö on sittemmin popularisoinut mallin useissa julkaisuissaan. Nimi tulee kolmesta mitalimetallista: Bronze on lähtöpiste, Silver on välivaihe, Gold on lopputulos — sama logiikka kuin urheilukilpailun mitaleissa, joissa arvo kasvaa kerroksittain. Databricks kutsuu mallia myös "multi-hop-arkkitehtuuriksi" (multi-hop architecture), koska data hyppää kerroksesta toiseen aina yhden muunnosaskeleen verran kerrallaan sen sijaan että raakadata muunnettaisiin suoraan raportointivalmiiksi yhdellä massiivisella ETL-ajolla. Malli on levinnyt Databricksin ulkopuolelle nopeasti: Microsoft on ottanut saman kerrosajattelun käyttöön Fabricin OneLake-arkkitehtuurissa, ja se on yleistynyt yleiskielenä puhuttaessa tietovaraston tasoista alustasta riippumatta.

Käytännössä Medallion-arkkitehtuuri on kolme kerrosta samaa dataa, jokainen jalostusasteeltaan edellistä pidemmällä:

Mitä Medallion-arkkitehtuuri EI ole

• Ei tietomallinnusmenetelmä. Medallion ei kerro miten dimensio- tai faktataulut rakennetaan sisäisesti — sen tekee tähtimalli. Medallion kertoo vain missä vaiheessa data on matkallaan sinne.
• Ei ETL/ELT-työkalu tai tuote. Se on kerrosjako, ei ohjelmisto. Bronze, Silver ja Gold voidaan toteuttaa millä tahansa ETL/ELT-työkalulla — Data Factorylla, dbt:llä, Power Queryllä tai käsin kirjoitetulla SQL:llä.
• Ei sama asia kuin Data Vault. Data Vault on mallinnusmenetelmä (hub/link/satelliitti), joka voi elää Silver-kerroksen sisällä. Medallion ei ota kantaa siihen miten dataa mallinnetaan kerroksen sisällä, vain siihen missä järjestyksessä kerrokset ovat.
• Ei pakollinen kolmen kerroksen laki. Osa organisaatioista lisää neljännen kerroksen (esim. "Platinum" liiketoiminta-aggregaateille) tai yhdistää Silverin ja Goldin pienissä ratkaisuissa. Kolme on lähtökohta, ei sääntö johon on pakko pitäytyä.

Miksi Medallion-arkkitehtuuri kannattaa ottaa käyttöön?

Yksi massiivinen ETL-ajo lähdejärjestelmästä raportointivalmiiseen tauluun on nopea rakentaa mutta hidas ylläpitää: kun ajo epäonnistuu puolivälissä tai raportin luku on väärä, ei ole tapaa selvittää missä vaiheessa virhe syntyi ilman koko putken purkamista. Medallion-arkkitehtuuri korjaa tämän jakamalla muunnoksen näkyviin, tarkistettaviin vaiheisiin.

• Auditointi ja jäljitettävyys. Bronze säilyttää raakadatan sellaisenaan, joten mistä tahansa virheestä voidaan aina palata alkuperäiseen lähteeseen ja todeta, syntyikö virhe lähdejärjestelmässä vai omassa muunnoksessa.
• Uudelleenkäsittely ilman lähdejärjestelmää. Jos Silver- tai Gold-tason logiikka muuttuu, koko historia voidaan ajaa uudelleen Bronzesta ilman että lähdejärjestelmää tarvitsee kysyä uudestaan — se on voinut jo muuttua tai kadota.
• Uudelleenkäyttö tiimien välillä. Sama Silver-kerros palvelee montaa Gold-tuotetta: talousraportointi, myyntianalytiikka ja koneoppimismalli voivat kaikki lukea samaa puhdistettua dataa ilman että jokainen tiimi puhdistaa sen itse uudelleen.
• Laadunvarmistus rajapinnassa. Jokaisella tasosiirtymällä on oma tarkistuspisteensä. Silveriin siirtyvä rivi joko läpäisee validoinnin tai jää karanteeniin — se ei pääse likaisena Goldiin asti pilaamaan raporttia.

Miksi Medallionia EI aina kannata rakentaa

• Kolme kertaa infrastruktuuria. Jokainen kerros tarvitsee oman tallennuspaikan, oman ajastuksen ja oman monitoroinnin. Yhden raportin projektissa tämä on kolme kertaa enemmän ylläpidettävää kuin suora lataus.
• Hitaampi ensimmäinen toimitus. Kun data pitää viedä kolmen kerroksen läpi ennen kuin ensimmäinen raportti on käytössä, aikaa kuluu enemmän kuin suorassa Bronze-Gold-latauksessa. Jos deadline on lähellä, kerrosten rakentaminen alusta asti on riski.
• Kurittomuus on pahempi kuin kerrosten puuttuminen. Jos tiimi ei pidä kiinni siitä mitä kullakin kerroksella saa tehdä, syntyy kolme paikkaa joissa sama bugi voi piillä sen sijaan että niitä olisi yksi.

Missä Medallion-arkkitehtuuria käytetään?

Termi syntyi lakehouse-alustoilla (Databricks, ja sittemmin Microsoft Fabric OneLake, Synapse, Snowflake), joissa Bronze/Silver/Gold ovat usein kirjaimellisesti kolme eri kansiota tai skeemaa samassa data-alustassa. Malli ei kuitenkaan vaadi lakehousea toimiakseen — sama kerrosajattelu pätee jokaiseen perinteiseen tietovarastoon ja Power BI -kehitykseen:

• Bronze = staging-alue. Perinteisessä tietovarastossa tämä on staging-tietokanta tai -skeema, johon data ladataan lähdejärjestelmästä ilman muunnoksia.
• Silver = integraatiokerros, ja se on materialisoitu. Tässä eri lähdejärjestelmien data yhdistetään ja puhdistetaan ennen kuin siitä rakennetaan raportointimalli.
• Gold = tähtimalli Power BI:tä varten. Dimensiotaulut ja faktataulut sellaisina kuin ne ladataan Power BI:hin.

Toisin sanoen: jos organisaatiossa on erillinen staging-tietokanta, integraatiokerros ja raportointimalli, siellä on jo käytännössä Medallion-arkkitehtuuri — vaikka kerroksia ei olisi koskaan nimetty Bronzeksi, Silveriksi tai Goldiksi.

Missä Medallion EI toimi

• Yhden Excel-tiedoston Power BI -pilotissa. Kun koko datalähde on yksi taulukko jota päivitetään kerran kuussa käsin, kolme kerrosta on kolme ylimääräistä klikkausta ilman hyötyä.
• Ilman orkestrointia. Jos kerrosten välistä ajojärjestystä ei voi automatisoida (ajastin, riippuvuudet), kerrokset ajautuvat helposti epäsynkkaan — Gold lukee vanhaa Silveriä eikä kukaan huomaa.
• Governance-työkalun korvikkeena. Medallion ei tee datakatalogia, ei aseta pääsyoikeuksia eikä dokumentoi liiketoimintasääntöjä puolestasi — se on rakenteellinen apuväline, ei hallintamalli.

Miten Medallion-arkkitehtuuri rakennetaan käytännössä?

Rakentaminen etenee kerros kerrokselta, ja jokaisella kerroksella on oma vastuunsa — sekoittamalla vastuita kerrosten välillä koko hyöty katoaa.

1. Bronze: lataa muuttamatta. Lähdejärjestelmän taulut ladataan sellaisenaan, lisäten vain tekniset metasarakkeet (latausaika, eräajon tunniste, lähdejärjestelmän nimi). Ei suodatuksia, ei liiketoimintasääntöjä — jos lähde lähettää virheellisen rivin, se päätyy Bronzeen sellaisenaan.
2. Silver: puhdista, yhdistä, avaa. Duplikaatit poistetaan, puuttuvat viittaukset korjataan tai merkitään, tietotyypit yhdenmukaistetaan ja useasta lähteestä tuleva sama entiteetti (esim. asiakas kahdesta eri järjestelmästä) yhdistetään yhdeksi riviksi. Tässä vaiheessa luodaan myös surrogaattiavaimet — ei aiemmin, koska Bronzen duplikaatit loisivat turhia avaimia, eikä myöhemmin, koska jokainen Gold-taulu tarvitsee saman yhteisen avaimen. Avaimet materialisoidaan Silver-tasolla eli kirjoitetaan fyysisiin tauluihin, ja se tehdään ennen faktataulun latausta: faktan lataus liittyy valmiiseen avaimeen sen sijaan että ratkaisisi sen itse.
3. Gold: mallinna liiketoiminnan käyttöön. Silver-data litistetään ja mallinnetaan tähtimalliksi: faktataulut ja dimensiot, nimetty liiketoiminnan termein, valmiina ladattavaksi Power BI -tietomalliin.

Sama asiakasentiteetti kolmella kerroksella näyttää SQL:nä tältä — huomaa miten rajoitteet ja liiketoiminnan nimeäminen ilmestyvät vasta sitä mukaa kun kerros nousee:

-- Bronze: lähdetaulu sellaisenaan + tekniset metasarakkeet
CREATE TABLE bronze.Asiakas_raw (
    AsiakasTunnus    VARCHAR(50)  NULL,   -- ei rajoitteita: virheellinenkin rivi säilyy
    AsiakasNimi      VARCHAR(200) NULL,
    Segmentti        VARCHAR(50)  NULL,
    LatausAika       DATETIME2    NOT NULL DEFAULT SYSDATETIME(),
    EraTunniste      VARCHAR(50)  NOT NULL,
    Lahdejarjestelma VARCHAR(50)  NOT NULL
);

-- Silver: puhdistettu ja yhdistetty — surrogaattiavain luodaan tässä
CREATE TABLE silver.DimAsiakas (
    AsiakasAvain  INT          NOT NULL,   -- SK, mapping-taulusta
    AsiakasTunnus VARCHAR(50)  NOT NULL,   -- NK säilyy attribuuttina
    AsiakasNimi   VARCHAR(200) NOT NULL,
    Segmentti     VARCHAR(50)  NOT NULL,
    CONSTRAINT PK_DimAsiakas PRIMARY KEY (AsiakasAvain)
);

-- Gold: raportointimalli — relaatioissa vain surrogaattiavaimet
CREATE VIEW gold.D_Asiakas AS
SELECT AsiakasAvain,
       AsiakasNimi AS [Asiakas],
       Segmentti   AS [Asiakassegmentti]
FROM   silver.DimAsiakas;

Kerrosten välinen siirtymä hoidetaan yleensä ajastetulla, inkrementaalisella latauksella: jokainen erä käsittelee vain uudet tai muuttuneet rivit lähtien Bronzesta ja edeten Silveriin ja Goldiin samassa järjestyksessä joka kerta. ETL/ELT-työkalu orkestroi ajojärjestyksen, mutta itse kerrosjako on arkkitehtuurin ydin riippumatta siitä, ajetaanko muunnokset SQL:llä, Sparkilla vai Power Queryllä.

Miten Medallionia EI kannata rakentaa

• Älä lisää liiketoimintalogiikkaa Bronzeen. Jos Bronze suodattaa tai muokkaa dataa, koko kerroksen tarkoitus — raakadatan säilyttäminen sellaisenaan — katoaa. Suodata ja muokkaa vasta Silverissä.
• Älä ohita Silveriä "nopeuden vuoksi". Bronze suoraan Goldiin toimii demossa mutta ei tuotannossa: Silverin puuttuessa jokainen Gold-taulu joutuu tekemään saman puhdistuksen erikseen, ja tulokset alkavat erota toisistaan.
• Älä sekoita kerroksia samaan skeemaan tai tauluun. Jos Bronze- ja Silver-taulut ovat samassa tietokannassa ilman selkeää nimeämiskäytäntöä (esim. etuliite tai erillinen skeema), kukaan ei tiedä kesken kehitystä kumman version taulua ollaan lukemassa.
• Älä luo surrogaattiavaimia Bronzeen tai Goldiin. Oikea paikka on Silver — ks. surrogaattiavaimien mallintaminen tarkemmin perusteluineen.

Milloin Medallion-arkkitehtuuria kannattaa käyttää — ja milloin ei?

Päätös ei ole makuasia vaan kynnyskysymys. Medallion maksaa kolminkertaisen infrastruktuurin ja hitaamman ensimmäisen toimituksen, ja tuottaa vastineeksi jäljitettävyyttä ja uudelleenkäyttöä. Jos kumpaakaan ei tarvita, kolme kerrosta on kolme ylimääräistä paikkaa joissa data voi mennä rikki. Käy kuusi signaalia läpi. Jos yksikin rivi osuu sarakkeeseen Medallion kannattaa, rakenna kerrokset. Jos kaikki kuusi osuvat sarakkeeseen ylimitoitettu, rakenna suoraan Gold-malli.