Teknik Derinlik

Data Mesh: Domain Odaklı Veri Mimarisi

Merkezi veri ekibi darboğaza dönüştüğünde Data Mesh, domain sahipliği ve federated yönetişimle çıkış yolu sunuyor. Hangi kurum için anlamlı, hangi tuzaklara dikkat etmeli?

BIART Ekibi3 dk okuma4 görüntüleme
Domain odaklı veri mimarisi şeması

Merkezi veri ekibi modeli son on yılın çoğunda kurumsal analitiği üretti. Ama 2024-2026 arasında pek çok büyük kurumda aynı semptomlar belirdi: veri ekibi her iş biriminin önceliğini eşit ölçüde ele alamıyor, talep listesi 6 aya yayılıyor, üretilen rapor iş bağlamından kopuk kalıyor. Zhamak Dehghani'nin 2019'da formüle ettiği Data Mesh paradigması bu tıkanıklığa cevap veriyor: domain odaklı, ürünleştirilmiş, federated yönetişimle çalışan bir veri mimarisi.

Data Mesh'in Dört Prensibi

Data Mesh tek bir teknoloji değil, dört prensibin toplamıdır:

  1. Domain ownership: Veri, onu üreten iş domain'inin sorumluluğundadır. Müşteri verisi pazarlamanın, sipariş verisi operasyonun.
  2. Data as a product: Domain'in ürettiği veri bir ürün gibi tasarlanır — ürün sahibi, SLA, dokümantasyon, geri bildirim mekanizmasıyla.
  3. Self-serve data platform: Domain ekipleri kendi veri ürünlerini üretebilsin diye merkezi bir platform sağlanır (deploy, gözlemleme, schema yönetimi).
  4. Federated computational governance: Yönetişim merkezi değil federated; standartlar (PII tagleme, lineage, kalite kuralları) platform tarafından otomatik uygulanır.

Hangi Kurum İçin Anlamlı?

Data Mesh her organizasyon için doğru cevap değil. Değerlendirmemizde dört koşul önemlidir:

  • Domain çeşitliliği: 5+ farklı iş domain'i varsa anlamlı; tek domain'de gereksiz.
  • Veri ekibi büyüklüğü: Merkezi ekip darboğaz hâline geldiyse anlamlı; küçük ekip için fazla yönetişim yükü.
  • Engineering kültürü: Domain ekiplerinin kendi pipeline'larını sahiplenmesi için yazılım disiplini olmalı.
  • Yönetim desteği: Sahiplik dağılımı için CDO/COO seviyesinde net karar gerekiyor.

Bankacılık ve telekom gibi büyük, çok-domain'li kurumlar için Data Mesh dönüşümü 2-3 yıllık bir programdır. Küçük ölçekli e-ticaret veya tek-iş kollu kurumlar için merkezi model genellikle daha verimli kalır.

Tipik Yanlış Anlamalar

  • "Data Mesh demek merkezi DWH'i kapatmak demek": Hayır. Data Mesh data lake/warehouse'u inkar etmez; onları her domain'in tükettiği bir platform olarak konumlandırır.
  • "Microservice paradigmasının veriye uyarlamasıdır": Yüzeyde benzese de microservice operasyonel veri için, Data Mesh analitik veri için tasarlanmıştır.
  • "Yönetişim azaldı": Tam tersi; federated yönetişim daha çok kuralı her domain'e dağıtarak uygular. Otomasyon olmadan kaos üretir.

Uygulama Yol Haritası

Data Mesh dönüşümleri için önerdiğimiz aşamalı yaklaşım:

  • Ay 1-3: İki pilot domain seç (en olgun ve en aciden bir tane). Veri ürünü tanımı, ürün sahibi atama.
  • Ay 3-6: Self-serve platformun MVP'si — schema registry, lineage, basic data quality.
  • Ay 6-12: 5-7 domain'e yaygınlaşma; federated governance kuralları platforma gömülür.
  • Ay 12+: Merkezi DWH veri ürünleri tüketici hâline gelir, domain ekipleri sahiplik kazanır.

Sonuç

Paylaş