Pozdravljeni vsi, moje ime je Alexander in sem inženir kakovosti podatkov, ki preverja kakovost podatkov. Ta članek bo govoril o tem, kako sem prišel do tega in zakaj je bilo leta 2020 to področje testiranja na vrhuncu vala.
svetovni trend
Današnji svet doživlja še eno tehnološko revolucijo, katere eden od vidikov je uporaba zbranih podatkov s strani vseh vrst podjetij za vrtenje lastnega vztrajnika prodaje, dobička in PR. Zdi se, da sta prav dostopnost dobrih (kakovostnih) podatkov, pa tudi spretni možgani, ki znajo z njimi zaslužiti (pravilno obdelati, vizualizirati, zgraditi modele strojnega učenja itd.), danes za mnoge postala ključ do uspeha. Če so se pred 15-20 leti velika podjetja ukvarjala predvsem z intenzivnim delom z zbiranjem podatkov in njihovo monetizacijo, je danes to stvar skoraj vseh zdravih ljudi.
V zvezi s tem so pred nekaj leti vsi portali za iskanje zaposlitve po vsem svetu začeli preplavljati s prostimi delovnimi mesti podatkovnih znanstvenikov, saj so bili vsi prepričani, da lahko s pridobitvijo takšnega strokovnjaka v svoje osebje zgradijo supermodel strojnega učenja, napovedujejo prihodnost. in narediti "kvantni skok" za podjetje. Sčasoma so ljudje spoznali, da ta pristop skoraj nikoli ne deluje, saj še zdaleč niso vsi podatki, ki padejo v roke takšnih strokovnjakov, primerni za modele usposabljanja.
In začele so se zahteve podatkovnih znanstvenikov: “Kupimo več podatkov od teh in onih…”, “Nimamo dovolj podatkov…”, “Potrebujemo še nekaj podatkov in po možnosti kakovostnih…”. Na podlagi teh zahtev so se začele graditi številne interakcije med podjetji, ki imajo v lasti tak ali drugačen niz podatkov. Seveda je to zahtevalo tehnično organizacijo tega procesa - povezati se z virom podatkov, jih prenesti, preveriti, ali so v celoti naloženi itd. Število takih procesov je začelo naraščati in danes imamo ogromno potrebo po drugi vrsti specialistov - Data Quality inženirjev - tistih, ki bi spremljali pretok podatkov v sistemu (data pipeline), kakovost podatkov na vhodu in izhodu, sklepali o njihovi zadostnosti, celovitosti in drugih značilnostih.
Trend kakovosti podatkov inženirjev je k nam prišel iz ZDA, kjer sredi divjanja dobe kapitalizma nihče ni pripravljen izgubiti bitke za podatke. Spodaj sem navedel posnetke zaslona z dveh najbolj priljubljenih spletnih mest za iskanje zaposlitve v ZDA: и - ki prikazuje podatke na dan 17 o številu prejetih objavljenih prostih delovnih mest, za ključni besedi: Data Quality in Data Scientist.
Data Scientists – 21416 prostih mest
Kakovost podatkov – 41104 prostih delovnih mest
Data Scientists – 404 prosta delovna mesta
Kakovost podatkov – 2020 prostih delovnih mest
Očitno ti poklici med seboj nikakor ne tekmujejo. S posnetki zaslona sem želel samo ponazoriti trenutno stanje na trgu dela glede povpraševanja po Data Quality inženirjih, ki so sedaj veliko bolj potrebni kot Data Scientists.
Junija 2019 je EPAM kot odgovor na potrebe sodobnega IT trga izpostavil Data Quality kot ločeno prakso. Inženirji kakovosti podatkov pri svojem vsakodnevnem delu upravljajo podatke, preverjajo njihovo obnašanje v novih pogojih in sistemih, kontrolirajo relevantnost podatkov, njihovo zadostnost in relevantnost. Ob vsem tem v praktičnem smislu inženirji kakovosti podatkov res malo časa posvetijo klasičnemu funkcionalnemu testiranju, VENDAR močno je odvisno od projekta (spodaj bom navedel primer).
Dolžnosti inženirja za kakovost podatkov niso omejene na rutinska ročna/samodejna preverjanja "nič, štetij in vsot" v tabelah baze podatkov, temveč zahtevajo globoko razumevanje strankinih poslovnih potreb in v skladu s tem sposobnost preoblikovanja razpoložljivih podatkov v uporabne poslovne informacije.
Teorija kakovosti podatkov
Da bi si čim bolje predstavljali vlogo takšnega inženirja, poglejmo, kaj je kakovost podatkov v teoriji.
Kakovost podatkov - ena od stopenj Upravljanja podatkov (cel svet, ki vam ga bomo prepustili v samostojno proučevanje) in je odgovoren za analizo podatkov po naslednjih kriterijih:
Mislim, da ni vredno dešifrirati vsake točke (teoretično se imenujejo "dimenzije podatkov"), na sliki so precej dobro opisane. Toda sam proces testiranja ne pomeni strogega kopiranja teh funkcij v testne primere in njihovega preverjanja. Pri kakovosti podatkov, tako kot pri vseh drugih vrstah testiranja, je treba najprej graditi na zahtevah glede kakovosti podatkov, dogovorjenih z udeleženci projekta, ki sprejemajo poslovne odločitve.
Odvisno od projekta kakovosti podatkov lahko inženir opravlja različne funkcije: od navadnega preizkuševalca-avtomatista s površno oceno kakovosti podatkov do osebe, ki izvaja njihovo globoko profiliranje po zgornjih merilih.
Zelo podroben opis upravljanja podatkov, kakovosti podatkov in povezanih procesov je dobro opisan v knjigi z naslovom "DAMA-DMBOK: zbirka znanja o upravljanju podatkov: 2. izdaja". To knjigo toplo priporočam kot uvod v to temo (povezavo do nje boste našli na koncu članka).
Moja zgodba
V IT industriji sem od Junior QA v proizvodnih podjetjih prešel do Lead Data Quality Engineer pri EPAM. Po približno dveh letih preizkuševanja sem bil trdno prepričan, da sem opravil absolutno vse vrste testiranja: regresijsko, funkcionalno, stresno, stabilnostno, varnostno, uporabniški vmesnik itd. – in preizkusil veliko število orodij za testiranje, ko sem delal v trije programski jeziki: Java, Scala, Python.
Če pogledam nazaj, razumem, zakaj je bil moj nabor spretnosti tako raznolik – sodeloval sem pri velikih in majhnih podatkovnih projektih. To je tisto, kar me je pripeljalo v svet številnih orodij in priložnosti za rast.
Če želite ceniti raznolikost orodij in priložnosti za pridobivanje novih znanj in veščin, si oglejte spodnjo sliko, ki prikazuje najbolj priljubljena med njimi v svetu »Data & AI«.
Tovrstno ilustracijo vsako leto pripravi eden od znanih investitorjev tveganega kapitala Matt Turck, rojen v razvoju programske opreme. Tukaj na svoj blog in kjer dela kot družbenik.
Še posebej hitro sem profesionalno rasel, ko sem bil edini preizkuševalec na projektu ali pa vsaj na začetku projekta. V tem trenutku morate biti odgovorni za celoten proces testiranja in nimate možnosti za umik, samo naprej. Sprva je bilo strašljivo, zdaj pa so mi očitne vse prednosti takega testa:
- Začnete komunicirati s celotno ekipo kot še nikoli prej, saj ni posrednika za komunikacijo: niti vodja testiranja niti kolegi preizkuševalci.
- Potopitev v projekt postane neverjetno globoka in imate informacije o vseh komponentah tako na splošno kot v podrobnostih.
- Razvijalci na vas ne gledajo kot na "tistega preizkuševalca, ki ne ve, kaj dela", ampak bolj kot na enakovrednega, ki ustvarja neverjetno vrednost za ekipo s svojimi samodejnimi testi in predvidevanjem napak v določenem vozlišču izdelka.
- Posledično ste učinkovitejši, bolj usposobljeni, bolj iskani.
Ko je projekt rasel, sem v 100% primerih postal mentor novim testerjem, ki so prihajali vanj, jih učili in prenašali znanje, ki sem se ga sam naučil. Hkrati, odvisno od projekta, od vodstva nisem vedno prejel strokovnjakov za samodejno testiranje na najvišji ravni in bilo je treba, da jih usposobim za avtomatizacijo (za tiste, ki želijo) ali ustvarim orodja za njihovo uporabo pri vsakodnevnih aktivnostih (orodja za generiranje podatkov in nalaganje le-teh v sistem, orodje za izvajanje obremenitvenega testiranja/hitrega testa stabilnosti itd.).
Primer konkretnega projekta
Zaradi obveznosti nerazkritja podatkov žal ne morem podrobneje govoriti o projektih, na katerih sem delal, bom pa navedel primere tipičnih nalog Data Quality Engineer na enem od projektov.
Bistvo projekta je implementacija platforme za pripravo podatkov za usposabljanje na osnovi modelov strojnega učenja. Naročnik je bila velika farmacevtska družba iz ZDA. Tehnično je bil grozd narašča na primerki, z več mikrostoritvami in osnovnim odprtokodnim projektom EPAM - , prilagojeno potrebam posameznega kupca (zdaj se je projekt prerodil v ). ETL procesi so bili organizirani z uporabo in premaknil podatke iz sistemi strank v vedra. Nato je bila na platformo uvedena slika dockerja modela strojnega učenja, ki je bila usposobljena na svežih podatkih in je z uporabo vmesnika REST API izdala napovedi, ki so bile zanimive za podjetje in rešile specifične probleme.
Vizualno je bilo videti nekako takole:
Na tem projektu je bilo veliko funkcionalnega testiranja in glede na hitrost razvoja funkcij in potrebo po ohranjanju tempa cikla izdaj (dvotedenski sprinti) je bilo treba takoj razmisliti o avtomatiziranem testiranju najbolj kritičnih sistemskih vozlišč. . Večino same platforme, ki temelji na Kubernetesu, so pokrivali samodejni testi, implementirani na + Python, vendar jih je bilo treba tudi podpreti in razširiti. Poleg tega je bil za udobje stranke ustvarjen GUI za upravljanje modelov strojnega učenja, razporejenih v gručo, kot tudi možnost določanja, od kod in kam naj se prenesejo podatki za usposabljanje modela. Ta obsežen dodatek je vključeval razširitev samodejnih funkcionalnih preverjanj, ki so bila večinoma opravljena prek klicev API-ja REST in majhnega števila testov uporabniškega vmesnika od konca 2 do konca. Okoli ekvatorja tega celotnega gibanja se nam je pridružil ročni tester, ki je opravil odlično delo s sprejemljivim testiranjem različic izdelkov in komuniciranjem s stranko o sprejemljivosti naslednje izdaje. Poleg tega smo zaradi prihoda novega specialista lahko dokumentirali naše delo in dodali nekaj zelo pomembnih ročnih pregledov, ki jih je bilo težko takoj avtomatizirati.
In končno, ko smo dosegli stabilnost s platformo in dodatkom GUI nad njo, smo začeli graditi cevovode ETL z uporabo Apache Airflow DAG. Avtomatizirano preverjanje kakovosti podatkov je bilo izvedeno s pisanjem posebnih Airflow DAG, ki so preverjali podatke na podlagi rezultatov procesa ETL. V okviru tega projekta smo imeli srečo in nam je stranka omogočila dostop do anonimiziranih podatkovnih nizov, na katerih smo testirali. Podatke smo preverili vrstico za vrstico glede skladnosti s tipom, prisotnosti poškodovanih podatkov, skupnega števila zapisov pred in po, primerjavo transformacij, ki jih je izvedel postopek ETL za združevanje, spreminjanje imen stolpcev itd. Poleg tega so bila ta preverjanja prilagojena različnim virom podatkov, na primer poleg SalesForce tudi na MySQL.
Končni pregledi kakovosti podatkov so bili izvedeni že na nivoju S3, kjer so bili shranjeni in v stanju, pripravljenem za uporabo za usposabljanje modelov strojnega učenja. Za pridobitev podatkov iz končne datoteke CSV, ki se nahaja v vedru S3, in njihovo potrditev je bila napisana koda z uporabo .
Tudi s strani naročnika je obstajala zahteva po shranjevanju dela podatkov v eno vedro S3, del pa v drugo. To je zahtevalo tudi pisanje dodatnih pregledov, ki kontrolirajo zanesljivost takšnega razvrščanja.
Splošne izkušnje na drugih projektih
Primer najbolj posplošenega seznama dejavnosti inženirja za kakovost podatkov:
- Pripravite testne podatke (veljavno neveljavno veliko majhno) prek avtomatiziranega orodja.
- Pripravljen nabor podatkov naložite v izvorni vir in preverite njegovo pripravljenost za uporabo.
- Zaženite procese ETL za obdelavo nabora podatkov od izvornega pomnilnika do končnega ali vmesnega z uporabo določenega nabora nastavitev (če je mogoče, nastavite konfigurabilne parametre za nalogo ETL).
- Preverite kakovost podatkov, ki jih obdeluje proces ETL, in njihovo skladnost s poslovnimi zahtevami.
Pri tem bi moral biti glavni poudarek preverjanj ne le na tem, ali je pretok podatkov v sistemu načeloma uspel in prišel do konca (kar je del funkcionalnega testiranja), ampak predvsem na preverjanje in potrjevanje podatkov glede skladnosti s pričakovanimi zahtevami, ugotavljanje nepravilnosti in drugo.
Orodja
Ena od tehnik takšnega nadzora podatkov je lahko organizacija verižnih pregledov na vsaki stopnji obdelave podatkov, v literaturi tako imenovana »podatkovna veriga« – nadzor podatkov od vira do mesta končne uporabe. Takšna preverjanja se najpogosteje izvajajo s pisanjem validacijskih poizvedb SQL. Jasno je, da morajo biti takšne poizvedbe čim bolj lahke in preverjati kakovost posameznih delov podatkov (metapodatki tabel, prazne vrstice, NULL, napake v sintaksi – drugi atributi, ki jih je treba preveriti).
V primeru regresijskega testiranja, ki uporablja že pripravljene (nespremenjene, rahlo spremenjene) nabore podatkov, lahko koda samodejnega testiranja shrani že pripravljene predloge za preverjanje skladnosti podatkov s kakovostjo (opisi pričakovanih metapodatkov tabel; predmeti vzorcev nizov, ki jih lahko naključno izbrani med preskusom itd.).
Poleg tega morate med testiranjem napisati testne procese ETL z uporabo ogrodij, kot je Apache Airflow, ali celo orodje v oblaku črne skrinjice, kot je , In tako naprej. Zaradi te okoliščine se preizkusni inženir potopi v načela delovanja zgornjih orodij in še bolj učinkovito izvaja funkcionalno testiranje (na primer procese ETL, ki obstajajo v projektu) in jih uporablja za preverjanje podatkov. Zlasti ima Apache Airflow že pripravljene operaterje za delo s priljubljenimi analitičnimi zbirkami podatkov, na primer . Najosnovnejši primer njegove uporabe je bil že opisan. tako da se ne bom ponavljala.
Poleg že pripravljenih rešitev vam nihče ne prepoveduje izvajanja svojih tehnik in orodij. To ne bo koristilo samo projektu, ampak tudi samemu inženirju kakovosti podatkov, ki bo s tem izboljšal svoj tehnični pogled in spretnosti kodiranja.
Kako deluje na resničnem projektu
Dobra ilustracija zadnjih odstavkov o "podatkovni verigi", ETL in vseprisotnih preverjanjih je naslednji proces iz enega od resničnih projektov:
Tukaj v vhodni »lijak« našega sistema pridejo različni podatki (seveda pripravljeni mi): veljavni, neveljavni, mešani itd., nato se filtrirajo in pridejo v vmesno shrambo, nato pa jih spet čaka serija transformacije in postavljeni v končno shrambo , ki bo nato služila za analitiko, gradnjo podatkovnih vitrin in iskanje poslovnih vpogledov. V takem sistemu se brez funkcionalnega preverjanja dela ETL procesov osredotočamo na kakovost podatkov pred in po transformacijah ter na izhod v analitiko.
Če povzamem zgoraj navedeno, ne glede na kraje, kjer sem delal, sem povsod sodeloval pri Data projektih, ki so združevali naslednje lastnosti:
- Samo z avtomatizacijo je mogoče preizkusiti nekatere primere in doseči cikel izdaje, ki je sprejemljiv za podjetje.
- Tester na takšnem projektu je eden najbolj cenjenih članov ekipe, saj vsakemu od sodelujočih prinaša velike koristi (pospešitev testiranja, dobri Data Scientist podatki, zgodnje odkrivanje napak).
- Ni pomembno, ali delate na lastni strojni opremi ali v oblaku - vsi viri so abstrahirani v gručo, kot so Hortonworks, Cloudera, Mesos, Kubernetes itd.
- Projekti so zgrajeni na mikrostoritvenem pristopu, prevladuje porazdeljeno in vzporedno računalništvo.
Ugotavljam, da preizkuševalec pri testiranju na področju kakovosti podatkov preusmeri svoj profesionalni fokus na kodo izdelka in uporabljena orodja.
Posebnosti testiranja kakovosti podatkov
Poleg tega sem zase ugotovil naslednje (takoj bom rezerviral ZELO posplošene in izjemno subjektivne) značilne lastnosti testiranja v projektih (sistemih) podatkov (Big Data) in na drugih področjih:
Uporabne povezave
- teorija: .
- EPAM
- Priporočeni materiali za inženirja kakovosti podatkov začetnika:
- Brezplačni tečaj o Stepiku: .
- Tečaj o učenju na LinkedInu: .
- Članki:
- ;
- ;
- ;
- Video:
- ;
- ;
Zaključek
Kakovost podatkov je zelo mlada perspektivna smer, biti del katere pomeni biti del start-upa. Ko boste enkrat v Data Quality, se boste potopili v veliko število sodobnih zahtevanih tehnologij, a kar je najpomembneje, imeli boste ogromne možnosti za ustvarjanje in uresničevanje svojih idej. Pristop nenehnega izboljševanja boste lahko uporabljali ne le pri projektu, ampak tudi zase, pri čemer se nenehno razvijate kot specialist.
Vir: www.habr.com