İlk çalıştırma genellikle iyi geçer. Kaynak seçilir, alanlar eşlenir, hedef yol verilir, satırlar gelir ve analitik ekibi memnun olur.
Zorluk ikinci ayda başlar. SAP tarafında bir alan uzar, yeni bir kolon eklenir, bir tipin ondalık hassasiyeti değişir. Hedefteki şema bu değişiklikleri kendiliğinden takip etmez ve bir süre hiçbir hata da görünmez.
Birikim şöyle işler: ilk ay bir alan, üçüncü ay üç alan, altıncı ay tam listesini kimsenin bilmediği bir fark. Kaybın görüldüğü yer de aktarım ekranı değil, raporda tutmayan bir toplam olur.
Parquet hedefinde şema tek bir dosyadan okunuyor
SAP kaynağından Fabric hedefine giden aktarım, hedef bağlantısı Fabric olan bir SQL Transfer projesi olarak tanımlanır. Kaynak alanlar seçilip hedef şemayla eşlenir; veri, analitik iş yüklerine uygun Delta/Parquet yapısında oluşur. Hedef yol, lakehouse altındaki tablo dizini olarak çözülür ve aynı bağlantı üzerinden mevcut tablo klasörleri listelenebilir.
Burada bilinmesi gereken mekanizma şu: hedef tablonun şeması ilk aktif Parquet dosyasının üst verisinden okunur. Dosyalar arasında şema farkı oluştuysa bu okuma tüm varyasyonları temsil etmeyebilir. Yani “şema doğru görünüyor” cümlesi, bütün dosyaların aynı şemada olduğunu kanıtlamaz.
Satır sayısını Delta günlüğünden almak
Doğrulamanın en pratik adımı satır sayımıdır. Satır sayısı önce Delta günlüğündeki kayıt bilgisinden alınır, gerektiğinde Parquet dosyalarının üst verisine düşülür; yani hedefte kaç kayıt olduğunu anlamak için tüm dosyaları taramak gerekmez. Bu sayıyı her çalıştırmadan sonra kaynak tarafında beklediğiniz satır sayısıyla karşılaştırmak, sessiz kayıpları erken gösterir.
Küçük kapsamlı bir test çalışması tip dönüşümlerini ve satır sayısını doğrulamak için yeterlidir. Hedef yolda varlık kontrolü, oluşturma ve temizleme işlemleri de aynı servis üzerinden yürür; mevcut uygulamada temizleme, yolun içeriğini silme davranışına yakındır, bu yüzden onu rutin bir bakım adımı gibi kullanmayın.
Şema kayması için üç alışkanlık
Şema kaymasını yönetmenin yolu otomasyon değil, düzen. Üç alışkanlık yeterli oluyor:
- Kaynak ile hedef arasındaki alan farklarını düzenli kontrol edin; SQL proje tarafında bu karşılaştırma yapılabilir.
- Yeni alan eklendiğinde eşlemeyi güncelleyin ve o alanı kullanan analitik modelleri gözden geçirin.
- Tip değişikliklerini önce küçük bir çalışmayla deneyin; mevcut dosyalarla uyumsuz bir tip, hatayı yazma anında değil okuma anında gösterebilir.
Beklentiyi doğru kurmak için iki not. Bu akış değişiklik yakalama değildir; tanımladığınız yükleme yöntemi ve zamanlamayla çalışır. Paketlerin hedefe yazılması ayrı bir servis bileşenine bağlıdır ve sonuç, bulut tarafındaki izinler ile depolama davranışına da bağlıdır. Bir çalışmanın “başarılı” görünmesi, veri tüketicisinin dosyayı okuyabildiğini kanıtlamaz.
Bunu bir gözden geçirme olarak öneriyoruz: Lakehouse’a yazdığınız tablolardan birini seçip kaynaktaki alan tanımlarıyla satır satır karşılaştıralım. İkinci ayda sessizce kayan şemayı bulmanın yolu bu karşılaştırmadan geçiyor; analitik ekibin ilk sorgusunu görmeden akışı tamamlanmış saymayın.