Herkese merhaba, benim adım Alexander ve verileri kalite açısından kontrol eden bir Veri Kalitesi Mühendisiyim. Bu makale buna nasıl geldiğimden ve 2020'de bu test alanının neden bir dalganın zirvesinde olduğundan bahsedecek.
Küresel eğilim
Bugünün dünyası başka bir teknolojik devrim yaşıyor; bunun bir yönü, her tür şirket tarafından kendi satış, kar ve PR çarklarını döndürmek için birikmiş verilerin kullanılmasıdır. Görünüşe göre iyi (kaliteli) verilerin mevcudiyeti ve bunlardan para kazanabilen (doğru işleme, görselleştirme, makine öğrenimi modelleri oluşturma vb.) Becerikli beyinler, bugün birçok kişi için başarının anahtarı haline geldi. 15-20 yıl önce, büyük şirketler esas olarak veri birikimi ve bunlardan para kazanma ile yoğun çalışmalar yapıyorsa, bugün bu, neredeyse tüm aklı başında insanların kaderidir.
Bu bağlamda, birkaç yıl önce, dünyanın dört bir yanındaki tüm iş arama portalları Veri Bilimcileri açık pozisyonlarıyla dolmaya başladı, çünkü herkes kadrosuna böyle bir uzman alarak bir makine öğrenimi süper modeli oluşturabileceklerinden, geleceği tahmin edebileceklerinden emindi. ve şirket için bir "kuantum sıçraması" yapın. Zamanla, insanlar bu yaklaşımın neredeyse hiç işe yaramadığını fark ettiler, çünkü bu tür uzmanların eline geçen tüm veriler eğitim modelleri için uygun değil.
Ve Veri Bilimcilerden talepler başladı: “Şunlardan ve bunlardan daha fazla veri alalım…”, “Yeterli verimiz yok…”, “Biraz daha veriye ihtiyacımız var ve tercihen yüksek kaliteli…”. Bu taleplere dayanarak, belirli bir veri kümesine sahip şirketler arasında çok sayıda etkileşim kurulmaya başlandı. Doğal olarak, bu, bu sürecin teknik organizasyonunu gerektiriyordu - veri kaynağına bağlanmak, indirmek, tam olarak yüklenip yüklenmediklerini kontrol etmek vb. Bu tür süreçlerin sayısı artmaya başladı ve bugün başka bir türe çok ihtiyacımız var. uzmanların - Veri Kalitesi mühendisleri - sistemdeki veri akışını (veri boru hatları), girdi ve çıktıdaki verilerin kalitesini izleyen, yeterlilikleri, bütünlükleri ve diğer özellikleri hakkında sonuçlar çıkaran kişiler.
Mühendislerin Veri Kalitesi trendi bize, kapitalizmin öfkeli çağının ortasında kimsenin veri savaşını kaybetmeye hazır olmadığı ABD'den geldi. Aşağıda ABD'deki en popüler iki iş arama sitesinden ekran görüntüleri sağladım: и - 17 Mart 2020 itibariyle, şu anahtar kelimeler için alınan açık pozisyon sayısına ilişkin verileri görüntüler: Veri Kalitesi ve Veri Bilimcisi.
Veri Bilimcileri – 21416 açık pozisyon
Veri Kalitesi – 41104 açık pozisyon
Veri Bilimcileri – 404 açık pozisyon
Veri Kalitesi - 2020 açık pozisyonlar
Açıkçası, bu meslekler hiçbir şekilde birbirleriyle rekabet etmiyor. Ekran görüntüleriyle, artık Veri Bilimcilerinden çok daha fazla ihtiyaç duyulan Veri Kalitesi mühendislerine yönelik talepler açısından işgücü piyasasındaki mevcut durumu göstermek istedim.
Haziran 2019'da modern BT pazarının ihtiyaçlarına cevap veren EPAM, Veri Kalitesini ayrı bir uygulama olarak seçti. Veri Kalitesi Mühendisleri günlük çalışmaları sırasında verileri yönetir, yeni koşullar ve sistemlerdeki davranışını kontrol eder, verilerin uygunluğunu, yeterliliğini ve uygunluğunu kontrol eder. Tüm bunlarla birlikte, pratik anlamda, Veri Kalitesi mühendisleri klasik işlevsel testlere gerçekten çok az zaman ayırırlar. ANCAK büyük ölçüde projeye bağlıdır (aşağıda bir örnek vereceğim).
Bir Veri Kalitesi Mühendisinin görevleri, veritabanı tablolarındaki "boşluklar, sayımlar ve toplamlar" için rutin manuel/otomatik kontrollerle sınırlı değildir, ancak müşterinin iş ihtiyaçlarının derinlemesine anlaşılmasını ve buna bağlı olarak mevcut verileri dönüştürme becerisini gerektirir. kullanılabilir iş bilgileri.
Veri Kalitesi Teorisi
Böyle bir mühendisin rolünü en iyi şekilde hayal etmek için, teoride Veri Kalitesinin ne olduğunu bulalım.
Veri kalitesi - Veri Yönetiminin aşamalarından biri (bağımsız çalışma için size bırakacağımız tüm dünya) ve verileri aşağıdaki kriterlere göre analiz etmekten sorumludur:
Bence her bir noktayı deşifre etmeye değmez (teoride bunlara "veri boyutları" denir), resimde oldukça iyi tanımlanmışlardır. Ancak test sürecinin kendisi, bu özelliklerin katı bir şekilde test durumlarına kopyalanması ve bunların doğrulanması anlamına gelmez. Veri Kalitesinde, diğer herhangi bir test türünde olduğu gibi, her şeyden önce, iş kararları veren proje katılımcıları ile üzerinde anlaşmaya varılan veri kalitesi gerekliliklerini oluşturmak gerekir.
Veri Kalitesi projesine bağlı olarak, bir mühendis farklı işlevleri yerine getirebilir: veri kalitesine ilişkin yüzeysel bir değerlendirme yapan sıradan bir test edici-otomatikleştiriciden, yukarıdaki kriterlere göre derin profil oluşturmasını yürüten bir kişiye.
Veri Yönetimi, Veri Kalitesi ve ilgili süreçlerin çok ayrıntılı bir açıklaması, adlı bir kitapta iyi bir şekilde açıklanmıştır. "DAMA-DMBOK: Veri Yönetimi Bilgi Gövdesi: 2. Baskı". Bu kitabı bu konuya bir giriş olarak şiddetle tavsiye ediyorum (makalenin sonunda bir bağlantı bulacaksınız).
Hikayem
BT endüstrisinde, ürün şirketlerinde Junior QA'dan EPAM'da Baş Veri Kalitesi Mühendisi konumuna geçtim. Testçi olarak yaklaşık iki yıl geçirdikten sonra, kesinlikle her tür testi yaptığım konusunda kesin bir kanaate sahiptim: regresyon, işlevsellik, stres, kararlılık, güvenlik, UI, vs. üç programlama dili: Java, Scala, Python.
Geriye dönüp baktığımda, becerilerimin neden bu kadar çeşitli olduğunu anlıyorum - büyük ve küçük veri projelerinde yer aldım. Bu, beni büyümek için pek çok araç ve fırsatın dünyasına getiren şeydi.
Yeni bilgi ve beceriler kazanmaya yönelik çeşitli araç ve fırsatları takdir etmek için, bunların "Veri ve Yapay Zeka" dünyasında en popüler olanlarını gösteren aşağıdaki resme bakmanız yeterlidir.
Bu tür bir illüstrasyon, yazılım geliştirmenin yerlisi olan tanınmış risk sermayedarlarından biri olan Matt Turck tarafından her yıl üretilir. Burada bloguna ve nerede ortak olarak çalışıyor.
Özellikle bir projedeki tek testçi olduğumda veya en azından bir projenin başlangıcında profesyonel olarak hızla büyüdüm. Şu anda, tüm test sürecinden sorumlu olmanız gerekiyor ve geri çekilme şansınız yok, sadece ileriye doğru. İlk başta korkutucuydu, ama şimdi böyle bir testin tüm avantajları benim için açık:
- Tüm ekiple daha önce hiç olmadığı gibi iletişim kurmaya başlarsınız, çünkü iletişim için bir vekil yoktur: ne test yöneticisi ne de diğer testçiler.
- Projeye daldırma inanılmaz derecede derinleşir ve tüm bileşenler hakkında hem genel hem de ayrıntılı olarak bilgi sahibi olursunuz.
- Geliştiriciler size "ne yaptığını bilmeyen test görevlisi" olarak değil, otomatik testleri ve belirli bir ürün düğümündeki hataları öngörmesiyle ekip için inanılmaz değer üreten eşit biri olarak bakar.
- Sonuç olarak, daha verimli, daha nitelikli, daha çok talep görüyorsun.
Proje büyüdükçe, vakaların %100'ünde ona gelen, onlara öğreten ve kendi öğrendiğim bilgileri aktaran yeni test uzmanları için akıl hocası oldum. Aynı zamanda, projeye bağlı olarak, yönetimden her zaman en yüksek düzeyde otomatik test uzmanları almadım ve onları otomasyon konusunda eğitmeye (dileyenler için) veya kullanacakları araçlar oluşturmaya ihtiyaç vardı. günlük aktivitelerde (veri oluşturmak ve bunları sisteme yüklemek için araçlar, yük testi/hızlı kararlılık testi yapmak için bir araç, vb.).
Belirli bir proje örneği
Ne yazık ki, gizlilik yükümlülüğü nedeniyle, üzerinde çalıştığım projeler hakkında ayrıntılı olarak konuşamıyorum, ancak projelerden biri üzerindeki tipik Veri Kalitesi Mühendisi görevlerinden örnekler vereceğim.
Projenin özü, makine öğrenimi modellerine dayalı eğitim için veri hazırlamak için bir platform uygulamaktır. Müşteri, ABD'den büyük bir ilaç şirketiydi. Teknik olarak bir kümeydi yükselen örnekler, birkaç mikro hizmet ve EPAM'ın temel Açık Kaynak projesi ile - , belirli bir müşterinin ihtiyaçlarına göre uyarlanmıştır (şimdi proje yeniden doğdu) ). ETL süreçleri kullanılarak organize edildi ve verileri şuradan taşıdı: müşteri sistemleri kovalar. Ardından, yeni verilerle eğitilen ve REST API arabirimini kullanan, işletmeyi ilgilendiren tahminler yayınlayan ve belirli sorunları çözen bir makine öğrenimi modelinin bir liman işçisi görüntüsü platforma dağıtıldı.
Görsel olarak, şöyle bir şeye benziyordu:
Bu projede çok sayıda işlevsel test vardı ve özellik geliştirme hızı ve sürüm döngüsünün hızını koruma ihtiyacı (iki haftalık sprintler) göz önüne alındığında, en kritik sistem düğümlerinin testini otomatikleştirmeyi hemen düşünmek gerekiyordu. . Kubernetes tabanlı platformun çoğu, üzerinde uygulanan otomatik testler kapsamındaydı. + Python, ancak bunların da desteklenmesi ve genişletilmesi gerekiyordu. Ek olarak, müşterinin rahatlığı için, kümeye dağıtılan makine öğrenimi modellerini yönetmek ve model eğitimi için verilerin nereden ve nereye aktarılacağını belirleme yeteneği için bir GUI oluşturuldu. Bu kapsamlı ekleme, çoğunlukla REST API çağrıları ve az sayıda end-2-end UI testi aracılığıyla yapılan otomatik işlevsel kontrollerin genişletilmesini gerektirdi. Tüm bu hareketin ekvatorunda, ürün sürümlerinin kabul testlerinde harika bir iş çıkaran ve müşteriyle bir sonraki sürümün kabulü hakkında iletişim kuran bir manuel test uzmanı bize katıldı. Ayrıca, yeni bir uzmanın gelmesi sayesinde çalışmalarımızı belgeleyebildik ve hemen otomatikleştirilmesi zor olan bazı çok önemli manuel kontrolleri ekleyebildik.
Ve son olarak, platformdan ve onun üzerindeki GUI eklentisinden kararlılık elde ettikten sonra, Apache Airflow DAG'leri kullanarak ETL işlem hatları oluşturmaya başladık. ETL işleminin sonuçlarına dayalı olarak verileri kontrol eden özel Airflow DAG'leri yazılarak otomatik veri kalitesi kontrolü gerçekleştirildi. Bu projenin bir parçası olarak şanslıydık ve müşteri bize üzerinde test ettiğimiz anonimleştirilmiş veri setlerine erişim sağladı. Tür uyumluluğu, bozuk verilerin varlığı, önceki ve sonraki toplam kayıt sayısı, toplama için ETL işlemi tarafından gerçekleştirilen dönüşümlerin karşılaştırması, sütun adlarını değiştirme vb. için verileri satır satır kontrol ettik. Ek olarak, bu kontroller, örneğin SalesForce'a ek olarak MySQL üzerinde de farklı veri kaynaklarına göre ölçeklendirildi.
Nihai veri kalitesi kontrolleri, depolandıkları ve makine öğrenimi modellerini eğitmek için kullanıma hazır durumda oldukları S3 düzeyinde zaten gerçekleştirildi. S3 Kovasında bulunan son CSV dosyasından veri almak ve doğrulamak için kullanılarak bir kod yazılmıştır. .
Ayrıca müşteri tarafında, verilerin bir kısmını bir S3 Kovasında, bir kısmını da diğerinde saklama gereksinimi vardı. Bu, aynı zamanda, bu tür sıralamanın güvenilirliğini kontrol eden ek kontrollerin yazılmasını da gerektiriyordu.
Diğer projelerde genelleştirilmiş deneyim
Bir Veri Kalitesi mühendisinin en genelleştirilmiş faaliyet listesine bir örnek:
- Test verilerini (geçerli, geçersiz, büyük, küçük) otomatik bir araçla hazırlayın.
- Hazırlanan veri setini orijinal kaynağa yükleyin ve kullanıma hazır olup olmadığını kontrol edin.
- Belirli bir ayar seti kullanarak (mümkünse, ETL görevi için yapılandırılabilir parametreleri ayarlayın) kaynak depolamadan son veya ara veri setine kadar bir veri setini işlemek için ETL işlemlerini başlatın.
- ETL süreci tarafından işlenen verilerin kalitesi ve iş gereksinimlerine uygunluğu açısından doğrulayın.
Aynı zamanda, kontrollerin ana odağı yalnızca sistemdeki veri akışının prensipte çalıştığı ve sona ulaştığı (işlevsel testin bir parçası olan) değil, çoğunlukla üzerinde olmalıdır. verilerin beklenen gereksinimlere uygunluk açısından kontrol edilmesi ve doğrulanması, anormalliklerin ve diğer şeylerin belirlenmesi.
Araçlar
Bu tür veri kontrolüne yönelik tekniklerden biri, literatürde "veri zinciri" olarak adlandırılan veri işlemenin her aşamasında zincir kontrollerin organizasyonu olabilir - verilerin kaynaktan son kullanım noktasına kadar kontrolü. Bu tür kontroller çoğunlukla doğrulayıcı SQL sorguları yazarak uygulanır. Bu tür sorguların olabildiğince basit olması ve veri kalitesinin tek tek parçalarını kontrol etmesi gerektiği açıktır (meta veriler, boş satırlar, NULL'lar, söz dizimindeki hatalar - kontrol edilmesi gereken diğer öznitelikler).
Hazır (değişmemiş, biraz değiştirilmiş) veri kümelerinin kullanıldığı regresyon testi durumunda, otomatik test kodu, verilerin kaliteye uygunluğunu kontrol etmek için hazır şablonları saklayabilir (beklenen tablo meta verilerinin açıklamaları; kullanılabilecek dize örnek nesneleri). test sırasında rastgele seçilen vb.).
Ayrıca, test sırasında, Apache Airflow gibi çerçeveleri kullanarak test ETL süreçleri yazmanız gerekir. hatta bir kara kutu bulut aracı gibi , Ve benzeri. Bu durum, test mühendisinin yukarıdaki araçların çalışma ilkelerini derinlemesine incelemesine ve hem işlevsel testleri (örneğin, projede mevcut olan ETL süreçleri) hem de bunları verileri kontrol etmek için kullanmasına daha da etkili bir şekilde zorlar. Özellikle Apache Airflow, popüler analitik veritabanlarıyla çalışmak için hazır operatörlere sahiptir, örneğin . Kullanımının en temel örneği zaten özetlenmiştir. bu yüzden kendimi tekrar etmeyeceğim.
Hazır çözümlere ek olarak, tekniklerinizi ve araçlarınızı uygulamanızı kimse yasaklamaz. Bu sadece proje için değil, aynı zamanda teknik görünümünü ve kodlama becerilerini geliştirecek olan Veri Kalitesi Mühendisinin kendisi için de faydalı olacaktır.
Gerçek bir projede nasıl çalışır?
"Veri zinciri", ETL ve her yerde bulunan kontroller hakkındaki son paragrafların iyi bir örneği, gerçek projelerden birindeki aşağıdaki süreçtir:
Burada farklı veriler (doğal olarak bizim tarafımızdan hazırlanmış) sistemimizin “huni” girişine girer: geçerli, geçersiz, karışık vb. dönüşümler ve nihai depolamaya yerleştirilir , bu da analitik, veri pazarları oluşturmak ve iş içgörüleri aramak için kullanılacaktır. Böyle bir sistemde, ETL süreçlerinin çalışmasını işlevsel olarak kontrol etmeden, dönüşümlerden önceki ve sonraki verilerin kalitesine ve analitik çıktılarına odaklanıyoruz.
Yukarıdakileri özetlemek gerekirse, çalıştığım yerlerden bağımsız olarak, dahil olduğum her yerde aşağıdaki özellikleri birleştiren Veri projeleri:
- Yalnızca otomasyon yoluyla bazı durumlar test edilebilir ve işletme için kabul edilebilir bir sürüm döngüsü elde edilebilir.
- Böyle bir projedeki test uzmanı, ekibin en saygın üyelerinden biridir çünkü her bir katılımcıya büyük faydalar sağlar (testin hızlandırılması, iyi Veri Bilimcisi verileri, kusurların erken tespiti).
- Kendi donanımınız üzerinde veya bulutta çalışmanız fark etmez; tüm kaynaklar Hortonworks, Cloudera, Mesos, Kubernetes vb. gibi bir kümeye ayrılmıştır.
- Projeler bir mikro hizmet yaklaşımı üzerine kuruludur, dağıtılmış ve paralel bilgi işlem hakimdir.
Veri Kalitesi alanında test yaparken, bir test uzmanının profesyonel odağını ürün koduna ve kullanılan araçlara kaydırdığını belirtmek isterim.
Veri Kalitesi Testinin Ayırt Edici Özellikleri
Ek olarak, kendim için, Veri (Büyük Veri) projelerinde (sistemlerinde) ve diğer alanlarda test etmenin aşağıdaki ayırt edici özelliklerini (hemen ÇOK genelleştirilmiş ve son derece öznel) belirledim:
Faydalı linkler
- teori: .
- EPAM
- Yeni başlayan bir Veri Kalitesi Mühendisi için önerilen malzemeler:
- Stepik'te ücretsiz kurs: .
- LinkedIn Learning Kursu: .
- Makaleler:
- ;
- ;
- ;
- Video:
- ;
- ;
Sonuç
Veri kalitesi parçası olmak, bir start-up'ın parçası olmak anlamına gelen, çok genç ve gelecek vaat eden bir yön. Veri Kalitesine girdikten sonra, çok sayıda modern talep gören teknolojiye dalacaksınız, ancak en önemlisi, fikirlerinizi üretmek ve uygulamak için çok büyük fırsatlarınız olacak. Sürekli iyileştirme yaklaşımını sadece projede değil, kendiniz için de kullanabilecek, uzman olarak sürekli gelişebileceksiniz.
Kaynak: habr.com