Hej alla, jag heter Alexander och jag Àr Data Quality-ingenjör som ansvarar för att kontrollera datakvaliteten. I den hÀr artikeln kommer jag att berÀtta hur jag kom hit och varför denna typ av testning blev en trend 2020.
Global trend
Dagens vÀrld genomgÄr en ny teknologisk revolution, dÀr en aspekt Àr anvÀndningen av insamlad data av olika företag för att driva sina egna försÀljningsmaskiner, vinster och PR. Det verkar som att nÀrvaron av bra (kvalitativa) data, tillsammans med skickliga personer som kan tjÀna pengar pÄ dem (bearbeta dem korrekt, visualisera dem, bygga maskininlÀrningsmodeller osv.), har blivit nyckeln till framgÄng för mÄnga. För 15-20 Är sedan Àgnade sig frÀmst stora företag Ät intensivt arbete med att samla in och monetisera data, medan det idag Àr en uppgift för nÀstan alla rationella företag.
I och med detta började för nÄgra Är sedan alla plattformar för jobbsökning runt om i vÀrlden att översvÀmmas av annonser för Data Scientists, eftersom alla var övertygade om att om de anstÀllde en sÄdan specialist kunde de bygga en supermodell för maskininlÀrning, förutsÀga framtiden och göra ett "kvantsteg" för företaget. Med tiden insÄg folk att denna metod nÀstan aldrig fungerar, dÄ lÄngt ifrÄn all data som hamnar i hÀnderna pÄ sÄdana specialister Àr anvÀndbar för att trÀna modeller.
Och sÄ började efterfrÄgan frÄn Data Scientists: "LÄt oss köpa mer data frÄn dem och dem...", "Vi har inte tillrÀckligt med data...", "Vi behöver lite mer data, och helst kvalitativ data...". Baserat pÄ dessa förfrÄgningar började det uppstÄ mÄnga samarbeten mellan företag som Àgde olika datamÀngder. Det krÀvde naturligtvis en teknisk organisering av denna process - att koppla upp sig mot datakÀllan, hÀmta dem, kontrollera att de laddades ner i sin helhet osv. Antalet sÄdana processer har ökat, och idag har vi en enorm efterfrÄgan pÄ en annan typ av specialister - Data Quality-ingenjörer - de som övervakar datastromen i systemet (data pipelines), datakvaliteten vid in- och utgÄng, och drar slutsatser om deras tillrÀcklighet, integritet och andra egenskaper.
Trenden för Data Quality ingenjörer har nĂ„tt oss frĂ„n USA, dĂ€r ingen Ă€r redo att förlora kampen om data mitt under den pĂ„gĂ„ende kapitalismens era. Nedan har jag presenterat skĂ€rmdumpar frĂ„n tvĂ„ av de mest populĂ€ra jobbsökningssajterna i USA: och â dĂ€r data frĂ„n den 17 mars 2020 visas, angĂ„ende antalet publicerade jobbannonser, baserat pĂ„ nyckelorden: Data Quality och Data Scientist.
Data Scientists â 21416 jobbannonser
Data Quality â 41104 jobbannonser
Data Scientists â 404 jobbannonser
Data Quality â 2020 jobbannonser
Det Àr uppenbart att dessa yrken pÄ ingen sÀtt konkurrerar med varandra. Med skÀrmdumparna ville jag bara illustrera den nuvarande situationen pÄ arbetsmarknaden nÀr det gÀller efterfrÄgan pÄ Data Quality ingenjörer, som just nu behövs mycket mer Àn Data Scientists.
I juni 2019, som svar pÄ behoven hos den moderna IT-marknaden, inrÀttade EPAM Data Quality som en separat praktik. Data Quality ingenjörer hanterar data i sitt dagliga arbete, testar deras beteende i nya miljöer och system, och övervakar relevansen, tillrÀckligheten och aktualiteten av data. Samtidigt Àgnar Data Quality ingenjörer faktiskt lite tid Ät klassisk funktionell testning, MEN detta beror mycket pÄ projektet (ett exempel kommer jag att ge senare).
Data Quality ingenjörers ansvar begrÀnsar sig inte bara till rutinmÀssiga manuella/automatiska kontroller av 'nulls, count och sums' i databastabeller, utan krÀver en djup förstÄelse för kundens affÀrsbehov och dÀrmed förmÄgan att omvandla befintliga data till nyttig affÀrsinformation.
Teorin om Data Quality
För att fÄ en sÄ fullstÀndig bild av rollen för en sÄdan ingenjör som möjligt, lÄt oss undersöka vad Data Quality innebÀr i teorin.
Data Quality â en av etapperna i Data Management (en hel vĂ€rld som vi lĂ€mnar till er för sjĂ€lvstudier) och ansvarar för analys av data enligt följande kriterier:
Jag tror inte att det Àr nödvÀndigt att avkoda varje punkt (som i teorin kallas 'data dimensions'); de Àr ganska vÀl beskrivna pÄ bilden. Men sjÀlva testprocessen innebÀr inte en strikt kopiering av dessa egenskaper till testfallen och deras verifiering. Inom Data Quality, precis som i all annan typ av testning, mÄste man först och frÀmst utgÄ frÄn de kvalitetskrav som har överenskommits med projektets deltagare som fattar affÀrsbeslut.
Beroende pÄ projektet kan Data Quality-ingenjören utföra olika funktioner: frÄn en vanlig testautomatiserare med ytlig bedömning av datakvalitet, till en person som utför djupgÄende profilering av dem enligt de ovan nÀmnda egenskaperna.
En mycket detaljerad beskrivning av processerna för Data Management, Data Quality och relaterat material Ă€r vĂ€l beskrivna i boken med titeln âDAMA-DMBOK: Data Management Body of Knowledge: 2nd Editionâ. Jag rekommenderar varmt denna bok som en introduktion till Ă€mnet (lĂ€nken till den hittar du i slutet av artikeln).
Min historia
Inom IT-branschen har jag gÄtt frÄn Junior-testare i produktföretag till Lead Data Quality Engineer pÄ EPAM. Redan efter cirka tvÄ Är som testare hade jag en fast övertygelse om att jag hade utfört alla typer av testning: regression, funktionell, stress, stabilitets-, sÀkerhets-, UI osv. - och jag har prövat mÄnga testverktyg, arbetat med tre programmeringssprÄk: Java, Scala, Python.
NÀr jag ser tillbaka inser jag varför min uppsÀttning professionella fÀrdigheter blev sÄ mÄngsidig - jag deltog i projekt kopplade till databehandling, stora och smÄ. Just detta ledde mig in i en vÀrld av mÄnga verktyg och möjligheter till tillvÀxt.
För att bedöma mÄngfalden av verktyg och möjligheter till nya kunskaper och fÀrdigheter rÀcker det med att titta pÄ bilden nedan, som visar de mest populÀra av dem inom 'Data & AI'.
SÄdana typer av illustrationer sammanstÀlls Ärligen av en kÀnd riskkapitalist, Matt Turck, som kommer frÄn mjukvaruutveckling. HÀr Àr hans blogg och , dÀr han arbetar som partner.
Jag vÀxte sÀrskilt snabbt i min profession nÀr jag var den enda testaren i projektet, eller Ätminstone i början av projektet. Just i sÄdana stunder mÄste man ta ansvar för hela testprocessen, och man har ingen möjlighet att backa, bara att gÄ framÄt. I början var det skrÀmmande, men nu ser jag tydligt alla fördelar med en sÄdan prövning:
- Du börjar kommunicera med hela teamet som aldrig tidigare, eftersom det inte finns nÄgon mellanhand för kommunikationen: varken testledare eller kollegor testare.
- Fördjupningen i projektet blir otroligt djup, och du har information om alla komponenter bÄde i stort och i detalj.
- Utvecklarna ser inte pÄ dig som "den dÀr killen frÄn testningen som gör nÄgot oklart", utan snarare som en jÀmlik, som skapar otroliga fördelar för teamet med sina automatiska tester och förutsÀgelse av buggar i specifika delar av produkten.
- Som ett resultat blir du mer effektiv, mer kvalificerad, mer eftertraktad.
I takt med att projektet vÀxer blev jag i 100% av fallen mentor för de nya testarna som kom till projektet, jag lÀrde upp dem och delade med mig av de kunskaper som jag sjÀlv lÀrt mig. Beroende pÄ projektet fick jag inte alltid experter pÄ högsta nivÄ inom automatisering frÄn ledningen och det fanns behov av att antingen utbilda dem i automatisering (för de som ville), eller skapa verktyg för deras dagliga aktiviteter (data-genereringsverktyg och deras uppladdning till systemet, verktyg för att genomföra belastningstestning/stabilitetstestning "snabbt" osv.).
Exempel pÄ ett specifikt projekt
TyvÀrr, pÄ grund av sekretessavtal kan jag inte berÀtta om projekten jag har arbetat med i detalj, men jag kan ge exempel pÄ typiska uppgifter för en Data Quality Engineer i ett av projekten.
Projektets kĂ€rna var att implementera en plattform för att förbereda data för att trĂ€na modeller för maskininlĂ€rning baserat pĂ„ dem. BestĂ€llaren var ett stort lĂ€kemedelsföretag i USA. Tekniskt var detta en kluster , som kördes pĂ„ instanser, med flera mikrotjĂ€nster och baserat pĂ„ Open Source-projektet frĂ„n företaget EPAM â , anpassat efter den specifika kundens behov (nu har projektet omformas till ). ETL-processerna organiserades med hjĂ€lp av och flyttade data frĂ„n kundens system till Buckets. DĂ€refter distribuerades en dockerbild av maskininlĂ€rningsmodellen pĂ„ plattformen, som trĂ€nades pĂ„ fĂ€rska data och via REST API grĂ€nssnittet gav förutsĂ€gelser av intresse för verksamheten och som löste specifika problem.
Visuellt sÄg allt ungefÀr ut sÄ hÀr:
Det fanns tillrÀckligt med funktionell testning i detta projekt, och med tanke pÄ hastigheten för funktionsutveckling och behovet av att upprÀtthÄlla takten i releasecykeln (tvÄveckors sprintar), var det nödvÀndigt att genast tÀnka pÄ automatisering av tester för de mest kritiska delarna av systemet. Större delen av plattformen baserad pÄ Kubernetes tÀcktes av automatiserade tester som implementerades pÄ + Python, men det var ocksÄ nödvÀndigt att underhÄlla och utöka dem. Dessutom skapades en GUI för att hantera maskininlÀrningsmodellerna som distribuerades pÄ klustret, samt möjligheten att specificera varifrÄn och vart data för modelltrÀning skulle flyttas. Detta omfattande tillÀgg ledde till utvidgning av automatiserade funktionella kontroller, som till stor del genomfördes via REST API-anrop och ett fÄtal end-2-end UI-tester. UngefÀr pÄ halva vÀgen i hela detta arbete anslöt sig en manuell testare till oss, som utmÀrkt hanterade godkÀnnande av produktversioner och kommunikation med kunden angÄende godkÀnnande av den senaste releasen. Dessutom, tack vare tillkomsten av den nya specialisten, kunde vi dokumentera vÄrt arbete och lÀgga till nÄgra mycket viktiga manuella kontroller som var svÄra att automatisera direkt.
Och slutligen, efter att vi uppnÄtt stabilitet med plattformen och GUI-överbyggnaden började vi bygga ETL-pipelines med hjÀlp av Apache Airflow DAGs. Automatisk kvalitetskontroll av data genomfördes genom att skriva speciella Airflow DAGs som kontrollerade data enligt resultaten frÄn ETL-processen. Inom ramen för detta projekt hade vi tur, och kunden gav oss tillgÄng till anonymiserade datamÀngder som vi testade pÄ. Vi kontrollerade data rad för rad mot typer, identifierade trasiga data, det totala antalet poster före och efter, samt jÀmförde de transformationer som utfördes av ETL-processen gÀllande aggregering, namnÀndringar pÄ kolumner och mer. Dessutom skalades dessa kontroller pÄ olika datakÀllor, exempelvis förutom SalesForce ocksÄ pÄ MySQL.
Kontroller av slutlig datakvalitet genomfördes redan pÄ S3-nivÄ, dÀr de lagrades och var i ready-to-use-tillstÄnd för att trÀna maskininlÀrningsmodeller. För att hÀmta data frÄn den slutliga CSV-filen som ligger pÄ S3 Bucket och validera dem, skrevs kod med hjÀlp av .
Det fanns ocksÄ ett krav frÄn kunden att lagra vissa data i en S3 Bucket och andra i en annan. För detta krÀvdes det ocksÄ att skriva ytterligare kontroller som övervakade riktigheten av en sÄdan sortering.
Generell erfarenhet frÄn andra projekt
Exempel pÄ en allmÀn lista över aktiviteter för en Data Quality-ingenjör:
- Förbereda testdata (giltiga/ogiltiga, stora/ smÄ) genom ett automatiserat verktyg.
- Ladda upp den förberedda databasen till den ursprungliga kÀllan och kontrollera dess beredskap för anvÀndning.
- Köra ETL-processerna för att bearbeta databasen frÄn den ursprungliga lagringsplatsen till den slutliga eller mellanliggande med hjÀlp av en viss uppsÀttning instÀllningar (om det Àr möjligt att ange konfigurerbara parametrar för ETL-uppgiften).
- Verifiera de bearbetade data som kom frÄn ETL-processen med avseende pÄ deras kvalitet och överensstÀmmelse med affÀrskrav.
Den huvudsakliga fokusen pÄ kontroller bör inte bara ligga pÄ att flödet av data i systemet har fungerat och nÄtt slutet (vilket Àr en del av funktionell testning), utan i högre grad pÄ att kontrollera och validera data för att sÀkerstÀlla att de uppfyller förvÀntade krav, upptÀckta avvikelser och annat.
Verktyg
En av teknikerna för sÄdan datakontroll kan vara att organisera kedjekontroller vid varje stadie av databehandling, den sÄ kallade 'data chain' - kontroll av data frÄn kÀllan till den slutgiltiga anvÀndningen. Denna typ av kontroller genomförs oftast genom att skriva kontrollerande SQL-frÄgor. Det Àr uppenbart att sÄdana frÄgor bör vara sÄ lÀtta som möjligt och kontrollera specifika delar av datakvalitet (tabellmetadata, tomma rader, NULL-vÀrden, syntaxfel - andra nödvÀndiga attribut för kontroller).
Vid regressions testning, dÀr redan fÀrdiga (oförÀndrade eller nÄgot förÀndrade) datamÀngder anvÀnds, kan koden för automatiserade tester innehÄlla redan fÀrdiga mallar för datavalidering i termer av kvalitet (beskrivningar av förvÀntad tabellmetadata; strÀngar av urvalsomrÄden som kan vÀljas slumpmÀssigt under testet, och annat).
Under testningen Àr det ocksÄ nödvÀndigt att skriva test-ETL-processer, med hjÀlp av sÄdana ramverk som Apache Airflow, eller helt enkelt anvÀnda black-box molnverktyg av typen , och annat. Denna omstÀndighet tvingar testingenjören att sÀtta sig in i principerna för ovan nÀmnda verktyg och att effektivare genomföra bÄde funktionell testning (till exempel av befintliga ETL-processer i projektet) och anvÀnda dem för datavalidering. Specifikt, för Apache Airflow finns det redan fÀrdiga operatörer för att arbeta med populÀra analytiska databaser, till exempel . Det mest grundlÀggande exemplet pÄ dess anvÀndning har redan redovisats , sÄ jag tÀnker inte upprepa mig.
Utöver fÀrdiga lösningar Àr ingen förbjuden att utveckla sina egna tekniker och verktyg. Detta kommer inte bara att vara till nytta för projektet, utan ocksÄ för Data Quality Engineer som dÀrigenom förbÀttrar sin tekniska förstÄelse och programmeringsfÀrdigheter.
Hur detta fungerar i ett riktigt projekt
En bra illustration av de senaste styckena om "data chain", ETL och allestÀdes nÀrvarande kontroller Àr följande process frÄn ett av vÄra verkliga projekt:
HÀr i ingÄngsvinkeln till vÄrt system strömmar olika data (naturligtvis förberedda av oss): giltiga, ogiltiga, blandade och sÄ vidare, som filtreras och hamnar i ett mellanlagringsutrymme, sedan vÀntar en rad förÀndringar innan de placeras i slutlagringsutrymmet, frÄn vilket analyser, datavitriner och affÀrsinsikter kommer att produceras. I ett sÄdant system fokuserar vi, utan att funktionellt kontrollera arbetet i ETL-processerna, pÄ datans kvalitet före och efter transformationerna, samt pÄ resultaten i analysen.
Sammanfattningsvis, oavsett var jag har arbetat har jag alltid varit involverad i Data-projekt som kÀnnetecknas av följande drag:
- Endast genom automatisering kan vissa fall kontrolleras och en acceptabel releasescykel för företaget uppnÄs.
- Testaren i ett sÄdant projekt Àr en av de mest respekterade medlemmarna i teamet, eftersom de ger stort vÀrde för varje deltagare (snabbare testning, bra data för Data Scientist, upptÀckte defekter i ett tidigt skede).
- Det spelar ingen roll om du arbetar pĂ„ din egen hĂ„rdvara eller i molnet â alla resurser Ă€r abstrakterade i en kluster av typen Hortonworks, Cloudera, Mesos, Kubernetes och sĂ„ vidare.
- Projekt bygger pÄ mikrotjÀnstestrukturen, med betoning pÄ distribuerade och parallella berÀkningar.
Jag noterar att nÀr man arbetar med testning inom Data Quality flyttar testspecialisten sitt professionella fokus till produktens kod och de verktyg som anvÀnds.
UtmÀrkande egenskaper för Data Quality-testning
Dessutom har jag identifierat följande (vilket jag genast vill pÄpeka Àr MYCKET generaliserade och helt subjektiva) utmÀrkande drag för testning inom Data (Big Data) projekt (system) och andra omrÄden:
Nyttiga lÀnkar
- Teori: .
- Â EPAMÂ
- Rekommenderat material för en nybörjare inom Data Quality engineering:
- Kostnadsfri kurs pĂ„ Stepik: .Â
- Kurs pÄ LinkedIn Learning: .
- Artiklar:
- ;Â
- ;Â
- ;Â
- Â
- Video:
- ;
- ;
Slutsats
Data Quality â det hĂ€r Ă€r en mycket ung och lovande riktning, att vara en del av den innebĂ€r att vara en del av ett slags startup. Genom att gĂ„ in i Data Quality kommer du att dyka ner i en mĂ€ngd moderna eftertraktade teknologier, men det viktigaste Ă€r att det framför dig öppnar sig enorma möjligheter för att generera och förverkliga dina idĂ©er. Du kommer att kunna anvĂ€nda en kontinuerlig förbĂ€ttringsmetod inte bara i projektet utan ocksĂ„ för dig sjĂ€lv, och dĂ€rigenom stĂ€ndigt utvecklas som specialist.
KĂ€lla: habr.com
