Hei alle sammen, jeg heter Alexander, og jeg er en datakvalitetsingeniør som sjekker data for kvaliteten. Denne artikkelen vil snakke om hvordan jeg kom til dette og hvorfor i 2020 dette området for testing var på toppen av en bølge.
Global trend
Dagens verden opplever nok en teknologisk revolusjon, hvorav ett aspekt er bruken av akkumulerte data av alle slags selskaper for å fremme sitt eget svinghjul av salg, fortjeneste og PR. Det ser ut til at tilstedeværelsen av gode (kvalitets)data, samt dyktige hjerner som kan tjene penger på det (korrekt behandle, visualisere, bygge maskinlæringsmodeller osv.), har blitt nøkkelen til suksess for mange i dag. Hvis store selskaper for 15-20 år siden hovedsakelig var involvert i intensivt arbeid med dataakkumulering og inntektsgenerering, er dette i dag loddet til nesten alle tilregnelige mennesker.
I denne forbindelse begynte alle portaler dedikert til jobbsøk rundt om i verden for flere år siden å bli fylt med ledige stillinger for dataforskere, siden alle var sikre på at etter å ha ansatt en slik spesialist, ville det være mulig å bygge en supermodell for maskinlæring , forutsi fremtiden og utføre et "kvantesprang" for selskapet. Over tid innså folk at denne tilnærmingen nesten aldri fungerer hvor som helst, siden ikke alle dataene som faller i hendene på slike spesialister er egnet for treningsmodeller.
Og forespørsler fra Data Scientists begynte: "La oss kjøpe mer data fra disse og de ...", "Vi har ikke nok data ...", "Vi trenger litt mer data, helst en av høy kvalitet ..." . Basert på disse forespørslene begynte det å bygges en rekke interaksjoner mellom selskaper som eier et eller annet sett med data. Dette krevde naturligvis den tekniske organiseringen av denne prosessen - å koble til datakilden, laste den ned, sjekke at den ble lastet i sin helhet osv. Antall slike prosesser begynte å vokse, og i dag har vi et stort behov for en annen type spesialister - Datakvalitetsingeniører - de som vil overvåke dataflyten i systemet (datarørledninger), kvaliteten på data ved inngang og utgang, og trekke konklusjoner om deres tilstrekkelighet, integritet og andre egenskaper.
Trenden for datakvalitetsingeniører kom til oss fra USA, der, midt i kapitalismens rasende epoke, er ingen klar til å tape kampen om data. Nedenfor har jeg gitt skjermbilder fra to av de mest populære jobbsøkesidene i USA: и — som viser data per 17. mars 2020 om antall utlyste ledige stillinger mottatt ved å bruke søkeordene: 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 profesjonene på ingen måte konkurrerer med hverandre. Med skjermbilder ville jeg bare illustrere dagens situasjon på arbeidsmarkedet når det gjelder forespørsler om datakvalitetsingeniører, som det trengs mye flere av nå enn dataforskere.
I juni 2019, delte EPAM, i samsvar med behovene til det moderne IT-markedet, datakvalitet i en egen praksis. Datakvalitetsingeniører, i løpet av sitt daglige arbeid, administrerer data, sjekker atferden i nye forhold og systemer, overvåker relevansen til dataene, dens tilstrekkelighet og relevans. Med alt dette, i praktisk forstand, bruker datakvalitetsingeniører virkelig lite tid til klassisk funksjonstesting, MEN dette avhenger i stor grad av prosjektet (jeg vil gi et eksempel nedenfor).
Ansvaret til en datakvalitetsingeniør er ikke bare begrenset til rutinemessige manuelle/automatiske kontroller for "null, tellinger og summer" i databasetabeller, men krever en dyp forståelse av kundens forretningsbehov og følgelig evnen til å transformere tilgjengelige data til nyttig forretningsinformasjon.
Datakvalitetsteori
For å kunne forestille oss rollen til en slik ingeniør, la oss finne ut hva datakvalitet er i teorien.
Datakvalitet — en av stadiene av Data Management (en hel verden som vi vil forlate for deg å studere på egen hånd) og er ansvarlig for å analysere data i henhold til følgende kriterier:
Jeg tror det ikke er nødvendig å dechiffrere hvert av punktene (i teorien kalles de "datadimensjoner"), de er ganske godt beskrevet på bildet. Men selve testprosessen innebærer ikke strengt å kopiere disse funksjonene inn i testsaker og sjekke dem. I datakvalitet, som i enhver annen type testing, er det først og fremst nødvendig å bygge på datakvalitetskravene som er avtalt med prosjektdeltakerne som tar forretningsbeslutninger.
Avhengig av Data Quality-prosjektet kan en ingeniør utføre ulike funksjoner: fra en vanlig automatiseringstester med en overfladisk vurdering av datakvalitet, til en person som utfører dyp profilering av dataene i henhold til kriteriene ovenfor.
En meget detaljert beskrivelse av Data Management, Data Quality og relaterte prosesser er godt beskrevet i boken kalt "DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition". Jeg anbefaler denne boken på det sterkeste som en introduksjon til dette emnet (du finner en lenke til den på slutten av artikkelen).
Historien min
I IT-bransjen jobbet jeg meg opp fra en Junior-tester i produktselskaper til en Lead Data Quality Engineer hos EPAM. Etter omtrent to års arbeid som tester, hadde jeg den faste overbevisningen om at jeg hadde utført absolutt alle typer tester: regresjon, funksjonell, stress, stabilitet, sikkerhet, brukergrensesnitt osv. - og prøvd et stort antall testverktøy, med jobbet samtidig i tre programmeringsspråk: Java, Scala, Python.
Når jeg ser tilbake, forstår jeg hvorfor ferdighetene mine var så mangfoldige – jeg var involvert i datadrevne prosjekter, store og små. Dette er det som brakte meg inn i en verden med mange verktøy og muligheter for vekst.
For å sette pris på mangfoldet av verktøy og muligheter for å få ny kunnskap og ferdigheter, se bare på bildet nedenfor, som viser de mest populære i "Data & AI"-verdenen.
Denne typen illustrasjoner kompileres årlig av en av de kjente risikokapitalistene Matt Turck, som kommer fra programvareutvikling. Her til bloggen hans og , hvor han jobber som partner.
Jeg vokste profesjonelt spesielt raskt da jeg var den eneste testeren på prosjektet, eller i det minste i starten av prosjektet. Det er i et slikt øyeblikk du må være ansvarlig for hele testprosessen, og du har ingen mulighet til å trekke deg tilbake, bare fremover. Først var det skummelt, men nå er alle fordelene med en slik test åpenbare for meg:
- Du begynner å kommunisere med hele teamet som aldri før, siden det ikke er noen proxy for kommunikasjon: verken testlederen eller andre testere.
- Fordypningen i prosjektet blir utrolig dyp, og du har informasjon om alle komponenter, både generelt og i detalj.
- Utviklere ser ikke på deg som «den fyren fra testing som ikke vet hva han gjør», men snarere som en likemann som produserer utrolige fordeler for teamet med sine automatiserte tester og påvente av feil som dukker opp i en spesifikk komponent av produkt.
- Som et resultat er du mer effektiv, mer kvalifisert og mer etterspurt.
Etter hvert som prosjektet vokste, ble jeg i 100 % av tilfellene en mentor for nye testere, lærte dem og videreformidlet kunnskapen jeg hadde lært selv. Samtidig, avhengig av prosjektet, mottok jeg ikke alltid det høyeste nivået av autotestspesialister fra ledelsen, og det var behov for enten å trene dem i automatisering (for de som er interessert) eller lage verktøy for bruk i daglige aktiviteter (verktøy for å generere data og laste dem inn i systemet , et verktøy for å utføre lasttesting/stabilitetstesting "raskt", etc.).
Eksempel på et spesifikt prosjekt
På grunn av taushetsplikt kan jeg dessverre ikke snakke i detalj om prosjektene jeg jobbet med, men jeg vil gi eksempler på typiske oppgaver til en Data Quality Engineer på ett av prosjektene.
Essensen av prosjektet er å implementere en plattform for å forberede data for opplæring av maskinlæringsmodeller basert på den. Kunden var et stort farmasøytisk selskap fra USA. Teknisk sett var det en klynge , stiger til forekomster, med flere mikrotjenester og det underliggende Open Source-prosjektet til EPAM - , tilpasset behovene til en spesifikk kunde (nå er prosjektet gjenfødt til ). ETL-prosesser ble organisert ved hjelp av og flyttet data fra kundesystemer i Bøtter. Deretter ble et Docker-bilde av en maskinlæringsmodell distribuert på plattformen, som ble trent på ferske data og, ved hjelp av REST API-grensesnittet, produserte spådommer som var av interesse for virksomheten og løste spesifikke problemer.
Visuelt så alt omtrent slik ut:
Det var rikelig med funksjonstesting på dette prosjektet, og gitt hastigheten på funksjonsutvikling og behovet for å opprettholde tempoet i utgivelsessyklusen (to ukers sprint), var det nødvendig å umiddelbart tenke på å automatisere testing av de mest kritiske komponentene i systemet. Det meste av selve den Kubernetes-baserte plattformen ble dekket av autotester implementert i + Python, men det var også nødvendig å støtte og utvide dem. I tillegg, for kundens bekvemmelighet, ble det laget en GUI for å administrere maskinlæringsmodeller distribuert til klyngen, samt muligheten til å spesifisere hvor og hvor data må overføres for opplæring av modellene. Dette omfattende tillegget innebar en utvidelse av automatisert funksjonell testing, som for det meste ble gjort gjennom REST API-kall og et lite antall end-2-end UI-tester. Rundt ekvator for all denne bevegelsen fikk vi selskap av en manuell tester som gjorde en utmerket jobb med aksepttesting av produktversjoner og kommunikasjon med kunden angående aksept av neste utgivelse. I tillegg, på grunn av ankomsten av en ny spesialist, kunne vi dokumentere arbeidet vårt og legge til flere svært viktige manuelle kontroller som var vanskelig å automatisere med en gang.
Og til slutt, etter at vi oppnådde stabilitet fra plattformen og GUI-tillegget over den, begynte vi å bygge ETL-rørledninger ved å bruke Apache Airflow DAG-er. Automatisert datakvalitetskontroll ble utført ved å skrive spesielle Airflow DAG-er som sjekket dataene basert på resultatene av ETL-prosessen. Som en del av dette prosjektet var vi heldige og kunden ga oss tilgang til anonymiserte datasett som vi testet. Vi sjekket dataene linje for linje for samsvar med typer, tilstedeværelsen av ødelagte data, totalt antall poster før og etter, sammenligning av transformasjoner gjort av ETL-prosessen for aggregering, endring av kolonnenavn og andre ting. I tillegg ble disse sjekkene skalert til forskjellige datakilder, for eksempel i tillegg til SalesForce, også til MySQL.
Endelige datakvalitetskontroller ble utført allerede på S3-nivå, hvor de ble lagret og var klare til bruk for opplæring av maskinlæringsmodeller. For å hente data fra den endelige CSV-filen som ligger på S3 Bucket og validere den, ble kode skrevet ved hjelp av .
Det var også krav fra kunden om å lagre deler av dataene i en S3 Bucket og en del i en annen. Dette krevde også å skrive tilleggssjekker for å sjekke påliteligheten til slik sortering.
Generell erfaring fra andre prosjekter
Et eksempel på den mest generelle listen over aktiviteter til en datakvalitetsingeniør:
- Forbered testdata (gyldig ugyldig stor liten) gjennom et automatisert verktøy.
- Last opp det forberedte datasettet til den opprinnelige kilden og kontroller at det er klart til bruk.
- Start ETL-prosesser for å behandle et sett med data fra kildelagringen til den endelige eller mellomliggende lagringen ved å bruke et bestemt sett med innstillinger (hvis mulig, angi konfigurerbare parametere for ETL-oppgaven).
- Bekreft data som behandles av ETL-prosessen for deres kvalitet og samsvar med forretningskrav.
Samtidig bør hovedfokus ved kontroller ikke bare være på at dataflyten i systemet i prinsippet har fungert og nådd ferdigstillelse (som er en del av funksjonstesting), men mest på å sjekke og validere data mht. etterlevelse av forventede krav, identifisering av anomalier og andre ting.
Verktøy
En av teknikkene for slik datakontroll kan være organisering av kjedekontroller i hvert trinn av databehandlingen, den såkalte "datakjeden" i litteraturen - kontroll av data fra kilden til det endelige brukspunktet. Disse typer kontroller implementeres oftest ved å skrive sjekkede SQL-spørringer. Det er klart at slike forespørsler bør være så lette som mulig og kontrollere individuelle datakvaliteter (tabell-metadata, tomme linjer, NULL-er, feil i syntaks - andre attributter som kreves for kontroll).
Ved regresjonstesting, som bruker ferdige (uforanderlige, litt utskiftbare) datasett, kan autotestkoden lagre ferdige maler for å kontrollere data for samsvar med kvalitet (beskrivelser av forventede tabellmetadata; radeksempelobjekter som kan valgt tilfeldig under testen osv.).
Under testing må du også skrive ETL-testprosesser ved å bruke rammeverk som Apache Airflow, eller til og med et svart-boks-sky-verktøy , Og så videre. Denne omstendigheten tvinger testingeniøren til å fordype seg i prinsippene for drift av verktøyene ovenfor og enda mer effektivt både utføre funksjonell testing (for eksempel eksisterende ETL-prosesser på et prosjekt) og bruke dem til å sjekke data. Spesielt har Apache Airflow ferdige operatører for å jobbe med populære analytiske databaser, for eksempel . Det mest grunnleggende eksemplet på bruken er allerede skissert , så jeg skal ikke gjenta meg selv.
Bortsett fra ferdige løsninger er det ingen som forbyr deg å implementere dine egne teknikker og verktøy. Dette vil ikke bare være gunstig for prosjektet, men også for datakvalitetsingeniøren selv, som dermed vil forbedre sin tekniske horisont og kodeferdigheter.
Hvordan det fungerer på et ekte prosjekt
En god illustrasjon av de siste avsnittene om "datakjeden", ETL og allestedsnærværende kontroller er følgende prosess fra et av de virkelige prosjektene:
Her kommer forskjellige data (naturligvis utarbeidet av oss) inn i inngangs-"trakten" til systemet vårt: gyldig, ugyldig, blandet, etc., deretter filtreres de og havner i et mellomlager, deretter gjennomgår de igjen en rekke transformasjoner og plasseres i den endelige lagringen, hvorfra det i sin tur vil bli utført analyser, bygging av datamars og søk etter forretningsinnsikt. I et slikt system, uten å funksjonelt sjekke driften av ETL-prosesser, fokuserer vi på kvaliteten på data før og etter transformasjoner, samt på output til analyse.
For å oppsummere det ovenstående, uansett hvor jeg jobbet, var jeg overalt involvert i dataprosjekter som delte følgende funksjoner:
- Bare gjennom automatisering kan du teste noen tilfeller og oppnå en utgivelsessyklus som er akseptabel for virksomheten.
- En tester på et slikt prosjekt er et av de mest respekterte medlemmene av teamet, siden det gir store fordeler for hver av deltakerne (akselerasjon av testing, gode data fra dataforskeren, identifisering av defekter i de tidlige stadiene).
- Det spiller ingen rolle om du jobber med din egen maskinvare eller i skyene - alle ressurser er abstrahert til en klynge som Hortonworks, Cloudera, Mesos, Kubernetes, etc.
- Prosjekter er bygget på en mikrotjenestetilnærming, distribuert og parallell databehandling dominerer.
Jeg vil merke meg at når en testing utfører testing innen datakvalitet, flytter en testspesialist sitt faglige fokus til koden til produktet og verktøyene som brukes.
Karakteristiske trekk ved testing av datakvalitet
I tillegg, for meg selv, har jeg identifisert følgende (jeg tar umiddelbart forbehold om at de er VELDIG generaliserte og utelukkende subjektive) karakteristiske trekk ved testing i Data (Big Data) prosjekter (systemer) og andre områder:
Nyttige lenker
- Teori: .
- EPAM
- Anbefalt materiale for en nybegynner datakvalitetsingeniør:
- Gratis kurs om Stepik: .
- Kurs om LinkedIn-læring: .
- artikler:
- ;
- ;
- ;
- Video:
- ;
- ;
Konklusjon
Datakvalitet er en veldig ung lovende retning, å være en del av det betyr å være en del av en startup. Når du først er i Data Quality, vil du bli fordypet i et stort antall moderne, etterspurte teknologier, men viktigst av alt vil det åpne seg enorme muligheter for deg til å generere og implementere ideene dine. Du vil være i stand til å bruke tilnærmingen til kontinuerlig forbedring ikke bare på prosjektet, men også for deg selv, og kontinuerlig utvikle deg som spesialist.
Kilde: www.habr.com