Medallion Architecture on kihiline andmearhitektuur, kus andmed liiguvad toorandmetest järk-järgult puhastatud ja ärikasutuseks valmis kujule läbi pronks-, hõbe- ja kullakihtide.
Medallion-arhitektuur tugineb praktilistele andmeinseneeria põhimõtetele, mis lähtuvad andmemeeskondade tegelikest vajadustest.
See lähenemine tugineb klassikalisele andmelao arhitektuuri mõtlemisele (Inmon, Kimball, Data Vault). Medallion-arhitektuur toob need põhimõtted kaasaegsesse lakehouse’i keskkonda, keskendudes selgelt probleemide eraldamisele.
Meeskonnad vajavad samaaegselt ajaloolisi andmeid auditeerimiseks ja uuesti laadimiseks, integreeritud andmavaateid analüütikaks ning jõudlusele optimeeritud struktuure aruandluseks.
Kihiline lähenemine võimaldab igat vajadust eraldi hallata, ilma et üks kompromiss mõjutaks kogu süsteemi.
Maandumistsoon. Andmed laetakse muutumatul kujul ja salvestatakse originaalformaatides (CSV, JSON, Parquet) enne Delta formaati teisendamist. Rikastamisel lisatakse metaandmed — allalaadimise ajatemplid ja andmeallika sildid. Toetab nii batch- kui ka voopõhist andmetöötlust ning on kasulik vigade tuvastamisel ja ajalooliste andmete uuesti laadimisel.
Siin rakendatakse andmekvaliteedi reegleid: parandatakse kuupäevi, eemaldatakse erimärgid ning korrigeeritakse vormindusvigu. Ajaloolise muutuste säilitamiseks kasutatakse tavaliselt SCD2 (Slowly Changing Dimension Type 2) lähenemist. Struktuur jääb küll allikasüsteemile lähedaseks, kuid on juba päringuteks kasutatav ning mõeldud operatiivse analüütika jaoks. Veerud nimetatakse ümber loetavuse parandamiseks ning rakendatakse kergeid ühtlustusi vastavalt ettevõtte standarditele.
Andmed harmoniseeritakse ja integreeritakse eri allikatest, kasutades tavaliselt Kimballi dimensioonmudelit (faktid ja dimensioonid). Siin rakendatakse keerukamaid ärireegleid, arvutusi ja andmete rikastamist. Tulemuseks on kasutusvalmis andmetooted, mis on loodud tarbijate jaoks, tagades tagasiühilduvuse ning selged andmelepingud (data contracts) allkasutajatega.
Äriküsimus: Kasvav e-kaubanduse ettevõte soovib mõista, kuidas turunduskulutused eri kanalite lõikes tulemusi mõjutavad. Eesmärk: ühendatud ROI analüüs mitmekanaliliste reklaamikampaaniate jaoks.
Andmeallikad: Facebook Ads ja Google Ads.
Aruandlusnõuded: kulud, näitamised ja klikid — jaotatuna reklaamide, kampaaniate, omistamise (1-päevane aken) ning demograafiliste tunnuste (vanus, sugu, seade ja platvorm) lõikes.
Facebook Insights pakub 134 välja ning lisaks täiendavaid parameetrikombinatsioone. Google Ads pakub 329 välja. Soovitus on lihtne: laadi kõik, mida APId tagastavad.
Transformatsioonid selles etapis on minimaalsed: eemaldatakse vigased või kasutuskõlbmatud kirjed, teisendatakse Delta formaati, rikastutakse metaandmetega (andmeallikas, allalaadimise aeg) ja partitsioonitakse kuupäeva järgi — aga ainult siis, kui andmemaht tekitab kitsaskohti.
Siin tehakse tegelikud disainiotsused. Facebook ja Google kasutavad samade mõistete jaoks erinevaid väljanimetusi — cost_micros vs spend, ad_group vs adset, segments.age_range vs age — ning mõningaid välju lihtsalt ei eksisteeri mõlemal platvormil.
Hoidke eraldi Facebook Silver tabelit ja Google Silver tabelit — mõlemad puhastatud ja ühise nimetuskonventsiooni järgi ümber nimetatud. Puuduvad väljad täidetakse null-väärtustega. Lihtne ehitada, allika nüansid säilivad, kuid nõuab hiljem ühendamist või liitmist.
Kaardistage mõlemad allikad Silver tasemel ühte jagatud tabelisse. Lihtsam allavoolu tarbijatele ja väldib korduvat union-loogikat. Soovitatav siis, kui platvormi spetsiifilised nüansid ei ole aruandluses olulised. Oluline: dokumenteerige kaardistamisotsused selgelt — adset ja ad_group ei ole identsed mõisted.
Andmemudel põhineb Data Vaulti lähenemisel, kus ärientiteedid on esitatud Hubidena (Hub_Ad, Hub_Campaign, Hub_Ad_Group), nendevahelised seosed Linkidena (Link_Ad_To_Campaign) ning mõõdikud ja detailandmed Satellite’idena (Sat_Ad). See struktuur on modulaarne ning võimaldab hästi jälgida suhete ja andmete muutumist ajas. See lähenemine sobib eriti hästi keerukate ja pika elueaga ettevõtte andmeplatvormide jaoks.
Ehitage Fact_Ad_Performance tabel, mis on seotud Dim_Campaign, Dim_Ad_Group, Dim_Ad ja Dim_Date tabelitega. Selge, BI-tööriistade poolt hästi mõistetav ja lihtne filtreerida. Kõige levinum lähenemine.
Pane kõik andmed ühte laia tabelisse. See muudab analüütikute töö ja iseteenindusliku aruandluse lihtsamaks, sest liitmisi (JOIN’e) pole vaja. Selline lähenemine sobib hästi siis, kui kasutusjuht on stabiilne ning ei ole vaja teha keerukat analüüsi mitme faktitabeli vahel.
Sidumisloogika — Facebook ja Google Hõbe tabelite liitmine üheks Kuld faktiks — võib olla eraldi samm (mis on soovitatav) või käsitletav otse ühenduste ja liitmistega Kuld notebookis.
Andmehaldus — Kõige Pronksi salvestamine võib muutuda GDPR probleemiks. Juurdepääsuõigused vajavad selget reeglistikku, eriti kui Hõbe tabelid sisaldavad isikuandmeid (PII) mitmest lähteandmesüsteemist.
Inimfaktor — Medallion on pigem nimetamis- ja struktuuriraamistik, mitte jäik reeglistik. Kui puuduvad selgelt kokkulepitud ja dokumenteeritud meeskonnareeglid selle kohta, mis millisesse kihti kuulub, hakkab arhitektuur ajas lagunema: tekivad ebajärjekindlused ja varjatud andmetorustikud (shadow pipelines).
Medallion-arhitektuur näeb diagrammil lihtne välja, kuid tegelikud disainiotsused — eriti Hõbe-kihis — võivad avaldada pikaajalist mõju. Kui soovite oma olukorrale sobiva lähenemise koos läbi mõelda, võtke julgelt ühendust ja broneerige kohtumine.
Kohtume kohvi joomas või võta meiega ühendust.
Võta ühendust →