Hej alle sammen, mit navn er Alexander, og jeg er en datakvalitetsingeniør, der kontrollerer data for deres kvalitet. Denne artikel vil tale om, hvordan jeg kom til dette, og hvorfor dette testområde i 2020 var på toppen af en bølge.
Global trend
Dagens verden oplever endnu en teknologisk revolution, hvor et aspekt er brugen af akkumulerede data af alle slags virksomheder til at fremme deres eget svinghjul af salg, overskud og PR. Det ser ud til, at tilstedeværelsen af gode (kvalitets)data, samt dygtige hjerner, der kan tjene penge på det (korrekt bearbejde, visualisere, bygge machine learning-modeller osv.), er blevet nøglen til succes for mange i dag. Hvis store virksomheder for 15-20 år siden hovedsageligt var involveret i intensivt arbejde med dataakkumulering og indtægtsgenerering, er det i dag næsten alle fornuftige menneskers lod.
I denne henseende begyndte alle portaler dedikeret til jobsøgning rundt om i verden for flere år siden at blive fyldt med ledige stillinger for Data Scientists, da alle var sikre på, at efter at have hyret en sådan specialist ville det være muligt at bygge en supermodel af maskinlæring , forudsige fremtiden og udføre et "kvantespring" for virksomheden. Over tid indså folk, at denne tilgang næsten aldrig virker nogen steder, da ikke alle de data, der falder i hænderne på sådanne specialister, er egnede til træningsmodeller.
Og anmodninger fra Data Scientists begyndte: "Lad os købe flere data fra disse og dem...", "Vi har ikke nok data...", "Vi har brug for nogle flere data, helst en af høj kvalitet..." . Baseret på disse anmodninger begyndte der at bygges adskillige interaktioner mellem virksomheder, der ejer et eller andet sæt data. Dette krævede naturligvis den tekniske tilrettelæggelse af denne proces - at oprette forbindelse til datakilden, downloade den, kontrollere, at den var fuldt indlæst osv. Antallet af sådanne processer begyndte at vokse, og i dag har vi et enormt behov for en anden form for specialister - Datakvalitetsingeniører - dem, der vil overvåge strømmen af data i systemet (datapipelines), kvaliteten af data ved input og output og drage konklusioner om deres tilstrækkelighed, integritet og andre egenskaber.
Tendensen for datakvalitetsingeniører kom til os fra USA, hvor ingen, midt i kapitalismens rasende æra, er klar til at tabe kampen om data. Nedenfor har jeg givet skærmbilleder fra to af de mest populære jobsøgningssider i USA: и — som viser data pr. 17. marts 2020 om antallet af opslåede ledige stillinger modtaget ved hjælp af nøgleordene: Data Quality and Data Scientist.
Data Scientists – 21416 ledige stillinger
Datakvalitet – 41104 ledige stillinger
Data Scientists – 404 ledige stillinger
Datakvalitet – 2020 ledige stillinger
Det er klart, at disse erhverv på ingen måde konkurrerer med hinanden. Med skærmbilleder ville jeg blot illustrere den aktuelle situation på arbejdsmarkedet i form af forespørgsler til Data Quality ingeniører, hvoraf der er behov for meget flere nu end Data Scientists.
I juni 2019 opdelte EPAM, som svar på det moderne it-markeds behov, Datakvalitet i en separat praksis. Datakvalitetsingeniører administrerer i løbet af deres daglige arbejde data, kontrollerer deres adfærd i nye forhold og systemer, overvåger dataens relevans, deres tilstrækkelighed og relevans. Med alt dette, i praktisk forstand, bruger datakvalitetsingeniører virkelig meget lidt tid til klassisk funktionstest, MEN dette afhænger meget af projektet (jeg vil give et eksempel nedenfor).
Ansvaret for en datakvalitetsingeniør er ikke kun begrænset til rutinemæssig manuel/automatisk kontrol for "nuller, tællinger og summer" i databasetabeller, men kræver en dyb forståelse af kundens forretningsbehov og dermed evnen til at transformere tilgængelige data til nyttige forretningsoplysninger.
Datakvalitetsteori
For mere fuldstændigt at forestille os en sådan ingeniørs rolle, lad os finde ud af, hvad datakvalitet er i teorien.
Datakvalitet — et af stadierne i Data Management (en hel verden, som vi vil efterlade dig til at studere på egen hånd) og er ansvarlig for at analysere data i henhold til følgende kriterier:
Jeg tror, der ikke er behov for at dechifrere hvert af punkterne (i teorien kaldes de "datadimensioner"), de er ret godt beskrevet på billedet. Men selve testprocessen indebærer ikke strengt at kopiere disse funktioner til testcases og kontrollere dem. I Data Quality, som i enhver anden form for test, er det først og fremmest nødvendigt at bygge videre på de datakvalitetskrav, der er aftalt med de projektdeltagere, der træffer forretningsbeslutninger.
Afhængig af Data Quality-projektet kan en ingeniør udføre forskellige funktioner: fra en almindelig automatiseringstester med en overfladisk vurdering af datakvalitet, til en person, der udfører dyb profilering af dataene efter ovenstående kriterier.
En meget detaljeret beskrivelse af Data Management, Data Quality og relaterede processer er godt beskrevet i bogen kaldet "DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition". Jeg anbefaler stærkt denne bog som en introduktion til dette emne (du finder et link til den i slutningen af artiklen).
Min historie
I IT-branchen arbejdede jeg mig op fra Junior tester i produktvirksomheder til Lead Data Quality Engineer hos EPAM. Efter cirka to års arbejde som tester, havde jeg den faste overbevisning om, at jeg havde udført absolut alle typer test: regression, funktionel, stress, stabilitet, sikkerhed, UI osv. - og prøvet en lang række testværktøjer, efter at have arbejdede på samme tid i tre programmeringssprog: Java, Scala, Python.
Når jeg ser tilbage, forstår jeg, hvorfor mine færdigheder var så forskellige – jeg var involveret i datadrevne projekter, store som små. Det er det, der bragte mig ind i en verden med mange værktøjer og muligheder for vækst.
For at værdsætte de mange forskellige værktøjer og muligheder for at få ny viden og færdigheder, skal du blot se på billedet nedenfor, som viser de mest populære i "Data & AI"-verdenen.
Denne form for illustration er udarbejdet årligt af en af de berømte venturekapitalister Matt Turck, som kommer fra softwareudvikling. Her til hans blog og , hvor han arbejder som partner.
Jeg voksede fagligt særligt hurtigt, da jeg var den eneste tester på projektet, eller i hvert fald i starten af projektet. Det er på et sådant tidspunkt, at du skal være ansvarlig for hele testprocessen, og du har ingen mulighed for at trække dig tilbage, kun fremad. Først var det skræmmende, men nu er alle fordelene ved sådan en test åbenlyse for mig:
- Du begynder at kommunikere med hele teamet som aldrig før, da der ikke er nogen proxy for kommunikation: hverken testlederen eller andre testere.
- Fordybelsen i projektet bliver utrolig dyb, og du har information om alle komponenter, både generelt og detaljeret.
- Udviklere ser ikke på dig som "den fyr fra test, der ikke ved, hvad han laver", men snarere som en ligemand, der producerer utrolige fordele for holdet med sine automatiserede tests og forventning om fejl, der dukker op i en specifik komponent af produkt.
- Som et resultat er du mere effektiv, mere kvalificeret og mere efterspurgt.
Efterhånden som projektet voksede, blev jeg i 100 % af tilfældene mentor for nye testere, underviste dem og videregav den viden, jeg selv havde lært. Samtidig modtog jeg, afhængigt af projektet, ikke altid det højeste niveau af autotest-specialister fra ledelsen, og der var behov for enten at uddanne dem i automatisering (for interesserede) eller skabe værktøjer til brug i hverdagens aktiviteter (værktøjer) til at generere data og indlæse dem i systemet , et værktøj til at udføre belastningstest/stabilitetstest "hurtigt" osv.).
Eksempel på et konkret projekt
På grund af tavshedspligt kan jeg desværre ikke fortælle detaljeret om de projekter, jeg har arbejdet på, men jeg vil give eksempler på typiske opgaver for en Data Quality Engineer på et af projekterne.
Essensen af projektet er at implementere en platform til at forberede data til træning af maskinlæringsmodeller baseret på det. Kunden var en stor medicinalvirksomhed fra USA. Teknisk set var det en klynge , stiger til instanser, med flere mikrotjenester og det underliggende Open Source-projekt af EPAM - , tilpasset en specifik kundes behov (nu er projektet genfødt til ). ETL processer blev organiseret vha og flyttede data fra kundesystemer i Spande. Dernæst blev et Docker-billede af en maskinlæringsmodel implementeret på platformen, som blev trænet på friske data og ved hjælp af REST API-grænsefladen producerede forudsigelser, der var af interesse for virksomheden og løste specifikke problemer.
Visuelt så alt sådan her ud:
Der var masser af funktionel test på dette projekt, og i betragtning af hastigheden af funktionsudvikling og behovet for at opretholde tempoet i udgivelsescyklussen (to-ugers sprint), var det nødvendigt straks at tænke på at automatisere test af de mest kritiske komponenter af systemet. Det meste af selve den Kubernetes-baserede platform var dækket af autotest implementeret i + Python, men det var også nødvendigt at understøtte og udvide dem. Derudover blev der for kundens bekvemmelighed oprettet en GUI til at styre maskinlæringsmodeller implementeret til klyngen, samt muligheden for at specificere hvor og hvor data skal overføres til træning af modellerne. Denne omfattende tilføjelse indebar en udvidelse af automatiseret funktionstest, som for det meste blev udført gennem REST API-kald og et lille antal end-2-end UI-tests. Omkring ækvator for hele denne bevægelse fik vi selskab af en manuel tester, som gjorde et fremragende stykke arbejde med accepttest af produktversioner og kommunikation med kunden vedrørende accept af den næste udgivelse. På grund af ankomsten af en ny specialist kunne vi desuden dokumentere vores arbejde og tilføje flere meget vigtige manuelle kontroller, som var svære at automatisere med det samme.
Og endelig, efter at vi havde opnået stabilitet fra platformen og GUI-tilføjelsen over den, begyndte vi at bygge ETL-rørledninger ved hjælp af Apache Airflow DAG'er. Automatiseret datakvalitetskontrol blev udført ved at skrive specielle Airflow DAG'er, der kontrollerede dataene baseret på resultaterne af ETL-processen. Som en del af dette projekt var vi heldige, og kunden gav os adgang til anonymiserede datasæt, som vi testede på. Vi kontrollerede dataene linje for linje for overholdelse af typer, tilstedeværelsen af ødelagte data, det samlede antal poster før og efter, sammenligning af transformationer foretaget af ETL-processen til aggregering, ændring af kolonnenavne og andre ting. Derudover blev disse kontroller skaleret til forskellige datakilder, for eksempel udover SalesForce også til MySQL.
Afsluttende datakvalitetstjek blev udført allerede på S3-niveau, hvor de blev opbevaret og var klar til brug til træning af maskinlæringsmodeller. For at hente data fra den endelige CSV-fil på S3 Bucket og validere den, blev kode skrevet vha .
Der var også et krav fra kunden om at opbevare en del af dataene i en S3 Bucket og en del i en anden. Dette krævede også at skrive yderligere kontroller for at kontrollere pålideligheden af en sådan sortering.
Generel erfaring fra andre projekter
Et eksempel på den mest generelle liste over aktiviteter for en datakvalitetsingeniør:
- Forbered testdata (gyldig ugyldig stor lille) gennem et automatiseret værktøj.
- Upload det forberedte datasæt til den originale kilde og kontroller, at det er klar til brug.
- Start ETL-processer til behandling af et sæt data fra kildelageret til det endelige eller mellemliggende lager ved hjælp af et bestemt sæt indstillinger (indstil om muligt konfigurerbare parametre for ETL-opgaven).
- Bekræft data behandlet af ETL-processen for deres kvalitet og overholdelse af forretningskrav.
Samtidig bør hovedfokus ved tjek ikke kun være på, at datastrømmen i systemet i princippet har fungeret og nået færdiggørelse (hvilket er en del af funktionstest), men mest på kontrol og validering af data mhp. overholdelse af forventede krav, identificering af uregelmæssigheder og andre ting.
Værktøj
En af teknikkerne til en sådan datakontrol kan være tilrettelæggelse af kædetjek på hvert trin af databehandlingen, den såkaldte "datakæde" i litteraturen - kontrol af data fra kilden til det endelige brug. Disse typer kontroller implementeres oftest ved at skrive kontrollerede SQL-forespørgsler. Det er klart, at sådanne forespørgsler skal være så lette som muligt og kontrollere individuelle stykker datakvalitet (tabellers metadata, tomme linjer, NULL'er, fejl i syntaks - andre attributter, der kræves til kontrol).
I tilfælde af regressionstest, som bruger færdige (uforanderlige, let udskiftelige) datasæt, kan autotestkoden gemme færdige skabeloner til kontrol af data for overensstemmelse med kvalitet (beskrivelser af forventede tabelmetadata; rækkeeksempelobjekter, der kan valgt tilfældigt under testen osv.).
Under test skal du også skrive ETL-testprocesser ved hjælp af rammer såsom Apache Airflow, eller endda et sort-boks-sky-værktøj , Og så videre. Denne omstændighed tvinger testingeniøren til at fordybe sig i principperne for driften af ovenstående værktøjer og endnu mere effektivt både udføre funktionel test (for eksempel eksisterende ETL-processer på et projekt) og bruge dem til at kontrollere data. Især Apache Airflow har færdige operatører til at arbejde med f.eks. populære analytiske databaser . Det mest grundlæggende eksempel på dets brug er allerede blevet skitseret , så jeg vil ikke gentage mig selv.
Bortset fra færdige løsninger er der ingen, der forbyder dig at implementere dine egne teknikker og værktøjer. Dette vil ikke kun være gavnligt for projektet, men også for datakvalitetsingeniøren selv, som dermed vil forbedre sine tekniske horisonter og kodningsevner.
Hvordan det fungerer på et rigtigt projekt
En god illustration af de sidste afsnit om "datakæden", ETL og allestedsnærværende kontroller er følgende proces fra et af de rigtige projekter:
Her kommer forskellige data (naturligvis udarbejdet af os) ind i input-"tragten" i vores system: gyldig, ugyldig, blandet osv., så filtreres de og ender i et mellemlager, så gennemgår de igen en række transformationer og placeres i det endelige lager, hvorfra der igen vil blive udført analyser, opbygning af data marts og søgning efter forretningsindsigt. I et sådant system, uden funktionelt at kontrollere driften af ETL-processer, fokuserer vi på kvaliteten af data før og efter transformationer, samt på output til analyse.
For at opsummere ovenstående, uanset hvor jeg arbejdede, var jeg overalt involveret i dataprojekter, der delte følgende funktioner:
- Kun gennem automatisering kan du teste nogle cases og opnå en udgivelsescyklus, der er acceptabel for virksomheden.
- En tester på et sådant projekt er et af de mest respekterede medlemmer af teamet, da det giver store fordele for hver af deltagerne (acceleration af test, gode data fra Data Scientist, identifikation af defekter i de tidlige stadier).
- Det er ligegyldigt, om du arbejder på din egen hardware eller i skyerne - alle ressourcer er abstraheret i en klynge som Hortonworks, Cloudera, Mesos, Kubernetes osv.
- Projekter er bygget på en mikroservice tilgang, distribueret og parallel computing dominerer.
Jeg vil gerne bemærke, at når en testspecialist laver test inden for datakvalitet, flytter en testspecialist sit faglige fokus til produktets kode og de anvendte værktøjer.
Karakteristiske træk ved test af datakvalitet
Derudover har jeg for mig selv identificeret følgende (jeg vil straks tage forbehold for, at de er MEGET generaliserede og udelukkende subjektive) karakteristiske træk ved test i Data (Big Data) projekter (systemer) og andre områder:
Nyttige links
- Teori: .
- EPAM
- Anbefalede materialer til en begyndende datakvalitetsingeniør:
- Gratis kursus om Stepik: .
- Kursus om LinkedIn Learning: .
- Artikler:
- ;
- ;
- ;
- Video:
- ;
- ;
Konklusion
Datakvalitet er en meget ung lovende retning, at være en del af hvilket betyder at være en del af en startup. Når du først er i Data Quality, vil du blive fordybet i en lang række moderne, efterspurgte teknologier, men vigtigst af alt vil der åbne sig enorme muligheder for, at du kan generere og implementere dine ideer. Du vil være i stand til at bruge den kontinuerlige forbedringstilgang ikke kun på projektet, men også for dig selv, idet du løbende udvikler dig som specialist.
Kilde: www.habr.com