Përshëndetje të gjithëve, unë quhem Aleksandër dhe jam inxhinier i Cilësisë së të Dhënave, i angazhuar në verifikimin e cilësisë së të dhënave. Ky artikull do të trajtojë se si kam arritur në këtë pozitë dhe pse në vitin 2020 ky drejtim i testimit u bë shumë i rëndësishëm.
Tendenca Botërore
Bota e sotme po përjeton një revolucion teknologjik, një nga aspektet e të cilit është përdorimi i të dhënave të grumbulluara nga kompani të ndryshme për të rritur volumet e shitjeve, fitimet dhe marketingun. Këtu vjen në pah rëndësia e të dhënave të mira (cilësore) dhe e mendjeve të zgjidhura që mund të nxjerrin para nga ato (të përpunojnë, vizualizojnë, ndjekin modele të mësimit të makinerisë etj.), që sot janë çelësi i suksesit për shumë kompani. Ndërsa 15-20 vjet më parë, vetëm kompanitë e mëdha merreshin me grumbullimin dhe shpërndarjen e të dhënave, tani ky detyrë është për praktikisht çdo kompani që mendon me arsyen.
Për këtë arsye, disa vjet më parë, të gjitha portalet globale të punës u mbushën me oferta për Data Scientists, pasi të gjithë ishin të bindur se duke marrë një specialist të tillë në ekip, mund të ndërtohej një supermodel mësimi të makinerisë, të parashikohej e ardhmja dhe të bëhej një "kërcim kuantik" për kompaninë. Me kalimin e kohës, njerëzit kuptuan se ky qasje nuk funksiononte asnjëherë, pasi jo të gjithë të dhënat që përfundonin në duar të këtyre specialistëve ishin të dobishme për mësimin e modeleve.
Dhe filluan kĂ«rkesat nga Data Scientists: "Le tĂ« blejmĂ« mĂ« shumĂ« tĂ« dhĂ«na nga kĂ«ta dhe ata...", "Na mungojnĂ« tĂ« dhĂ«nat...", "Na nevojitet mĂ« shumĂ« tĂ« dhĂ«na, dhe sa mĂ« cilĂ«sore...". Duke u mbĂ«shtetur nĂ« kĂ«to kĂ«rkesa, filluan tĂ« ndĂ«rtohen shumĂ« bashkĂ«punime midis kompanive qĂ« zotĂ«ronin grupe tĂ« ndryshme tĂ« tĂ« dhĂ«nave. Natyrisht, kjo kĂ«rkonte organizimin teknik tĂ« kĂ«tij procesi â pĂ«r t'u lidhur me burimin e tĂ« dhĂ«nave, pĂ«r t'i shkarkuar ato, pĂ«r tĂ« kontrolluar qĂ« ata ishin ngarkuar plotĂ«sisht etj. Numri i kĂ«tyre proceseve filloi tĂ« rritet, dhe sot kemi njĂ« nevojĂ« tĂ« madhe pĂ«r specialistĂ« tĂ« tjerĂ« â inxhinierĂ« tĂ« CilĂ«sisĂ« sĂ« tĂ« DhĂ«nave â ata qĂ« do tĂ« monitoronin rrjedhat e tĂ« dhĂ«nave nĂ« sistem (data pipelines), cilĂ«sinĂ« e tĂ« dhĂ«nave nĂ« hyrje dhe nĂ« dalje, do tĂ« nxirrnin pĂ«rfundime mbi mjaftueshmĂ«rinĂ« e tyre, integritetin dhe karakteristika tĂ« tjera.
Tendenca pĂ«r inxhinierĂ« tĂ« CilĂ«sisĂ« sĂ« tĂ« DhĂ«nave erdhi te ne nga SHBA, ku nĂ« mes tĂ« erĂ«s kapitaliste askush nuk Ă«shtĂ« i gatshĂ«m tĂ« humbasĂ« betejĂ«n pĂ«r tĂ« dhĂ«nat. MĂ« poshtĂ« kam paraqitur kapje ekranesh nga dy nga faqet e punĂ«s mĂ« tĂ« njohura nĂ« SHBA: dhe â nĂ« tĂ« cilat paraqiten tĂ« dhĂ«nat pĂ«r datĂ«n 17 mars 2020 pĂ«r numrin e ofertave tĂ« publikuara, tĂ« marra pĂ«r fjalĂ« kyçe: Data Quality dhe Data Scientist.
Data Scientists â 21416 oferta
Data Quality â 41104 oferta
Data Scientists â 404 oferta
Data Quality â 2020 oferta
Padyshim se këto profesione nuk konkurrojnë në asnjë mënyrë me njëra-tjetrën. Me këto kapje ekrani, thjesht doja të ilustroja situatën aktuale në tregun e punës sa i përket kërkesave për inxhinierë të Cilësisë së të Dhënave, të cilët tani kërkohen shumë më tepër se Data Scientists.
Në qershor 2019, EPAM, duke u përgjigjur kërkesave të tregut modern të IT-së, e ndau drejtimin e Cilësisë së të Dhënave në një praktikë të veçantë. Inxhinierët e Cilësisë së të Dhënave gjatë punës së tyre të përditshme menaxhojnë të dhënat, kontrollojnë sjelljen e tyre në kushte dhe sisteme të reja, monitorojnë relevancën, mjaftueshmërinë dhe aktualitetin e të dhënave. Ndërkohë, në kuptimin praktik, inxhinierët e Cilësisë së të Dhënave vërtet i kushtojnë pak kohë testimit tradicional funksional, POR kjo varet shumë nga projekti (një shembuj do të jap më pas).
Detyrat e inxhinierit të Cilësisë së të Dhënave nuk përfshijnë vetëm verifikimet rutinë manuale/automatikë për "nulls, count dhe sums" në tabelat e bazave të të dhënave, por kërkojnë një kuptim të thellë të nevojave të biznesit të klientëve dhe, për rrjedhojë, aftësinë për të transformuar të dhënat e disponueshme në informacion të dobishëm për biznesin.
Teoria e Cilësisë së të Dhënave
Për të përshkruar më mirë rolin e këtij inxhinieri, le të kuptojmë se çfarë është Cilësia e të Dhënave në teori.
CilĂ«sia e tĂ« DhĂ«nave â njĂ« nga fazat e Menaxhimit tĂ« tĂ« DhĂ«nave (njĂ« botĂ« e tĂ«rĂ«, tĂ« cilĂ«n do ta lĂ«mĂ« pĂ«r studim tĂ« pavarur) dhe pĂ«rgjigjet pĂ«r analizĂ«n e tĂ« dhĂ«nave sipas kritereve tĂ« mĂ«poshtme:
Mendoj se nuk është e nevojshme të shpjegojmë çdo pikë (në teori quhen "dimensionet e të dhënave"), ato janë të përshkruara shumë mirë në imazh. Por procesi i testimit nuk nënkupton kopjimin e rreptë të këtyre karakteristikave në rastet e testeve dhe kontrollin e tyre. Në Cilësinë e të Dhënave, si në çdo formë tjetër testimi, është e nevojshme së pari të bazohemi në kërkesat për cilësinë e të dhënave, të miratuara me pjesëmarrësit e projektit, të cilët marrin vendime biznesi.
Në varësi të projektit, inxhinieri i Cilësisë së të Dhënave mund të kryejë funksione të ndryshme: nga një tester automatizues i zakonshëm me një vlerësim të sipërfaqshëm të cilësisë së të dhënave, deri te një person që kryen profilizimin e thellë të tyre sipas karakteristikave të mësipërme.
Një përshkrim shumë i detajuar i proceseve të Menaxhimit të të Dhënave, Cilësisë së të Dhënave dhe fushave të lidhura është përshkruar shkëlqyer në libër me titullin «DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition». E rekomandoj shumë këtë libër si një hyrje në këtë fushë (linkun për të do ta gjeni në fund të artikullit).
Historia ime
NĂ« industrinĂ« IT kam kaluar nga Junior tester nĂ« kompanitĂ« produktive deri nĂ« Lead Data Quality Engineer nĂ« kompaninĂ« EPAM. Rreth dy vjet pas fillimit tĂ« punĂ«s si tester, pata njĂ« bindje tĂ« fortĂ« se kisha bĂ«rĂ« tĂ« gjitha llojet e testimeve: regresive, funksionale, stresit, stabilitetit, sigurisĂ«, UI etj. â dhe kam provuar njĂ« sĂ«rĂ« tools testimi, duke punuar nĂ« tre gjuhĂ« programimi: Java, Scala, Python.
Duke u kthyer pas, kuptoj se pĂ«rse grupi im i aftĂ«sive profesionale u bĂ« kaq i ndryshĂ«m â kam marrĂ« pjesĂ« nĂ« projekte qĂ« lidhen me punĂ«n me tĂ« dhĂ«na, tĂ« mĂ«dha dhe tĂ« vogla. Ky ishte shkaku qĂ« mĂ« çoi nĂ« botĂ«n e shumĂ« mjeteve dhe mundĂ«sive pĂ«r rritje.
Për të vlerësuar larmishmërinë e mjeteve dhe mundësive për të fituar njohuri dhe aftësi të reja, mjafton të shikoni imazhin më poshtë, ku janë paraqitur më të njohurit në botën e «Data & AI».
Këto ilustime përgatiten çdo vit nga një nga kapitalistët më të njohur të riskut, Matt Turck, një ish zhvillues softuerësh. Ja blogu i tij dhe , ku ai punon si partner.
Veçanërisht kam përparuar profesionalisht shpejt kur isha tester i vetëm në projekt, ose të paktën në fillim të projektit. Në ato momente je përgjegjës për të gjithë procesin e testimit, dhe nuk ke mundësi të tërheqësh prapa, vetëm përpara. Në fillim më frikësonte kjo, por tani më janë të qarta të gjitha avantazhet e një sfide të tillë:
- Fillon të komunikosh me gjithë ekipin si kurrë më parë, pasi nuk ka asnjë ndërmjetës për komunikim: as menaxher testi, as kolegë testers.
- Përfshirja në projekt bëhet jashtëzakonisht e thellë, dhe ti disponon informacion mbi të gjitha komponentët si në përgjithësi, ashtu edhe në detaje.
- Zhvilluesit nuk të shohin si «atë djalin nga testimi që merret me diçka që nuk është e qartë», por më tepër si një të barabartë, që sjell një dobi të jashtëzakonshme për ekipin me testet e tij automatike dhe parashikimin e shfaqjes së gabimeve në një bllok specifik të produktit.
- Si rezultat â je mĂ« efikas, mĂ« i kualifikuar, mĂ« i kĂ«rkuar.
Me rritjen e projektit, në 100% të rasteve kam qenë mentor për testerët e rinj që kanë ardhur në të, kam mësuar ata dhe kam ndarë njohuritë që kam fituar. Në këtë rast, varësisht nga projekti, nuk kam marrë gjithmonë nga drejtorët specialistë të testimit automatizues me nivel të lartë dhe ka pasur nevojë për të mësuar ata në automatizim (për ata që dëshironin), ose për të krijuar mjete për t'i përdorur ata në aktivitete të përditshme (mjete gjenerimi të të dhënave dhe ngarkimi i tyre në sistem, mjet për kryerjen e testimeve të ngarkesës/testimeve të stabilitetit «shpejt» etj.).
Një shembull i projektit konkret
Fatkeqësisht, për shkak të angazhimeve për moszbulim, nuk mund të flas në detaje për projektet në të cilat kam punuar, megjithatë do të jap shembuj të detyrave tipike të Inxhinierit të Cilësisë së të Dhënave në një nga projektet.
QĂ«llimi i projektit â tĂ« realizohet njĂ« platformĂ« pĂ«r pĂ«rgatitjen e tĂ« dhĂ«nave pĂ«r trajnim mbi bazĂ«n e modeleve tĂ« mĂ«simit tĂ« makinerisĂ«. Klienti ishte njĂ« kompani farmaceutike e madhe nga SHBA. Teknikisht, ky ishte njĂ« grup , qĂ« ngrihej nĂ« instance, me disa mikroshĂ«rbime dhe njĂ« projekt Open Source nĂ« thelb tĂ« kompanisĂ« EPAM â , i adaptuar pĂ«r nevojat e klientit tĂ« veçantĂ« (tani projekti Ă«shtĂ« transformuar nĂ« ). Proceset ETL u organizuan pĂ«rmes dhe transferuan tĂ« dhĂ«nat nga i klientit nĂ« Buckets. MĂ« pas, njĂ« imazh docker i modelit tĂ« mĂ«simit tĂ« makinerisĂ« u vendos nĂ« platformĂ«, e cila mĂ«sonte mbi tĂ« dhĂ«na tĂ« reja dhe pĂ«rmes ndĂ«rfaqes REST API jepte parashikime qĂ« interesonin biznesin dhe zgjidhnin probleme specifike.
Pamja vizuale ishte përafërsisht kështu:
Ka përfundimeve të testimit funksional në këtë projekt kishte me bollëk, dhe duke marrë parasysh shpejtësinë e zhvillimit të funksioneve dhe nevojën për të mbajtur ritmin e ciklit të lëshimit (sprintet dyjavore), ishte e domosdoshme të mendonim menjëherë për automatizimin e testimit të nyjave më kritike të sistemit. Pjesa më e madhe e platformës me bazë Kubernetes ishte e mbuluar nga testet automatike, të realizuara në + Python, por ishte e nevojshme gjithashtu të mbaheshin dhe zgjerohej ato. Gjithashtu, për lehtësinë e klientit, u krijua një GUI për menaxhimin e modeleve të mësimit të makinerive, të deponuar në grumbull, si dhe mundësia për të treguar nga dhe në cilin vend duhej të transferoheshin të dhënat për trajnimin e modeleve. Ky shtesë i gjerë solli zgjerimin e kontrolleve automatizuese funksionale, që kryesisht u realizuan përmes thirrjeve REST API dhe një numri të vogël të testeve UI end-2-end. Rreth ekuatorit të gjithë këtij procesi, u bashkua një testues manual, i cili e menaxhoi shumë mirë testimin e pranuar të versioneve të produktit dhe komunikimin me klientin për miratimin e lëshimit të ardhshëm. Për më tepër, me ardhjen e një specialisti të ri, ne arritëm të dokumentonim punën tonë dhe të shtonin disa kontrolle manuale shumë të rëndësishme, të cilat ishte e vështirë t'i automatizonim menjëherë.
Dhe përfundimisht, pasi arritëm stabilitetin nga platforma dhe shtresa GUI mbi të, filluam të ndërtojmë ETL pipelines duke përdorur Apache Airflow DAGs. Kontrolli automatizuar i cilësisë së të dhënave u realizua duke shkruar DAG të veçantë Airflow që kontrollonin të dhënat në përputhje me rezultatet e procesit ETL. Në këtë projekt na u afrua fat, dhe klienti na dha akses në grupe të dhënash të paidentifikuara, mbi të cilat ne testoheshim. Kontrollonim të dhënat rresht pas rreshti për përputhshmërinë me tiparet, praninë e të dhënave të prishura, shifrën totale të regjistrimeve para dhe pas, krahasimin e transformimeve të kryera nga procesi ETL në agregimin, ndryshimin e emrave të kolonave dhe më shumë. Për më tepër, këto kontrolle u skaluan në burime të ndryshme të të dhënave, për shembull përveç SalesForce edhe në MySQL.
Kontrollimi i cilësisë së fundit të të dhënave u realizua tashmë në nivelin S3, ku ato ishin ruajtur dhe ishin në gjendje ready-to-use për trajnimin e modeleve të mësimit të makinerive. Për të marrë të dhënat nga skedari përfundimtar CSV, që ndodhej në S3 Bucket, dhe për validimin e tyre, u shkrua një kod duke përdorur .
Gjithashtu, nga ana e klientit kishte kërkesën për ruajtjen e një pjese të të dhënave në një S3 Bucket dhe një pjese në një tjetër. Për këtë u nevojitën të shkruheshin kontrolle shtesë, që kontrollonin saktësinë e një ndarjeje të tillë.
Eksperienca e përmbledhur nga projekte të tjera
Shembulli i listës më të përgjithshme të aktiviteteve të Data Quality inxhinierit:
- Përgatitni të dhëna testuese (valide, të pavlefshme, të mëdha, të vogla) përmes një mjeti automatizuar.
- Ngarko setin e përgatitur të të dhënave në burimin origjinal dhe kontrolloni gatishmërinë e tij për përdorim.
- Aktivizoni proceset ETL për përpunimin e setit të të dhënave nga depoja origjinale në përfundimtare ose të ndërmjetme duke përdorur një grup të caktuar konfigurimesh (nëse është e mundur të caktohen parametra konfigurues për detyrën ETL).
- Verifikoni të dhënat e përpunuara nga procesi ETL për cilësinë e tyre dhe përputhshmërinë me kërkesat e biznesit.
Dhe në këtë pikë, theksi kryesor i kontrollit duhet të jetë jo vetëm në atë se si rrjedha e të dhënave në sistem ka kaluar në përgjithësi, por kryesisht në verifikimin dhe validimin e të dhënave në përputhje me kërkesat e pritura, identifikimin e anomalive dhe më shumë.
Mjetet
NjĂ« nga teknikĂ«t e tillĂ« tĂ« kontrollit tĂ« tĂ« dhĂ«nave mund tĂ« jetĂ« organizimi i kontrollove tĂ« zinxhirĂ«ve nĂ« çdo fazĂ« tĂ« pĂ«rpunimit tĂ« tĂ« dhĂ«nave, tĂ« njohura nĂ« literaturĂ« si 'data chain' â kontrolli i tĂ« dhĂ«nave nga burimi deri nĂ« pikĂ«n e pĂ«rdorimit pĂ«rfundimtar. KontrollĂ«t e tilla zakonisht realizohen pĂ«rmes shkrimit tĂ« pyetjeve SQL tĂ« verifikimit. Natyrisht, qĂ« kĂ«to pyetje duhet tĂ« jenĂ« sa mĂ« tĂ« lehta dhe tĂ« kontrollojnĂ« copĂ«za tĂ« veçanta tĂ« cilĂ«sisĂ« sĂ« tĂ« dhĂ«nave (metadata e tabelave, rreshtat bosh, NULL, Gabimet nĂ« sintaksĂ« â atributet e tjera tĂ« kĂ«rkuara pĂ«r kontroll).
Në rastin e testimit regresiv, në të cilin përdoren sete të dhënash tashmë të gatshme (të pandryshueshme ose pak të ndryshueshme), në kodin e testeve automatike mund të ruhen të gatshme shabllone verifikimi për cilësinë e të dhënave (përshkrime të metadatas së pritura të tabelave; objekte të përzgjedhura në rresht, të cilat mund të zgjidhen rastësisht gjatë testit, etj.).
Gjithashtu, gjatë testimit është e nevojshme të shkruhen procese testuese ETL, duke përdorur framework-e si Apache Airflow, ose fare mjete cloud black-box si , etj. Ky faktor bën që inxhinieri i testimit të thellohet në parimet e funksionimit të mjeteve të përmendura dhe të kryejë më efektivisht si testimin funksional (për shembull, të proceseve ETL ekzistuese në projekt), ashtu edhe t'i përdorë ato për të verifikuar të dhënat. Në veçanti, për Apache Airflow, ekzistojnë tashmë operatorë të gatshëm për punë me bazat e të dhënave analitike popullore, siç është . Shembulli më bazik i përdorimit të tij është përshkruar tashmë, , prandaj nuk do të përsëritem.
Përveç zgjidhjeve të gatshme, askush nuk e ndalon të realizoni teknikat dhe mjetet tuaja. Kjo do të jetë e dobishme jo vetëm për projektin, por edhe për vetë Inxhinierin e Cilësisë së të Dhënave, i cili kështu do të zhvillojë horizontin e tij teknik dhe aftësitë e kodimit.
Si funksionon kjo në një projekt real
Një ilustim i mirë i parashtrimeve të fundit për "zinxhirin e të dhënave", ETL dhe kontrollin e gjeneruar kudo është procesi në vijim nga një nga projektet reale:
Këtu, në "vrullin" e sistemit tonë hyjnë të dhëna të ndryshme (natyrisht, të përgatitura nga ne): të vlefshme, të pavlefshme, të përziera, etj., pastaj ato filtrohen dhe kalojnë në një depo të përkohshme, më pas pësojnë një sërë përpunimesh dhe vendosen në një depo përfundimtare, nga e cila, për rrjedhojë, do të kryhet analiza, ndërtimi i pamjeve të të dhënave dhe gjetja e njohurive të biznesit. Në një sistem të tillë, pa verifikuar funksionalisht punën e proceseve ETL, përqendrohemi në cilësinë e të dhënave para dhe pas përpunimeve, si dhe në daljen në analizë.
Duke përmbledhur atë që u tha më sipër, pa marrë parasysh vendet ku kam punuar, gjithmonë kam qenë i përfshirë në projekte të të dhënave, të cilat përfshinin karakteristika të mëposhtme:
- Vetëm përmes automatizimit mund të kontrollohen disa raste dhe të arrihet një cikël publikimi i pranueshëm për biznesin.
- Testuesi në një projekt të tillë është një nga anëtarët më të respektuar të ekipit, pasi sjell një përfitim të madh për secilin prej anëtarëve (shpejtimi i testimit, të dhëna të mira për Data Scientist, identifikimi i defekteve në fazat e hershme).
- Nuk ka rĂ«ndĂ«si nĂ«se punoni nĂ« pajisjet tuaja apo nĂ« cloud â tĂ« gjithĂ« burimet janĂ« tĂ« abstaruara nĂ« njĂ« klasĂ« si Hortonworks, Cloudera, Mesos, Kubernetes etj.
- Projektet ndërtohen me një qasje mikroshërbimesh, dhe dominon llogaritja e shpërndarë dhe e paralel.
Dua të theksoj se, duke u marrë me testimin në fushën e Cilësisë së të Dhënave, specialisti i testimit zhvendos fokusin e tij profesional në kodin e produktit dhe mjetet e përdorura.
Karakteristikat dalluese të testimit të Cilësisë së të Dhënave
Përveç kësaj, për veten time kam identifikuar karakteristika të tjera (të theksuara shumë në mënyrë të përgjithësuar dhe në mënyrë subjektive) të testimit në projekte (sistemat) Data (Big Data) dhe drejtime të tjera:
Linqe të dobishme
- Teoria: .
- Â EPAMÂ
- Materialet e rekomanduara për inxhinierin e njohur të Cilësisë së të Dhënave:
- Kursi falas nĂ« Stepik: .Â
- Kurs në LinkedIn Learning: .
- Artikuj:
- ;Â
- ;Â
- ;Â
- Â
- Video:
- ;
- ;
PĂ«rfundimi
CilĂ«sia e tĂ« DhĂ«nave â Ă«shtĂ« njĂ« fushĂ« shumĂ« e re dhe premtuese, tĂ« jesh pjesĂ« e sĂ« cilĂ«s do tĂ« thotĂ« tĂ« jesh pjesĂ« e njĂ« startup-i. Duke hyrĂ« nĂ« CilĂ«sinĂ« e tĂ« DhĂ«nave, do tĂ« zhytet nĂ« njĂ« mori teknologjish tĂ« kĂ«rkuara moderne, por mĂ« e rĂ«ndĂ«sishmja â do tĂ« hapen mundĂ«si tĂ« mĂ«dha pĂ«r tĂ« gjeneruar dhe realizuar idetĂ« tuaja. Do tĂ« keni mundĂ«sinĂ« tĂ« pĂ«rdorni qasjen e pĂ«rmirĂ«simit tĂ« vazhdueshĂ«m jo vetĂ«m nĂ« projekt, por edhe pĂ«r veten, duke u zhvilluar vazhdimisht si profesionist.
Burimi: habr.com
