Hei kaikki, nimeni on Alexander, ja olen tietojen laatuinsinööri, joka tarkistaa tietojen laadun. Tämä artikkeli kertoo siitä, miten päädyin tähän ja miksi vuonna 2020 tämä testausalue oli aallon harjalla.
globaali trendi
Nykymaailmassa on meneillään toinen teknologinen vallankumous, jonka yhtenä osapuolena on kaikenlaisten yritysten keräämän tiedon käyttö edistääkseen omia myynti-, voitto- ja PR-vauhtipyöräään. Näyttää siltä, että hyvän (laadukkaan) datan läsnäolo sekä ammattitaitoiset aivot, jotka pystyvät tienaamaan sillä (oikein prosessoimaan, visualisoimaan, rakentamaan koneoppimismalleja jne.), ovat nykyään monelle avain menestykseen. Jos 15-20 vuotta sitten suuret yritykset olivat pääosin mukana intensiivisessä työssä tiedon keruun ja rahallistamisen parissa, niin nykyään tämä on lähes kaikkien järkevien ihmisten osa.
Tältä osin useita vuosia sitten kaikki työnhakuun omistetut portaalit ympäri maailmaa alkoivat täyttyä avoimista datatieteilijöiden työpaikoista, koska kaikki olivat varmoja, että tällaisen asiantuntijan palkkaamisen jälkeen olisi mahdollista rakentaa koneoppimisen supermalli. , ennustaa tulevaisuutta ja tehdä "kvanttihyppy" yritykselle. Ajan myötä ihmiset ymmärsivät, että tämä lähestymistapa ei toimi melkein koskaan missään, koska kaikki tällaisten asiantuntijoiden käsiin tulevat tiedot eivät sovellu koulutusmalleihin.
Ja Data Scientistien pyynnöt alkoivat: "Ostetaan lisää dataa näistä ja noista...", "Meillä ei ole tarpeeksi dataa...", "Tarvitsemme lisää dataa, mieluiten korkealaatuista..." . Näiden pyyntöjen perusteella alettiin rakentaa lukuisia vuorovaikutuksia yritysten välillä, jotka omistavat yhtä tai toista dataa. Luonnollisesti tämä vaati tämän prosessin teknistä organisointia - yhteyden muodostamista tietolähteeseen, lataamista, tarkistamista, että se oli ladattu kokonaan jne. Tällaisten prosessien määrä alkoi kasvaa, ja nykyään meillä on valtava tarve toisenlaiselle asiantuntijat - Tietojen laatuinsinöörit - ne, jotka valvoisivat tiedonkulkua järjestelmässä (dataputket), tiedon laatua syötössä ja lähdössä ja tekevät johtopäätöksiä niiden riittävyydestä, eheydestä ja muista ominaisuuksista.
Tietojen laatuinsinöörien trendi tuli meille Yhdysvalloista, missä raivoavan kapitalismin aikakauden keskellä kukaan ei ole valmis häviämään taistelua datasta. Alla olen toimittanut kuvakaappauksia kahdesta Yhdysvaltain suosituimmasta työnhakusivustosta: и — joka näyttää tiedot 17. maaliskuuta 2020 saatujen julkaistujen avoimien työpaikkojen määrästä käyttämällä avainsanoja: Data Quality ja Data Scientist.
Data Scientists – 21416 avointa työpaikkaa
Tietojen laatu – 41104 avointa työpaikkaa
Data Scientists – 404 avointa työpaikkaa
Tietojen laatu – 2020 avoimet työpaikat
On selvää, että nämä ammatit eivät millään tavalla kilpaile keskenään. Kuvakaappauksilla halusin vain havainnollistaa nykyistä työmarkkinoiden tilannetta tiedonlaadun insinöörien pyynnöillä, joita tarvitaan nyt paljon enemmän kuin Data Scientists.
Kesäkuussa 2019 EPAM erotti nykyaikaisten IT-markkinoiden tarpeisiin Data Qualityn omaksi käytännöksi. Tietojen laatuinsinöörit päivittäisessä työssään hallitsevat dataa, tarkistavat sen käyttäytymistä uusissa olosuhteissa ja järjestelmissä, valvovat tiedon relevanssia, riittävyyttä ja relevanssia. Käytännössä tiedonlaadun insinöörit omistavat todella vähän aikaa klassiseen toiminnalliseen testaukseen. MUTTA tämä riippuu suuresti projektista (annan esimerkin alla).
Tietojen laatuinsinöörin vastuut eivät rajoitu vain rutiininomaisiin manuaalisiin/automaattisiin tarkistuksiin tietokantataulukoiden "nolla-, counts and summas" varalta, vaan se edellyttää syvällistä ymmärrystä asiakkaan liiketoiminnan tarpeista ja vastaavasti kykyä muuntaa saatavilla olevat tiedot hyödyllistä yritystietoa.
Tietojen laatuteoria
Jotta voisimme paremmin kuvitella tällaisen insinöörin roolin, selvitetään, mitä Data Quality on teoriassa.
Tietojen laatu — yksi tiedonhallinnan vaiheista (koko maailma, jonka jätämme sinun tutkittavaksi yksin) ja vastaa tietojen analysoinnista seuraavien kriteerien mukaan:
Mielestäni jokaista pistettä ei tarvitse tulkita (teoriassa niitä kutsutaan "datadimensioiksi"), ne on kuvattu kuvassa melko hyvin. Mutta itse testausprosessi ei tarkoita näiden ominaisuuksien tarkkaa kopioimista testitapauksiin ja niiden tarkistamista. Datan laadussa, kuten kaikissa muissakin testauksissa, on ensisijaisesti noudatettava niitä datan laatuvaatimuksia, joista on sovittu liiketoimintapäätöksiä tekevien projektiin osallistujien kanssa.
Tietojen laatuprojektista riippuen insinööri voi suorittaa erilaisia tehtäviä: tavallisesta automaatiotestaajasta, joka arvioi pinnallisesti tiedon laadun, aina tietojen syväprofilointiin edellä mainittujen kriteerien mukaan.
Erittäin yksityiskohtainen kuvaus tiedonhallinnasta, tiedon laadusta ja niihin liittyvistä prosesseista on kuvattu hyvin kirjassa nimeltä "DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition". Suosittelen lämpimästi tätä kirjaa johdannona tähän aiheeseen (löydät linkin siihen artikkelin lopusta).
Tarinaani
IT-alalla työskentelin tuoteyritysten nuoresta testaajasta johtavaksi tietojen laatuinsinööriksi EPAM:ssa. Noin kahden vuoden testaajan työskentelyn jälkeen minulla oli vahva vakaumus, että olin tehnyt ehdottomasti kaikenlaisia testejä: regressio-, toiminnallisia, stressitestejä, vakautta, turvallisuutta, käyttöliittymää jne. - ja kokeillut useita testaustyökaluja, joilla oli työskenteli samanaikaisesti kolmella ohjelmointikielellä: Java, Scala, Python.
Jälkeenpäin katsoessani ymmärrän, miksi taitovalikoimani oli niin monipuolinen – olin mukana tietopohjaisissa projekteissa, isoissa ja pienissä. Tämä toi minut monien työkalujen ja kasvumahdollisuuksien maailmaan.
Arvostaaksesi erilaisia työkaluja ja mahdollisuuksia hankkia uusia tietoja ja taitoja, katso vain alla olevaa kuvaa, joka näyttää suosituimmat "Data & AI" -maailmassa.
Tämän kaltaisen havainnoinnin laatii vuosittain yksi kuuluisista pääomasijoittajista Matt Turck, joka on kotoisin ohjelmistokehityksestä. Tässä blogiinsa ja , jossa hän työskentelee kumppanina.
Kasvoin ammatillisesti erityisen nopeasti, kun olin projektin ainoa testaaja tai ainakin projektin alussa. Juuri tällä hetkellä sinun täytyy olla vastuussa koko testausprosessista, eikä sinulla ole mahdollisuutta vetäytyä, vain eteenpäin. Aluksi se oli pelottavaa, mutta nyt kaikki tällaisen testin edut ovat minulle ilmeisiä:
- Alat kommunikoida koko tiimin kanssa ennennäkemättömällä tavalla, koska kommunikaatiolle ei ole välityspalvelinta: ei testipäällikköä eikä muita testaajia.
- Uppoutuminen projektiin tulee uskomattoman syväksi, ja sinulla on tietoa kaikista komponenteista sekä yleisesti että yksityiskohtaisesti.
- Kehittäjät eivät pidä sinua "testaajana, joka ei tiedä mitä tekee", vaan pikemminkin tasavertaisena, joka tuottaa uskomattomia etuja tiimille automatisoiduilla testeillä ja ennakoimalla, että tietyssä komponentissa esiintyy virheitä. tuote.
- Tämän seurauksena olet tehokkaampi, pätevämpi ja kysytympi.
Projektin kasvaessa minusta tuli 100 %:ssa uusien testaajien mentori, joka opetti heitä ja välitin itse oppimaani tietoa. Samaan aikaan en projektista riippuen aina saanut johdolta korkeimman tason autotestauksen asiantuntijoita ja oli tarve joko kouluttaa heitä automaatioon (kiinnostuneille) tai luoda työkaluja jokapäiväiseen toimintaan (työkalut). tietojen luomiseen ja lataamiseen järjestelmään, työkalu kuormitustestauksen/vakaustestauksen suorittamiseen "nopeasti" jne.).
Esimerkki tietystä projektista
Valitettavasti salassapitovelvoitteiden vuoksi en voi kertoa tarkemmin projekteista, joissa työskentelin, mutta annan esimerkkejä tyypillisistä Data Quality Engineerin tehtävistä yhdessä projektista.
Projektin ydin on toteuttaa alusta, jolla valmistetaan dataa siihen perustuvien koneoppimismallien koulutukseen. Asiakas oli suuri lääkeyhtiö Yhdysvalloista. Teknisesti se oli klusteri , nousee instanssit, joissa on useita mikropalveluita ja taustalla oleva EPAM:n Open Source -projekti - , mukautettu tietyn asiakkaan tarpeisiin (nyt projekti on syntynyt uudelleen ). ETL-prosessit organisoitiin käyttäen ja siirsi tiedot kohteesta asiakasjärjestelmät sisään Kauhat. Seuraavaksi alustalle otettiin käyttöön Docker-kuva koneoppimismallista, joka koulutettiin tuoreeseen dataan ja REST API -rajapinnan avulla tuotti liiketoimintaa kiinnostavia ennusteita ja ratkaisi tiettyjä ongelmia.
Visuaalisesti kaikki näytti tältä:
Tässä projektissa oli runsaasti toiminnallista testausta, ja ottaen huomioon ominaisuuksien kehityksen nopeus ja tarve ylläpitää julkaisusyklin vauhtia (kahden viikon sprintit), oli välttämätöntä heti miettiä kriittisimpien komponenttien testauksen automatisointia. systeemi. Suurin osa itse Kubernetes-pohjaisesta alustasta oli vuonna toteutettujen automaattisten testien piirissä + Python, mutta niitä oli myös tarpeen tukea ja laajentaa. Lisäksi asiakkaan mukavuuden vuoksi luotiin graafinen käyttöliittymä, joka hallitsee klusteriin käyttöön otettuja koneoppimismalleja sekä mahdollisuus määrittää, minne ja minne tietoja on siirrettävä mallien koulutukseen. Tämä laaja lisäys sisälsi automaattisen toiminnallisen testauksen laajentamisen, joka tehtiin enimmäkseen REST API -kutsujen ja pienen määrän end-2-end UI-testien avulla. Kaiken tämän liikkeen päiväntasaajan ympärille liittyi meihin manuaalinen testaaja, joka teki erinomaista työtä tuoteversioiden hyväksyntätestauksessa ja yhteydenpidossa asiakkaan kanssa seuraavan julkaisun hyväksymisestä. Lisäksi uuden asiantuntijan tulon ansiosta pystyimme dokumentoimaan työmme ja lisäsimme useita erittäin tärkeitä manuaalisia tarkistuksia, joita oli vaikea heti automatisoida.
Ja lopuksi, kun saavutimme vakauden alustan ja sen GUI-lisäosan avulla, aloimme rakentaa ETL-putkistoja Apache Airflow DAG:ien avulla. Automaattinen tietojen laaduntarkistus tehtiin kirjoittamalla erityisiä Airflow DAG:ita, jotka tarkastivat tiedot ETL-prosessin tulosten perusteella. Osana tätä projektia meillä oli onnea ja asiakas antoi meille pääsyn anonymisoituihin tietokokonaisuuksiin, joita testasimme. Tarkistimme datan rivi riviltä tyyppien yhteensopivuuden, rikkinäisten tietojen esiintymisen, tietueiden kokonaismäärän ennen ja jälkeen, ETL-prosessin muunnosten vertailun aggregointia varten, sarakkeiden nimien muuttamisen ja muita asioita. Lisäksi nämä tarkistukset skaalattiin eri tietolähteisiin, esimerkiksi SalesForcen lisäksi myös MySQL:ään.
Lopulliset tiedon laadun tarkistukset tehtiin jo S3-tasolla, jonne ne tallennettiin ja olivat valmiita koneoppimismallien koulutukseen. Tietojen saamiseksi lopullisesta S3-säilön CSV-tiedostosta ja sen vahvistamiseksi koodi kirjoitettiin käyttämällä .
Asiakkaalta edellytettiin myös, että osa tiedoista säilytetään yhteen S3-ämpäriin ja osa toiseen. Tämä vaati myös lisätarkistuksia lajittelun luotettavuuden tarkistamiseksi.
Yleinen kokemus muista projekteista
Esimerkki tietojen laatuinsinöörin yleisimmästä luettelosta:
- Valmistele testitiedot (kelvollinen iso pieni) automaattisen työkalun avulla.
- Lataa valmis tietojoukko alkuperäiseen lähteeseen ja tarkista, että se on käyttövalmis.
- Käynnistä ETL-prosessit datajoukon käsittelemiseksi lähdemuistista lopulliseen tai välimuistiin käyttämällä tiettyä asetussarjaa (jos mahdollista, aseta määritettävissä olevat parametrit ETL-tehtävälle).
- Tarkista ETL-prosessin käsittelemien tietojen laatu ja liiketoiminnan vaatimustenmukaisuus.
Samanaikaisesti tarkistuksissa ei tulisi keskittyä pelkästään siihen, että järjestelmän tietovirta on periaatteessa toiminut ja päättynyt (joka on osa toiminnallista testausta), vaan lähinnä tietojen tarkistamiseen ja validointiin. odotettujen vaatimusten noudattaminen, poikkeamien tunnistaminen ja muut asiat.
Työkalut
Yksi tällaisen tietojen hallinnan tekniikoista voi olla ketjutarkistusten järjestäminen jokaisessa tietojenkäsittelyn vaiheessa, kirjallisuudessa niin kutsuttu "tietoketju" - tiedon hallinta lähteestä lopulliseen käyttöpisteeseen. Tämän tyyppiset tarkistukset toteutetaan useimmiten kirjoittamalla SQL-tarkistuskyselyitä. On selvää, että tällaisten kyselyiden tulee olla mahdollisimman kevyitä ja niiden tulee tarkistaa yksittäisten tietojen laatu (taulukon metatiedot, tyhjät rivit, NULL-arvot, syntaksivirheet - muut tarkistukseen vaadittavat attribuutit).
Jos kyseessä on regressiotestaus, jossa käytetään valmiita (muuttumattomia, hieman muuttuvia) tietojoukkoja, automaattinen testikoodi voi tallentaa valmiita malleja tietojen laadun tarkistamiseksi (odotettujen taulukon metatietojen kuvaukset; rivinäyteobjektit, jotka voidaan valittu satunnaisesti testin aikana jne. ).
Testauksen aikana sinun on myös kirjoitettava ETL-testiprosesseja käyttämällä kehyksiä, kuten Apache Airflow, tai jopa black-box-pilvityyppinen työkalu , Ja niin edelleen. Tämä seikka pakottaa testausinsinöörin uppoutumaan yllä olevien työkalujen toimintaperiaatteisiin ja vielä tehokkaammin sekä suorittamaan toiminnallisia testauksia (esimerkiksi projektin olemassa olevia ETL-prosesseja) että käyttämään niitä tietojen tarkistamiseen. Erityisesti Apache Airflowlla on valmiita operaattoreita työskennelläkseen esimerkiksi suosittujen analyyttisten tietokantojen kanssa . Perusesimerkki sen käytöstä on jo hahmoteltu , joten en toista itseäni.
Valmiiden ratkaisujen lisäksi kukaan ei kiellä toteuttamasta omia tekniikoita ja työkaluja. Tästä ei ole hyötyä vain projektille, vaan myös itse Data Quality Engineerille, joka parantaa siten teknistä näköalojaan ja koodaustaitojaan.
Kuinka se toimii todellisessa projektissa
Hyvä esimerkki viimeisistä kappaleista, jotka koskevat "tietoketjua", ETL:ää ja kaikkialla olevia tarkastuksia, on seuraava prosessi yhdestä todellisista projekteista:
Täällä järjestelmämme syöttösuppiloon saapuu erilaisia tietoja (luonnollisesti meidän valmistamia): kelvollinen, virheellinen, sekoitettu jne., sitten ne suodatetaan ja päätyvät välimuistiin, sitten ne käyvät läpi useita muunnoksia. ja sijoitetaan loppuvarastoon, josta puolestaan suoritetaan analytiikkaa, datamarssien rakentamista ja liiketoimintanäkemysten etsimistä. Tällaisessa järjestelmässä, ilman ETL-prosessien toiminnan toiminnallista tarkistamista, keskitymme datan laatuun ennen ja jälkeen muunnoksia sekä tulostukseen analytiikkaan.
Lyhyesti sanottuna, riippumatta paikoista, joissa olen työskennellyt, olin kaikkialla mukana dataprojekteissa, joissa oli seuraavat ominaisuudet:
- Vain automatisoinnin avulla voit testata joitain tapauksia ja saavuttaa yritykselle hyväksyttävän julkaisusyklin.
- Tällaisen projektin testaaja on yksi ryhmän arvostetuimmista jäsenistä, koska se tuo suuria etuja jokaiselle osallistujalle (testauksen nopeutuminen, hyvä data Data Scientistilta, vikojen tunnistaminen alkuvaiheessa).
- Sillä ei ole väliä, työskenteletkö omalla laitteistollasi vai pilvissä – kaikki resurssit on koottu klusteriin, kuten Hortonworks, Cloudera, Mesos, Kubernetes jne.
- Projektit rakentuvat mikropalvelulähestymistapalle, hajautettu ja rinnakkaislaskenta hallitsevat.
Haluan huomioida, että testattaessa Data Quality -alaa testausasiantuntija siirtää ammatillisen painopisteensä tuotteen koodiin ja käytettäviin työkaluihin.
Tiedonlaadun testauksen erityispiirteet
Lisäksi olen itselleni tunnistanut seuraavat (tehdän heti varauksen, että ne ovat ERITTÄIN yleistettyjä ja yksinomaan subjektiivisia) testauksen erityispiirteitä Data (Big Data) -projekteissa (järjestelmissä) ja muilla alueilla:
Hyödyllisiä linkkejä
- Teoria: .
- EPAM
- Suositeltavat materiaalit aloittelevalle tiedonlaatuinsinöörille:
- Ilmainen Stepik-kurssi: .
- LinkedIn Learning -kurssi: .
- Artikkelit:
- ;
- ;
- ;
- Video:
- ;
- ;
Johtopäätös
Tietojen laatu on hyvin nuori lupaava suunta, johon kuuluminen tarkoittaa startupissa olemista. Datan laadussa pääset uppoutumaan lukuisiin nykyaikaisiin, kysyttyihin teknologioihin, mutta mikä tärkeintä, sinulle avautuu valtavia mahdollisuuksia ideoiden luomiseen ja toteuttamiseen. Pystyt hyödyntämään jatkuvan parantamisen lähestymistapaa paitsi projektissa, myös itsellesi kehittyen jatkuvasti asiantuntijana.
Lähde: will.com