Artımlı yükleme (incremental load) ve watermark kurgusu

Artımlı yükleme neden gerekir?

Tam yükleme (full load) her çalışmada kaynaktaki tüm veriyi hedefe yeniden taşır. Küçük tablolarda basit ve güvenlidir, ama tablo büyüdükçe süre, kaynak sistemdeki yük ve maliyet artar. Artımlı yüklemede ise yalnızca son çalışmadan beri eklenen ya da değişen kayıtlar taşınır.

Bu yaklaşımın bedeli tasarım karmaşıklığıdır: hangi kaydın yeni olduğunu, hangisinin güncellendiğini ve hangisinin silindiğini güvenilir biçimde bilmeniz gerekir. Bu bilgiyi sağlayan mekanizmanın en yaygın biçimi watermark, yani "en son nereye kadar yükledim" işaretidir.

Watermark nedir ve hangi kolon seçilir?

Watermark, son başarılı yüklemede işlenen en büyük değeri saklayan bir kayıttır. Bir sonraki çalışma bu değerden büyük kayıtları ister. Seçilen kolon, değişen her kayıtta yenilenmeli ve güvenilir biçimde artmalıdır.

İyi adaylar: güncelleme zaman damgası (updated_at gibi), tek yönlü artan bir kimlik ya da kaynak sistemin sürüm numarası. Riskli adaylar: oluşturma tarihi (güncellemeleri kaçırır), uygulama tarafından elle girilen tarihler, saat dilimi karışıklığı olan alanlar ve her zaman güncellenmeyen kolonlar.

Kritik nokta: kolonu uygulama mı, veritabanı mı güncelliyor? Bir toplu güncelleme betiği updated_at alanını dokunmadan değiştiriyorsa artımlı yükleme o değişikliği hiç görmez. Watermark tasarımına başlamadan önce kaynağın bu davranışı doğrulanmalıdır.

Temel akış: watermark, çek, yaz, ilerlet

Tipik akış şöyledir:

• Watermark tablosundan son değeri oku.
• Kaynaktan bu değerden büyük kayıtları çek.
• Hedefe yaz (ekleme veya birleştirme).
• Yazma başarılı olduktan sonra watermark'ı ilerlet.

Son adımın sırası önemlidir. Watermark yazma başarılı olmadan ilerletilirse, arada hata olursa kayıtlar sonsuza kadar kaybolur. Yazma başarılı ama watermark güncellemesi başarısızsa bir sonraki çalışma aynı kayıtları tekrar çeker; bu yüzden yazmanın tekrar çalıştırılabilir (idempotent) olması gerekir.

Basit bir sorgu örneği:

SELECT * FROM siparisler WHERE guncelleme_zamani > :son_watermark AND guncelleme_zamani <= :bu_calisma_ust_siniri

Üst sınır tanımlamak, çalışma sırasında gelen kayıtların yarım okunmasını önler. Bir sonraki watermark bu üst sınır olur.

Hedefe yazma: ekleme mi, birleştirme mi?

Kaynak yalnızca yeni kayıt ekliyorsa (olay günlüğü, işlem hareketi gibi) hedefe doğrudan ekleme yeterlidir. Kayıtlar güncelleniyorsa upsert gerekir: anahtar eşleşirse güncelle, eşleşmezse ekle. Birçok veritabanında bu işlem MERGE komutuyla yapılır.

Bu kurgu için iş anahtarının (business key) net olması şarttır. Anahtar tekil değilse birleştirme yinelenen kayıt üretir ya da yanlış satırı ezer. Ayrıca kaynak kayıtlarını doğrudan hedef tabloya birleştirmek yerine önce bir hazırlık (staging) tablosuna yazıp oradan MERGE etmek, hata ayıklamayı ve yeniden çalıştırmayı kolaylaştırır.

Boyut tablolarında geçmiş değişiklikleri korumak gerekiyorsa yavaş değişen boyut (SCD) yaklaşımı eklenir; bu, artımlı yüklemenin üstüne kurulan ayrı bir tasarım kararıdır.

Silinen kayıtlar ve geç gelen veri

Watermark yaklaşımının zayıf noktası silmelerdir: kaynakta silinen bir satır güncelleme zaman damgası taşımaz, dolayısıyla artımlı sorguda görünmez. Çözümler: kaynakta yumuşak silme (is_deleted gibi bir işaret) kullanmak, silinen anahtarları ayrı bir tabloda tutmak, kaynak sistemin değişiklik yakalama (CDC) mekanizmasından yararlanmak ya da periyodik olarak anahtar listesini karşılaştırmak.

Geç gelen veri ise başka bir sorundur. Bir kayıt, watermark'ın geçtiği bir zaman damgasıyla sonradan görünürse (uzun bir işlemin geç commit etmesi gibi) kaçırılır. Bunu önlemek için watermark'tan bir güvenlik payı geriye gidilerek çekim yapılır, tekrar gelen kayıtlar upsert ile zararsız hale getirilir. Böylece yeniden çalıştırılabilirlik hem güvenlik payını hem de hataları kapatır.

Örnek senaryo: sipariş tablosunun günlük yüklemesi

Örneğin e-ticaret şirketinin sipariş tablosu kaynak veritabanında bulunuyor ve veri ambarına her gece taşınıyor. Tam yükleme artık uzun sürdüğü için artımlı yükleme tasarlanıyor.

Ekip önce güncelleme zaman damgası kolonunu inceliyor ve iade işlemlerinin bu kolonu güncellemediğini fark ediyor. Sorunu kaynak ekiple çözüyor, tetikleyici ekleniyor. Ardından akış kuruluyor: watermark tablosu okunuyor, değişen siparişler hazırlık tablosuna yazılıyor, sipariş numarası anahtarıyla hedef tabloya birleştiriliyor, sonra watermark ilerletiliyor. Silinen siparişler için kaynakta iptal durumu işaretleniyor ve hedefte de aynı durum taşınıyor. Her gece bir kontrol sorgusu kaynak ve hedef kayıt sayılarını karşılaştırıyor. Fark çıkarsa uyarı gidiyor.

Sık yapılan hatalar ve kontrol listesi

• Güvenilmez watermark kolonu seçmek: Güncellemeleri yansıtmayan alanlar sessiz veri kaybına yol açar.
• Watermark'ı yazmadan önce ilerletmek: Hata durumunda veri atlanır.
• Çalıştırmanın tekrarlanabilir olmaması: Yeniden çalıştırma yinelenen kayıt üretmemeli.
• Silmeleri unutmak: Hedef zamanla kaynaktan sapar.
• Saat dilimi ve ondalık saniye farklarını ihmal etmek: Sınırdaki kayıtlar kaybolur ya da çiftlenir.
• Hiç uzlaştırma yapmamak: Periyodik sayım ve toplam karşılaştırması yapılmayan artımlı yükleme zamanla sessizce bozulur.
• Tam yüklemeye dönüş planı olmamak: Sorun durumunda hedefi sıfırdan kurabilmek gerekir.

Kontrol listesi olarak şu soruları sorun: kaynağın değişiklik kolonu güvenilir mi, yazma tekrar çalıştırılabilir mi, silmeler nasıl yakalanıyor, geç gelen veri için pay var mı, hata durumunda watermark nerede duruyor, uzlaştırma kontrolü var mı?

Mindset programlarında nerede çalışılır?

ETL Süreçleri Temelleri eğitiminin modülleri Extract (veri çekme), Transform (dönüştürme) ve Load (veri yükleme) aşamalarını, ETL performansı ve ölçeklendirmeyi, araç ve platformları ve ETL proje yönetimi ile doğrulamayı kapsar. Veri Mühendisliği Temelleri eğitimi ise veri depolama mimarileri, veri pipeline tasarımı, SQL ve veri sorgulama, entegrasyon araçları, veri kalitesi ve gözlemlenebilirliği içerir.

Bu içerikler, kurumsal veri ambarı ya da raporlama altyapısını kuran veri mühendisleri, BI geliştiricileri ve analitik ekipleri için uygundur. Ekipler tablo bazında yükleme stratejisini ortak bir yöntemle belirlemek istediğinde bu temel kavramlar işe yarar.