Veri bilimcileri, zamanlarının %80’ini verileri temizlemekle geçirdiklerini ve geri kalan %20’sini de verileri temizlemekten şikayet ederek geçirdiklerini iddia ediyor. Bu resimde açıkça bir yanlışlık var ama ne yazık ki kendi deneyimlerim bunun pratikte doğru olduğunu doğrulayabilir. Bu blogda amacım, veri temizleme gerçekleştirme ihtiyacının neden bu kadar yaygın bir sorun olduğunu keşfetmek. Daha da önemlisi, benimsemeye çalışmamız gereken daha iyi seçenekleri tartışıyorum. Bu keşif için. Bir sorunun temel nedenine ulaşana kadar neden diye sormaya devam ettiğiniz “5 Neden” adlı yalın bir teknik uyguluyorum.
Neden Bu Kadar Çok Veri Temizleme?
Çoğu kuruluş, yüksek düzeyde veri teknik borcundan veya başka bir deyişle düşük kaliteli verilerden muzdariptir. Kötü veri kalitesi birkaç nedenden dolayı ciddi bir sorundur:
- Verilere güvenilemeyeceği için veriye dayalı karar verme engellenir
- Genel olarak yazılım geliştirme girişimleri, daha düşük kaliteli varlıklarla çalışılması nedeniyle yavaşlar.
- Makine öğrenimi (ML)/yapay zeka (AI), aksi takdirde “çöp içeri, çöp dışarı” sorunlarından muzdarip modelleri eğitmek için yüksek kaliteli veriler gerektirir
- Veri ambarı (DW)/iş zekası (BI) çözümleri, dönüşüm mantığına önemli ölçüde yatırım yapar (veya daha doğrusu boşa harcar)
Yukarıdaki kullanım durumlarının hepsinde, verilerin kullanılabilir olduğu noktaya getirilmesine ihtiyaç vardır. Sonuç olarak, bunun etkili bir strateji olduğuna inanarak gerekli olan verileri temizliyoruz.
Veri Temizlemenin Neden Etkili Olduğu Düşünülüyor?
Kuruluşunuz aşırı veri teknik borcundan muzdarip olduğunda, temiz veri gerektiren her kullanım durumu, kullanım noktasında veri temizliği gerçekleştirmelidir (kuruluşunuzun daha sonra açıklanan daha iyi stratejileri izlemediği varsayılarak). Yüzeyde, bu iki nedenden dolayı mantıklı görünüyor:
- Bireysel ekiplerin, gelen verilerle nasıl çalışacakları üzerinde kontrolü vardır.. Veri sahipleri, verilere erişim için bir yol sağlar, ancak genellikle kaynak verileri manipüle etmek için yollar sağlamazlar (belki de genellikle hizmetler olarak uygulanan bir tür kapsülleme katmanı dışında). Kısacası, insanların kendi veri kopyalarıyla istedikleri her şeyi yapmalarına izin verilir, ancak kaynağı düzeltme konusunda sınırlı yetenekleri vardır. Bu nedenle, verileri kullanım noktasında temizlemek, onlar için mevcut olan tek seçenektir.
- İş, yalnızca ihtiyaç duydukları verilerle sınırlıdır. İnsanlar genellikle kendilerine sunulan kaynak verilerin bir alt kümesiyle ve genellikle verilerin çok küçük bir alt kümesiyle çalışır. Bu nedenle, gerçekleştirmeleri gereken veri temizleme çabası, tüm kaynak verileri düzeltmek için gereken çabadan çok daha azdır. Onların bakış açısından, bu çok daha az iş (ve onlar için).
Ancak, birden fazla ekibin aynı temizlik işini yapma olasılığı nedeniyle bu etkili değildir. Örneğin, bir adres biçimlendirme tutarsızlıklarından muzdaripse, adres verileriyle çalışan her ekibin bu veriler üzerinde benzer temizleme mantığını uygulaması, test etmesi ve sürdürmesi gerekir. Düşük kaliteli veriler, söz konusu temizleme mantığının tekrarı yoluyla ekipleri kuruluşunuzun genel teknik borcunu artırmaya motive eder. Kısacası, teknik borç daha fazla teknik borcu doğurur.
Verileri Neden Bir Kez Temizlemiyoruz?
Adres bilgisini girdi olarak alan her yerde temizlemek yerine bu kaynaktan çıktı alınca veriyi temizlemek için mantığı bir kez yazmak daha kolay olmaz mıydı? Veri ambarı (DW) çözümlerinde yaptığınız şey tam olarak budur. Veri ambarları, verileri birden fazla kaynaktan alır ve birçok farklı raporlama amacı için kullanılabilir hale getirir. Matematiksel olarak, N veri kaynağıyla çalışıyorlar ve bunu M kullanım durumu için sağlıyorlar. Yukarıda açıklanan veri temizleme stratejisi uygulanacaksa, verileri gerekli biçimlere sokmak için potansiyel olarak NxM temizleme zorluklarıyla karşılaşırlar. Elbette o kadar da kötü olmaz çünkü her kullanım durumu tüm N kaynaklarından veri gerektirmez, ancak her kullanım durumu bir veya daha fazla kaynaktan veri gerektirir. Bu nedenle, örneğin kullanıldığı her yerde adres verilerini düzeltmek için temizleme mantığı gibi yinelenen işler olacaktır.
Bunun yerine DW ekipleri, bir veri kaynağından gelen verilerin DW’ye yerleştirilmeden önce bir kez temizlendiği bir ayıklama-dönüştürme-yükleme (ETL) stratejisi kullanır. Bu, ETL’nin dönüştürme kısmıdır. Bundan sonra, herkes uygun şekilde manipüle edilen yüksek kaliteli verilere erişebilir. Bu, daha önce açıklanan veri temizleme stratejisinden daha az çalışma gerektirir ve daha az teknik borç, temizleme/dönüştürme kodu enjekte eder.
DW çözümlerinin dışında kuruluşlar ayrıca veritabanı erişimini kapsüllemeyi seçecek ve sistemleri verilere doğrudan SQL kodu (veya benzeri) yerine hizmetler veya bileşenler aracılığıyla erişmeye zorlayacaktır. Yaygın bir strateji, veri kaynağının kullanıcılarına veri sağlayan hizmetlere temizleme/dönüştürme mantığı koymaktır.
Verilerin kaynaktan okunduğu şekliyle temizlenmesi de sorunludur. Verileri bir kez temizlemek için gereken dönüşüm mantığı, zaman içinde oluşturulması, sürdürülmesi ve işletilmesi için çaba gerektiren teknik borçtur. Evet, bunu her kullanım noktasında birden fazla yerde yapmaktan daha az israf ama yine de israf.
Neden Kaynak Verileri Düzeltmiyoruz?
Üretimde çalışanlar da dahil olmak üzere mevcut eski veri kaynaklarındaki veri teknik borcunu ele alan araçlar ve teknikler yıllardır mevcuttur. İki kritik teknik şunlardır:
- Veritabanı yeniden düzenleme. Bir veritabanı yeniden düzenlemesi, bir veritabanının tasarımında, tasarımının kalitesini artıran basit bir değişikliktir. Veritabanı yeniden faktoringleri genellikle tablo yapısını, kod kalitesini (saklı yordamların, tetikleyicilerin vb.) veya veri kaynağına erişim yöntemlerini iyileştirir. Veritabanı yeniden faktoring örnekleri, bir sütunu yeniden adlandırmayı, bir tabloyu bölmeyi, bir görünüm eklemeyi ve daha fazlasını içerir. Kapsamlı bir liste için Database Re-factorings Kataloğuna bakın.
- Veri onarımı. Veri onarımı, mevcut bir veri kaynağındaki verilerin değerlerinde yapılan basit bir değişikliktir. Veri onarımlarına örnek olarak ortak bir formatın tanıtılması, dizelerdeki biçimlendirme karakterlerinin değiştirilmesi ve “hatalı değerlerin” düzeltilmesi yer alır.
Bu iki teknik oldukça basit olmasına rağmen, işle ilgili veya organizasyonel zorluklar nedeniyle uygulanması zor olabilir. Bu zorluklar şunları yapma ihtiyacını içerir:
- Kaynak verilere sahip olun. Çoğu kuruluşta, bir veri kaynağının sahibi, üzerinde değişiklik yapma yetkisine sahip tek kişidir. Bunun anlamı, ekibim mevcut bir veri kaynağında bir veri kalitesi sorunuyla karşılaşırsa sorunu çözmek için o veri kaynağının sahibi olan ekiple çalışmamız gerektiğidir. Bunu gerçekleştirmek genellikle çeşitli nedenlerle zor olabilir.
- Düzeltme yeteneğine sahip olmak. Veri kaynaklarını/kaynaklarını düzeltme becerisine sahip kişilere ve bunu yapmak için gereken araçlara ihtiyacınız olacak.
- kaynaklara sahip olmak. Mevcut veri kaynaklarını düzeltmek, normal geliştirme süreçlerinizde yerleşik olsa bile zaman ve finansman gerektirir.
Veri kalitesi sorunlarını kaynağında düzeltmek, elimizdeki mevcut veri teknik borcuyla karşılaştığımızda elimizdeki en iyi stratejidir. Ancak, ele alınması en kolay teknik borç, en başta maruz kalmadığımız teknik borçtur. Bu da bizi beşinci ve son sorumuza götürüyor.
Düşük Kalitede Veri Oluşturmayı Neden Durdurmuyoruz?
Veri kaynaklarına kasıtlı olarak düşük kaliteli veriler eklenir; bu kadar basit.
Bu, veri kalitesini sağlamak için yeterli kontrole sahip olmayan uygulamalar/sistemler aracılığıyla yapılır. Düşük kaliteli veriler, verilerin tutarsız bir şekilde anlaşılmasından veya verilerle ilgili anlaşmalardan da kaynaklanır. Örneğin, BDate adında bir sütunu olan bir Kişi tablosu vardır. Ekibim bunu bir kişinin doğum tarihini saklamak için kullanıyor çünkü bu ada sahip bir sütunun saklaması gereken şey kesinlikle bu. Ne yazık ki, bu tablonun ilk oluşturulduğu sistem, bunu müşterinin son faturalandırıldığı tarihi (belli ki) saklamak için kullanıyor. Bir sütunu birden fazla amaç için kullanmak, tespit edilmesi için yüzey düzeyinde bir analizden daha fazlasını gerektiren ciddi bir kalite sorunudur. Ayrıca, verilerin manuel olarak değiştirilmesi yoluyla da yapılır, belki de idari yetkiye sahip biri doğrudan verileri düzenler. Ya da kalitesiz veriler başka bir yerden bir veri kaynağına yüklenebilir. Buradaki nokta, kalitesiz verilerin çeşitli yöntemlerle veri kaynaklarına enjekte edilmesidir, bunlar daha yaygın olanlardır.
Bir veri kaynağının neden düşük kaliteli veriler içerdiğinin temel nedenini düzeltmek için şunları yapmanız gerekir:
- Veri kaynağındaki kalite sorunlarını/sorunlarını tanımlayın. Veri kaynaklarının tipik olarak birçok kalite sorunu vardır.
- Düşük kaliteli verileri neyin enjekte ettiğini belirleyin. Bu bir uygulama, harici bir veri kaynağından veri yükleme, manuel veri girişinin sonucu veya bunların kombinasyonları olabilir. Bunun tek bir kaynak olmayabileceğini ve daha da kötüsü düşük kaliteli verilerin, her biri kendi bağlamında doğru olan bir dizi şeyin sonucu olduğunu kabul etmek önemlidir.
- Gerçekte ne olması gerektiğini tanımlayın. Sorunu belirlemek yalnızca iyi bir başlangıçtır, ayrıca soruna/sorunlara bir çözüm belirlemeniz gerekir.
- İşe öncelik verin. Önce en kritik sorunları çözerek başlayın. İlginç bir şekilde, 80/20 kuralının geçerli olduğunu ve veri kalitesi sorunlarınızın birçoğunun aynı kaynak(lar)a sahip olduğunu fark edeceksiniz.
- Bozuk kodu, bozuk işlemi veya her ikisini düzeltin. Amacınız, düşük kaliteli verilerin enjeksiyonunu kalıcı olarak durdurmaktır.
Düşük kaliteli veri üretmeyi başarılı bir şekilde durdurmak için benimsememiz gereken üç temel strateji vardır:
- Geliştiriciler, veri mühendisliği temellerinde yetenekli olmalıdır. Geliştiriciler, temel veri mühendisliği tekniklerinde, özellikle Çevik Veritabanı Teknikleri Yığınındakilerde temel beceri ve bilgiye ihtiyaç duyar.
- Uygulama geliştirme ekiplerinin desteklenmesi gerekiyor. Veri, paylaşılan bir kurumsal varlıktır veya en azından öyle olmalıdır. Kuruluşunuzun, geleneksel yaklaşımın hemen hemen tam tersi olan, veri uzmanlarınızın evrimsel ve işbirliğine dayalı bir şekilde çalıştığı çevik bir veri yönetimi stratejisi benimsemesi gerekir. Veri profesyonellerinin masaya gerçek değer katması, birlikte çalışılması kolay olması ve beceri ve bilgilerini ekiplere aktarması gerekir. İlk adım, Çevik Veri Zihniyetini benimsemektir. İlginç bir şekilde, daha önceki Kişi BDate sütun örneği, gerçekten bir veri yönetimi başarısızlığıydı. Ekibim ya bu sütunun doğru kullanımı hakkında kiminle konuşacağını bilmiyordu, belgelere erişimi yoktu, belgeler mevcut değildi ya da veri becerileri konusunda bunun bir sorun. Ekiplerin bu şekilde uygun şekilde desteklenmesini sağlamak, kuruluşunuzun veri yönetimi ekibinin sorumluluğundadır.
- Uygulama geliştirme ekiplerinin bunu yapmasına izin verilmesi gerekir. Kuruluşlarda veri teknik borcu da dahil olmak üzere teknik borcun birincil nedeni, zayıf proje yönetimidir. Yazılım geliştirme projelerinin “zamanında ve bütçe dahilinde” olması isteği genellikle işten kaynaklanır, ancak bu kısıtlamalar genellikle proje yönetimi tarafından kabul edilir ve taahhüt edilir. Zamanında ve bütçede olmak için proje ekipleri her zaman işlevselliği, kaliteyi veya her ikisini de kesecek ve böylece teknik borç enjekte edecektir. Bu koşu bandından çıkmalı ve bunun yerine proje düzeyinde kısa vadede uygun olan bir kararın kuruluşunuzun uzun vadeli sağlığı için oldukça zararlı olduğunu kabul etmeliyiz. Ekiplerinizin yüksek kaliteli verilerle sonuçlanan uygulamalar/sistemler üretmesini istiyorsanız, bunu yapmak için gereken zaman ve paranın onlara verilmesi gerekir. İyi haber şu ki, en başından itibaren kaliteye yapılan yatırım, genellikle bir projenin sonuna doğru kaliteyi bırakmaktan (veya tamamen bırakmaktan) daha ucuz ve daha hızlıdır.
Ayrılık Düşünceleri
Yüksek kaliteli veri üreten sistemler oluşturmak, kaynak veriyi sonradan düzeltmekten, veriyi bir veri kaynağından çıkarıldığında dönüştürmekten, bu da veriyi kullanım noktasında temizlemekten daha iyidir. düşük kaliteli verilerle çalışmaktansa.
