Data Quality
Business Intelligence projelerini fazlandırırsak sanırım yönetim seviyesinin en bilmediği fakat BI developerların en çok zaman harcadığı ve hakikaten kimi durumlarda mühendislik yaptığı kısmın data warehouse oluşturulduğu bölüm olduğunu söyleyebiliriz. ETL süreçleri ile yönlendirilen Data Warehouse bölümü aslında tamamen Business Intelligence projelerinin icebergin su altında kalan kısmı gibidir. Kimse görmez kimse bilmez. Görülen kısım Reporting Services ve Analysis Services gibi kısımlardır aslında.
Fakat bir Business Intelligence projesinin sürdürülebilirlik düzeyinin belki de en büyük göstergesi ETL süreçleridir. İki BI projesi ele alalım bunlardan ilki ETL sürecini olabildiğince çabuk ve verimsiz geçirmiş olsun. Fakat üst faza baktığımızda proje tıkır tıkır çalışıyor. Üç yıl sonrasına gidelim. Şirketimizin sürecinde küçük bir değişiklik oldu ve bunu bizim raporlamamız talep edildi. Sırasıyla Reporting Services’te değişiklik, OLAP küplerinde değişiklik ve ETL paketlerinde değişiklik yapmamız gerekecek. Öte yandan aslında birçok hesaplanmış alanı ETL fazında gerçekleştirmemiz gerekirken reporting service üzerinde gerçekleştirdiğimiz için ilk başta daha az adam/saat maliyeti ile karşımıza çıkan proje sürdürülebilirliği sağlamak adına astarı yüzünden pahalıya gelecek.
Bu icebergin altındaki bir sorundu. Günümüzde ise aslında hep varolan ama şimdilerde daha da önem kazanan bir sorun karşımıza çıktı. Veri Kalitesi. Günü kurtarmak adına es geçilen kurallar, developerların joinli sorgulama maliyetlerinden kaçınarak yaptıkları (açtıkları) kara noktalar, birçok uygulamanın aynı datayı (kişisel bilgiler gibi) kendi içlerinde farklı formatta tutması ve bunun gibi birçok sorundan dolayı Business Intelligence projeleri geliştirilip ilk yayınlarına çıktıktan sonra şirketlerin mevcut süreçlerini denetleyen yapılar gibi davranmaya başladılar. Çünkü veri manipulasyonu olmayan BI projelerinde kimi durumlarda eksik süreç veya eksik veriler kaba tabirle kabak gibi ortaya çıkmakta. Hal böyle olunca dön başa iş süreçlerini değiştir, yazılımlarını güncelle gibi aslında tekrar bir süreç değişikliğine gidilmekte. Bunların genelde en ama en temel sebebi ise veri kalitesi. BI projelerinde yaşanan sıkıntıların başında aslında developerların kimi zaman günü kurtarmak adına yaptıkları free text alanlar gelmekte. İnsan müdahalesine en açık olan bu alanlar hesaplamada ciddi sıkıntı yaratıyor.
Bu sebeple şirketlerde genelde BI projeleri belirli bir olgunluğa geldikten ve aslında insanlar verilerden yaka silkmeye başladıktan sonra Data Quality projeleri işin içine girmeye başlıyor. BI projelerinin temel prensibi Single Version Of Truth. Michael Sharpe’nin Temmuz 2011 de Information Week için kaleme aldığı Mastering Data Integration isimli raporda bilgi yönetimi projelerinin başarısızlık nedenlerinden bahsetmiştir. Raporda yapılan araştırmaya göre karşılaşılan en büyük engeller sıralamasında birinci sırada doğru ve güvenilir veriye ulaşma problemi karşımıza çıkmaktadır. Günü kurtarmak için geliştirilen modüller bir süre sonra şirketin süreçlerinde kemikleşmeye başlamaktadır. Genelde zihniyet “çalışıyorsa dokunma” veya zaten bu şu anda çalışıyor yapmamız gereken diğer acil durumlara eğilelim sonrasında bakarız tarzında olunca o günü kurtaran modül yıllar sonra dahi sıkıntı yaratsa ve ihtiyaçları karşılayamaz hale gelse de yaşamına devam etmektedir. Onun üzerine geliştirilecek modullerde de developer çeşitli sebeplerden dolayı (aciliyet, mevcut yapıyı anlayamama, mevcut yapının tekrar geliştirilebilmeye açık olmaması vs.) yeni kısımlar açarak yoluna devam edince karşımıza iki büyük sıkıntı çıkmaktadır. 1) Verilerin tekil olmaması 2)Know how eksikliği.
Aynı raporda ikinci madde ise dataların entegre edilememesi sıkıntısı. Bu özellikle çok uluslu şirketlerde karşımıza sıklıkla çıkan bir yapıdır. Şöyle ki her bir süreç için farklı veri tipleri farklı teknolojiler kullanıldığında bunların entegrasyonu ciddi maliyet yaratabilmektedir. Örneğin finans verilerinizin SAP, satış bilgilerinizin Siebel, web bilgilerinizin Omniture, Operasyon bilgilerinizin Oracle, malzeme yönetim bilgilerinizin şirket içerisindeki SQL Server, küçük anlık uygulamalarınızın SQL Azure, CRM bilgilerinizin Salesforce, mail bilgilerinizin postgresql, en büyük partnerınızın bilgilerinin ise DB2 üzerinde tutulduğunu düşünün. Bunlarda aslında birçok platformda birbirinin eşleniği (userID, Transaction ID vb.) bilgiler var. Fakat entegrasyon çözümleri bu gibi durumlarda ciddi maliyet yaratmakta. Neden böyle bir yapıya gidildiği ise bu yazının konusu değil. Fakat yukarıdaki senaryoda da aslında en büyük sıkıntı kaliteli veri Çünkü her platformda da aynı bilgiler yer alsa dahi farklı tipte saklanabiliyor olabilir. Bir müşteri bilgisi düşünün. Bir veritabanında CustomerID, bir veritabanında email, başkasında T.C. Kimlik no ile tekilleştirilmeye çalışılıyorsa burada veri kaybı olabilir veya kaliteli veri elde etmenin maliyeti yüksek olabilir. Rapordaki üçüncü başarısızlık nedeni de verilerin temizliği ve tekilleştirilmesi. Başka bir bölümde ise BI projelerine giriş bariyerleri ile ilgili araştırma yapılmış ve karşımıza en yüksek oranda sıkıntının Data Qualify Problemleri olduğu çıkıyor. Sıfırdan bir proje geliştirmek yerine evcut projeyi güncellemek genellikle daha büyük sorun çıkartır başımıza ve veri kalitesi ile ilgili projeler her zaman ikinci senaryoda karşımıza çıkan durumlar. Herşeyi bir kenara bırakın ve aslında her şirketin aldığı iletişim bilgileri formunu bir düşünün. Sadece bir alan üzerine yoğunlaşmanızı istiyorum. Karşımıza text box olarak çıkartılan telefon numarası alanının ne kadar farklı şekilde kullanıcı tarafından giriş yapılacağını hayal edin. Bu alan üzerinde bir hesaplama yapmak dahi kimi zaman bizler için bir kabusa dönüşebiliyor.
Yazılım geliştirilirken genellikle gözardı edilen verilerin düzgün formatta gelmesi sonrasında başımıza iş açmasının ötesinde artık ciddi bir iş alanı oldu. 2011 sonunda 950 milyon dolarlık bir iş hacmine ulaşan Data Quality sektöründeki öncü firmalar ise aşağıdaki gibidir.
Peki herhangi bir üçüncü parti ürün alınmadan veri kalitesi ile ilgili bir çalışma SQL Server üzerinde yapılamıyor mu?
SQL Server’ın aslında bir süredir hayatımızda olan ürünü Data Quality Services tam olarak bu işe yarıyor. Elbette daha alması gereken yol var Gartner’ın Magic Quadrant’ında kendisine yer edinebilmesi için. Buna rağmen aslında belirlediğimiz kurallar formatlar ile ihtiyaçlarımızın büyük bir çoğunluğunu karşılıyor diyebiliriz. Peki Data Quality Services (DQS) öncesinde veri temizliğini nasıl yapıyorduk? Öncelikle oltp yapılarımızda referans tablosu oluştur ve bunu baz alarak işlem yap mantığı vardı. Yani aslında ara tablolar ile join işlemi yaparak verileri kaliteli bir hale getirmeye çalışıyorduk. Bu plaka kodu yazan şehri bularak onun veritabanında karşılık gelen ID’sini bulma konusunda çalışabilir bir yapı. Fakat her zaman referans tablomuz olmayabilir veya olduğunda eş gelmeyebilir. Bununla ilgili ise SSIS bileşenlerinden Fuzzy Lookup ve Fuzzy Grouping kullanılabilir.
Bu yazımızın devamında DQS ile ilgili tanımlamalarla devam edeceğiz.