Delta Lake ile Güvenilir Veri Gölü: Kurulum, Yazma Desenleri ve Bakım

Delta Lake ve lakehouse neyi çözer?

Klasik veri gölü, bulut depolamadaki dosya yığınıdır: Ucuz ve esnektir, ama bir tabloda olması gereken güvenceleri vermez. Birden fazla iş aynı klasöre aynı anda yazarsa tamamlanmamış dosyalar görünür, başarısız bir yazma geride tutarsız veri bırakır, bir kaydı güncellemek için tüm dosyaları yeniden yazmak gerekir ve veriyi dünkü haline döndürmenin yolu yoktur.

Delta Lake, bu dosyaların üzerine bir işlem günlüğü (transaction log) ekleyen açık kaynaklı bir depolama katmanıdır. Veri Parquet dosyalarında kalır; hangi dosyaların tablonun güncel halini oluşturduğunu günlük söyler. Böylece göl, ACID işlem güvencesi, şema denetimi, güncelleme ve silme desteği ile zaman yolculuğu kazanır. Lakehouse mimarisi, bu katmanın üzerine hem toplu analitik hem akış verisi hem de makine öğrenmesi iş yüklerini aynı kopyadan besleyen yaklaşımdır: Ayrı bir veri ambarı kopyasına ihtiyaç azalır.

Kavramsal tanımlar için veri gölü ve lakehouse sözlük sayfaları ayrıdır; burada odak, bu mimarinin nasıl kurulup işletildiğidir.

Kurulum öncesi karar listesi

Tabloyu açmadan önce şu kararları netleştirmek sonradan yeniden yazmayı önler.

Kararlar şunlardır: • Depolama: Nesne depolama (bulut) üzerinde klasör hiyerarşisi. Ham, işlenmiş ve sunum alanlarını ayrı yollarda tutun. • Hesaplama motoru: Spark ile ya da Delta'yı destekleyen başka bir motorla. Mevcut ekibinizin bildiği motor, ilk adımı belirler. • Katalog ve erişim: Tabloların adlandırıldığı, sahiplerinin ve izinlerinin tutulduğu bir katalog. Yönetişim sonradan eklenmesi zor bir şeydir. • Açık tablo biçimi tercihi: Delta ile birlikte Apache Iceberg gibi açık tablo biçimleri de vardır. Hangi ekosistemle çalıştığınıza göre seçilir; birlikte çalışabilirlik önemliyse biçimler arası okuma desteği değerlendirilmelidir. • Bölümleme stratejisi: Sorguların çoğunun hangi sütunla filtrelendiği (çoğunlukla tarih). • Veri sözleşmesi: Kaynak sistemlerden beklenen şema, tazelik ve kalite kuralları.

Medallion mimarisi: bronze, silver, gold

Lakehouse'ta veri genellikle kalite katmanlarına ayrılır. Bronze katmanı kaynaktan gelen ham veriyi olduğu gibi ve eklemeli biçimde saklar; böylece gerektiğinde yeniden işleme imkânı olur. Silver katmanı temizlenmiş, tekilleştirilmiş, tipleri düzeltilmiş ve ilişkilendirilmiş veriyi içerir. Gold katmanı ise iş birimlerinin doğrudan kullanacağı özet tablolar, ölçü setleri ve model besleme tablolarını barındırır.

Bu ayrımın pratik değeri, hatanın yerini bulmakta yatar. Rapordaki rakam yanlışsa gold'dan silver'a, oradan bronze'a inip hatanın hangi dönüşümde oluştuğunu görebilirsiniz. Kaynakta sorun varsa bronze'u koruyup yalnızca aşağı katmanları yeniden hesaplarsınız.

Örneğin bir e-ticaret şirketi sipariş olaylarını bronze'a ham JSON olarak alır, silver'da müşteri ve ürün tablolarıyla ilişkilendirip mükerrer olayları temizler, gold'da günlük ve kategori bazlı satış özetini üretir. Her katman bir Delta tablosudur ve bir öncekinden okuyan bir iş tarafından beslenir.

Yazma desenleri: ekleme, MERGE ve şema yönetimi

Delta tabloya yazmanın temel kalıpları şunlardır. Eklemeli yazma (append) yeni veriyi mevcut tabloya katar; bronze için doğaldır. Üzerine yazma (overwrite) tabloyu ya da belirli bölümleri değiştirir. En güçlüsü MERGE işlemidir: Kaynak veri ile hedef tabloyu bir anahtarla eşleştirir; eşleşen satırı günceller, eşleşmeyeni ekler, istenirse silinmesi gerekeni siler (upsert).

MERGE, kaynak sistemde yapılan değişikliklerin (değişiklik verisi yakalama, CDC) lakehouse'a taşınmasının ana yoludur. Klasik bir veri gölünde bu iş tüm bölümü yeniden yazmayı gerektirirdi; Delta'da yalnızca etkilenen dosyalar yeniden yazılır. Önemli nokta, kaynak tarafta aynı anahtardan birden fazla satır varsa MERGE'in hata vereceği ya da belirsiz sonuç üreteceğidir; kaynağı önce tekilleştirin.

Şema yönetiminde Delta varsayılan olarak uyumsuz yazmaları reddeder (schema enforcement). Bilinçli olarak yeni sütun eklemek gerektiğinde şema evrimi (schema evolution) seçeneği açılır. Bu davranışlar birlikte, sessizce bozulan veri riskini azaltır. Yeni sütunların otomatik eklenmesini tüm katmanlarda açık bırakmak ise yanlış kaynağın şemayı kirletmesine yol açabilir; en azından silver ve gold'da kontrollü ilerleyin.

Zaman yolculuğu, kalite kısıtları ve veri güvenilirliği

Her yazma, işlem günlüğünde yeni bir sürüm oluşturur. Zaman yolculuğu (time travel), tabloyu belirli bir sürüm ya da zaman damgasıyla sorgulamanızı sağlar. Tipik kullanımları şunlardır: hatalı bir yazmayı geri almak, bir raporun geçen haftaki sayılarını yeniden üretmek ve sürümler arasındaki farkı denetlemek. Geçmişi görmek için tablo geçmişi komutu, kimin ne zaman hangi işlemi yaptığını listeler.

Kalite tarafında CHECK kısıtları ve NOT NULL tanımları, kurallara uymayan satırın yazmayı başarısız kılmasını sağlar. Örneğin tutarın negatif olamayacağını ya da sipariş tarihinin boş olamayacağını tablo düzeyinde tanımlarsanız, kötü veri aşağıya hiç akmaz. Daha esnek senaryoda hatalı kayıtlar ayrı bir karantina tablosuna yönlendirilip düzeltilmek üzere saklanır.

Eşzamanlı yazmalarda Delta iyimser eşzamanlılık denetimi kullanır; çakışan işlemlerden biri başarısız olursa yeniden denenir. Aynı bölümü değiştiren işleri programda ayrı zamanlara yaymak çakışmaları azaltır.

Performans ve bakım: OPTIMIZE, VACUUM ve veri düzeni

Sık küçük yazmalar çok sayıda küçük dosya üretir ve sorguları yavaşlatır. OPTIMIZE komutu küçük dosyaları daha büyük dosyalarda birleştirir; Z-order gibi veri düzenleme teknikleri, sık filtrelenen sütunlara göre benzer değerleri yakın dosyalara toplayarak okunan veri miktarını azaltır. Son yıllarda bu düzeni otomatik yöneten özellikler de ortaya çıkmıştır; kullandığınız platformda hangisinin mevcut olduğuna bakın.

VACUUM komutu, artık tablonun güncel sürümüne ait olmayan eski dosyaları fiziksel olarak siler. Bu, depolama maliyetini düşürür, ama silinen dosyalara dayanan zaman yolculuğu da ortadan kalkar. Saklama süresini iş gereksinimlerine ve denetim ihtiyacına göre bilinçli belirleyin; varsayılan değerin altına inmeden önce yazan ve okuyan uzun süren işleri kontrol edin.

Bakım işlerini düzenli çalışan bir iş olarak zamanlayın ve tablo büyüklüğü, dosya sayısı, ortalama dosya boyutu gibi göstergeleri izleyin. Bölümleme ölçütünü çok ince seçmek (yüksek kardinaliteli sütun) küçük dosya sorununu büyütür; çoğu zaman tarih düzeyinde bölümleme yeterlidir.

Akış ve toplu işlemenin birleşimi

Delta tabloları hem akış kaynağı hem akış hedefi olarak kullanılabilir. Bu, bronze'a gelen olayların akış işiyle silver'a taşınması, aynı silver tablonun ise ertesi sabah toplu bir işle gold'a özetlenmesi gibi karma mimariler kurmayı mümkün kılar. Ayrı akış ve toplu sistemleri yan yana çalıştıran eski mimarilerin karmaşıklığı böylece azalır.

Akış işlerinde kontrol noktası (checkpoint) konumunu sabit tutmak ve tablo şemasını gelişigüzel değiştirmemek gerekir; kontrol noktasını silmek akışın baştan başlamasına yol açar. Gecikmeye dayanıklı kullanım için işleme sıklığını iş ihtiyacına göre seçin: Gerçek zamanlı gerekmeyen raporlar için düzenli aralıklı tetiklenen işler hem daha ucuz hem daha basit olabilir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Delta Lake ile Güvenilir Veri Gölü eğitiminin modülleri bu sayfadaki başlıklarla örtüşür: Delta Lake Mimarisi ve İşlem Günlüğü, Yazma Desenleri ve MERGE İşlemleri, Zaman Yolculuğu, Kalite ve Kısıtlar, Performans Optimizasyonu, Akış ve Toplu İşlemenin Birleşimi ile Göl Evi Mimarisi, Bakım ve Bitirme Projesi.

Veri Lakehouse Mimarisi eğitimi ise daha geniş çerçeveyi ele alır: Veri Mimari Evrimi ve Lakehouse Kavramı, Delta Lake ile Güvenilir Veri Katmanı, Apache Iceberg ile Açık Tablo Formatı, Medallion Mimarisi, Akış Verisi ve Lakehouse Entegrasyonu, Sorgu Motoru ve Performans Optimizasyonu ile Veri Yönetişimi ve Güvenliği.