Mimari kata · K—04
Kurumsal Veri Ambarının BigQuery'ye Göçü
Mimari kata · kurgusal bir problem tanımı üzerine tasarım çalışması
- Sektör
- Perakende veri platformu
- Konu
- Güvenilir veri
- Teknolojiler
- BigQuery, Dataform, Debezium, Apache Kafka, Cloud Composer, Cloud Storage, Data Vault 2.0, Quarkus, Great Expectations, Dataplex
Kısaca
60 TB'lık SQL Server ambarını ve 1.900 ETL paketini 12 ayda, dalga dalga ve her tabloyu mutabakatla BigQuery'ye taşımak.
Problem
40 ülkede 1.200 mağazası olan bir moda perakendecisi, şirket içi bir SQL Server ambarı işletiyor. Ambar 60 TB, 2.800 tablo ve 1.900 SSIS paketinden oluşuyor; yanında bir Hadoop kümesi var. Gecelik batch dokuz saat sürüyor ve sık sık 07:00 hedefini kaçırıyor. Donanım desteği 14 ay sonra bitiyor. Yönetim kurulu BigQuery’ye geçişi onayladı. 600 Power BI raporu ve 40 alt sistem ambara bağlı; ay sonu finans kapanışı bir gün bile kayamıyor. Veri ekibi 16 kişi ve yarısı buluta yeni SQL Server uzmanı.
Yaklaşım
Ana kısıt: geçiş sırasında işletme durmuyor. Büyük patlama geçişi imkânsız olduğundan göç, çift çalıştırmalı (dual-run) ve tablo tablo ilerliyor. Eski platform referans olarak kalıyor. Yeni platform aynı kesim noktasından aynı tabloları üretiyor. Bir mutabakat servisi her gece satır sayısı, toplam ve özetleri karşılaştırıyor. İki kapalı muhasebe dönemi boyunca fark sıfırlanmadan hiçbir tablo geçmiyor.
Mimari
- Yakalama ve yükleme: Debezium değişiklik yakalama, Kafka üzerinden Cloud Storage’a Avro olarak akıyor. Tarihsel veri dalga başına bir kez toplu yükleniyor.
- Katmanlar: Dataform; staging, core (Data Vault 2.0) ve boyutsal mart katmanlarını Git’te sürümlü SQL olarak tutuyor; assertion’lar var ve üretime yalnızca CI/CD ile girilir.
- Eski paketler: SSIS otomatik çevrilmiyor. Bağımlılık grafı çıkarılıyor, ölü ve tekrarlı paketler atılıyor, akışlar iş alanına göre dalgalara bölünüyor.
- Kontrol düzlemi: bağımlılık grafı, dalga planlayıcı, mutabakat servisi ve tablo başına geçiş anahtarı.
- Tüketiciler: eski tablo adları BigQuery’de görünüm olarak yaşıyor. T-SQL tüketicileri için geçiş döneminde SQL Server’a ters senkron var.
Neden bu bileşenler
| İhtiyaç | Seçim | Neden |
|---|---|---|
| Veri ambarı | BigQuery; ticari, gereksinimin izin verdiği istisna | Kurul kararı: sunucusuz, sütunlu, AB çok bölgeli. Rezervasyon ve bayt tavanı maliyeti öngörülebilir kılıyor; time travel ve snapshot geri dönüş yolu veriyor. Kurul BigQuery’yi seçince Iceberg üzerinde Trino seçenek olmaktan çıktı. |
| Değişiklik yakalama | Debezium (Kafka Connect), Apache Kafka (Strimzi) | SQL Server değişiklik tablolarını günlük konumuna göre akıtıyor; tablo başına watermark mutabakatın okuduğu çizgi. Datastream yönetilen ama eski SQL Server sürümlerini ve şema geçmişini desteklemiyor. Redpanda lisansı nedeniyle elendi. |
| İlk toplu yükleme | bcp ve distcp ile Cloud Storage’a Avro, ardından BigQuery yükleme işleri | Dalga başına bir kez 60 TB; Interconnect üzerinden yaklaşık iki gün. BigQuery Data Transfer Service alternatif, ama Hadoop verisi zaten distcp istiyor. Tek yöntem, daha az araç demek. |
| Landing | Google Cloud Storage; AB, değiştirilemez | Tablo ve gün bazında Avro dosyaları. Her BigQuery katmanı landing ve Dataform’dan yeniden kurulabiliyor. Yaşam döngüsü kuralı nesneleri 90 günde Nearline’a taşıyor. |
| Dönüşüm | Dataform (SQLX) | SQL Server uzmanlarının üç ayda üretken olmasının anahtarı: Java değil SQL yazıyorlar. Her modelde assertion, Git ve yalnızca CI/CD. Taşınabilir alternatif dbt Core; Dataform ek altyapı istemiyor. |
| Core model | Data Vault 2.0; hub, link ve satellite | Kaynak değişince yalnızca satellite değişiyor; mart’lar ve Power BI modelleri yerinde kalıyor. Yükleme, iş anahtarı ve yükleme zamanıyla idempotent MERGE. Doğrudan boyutsal core her kaynak değişikliğinde mart’ı kırardı. |
| Orkestrasyon | Cloud Composer (yönetilen Apache Airflow) | Alan başına gecelik DAG’lar, dalga DAG’ları, watermark kontrolü ve 05:00 hedefi. Airflow açık kaynak; DAG’lar taşınabilir kalıyor. |
| Göç kontrol düzlemi | Cloud Run’da Quarkus servisleri, Cloud SQL PostgreSQL | SSIS XML’inden bağımlılık grafiği, dalga planlayıcı, mutabakat, tablo başına geçiş anahtarı ve kapanış sahibi bayrağı. Ticari SSIS çeviricileri paketlerin teknik borcunu taşır; ölü paketleri atmak işi yarıya indiriyor. |
| Mutabakat | Mutabakat servisi ve Great Expectations | Satır sayısı, sütun toplamları ve kanonik satır özeti partition başına iki tarafta hesaplanıyor. Her fark sınıflanıyor, kuralı dönüşüme yazılıyor. Great Expectations eşik ve okunur rapor ekliyor. |
| Uyumluluk arayüzü | BigQuery’de legacy view şeması, mevcut SQL Server’a ters senkron | Kırk tüketici aynı gün değişemez. Eski adlar görünüm olarak yaşıyor; 15 T-SQL tüketicisi gecelik ters senkron alıyor. Yeni SQL Server lisansı yok. Babelfish yalnızca AWS’de ve T-SQL’i kısmen destekliyor. |
| Katalog, soy ağacı, policy tag | Dataplex ve BigQuery policy tag’leri | Kişisel veri sütunları staging’de etiketleniyor; erişim policy tag’le, okumalar bir denetim dataset’inde. Açık alternatif OpenMetadata; Dataplex BigQuery soy ağacını kendiliğinden veriyor. |
| Kimlik | Keycloak (OpenID Connect), Google Cloud IAM grupları | Göç kokpiti ve Grafana için Keycloak. BigQuery erişimi alan başına IAM gruplarıyla; kullanıcı bazlı yetki yok. |
| Gözlemlenebilirlik | Prometheus, Grafana, Cloud Monitoring, Logging sink | Mutabakat farkı, batch bitiş saati, alan başına bayt ve legacy view kullanımı tek panoda. Denetim günlükleri GDPR Madde 30 kayıtları için BigQuery’ye akıyor. |
Kararlar ve ödünleşimler
- Büyük patlama değil, dalga dalga çift çalışma. 2.800 tablo ve 40 tüketiciyle bir hafta sonu geçişinin geri dönüşü yok. Ay sonu kapanışı tek bir yanlış sayıyı kaldırmaz. Her tablo geçmeden önce iki kapalı dönem boyunca sıfır fark göstermeli; geri alma bir bayrak. Bedeli iki platformu birlikte işletmek. Fark çıkan bir dönem o dalgayı bir dönem uzatıyor.
- Her ay sonu kapanışının tek sahibi var. Her dönem açılmadan önce geçiş anahtarı kapanışın hangi platformda olduğunu kaydediyor. Yalnızca sahip yayınlıyor. Diğer sonuç, yalnızca veri ekibinin okuyabildiği bir gölge dataset; finans mart’ı tek blok halinde geçiyor. Bedeli: finans önce paralel bir kapanış isteyebilir, bu da bir dönem ekler.
- Doğrudan boyutsal model yerine Data Vault 2.0 core. ERP, POS ve e-ticaret sistemleri göç boyunca değişmeye devam ediyor. Kaynak değişikliği yalnızca bir satellite’e dokunuyor; mart’lar ve 600 Power BI modeli sabit kalıyor, mutabakat kaynak başına izlenebiliyor. Kullanıcı yalnızca boyutsal mart’ları görüyor. Bedeli daha fazla tablo.
- Eşitliği kanıtla, sonucu asla yamalama. İki taraf aynı kanonik dizgiyi SHA-256 ile özetliyor. Fark sınıflanıyor: zaman dilimi, yuvarlama, NULL davranışı, collation ya da geç veri. Kural Dataform modeline yazılıyor. Eski sistemin hatalı çıktığı durumda hangi sayının geçerli olduğuna finans karar veriyor ve karar yazılı kalıyor.
- İlk sprintten itibaren FinOps. Autoscale tavanlı sabit slot rezervasyonu, kullanıcılara on-demand kapalı, her sorguda bayt tavanı: kullanıcı için 1 TB, boru hattı için 10 TB. Tavanı aşan sorgu hiç başlamıyor ve fatura üretmiyor. Etiketler aylık geri fatura raporunu besliyor. Bedeli: kullanıcılar sorgularını daraltmalı; DirectQuery raporları da tavanı zorluyor.
- Önce SQL becerisi, otomatik SSIS çevirisi yok. Kata 1.900 paketin yaklaşık %30’unun ölü ya da tekrarlı olduğunu varsayıyor. Bağımlılık grafiğini çıkarıp onları atıyorum, akış başına bir Dataform modeli yazıyorum. Bu işi yarıya indiriyor ve ekibe SQL’i öğretiyor. Java üç kişilik akış çekirdeğinde kalıyor. Bedeli elle yeniden yazım.
Yeniden ele alacaklarım
- T-SQL tüketicileri. 15 tüketiciden hangisi gerçekten T-SQL istiyor ve ne kadar süre? Uyumluluk veritabanının ömrünü ve ters senkronun kapsamını bu belirler.
- Finansın kabulü. Finans yeni platformu beşinci dalgadan itibaren kapanış sahibi olarak kabul edecek mi, yoksa önce paralel kapanış mı isteyecek? Bu bir dalgayı bir dönem uzatabilir.
- Mağaza satış kaynakları. Debezium veritabanı başına değişiklik yakalama istiyor. 40 ülkedeki eski SQL Server sürümleri araya bir log shipping replikası gerektirebilir.
- Hadoop işleri. Yalnızca SQL değil Spark ya da Java mantığı da içeriyorsa birinci dalga Beam’e ya da BigQuery SQL’e yeniden yazım ister.
Sonuç notları (tasarım varsayımları, ölçüm değil)
Bu bir tasarım çalışmasıdır, tamamlanmış bir göç değildir. Çıktı: dört sayfalık diyagram seti, tek sayfalık beyaz tahta sürümü ve 16 sayfalık Türkçe PDF. Üç saatlik batch hedefi bir gereksinimdir; sonuç değildir.
Kaynaklar
- Mimari PDF (Türkçe, 16 sayfa).
- draw.io diyagramları (İngilizce etiketler): dört sayfalık set ve 30 dakikalık tek sayfa sürüm.
İlgili yazılar
Blog
Ay Sonu Kapanışını Kaçırmadan BigQuery'ye 60 TB'lık Göç
ahmetkalafat.com
Bu konudaki gerçek projeler
P—01
Tamamlandı
Öne çıkan
Kurumsal Veri Ambarının Google BigQuery'ye Taşınması
80 TB'lık ambar SQL Server ve 15 düğümlü Cloudera kümesinden BigQuery'ye taşındı: yıllık $550K tasarruf, %75 düşük altyapı maliyeti, 7 kat hızlı iş akışları.
Rol
Tasarım ve liderlik · Kıdemli Veri Mühendisliği ve Veri Mimarisi Grup Yöneticisi
P—08
Tamamlandı
Veri Yönetişimi, Metadata ve Ana Veri Yönetimi (MDM)
100+ kaynak sistem genelinde veri yönetişimi, metadata yönetimi ve ana veri yönetimi (MDM); veri kataloğu ve soy ağacı (lineage) araçlarıyla.
Rol
Uygulama · Büyük Veri Yönetimi ve Veri Mimarisi Yöneticisi