Sveiki visi, mano vardas Aleksandras, aš esu duomenų kokybės inžinierius, tikrinantis duomenų kokybę. Šiame straipsnyje bus kalbama apie tai, kaip aš iki to priėjau ir kodėl 2020 m. ši bandymų sritis buvo ant bangos viršūnės.
Pasaulinė tendencija
Šiandieninis pasaulis išgyvena dar vieną technologinę revoliuciją, kurios vienas aspektų yra įvairių įmonių sukauptų duomenų naudojimas reklamuojant savo pardavimų, pelno ir viešųjų ryšių smagratį. Atrodo, kad gerų (kokybiškų) duomenų buvimas, taip pat kvalifikuotos smegenys, galinčios iš jų uždirbti (teisingai apdoroti, vizualizuoti, kurti mašininio mokymosi modelius ir pan.), šiandien daugeliui tapo raktu į sėkmę. Jei prieš 15-20 metų didelės įmonės daugiausia užsiėmė intensyviu duomenų kaupimu ir monetizavimu, tai šiandien tai yra beveik visų sveiko proto žmonių reikalas.
Šiuo atžvilgiu prieš keletą metų visi portalai, skirti darbo paieškai visame pasaulyje, buvo užpildyti laisvomis duomenų mokslininkų darbo vietomis, nes visi buvo tikri, kad pasamdžius tokį specialistą bus galima sukurti mašininio mokymosi supermodelį. , nuspėti ateitį ir atlikti „kvantinį šuolį“ įmonei. Laikui bėgant žmonės suprato, kad šis metodas beveik niekur neveikia, nes ne visi duomenys, kurie patenka į tokių specialistų rankas, yra tinkami mokymo modeliams.
Ir prasidėjo „Data Scientists“ užklausos: „Nupirkim daugiau duomenų iš tų ir tų...“, „Neturime pakankamai duomenų...“, „Mums reikia daugiau duomenų, geriausia kokybiškų...“ . Remiantis šiais prašymais, buvo pradėta kurti daug sąveikų tarp įmonių, kurioms priklauso vienas ar kitas duomenų rinkinys. Natūralu, kad tam reikėjo techninio šio proceso organizavimo – prisijungimo prie duomenų šaltinio, atsisiuntimo, patikrinimo, ar jis pilnai įkeltas ir pan. Tokių procesų skaičius pradėjo augti, o šiandien mums labai reikia kitokio pobūdžio specialistai – Duomenų kokybės inžinieriai – tie, kurie stebėtų duomenų srautą sistemoje (duomenų vamzdynuose), įvesties ir išvesties duomenų kokybę ir darytų išvadas apie jų pakankamumą, vientisumą ir kitas charakteristikas.
Duomenų kokybės inžinierių tendencija pas mus atkeliavo iš JAV, kur siautėjančios kapitalizmo eros įkarštyje niekas nėra pasiruošęs pralaimėti mūšio dėl duomenų. Žemiau pateikiau ekrano kopijas iš dviejų populiariausių darbo paieškos svetainių JAV: и – kuriame rodomi 17 m. kovo 2020 d. duomenys apie gautų paskelbtų laisvų darbo vietų skaičių naudojant raktinius žodžius: duomenų kokybė ir duomenų mokslininkas.
„Data Scientists“ – 21416 laisvų darbo vietų
Duomenų kokybė – 41104 laisvos darbo vietos
„Data Scientists“ – 404 laisvos darbo vietos
Duomenų kokybė – 2020 m
Akivaizdu, kad šios profesijos jokiu būdu nekonkuruoja tarpusavyje. Ekrano kopijomis tiesiog norėjau iliustruoti esamą situaciją darbo rinkoje, kalbant apie užklausas duomenų kokybės inžinieriams, kurių dabar reikia daug daugiau nei duomenų mokslininkams.
2019 metų birželį EPAM, reaguodama į šiuolaikinės IT rinkos poreikius, Duomenų kokybę išskyrė į atskirą praktiką. Duomenų kokybės inžinieriai savo kasdieniniame darbe tvarko duomenis, tikrina jų elgseną naujomis sąlygomis ir sistemose, stebi duomenų aktualumą, pakankamumą ir aktualumą. Praktine prasme duomenų kokybės inžinieriai skiria mažai laiko klasikiniams funkciniams bandymams, BET tai labai priklauso nuo projekto (toliau pateiksiu pavyzdį).
Duomenų kokybės inžinieriaus pareigos neapsiriboja tik įprastiniu rankiniu/automatiniu duomenų bazių lentelių „nulių, skaičių ir sumų“ patikrinimu, bet reikalauja gilaus kliento verslo poreikių supratimo ir, atitinkamai, gebėjimo paversti turimus duomenis į naudingos verslo informacijos.
Duomenų kokybės teorija
Norėdami geriau įsivaizduoti tokio inžinieriaus vaidmenį, išsiaiškinkime, kas teoriškai yra duomenų kokybė.
Duomenų kokybė — vienas iš Duomenų valdymo etapų (visas pasaulis, kurį paliksime jums studijuoti patiems) ir atsakingas už duomenų analizę pagal šiuos kriterijus:
Manau, kad nereikia iššifruoti kiekvieno iš taškų (teoriškai jie vadinami „duomenų matmenimis“), jie gana gerai aprašyti paveikslėlyje. Tačiau pats testavimo procesas nereiškia griežto šių funkcijų kopijavimo į bandomuosius atvejus ir jų tikrinimo. Atliekant duomenų kokybę, kaip ir atliekant bet kokį kitą testavimą, visų pirma būtina remtis duomenų kokybės reikalavimais, dėl kurių susitarta su verslo sprendimus priimančiais projekto dalyviais.
Priklausomai nuo Duomenų kokybės projekto, inžinierius gali atlikti įvairias funkcijas: nuo paprasto automatizavimo testerio su paviršutinišku duomenų kokybės įvertinimu, iki asmens, kuris atlieka gilų duomenų profiliavimą pagal aukščiau nurodytus kriterijus.
Labai išsamus duomenų valdymo, duomenų kokybės ir susijusių procesų aprašymas yra gerai aprašytas knygoje pavadinimu „DAMA-DMBOK: Duomenų valdymo žinių rinkinys: 2-asis leidimas“. Labai rekomenduoju šią knygą kaip įvadą į šią temą (nuorodą į ją rasite straipsnio pabaigoje).
Mano istorija
IT pramonėje iš jaunesniojo testuotojo produktų įmonėse pasiekiau pagrindinį duomenų kokybės inžinierių EPAM. Po maždaug dvejų metų darbo testuotoju buvau tvirtai įsitikinęs, kad atlikau absoliučiai visus testus: regresijos, funkcinius, stresinius, stabilumo, saugumo, vartotojo sąsajos ir kt. – ir išbandžiau daugybę testavimo įrankių, turėdamas vienu metu dirbo trimis programavimo kalbomis: Java, Scala, Python.
Žvelgdamas atgal suprantu, kodėl mano įgūdžių rinkinys buvo toks įvairus – dalyvavau dideliuose ir mažuose duomenimis paremtuose projektuose. Tai mane atvedė į pasaulį, kuriame yra daugybė augimo priemonių ir galimybių.
Norėdami įvertinti įrankių ir galimybių įgyti naujų žinių ir įgūdžių įvairovę, tiesiog pažiūrėkite į žemiau esantį paveikslėlį, kuriame pavaizduoti patys populiariausi „Data & AI“ pasaulyje.
Tokią iliustraciją kasmet parengia vienas garsių rizikos kapitalistų Mattas Turckas, kuris yra programinės įrangos kūrimo srityje. Čia į savo dienoraštį ir , kur dirba partneriu.
Profesionaliai ypač greitai augau, kai buvau vienintelis projekto testuotojas arba bent jau projekto pradžioje. Būtent tokiu momentu tu turi būti atsakingas už visą testavimo procesą ir neturi galimybės trauktis, tik pirmyn. Iš pradžių buvo baisu, bet dabar visi tokio testo pranašumai man akivaizdūs:
- Pradedate bendrauti su visa komanda kaip niekad anksčiau, nes bendravimui nėra įgaliotojo: nei testo vadovas, nei kiti bandytojai.
- Panirimas į projektą tampa neįtikėtinai gilus, o jūs turite informacijos apie visus komponentus, tiek bendrą, tiek išsamią.
- Kūrėjai nežiūri į jus kaip į „į testavimo žmogų, kuris nežino, ką daro“, o kaip į lygiavertį, kuris komandai duoda neįtikėtiną naudą atlikdamas automatinius testus ir tikėdamasis, kad tam tikrame programos komponente atsiras klaidų. produktas.
- Dėl to esate efektyvesnis, labiau kvalifikuotas ir paklausesnis.
Vykstant projektui, 100% atvejų tapau naujų testuotojų mentoriumi, mokydavau juos ir perteikdavau žinias, kurias išmokau pats. Tuo pačiu, priklausomai nuo projekto, ne visada iš vadovybės sulaukdavau aukščiausio lygio auto testavimo specialistų ir iškildavo poreikis arba juos apmokyti automatikos srityje (besidomintiems), arba sukurti įrankius, skirtus naudoti kasdienėje veikloje (įrankiai). duomenims generuoti ir įkelti į sistemą, įrankis apkrovos testavimui/stabilumo testavimui „greitai“ atlikti ir pan.).
Konkretaus projekto pavyzdys
Deja, dėl neatskleidimo įsipareigojimų negaliu išsamiai kalbėti apie projektus, prie kurių dirbau, bet pateiksiu tipinių duomenų kokybės inžinieriaus užduočių viename iš projektų pavyzdžius.
Projekto esmė – jos pagrindu įdiegti duomenų rengimo mašininio mokymosi modeliams platformą. Klientas buvo didelė farmacijos įmonė iš JAV. Techniškai tai buvo klasteris , kyla iki egzemplioriai su keliomis mikropaslaugomis ir pagrindiniu EPAM atvirojo kodo projektu - , pritaikytas konkretaus kliento poreikiams (dabar projektas atgimė į ). ETL procesai buvo organizuojami naudojant ir perkėlė duomenis iš klientų sistemose Kibirai. Tada platformoje buvo įdiegtas mašininio mokymosi modelio „Docker“ vaizdas, kuris buvo apmokytas naudojant naujus duomenis ir, naudojant REST API sąsają, pateikė prognozes, kurios buvo įdomios verslui ir išsprendė konkrečias problemas.
Vizualiai viskas atrodė maždaug taip:
Šiame projekte buvo atlikta daugybė funkcinių testų, todėl, atsižvelgiant į funkcijų kūrimo greitį ir poreikį išlaikyti išleidimo ciklo tempą (dviejų savaičių sprintai), reikėjo nedelsiant pagalvoti apie svarbiausių komponentų testavimo automatizavimą. sistema. Dauguma pačios Kubernetes pagrindu veikiančios platformos buvo padengtos automatiniais testais, įdiegtais + Python, bet taip pat reikėjo juos palaikyti ir plėsti. Be to, kliento patogumui buvo sukurta GUI, skirta valdyti mašininio mokymosi modelius, įdiegtus klasteryje, taip pat galimybę nurodyti, kur ir kur reikia perduoti duomenis, kad būtų galima apmokyti modelius. Šis platus papildymas lėmė automatinio funkcinio testavimo išplėtimą, kuris dažniausiai buvo atliktas naudojant REST API iškvietimus ir nedidelį skaičių 2 galo UI testų. Prie viso šio judėjimo pusiaujo prie mūsų prisijungė rankinis testeris, kuris puikiai atliko gaminio versijų priėmimo testavimą ir bendravo su klientu dėl kitos laidos priėmimo. Be to, dėl naujo specialisto atvykimo galėjome dokumentuoti savo darbą ir pridėti keletą labai svarbių rankinių patikrinimų, kuriuos buvo sunku iš karto automatizuoti.
Galiausiai, kai pasiekėme stabilumą iš platformos ir GUI priedo, pradėjome kurti ETL vamzdynus naudodami Apache Airflow DAG. Automatizuotas duomenų kokybės patikrinimas buvo atliktas parašant specialius Airflow DAG, kurie tikrino duomenis pagal ETL proceso rezultatus. Vykdydami šį projektą mums pasisekė ir klientas suteikė prieigą prie anoniminių duomenų rinkinių, kuriuos išbandėme. Tikrinome duomenų eilutę, ar jie atitinka tipus, ar nėra sugadintų duomenų, bendras įrašų skaičius prieš ir po, ETL proceso atliktų transformacijų palyginimas agregacijai, stulpelių pavadinimų keitimas ir kiti dalykai. Be to, šie patikrinimai buvo pritaikyti skirtingiems duomenų šaltiniams, pavyzdžiui, ne tik „SalesForce“, bet ir „MySQL“.
Galutiniai duomenų kokybės patikrinimai buvo atlikti jau S3 lygiu, kur jie buvo saugomi ir buvo paruošti naudoti mokant mašininio mokymosi modelius. Norint gauti duomenis iš galutinio CSV failo, esančio S3 segmente, ir jį patvirtinti, kodas buvo parašytas naudojant .
Taip pat klientas reikalavo dalį duomenų saugoti viename S3 segmente, o dalį – kitame. Tam taip pat reikėjo rašyti papildomus patikrinimus, kad būtų patikrintas tokio rūšiavimo patikimumas.
Apibendrinta patirtis iš kitų projektų
Bendriausio duomenų kokybės inžinieriaus veiklos sąrašo pavyzdys:
- Paruoškite bandymo duomenis (galioja netinkamas didelis mažas) naudodami automatinį įrankį.
- Įkelkite paruoštą duomenų rinkinį į pirminį šaltinį ir patikrinkite, ar jis paruoštas naudoti.
- Paleiskite ETL procesus, kad apdorotumėte duomenų rinkinį iš šaltinio saugyklos į galutinę ar tarpinę saugyklą, naudodami tam tikrą nustatymų rinkinį (jei įmanoma, nustatykite konfigūruojamus ETL užduoties parametrus).
- Patikrinkite ETL proceso tvarkomų duomenų kokybę ir atitiktį verslo reikalavimams.
Tuo pačiu metu pagrindinis patikrinimų dėmesys turėtų būti skiriamas ne tik tam faktui, kad duomenų srautas sistemoje iš esmės veikė ir baigtas (tai yra funkcinio testavimo dalis), bet daugiausia dėmesio skiriant duomenų tikrinimui ir patvirtinimui. laukiamų reikalavimų laikymasis, nukrypimų nustatymas ir kiti dalykai.
Įrankiai
Vienas iš tokių duomenų kontrolės metodų gali būti grandinės patikrų organizavimas kiekviename duomenų apdorojimo etape, literatūroje vadinamoji „duomenų grandinė“ – duomenų kontrolė nuo šaltinio iki galutinio panaudojimo. Šios patikros rūšys dažniausiai įgyvendinamos rašant tikrinimo SQL užklausas. Aišku, kad tokios užklausos turėtų būti kuo lengvesnės ir tikrinti atskirų duomenų kokybę (lentelių metaduomenis, tuščias eilutes, NULL, Sintaksės klaidos – kiti tikrinimui reikalingi atributai).
Regresinio testavimo atveju, kai naudojami paruošti (nekeičiami, šiek tiek keičiami) duomenų rinkiniai, automatinio testo kodas gali saugoti paruoštus šablonus, skirtus duomenų kokybei patikrinti (tikėtinų lentelės metaduomenų aprašymai; eilučių pavyzdžių objektai, kuriuos galima atsitiktinai parinkta testo metu ir pan.).
Be to, testavimo metu turite parašyti ETL testavimo procesus naudodami tokias sistemas kaip Apache Airflow, ar net juodosios dėžės debesies tipo įrankis , Ir taip toliau. Ši aplinkybė verčia testuotoją pasinerti į minėtų įrankių veikimo principus ir dar efektyviau tiek atlikti funkcinius testavimus (pavyzdžiui, esamus projekto ETL procesus), tiek naudoti juos duomenims tikrinti. Visų pirma, „Apache Airflow“ turi paruoštus operatorius, skirtus darbui su populiariomis analitinėmis duomenų bazėmis, pvz. . Pats paprasčiausias jo naudojimo pavyzdys jau buvo aprašytas , todėl nesikartosiu.
Be jau paruoštų sprendimų, niekas nedraudžia diegti savo technikos ir priemonių. Tai bus naudinga ne tik projektui, bet ir pačiam duomenų kokybės inžinieriui, kuris taip pagerins savo techninį akiratį ir kodavimo įgūdžius.
Kaip tai veikia realiame projekte
Gera paskutinių pastraipų apie „duomenų grandinę“, ETL ir visur esančius patikrinimus iliustracija yra toks vieno iš tikrų projektų procesas:
Čia įvairūs duomenys (natūralu, mūsų paruošti) patenka į mūsų sistemos įvesties „piltuvėlį“: galiojantis, negaliojantis, mišrus ir pan., tada jie filtruojami ir patenka į tarpinę saugyklą, tada vėl patiria daugybę transformacijų. ir dedami į galutinę saugyklą , iš kurios savo ruožtu bus atliekama analizė, duomenų rinkų kūrimas ir verslo įžvalgų paieška. Tokioje sistemoje, funkciškai netikrindami ETL procesų veikimo, orientuojamės į duomenų kokybę prieš ir po transformacijų, taip pat į išvestį į analizę.
Apibendrinant tai, kas išdėstyta pirmiau, nepaisant to, kur dirbau, visur dalyvavau duomenų projektuose, kuriems būdingos šios funkcijos:
- Tik automatizuodami galite išbandyti kai kuriuos atvejus ir pasiekti verslui priimtiną išleidimo ciklą.
- Tokio projekto testuotojas yra vienas iš labiausiai gerbiamų komandos narių, nes kiekvienam dalyviui tai duoda didžiulę naudą (testavimo pagreitis, geri Data Scientist duomenys, defektų nustatymas ankstyvosiose stadijose).
- Nesvarbu, ar dirbate su savo aparatine įranga, ar debesyse – visi ištekliai yra suskirstyti į grupę, pvz., „Hortonworks“, „Cloudera“, „Mesos“, „Kubernetes“ ir kt.
- Projektai paremti mikro paslaugų metodu, vyrauja paskirstytasis ir lygiagretusis skaičiavimas.
Noriu pastebėti, kad atliekant bandymus duomenų kokybės srityje testavimo specialistas savo profesinį dėmesį perkelia į gaminio kodą ir naudojamas priemones.
Skiriamieji duomenų kokybės testavimo bruožai
Be to, aš nustatiau šiuos (iš karto padarysiu išlygą, kad tai yra LABAI apibendrinti ir išskirtinai subjektyvūs) išskirtinius duomenų (Big Data) projektų (sistemų) ir kitų sričių testavimo bruožus:
Naudingos nuorodos
- Teorija: .
- EPAM
- Pradedančiam duomenų kokybės inžinieriui rekomenduojamos medžiagos:
- Nemokamas Stepiko kursas: .
- Kursas apie LinkedIn mokymąsi: .
- Straipsniai:
- ;
- ;
- ;
- Vaizdo įrašas:
- ;
- ;
išvada
Duomenų kokybė yra labai jauna perspektyvi kryptis, kurios dalimi būti reiškia būti startuolio dalimi. Patekę į Duomenų kokybę, pasinersite į daugybę modernių, paklausių technologijų, bet svarbiausia, kad jums atsivers didžiulės galimybės generuoti ir įgyvendinti savo idėjas. Nuolatinio tobulėjimo metodą galėsite taikyti ne tik projekte, bet ir sau, nuolat tobulėdami kaip specialistas.
Šaltinis: www.habr.com