Great Expectations ile Veri Pipeline'ında Kalite Testleri Yazmak
Great Expectations, verinin beklentilerinizi karşılayıp karşılamadığını kod olarak yazıp otomatik denetlemenizi sağlayan bir Python kütüphanesidir. Sayfada temel bileşenler, ilk beklentinin yazımı, checkpoint ile doğrulama akışı ve sık yapılan hatalar anlatılır.
Bir bakışta
- Beklenti, verinin nasıl olması gerektiğine dair doğrulanabilir bir iddiadır. Great Expectations belgeleri bunu bir birim testindeki doğrulamaya benzetir.
- Beklentiler bir Expectation Suite içinde gruplanır ve belirli bir veri grubuna uygulanır. Hangi verinin hangi beklentilerle denetleneceği bir Validation Definition ile bağlanır.
- Üretimde doğrulamayı Checkpoint çalıştırır. Checkpoint, sonuç kaydı ve bildirim gibi işlemleri tetikleyebilir.
- Her şeyi test etmek yerine kritik varsayımları test etmek gerekir. Gürültülü bir beklenti listesi, gerçek sorunların gözden kaçmasına yol açar.
- Sonuçlar insan tarafından okunur hale getirilmeli ve sahibi olmalıdır. Data Docs gibi raporlar, kimsenin bakmadığı bir log değil, ekibin bildiği bir sinyal olmalıdır.
Pipeline'da veri kalitesi testi neden gerekir?
Bir veri pipeline'ı kod olarak çalışıyorsa hata vermeden de yanlış sonuç üretebilir. Kaynak sistem bir sütunun anlamını değiştirir, bir tablo eksik yüklenir, bir alan sessizce boş gelmeye başlar; pipeline hatasız tamamlanır ve bozuk veri raporlara, modellere ve kararlara ulaşır. Kod testi bunu yakalayamaz, çünkü sorun kodda değil veridedir.
Veri kalitesi testi bu açığı kapatır: verinin sahip olması gereken özellikler baştan yazılır ve her çalıştırmada denetlenir. Great Expectations bu yaklaşımı hazır bir çerçeveyle sunar. Belgeleri, beklentiyi bir birim testindeki doğrulamaya benzer biçimde tanımlar: veri, tanımlı bir iddiayı sağlıyor ya da sağlamıyor. Veri kalitesi kavramı için sözlük maddesine, kalite ile yönetişim farkı için karşılaştırma sayfasına bakılabilir; burada pipeline'a test yazmanın uygulaması anlatılıyor.
Temel bileşenler
Great Expectations'ın belgelerinde bir iş akışı şu bileşenlerden oluşur. Data Context, tüm yapılandırmaya, beklentilere ve sonuçlara erişim sağlayan Python nesnesidir; her akış onunla başlar. Data Source, verinin tutulduğu deposunun (veritabanı, bulut depolamadaki dosyalar) temsilidir; Data Asset ise o depodaki bir kayıt kümesidir, örneğin bir tablo ya da sorgu sonucu. Batch Definition, kayıtların hangi gruplara ayrılarak doğrulanacağını belirler. Expectation Suite, birlikte doğrulanan beklentiler grubudur ve farklı veri gruplarında yeniden kullanılabilir. Validation Definition, hangi veri grubunun hangi suite ile denetleneceğini bağlar. Checkpoint, üretimde doğrulamaları çalıştıran temel bileşendir. Sonuçlar Validation Results olarak döner ve Data Docs ile okunabilir hale getirilir.
Önce veriyi tanımla, sonra beklentiyi bağla, sonra çalıştır
Great Expectations bileşenleri
- Data ContextYapılandırma ve sonuçlara erişim noktası.
- Data Source ve AssetVerinin nerede olduğu ve hangi kümenin test edileceği.
- Expectation SuiteBeklentilerin toplandığı grup.
- Validation DefinitionVeri grubunu suite ile eşleştirir.
- CheckpointDoğrulamayı çalıştırır, işlem tetikler.
- Data DocsSonuçları insan okunur sunar.
İlk beklentiyi yazmak
Belgelere göre beklentiler gx.expectations modülündedir ve her biri bir sınıftır. Bir sipariş tablosunda sipariş numarası sütununun hiç boş olmamasını istediğinizi varsayın:
import great_expectations as gx
context = gx.get_context()
beklenti = gx.expectations.ExpectColumnValuesToNotBeNull( column="siparis_no" )
Bu beklenti bir Expectation Suite içine eklenir, suite bir Validation Definition ile veri grubuna bağlanır ve doğrulama çalıştırıldığında sonuç, beklentinin sağlanıp sağlanmadığını söyler. Beklentilerin sınıf adları ve parametreleri sürümlere göre değişebilir; kodu yazarken kullandığınız sürümün belgelerini esas alın. Belgelerdeki bir örnek, bir beklentiye önem düzeyi (severity) de verilebildiğini gösterir; örnekte bu 'warning' olarak ayarlanmıştır. Böylece her beklentiyi aynı ağırlıkta ele almak zorunda kalmazsınız.
Hangi beklentiler yazılmalı?
Tüm sütunlara mümkün olan her beklentiyi yazmak cazip görünür ama yanlış bir yoldur: kısa sürede gürültü üretir, ekip uyarılara alışır ve gerçek sorun gözden kaçar. Daha iyi bir yöntem, veri kullanıcılarının bağımlı olduğu varsayımlardan başlamaktır:
- Tamlık: Anahtar ve zorunlu alanlar boş değil, beklenen tablolar boş gelmiyor.
- Benzersizlik: Tanımlayıcılar tekrar etmiyor.
- Geçerli aralık ve küme: Tutarlar ve tarihler makul aralıkta, durum alanı bilinen değerlerden biri.
- Şema: Beklenen sütunlar var, türleri tutarlı.
- Tazelik: Veri beklenen zamanda geldi.
Beklenti kataloğunda bu tür kontroller için hazır beklentiler bulunur; kesin ad ve parametreler için sürüm belgesine bakın. Beklenti eşiklerini tahminle değil, verinin gerçek davranışına ve iş kuralına dayanarak belirleyin. Verinin profilinden otomatik beklenti üretmek başlangıç için yararlıdır ama üretilen listeyi körü körüne kabul etmek, verideki mevcut hataları da 'normal' ilan etmek anlamına gelebilir.
Kurgusal bir sipariş tablosu için kısa bir başlangıç listesi şöyle olabilir: sipariş numarası boş olamaz ve benzersizdir, sipariş tarihi boş olamaz ve gelecekte olamaz, durum alanı bilinen değerlerden biridir, tutar negatif olamaz, tablo beklenen zamanda yenilenmiştir. Birkaç beklenti bile, sessiz bozulmaların büyük bir bölümünü erken yakalar. Daha sonra ortaya çıkan her gerçek veri sorunu için yeni bir beklenti eklemek, listeyi gerçek olaylarla büyütür ve gereksiz kuralları dışarıda tutar.
Pipeline'a yerleştirmek ve başarısızlığı yönetmek
Doğrulama, pipeline'da veri kritik bir adıma geçmeden önce çalıştırılır: kaynaktan yüklemeden sonra, dönüşümden önce ve tüketicilere sunulmadan önce uygun noktalar seçilir. Doğrulamayı Checkpoint çalıştırır; belgelere göre checkpoint ortak parametrelerle bir doğrulama listesini yürütür ve sonuçlara göre işlem tetikleyebilir. Orkestrasyon aracı (örneğin Airflow) bu çağrıyı bir görev olarak çalıştırır.
Asıl karar, doğrulama başarısız olduğunda ne olacağıdır. Her başarısızlık pipeline'ı durdurmak zorunda değildir. Ölçüt, kusurun tüketicide yaratacağı zarardır.
Başarısızlığın ağırlığı, tepkiyi belirler
- Kritik beklenti bozuldu (anahtar alan boş, tablo eksik)Akışı durdur ve sorumluya haber verBozuk veri tüketiciye ulaşmamalı.
- Önem düzeyi uyarı olan beklenti bozulduAkışı sürdür, uyarı gönderEğilim izlenir, tekrar ederse seviye yükseltilir.
- Yalnız bazı kayıtlar kuralı bozuyorKayıtları ayır (karantina) ve geri kalanı işleKarantina kayıtlarının sahibi ve incelemesi olmalı.
Sonuçları okunur kılmak ve sık hatalar
Doğrulama sonuçları yalnız bir log satırı olarak kalırsa işe yaramaz. Data Docs, beklentileri ve sonuçları insan okunur bir sitede toplar; checkpoint ve işlemler bunu otomatik güncelleyebilir. Önemli olan, bir başarısızlıkta kimin ne yapacağının önceden belli olmasıdır: kalite sorunlarının sahibi ve ilk müdahale adımı yazılı olmalıdır.
Sık hatalar şunlardır: çok fazla beklenti yazıp uyarı yorgunluğu yaratmak, eşikleri veriye bakmadan belirlemek, otomatik üretilen beklentileri gözden geçirmemek, başarısızlık kararını (durdur ya da devam et) belirlememek ve beklentileri kodla birlikte sürüm kontrolüne koymamak. Kütüphanenin arayüzü sürümlere göre değiştiği için, örnekleri kopyalarken kendi sürümünüzün belgelerini kontrol edin.
Bu beceriyi Mindset programlarında nerede çalışırsınız
Veri kalitesi testi, veri mühendislerinin ve analitik mühendislerinin pipeline güvenilirliği için kullandığı bir beceridir. Mindset kataloğunda Great Expectations ile Veri Kalitesi Testi programı veri kalitesi testi modelini, beklenti tasarımı ve kural yazımını, profilleme ile beklenti üretimini, kontrol noktaları ve doğrulama akışını, özel beklentileri ve entegrasyonları ve raporlama ile yönetişimi bir bitirme projesiyle işler. Veri Mühendisliği Temelleri programı ise veri kalitesi ve gözlemlenebilirliği pipeline tasarımı, depolama ve SQL ile birlikte daha geniş bir çerçevede ele alır.
İlgili Mindset programı
Great Expectations ile Veri Kalitesi Testi
Sık sorulan sorular
Great Expectations yerine veritabanı kısıtları yeterli olmaz mı?
Kısıtlar (boş olamaz, benzersiz) veritabanına yazarken uygulanır ve yararlıdır. Great Expectations ise kaynağı farklı olan, dosya ya da veri ambarı gibi yerlerdeki veriyi de iş kurallarına göre denetler; dağılım, tazelik, tablolar arası tutarlılık gibi kuralları ifade eder. İkisi birbirini tamamlar.
Expectation Suite nedir?
Birlikte doğrulanan beklentilerin grubudur. Aynı veri için birden fazla suite oluşturabilir ya da bir suite'i farklı veri gruplarında yeniden kullanabilirsiniz. Hangi suite'in hangi veri grubuna uygulanacağı bir Validation Definition ile bağlanır.
Checkpoint'in rolü nedir?
Checkpoint, doğrulamaları üretimde çalıştıran temel bileşendir. Bir doğrulama listesini ortak parametrelerle yürütür ve sonuçlara göre işlemler, örneğin bildirim ya da Data Docs güncellemesi tetikleyebilir. Pipeline'ınızdaki orkestrasyon görevi genellikle checkpoint'i çağırır.
Otomatik üretilen beklentilere güvenebilir miyim?
Başlangıç için yararlıdır ama doğrudan üretime almayın. Veri profilinden çıkan beklentiler verinin bugünkü halini yansıtır; içinde mevcut hatalar da olabilir. Her beklentiyi iş kuralıyla karşılaştırıp gözden geçirin.
Yalnız veri mühendisleri mi kullanır?
En çok onlar kullanır ama veri analistleri ve analitik mühendisleri de kritik raporların girdi verisini denetlemek için kullanabilir. Beklentileri iş birimiyle birlikte tanımlamak, kuralların gerçekten iş anlamına uymasını sağlar.
İlgili rehberler
İlgili eğitimler
Kategori: Veri Mühendisliği ve MLOps