Pozdrav svima, moje ime je Alexander i ja sam inženjer kvalitete podataka koji provjerava kvalitetu podataka. Ovaj članak će govoriti o tome kako sam došao do ovoga 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 tvrtki kako bi vrtile vlastiti kotač zamašnjak prodaje, profita i PR-a. Čini se da su upravo dostupnost dobrih (kvalitetnih) podataka, kao i vješti mozgovi koji na njima mogu zaraditi (ispravno obraditi, vizualizirati, izgraditi modele strojnog učenja itd.), mnogima danas postali ključ uspjeha. Ako su se prije 15-20 godina velike tvrtke uglavnom bavile intenzivnim radom na prikupljanju podataka i njihovoj monetizaciji, danas je to sudbina gotovo svih zdravorazumskih ljudi.
S tim u vezi, prije nekoliko godina, svi portali za traženje posla diljem svijeta počeli su biti preplavljeni natječajima Data Scientists, jer su svi bili uvjereni da se dolaskom takvog stručnjaka u svoje osoblje može izgraditi supermodel strojnog učenja, predvidjeti budućnost i napraviti "kvantni skok" za tvrtku. S vremenom su ljudi shvatili da ovaj pristup gotovo nikada ne funkcionira, budući da daleko od svih podataka koji padnu u ruke takvih stručnjaka nisu prikladni za modele obuke.
I krenuli su zahtjevi Data Scientistsa: “Kupimo još podataka od ovih i onih…”, “Nemamo dovoljno podataka…”, “Trebamo još malo podataka i po mogućnosti kvalitetnih…”. Na temelju tih zahtjeva počele su se graditi brojne interakcije između tvrtki koje posjeduju jedan ili drugi skup podataka. Naravno, to je zahtijevalo tehničku organizaciju ovog procesa - spojiti se na izvor podataka, preuzeti ih, provjeriti jesu li učitani u cijelosti itd. Broj takvih procesa počeo je rasti, a danas imamo veliku potrebu za drugom vrstom specijalista - Data Quality Engineers - oni koji bi pratili tijek podataka u sustavu (data pipeline), kvalitetu podataka na ulazu i izlazu, donosili zaključke o njihovoj dostatnosti, cjelovitosti i drugim karakteristikama.
Trend kvalitete podataka inženjera došao nam je iz SAD-a, gdje usred bijesne ere kapitalizma nitko nije spreman izgubiti bitku za podatke. U nastavku donosim snimke zaslona s dvije najpopularnije stranice za traženje posla u SAD-u: и - koji prikazuju podatke na dan 17. ožujka 2020. o broju zaprimljenih objavljenih slobodnih radnih mjesta, za ključne riječi: Data Quality i Data Scientist.
Data Scientists – 21416 slobodnih radnih mjesta
Kvaliteta podataka – 41104 slobodnih radnih mjesta
Data Scientists – 404 slobodna mjesta
Kvaliteta podataka - 2020 slobodnih radnih mjesta
Očito, te profesije ni na koji način ne konkuriraju jedna drugoj. Snimkama zaslona samo sam htio ilustrirati trenutno stanje na tržištu rada u smislu zahtjeva za Data Quality inženjerima, koji su sada puno potrebniji od Data Scientista.
U lipnju 2019. EPAM je, odgovarajući na potrebe suvremenog IT tržišta, izdvojio Data Quality kao zasebnu praksu. Inženjeri kvalitete podataka u svakodnevnom radu upravljaju podacima, provjeravaju njihovo ponašanje u novim uvjetima i sustavima, kontroliraju relevantnost podataka, njihovu dostatnost i relevantnost. Uz sve to, u praktičnom smislu, inženjeri kvalitete podataka posvećuju malo vremena klasičnom funkcionalnom testiranju, ALI to jako ovisi o projektu (u nastavku ću dati primjer).
Dužnosti inženjera za kvalitetu podataka nisu ograničene na rutinske ručne/automatske provjere za "nula, zbrojeve i zbrojeve" u tablicama baze podataka, već zahtijevaju duboko razumijevanje poslovnih potreba korisnika i, sukladno tome, sposobnost pretvaranja dostupnih podataka u korisne poslovne informacije.
Teorija kvalitete podataka
Kako bismo što potpunije zamislili ulogu takvog inženjera, shvatimo što je kvaliteta podataka u teoriji.
Kvaliteta podataka - jedna od faza Upravljanja podacima (cijeli svijet koji ćemo Vam ostaviti na samostalno proučavanje) i odgovoran je za analizu podataka prema sljedećim kriterijima:
Mislim da ne vrijedi dešifrirati svaku od točaka (u teoriji se zovu "dimenzije podataka"), prilično su dobro opisane na slici. Ali sam proces testiranja ne podrazumijeva striktno kopiranje ovih značajki u testne slučajeve i njihovu provjeru. Kod Data Qualitya, kao i kod svake druge vrste testiranja, potrebno je prije svega graditi na zahtjevima kvalitete podataka dogovorenim sa sudionicima projekta koji donose poslovne odluke.
Ovisno o projektu kvalitete podataka, inženjer može obavljati različite funkcije: od običnog ispitivača-automatatora s površnom procjenom kvalitete podataka do osobe koja provodi njihovo dubinsko profiliranje prema gore navedenim kriterijima.
Vrlo detaljan opis procesa upravljanja podacima, kvalitete podataka i povezanih procesa dobro je opisan u knjizi pod nazivom "DAMA-DMBOK: Zbirka znanja o upravljanju podacima: 2. izdanje". Toplo preporučujem ovu knjigu kao uvod u ovu temu (naći ćete poveznicu na nju na kraju članka).
Moja priča
U IT industriji prošao sam put od Junior QA u proizvodnim tvrtkama do Lead Data Quality Engineer u EPAM-u. Nakon otprilike dvije godine kao tester, bio sam čvrsto uvjeren da sam radio apsolutno sve vrste testiranja: regresijsko, funkcionalno, stres, stabilnost, sigurnost, korisničko sučelje, itd. - i isprobao velik broj alata za testiranje, nakon što sam radio u tri programska jezika: Java, Scala, Python.
Gledajući unatrag, shvaćam zašto je moj set vještina tako raznolik - bio sam uključen u podatkovne projekte, velike i male. To je ono što me dovelo u svijet puno alata i prilika za rast.
Da biste cijenili raznolikost alata i mogućnosti za stjecanje novih znanja i vještina, samo pogledajte sliku ispod koja prikazuje najpopularnije od njih u svijetu "Data & AI".
Ovu vrstu ilustracije svake godine proizvodi jedan od poznatih investitora rizičnog kapitala Matt Turck, rođen u razvoju softvera. Ovdje na svoj blog i gdje radi kao partner.
Posebno brzo sam profesionalno rastao kada sam bio jedini tester na projektu, ili barem na početku projekta. Upravo u ovom trenutku vi morate biti odgovorni za cijeli proces testiranja i nemate mogućnosti za povlačenje, samo naprijed. U početku je bilo zastrašujuće, ali sada su mi očite sve prednosti takvog testa:
- Počinjete komunicirati s cijelim timom kao nikad prije, budući da ne postoji posrednik za komunikaciju: ni voditelj testiranja ni kolege testeri.
- Uranjanje u projekt postaje nevjerojatno duboko, a imate informacije o svim komponentama općenito i detaljno.
- Razvojni programeri na vas ne gledaju kao na "onog testnog tipa koji ne zna što radi", već kao na ravnopravnog, koji stvara nevjerojatnu vrijednost za tim svojim autotestovima i predviđanjem grešaka u određenom čvoru proizvoda.
- Kao rezultat toga, vi ste učinkovitiji, kvalificiraniji, više traženi.
Kako je projekt rastao, u 100% slučajeva postao sam mentor novim testerima koji su dolazili u njega, podučavali ih i prenosili im znanje koje sam i sam naučio. U isto vrijeme, ovisno o projektu, od uprave nisam uvijek dobivao stručnjake za automatsko testiranje na najvišoj razini i bilo je potrebno ili ih obučiti za automatizaciju (za one koji žele) ili stvoriti alate za njihovu upotrebu u svakodnevnim aktivnostima (alati za generiranje podataka i njihovo učitavanje u sustav, alat za provođenje testa opterećenja/brzog testa stabilnosti itd.).
Primjer konkretnog projekta
Nažalost, zbog tajnosti podataka, ne mogu detaljno govoriti o projektima na kojima sam radio, ali ću navesti primjere tipičnih zadataka Data Quality Engineera na jednom od projekata.
Bit projekta je implementacija platforme za pripremu podataka za obuku temeljene na modelima strojnog učenja. Kupac je bila velika farmaceutska tvrtka iz SAD-a. Tehnički je to bio klaster dižući se do instance, s nekoliko mikroservisa i temeljnim projektom otvorenog koda iz EPAM-a - , prilagođen potrebama pojedinog kupca (sada je projekt ponovno rođen u ). ETL procesi organizirani su pomoću i premješteni podaci iz korisničkih sustava u kante. Zatim je docker slika modela strojnog učenja postavljena na platformu, koja je obučena na svježim podacima i, koristeći sučelje REST API, izdala je predviđanja koja su bila od interesa za poslovanje i riješila specifične probleme.
Vizualno je to izgledalo otprilike ovako:
Bilo je dosta funkcionalnog testiranja na ovom projektu, a s obzirom na brzinu razvoja značajki i potrebu održavanja tempa ciklusa izdanja (dvotjedni sprintovi), bilo je potrebno odmah razmišljati o automatizaciji testiranja najkritičnijih čvorova sustava. . Većina same platforme temeljene na Kubernetesu bila je pokrivena autotestovima implementiranim na + Python, ali i njih je trebalo podržati i proširiti. Osim toga, radi praktičnosti korisnika, kreiran je GUI za upravljanje modelima strojnog učenja raspoređenim u klaster, kao i mogućnost određivanja odakle i gdje prenijeti podatke za obuku modela. Ovaj opsežni dodatak podrazumijevao je proširenje automatiziranih funkcionalnih provjera, koje su se uglavnom provodile putem REST API poziva i malog broja end-2-end UI testova. Na ekvatoru cijelog ovog kretanja pridružio nam se ručni tester koji je odlično obavio testiranje prihvatljivosti verzija proizvoda i komunicirao s kupcem o prihvaćanju sljedećeg izdanja. Osim toga, dolaskom novog specijalista uspjeli smo dokumentirati svoj rad i dodati neke vrlo važne ručne provjere 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. Automatizirana provjera kvalitete podataka provedena je pisanjem posebnih Airflow DAG-ova koji provjeravaju podatke na temelju rezultata ETL procesa. U sklopu ovog projekta imali smo sreće pa nam je kupac omogućio pristup anonimiziranim skupovima podataka na kojima smo testirali. Provjerili smo redak po redak podataka za usklađenost tipa, prisutnost pokvarenih podataka, ukupan broj zapisa prije i poslije, usporedbu transformacija koje je izvršio ETL proces za agregaciju, promjenu naziva stupaca i tako dalje. Osim toga, te su provjere skalirane na različite izvore podataka, primjerice, uz SalesForce, također i na MySQL.
Konačne provjere kvalitete podataka provedene su već na S3 razini, gdje su pohranjeni i bili su u stanju spremni za korištenje za obuku modela strojnog učenja. Da biste dobili podatke iz konačne CSV datoteke koja se nalazi na S3 Bucketu i potvrdili je, napisan je kod pomoću .
Također, od strane korisnika postojao je zahtjev za pohranjivanjem dijela podataka u jedan S3 Bucket, a dijela u drugi. To je također zahtijevalo pisanje dodatnih provjera koje kontroliraju pouzdanost takvog sortiranja.
Općenito iskustvo na drugim projektima
Primjer najopćenitijeg popisa 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 izvorni izvor i provjerite njegovu spremnost za korištenje.
- Pokrenite ETL procese za obradu skupa podataka od izvorne pohrane do konačne ili posredne pomoću određenog skupa postavki (ako je moguće, postavite konfigurabilne parametre za ETL zadatak).
- Provjerite kvalitetu podataka koje obrađuje ETL proces i sukladnost s poslovnim zahtjevima.
Istovremeno, glavni fokus provjera ne bi trebao biti samo na činjenici da je tijek podataka u sustavu, u načelu, funkcionirao i došao do kraja (što je dio funkcionalnog testiranja), već najvećim dijelom na provjera i validacija podataka za usklađenost s očekivanim zahtjevima, identificiranje anomalija i drugo.
Alat
Jedna od tehnika takve kontrole podataka može biti organiziranje lančanih provjera u svakoj fazi obrade podataka, u literaturi tzv. „lanac podataka“ – kontrola podataka od izvora do točke konačne uporabe. Takve se provjere najčešće provode pisanjem potvrđujućih SQL upita. Jasno je da bi takvi upiti trebali biti što lakši i provjeravati kvalitetu pojedinačnih dijelova podataka (metapodaci tablica, prazni redovi, NULL-ovi, pogreške u sintaksi - drugi atributi potrebni za provjeru).
U slučaju regresijskog testiranja, koje koristi gotove (nepromijenjene, malo promijenjene) skupove podataka, kod za automatsko testiranje može pohraniti gotove predloške za provjeru usklađenosti podataka s kvalitetom (opisi očekivanih metapodataka tablice; objekti uzorka niza koji se mogu nasumično odabrani tijekom testa itd.).
Također, tijekom testiranja morate napisati testne ETL procese koristeći okvire kao što su Apache Airflow, ili čak alat crne kutije u oblaku poput , I tako dalje. Ova okolnost tjera testnog inženjera da zaroni u načela rada gore navedenih alata i još učinkovitije provede funkcionalno testiranje (na primjer, ETL procesi koji postoje na projektu) i koristi ih za provjeru podataka. Konkretno, Apache Airflow ima gotove operatore za rad s popularnim analitičkim bazama podataka, na primjer . Najosnovniji primjer njegove uporabe već je naveden. pa da se ne ponavljam.
Osim gotovih rješenja, nitko vam ne brani implementirati svoje tehnike i alate. To neće biti korisno samo za projekt, već i za samog inženjera kvalitete podataka, koji će na taj način poboljšati svoj tehnički pogled i vještine kodiranja.
Kako to funkcionira na stvarnom projektu
Dobra ilustracija zadnjih odlomaka o "lancu podataka", ETL-u i sveprisutnim provjerama je sljedeći proces iz jednog od stvarnih projekata:
Ovdje različiti podaci (naravno, mi pripremljeni) ulaze u ulazni „lijevak“ našeg sustava: važeći, nevažeći, mješoviti itd., potom se filtriraju i ulaze u međuskladište, zatim ih opet čeka niz transformacije i smješteni u finalnu pohranu, koja će se, pak, koristiti za analitiku, izgradnju podatkovnih maraca i traženje poslovnih uvida. U takvom sustavu mi se, bez funkcionalne provjere rada ETL procesa, fokusiramo na kvalitetu podataka prije i poslije transformacija, kao i na izlaz u analitiku.
Da rezimiramo gore navedeno, bez obzira na mjesta na kojima sam radio, svugdje sam bio uključen u Data projekte koji su kombinirali sljedeće karakteristike:
- Samo putem automatizacije mogu se testirati neki slučajevi i postići ciklus izdavanja prihvatljiv za poslovanje.
- Tester na takvom projektu je jedan od najcjenjenijih članova tima, jer svakom od sudionika donosi veliku korist (ubrzanje testiranja, dobri Data Scientist podaci, rano otkrivanje nedostataka).
- Nije važno radite li na vlastitom hardveru ili u oblaku — svi resursi su apstrahirani u klaster kao što su Hortonworks, Cloudera, Mesos, Kubernetes itd.
- Projekti se grade na mikroservisnom pristupu, prevladava distribuirano i paralelno računalstvo.
Napominjem da prilikom testiranja u području kvalitete podataka, tester prebacuje svoj profesionalni fokus na kod proizvoda i alate koji se koriste.
Razlikovne značajke testiranja kvalitete podataka
Osim toga, za sebe sam identificirao sljedeće (odmah ću rezervirati VRLO generalizirane i krajnje subjektivne) karakteristične značajke testiranja u Data (Big Data) projektima (sustavima) i drugim područjima:
korisni linkovi
- Teorija: .
- EPAM
- Preporučeni materijali za inženjera kvalitete podataka početnika:
- Besplatan tečaj o Stepiku: .
- Tečaj o LinkedIn učenju: .
- Članci:
- ;
- ;
- ;
- Video:
- ;
- ;
Zaključak
Kvaliteta podataka je vrlo mlad perspektivan smjer, biti dio kojeg znači biti dio start-upa. Jednom u Data Qualityu, uronit ćete u veliki broj modernih traženih tehnologija, ali što je najvažnije, imat ćete ogromne mogućnosti za generiranje i implementaciju svojih ideja. Pristup stalnog poboljšanja moći ćete koristiti ne samo na projektu, već i za sebe, neprestano se razvijajući kao stručnjak.
Izvor: www.habr.com