Data Mesh Nedir?
Veri Bataklığından Veri Ekosistemine
Şirketler yıllardır “veri odaklı bir organizasyon” (data-driven organization) olma hayaliyle devasa yatırımlar yapıyor: Data Warehouse (Veri Ambarı), Data Lake (Veri Gölü) ve modern bulut platformları…
Peki, sonuç ne? Genellikle şunlarla karşılaşıyoruz:
- Yavaş veri erişimi: Veriye ulaşmak haftalar alıyor.
- Merkezi ekip darboğazı: Tek bir veri ekibi tüm şirketin taleplerine yetişmeye çalışırken boğuluyor.
- Ölçeklenemeyen yapılar: Teknoloji büyüyor ama iş değeri aynı hızda artmıyor.
Veri mimarisi buraya nasıl evrildi ve Data Mesh bu kördüğümü nasıl çözüyor? Veri ekibiniz taleplere yetişemiyor mu? Data Lake’iniz bir veri çöplüğüne mi dönüştü?
O zaman önce geçmişe bakalım.
Günümüze gelene kadar veri mimarisi nasıl evrildi:
- 90’lar: Veri Ambarları (Data Warehouse Dönemi)
1990’larda veri dünyası daha düzenliydi. Finans tabloları, ERP kayıtları, CRM verileri… Her şey tabloydu, yapısal ve düzenliydi..
Merkezde bir Data Warehouse vardı. ETL süreçleri ile veriler buraya taşınırdı. Bu sayede tek doğruluk kaynağı (Single Source of Truth), güçlü BI raporlama, yönetilebilir şema.
Ama tabi IT darboğazı, yeni veri tiplerine kapalı yapı, değişime yavaş adaptasyonu gibi dezavantaljları da vardı.
2. Big Data ve Data Lake: “Her Şeyi Saklayalım” Dönemi
Büyük veri (Big Data) çağıyla birlikte loglar, IoT verileri ve sosyal medya akışları hayatımıza girdi. Hadoop ve Spark gibi sistemlerle yeni bir slogan doğdu:
“Her şeyi sakla, sonra bakarız.”
Bu yaklaşımın sonucu olarak Data Lake mimarisi hızla yaygınlaştı ve birçok kurum için varsayılan veri depolama modeli haline geldi. Bu model sayesinde
- Şemasız veri saklama mümkün oldu
- Ucuz ve ölçeklenebilir depolama sağlandı
- Machine Learning çalışmaları için esnek bir altyapı oluştu
Ancak zamanla bu göller, sahipliği belirsiz, kalitesi standartları tanımsız dokümantasyonu eksik veri kümeleri birikmeye başladı. Ve birçok organizasyonda Data Lake’ler şu soruların cevapsız kaldığı bir Data Swamp (Veri Bataklığı) haline dönüştü Zamanla sektörde büyük bir belirsizlik oluştu; Kim veri üretti, kalitesi ne, şeması ne, sahibi kim?
Teknik olarak güçlü sistemler, organizasyonel belirsizlik nedeniyle iş değeri üretmekte zorlanmaya başladı.
3. 2019: Merkeziyetçilik Krizi
2019’da Zhamak Dehghani bir makale yayımladı: “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh” .
Makale bir devrim niteliğindeydi, ana iddiası şuydu: Problem teknoloji değil, mimari paradigma. Yani sorun artık teknik değil, organizasyoneldi. Merkezi veri ekipleri, verinin geldiği iş birimini (Domain) tanımıyordu, tüm veri taleplerine yetişemiyor, iş ekipleri bağımlı kalıyordu. Çözüm mü? Veriyi en iyi bilen kişi yönetsin.
Data Mesh Nedir?
Bir organizasyon + süreç + platform birlikte tasarımıdır.
Yani sadece tool kurarak olmaz, sadece ekip reorganizasyonu yaparak da olmaz.
Üçünün birlikte değişmesi gerekir:
Data Mesh = %30 teknoloji + %40 organizasyon + %30 süreç
Data Mesh’in 4 Temel Direği
1.Domain Ownership (Etki Alanı Sahipliği):
Herkes kendi mutfağından sorumlu. Merkezi veri ekibi yerine: Domain bazlı veri sahipliği, veri ürünleri, sorumluluk devri;
Muhasebe verisini muhasebe domain’i yönetsin.
Finans verisini finans domain’i yönetsin.
Log verisini platform ekibi yönetsin.
Bu modelde prosedürler önce yazılımdan değil, insan sorumluluğundan başlar.
2. Data as a Product (Ürün Olarak Veri):
Veri bir “yan çıktı” değil, müşterisi olan bir “üründür”. Bir veri ürününün açık şeması, dokümantasyonu ve SLA’i (hizmet kalitesi sözü), versiyonlama, erişim politikası olmalıdır.
Yani “CSV attım klasöre” yaklaşımı sürdürülebilir değildir.
Nasıl Uygulanır? Domain ekibi (örneğin Finans), veriyi sadece bir tablo olarak değil, bir API veya bir S3 klasörü (üzerinde standart bir şema ile) olarak sunar.
- Teknik Araçlar: Docker konteynerları içinde çalışan küçük veri işleme kodları (Python/Spark) veya dbt (data build tool) modelleri.
- Data Contract (Veri Sözleşmesi): Yazılımsal olarak bir
YAMLveyaJSONdosyası hazırlarsın. Bu dosyada şunlar yazar: "Bu verinin adı 'fatura_tablosu', içinde 'tutar' alanı var ve bu alan asla boş olamaz."
3. Self-Serve Data Platform:
Merkezi ekip artık veri üretmez; domain ekiplerinin kendi verilerini kolayca yönetebileceği araçları ve altyapıyı sağlar, tooling sunar, governance çerçevesini kurar vs
Get Bilana Altay’s stories in your inbox
Join Medium for free to get updates from this writer.
Yani domain ekipleri üretir, sahiplenir, yayınlar.
Bir platform arayüzü (Internal Developer Portal) düşünün. Kullanıcı “Bana bir veri alanı aç” butonuna basar.
- Arka Planda Ne Çalışır? Infrastructure as Code (Terraform veya Pulumi) devreye girer. Otomatik olarak o ekibe özel bir AWS S3 bucket, bir SQL şeması ve bir erişim yetkisi (IAM Role) tanımlar.
- Sonuç: Yazılımcı, veritabanı kurulumuyla uğraşmaz, sadece verisini oraya yazar.
4. Federated Computational Governance:
Başıboşluk değil, ortak standartlar. Güvenlik ve uyum politikaları merkezden belirlenir ama uygulama domain’lerde gerçekleşir.
Merkezi ekip ne yapar? Ortak kuralları belirler:
- Veri kalite kuralları
- Güvenlik politikaları
- Metadata zorunlulukları
- Data contract standartları
Domain ekipleri ne yapar?
- Metadata zorunlulukları
- Data contract standartları
- Veriyi üretir
- Yayınlar
- SLA sağlar
- Kaliteyi korur
Nasıl Uygulanır? Yazılımsal “Policy as Code” uygulanır.
- Örnek Senaryo: Bir domain ekibi yeni bir veri yayınlamak istediğinde, sistem otomatik olarak (CI/CD pipeline içinde) şu testi yapar:
- PII (Kişisel veri) içeriyor mu? Evet.
- Maskelenmiş mi? Hayır.
- Hata! Veri yayına alınamaz.
Böylece federatif veri kontrolü sağlanır.
Data Mesh Ne Zaman Kullanılmamalı?
Data Mesh son yılların en popüler veri mimarisi yaklaşımlarından biri olsa da, her organizasyon için doğru çözüm olmayabilir.
Aslında birçok şirketin yaptığı en büyük hata şudur:
Organizasyonel problemi mimari trendlerle çözmeye çalışmak.
Data Mesh güçlüdür — ama yalnızca doğru koşullarda.
Özellikle küçük ekiplerde tam Data Mesh kurmak gereksiz karmaşıklık yaratabilir.
Küçük ekipler için daha gerçekçi yaklaşım:
Mini Mesh (Pragmatic Mesh)
- Domain owner belirle
- Data contract zorunlu yap
- Ortak data catalog tut
- Log & business data ayır
- Tek pipeline yerine domain pipeline
Yani:
Architecture değil → mindset uygulanır.
Sonuç: Paradigma Değişimi
Data Mesh bir teknoloji dönüşümü değil, organizasyonel bir dönüşümdür. Yazılım platformları yalnızca bu modeli mümkün kılar; asıl değişim veri sahipliğinin merkezi ekiplerden domain ekiplerine devredilmesidir. Başarılı bir Data Mesh uygulaması, insan sorumluluğu, süreç tasarımı ve self-serve platformun birlikte evrilmesini gerektirir.
Data Mesh, veriyi teknik bir sorundan çıkarıp organizasyonel bir stratejiye dönüştürüyor. Eğer siz de veri bataklığında debelenmekten yorulduysanız, belki de çözüm daha büyük platformlar kurmak değil, veri sahipliğini yeniden düşünmektir.
Peki sizin organizasyonunuzda en büyük darboğaz hangisi? Merkezi ekip mi, yoksa veri kalitesi mi?
