Medallion Mimari Diyagramı: Bronz, Gümüş ve Altın Katmanlar

Her veri platformu sonunda bir bataklığa dönüşür: orders adlı beş tablo, finansın hangisini kullandığından kimse emin değil ve biri yukarı akışta bir hatayı düzelttiği için bozulan bir pano. Medallion mimarisi bu karmaşaya basit bir cevaptır. Bir lakehouse'u bronz, gümüş ve altın olmak üzere üç katmana ayırır; her katmanın, verisinin ne kadar güvenilir olduğuna ve onu kimin kullanabileceğine dair net bir sözleşmesi vardır.

Fikir anlatması kolay olduğu için popülerdir ve yine anlatması kolay olduğu için sık sık yanlış uygulanır. Bu yazı, uyarlayabileceğiniz bir diyagramla birlikte her katmanın neyi tuttuğunu ve neyi tutmaması gerektiğini, verinin katmanlar arasında nasıl ilerlediğini, veri kalitesi kontrollerini, yeniden işlemeyi, yönetişimi, sık yapılan hataları ve desene hiç ihtiyaç duymadığınız durumları ele alıyor.

Üç katmana genel bakış

Ad, Databricks'ten gelir; şirketin belgeleri katmanları ham, doğrulanmış ve zenginleştirilmiş olarak tanımlar. Pratikte:

Katmanları işleme adımlarının sayısı olarak değil, bir kalite sözleşmesi olarak okuyun. Bronz eksiksizlik, gümüş doğruluk, altın ise adı belli bir kitle için kullanışlılık vaat eder.

Bronz: her şeyi saklayın, hiçbir şeyi değiştirmeyin

Bronz, ham verinin indiği yerdir: nesne depolamadan dosyalar, Kafka topic'leri, operasyonel veritabanlarından değişiklik verisi yakalama akışları, SaaS araçlarından dışa aktarımlar. Kurallar:

• Yalnızca ekleme. Normal işleme sırasında bronz kayıtları asla güncellemeyin ya da silmeyin.
• Minimum ayrıştırma. Databricks, yukarı akıştaki beklenmedik bir şema değişikliği veri kaybettirmesin diye bronzda çoğu alanı string, variant ya da binary değer olarak saklamayı önerir.
• Meta veri ekleyin: alım zamanı, kaynak sistem, dosya adı ya da topic offset'i. Hata ayıklama ve yeniden oynatma için bunlara ihtiyacınız olacak.
• Yeniden kurabilecek kadar uzun saklayın. Bronz saklama süresi, bir hata düzeltmesinden sonra gümüş ve altını ne kadar geriye kadar yeniden hesaplayabileceğinizi belirler.

Bronz, sonradan keşke kopyalamasaydım diyeceğiniz kişisel veriler dahil her şeyi içerir. Erişimi boru hatlarıyla sınırlayın ve hassas alanları alım sırasında tokenize etmeyi ya da şifrelemeyi düşünün. GDPR veri haritalama diyagramı kişisel verinin nereye aktığını izlemeye yardımcı olur.

Gümüş: doğru hâle getirin

Mühendislik emeğinin çoğu gümüşe gider:

• Alanları ayrıştırın ve tiplendirin, zaman damgalarını UTC'ye normalize edin, birimleri ve kodları standartlaştırın.
• İki kez gelen kayıtları tekilleştirin; bu, en az bir kez teslim eden her kaynakta olur.
• Değişiklikleri uygulayın. Değişiklik verisi yakalama kaynakları için eklemeleri, güncellemeleri ve silmeleri güncel durum tablosuna merge edin.
• Anahtarları uyumlu hâle getirin, böylece bir müşteri CRM'den de faturalama sisteminden de gelse aynı tanımlayıcıya sahip olur.
• Atmak yerine karantinaya alın. Doğrulamadan geçemeyen satırlar, nedeniyle birlikte birinin görebileceği bir karantina tablosuna gider.

Spark SQL'de Delta Lake ya da Apache Iceberg ile tipik bir gümüş merge'ü, her siparişin yalnızca en son sürümünü tutar:

MERGE INTO silver.orders AS t
USING (
  SELECT * FROM (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC) AS rn
    FROM bronze.orders_raw
    WHERE _ingested_at > '2026-11-01T00:00:00Z'
  ) WHERE rn = 1
) AS s
ON t.order_id = s.order_id
WHEN MATCHED AND s.updated_at > t.updated_at THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

Veri kalitesi kuralları bu sınırda yer alır. Örneğin Databricks boru hatları bunları, uyarı veren, sorunlu satırları atan ya da güncellemeyi başarısız kılan expectation'lar olarak tanımlar:

CREATE OR REFRESH STREAMING TABLE silver_payments (
  CONSTRAINT positive_amount EXPECT (amount > 0) ON VIOLATION DROP ROW,
  CONSTRAINT known_currency EXPECT (currency IN ('USD', 'EUR', 'GBP')) ON VIOLATION DROP ROW
)
AS SELECT * FROM STREAM(bronze_payments);

Hangi aracı kullanırsanız kullanın, kuralları görünür kılın ve reddettikleri satırları sayın.

Altın: kullanışlı hâle getirin

Altın tablolar tüketiciler için kurulur: finans raporlaması için bir yıldız şema, yönetim panosu için bölgeye göre günlük gelir, bir kayıp (churn) modeli için müşteri özellikleri. Her altın tablonun bir sahibi, belgelenmiş bir tanımı ve bir tazelik hedefi olmalıdır. “Aktif müşteri” ya da “net gelir” gibi metrik tanımları buraya aittir; her panoda yeniden uygulanmaz, bir kez yazılır.

Altın, hız için denormalize edip toplama yaptığınız yerdir de. Gümüş ayrıntıyı tutar; altın soruları cevaplar.

Batch, akış ya da ikisi birden

Katmanlar gecikmeyi dayatmaz. Her geçiş gecelik bir batch, saatlik artımlı bir iş ya da checkpoint'li sürekli bir akış olarak çalışabilir. Pek çok ekip kaynaklardan bronz ve gümüşe akış yapar, böylece veri dakikalar içinde günceldir; altın toplamları ise birilerinin onlara ne sıklıkla baktığına uyan bir takvimle yeniler. Mümkün olan her yerde artımlı işleyin: Yalnızca son çalışmadan beri gelen yeni bronz veriyi okumak, veri büyürken maliyetleri sabit tutan şeydir.

Yeniden işleme ve geçmiş

Bronz değişmez olduğu için gümüş mantığındaki bir hata kurtarılabilir: Kodu düzeltin, etkilenen gümüş partition'larını bronzdan yeniden kurun, ardından altını yeniden kurun. Delta Lake ve Iceberg gibi tablo biçimleri snapshot ekler; böylece bir tabloyu dünkü hâliyle sorgulayabilir, bir değişikliği denetleyebilir ya da hatalı bir yüklemeyi geri alabilirsiniz. Bunu baştan planlayın: Dönüşümleri deterministik tutun ve tabloları, bir ayı yeniden kurmak her şeyi yeniden kurmak anlamına gelmeyecek şekilde partition'layın.

Katmana göre yönetişim

Her katmanı kataloğunuzda kendi şemasına koyun; örneğin Databricks'in kendi örneğinde kullandığı düzen olan ops.bronze, ops.silver ve ops.gold. Ardından erişimi katmana göre verin: Boru hatları bronza yazar, mühendisler ve analistler gümüşü okur, şirketin çoğu yalnızca altını okur. Katmanlar arası soy (lineage), bir olay sırasında herkesin sorduğu soruyu cevaplar: Bu bozuk kaynağa hangi panolar bağımlı?

Tuzaklar

• Üçü bir kural saymak. Bazı kaynaklar daha fazla adım, bazıları daha az adım ister. Önemli olan geçiş sayısı değil, sözleşmedir.
• Gümüşte iş mantığı. Gümüş birçok tüketici tarafından yeniden kullanılabilmelidir. Tek bir rapora hizmet eden mantık altına aittir.
• Çöplüğe dönen altın. Sahipler olmadan altın, kimsenin bakımını yapmadığı tek seferlik tablolarla dolar. Onları gözden geçirin ve emekliye ayırın.
• Her şeyi üç kez kopyalamak. Üç biçimde saklanan büyük ham veri setleri gerçek para tutar. Gümüşte yalnızca insanların gerçekten ihtiyaç duyduğu sütunları ve geçmişi tutun.
• Karantinayı atlamak. Sessizce atılan satırlar, rakamların kimse fark etmeden kaymasının yoludur.

Medallion ne zaman gereğinden fazladır

Veriniz bir bulut veri ambarına rahatça sığıyor ve bir avuç kaynaktan geliyorsa, belki bir lakehouse'a hiç ihtiyacınız yoktur. Yaygın dbt kuralı olan staging, intermediate ve marts, tek bir veri ambarı içinde giderek artan arıtma fikrinin aynısını ifade eder:

Adlar disiplinden daha az önemlidir: bozulmadan saklanan ham veri, her varlığın tek bir temiz sürümü ve sahibi olan amaca yönelik tablolar.

Medallion diyagramı

Nasıl okunur:

• Soldaki kaynaklar: Postgres'ten değişiklik verisi, Kafka'dan olaylar ve bir CRM dışa aktarımı.
• Üç renkli çerçeve katmanlardır. Bronz ham dosyaları, gümüş temizlenmiş tabloları ve bir karantina deposunu, altın iş tablolarını tutar.
• Çerçeveler arasındaki kenarlar boru hattı adımlarıdır ve ne yaptıklarıyla etiketlenmiştir: ayrıştırma, tekilleştirme, merge, toplama.
• Sağdaki tüketiciler: BI panoları ve makine öğrenmesi için bir özellik deposu yalnızca altından okur.
• Markdown bloğu her katmanın sözleşmesini listeler.

İnsanların yolunu bulabildiği veri platformları çizmek

• Katmanları renklendirin. Bronz, gümüş ve altın tam da görsel oldukları için akılda kalır; renkleri kullanın.
• Her geçişi yalnızca bir okla değil, işlemiyle etiketleyin. “Tekilleştir ve merge et” ifadesi, inceleyene bir hatayı nerede arayacağını söyler.
• Kimin neyi okuduğunu gösterin. Katmana göre erişim bir tasarım kararıdır ve diyagram panoların asla bronzu okumadığını açıkça göstermelidir.
• Karantina yolunu ekleyin. Reddedilen verinin nereye gittiğini inceleyenlere gösterir.

Lakehouse'un etrafındaki daha geniş boru hattı veri boru hattı mimari diyagramında, akış kaynakları Kafka mimari diyagramında, ML tüketicileri de MLOps mimari diyagramında ele alınıyor.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Kaynaklar olarak Veri paketinden bir Postgres ve bir Kafka düğümü, CRM için de C4 Modeli paketinden bir Harici sistem ekleyin.
3. Bronze, Silver ve Gold adlı, renkleri uyumlu üç Temel Çerçeve düğümü ekleyin.
4. Bronzun içine ham dosyalar için Veri paketinden bir Nesne deposu ekleyin. Gümüşün içine temizlenmiş tablolar için bir Veri ambarı düğümü ve karantina için bir Nesne deposu ekleyin. Altının içine iş tabloları için bir Veri ambarı düğümü daha ekleyin.
5. Tüketiciler olarak BI panoları için bir Temel Kutu ve ML paketinden bir Özellik deposu ekleyin.
6. Kenarları her adımla etiketleyin ve katman kurallarıyla Temel paketinden bir Markdown bloğu ekleyin.

Örnek 13 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Medallion mimarisi nedir? Bir lakehouse'u kalitesi giderek artan üç katmana ayırmanın bir yolu: alındığı hâliyle ham veri için bronz, temizlenmiş ve uyumlu hâle getirilmiş veri için gümüş, belirli kullanımlar için kurulmuş iş kullanımına hazır tablolar için altın.

Gümüş ile altın arasındaki fark nedir? Gümüş, ayrıntı düzeyinde doğru ve yeniden kullanılabilir veriyi tutar; varlık ya da olay türü başına bir tablo. Altın ise toplamlar, yıldız şemalar ya da ML özellikleri gibi bir amaca göre biçimlendirilmiş, sahibi ve tanımları olan tabloları tutar.

Bronz veri hiç değiştirilmeli mi? Normal işlemenin parçası olarak hayır. Bronz yalnızca ekleme yapılan bir katmandır; böylece aşağı akıştaki her şeyi yeniden kurabilirsiniz. İstisnalar yasal silme talepleri ve saklama sınırlarıdır; bunların kendi süreci olmalıdır.

Medallion mimarisi yalnızca Databricks için mi? Hayır. Ad Databricks'ten gelir, ama desen her lakehouse ya da veri ambarıyla çalışır: Delta Lake, Apache Iceberg, Snowflake ya da BigQuery; Spark, dbt ya da başka araçlarla.

Her zaman üç katmana ihtiyacım var mı? Hayır. Kaynaklarınızın ihtiyaç duyduğu kadar adım kullanın. Önemli olanlar dokunulmamış bir ham kopya, her varlığın tek bir temiz sürümü ve sahibi olan amaca yönelik tablolardır.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.