DWH’da Veri Bütünlüğü Veri Temizliği

 

DWH’da Veri Bütünlüğü Veri Temizliği

Veri bütünlüğü tüm ortamlarda olduğu gibi DWH’da da en önemli konulardan bir tanesi.Veri bütünlüğünü şöyle özetleyebiliriz müşteri tablosunda olmayan bir müşteriye ait satış olmamalıdır.Biz genelde dimensional modellemede(kimball) inmon modelleme kadar özen göstermeyebiliyoruz veri bütünlüğüne ama bizde de elbette sorunlara yol açabiliyor.

Normalde kaynak sistemlerimizin normalize edilmesini ve bütünlüğün FK’larla sağlanmasını bekliyoruz.Fakat bu her zaman istenildiği ölçüde başarılı olmayabiliyor.Özellikle eski sistemlerde bu çok başımıza gelebiliyor.Bu durumda yapmamız gereken ilk şey kaynak sistemde bu sorunları düzeltmek olmalı.Çünkü software ve data engineer olarak ayrılsakda bu bir bütün meselesi ve söz konusu olan iş dağılımı değil şirketin bütünlüğü.Dolayısıyla testlerinizde böyle bir örnek ile karşılaştınız veya iş biriminiz fark ettiğinde,sorunu kendi tarafınızda çözmeye çalışmaktansa kaynak sistemdeki arkadaşlarla görüşüp datayı orada düzenletirseniz sizin süreciniz dışındada bu datayla bir şekilde ilgilenen olursa onlar için de bu sorunu düzeltmiş olursunuz.

Fakat diyelim ki dokunulamıyor kaynak sisteme bu durumda ne yapacağız?Bu durumda sorunun sizin pipeline’lardan kaynaklanmadığını göstermek için “Tanımsız Kayıt” veya “Kaynakda Bulunamadı” gibi bir tanımlama ile bu sorunlu kayıtları göstermeniz lazım.Bunun içinde yapmanız gereken şey aslında çok basit.Fact’inizi doldururken ilgili FK’ları dolduracağınız pipeline’da BI katmanında joinleneceği dimension ile pipeline’da joinleyip varlık yokluk kontrolüne koyduktan sonra yok ise -1 var ise ilgili id’yi basabilirsiniz.Peki bu -1 neyi ifade edecek?Bu -1,dimension tablosuna öncesinde -1 idli,”Tanımsız Kayıt” açıklamalı eklediğiniz satır ile eşleşecek ve BI tarafında kullanıcılar Tanımsız Kayıt görecekler.Böylelikle sorunlu kayıtları hemen fark edebilecekler.Kaynak sistemde kayıtları düzeltebiliyorsanız dahi böyle bir mekanizma kurmanız hatalı kayıtları tespitini çok kolaylaştıracaktır.Tek sorun pipeline süresi uzayacaktır bence varsın uzasın veri bütünlüğü çok önemli bir konu çünkü.

Bir diğer önemli konu asla ama asla veri filtrelemeyin!.Bu çok canınızı sıkacak bir konudur.Örneğin bir log tablonuz var sizden xxxxx tipindeki işlemler istendi sadece,sizde ODS’e bu şekilde aldınız haliyle fact tablonuzada direkt ODS’den çıktınız.Fakat sonrasında yyyyy tipindeki işlemlerde istendi.Bu durumda ODS’e bunu aldınız fakat fact’iniz bu sefer başka tipdeki işlemleri göstermeye başladı.O yüzden muhakkak ODS’e full almaya çalışın veya bunu kullanan factlerinizde yarını düşünerek uygun filtrenizi verin.Bir diğer konu ODS full aldınız ama fact’e sadece belirli bir kısmı aldınız.Bu durumda diğerlerini istediğinizde tekrar çalışmanız gerekir.Peki son kullanıcı sadece durumu xxx olanları istiyor bu durumda ne yapmalıyız?Siz full çıkın kullanıcı için filtre koyun filtrelisiniz kendisi.Bunu yapamayız C level için yaptık,bu durumda yine fact’i full çıkın rapor veya dashboardda filtreleyin ama factiniz hala full olsun.

DWH’da en önemli konulardan bir tanesi granularity.Yani en dip seviyede veri vermeye çalışmalıyız.Çünkü yine aynı sebepten kesinlikle yarın detay seviyesi sorulacak ve size ek çalışma masrafı çıkacak.O yüzden en dip seviyede verin zaten BI toolunda aggregate olacak.Performans sorunu yaşarsanız en dip seviyedeki fact’inizden aggregate fact tablo çıkabilirsiniz.

 

Peki veri temizliği konularında ne yapabiliriz?

Burada o kadar fazla case karşınıza çıkacak ki herbiri birbirinden farklı olabilir.Fakat şunu söyleyebiliriz burada yine kaynakda işi çözdürmeye özen gösterin bu sizin için olduğu kadar onlar içinde çok değerli olacaktır.

Örnek verelim hemen.Mesela diyelim ki CRM uygulamanızın bir tablosu var müşteriye yapılan işlemleri tutuyor.Sizden işlem tipi bazında her gün kaç işlem yapıldı kaç farklı müşteriye yapıldı gibi bir rapor isteniyor.Fakat tablonuzda işlem tipi yok 😊İşlem tipi açıklama sütununda belirli bir prefix ile free text tutulmuş.Aşağıdaki örneklerde olduğu gibi.

Limit Değişikliği:Müşteri istedi değiştirdik.

İlan Hakkı Değişikliği:Müşteri ek istedi verdik.

Böyle bir tabloda belirli bir prefix ve sonrası free text verilmiş ya da daha kötüsü hiç prefix yok direkt açıklama içinde kuralsız yazılmış.Bu durumda açıklama alanını parçalayıp kendiniz bir işlem tipi alanı yaratabilirsiniz ama yarın kurala uymayan bir tip gelebilir ve sizin kuralınız işlemeyebilir.Bu yüzden kesinlikle kaynak sistemde böyle bir alan açılmasını istemelisiniz.

Free text bir alandan içinde xxxx veya yyyy gibi değerler aratacak şeklinde bir kural işleteceksiniz, öncesinde muhakkak lower veya upper fonksiyonları ile tüm yazıyı düzenleyin case sensitiveden gol yiyebilirsiniz.

 Diyelimki bu açıklama alanından işlemtipini ayırabildiniz bu bir fact tablo olduğu için kesinlikle text bir alan bırakmamalısınız.Bu durumda öncesinde bir lookup tablo yaratmanız gerekir.Lookup tablolar kaynakdan gelmeyen sizin oluşturduğunuz id ve açıklama barındıran tablolardır.Hangi işlem tipine hangi id’nin geleceği belli olduktan sonra artık fact tablonuzdaki işlemtipi_key sütununa bu lookup tablosundaki id’i basmanız gerekir.

Bunu yapmamızın çok önemli iki sebebi var.Birincisi text alanlar fact üzerinde çok ciddi yer kaplıyorlar.İkincisi İşlemtipini lookupdan almazsanız fact üzerinden almak zorunda kalırsınız bu da sadece işlemi olan işlemtiplerini getirmenizi sağlar.Fakat son kullanıcı tüm işlem tiplerini görmek ister yani işlemi yok ise xxx işlemtipinden 0 adet işlem var görmek ister.Ayrıca BI toolunuzdaki filtrelenizdede factten veri getirdiğinizde çok yavaş açılacaktır.

Örnekler çoğaltılabilir.Bir diğer konu artık JSON’ların hayatımızda çok fazla yer alması.JSON’lardan verileri çıkarmak istediğinizde ona bir text gibi davranıp text fonksiyonları ile örneğin SUBSTRING,LEFT vb kullanıp kesinlikle istediğiniz değeri dışarı almayın.JSON sütunlar tercih edilmesinin sebebi yeni bir sütunun hemen eklenebilmesidir.2 hafta doğru çalışan kodunuz bir günde çalışamaz olabilir çünkü siz statik bir kod yazmış oldunuz.JSON fonksiyonlar kullanarak key value ilişkisinden scalar değeri döndürün muhakkak.Ayrıca kesinlikle tüm sütunları çıkarmaya çalışmayın lazım oldukça alırsınız çoğunu hiç bir zaman kullanmayacaksanız.JSON için yazdığım bir yazım vardı blog ve linkedin profilimden görebilirsiniz.

Yine bir örnek daha verelim, telefon veya tc no sütunu free text girilmiş.Bu sütunlar belirli bir pattern’i takip ettiği için düzenlememiz hala bir nebze kolay.Öncelikle tüm verilerimizi aynı formatta vermemiz çok önemli o yüzden şu şekil bir telefon formatı vermemlisiniz son kullanıcıya.

+905555555555

05555555555

5555555555

0555 555 55 55

Çünkü son kullanıcı böyle bir bilgi alacaksa muhakkak sonrasında bir işlem yapacaktır ve bu durumda onun otomatize etmeye çalıştığı yapıya zarar verecektir.Bu yüzden iş birimleri ile el sıkıştığınız bir formata karar verip tüm gelen datalar için bu formata uyacak şekilde düzenlemeniz gerekir.Elbette söylemeye gerek yok kaynakta düzenletebilirseniz ne mutlu 😊

 

Açıkçası ne kadar örnek versek az kalacak veri temizliği özelinde, o yüzden veriye bunun kaynakda mı düzenlemesi lazım, benim tarafımda mı diye baktıktan sonra bu işlemleri yapmanız en doğrusu olacaktır.

 

Umarım faydalı olmuştur,sonraki yazılarda görüşmek üzere😊