Hej alla, jag heter Alexander och jag är en datakvalitetsingenjör som kontrollerar data för dess kvalitet. Den här artikeln kommer att prata om hur jag kom till detta och varför 2020 detta testområde var på toppen av en våg.
global trend
Dagens värld upplever ännu en teknisk revolution, vars ena aspekt är användningen av ackumulerad data av alla typer av företag för att främja sitt eget svänghjul av försäljning, vinster och PR. Det verkar som att närvaron av bra (kvalitets)data, såväl som skickliga hjärnor som kan tjäna pengar på det (korrekt bearbeta, visualisera, bygga maskininlärningsmodeller etc.), har blivit nyckeln till framgång för många idag. Om stora företag för 15-20 år sedan huvudsakligen var involverade i ett intensivt arbete med dataackumulering och monetarisering, så är detta idag nästan alla friska människors lott.
I detta avseende började alla portaler för jobbsökning runt om i världen för flera år sedan fyllas med lediga tjänster för dataforskare, eftersom alla var säkra på att det skulle vara möjligt att bygga en supermodell av maskininlärning efter att ha anställt en sådan specialist. , förutsäga framtiden och göra ett "kvantsprång" för företaget. Med tiden insåg människor att detta tillvägagångssätt nästan aldrig fungerar någonstans, eftersom inte all data som faller i händerna på sådana specialister är lämpliga för träningsmodeller.
Och förfrågningar från Data Scientists började: "Låt oss köpa mer data från dessa och de...", "Vi har inte tillräckligt med data...", "Vi behöver lite mer data, helst en av hög kvalitet..." . Baserat på dessa förfrågningar började många interaktioner byggas mellan företag som äger en eller annan uppsättning data. Naturligtvis krävde detta den tekniska organisationen av denna process - att ansluta till datakällan, ladda ner den, kontrollera att den laddades i sin helhet, etc. Antalet sådana processer började växa, och idag har vi ett stort behov av en annan typ av specialister - Datakvalitetsingenjörer - de som skulle övervaka flödet av data i systemet (datapipelines), kvaliteten på data vid ingång och utgång och dra slutsatser om deras tillräcklighet, integritet och andra egenskaper.
Trenden för datakvalitetsingenjörer kom till oss från USA, där, mitt i kapitalismens rasande era, ingen är redo att förlora kampen om data. Nedan har jag tillhandahållit skärmdumpar från två av de mest populära jobbsökningssidorna i USA: и — som visar data från och med den 17 mars 2020 om antalet utstationerade lediga tjänster som tagits emot med hjälp av nyckelorden: Data Quality and Data Scientist.
Data Scientists – 21416 lediga tjänster
Datakvalitet – 41104 lediga tjänster
Data Scientists – 404 lediga tjänster
Datakvalitet – 2020 lediga jobb
Uppenbarligen konkurrerar dessa yrken inte på något sätt med varandra. Med skärmdumpar ville jag bara illustrera den nuvarande situationen på arbetsmarknaden när det gäller förfrågningar om Data Quality-ingenjörer, av vilka det behövs mycket fler nu än Data Scientists.
I juni 2019 delade EPAM, som svar på behoven på den moderna IT-marknaden, upp datakvalitet i en separat praxis. Datakvalitetsingenjörer hanterar i sitt dagliga arbete data, kontrollerar dess beteende i nya förhållanden och system, övervakar datas relevans, dess tillräcklighet och relevans. Med allt detta, i praktisk mening, ägnar datakvalitetsingenjörer verkligen lite tid åt klassisk funktionstestning, MEN detta beror mycket på projektet (jag ger ett exempel nedan).
Ansvaret för en datakvalitetsingenjör är inte begränsade till rutinmässiga manuella/automatiska kontroller för "null-, räkningar och summor" i databastabeller, utan kräver en djup förståelse för kundens affärsbehov och, följaktligen, förmågan att omvandla tillgänglig data till användbar affärsinformation.
Datakvalitetsteori
För att bättre kunna föreställa oss rollen för en sådan ingenjör, låt oss ta reda på vad datakvalitet är i teorin.
Datakvalitet — ett av stadierna av Data Management (en hel värld som vi lämnar för dig att studera på egen hand) och ansvarar för att analysera data enligt följande kriterier:
Jag tror att det inte finns något behov av att dechiffrera var och en av punkterna (i teorin kallas de "datadimensioner"), de är ganska väl beskrivna på bilden. Men själva testprocessen innebär inte att man strikt kopierar dessa funktioner till testfall och kontrollerar dem. Inom datakvalitet, som i alla andra typer av testning, är det först och främst nödvändigt att bygga vidare på de datakvalitetskrav som överenskommits med projektdeltagarna som fattar affärsbeslut.
Beroende på Data Quality-projektet kan en ingenjör utföra olika funktioner: från en vanlig automationstestare med en ytlig bedömning av datakvalitet, till en person som gör en djupgående profilering av datan enligt ovanstående kriterier.
En mycket detaljerad beskrivning av datahantering, datakvalitet och relaterade processer beskrivs väl i boken som heter "DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition". Jag rekommenderar starkt den här boken som en introduktion till detta ämne (du hittar en länk till den i slutet av artikeln).
Min historia
I IT-branschen arbetade jag mig upp från en Junior testare i produktföretag till en Lead Data Quality Engineer på EPAM. Efter ungefär två års arbete som testare hade jag den fasta övertygelsen att jag hade gjort absolut alla typer av tester: regression, funktionell, stress, stabilitet, säkerhet, UI, etc. - och provat ett stort antal testverktyg, med arbetade samtidigt i tre programmeringsspråk: Java, Scala, Python.
När jag ser tillbaka förstår jag varför min kompetens var så mångsidig – jag var involverad i datadrivna projekt, stora som små. Detta är vad som förde mig in i en värld av många verktyg och möjligheter för tillväxt.
För att uppskatta mångfalden av verktyg och möjligheter att få nya kunskaper och färdigheter, titta bara på bilden nedan, som visar de mest populära inom "Data & AI"-världen.
Den här typen av illustrationer sammanställs årligen av en av de kända riskkapitalisterna Matt Turck, som kommer från mjukvaruutveckling. Här till hans blogg och , där han arbetar som partner.
Jag växte professionellt särskilt snabbt när jag var den enda testaren på projektet, eller åtminstone i början av projektet. Det är i ett sådant ögonblick som du måste ansvara för hela testprocessen, och du har ingen möjlighet att dra dig tillbaka, bara framåt. Först var det läskigt, men nu är alla fördelarna med ett sådant test uppenbara för mig:
- Du börjar kommunicera med hela teamet som aldrig förr, eftersom det inte finns någon proxy för kommunikation: varken testledaren eller andra testare.
- Fördjupningen i projektet blir otroligt djup, och du har information om alla komponenter, både generellt och i detalj.
- Utvecklare ser inte på dig som "den där killen från att testa som inte vet vad han gör", utan snarare som en jämlik person som skapar otroliga fördelar för teamet med sina automatiserade tester och förväntan om buggar som dyker upp i en specifik komponent av produkt.
- Som ett resultat är du mer effektiv, mer kvalificerad och mer efterfrågad.
I takt med att projektet växte blev jag i 100 % av fallen mentor för nya testare, undervisade dem och förmedlade kunskapen som jag själv hade lärt mig. Samtidigt, beroende på projekt, fick jag inte alltid den högsta nivån av autotestspecialister från ledningen och det fanns ett behov av att antingen utbilda dem i automation (för intresserade) eller skapa verktyg för användning i vardagliga aktiviteter (verktyg) för att generera data och ladda in den i systemet , ett verktyg för att utföra lasttestning/stabilitetstestning "snabbt" etc.).
Exempel på ett specifikt projekt
På grund av sekretessskyldigheter kan jag tyvärr inte berätta i detalj om de projekt som jag arbetat med, men jag kommer att ge exempel på typiska uppgifter för en Data Quality Engineer på ett av projekten.
Kärnan i projektet är att implementera en plattform för att förbereda data för träning av maskininlärningsmodeller baserade på den. Kunden var ett stort läkemedelsföretag från USA. Tekniskt sett var det ett kluster , stiger till instanser, med flera mikrotjänster och det underliggande Open Source-projektet av EPAM - , anpassad till en specifik kunds behov (nu har projektet återfödts till ). ETL-processer organiserades med hjälp av och flyttade data från kundsystem i Hinkar. Därefter distribuerades en Docker-bild av en maskininlärningsmodell på plattformen, som tränades på färsk data och, med hjälp av REST API-gränssnittet, producerade förutsägelser som var av intresse för verksamheten och löste specifika problem.
Visuellt såg allt ut ungefär så här:
Det fanns gott om funktionstestning på detta projekt, och med tanke på hastigheten i utvecklingen av funktioner och behovet av att upprätthålla takten i releasecykeln (två veckors sprints), var det nödvändigt att omedelbart tänka på att automatisera testning av de mest kritiska komponenterna i systemet. Det mesta av den Kubernetes-baserade plattformen i sig täcktes av autotester implementerade i + Python, men det var också nödvändigt att stödja och utöka dem. För kundens bekvämlighet skapades dessutom ett GUI för att hantera maskininlärningsmodeller som distribueras till klustret, samt möjligheten att specificera var och var data behöver överföras för att träna modellerna. Detta omfattande tillägg innebar en utökning av automatiserad funktionstestning, vilket mestadels gjordes genom REST API-anrop och ett litet antal end-2-end UI-tester. Runt ekvatorn för all denna rörelse fick vi sällskap av en manuell testare som gjorde ett utmärkt jobb med acceptanstestning av produktversioner och kommunikation med kunden angående acceptans av nästa release. På grund av tillkomsten av en ny specialist kunde vi dessutom dokumentera vårt arbete och lägga till flera mycket viktiga manuella kontroller som var svåra att automatisera direkt.
Och slutligen, efter att vi uppnått stabilitet från plattformen och GUI-tillägget över den, började vi bygga ETL-pipelines med Apache Airflow DAGs. Automatiserad datakvalitetskontroll utfördes genom att skriva speciella Airflow DAGs som kontrollerade data baserat på resultaten av ETL-processen. Som en del av 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 för överensstämmelse med typer, förekomsten av trasiga data, det totala antalet poster före och efter, jämförelse av transformationer gjorda av ETL-processen för aggregering, ändra kolumnnamn och annat. Dessutom skalades dessa kontroller till olika datakällor, till exempel, förutom SalesForce, även till MySQL.
Slutliga datakvalitetskontroller genomfördes redan på S3-nivå, där de lagrades och var färdiga att använda för att träna maskininlärningsmodeller. För att hämta data från den slutliga CSV-filen som finns på S3 Bucket och validera den skrevs kod med hjälp av .
Det fanns också ett krav från kunden att lagra en del av datan i en S3 Bucket och en del i en annan. Detta krävde också att ytterligare kontroller skrevs för att kontrollera tillförlitligheten av sådan sortering.
Generell erfarenhet från andra projekt
Ett exempel på den mest allmänna listan över aktiviteter för en datakvalitetsingenjör:
- Förbered testdata (giltig ogiltig stor liten) genom ett automatiserat verktyg.
- Ladda upp den förberedda datamängden till den ursprungliga källan och kontrollera att den är redo att användas.
- Starta ETL-processer för att bearbeta en uppsättning data från källlagringen till den slutliga eller mellanliggande lagringen med en viss uppsättning inställningar (om möjligt, ställ in konfigurerbara parametrar för ETL-uppgiften).
- Verifiera data som behandlas av ETL-processen för dess kvalitet och överensstämmelse med affärskrav.
Samtidigt ska huvudfokus vid kontroller inte bara ligga på att dataflödet i systemet i princip har fungerat och nått slutet (vilket är en del av funktionstestning), utan mest på att kontrollera och validera data för att uppfylla förväntade krav, identifiera avvikelser och annat.
Verktyg
En av teknikerna för sådan datakontroll kan vara att organisera kedjekontroller i varje steg av databehandlingen, den så kallade "datakedjan" i litteraturen - kontroll av data från källan till den slutliga användningspunkten. Dessa typer av kontroller implementeras oftast genom att skriva checkande SQL-frågor. Det är tydligt att sådana frågor bör vara så lätta som möjligt och kontrollera enskilda delar av datakvalitet (tabeller metadata, tomma rader, NULLs, Fel i syntax - andra attribut som krävs för kontroll).
När det gäller regressionstestning, som använder färdiga (oföränderliga, något föränderliga) datamängder, kan autotestkoden lagra färdiga mallar för att kontrollera data för överensstämmelse med kvalitet (beskrivningar av förväntad tabellmetadata; radexempelobjekt som kan väljs slumpmässigt under testet etc.).
Under testning måste du också skriva ETL-testprocesser med ramverk som Apache Airflow, eller till och med ett verktyg av typen black-box moln , Och så vidare. Denna omständighet tvingar testingenjören att fördjupa sig i principerna för driften av ovanstående verktyg och ännu mer effektivt både utföra funktionstestning (till exempel befintliga ETL-processer på ett projekt) och använda dem för att kontrollera data. Speciellt Apache Airflow har färdiga operatörer för att arbeta med till exempel populära analytiska databaser . Det mest grundläggande exemplet på dess användning har redan beskrivits , så jag ska inte upprepa mig.
Förutom färdiga lösningar är det ingen som förbjuder dig att implementera dina egna tekniker och verktyg. Detta kommer inte bara att vara fördelaktigt för projektet, utan också för datakvalitetsingenjören själv, som därmed kommer att förbättra sina tekniska horisonter och kodningsförmåga.
Hur det fungerar på ett riktigt projekt
En bra illustration av de sista styckena om "datakedjan", ETL och allestädes närvarande kontroller är följande process från ett av de verkliga projekten:
Här kommer olika data (naturligtvis framställda av oss) in i vårt systems ingångs-"tratt": giltig, ogiltig, blandad, etc., sedan filtreras de och hamnar i ett mellanlagring, sedan genomgår de återigen en serie transformationer och placeras i den slutliga lagringen, från vilken i sin tur analyser, byggande av datamarts och sökning efter affärsinsikter kommer att utföras. I ett sådant system, utan att funktionellt kontrollera driften av ETL-processer, fokuserar vi på kvaliteten på data före och efter transformationer, såväl som på output till analys.
För att sammanfatta ovanstående, oavsett var jag arbetade, var jag överallt involverad i dataprojekt som delade följande egenskaper:
- Endast genom automatisering kan du testa vissa fall och uppnå en releasecykel som är acceptabel för verksamheten.
- En testare på ett sådant projekt är en av de mest respekterade medlemmarna i teamet, eftersom det ger stora fördelar för var och en av deltagarna (acceleration av testning, bra data från dataforskaren, identifiering av defekter i tidiga skeden).
- Det spelar ingen roll om du arbetar med din egen hårdvara eller i molnen - alla resurser abstraheras till ett kluster som Hortonworks, Cloudera, Mesos, Kubernetes, etc.
- Projekt bygger på en mikrotjänstmetod, distribuerad och parallell beräkning dominerar.
Jag skulle vilja notera att när en testspecialist gör tester inom området datakvalitet flyttar en testspecialist sitt professionella fokus till produktens kod och de verktyg som används.
Utmärkande egenskaper för testning av datakvalitet
Dessutom, för mig själv, har jag identifierat följande (jag kommer omedelbart att reservera mig för att de är MYCKET generaliserade och uteslutande subjektiva) särdrag för testning i Data (Big Data) projekt (system) och andra områden:
Användbara länkar
- Teori: .
- EPAM
- Rekommenderat material för en nybörjare som datakvalitetsingenjör:
- Gratis kurs om Stepik: .
- Kurs om LinkedIn Learning: .
- Artiklar:
- ;
- ;
- ;
- videor:
- ;
- ;
Slutsats
Datakvalitet är en mycket ung lovande riktning, att vara en del av vilket innebär att vara en del av en startup. Väl i Data Quality kommer du att fördjupas i ett stort antal moderna, efterfrågade teknologier, men viktigast av allt kommer enorma möjligheter att öppnas för dig att generera och implementera dina idéer. Du kommer att kunna använda den ständiga förbättringsmetoden inte bara på projektet, utan också för dig själv, ständigt utvecklas som specialist.
Källa: will.com