Pozdrav svima, moje ime je Aleksandar i ja sam inženjer kvaliteta podataka koji provjerava kvalitet podataka. Ovaj članak će govoriti o tome kako sam došao do toga i zašto je 2020. ovo područje testiranja bilo na vrhuncu vala.
Globalni trend
Današnji svijet doživljava još jednu tehnološku revoluciju, čiji je jedan aspekt korištenje akumuliranih podataka od strane svih vrsta kompanija za promoviranje vlastitog zamajca prodaje, profita i PR-a. Čini se da su prisustvo dobrih (kvalitetnih) podataka, kao i vješti mozgovi koji od njih mogu zaraditi (ispravno obrađivati, vizualizirati, graditi modele strojnog učenja itd.), danas mnogima postali ključ uspjeha. Ako su se prije 15-20 godina velike kompanije uglavnom bavile intenzivnim radom na akumulaciji podataka i monetizaciji, danas je to sudbina gotovo svih zdravih ljudi.
S tim u vezi, prije nekoliko godina, svi portali posvećeni traženju posla širom svijeta počeli su da se popunjavaju slobodnim radnim mjestima za Data Scientists, jer su svi bili sigurni da će, unajmivši takvog stručnjaka, biti moguće izgraditi supermodel mašinskog učenja , predvidjeti budućnost i izvršiti "kvantni skok" za kompaniju. S vremenom su ljudi shvatili da ovaj pristup gotovo nikada nigdje ne funkcionira, jer nisu svi podaci koji padaju u ruke takvih stručnjaka prikladni za modele obuke.
I počeli su zahtjevi Data Scientists: “Hajde da kupimo više podataka od ovih i onih...”, “Nemamo dovoljno podataka...”, “Treba nam još podataka, po mogućnosti kvalitetnih...” . Na osnovu ovih zahtjeva počele su se graditi brojne interakcije između kompanija koje posjeduju jedan ili drugi skup podataka. Naravno, to je zahtijevalo tehničku organizaciju ovog procesa – povezivanje sa izvorom podataka, njegovo preuzimanje, provjeru da li je učitan u potpunosti, itd. Broj ovakvih procesa je počeo rasti, a danas imamo ogromnu potrebu za još jednom vrstom specijalisti - Inženjeri kvaliteta podataka - oni koji bi pratili protok podataka u sistemu (data pipelines), kvalitet podataka na ulazu i izlazu, i izvlačili zaključke o njihovoj dovoljnosti, integritetu i drugim karakteristikama.
Trend za inženjere kvaliteta podataka došao nam je iz SAD-a, gdje, usred bijesne ere kapitalizma, niko nije spreman izgubiti bitku za podatke. U nastavku sam dao snimke ekrana sa dvije najpopularnije stranice za traženje posla u SAD-u: и — koji prikazuje podatke na dan 17. marta 2020. o broju objavljenih slobodnih radnih mjesta zaprimljenih pomoću ključnih riječi: Kvalitet podataka i Data Scientist.
Data Scientists – 21416 slobodnih radnih mjesta
Kvalitet podataka – 41104 slobodnih radnih mjesta
Data Scientists – 404 slobodna radna mjesta
Kvalitet podataka – 2020 slobodnih radnih mjesta
Očigledno je da se ove profesije ni na koji način ne nadmeću jedna s drugom. Snimcima ekrana sam samo želio da ilustrujem trenutnu situaciju na tržištu rada u smislu zahtjeva za inženjere kvaliteta podataka, kojih je sada potrebno mnogo više nego Data Scientists.
U junu 2019. EPAM je, odgovarajući na potrebe savremenog IT tržišta, izdvojio kvalitet podataka u zasebnu praksu. Inženjeri kvaliteta podataka u svakodnevnom radu upravljaju podacima, provjeravaju njihovo ponašanje u novim uslovima i sistemima, prate relevantnost podataka, njihovu dovoljnost i relevantnost. Uz sve to, u praktičnom smislu, inženjeri kvaliteta podataka zaista posvećuju malo vremena klasičnom funkcionalnom testiranju, BUT ovo uvelike ovisi o projektu (navest ću primjer u nastavku).
Odgovornosti inženjera kvaliteta podataka nisu ograničene samo na rutinske ručne/automatske provjere za „nulte, brojanje i sume“ u tabelama baze podataka, već zahtijevaju duboko razumijevanje poslovnih potreba korisnika i, shodno tome, sposobnost transformacije dostupnih podataka u korisne poslovne informacije.
Teorija kvaliteta podataka
Da bismo potpunije zamislili ulogu takvog inženjera, hajde da shvatimo šta je kvaliteta podataka u teoriji.
Kvalitet podataka — jedna od faza upravljanja podacima (cijeli svijet koji ćemo vam ostaviti da sami proučavate) i odgovoran je za analizu podataka prema sljedećim kriterijima:
Mislim da nema potrebe dešifrirati svaku od tačaka (u teoriji se zovu “dimenzije podataka”), prilično su dobro opisane na slici. Ali sam proces testiranja ne podrazumijeva striktno kopiranje ovih karakteristika u test slučajeve i njihovu provjeru. U kvaliteti podataka, kao iu svakom drugom tipu testiranja, potrebno je, prije svega, graditi na zahtjevima kvaliteta podataka dogovorenim sa učesnicima projekta koji donose poslovne odluke.
U zavisnosti od projekta kvaliteta podataka, inženjer može obavljati različite funkcije: od običnog automatizatora sa površnom procenom kvaliteta podataka, do osobe koja vrši dubinsko profilisanje podataka prema gore navedenim kriterijumima.
Vrlo detaljan opis upravljanja podacima, kvaliteta podataka i povezanih procesa dobro je opisan u knjizi pod nazivom "DAMA-DMBOK: Zbir znanja o upravljanju podacima: 2. izdanje". Toplo preporučujem ovu knjigu kao uvod u ovu temu (link do nje ćete naći na kraju članka).
Moja prica
U IT industriji, napredovao sam od mlađeg testera u kompanijama za proizvode do vodećeg inženjera kvaliteta podataka u EPAM-u. Nakon otprilike dvije godine rada kao tester, imao sam čvrsto uvjerenje da sam uradio apsolutno sve vrste testiranja: regresijsko, funkcionalno, stresno, stabilnostno, sigurnosno, korisničko sučelje, itd. - i isprobao veliki broj alata za testiranje, imajući radio u isto vreme u tri programska jezika: Java, Scala, Python.
Gledajući unatrag, razumijem zašto je moj skup vještina bio toliko raznolik – bio sam uključen u projekte vođene podacima, velike i male. To je ono što me dovelo u svijet mnogih alata i mogućnosti za rast.
Da biste se uvjerili u raznolikost alata i mogućnosti za stjecanje novih znanja i vještina, samo pogledajte sliku ispod, koja prikazuje one najpopularnije u svijetu „Data & AI“.
Ovakvu ilustraciju svake godine sastavlja jedan od poznatih rizičnih kapitalista Matt Turck, koji dolazi iz razvoja softvera. Evo na njegov blog i , gdje radi kao partner.
Profesionalno sam posebno brzo rastao kada sam bio jedini tester na projektu, ili barem na početku projekta. U takvom trenutku morate biti odgovorni za cijeli proces testiranja i nemate mogućnosti da se povučete, samo naprijed. U početku je bilo zastrašujuće, ali sada su mi očigledne sve prednosti takvog testa:
- Počinjete komunicirati sa cijelim timom kao nikada prije, jer nema proxyja za komunikaciju: ni test menadžera ni kolega testera.
- Uranjanje u projekat postaje nevjerovatno duboko, a imate informacije o svim komponentama, kako općenito tako i u detaljima.
- Programeri ne gledaju na vas kao na "onog tipa iz testiranja koji ne zna šta radi", već kao na ravnog koji proizvodi nevjerovatne prednosti za tim svojim automatiziranim testovima i predviđanjem da se greške pojavljuju u određenoj komponenti proizvod.
- Kao rezultat toga, vi ste efikasniji, kvalifikovaniji i traženiji.
Kako je projekat rastao, u 100% slučajeva sam postajao mentor novim testerima, podučavao ih i prenosio znanje koje sam sam naučio. Istovremeno, u zavisnosti od projekta, nisam uvek dobijao najviši nivo stručnjaka za autotestiranje od menadžmenta i postojala je potreba da ih obučim za automatizaciju (za zainteresovane) ili kreiram alate za upotrebu u svakodnevnim aktivnostima (alati za generisanje podataka i njihovo učitavanje u sistem, alat za "brzo" izvođenje testiranja opterećenja/testiranja stabilnosti itd.).
Primjer konkretnog projekta
Nažalost, zbog obaveze neotkrivanja podataka, ne mogu detaljnije govoriti o projektima na kojima sam radio, ali ću navesti primjere tipičnih zadataka inženjera kvaliteta podataka na jednom od projekata.
Suština projekta je implementacija platforme za pripremu podataka za obuku zasnovanih na modelima mašinskog učenja. Kupac je bila velika farmaceutska kompanija iz SAD-a. Tehnički je to bila klaster , diže se do instance, sa nekoliko mikroservisa i osnovnim Open Source projektom EPAM-a - , prilagođen potrebama konkretnog kupca (sada je projekat preporođen u ). ETL procesi su organizirani korištenjem i premješteni podaci iz sistemi kupaca u Kante. Zatim je na platformu postavljena Docker slika modela strojnog učenja, koja je obučena na svježim podacima i, koristeći REST API sučelje, proizvela je predviđanja koja su bila od interesa za posao i rješavala specifične probleme.
Vizuelno je sve izgledalo otprilike ovako:
Na ovom projektu je bilo dosta funkcionalnog testiranja, a s obzirom na brzinu razvoja karakteristika i potrebu da se održi tempo ciklusa izdavanja (dvonedeljni sprintovi), bilo je potrebno odmah razmišljati o automatizaciji testiranja najkritičnijih komponenti sistem. Većina same platforme zasnovane na Kubernetesu bila je pokrivena autotestovima implementiranim u + Python, ali ih je također bilo potrebno podržati i proširiti. Pored toga, za praktičnost korisnika, kreiran je GUI za upravljanje modelima mašinskog učenja koji su raspoređeni u klaster, kao i mogućnost da se specificira gde i gde treba preneti podatke za obuku modela. Ovaj opsežni dodatak je uključivao proširenje automatskog funkcionalnog testiranja, koje je uglavnom obavljeno putem REST API poziva i malog broja end-2-end UI testova. Na ekvatoru svih ovih kretanja pridružio nam se i ručni tester koji je odlično obavio testiranje prihvatljivosti verzija proizvoda i komunikaciju s kupcem u vezi prihvatanja sljedećeg izdanja. Osim toga, zahvaljujući dolasku novog stručnjaka, uspjeli smo dokumentirati svoj rad i dodati nekoliko vrlo važnih ručnih provjera koje je bilo teško odmah automatizirati.
I konačno, nakon što smo postigli stabilnost platforme i GUI dodatka preko nje, počeli smo graditi ETL cjevovode koristeći Apache Airflow DAG-ove. Automatska provjera kvaliteta podataka izvršena je pisanjem posebnih Airflow DAG-ova koji su provjeravali podatke na osnovu rezultata ETL procesa. U sklopu ovog projekta imali smo sreće i kupac nam je dao pristup anonimiziranim skupovima podataka na kojima smo testirali. Provjeravali smo red po red podataka za usklađenost s tipovima, prisustvo pokvarenih podataka, ukupan broj zapisa prije i poslije, poređenje transformacija napravljenih ETL procesom za agregaciju, promjenu naziva kolona i druge stvari. Osim toga, ove provjere su skalirane na različite izvore podataka, na primjer, pored SalesForcea, također i na MySQL.
Konačne provjere kvaliteta podataka provedene su već na nivou S3, gdje su pohranjeni i spremni za korištenje za obuku modela mašinskog učenja. Za dobijanje podataka iz konačne CSV datoteke koja se nalazi na S3 Bucket-u i njihovu validaciju, kod je napisan pomoću .
Također je postojao zahtjev od strane kupca da dio podataka pohrani u jednu S3 Bucket, a dio u drugu. To je također zahtijevalo pisanje dodatnih provjera kako bi se provjerila pouzdanost takvog sortiranja.
Uopšteno iskustvo sa drugih projekata
Primjer najopćenitije liste aktivnosti inženjera kvalitete podataka:
- Pripremite testne podatke (važeći nevažeći veliki mali) putem automatiziranog alata.
- Učitajte pripremljeni skup podataka u originalni izvor i provjerite da li je spreman za upotrebu.
- Pokrenite ETL procese za obradu skupa podataka od izvorne memorije do konačnog ili međuskladišta koristeći određeni skup postavki (ako je moguće, postavite konfigurabilne parametre za ETL zadatak).
- Provjeriti kvalitetu podataka koje obrađuje ETL proces i njihovu usklađenost s poslovnim zahtjevima.
Pri tome, glavni fokus provjera ne bi trebao biti samo na činjenici da je tok podataka u sistemu u principu proradio i došao do kraja (što je dio funkcionalnog testiranja), već najviše na provjeri i validaciji podataka. za usklađenost sa očekivanim zahtjevima, utvrđivanje anomalija i drugo.
Alati
Jedna od tehnika za takvu kontrolu podataka može biti organizacija lančanih provjera u svakoj fazi obrade podataka, takozvani „lanac podataka“ u literaturi – kontrola podataka od izvora do tačke konačne upotrebe. Ove vrste provjera se najčešće implementiraju pisanjem provjeravajućih SQL upita. Jasno je da takvi upiti treba da budu što lakši i da proveravaju kvalitet pojedinačnih podataka (metapodaci tabela, prazni redovi, NULL-ovi, greške u sintaksi - ostali atributi potrebni za proveru).
U slučaju regresijskog testiranja, koje koristi gotove (nepromjenjive, malo promjenjive) skupove podataka, kod za autotest može pohraniti gotove predloške za provjeru usklađenosti podataka sa kvalitetom (opisi očekivanih metapodataka tablice; uzorci reda objekata koji se mogu nasumično odabrano tokom testa, itd.).
Takođe, tokom testiranja, morate pisati ETL testne procese koristeći okvire kao što su Apache Airflow, ili čak alat tipa oblaka crne kutije , I tako dalje. Ova okolnost primorava inženjera za testiranje da se udubi u principe rada gore navedenih alata i još efikasnije i provede funkcionalno testiranje (na primjer, postojeći ETL procesi na projektu) i koristi ih za provjeru podataka. Apache Airflow posebno ima gotove operatere za rad sa popularnim analitičkim bazama podataka, na primjer . Najosnovniji primjer njegove upotrebe je već naveden , pa se neću ponavljati.
Osim gotovih rješenja, niko vam ne brani da implementirate vlastite tehnike i alate. Ovo neće biti od koristi samo za projekat, već i za samog Inženjera kvaliteta podataka, koji će na taj način poboljšati svoje tehničke horizonte i veštine kodiranja.
Kako to funkcionira na pravom projektu
Dobra ilustracija zadnjih paragrafa o „lancu podataka“, ETL-u i sveprisutnim provjerama je sljedeći proces iz jednog od stvarnih projekata:
Ovdje razni podaci (naravno, pripremljeni od nas) ulaze u ulazni “lijevak” našeg sistema: važeći, nevažeći, miješani itd., zatim se filtriraju i završavaju u međuskladištu, zatim ponovo prolaze kroz niz transformacija i smješteni su u završnu memoriju iz koje će se, zauzvrat, vršiti analitika, izgradnja podatkovnih vitrina i traženje poslovnih uvida. U takvom sistemu, bez funkcionalne provere rada ETL procesa, fokusiramo se na kvalitet podataka pre i posle transformacije, kao i na izlaz u analitiku.
Da sumiramo gore navedeno, bez obzira na mjesto gdje sam radio, svuda sam bio uključen u Data projekte koji su dijelili sljedeće karakteristike:
- Samo kroz automatizaciju možete testirati neke slučajeve i postići ciklus izdavanja prihvatljiv za poslovanje.
- Tester na ovakvom projektu jedan je od najcjenjenijih članova tima, jer donosi velike koristi svakom od učesnika (ubrzanje testiranja, dobri podaci od Data Scientista, identifikacija nedostataka u ranim fazama).
- Nije bitno da li radite na svom hardveru ili u oblacima - svi resursi se apstrahuju u klaster kao što su Hortonworks, Cloudera, Mesos, Kubernetes, itd.
- Projekti su izgrađeni na mikroservisnom pristupu, preovlađuju distribuirano i paralelno računarstvo.
Želeo bih da napomenem da kada vrši testiranje u oblasti kvaliteta podataka, stručnjak za testiranje prebacuje svoj profesionalni fokus na kod proizvoda i alate koji se koriste.
Posebne karakteristike testiranja kvaliteta podataka
Pored toga, za sebe sam identifikovao sledeće (odmah ću rezervisati da su VRLO generalizovane i isključivo subjektivne) karakteristične karakteristike testiranja u Data (Big Data) projektima (sistemima) i drugim oblastima:
korisni linkovi
- Teorija: .
- EPAM
- Preporučeni materijali za inženjera kvaliteta podataka početnika:
- Besplatan kurs o Stepiku: .
- Kurs o LinkedIn Learningu: .
- Članci:
- ;
- ;
- ;
- Video:
- ;
- ;
zaključak
Kvalitet podataka je vrlo mlad smjer koji obećava, čiji dio znači biti dio startupa. Kada jednom uđete u kvalitet podataka, bit ćete uronjeni u veliki broj modernih, traženih tehnologija, ali što je najvažnije, otvorit će vam se ogromne mogućnosti za generiranje i implementaciju vaših ideja. Bićete u mogućnosti da koristite pristup kontinuiranog poboljšanja ne samo na projektu, već i za sebe, kontinuirano se razvijajući kao specijalista.
izvor: www.habr.com