Ay Sonu Kapanışını Kaçırmadan BigQuery'ye 60 TB'lık Göç

Bir veri ambarı göçünü zorlaştıran şey 60 TB değildir; 60 TB iki günde kopyalanır. Zor olan, göç sürerken her sabah 07:00’de 1.200 mağazanın raporunun ekranda olması ve her ay sonu finans kapanışının tek bir gün bile kaymamasıdır. Tek bir yanlış sayı kapanışı bozar, tek bir boş rapor mağazayı kör bırakır ve bu iki şey 12 ay boyunca her gün doğru kalmak zorundadır.

Bu kurgusal bir senaryodur; gerçek bir şirketin sistemlerini tanımlamaz.

Problem

Bu senaryoda, 40 ülkede 1.200 mağazası ve bir e-ticaret kanalı olan bir moda perakendecisinin baş veri mimarı rolündeyim. Analitik platform on-prem bir SQL Server ambarı (60 TB, 2.800 tablo, 1.900 SSIS (SQL Server Integration Services) paketi) ve en ağır batch işlerini üstlenen 12 düğümlü bir Hadoop kümesi. Gecelik batch 9 saat sürüyor ve mağaza yöneticileri açmadan önceki 07:00 sınırını düzenli olarak kaçırıyor. Donanımın desteği 14 ay sonra bitiyor; lisans yenilemesi bulut bütçesinden pahalı. Kurul, ambar olarak BigQuery ile Google Cloud’a geçişi onayladı.

Ambarın çevresinde 2.500 iş kullanıcısı 600 Power BI raporuna bağlı; 40 alt sistem (ikmal, fiyatlama, finans kapanışı) ambar tablolarını doğrudan okuyor. Veri ekibi 16 kişi; yarısı bulutu hiç görmemiş SQL Server uzmanı. Ay sonu kapanışı ambarda çalışıyor ve bir gün bile kayamaz.

Sekiz gereksinim:

• R1. 60 TB ve 1.900 paket 12 ayda, rapor kesintisi olmadan taşınır; ay sonu kapanışı eski ya da yeni platformda çalışır, asla ikisinde farklı sayılarla değil.
• R2. Yeni platformda gecelik batch 3 saatin altında; 07:00 mağaza sınırı göç sırasında ve sonrasında her gün tutulur.
• R3. Her taşınan tablo, eski tablo kapatılmadan önce en az 2 kapalı muhasebe dönemi boyunca satır sayısı, toplam ve hash ile eşit kanıtlanır.
• R4. Bulut maliyeti öngörülebilir: iş alanı başına aylık bütçe, sınırsız sorgu yok, finansa geri fatura (chargeback) raporu.
• R5. Alt sistemler çalışmaya devam eder; 40 tüketici SQL ya da dosya ile okuyor, hepsi aynı anda değişemez, bir kısmı geçiş dönemi için SQL Server uyumlu arayüz ister.
• R6. Katmanlı ambar (landing, staging, core, mart), versiyonlu SQL, CI/CD, otomatik veri kalitesi; üretimde elle çalıştırılan script yok.
• R7. GDPR: analitik katmanlarda takma adlandırılmış müşteri verisi, AB yerleşimi, tablo başına saklama, kişisel veriyi kimin sorguladığının denetimi.
• R8. SQL Server uzmanları 3 ayda üretken; 6. aydan sonra dış danışmana bağımlılık yok.

Her şeyi şekillendiren kısıt

Tasarımı belirleyen cümle şu: göç sırasında işletme durmaz. Ay sonu kapanışı ve 07:00 raporu her gün çalışmak zorunda olduğu için büyük patlama (big-bang) geçişi baştan elenir; 2.800 tablo ve 40 tüketici bir hafta sonunda taşınamaz, çünkü geri dönüş yolu yoktur. Bu kısıt mimariyi tablo tablo, çift çalıştırmalı (dual-run) ve mutabakatla kanıtlanmış bir geçişe zorlar. İkinci kısıt maliyettir: BigQuery’de kontrolsüz sorgu bütçeyi aylar içinde tüketir; bu yüzden FinOps (bulut maliyet yönetimi) ilk sprintin çıktısıdır, sonradan eklenen bir rapor değil. Geri kalan her karar bu ikisinden türer.

Tasarıma kuş bakışı

Tasarımı, bir mülakatta tahtaya çizdiğim sırayla soldan sağa anlatayım.

En solda var olan sistemler durur: ERP, POS ve e-ticaret kaynakları, 12 düğümlü Hadoop ve emekliliğe kadar referans kalan eski SQL Server ambarı. Oradan iki yol çıkar: Debezium CDC ile Kafka (tablo başına LSN watermark) ve dalga başına bir kez yapılan 60 TB’lık toplu yükleme. İkisi de AB’deki değişmez GCS landing’e iner, oradan alan başına bir BigQuery projesine yüklenir.

Ortada BigQuery katmanları var: landing, staging, core (Data Vault 2.0), mart ve eski tablo adlarını taşıyan legacy view şeması.

Altında Dataform ve Composer (02:00 kesim, 04:30 bitiş) ile göç kontrol düzlemi var: SSIS bağımlılık grafı, dalga planlayıcı, iki tarafta sayı, toplam ve hash hesaplayan mutabakat, tablo başına geçiş anahtarı ve dönem başına kapanış sahibi bayrağı. Mutabakat hash’leri eski ambarla karşılaştırır; geçiş anahtarı uyumluluk servisini yönetir, o da on-prem SQL Server uyumluluk veritabanını besler.

En sağda tüketiciler durur: FinOps, 600 Power BI raporu, 40 alt sistem, finans ve 16 kişilik ekip.

Çözüm görünümü

Bileşen düzeyinde her seçim dual-run kısıtından türer.

Veri alımı

Kaynaklar dokunulmaz kalır: Debezium (Kafka Connect) SQL Server CDC (değişiklik yakalama) tablolarını önce snapshot, sonra akış olarak okur ve her tablo için LSN (log sıra numarası) watermark’ı üretir; bu watermark gece çalıştırmasının ve mutabakatın okuduğu çizgidir. Kafka (Strimzi, üç kopya ile RF=3, 7 gün saklama) cdc.<domain>.<table> ve migration.events konularını taşır; Apicurio tablo başına Avro sözleşmesini tutar. Tarihsel veri dalga başına bir kez bcp ya da distcp ile GCS’te Avro’ya, oradan load job ile BigQuery’ye yüklenir.

Dönüşüm: Dataform

Dönüşüm katmanı Dataform. Nedeni teknik değil, insani: R8’e göre 8 SQL Server uzmanı 3 ayda üretken olmalı ve Dataform modeli bir SELECT, assertion’ı da bir SELECT’tir. dbt Core taşınabilir bir alternatif, ama Dataform BigQuery içinde çalıştığı için ek altyapı istemiyor. Her model Git’te, her modelin assertion’ı var, üretime yalnız CI/CD ile giriliyor. Java yalnız Kafka ve Debezium’u işleten 3 kişilik çekirdek ekiptedir.

Katmanlar ve Data Vault 2.0

BigQuery’de dört katman var. Landing ham Avro’yu yükleme gününe göre partition’lanmış tutar ve ham tanımlayıcıların yaşadığı tek yerdir. Staging tipli, tekilleştirilmiş ve takma adlandırılmış veridir; kişisel veri sütunları burada policy tag alır. Core katmanı Data Vault 2.0’dır: hub, link ve satellite. Bu katada diğerlerinden farklı seçtiğim bileşen budur. Göç 12 ay sürerken ERP, POS ve e-ticaret değişmeye devam eder; doğrudan dimensional model kursaydım her kaynak değişikliği mart’ı ve 600 Power BI modelini kırardı. Data Vault’ta kaynak değişince yalnız satellite değişir; mutabakat da kaynak başına izlenebilir kalır. Dimensional model yalnız mart katmanındadır ve kullanıcı Data Vault’u hiç görmez.

Orkestrasyon ve göç kontrol düzlemi

Cloud Composer (yönetilen Airflow) gecelik ve dalga DAG’lerini çalıştırır. Göç kontrol düzlemi Cloud Run üzerinde Quarkus servisleri ve Cloud SQL PostgreSQL’den oluşur: bağımlılık grafı servisi 1.900 SSIS paketinin XML’ini ayrıştırıp ölü ve tekrarlı olanları işaretler (varsayımım yüzde 30), dalga planlayıcı alanları iki kapalı dönemlik dual-run’a böler, mutabakat servisi karşılaştırır, geçiş anahtarı tablo başına durumu ve dönem başına kapanış sahibini tutar. Ticari SSIS çeviri aracı kullanmadım; çeviri, paketin teknik borcunu da taşır. Graf çıkarıp ölü paketleri atmak işi yaklaşık yarıya indirir: 1.300 akış, 600 Dataform modeli.

Tüketiciler eski adlarını korur

Tüketiciler için uyumluluk servisleri var: BigQuery’de eski tablo adlarını mart’ın üzerinde yaşatan legacy view şeması ve T-SQL’e ihtiyaç duyan 15 tüketici için mevcut lisanslı SQL Server’a gecelik ters senkron. Yeni lisans alınmaz. Power BI raporları bağlantı dizisini değiştirir, modelini değil. Legacy view ve uyumluluk veritabanı kullanımı tüketici başına günlüklenir; 30 gün okuyucusu olmayan ve grafında alt akışı kalmayan tablo önce yeniden adlandırılır, iki dönem sonra silinir. Emekliliğe bir slayttaki tarih değil, veri karar verir. Dataplex katalog ve lineage’ı, Keycloak kokpit kimliğini sağlar.

Garantiler nasıl tutuluyor

Her tablo beş duraktan geçer: eski çalıştırma, yeni çalıştırma, mutabakat, geçiş kararı, emeklilik. Aşağıda her durağın mekanizması adıyla yazılı; bu serinin kuralı budur, mekanizmasız garanti yazmam.

Rapor kesintisi yok: dual-run

SSIS batch göç boyunca değişmeden her gece çalışır ve referanstır. Yeni çalıştırma aynı iş gününü okur: Composer DAG’i, her kaynak tablonun CDC watermark’ı (LSN) 02:00 kesimini geçtiğinde başlar ve eski taraftaki mutabakat sorgusu aynı LSN ya da kesim zaman damgasına filtrelenir; böylece iki taraf aynı dilimi karşılaştırır. Kesimden sonra commit edilen değişiklik o gece iki dilimde de yoktur; BigQuery’ye geç ulaşan değişiklik ertesi günün partition’ına düşer ve “geç veri” olarak işaretlenir, kapalı döneme sessizce karışmaz. Yüklemeler idempotenttir: satellite’lara iş anahtarı ve load_ts ile MERGE, mart’lara partition düzeyinde değiştirme; tekrar çalıştırma aynı tabloyu üretir, çift satır üretmez. Hadoop offload işleri 1. dalgada taşınır; bu yüzden eski batch göç sırasında uzamaz, kısalır.

Kanıtlanmış eşitlik: mutabakat servisi

Dual-run’daki her tablo için her gece satır sayısı, her sayısal sütunun toplamı ve kanonik satır hash’inin partition başına toplamı iki tarafta hesaplanır. İki taraf aynı kanonik dizgiyi (ISO UTC tarih, sabit ölçekli ondalık, NULL literal) SHA-256 ile hash’ler: SQL Server’da HASHBYTES(‘SHA2_256’), BigQuery’de SHA256(). Fark sınıflandırılır: zaman dilimi, yuvarlama, NULL semantiği, collation ve boşluk, geç veri, gerçek hata. Her sınıfın yazılı kuralı vardır ve kural Dataform dönüşümüne yazılır; sonucu yamalamak yasaktır. Kanıt, tablo ve dönem başına mutabakat deposunda saklanır; finans mart’ı için finans imzalar.

Tek kapanış sahibi: bir bayrak

Her muhasebe dönemi açılmadan önce geçiş anahtarı, tablo grubu başına (finans mart’ı bir bütün olarak) tek bir kapanış sahibi platform kaydeder. Yalnız sahibin sonuçları yayınlanır: legacy view’lar ve Power BI bağlantı dizileri sahibi gösterir; diğer platformun sonucu, veri ekibi dışında kimsenin okuyamadığı gölge veri setidir. Geri alma bir bayraktır ve iki bağlantı dizisi iki dönem boyunca tutulur.

07:00 sınırı: kapasite ve watermark alarmı

07:00 için hesap şu: pilotta 180 model gecede 220 slot-saat ölçtü; 600 model yaklaşık 730 slot-saat eder, bu da 500 slot ile 1,5 saat demektir. Kritik yol 45 model çarpı yaklaşık 2 dakika, yine 1,5 saat; plan 2,5 saat. Slot rezervasyonu 02:00’de kapasiteyi garanti eder; ay sonunda +500 slotluk autoscale tavanı ve finans önceliği devreye girer. Tablo başına CDC gecikmesi kesimden 30 dakika önce alarm verir; geç kalan tablo son watermark’ıyla çalışır ve durum tablosunda “bayat” olarak işaretlenir.

Öngörülebilir maliyet: rezervasyon ve bayt tavanı

Her alan projesinin aylık bütçesi var. Yıllık taahhütlü 500 slotluk taban sabit bir aylık maliyettir ve ilk sorgu çalışmadan önce bilinir. Kullanıcılar için on-demand kapalıdır ve her sorguda maximum_bytes_billed vardır: kullanıcı için 1 TB, boru hattı için 10 TB; tavanı aşan sorgu çalışmaz ve fatura üretmez. Etiketlerden INFORMATION_SCHEMA.JOBS üzerinden aylık geri fatura raporu finansa gider.

Dağıtım, güvenlik, regülasyon

Projeler ve ağ

Google Cloud tarafında tek bir organizasyon klasörü (dwh) ve fonksiyon ile alan başına projeler var: dwh-ingest (GKE üzerinde Kafka, Apicurio ve GCS landing), dwh-core (BigQuery katmanları, Dataform, Composer, rezervasyon), dwh-mart-finance, -merch, -supply ve -ecom (her birinin kendi bütçesi ve slot payı), dwh-migration (kontrol düzlemi, Cloud SQL, Keycloak), dwh-ops ve dwh-admin. Proje maliyet ve erişim sınırıdır. Tüm projeler tek bir VPC-SC çevresinde; BigQuery’ye açık uç nokta yok, Power BI ve tüketiciler Private Service Connect ile bağlanır. On-prem bölge dalga dalga küçülür: Hadoop 6. ayda, uyumluluk veritabanı 12. ayda kapanır. Dedicated Interconnect 10 Gbps artı HA VPN; 60 TB’lık ilk kopya yaklaşık 2 gün, günde 400 GB CDC, gecelik 50 GB ters senkron.

Kimlik ve erişim

Kimlik, alan başına IAM gruplarıdır; kullanıcı bazlı yetki (grant) yok, acil erişim (break-glass) onaylı. Kişisel veri sütunları staging’de policy tag alır; landing’deki ham sütunları yalnız takma adlandırma işi ve veri koruma sorumlusu (DPO) grubu okur. Mart’larda ülke yöneticileri için satır düzeyi güvenlik var; core’a doğrudan erişim yok, authorised view ile erişilir. Ad-hoc analiz kendi bayt tavanı olan sandbox projesinde yapılır. Her iş, her yetki ve her geçiş bayrağı değişikliği aktör ve gerekçeyle denetim veri setine yazılır.

GDPR

GDPR m. 5 veri minimizasyonu için müşteri tanımlayıcıları staging’de Cloud KMS’teki kişi başına anahtarla takma adlandırılır; ham tanımlayıcı yalnız landing’dedir ve 30 günde yaşam döngüsüyle silinir. M. 17 silme hakkı, kişi başına anahtar malzemesinin yok edilmesi, landing’in 30 günde dolması ve müşteri satellite’ının temizlenmesiyle karşılanır; mart’lar core’dan partition bazında yeniden kurulur ve kanıt saklanır. M. 30 işleme kayıtları DPO’da tutulur; BigQuery Data Access denetim günlükleri kimin hangi kişisel veri sütununu ne zaman sorguladığını yanıtlar ve DPO’ya aylık rapor gider. AB yerleşimi Org Policy resourceLocations = EU, BigQuery AB multi-region, GCS AB ve AB’deki Power BI kiracısıyla zorlanır. Saklama tablo başınadır: landing 30 gün, staging 90 gün, core yasal sınıfa, mart alan politikasına göre.

İzleme ve dayanıklılık

Tek bir pano mutabakat farkını, 07:00’a karşı batch bitiş saatini, bütçeye karşı alan başına taranan baytı, CDC gecikmesini ve tüketici başına legacy view kullanımını gösterir. Dayanıklılık tarafında her dalga yüklemesinden önce gecelik snapshot ve 7 günlük time travel var; Dataform’da geri alma, git revert artı yeniden çalıştırmadır ve yüklemeler idempotent olduğu için güvenlidir. En önemlisi, eski platform emekliliğe kadar sıcak kalır: dual-run sırasında BigQuery’de kötü bir gece hiçbir şeye mal olmaz, çünkü sahip platform yayınlar.

Mülakatta bana sorulacaklar

1. Dual-run’da iki platform aynı gece farklı sayı üretti ve o gün ay sonu; ne yayınlanır? Kapanış sahibinin sayısı. Diğeri gölgedir, kimse görmez. Fark mutabakat deposuna yazılır, sınıflandırılır ve dönüşümde düzeltilir; o dönem o tablo için sıfır fark sayılmaz, dalga bir dönem uzar. Kapanış asla iki platformdan farklı sayıyla yapılmaz.
2. Mutabakat farkı hiç sıfır olmazsa? Eski tablo yaşar ve kapanış sahibi kalır. Farkların büyük çoğunluğu zaman dilimi, yuvarlama, NULL semantiği ve collation’dan gelir; her sınıfın kuralı dönüşüme yazılır ve yeniden kanıtlanır. Gerçek bir eski sistem hatası bulunursa finansla hangi sayının doğru olduğu kararlaştırılır ve belgelenir; sonuç yamalanmaz.
3. Bir kullanıcı 60 TB’lık tabloya SELECT * attı; fatura ne olur? Olmaz. Kullanıcı sorgularında maximum_bytes_billed 1 TB’dir; sorgu tahmini tavanı aşınca başlamadan reddedilir ve fatura üretmez. Boru hatları 10 TB tavanla rezervasyon içinde çalışır; rezervasyon sabit maliyettir (500 slot, yıllık taahhüt), kullanıcılar için on-demand kapalıdır.

Açık noktalar

• 40 tüketicinin hangi 15’i gerçekten T-SQL’e ihtiyaç duyuyor ve ne kadar süreyle? Uyumluluk veritabanının ömrünü ve ters senkronun kapsamını bu belirler.
• Finans yeni platformu 5. dalgadan itibaren kapanış sahibi olarak kabul ediyor mu, yoksa önce paralel bir kapanış mı istiyor? Bu, dalga süresini bir dönem uzatabilir.
• 40 ülkedeki POS beslemelerinin SQL Server sürümleri ve CDC izinleri: Debezium veritabanı başına CDC ister; eski sürümler için log shipping replikası gibi bir ara çözüm gerekebilir.

Karar

Tek cümleyle: büyük patlamayı reddedip her tabloyu iki kapalı dönem boyunca kanıtlamak göçü 12 aya yayar, ama kapanışı ve 07:00 raporunu bir gün bile riske atmaz; bu ödünleşimi her seferinde veririm.

Siz bir ambar göçünde kapanış sahipliğini nasıl yönettiniz: bayrakla mı, takvimle mi, yoksa iki platformu da yayınlayarak mı?

---

Mimari Katalar serisinin 1. bölümü (16 bölüm). Seri, kurgusal mülakat tipi tasarım problemlerini tahtada çözeceğim gibi uçtan uca işliyor. Serinin sonraki yazısı: Çok Kanallı Sipariş ve Stok Orkestrasyonu.