Veri Ambarı Taşırken Platform Seçimi: Acı Nokta, PoC ve TCO

Kurumsal analitik yıllarca on-prem kurumsal veri ambarında büyüdü: Kimball tarzı model, ETL paketleri, belki küpler. Batch penceresi daraldıkça ağır işler Hadoop veya Spark tarafına kaydı. Sonuç tipik bir hibrit: iki yer, iki sayı, iki operasyon ekibi. Buluta geçiş bu tabloyu olduğu gibi taşımak değil; tek doğruluk kaynağı, öngörülebilir maliyet ve sürdürülebilir operasyon kurmaktır.

Bu yazıda üç yol var: klasik bulut veri ambarı (BigQuery, Snowflake), data lake / lakehouse (Databricks, Delta, Iceberg) ve hibrit katmanlar. Hangisinin yükünüze oturduğu, bir kavram kanıtı (PoC) ve toplam sahip olma maliyeti (TCO) hesabı olmadan netleşmez.

Hedef her zaman bulut olmak zorunda değil. Yeni nesil on-prem bir platform (örneğin bir appliance) da adaydır. Bulut ve on-prem seçeneklerini aynı senaryolarda, aynı skor kartında yarıştırmak gerekir. “Buluta gidiyoruz” kararını PoC’den önce vermek, seçenekleri baştan daraltır.

Karar yolu (özet): on-prem → acı noktaları listele → PoC: 2–3 aday, aynı senaryo → 3 yıllık TCO → referans mimari. En hızlı yol ile en düşük bütçe çoğu zaman aynı cevap değildir; ikisini aynı skor kartında görün.

Önce acı nokta, sonra ürün

Vendor sunumları genelde ürünle başlar. Sahada iş acı noktayla başlar.

Aşağıdaki dokuz madde örnektir. Kendi ortamınızda bir kısmı çıkar, bir kısmı eklenir; önemli olan listeyi yazmak ve her satırı bir karşılığa bağlamaktır. Karşılıkların birkaçında geçen ADR (architecture decision record), neyin neden kararlaştırıldığını yazan kısa ve tarihli bir mimari karar notudur.

Alan	Acı nokta	Ne söylüyor	Karşılığı
Mimari	Veri büyüdükçe süreler uzuyor	Ölçeklenme sınırına yaklaşıldı	Ölçeklenebilir mimari; PoC’de büyüyen hacimle ölçüm
Mimari	Katmanlar birbirine karışmış	Bir değişiklik her yere dokunur	Katmanlı model; sahipler ve isimler ADR’de
Mimari	Aynı rakam farklı yerde farklı	İki yer, iki sayı	Tek doğruluk kaynağı; ortak Core modeli
Operasyon	Geceye sığmayan batch	Büyük küme nefes aldırır, kök neden aynı kalır	Artımlı (incremental) yükleme, işi parçalara ayırma
Operasyon	Donanım veya yazılım destek sonuna yaklaştı	Yenileme zorunlu ve pahalı	Yenileme yerine platform kararı; PoC ve TCO
Operasyon	Eski sistem hâlâ açık	Dual-run takvimi yer	Kapanış listesi, ADR olarak
Yönetişim	Hata rapordan sonra fark ediliyor	Güven kırılmış	Pipeline’da assertion / test kapısı
Yönetişim	Değişiklikler izlenemiyor	Kodun ve verinin geçmişi yok	Kod deposu; versiyonlu veri
Yönetişim	Sözlük, katalog ve kalite aracı yok	Kimin neyi nerede tuttuğu belirsiz	Katalog, lineage, kalite kapısı

Acı nokta tek bir cümle değil, bir listedir. Önemli olan listenin her satırının bir karşılığı olmasıdır: hangi katman, hangi karar, PoC’de hangi ölçüm bu maddeyi kapatıyor. Karşılığı olmayan madde, taşıdıktan sonra da yerinde durur.

Takvimi yiyen çoğu zaman kırmızı job değil, eski sistemin “emin olalım” diye açık kalmasıdır. Kapanış listesi kısadır: tek tarih alanı, tek grain, sapma eşiği, imza. İmza yokken BigQuery’ye taşımak ikinci kopya üretir; lake’e dökmek kontrolsüz büyüme getirir.

Üç hedef mimari

Bulut veri ambarı (SQL-first): modellenmiş tablolar, gece batch. BigQuery + Dataform, Snowflake + dbt.

Lakehouse: ham ve işlenmiş veri dosyada; Spark, ML. Delta / Iceberg, Databricks, Dataproc.

Hibrit (medallion): bronze lake’te, gold ambarda. Çoğu büyük kurumsal geçişin gerçekçi hedefi.

On-prem’den çıkışta soru “ambar mı, lake mi?” değil. Asıl sorular şunlar: dönüşümün çoğu SQL mi Spark mı, gecikme gece mi dakika mı, beceri hangi ekipte?

Tipik akış: on-prem kurumsal veri ambarı (CDC, yani değişiklik yakalama, ya da batch) → Landing → Lake (bronze/silver) → Gold ambar (BigQuery, mart) → BI. Spark/ML yükü lake’te kalabilir; raporlama gold’da.

Katmanlı ambar ve medallion

“BigQuery’ye taşıyoruz” çoğu zaman aslında katmanlı model taşımaktır. Medallion ayrı bir sözlüktür. İkisi karıştırılırsa PoC uzar, kopyalar çoğalır.

Katmanlı ambar: Landing → Staging → Core → Data mart

• Landing zone: ham alım; yeniden oynatma (replay), denetim.
• Staging: temizlik, birleştirme, hafif dönüşüm.
• Core: modellenmiş kurumsal veri, ortak boyutlar, tek doğruluk kaynağı; tüketime kapalı.
• Data mart: iş birimine özel tüketim grain’i; BI buradan beslenir.

Core neden mart’tan ayrı? Mart’ta bir iş birimine özel, stok, satış ve fiyatın yan yana durduğu geniş bir tablo olur. Core’da aynı grain’de stok ayrı, fiyat ayrı, satış ayrı tutulur ve Core dışarıya açılmaz. Benim önerdiğim yaklaşım bu; bazı mimarilerde silver katmanı da doğrudan tüketilir. Hangisini seçerseniz seçin, ADR’de yazılı olsun. Kazancı şurada: sadece fiyatlar değiştiğinde tüm yapı yeniden dönüşüme girmez; yalnızca ilgili veri setleri ve onlara bağlı martlar işlenir. Kazanç hız ve maliyettir.

Avantajlar: mevcut ambardaki Kimball dili korunur; gece batch’e uygundur; partition ve saklama süresiyle katman bazında FinOps (bulut maliyet yönetimi) yapılır; Dataform/dbt ile versiyon ve assertion gelir.

Medallion: Bronze → Silver → Gold

• Bronze: append-only ham veri (lake / object storage).
• Silver: tekilleştirme (dedupe), uyumlama (conform), kalite.
• Gold: tüketim katmanı (data mart rolü): BI grain’i, KPI, mart tabloları.

Avantajlar: yarı ham veri ve Spark/ML bronze-silver’da kalır; ucuz arşiv ve silver’da kalite kapısı sağlanır; BigQuery gold dataset’leriyle örtüşebilir.

İki sözlüğü eşlemek

Gold = data mart mı? Rol olarak evet: medallion’da raporların beslendiği katman olan gold, katmanlı ambardaki data mart ile aynı işi görür. Core ise ayrıdır: entegrasyon ve tek doğruluk kaynağıdır; hibritte çoğu zaman silver ve gold’daki ortak modellere denk gelir.

Kabaca:

• Landing ≈ Bronze
• Staging ≈ Silver
• Core ≈ Silver/Gold entegrasyonu (ortak boyutlar, conformed facts)
• Data mart ≈ Gold (tüketim)

Dataset adları farklı olsa da hedef ortak bir sözlüktür. Katman sayısı disiplin getirir; disiplin yoksa yalnızca daha pahalı kopya üretir. PoC skor kartına “Katman sahipleri ve isimler ADR’de mi?” satırını ekleyin.

PoC: en hızlı öğrenme, en küçük risk

PoC’nin amacı satın alma slaytı değil, yanlış yolu erken elemektir.

1. Senaryo seçin (en fazla üç). Tüm işi taşımak gerekmez. En sıkıntılı işin en sıkıntılı statement’larını seçin: en ağır gece job’ı, en tartışmalı rapor ya da en çok kopya üreten entegrasyon. Bulk insert, update, karmaşık select ve window function gibi farklı profilleri kapsasınlar. Her biri küçük, orta ve büyük veri hacminde koşulsun; adayların sıralaması hacimle değişebilir.
2. Aynı girdi, aynı çıktı. Grain ve kabul kriterleri yazılı olsun: satır sayısı, toplam, örnek join.
3. İki-üç aday, aynı süre (iki hafta). Örneğin BigQuery + Dataform, Snowflake + dbt, Databricks lakehouse.
4. Tek skor kartı. Geliştirme süresi, PoC ortam maliyeti, sorgu gecikmesi, operasyondaki hareketli parça sayısı, ekip uyumu, güvenlik/yönetişim. Ayrıca: akış net mi, maliyet tavanı var mı, operasyonel sahip kim, lineage kurulu mu? Sorun çıktığında kiminle konuşacağınız da bir satır olsun (aşağıya bakın).
5. Canlıya değil, karara. Kazanan desen referans mimari olur; geri kalanı dalga dalga gelir.

PoC’de parlayıp canlıda dağılan fikirlerin sık nedenleri: veri akışı belirsiz, maliyet tavanı yok, sahip yok, izlenebilirlik sonradan eklenmiş.

Adayları performans ve maliyet eler, muhatap karar verir

PoC’de adaylar çoğunlukla performans ve maliyet dengesinde elenir. Son seçimde en belirleyici soru ise çoğu zaman başkadır: sorun yaşadığımızda kiminle konuşacağız? Canlıda bir sorgu dağıldığında ya da fatura beklenmedik biçimde büyüdüğünde, aynı saat diliminde ve aynı dilde ulaşılabilen bir muhatap operasyonel riski doğrudan düşürür. Bu yüzden sağlayıcının yerel ofisi, destek ekibi ve partner ağı karar tablosunda somut bir ağırlık taşımalıdır.

Bunu skor kartında açık satırlara çevirin: yerel ofis, destek kanalı ve yanıt süresi, yerel partner ekosistemi, danışman kalitesi. Aksi hâlde karar toplantıda “hissedilen güven” olarak kalır.

PoC’den üç ders

1. Sıralama veri hacmiyle değişebilir. Küçük veride hızlı olan aday büyük hacimde geri düşebilir. PoC’yi küçük, orta ve büyük hacimde koşun; tek hacimde alınan sonuç karar için yetmez.
2. Dosyayı dışarıdan okumak ile tabloyu içeride tutmak aynı şey değildir. Verinin dosya olarak durup dışarıdan okunduğu kurulum kolay görünür, ama sorgu süresi ve maliyet değişir. PoC’de iki modeli de ölçün.
3. Tek kullanıcılı test yanıltır. Aynı sorguları paralel yük altında da koşun; maliyeti tek sorgu başına değil, gerçekçi bir günlük yük için hesaplayın.

Ürün kısa listesi

Profil	Genelde uygun yön	Dikkat
SQL, gece batch, çok rapor	BigQuery / Snowflake + Dataform / dbt	Partition, slot; TCO şişebilir
Spark, ML, yarı ham veri	Lakehouse	Gold olmadan lake dağılır
Google Cloud’a yerleşim hazır	BigQuery merkezli hibrit	Multi-cloud operasyonu ikiye katlar
Microsoft 365, Fabric, Power BI	Fabric / OneLake	SSAS küpleri varsa semantik katman korunabilir
Stream (olay, dakika altı gecikme)	Pub/Sub + Dataflow ya da Flink	Landing append veya doğrudan silver/gold; batch ile aynı Core

“BigQuery mi, Snowflake mi?” bu tabloda çoğu zaman tek satırdır. Asıl ayrım, lakehouse ihtiyacı ve buluttaki mevcut yerleşiminizdir.

TCO: en düşük bütçe tek satırda çıkmaz

En az üç yıl ve şu kalemler:

• Lisans ve kapasite: mevcut ambar ve Hadoop baseline’ı. On-prem bir hedef de masadaysa yeni donanım, lisans ve felaket kurtarma (DR) da aynı tabloya girer; bulutta bunların yerini tüketim alır.
• Bulut tüketimi: depolama, slot, pipeline, egress.
• Geçiş: dual-run, test, eğitim.
• Operasyon: platform ekibi, vendor.
• Risk: gecikmiş rapor, kalite, regülasyon. Yalnızca sıralama olarak bile olsa skor kartında yer alsın.

Birinci yılda dual-run ve geçiş projesi unutulursa “bulut ucuz” yanıltır. PoC faturayı üretim hacmine ölçekler; TCO eski lisansın ne zaman kapatılabileceğini sorar.

En hızlı geçiş lift-and-shift gibi görünür; en düşük TCO çoğu zaman bir miktar yeniden modelleme ister. PoC ikisinin kesişimini gösterir.

Canlıya geçiş: iki sistem birlikte, imzayla kapanış

Platform seçildikten sonraki soru, eski sistemi ne zaman kapatacağınızdır. Önerdiğim sıra şu:

1. İki sistemi birlikte yaşatın (dual-run). Eski ve yeni platform aynı kaynaktan beslensin.
2. Fark (gap) analizi yapın. Aynı rapor ve tabloları iki tarafta karşılaştırın, sapmaları tek tek listeleyin ve kapatın.
3. İş birimlerini kullanıcı kabul testine (UAT) açın. Rakamı kullanan taraf kendi raporlarını yeni sistemde doğrulasın.
4. Tamamen emin olunca eski sistemi emekliye ayırın. Yeni sistem ancak bu noktadan sonra tek doğruluk kaynağı olsun.

Dual-run TCO’da bir maliyet kalemidir ve süresi uzadıkça pahalanır. Bu yüzden kapanış kriterini baştan yazın: sapma eşiği, UAT onayı veren iş birimleri ve tarih. Süre uzayabilir, ama kapanış koşulu belirsiz olmasın.

Karar sırası

1. Gecikme: gece mi, dakika mı?
2. Kaynak: dosya mı, CDC mi, olay mı?
3. Dönüşüm: SQL modeli mi, Spark mı?
4. Doğruluk: kural kırılınca akış duruyor mu?
5. Muhatap: sorun çıktığında kime ulaşıyorsunuz?
6. Para: üç yıllık TCO.

Sıra yazılınca kısa liste çıkar; PoC kazananı seçer; TCO finans onayını alır.

Google Cloud örnek haritası

Aynı mantık diğer bulutlarda da kurulabilir; burada örnek olarak Google Cloud var.

• Gece batch, SQL, katmanlı ambar: Datastream / batch load → Landing → Staging → Core → Data mart (BigQuery dataset’leri); Dataform + Composer + assertion’lar.

• Stream: Pub/Sub → Dataflow (Beam) → BigQuery. İki yol var:

  • A. Landing append: ham olay landing’e yazılır, silver/Core gece batch ile işlenir. Denetim ve replay kolaydır; gecikme yaklaşık bir batch’tir.
  • B. Doğrudan silver/gold: Beam’de doğrulama ve tekilleştirme sonrası hedef grain’e yazılır. Dakika altı kararlar içindir; şema sözleşmesi ve kalite kontrolü şarttır.

  İki yol da gece batch’inin ürettiği Core modeline birleşir; stream ayrı bir mart açarsa yine iki sayıya dönersiniz.

• Yönetişim: Dataplex + Dataform assertion’ları + Cloud Build.

Canlıda çok miktarda Spark varsa Dataproc bir süre kalır. Doğası SQL olan iş SQL’de kalır; lake besleme ve arşiv rolünü üstlenir.

On-prem’den BigQuery’ye mi, önce lake’e mi?

Pratik cevap çoğu kurumda hibrit. PoC’de aynı senaryoyu her iki katmanla bir kez koşturmak ideolojiyi bitirir.

Kapanış için üç soru: Acı noktalarınızı listeleyip her birine bir karşılık yazabiliyor musunuz? PoC’de ölçtünüz mü? TCO’da üçüncü yılı gösterdiniz mi?

---

Bu yazıdaki görüşler kişiseldir.