Veri Kalitesi Süreci Nasıl Uygulanır?

Veri ambarı sistemlerinde Veri Kalitesi (DQ) giderek daha önemli hale geliyor. Artan yasal gereklilikler ve aynı zamanda veri ambarı çözümlerinin artan karmaşıklığı, şirketleri bir veri kalitesi girişimini yoğunlaştırmaya (veya başlatmaya) zorlar.

Bu makalenin ana odak noktası “geleneksel” veri ambarı olacaktır, ancak veri kalitesi aynı zamanda veri gölleri gibi daha “modern” kavramlarda da bir sorundur. Bir veri kalitesi stratejisi uygularken göz önünde bulundurulması gereken bazı ana noktaları ve ayrıca kaçınılması gereken bazı yaygın tuzakları gösterecektir. Bir DQ çerçevesi oluşturmak için doğru teknoloji/aracın seçilmesi bölümünü kapsamaz.

Bir DQ projesinin en büyük engellerinden biri, ilk bakışta herhangi bir ekstra işlevsellik sağlamadan iş birimleri için çok fazla iş yaratmasıdır. Bir veri kalitesi girişiminin genellikle yalnızca aşağıdaki durumlarda güçlü destekçileri vardır:

• İş üzerinde ciddi etkisi olan veri kalitesi sorunları var.
• Düzenleyici kurumlar veri kalitesi standartlarını uygular (örneğin finans sektöründe BCBS 239).

DQ'nun tedavisi, yazılım geliştirmedeki testlere benzer - bir projenin zamanı ve/veya bütçesi biterse, önce bu kısım azaltılır.

Bu, elbette, gerçeğin tamamı değildir. İyi bir veri kalitesi sistemi, hataları erkenden tespit etmeye yardımcı olur, böylece kullanıcılara "yeterince iyi" kalitede veri sağlama sürecini hızlandırır.

Şartların tanımı

Konuyu tartışmadan önce, kullanılan terimlerin ortak bir şekilde anlaşılması önemlidir.

Veri Ambarı (DWH)

Bir veri ambarı (DWH), esas olarak karar desteği için kullanılan, operasyonel olmayan bir sistemdir. Operasyonel sistemlerin verilerini (tümü veya daha küçük bir alt küme) birleştirir ve DWH sisteminin kullanıcıları için sorgu için optimize edilmiş veriler sağlar. Veri ambarı, işletme içinde “tek bir doğruyu” sağlamalıdır. Bir veri ambarı genellikle aşamalardan/katmanlardan oluşur:

Operasyonel veriler çoğunlukla değişmeden bir evreleme katmanında saklanır. Çekirdek katman , birleştirilmiş ve birleştirilmiş veriler içerir. Bir sonraki isteğe bağlı aşama, türetilmiş veriler (örneğin, satışlar için bir müşteri puanı) ve toplamalar sağlayan bir türetme alanıdır . Data mart katmanı , belirli bir kullanıcı grubu için optimize edilmiş verileri içerir. Veri marketleri genellikle toplamalar ve çok sayıda türetilmiş metrik içerir. Veri ambarı kullanıcıları genellikle yalnızca data mart katmanıyla çalışır.

Her aşama arasında bir tür veri dönüşümü gerçekleşir. Genellikle, bir veri ambarı, operasyonel verilerin delta çıkarımlarıyla periyodik olarak yüklenir ve geçmiş verileri tutmak için algoritmalar içerir.

Veri kalitesi

Veri kalitesi genellikle bir ürünün kullanıcı gereksinimlerini ne kadar iyi karşıladığını gösteren bir ölçü olarak tanımlanır. Farklı kullanıcıların bir ürün için farklı gereksinimleri olabilir, bu nedenle uygulama kullanıcının bakış açısına bağlıdır ve bu ihtiyaçların belirlenmesi önemlidir.

Veri kalitesi, verilerin tamamen veya neredeyse hatasız olması gerektiği anlamına gelmez; bu, kullanıcıların gereksinimlerine bağlıdır. "Yeterince iyi" bir yaklaşım, başlamak için iyi bir seçimdir. Günümüzde daha büyük şirketlerin bir “veri (veya bilgi) devlet politikası” var ve veri kalitesi de bunun bir parçası. Bir veri devleti politikası , şirketinizin verilerle nasıl ilgilendiğini ve verilerin doğru kaliteye sahip olmasını ve veri gizliliği kurallarının ihlal edilmemesini nasıl sağladığını açıklamalıdır.

Veri kalitesi devam eden bir konudur. Bir DQ devre döngüsü uygulanmalıdır (bir sonraki bölüme bakın). Mevzuat gereklilikleri ve uyumluluk kuralları, gizlilik sorunları için Avrupa'da TCPA (ABD Telefon Tüketici Koruma Yasası) veya GDPR gibi ihtiyaç duyulan veri kalitesi üzerinde ve ayrıca AB'de sigortalar için Solvency II, BCBS 239 gibi sektöre özel kurallar üzerinde de etkilidir. ve diğerleri bankacılık için vb.

Veri Kalitesi Devre Döngüsü

Tüm kalite konularında olduğu gibi, DQ da tatmin edici kaliteyi sürdürmek için tasarlanmış sürekli bir faaliyettir. Bir DQ projesinin sonucu olarak, aşağıdakine benzer bir devre döngüsü uygulanmalıdır:

Bu döngü içindeki adımlar sonraki bölümlerde açıklanacaktır.

Veri Kalitesi Rolleri

Başarılı bir DQ girişimini uygulamak için aşağıdaki rollere ihtiyaç vardır:

• Veri Sahibi. Bir veri sahibi, veri kalitesinden değil, aynı zamanda veri gizliliğinin korunmasından da sorumludur. Veri sahibi bir veri alanının "sahibidir", erişimi kontrol eder ve veri kalitesini sağlamaktan ve bulguları düzeltmek için harekete geçmekten sorumludur. Daha büyük kuruluşlarda, birkaç veri sahibi bulmak yaygındır. Veri alanları, örneğin pazarlama verileri, verileri kontrol etme vb. olabilir. Bir şirkette birden fazla veri sahibi varsa, genel veri kalitesi sürecinden bir kişi (veri sahibi veya başka biri) sorumlu olmalıdır. Bir veri sahibi, veri kalitesini uygulamak ve DQ sürecini desteklemek için güçlü bir yetkiye sahip olmalıdır; bu nedenle, veri sahipleri genellikle üst düzey paydaşlardır. İyi iletişim becerileri ile birlikte iş alanının iyi anlaşılması önemlidir.
• Veri Sorumlusu. Bir veri sorumlusu, bir kuruluş içinde veri kalitesinin uygulanmasına yardımcı olur, veri kullanıcılarını verilerin/veri modelinin nasıl yorumlanacağı, veri kalitesi sorunları vb. hakkında sorular konusunda destekler. Veri görevlileri genellikle veri sahibinin personelidir veya bir veri kalitesi yetkinlik merkezinde organize edilebilir. veya bir DQ ekibi. Veri görevlileri bir BT veya iş geçmişine sahip olabilir ancak her iki tarafı da bilmelidir. Analitik beceriler, destekledikleri iş alanının iyi anlaşılması ve güçlü iletişim becerileri ile birleştiğinde, başarılı bir veri sorumlusu için başlıca ön koşullardır.
• Veri Kullanıcısı. Bunlar, verilerle çalışan veri ambarı kullanıcılarıdır. Veri kullanıcıları genellikle data mart katmanıyla çalışır ve verilerle yapılan iş sonuçlarından sorumludur. Veri kullanıcıları, ihtiyaç duydukları kalite düzeyi için yeterli veri kalitesi kontrollerinin yapıldığından emin olur. Veri kullanıcılarının verileri, iş alanlarını ve verileri yorumlamak için gerekli analitik becerilere ilişkin güçlü bir anlayışa ihtiyacı vardır. Her iş birimindeki veri kullanıcıları arasında veri kalitesi sorunlarından sorumlu olacak birkaç kişi bulmak mantıklıdır.

Başarıyı sağlamak için, DQ projenizin ilk aşamalarında bu rollerin açık bir şekilde tanımlanması ve kuruluşunuzda geniş çapta kabul görmesi önemlidir. Projeyi destekleyen bu roller için yetkin veri uzmanları bulmak da aynı derecede önemlidir.

Kuralları Tanımlayın

Yararlı DQ kontrollerini/kurallarını bulun ve uygulayın. DQ kurallarının tanımlanması, veri ambarınızın ve kullanımının iyi anlaşılmasını gerektirir.

DQ Kuralları Nasıl Bulunur?

Daha önce tartışıldığı gibi, veri kullanıcıları (ve veri sahibi) veri kullanımından ve dolayısıyla gerekli veri kalitesi seviyesinden sorumludur. Veri kullanıcılarının, yararlı veri kalitesi kuralları için en iyi girdiyi verebilmeleri için verilerini iyi anlamaları gerekir.

Ayrıca veri kalitesi kurallarının sonuçlarını analiz edenler de onlardır, bu nedenle kendi kurallarını tanımlamalarına izin vermek her zaman iyi bir fikirdir. Bu, bir veri kullanıcı birimine atanan DQ kurallarının sonucunu kontrol etme ve derecelendirme kabulünü daha da geliştirir (bkz. “Analiz” bölümü).

Bu yaklaşımın dezavantajı, veri kullanıcılarının normalde veri ambarının önceki katmanlarını değil, yalnızca data mart katmanını bilmesidir. Veriler "alt" aşamalarda bozulduysa, bu, veri ambarınızın yalnızca "üst" katmanı kontrol edilerek algılanmayacaktır.

Hatalarla Mücadele

Bir veri ambarında ne tür bilinen hatalar oluşabilir?

• Veri ambarında yanlış dönüşüm mantığı
  • BT ortamınız ne kadar karmaşıksa, dönüşüm mantığı da o kadar karmaşık olma eğilimindedir. Bunlar en yaygın DQ sorunlarıdır ve bu tür hataların etkisi “kaybedilen” veriler, kopyalar, yanlış değerler vb. olabilir.
• Kararsız yükleme süreci veya yüklerin yanlış taşınması
  • Bir veri ambarının yükü, iş düzenlemesinin tanımındaki hataları (işlerin çok erken veya çok geç başlaması, yürütülmeyen işler vb.) içerebilecek karmaşık bir süreç olabilir. Manuel müdahaleden kaynaklanan hatalar (örneğin, bazı işler atlanır, bazı işler yanlış son tarihte veya dünün veri dosyalarıyla başlatılır) genellikle bazı kesintiler nedeniyle yükleme işlemi bant dışına çıktığında meydana gelir.
• Veri kaynaklarının yanlış veri aktarımı
  • Veri aktarımı genellikle kaynak sistemin bir görevi olarak uygulanır. İş akışlarındaki anormallikler veya kesintiler, boş veya eksik verilerin teslimine neden olabilir.
• Yanlış operasyonel veriler
  • İşletim sistemindeki veriler şu ana kadar tanınmayan hatalar içeriyor. Garip gelebilir, ancak veri ambarı projelerinde, veriler bir DWH'ye dahil edilene kadar operasyonel verilerin kalitesinin genellikle görülmediği bir klişedir.
• Verilerin yanlış yorumlanması
  • Veriler doğru, ancak kullanıcılar onu nasıl doğru yorumlayacaklarını bilmiyorlar. Bu, kesinlikle bir veri kalitesi sorunu olmayan, ancak veri yönetişimi ile ilgili olan ve veri sorumlularının görevi olan çok yaygın bir "hatadır".

Bu sorunlara genellikle, bir veri ambarı çözümünü tanımlama, uygulama, çalıştırma ve bu çözümle çalışma için uygun teknik bilgi ve becerilere sahip olmayan kişiler neden olur.

Veri Kalitesi Boyutları

DQ boyutları , DQ kontrollerini tanımlamanın ve kümelemenin yaygın bir yoludur. Birçok tanım vardır ve boyutların sayısı önemli ölçüde değişir: 16 veya daha fazla boyut bulabilirsiniz. Pratik bir bakış açısından, birkaç boyutla başlamak ve kullanıcılarınız arasında bunlarla ilgili genel bir anlayış bulmak daha az kafa karıştırıcıdır.

• Tamlık: Gerekli tüm veriler mevcut ve erişilebilir mi? Gerekli tüm kaynaklar mevcut ve yüklendi mi? Aşamalar arasında veri kaybı oldu mu?
• Tutarlılık: Hatalı/çakışan/tutarsız veriler var mı? Örneğin, "Fesih" durumundaki bir sözleşmenin fesih tarihi, sözleşmenin başlangıç ​​tarihinden daha yüksek veya ona eşit geçerli bir tarih içermelidir.
• Benzersizlik: Herhangi bir kopya var mı?
• Bütünlük: Tüm veriler doğru şekilde bağlanmış mı? Örneğin, var olmayan müşteri kimliklerine bağlanan siparişler var mı (klasik bir bilgi bütünlüğü sorunu)?
• Zamanlılık: Veriler güncel mi? Örneğin, günlük güncellemelerin olduğu bir veri ambarında, dünün verilerinin bugün mevcut olmasını beklerdim.

Veri ambarı yükleme işlemi tarafından oluşturulan veriler de yardımcı olabilir.

• Atılan veriler içeren tablolar. Veri ambarınız, teknik sorunlar (ör. biçim dönüştürme, eksik zorunlu değerler vb.) nedeniyle yüklenemeyen verileri atlama/gecikme işlemlerine sahip olabilir.
• Günlük bilgileri. Günlük tablolarına veya günlük dosyalarına fark edilebilir sorunlar yazılabilir.
• Teslimat faturası. Bazı sistemler, operasyonel sistemler tarafından sağlanan veriler için “teslimat faturalarını” kullanır (örneğin, kayıt sayısı, farklı anahtarların sayısı, değerlerin toplamı). Bunlar, veri ambarı ve operasyonel sistemler arasındaki mutabakat kontrolleri (aşağıya bakın) için kullanılabilir.

Hataların bulunması durumunda, her veri kalitesi kontrolünün en az bir veri kullanıcısı tarafından analiz edilmesi gerektiğini unutmayın (bkz. “Analiz” bölümü).

Karmaşık bir veri ambarında, birçok (bazen binlerce) DQ kuralıyla karşılaşabilirsiniz. Veri kalitesi kurallarını uygulama süreci, bununla başa çıkacak kadar sağlam ve yeterince hızlı olmalıdır.

Teknik uygulama tarafından garanti edilen gerçekleri kontrol etmeyin. Örneğin, veriler bir ilişkisel VTYS'de depolanıyorsa, aşağıdakileri kontrol etmek gerekli değildir:

• Zorunlu olarak tanımlanan sütunlar NULL değerler içerir.
• Birincil anahtar alan(lar)ı değerleri bir tabloda benzersizdir.
• İlişkisel bütünlük denetimlerinin etkinleştirildiği bir tabloda mevcut yabancı anahtar yok.

Bununla birlikte, bir veri ambarının sürekli değişim içinde olduğunu ve alanların ve tabloların veri tanımlarının zaman içinde değişebileceğini her zaman aklınızda bulundurun.

Ev temizliği çok önemlidir. Farklı veri kullanıcı birimleri tarafından tanımlanan kurallar çakışabilir ve konsolide edilmelidir. Organizasyonunuz ne kadar karmaşık olursa, o kadar fazla temizlik ihtiyacı olacaktır. Veri sahipleri, bir tür "veri kalitesi kuralları için veri kalitesi" olarak bir kural konsolidasyonu süreci uygulamalıdır. Ayrıca, veriler artık kullanılmıyorsa veya tanımı değiştiyse, veri kalitesi kontrolleri işe yaramaz hale gelebilir.

Veri Kalitesi Kuralları Sınıfları

Veri kalitesi kuralları, testin türüne göre sınıflandırılabilir.

• Veri kalitesi kontrolü. “Normal” durum, verileri tek bir veri ambarı katmanında (bkz. Şekil 1) tek bir tablo veya bir dizi tablo içinde kontrol eder.
• Mutabakat. Verilerin veri ambarı katmanları arasında doğru bir şekilde taşınıp taşınmadığını kontrol eden kurallar (bkz. Şekil 1). Bu kurallar çoğunlukla “Bütünlük”ün DQ boyutunu kontrol etmek için kullanılır. Mutabakat, tek bir satır veya özetlenmiş bir yaklaşım kullanabilir. Tek satırları kontrol etmek çok daha ayrıntılıdır, ancak karşılaştırılan katmanlar arasında dönüştürme adımlarını (veri filtreleme, alan değerlerindeki değişiklikler, denormalizasyon, birleşimler, vb.) yeniden oluşturmanız gerekir. Ne kadar çok katmanı atlarsanız, o kadar karmaşık dönüşüm mantığı uygulanmalıdır. Bu nedenle, evrelemeyi data mart katmanıyla karşılaştırmak yerine, her katman ve önceki katman arasında mutabakat yapmak iyi bir seçimdir. Mutabakat kurallarında dönüşümlerin uygulanması gerekiyorsa, veri ambarı kodunu değil, belirtimi kullanın! Özetlenmiş mutabakat için anlamlı alanlar bulun (örn. özetleme, farklı değerlerin sayısı, vb.).
• izleme. Bir veri ambarı genellikle geçmiş verileri içerir ve operasyonel verilerin delta özleri ile yüklenir. Veri ambarı ve operasyonel veriler arasında yavaş yavaş artan bir boşluk tehlikesi vardır. Özetlenmiş zaman serileri oluşturmak, bunun gibi sorunların belirlenmesine yardımcı olur (örneğin, geçen ayın verilerini mevcut ayın verileriyle karşılaştırma). Verileri hakkında iyi bilgi sahibi olan veri kullanıcıları, izleme kuralları için faydalı önlemler ve eşikler sağlayabilir.

Veri Kalitesi Sorunu Nasıl Ölçülür

Neyin kontrol edileceğini tanımladıktan sonra, tanımlanan sorunların nasıl ölçüleceğini belirtmeniz gerekir. "Beş veri satırı, ID 15 ile DQ kuralını ihlal ediyor" gibi bilgiler, veri kalitesi için pek anlamlı değildir.

Aşağıdaki parçalar eksik:

• Tespit edilen hataların nasıl ölçüleceği/sayılacağı. "Satır sayısını" sayabilirsiniz, ancak parasal bir ölçek de kullanabilirsiniz (örneğin, pozlama). Parasal değerlerin farklı işaretlere sahip olabileceğini unutmayın, bu nedenle bunları nasıl anlamlı bir şekilde özetleyeceğinizi araştırmanız gerekecek. Bir veri kalitesi kuralı için her iki niceleme birimini (satır sayısı ve özetleme) kullanmayı düşünebilirsiniz.
• Nüfus. Veri kalitesi kuralı tarafından kontrol edilen birim sayısı nedir? "Beşte beş veri satırı", "5 milyonda beş"ten farklı bir kaliteye sahiptir. Popülasyon, hatalarla aynı nicelik(ler) kullanılarak ölçülmelidir. Bir veri kalitesi kuralının sonucunun yüzde olarak gösterilmesi yaygındır. Popülasyon, bir tablodaki satır sayısıyla aynı olmamalıdır. Bir DQ kuralı, verilerin yalnızca bir alt kümesini kontrol ederse (örneğin, sözleşmeler tablosunda yalnızca feshedilmiş sözleşmeler), popülasyonu ölçmek için aynı filtre uygulanmalıdır.
• Sonucun tanımı. Bir veri kalitesi kontrolünde sorunlar bulunsa bile, bunun her zaman bir hataya neden olması gerekmez. Veri kalitesi için, bulguları derecelendirmek için eşik değerleri kullanan bir trafik ışığı sistemi (kırmızı, sarı, yeşil) çok faydalıdır. Örneğin, yeşil: %0-2, sarı: %2-5, kırmızı: %5'in üzerinde. Veri kullanıcı birimleri aynı kuralları paylaşıyorsa, belirli bir kural için çok farklı eşiklere sahip olabileceklerini unutmayın. Bir pazarlama iş birimi, birkaç siparişin kaybolmasını umursamayabilirken, bir muhasebe birimi sentleri bile önemseyebilir. Yüzde veya mutlak rakamlar üzerinden eşikler tanımlanabilmelidir.
• Örnek hata satırlarını toplayın. Bir veri kalitesi kuralının algılanan hataların bir örneğini sağlamasına yardımcı olur—normalde (iş!) anahtarları ve kontrol edilen veri değerleri, hatayı incelemeye yardımcı olmak için yeterlidir. Bir veri kalitesi kuralı için yazılı hata satırlarının sayısını sınırlamak iyi bir fikirdir.
• Bazen, verilerde düzeltilmeyecek ancak yararlı veri kalitesi kontrolleriyle bulunan "bilinen hatalar" bulabilirsiniz. Bu durumlarda, beyaz listelerin (veri kalite kontrolü tarafından atlanması gereken kayıtların anahtarları) kullanılması önerilir.

Diğer Meta Veriler

Meta veriler, "Analiz"i yönlendirmek ve veri kalite kontrol döngüsünün aşamalarını izlemek için önemlidir.

• Kontrol edilen öğeler. Kontrol edilen tablo(lar) ve alan(lar)ın bir veri kalitesi kuralına atanmasına yardımcı olur. Gelişmiş bir meta veri sisteminiz varsa, bu, bu kurala otomatik olarak veri kullanıcıları ve bir veri sahibi atamanıza yardımcı olabilir. Düzenleyici nedenlerle (BCBS 239 gibi), verilerin DQ tarafından nasıl kontrol edildiğinin kanıtlanması da gereklidir. Ancak, veri kullanıcıları/veri sahiplerine veri kökeni (*) aracılığıyla otomatik olarak kurallar atamak iki ucu keskin bir kılıç olabilir (aşağıya bakın).
• Veri kullanıcısı. Her DQ kuralı, "Analiz" aşaması sırasında sonucu kontrol etmek ve bir bulgunun verilerle çalışmalarını etkileyip etkilemediğine ve nasıl etkileyeceğine karar vermek için atanmış en az bir veri kullanıcısı/veri kullanıcı birimine sahip olmalıdır.
• Veri sahibi. Her DQ kuralına atanmış bir veri sahibi olmalıdır.

(*) Veri çizgisi, iki nokta arasındaki veri akışını gösterir. Veri kökeni ile, deponuzdaki belirli bir hedef alanı etkileyen tüm veri öğelerini bulabilirsiniz.

Kullanıcıları kurallara atamak için veri kökenini kullanmak sorunlu olabilir. Daha önce de belirtildiği gibi, iş kullanıcıları genellikle yalnızca data mart katmanını (ve işletim sistemini) bilir, ancak veri ambarının alt seviyelerini bilmez. Veri kökeni yoluyla eşleme yaparak, veri kullanıcılarına aşina olmadıkları kurallar atanacaktır. Daha düşük seviyeler için, bir veri kalitesi bulgusunu değerlendirmek için BT personeline ihtiyaç duyulabilir. Çoğu durumda, manuel bir haritalama veya karma bir yaklaşım (yalnızca data mart içindeki veri kökeni aracılığıyla haritalama) yardımcı olabilir.

Veri Kalitesini Ölçme

Veri kalitesinin ölçülmesi, veri ambarının yükleme süreçleri tarafından tetiklenen, otomatik olarak yapılması gereken mevcut veri kalitesi kurallarının yürütülmesi anlamına gelir. Daha önce gördüğümüz gibi, dikkate değer sayıda veri kalitesi kuralı olabilir, bu nedenle kontroller zaman alacaktır.

Mükemmel bir dünyada, bir veri ambarı yalnızca tüm veriler hatasız olduğunda yüklenir. Gerçek dünyada, durum nadiren böyledir (gerçekçi olarak, durum neredeyse hiç böyle değildir). Veri ambarınızın genel yükleme stratejisine bağlı olarak, veri kalitesi süreci yükleme sürecini yönetmeli veya yönetmemelidir (ikincisi çok daha olasıdır). Veri kalitesi süreçlerinin (iş ağları) paralel ve “düzenli” veri ambarı yük süreçleriyle bağlantılı olması iyi bir tasarımdır.

Tanımlanmış hizmet düzeyi anlaşmaları varsa, veri kalitesi kontrolleriyle veri ambarı yüklerini engellemediğinizden emin olun. Veri kalitesi süreçlerindeki hatalar/esneklikler, normal yükleme sürecini durdurmamalıdır. Veri kalitesi süreçlerindeki beklenmeyen hatalar raporlanmalı ve “Analiz” aşaması için gösterilmelidir (bir sonraki bölüme bakınız).

Beklenmeyen hatalar nedeniyle bir veri kalitesi kuralının çökebileceğini unutmayın (belki kuralın kendisi yanlış uygulanmış veya temel alınan veri yapısı zaman içinde değişmiştir). Veri kalitesi sisteminizin bu tür kuralları devre dışı bırakmak için bir mekanizma sağlaması, özellikle şirketinizin yılda birkaç sürümü varsa, bu yardımcı olacaktır.

DQ süreçleri mümkün olduğunca erken, ideal olarak, kontrol edilen veriler yüklendikten hemen sonra yürütülmeli ve raporlanmalıdır . Bu, veri ambarının yüklenmesi sırasında hataların mümkün olduğunca erken tespit edilmesine yardımcı olur (bazı karmaşık ambar sistemi yüklerinin birkaç günlük süresi vardır).

analiz et

Bu bağlamda “analiz”, veri kalitesi bulgularına tepki vermek anlamına gelir. Bu, atanan veri kullanıcıları ve veri sahibi için bir görevdir.

Tepki vermenin yolu, veri kalitesi projeniz tarafından açıkça tanımlanmalıdır. Veri kullanıcıları, bulguyu ele almak için hangi önlemlerin alındığını açıklayan bulgularla (en azından kırmızı ışıklı kurallar) bir kural hakkında yorum yapmakla yükümlü olmalıdır. Veri sahibi bilgilendirilmeli ve veri kullanıcısı/kullanıcıları ile birlikte karar vermelidir.

Aşağıdaki eylemler mümkündür:

• Ciddi sorun: Sorun düzeltilmeli ve veri yüklemesi tekrarlanmalıdır.
• Sorun kabul edilebilir: Gelecekteki veri yüklemeleri için düzeltmeye çalışın ve sorunu veri ambarı veya raporlama içinde ele alın.
• Arızalı DQ kuralı: Sorunlu DQ kuralını düzeltin.

Mükemmel bir dünyada, her veri kalitesi sorunu çözülür. Ancak, kaynak ve/veya zaman eksikliği genellikle geçici çözümlerle sonuçlanır.

DQ sisteminin zamanında tepki verebilmesi için veri kullanıcılarını “kendi” kuralları hakkında bulgularla bilgilendirmesi gerekir. Bir veri kalitesi panosu kullanmak (belki bir şeyin geldiğine dair mesajlar göndererek) iyi bir fikirdir. Kullanıcılar bulgular hakkında ne kadar erken bilgilendirilirse o kadar iyi olur.

Veri kalitesi kontrol paneli şunları içermelidir:

• Belirli bir role atanan tüm kurallar
• Sonuç ve veri alanına göre kuralları filtreleme özelliğine sahip kuralların sonuçları (trafik ışığı, ölçüler ve örnek satırlar)
• Veri kullanıcılarının bulgular için girmesi gereken zorunlu bir yorum
• İsteğe bağlı olarak sonucu "geçersiz kılmak" için bir özellik (örneğin, veri kalitesi kuralı hatalı bir uygulamadan kaynaklanan hataları bildiriyorsa). Birden fazla iş birimi aynı veri kalitesi kuralına sahipse, "geçersiz kılma" yalnızca veri kullanıcısının iş birimi (şirketin tamamı için değil) için geçerlidir.
• Yürütülmeyen veya değiştirilen kurallar gösteriliyor

Pano ayrıca son veri ambarı yükleme işleminin mevcut durumunu göstererek kullanıcılara veri ambarı yükleme işleminin 360 derecelik bir görünümünü sunmalıdır.

Veri sahibi, her bulgunun yorumlandığından ve veri kalitesinin (orijinal veya geçersiz) durumunun tüm veri kullanıcıları için en az sarı olduğundan emin olmaktan sorumludur.

Hızlı bir genel bakış için, veri kullanıcıları/veri sahipleri için bir tür basit KPI (temel performans göstergeleri) oluşturmaya yardımcı olacaktır. Her kurala aynı ağırlık verilirse, ilgili tüm kuralların sonuçları için genel bir trafik ışığına sahip olmak oldukça kolaydır.

Şahsen, belirli bir veri alanı için genel bir veri kalitesi değeri hesaplamanın oldukça karmaşık olduğunu ve kabalistik olma eğiliminde olduğunu düşünüyorum, ancak en azından bir veri alanı için sonuca göre gruplandırılmış genel kuralların sayısını gösterebilirsiniz (örneğin, "100 DQ kuralı" %90 yeşil, %5 sarı ve %5 kırmızı sonuçlarla”).

Bulguların düzeltilmesini ve veri kalitesinin iyileştirilmesini sağlamak veri sahibinin görevidir.

Süreçleri İyileştirme

Veri ambarı süreçleri sıklıkla değiştiğinden, veri kalitesi mekanizmasının da bakıma ihtiyacı vardır.

Bir veri sahibi her zaman aşağıdaki noktalara dikkat etmelidir:

• Güncel tutun. Veri ambarındaki değişikliklerin veri kalite sisteminde yakalanması gerekir.
• Genişletmek. Henüz veri kalitesi kurallarının kapsamına girmeyen hatalar için yeni kurallar uygulayın.
• Kolaylaştırın. Artık gerekmeyen veri kalitesi kurallarını devre dışı bırakın. Çakışan kuralları birleştirin.

Veri Kalitesi Süreçlerinin İzlenmesi

Tüm veri kalitesi sürecinin izlenmesi, zaman içinde iyileştirilmesine yardımcı olur.

İzlemeye değer şeyler şunlar olabilir:

• Veri kalite kuralları ile verilerinizin kapsamı
• Zaman içinde etkin kurallar içindeki veri kalitesi bulgularının yüzdesi
• Etkin veri kalitesi kurallarının sayısı (Gözünüz üzerinde olsun - Veri kullanıcılarının giderek daha fazla veri kalitesi kuralını devre dışı bırakarak bulgularını çözdüğünü gördüm.)
• Tüm bulguların derecelendirilmesi ve sabitlenmesi için bir veri yükü içinde gereken süre

Çözüm

Aşağıdaki noktaların çoğu her türlü projede önemlidir.

Direnci tahmin edin. Gördüğümüz gibi, acil bir kalite sorunu yoksa, veri kalitesi genellikle yeni işlevler sunmadan ek bir yük olarak görülür. Veri kullanıcıları için ek iş yükü oluşturabileceğini unutmayın. Çoğu durumda, uyumluluk ve düzenleyici talepler, kullanıcıları bunu kaçınılmaz bir gereklilik olarak görmeye ikna etmenize yardımcı olabilir.

Bir sponsor bulun. Yukarıda belirtildiği gibi, DQ hızlı satılan bir ürün değildir, bu nedenle güçlü bir sponsor/paydaş gereklidir - yönetimde ne kadar yüksek olursa o kadar iyidir.

Müttefikler bulun. Sponsorda olduğu gibi, güçlü veri kalitesi fikrini paylaşan herkes çok yardımcı olacaktır. DQ devre döngüsü devam eden bir süreçtir ve devre döngüsünü canlı tutmak için insanlara ihtiyaç duyar.

Küçük başla. Şimdiye kadar herhangi bir DQ stratejisi yoksa, daha iyi veri kalitesine ihtiyaç duyan bir iş birimi arayın. Onlara daha iyi verilerin faydasını göstermek için bir prototip oluşturun. Göreviniz belirli bir veri kalitesi stratejisini iyileştirmek veya hatta değiştirmekse, kuruluşta iyi çalışan/kabul edilen şeylere bakın ve bunları saklayın.

Resmin tamamını gözden kaçırmayın. Küçük başlasa da, bazı noktaların, özellikle rollerin başarılı bir DQ stratejisi için önkoşul olduğunu unutmayın.

Bir kez uygulandıktan sonra bırakmayın. Veri kalitesi süreci, veri ambarı kullanımının bir parçası olmalıdır. Zamanla, veri kalitesine odaklanmak biraz kaybolma eğilimindedir ve bunu korumak size kalmıştır.