Ahojte všetci, volám sa Alexander a som inžinier kvality údajov, ktorý kontroluje kvalitu údajov. Tento článok bude hovoriť o tom, ako som k tomu prišiel a prečo bola táto oblasť testovania v roku 2020 na vrchole vlny.
Globálny trend
Dnešný svet zažíva ďalšiu technologickú revolúciu, ktorej jedným z aspektov je využívanie nahromadených dát všetkými druhmi spoločností na podporu vlastného zotrvačníka predaja, ziskov a PR. Zdá sa, že prítomnosť dobrých (kvalitných) dát, ako aj šikovné mozgy, ktoré na nich dokážu zarobiť (správne spracovať, vizualizovať, postaviť modely strojového učenia atď.), sa dnes pre mnohých stali kľúčom k úspechu. Ak sa pred 15 – 20 rokmi veľké firmy venovali najmä intenzívnej práci s akumuláciou dát a monetizáciou, dnes je to údel takmer všetkých príčetných ľudí.
V tomto ohľade sa pred niekoľkými rokmi všetky portály venované hľadaniu práce na celom svete začali zapĺňať voľnými pracovnými miestami pre Data Scientists, pretože každý si bol istý, že po najatí takého špecialistu by bolo možné vybudovať supermodel strojového učenia. , predpovedať budúcnosť a vykonať pre spoločnosť „kvantový skok“. Postupom času si ľudia uvedomili, že tento prístup takmer nikdy nikde nefunguje, pretože nie všetky údaje, ktoré spadajú do rúk takýchto špecialistov, sú vhodné na tréningové modely.
A začali sa požiadavky od Data Scientists: “Poďme kúpiť viac dát od tých a tých...”, “Nemáme dostatok dát...”, “Potrebujeme ešte nejaké dáta, najlepšie kvalitné...” . Na základe týchto požiadaviek sa začali budovať početné interakcie medzi spoločnosťami, ktoré vlastnia ten či onen súbor údajov. Prirodzene si to vyžadovalo technickú organizáciu tohto procesu – pripojenie k zdroju dát, jeho stiahnutie, kontrola, či je celý načítaný atď. Počet takýchto procesov začal rásť a dnes máme obrovskú potrebu iného druhu špecialisti - Data Quality engineers - tí, ktorí by monitorovali tok dát v systéme (data pipeline), kvalitu dát na vstupe a výstupe a vyvodzovali závery o ich dostatočnosti, integrite a ďalších vlastnostiach.
Trend pre inžinierov dátovej kvality k nám prišiel z USA, kde uprostred zúriacej éry kapitalizmu nie je nikto pripravený prehrať boj o dáta. Nižšie uvádzam snímky obrazovky z dvoch najpopulárnejších stránok na hľadanie zamestnania v USA: и — ktorý zobrazuje údaje k 17 o počte prijatých voľných pracovných miest pomocou kľúčových slov: Data Quality a Data Scientist.
Data Scientists – 21416 voľných pracovných miest
Kvalita dát – 41104 voľných pracovných miest
Data Scientists – 404 voľných pracovných miest
Kvalita dát – 2020 voľných pracovných miest
Je zrejmé, že tieto profesie si v žiadnom prípade nekonkurujú. Screenshotmi som chcel len ilustrovať aktuálnu situáciu na trhu práce z hľadiska požiadaviek na Data Quality inžinierov, ktorých je teraz potrebných oveľa viac ako Data Scientists.
V júni 2019 EPAM v reakcii na potreby moderného IT trhu oddelil Data Quality do samostatnej praxe. Inžinieri dátovej kvality v rámci svojej každodennej práce spravujú dáta, kontrolujú ich správanie v nových podmienkach a systémoch, sledujú relevantnosť dát, ich dostatočnosť a relevantnosť. Vďaka tomu všetkému v praktickom zmysle inžinieri kvality údajov venujú klasickému funkčnému testovaniu naozaj málo času, VUT v Brne to veľmi závisí od projektu (uvediem príklad nižšie).
Zodpovednosti inžiniera kvality údajov sa neobmedzujú len na rutinné manuálne/automatické kontroly „nulových hodnôt, počtov a súčtov“ v databázových tabuľkách, ale vyžadujú si hlboké pochopenie obchodných potrieb zákazníka, a teda schopnosť transformovať dostupné údaje na užitočné obchodné informácie.
Teória kvality údajov
Aby sme si lepšie predstavili úlohu takéhoto inžiniera, poďme zistiť, čo je kvalita údajov teoreticky.
Kvalita údajov — jedna z etáp správy údajov (celý svet, ktorý vám necháme, aby ste si ho preštudovali sami) a zodpovedá za analýzu údajov podľa nasledujúcich kritérií:
Myslím, že nie je potrebné dešifrovať každý z bodov (teoreticky sa nazývajú „dátové dimenzie“), sú celkom dobre popísané na obrázku. Samotný proces testovania však neznamená striktné kopírovanie týchto funkcií do testovacích prípadov a ich kontrolu. V Data Quality, ako aj v každom inom type testovania, je potrebné v prvom rade stavať na požiadavkách na kvalitu dát dohodnutých s účastníkmi projektu, ktorí robia obchodné rozhodnutia.
V závislosti od projektu Kvalita údajov môže inžinier vykonávať rôzne funkcie: od bežného testera automatizácie s povrchným hodnotením kvality údajov až po osobu, ktorá vykonáva hlboké profilovanie údajov podľa vyššie uvedených kritérií.
Veľmi podrobný popis Data Management, Data Quality a súvisiacich procesov je dobre popísaný v knihe tzv "DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition". Túto knihu vrelo odporúčam ako úvod do tejto témy (odkaz na ňu nájdete na konci článku).
Môj príbeh
V IT priemysle som sa vypracoval z Junior testera v produktových spoločnostiach na vedúceho Data Quality Engineer v EPAM. Asi po dvoch rokoch práce ako tester som bol pevne presvedčený, že som urobil úplne všetky typy testovania: regresné, funkčné, stresové, stabilné, bezpečnostné, UI atď. – a vyskúšal som veľké množstvo testovacích nástrojov, pracoval súčasne v troch programovacích jazykoch: Java, Scala, Python.
Keď sa obzriem späť, chápem, prečo bol súbor mojich zručností taký rôznorodý – podieľal som sa na projektoch založených na údajoch, veľkých aj malých. To ma priviedlo do sveta mnohých nástrojov a príležitostí na rast.
Ak chcete oceniť rozmanitosť nástrojov a príležitostí na získanie nových vedomostí a zručností, stačí sa pozrieť na obrázok nižšie, ktorý zobrazuje tie najpopulárnejšie vo svete „Data & AI“.
Tento druh ilustrácie každoročne zostavuje jeden zo slávnych venture kapitalistov Matt Turck, ktorý pochádza z vývoja softvéru. Tu na jeho blog a , kde pôsobí ako spoločník.
Profesne som rástol obzvlášť rýchlo, keď som bol na projekte jediný tester, alebo aspoň na začiatku projektu. Práve v takom momente musíte byť zodpovedný za celý proces testovania a nemáte možnosť ustúpiť, iba vpred. Spočiatku to bolo desivé, ale teraz sú mi zrejmé všetky výhody takéhoto testu:
- Začnete komunikovať s celým tímom ako nikdy predtým, pretože neexistuje žiadny proxy pre komunikáciu: ani manažér testu, ani kolegovia testeri.
- Ponorenie do projektu sa stane neuveriteľne hlbokým a máte informácie o všetkých komponentoch, a to ako vo všeobecnosti, tak aj v detailoch.
- Vývojári sa na vás nepozerajú ako na „toho chlapíka z testovania, ktorý nevie, čo robí“, ale skôr ako na rovnocenného partnera, ktorý vďaka svojim automatickým testom a očakávaniu chýb, ktoré sa objavia v špecifickom komponente, prináša neuveriteľné výhody pre tím. produktu.
- Vďaka tomu ste efektívnejší, kvalifikovanejší a žiadanejší.
Ako projekt rástol, v 100% prípadov som sa stal mentorom pre nových testerov, učil som ich a odovzdával im vedomosti, ktoré som sa sám naučil. Zároveň som v závislosti od projektu nie vždy dostával od manažmentu odborníkov na autotestovanie na najvyššej úrovni a bolo potrebné ich buď zaškoliť v automatizácii (pre záujemcov), alebo vytvoriť nástroje na použitie v každodenných činnostiach (nástroje na generovanie dát a ich načítanie do systému, nástroj na „rýchle“ vykonávanie záťažového testovania/testovania stability a pod.).
Príklad konkrétneho projektu
Žiaľ, kvôli povinnosti mlčanlivosti nemôžem podrobne hovoriť o projektoch, na ktorých som pracoval, ale uvediem príklady typických úloh Data Quality Engineer na jednom z projektov.
Podstatou projektu je implementácia platformy na prípravu dát pre trénovanie modelov strojového učenia na jej základe. Zákazníkom bola veľká farmaceutická spoločnosť z USA. Technicky to bol klaster , stúpajúci k inštancie s niekoľkými mikroslužbami a základným projektom Open Source EPAM - , prispôsobené potrebám konkrétneho zákazníka (teraz sa projekt prerodil do ). ETL procesy boli organizované pomocou a presunul údaje z zákaznícke systémy v Vedrá. Ďalej bol na platformu nasadený Docker obraz modelu strojového učenia, ktorý bol trénovaný na čerstvých údajoch a pomocou rozhrania REST API vytváral predpovede, ktoré boli pre podnik zaujímavé a riešili konkrétne problémy.
Vizuálne všetko vyzeralo asi takto:
Na tomto projekte sa uskutočnilo množstvo funkčných testov a vzhľadom na rýchlosť vývoja funkcií a potrebu udržať tempo cyklu vydania (dvojtýždňové sprinty), bolo potrebné okamžite premýšľať o automatizácii testovania najdôležitejších komponentov. systém. Väčšinu samotnej platformy založenej na Kubernetes pokrývali autotesty implementované v + Python, ale bolo potrebné ich aj podporovať a rozširovať. Okrem toho bolo pre pohodlie zákazníka vytvorené GUI na správu modelov strojového učenia nasadených do klastra, ako aj možnosť špecifikovať, kde a kam je potrebné preniesť údaje na trénovanie modelov. Tento rozsiahly doplnok znamenal rozšírenie automatizovaného funkčného testovania, ktoré sa väčšinou uskutočňovalo prostredníctvom volaní REST API a malého počtu end-2-end testov používateľského rozhrania. Okolo rovníka celého tohto pohybu sa k nám pripojil manuálny tester, ktorý odviedol skvelú prácu s akceptačným testovaním verzií produktov a komunikáciou so zákazníkom ohľadom akceptácie ďalšieho vydania. Navyše, vďaka príchodu nového špecialistu sme mohli zdokumentovať našu prácu a pridať niekoľko veľmi dôležitých ručných kontrol, ktoré bolo ťažké hneď automatizovať.
A nakoniec, keď sme dosiahli stabilitu z platformy a doplnku GUI nad ňou, začali sme budovať ETL potrubia pomocou Apache Airflow DAG. Automatizovaná kontrola kvality dát bola vykonaná napísaním špeciálnych Airflow DAG, ktoré kontrolovali dáta na základe výsledkov ETL procesu. V rámci tohto projektu sme mali šťastie a zákazník nám umožnil prístup k súborom anonymizovaných dát, na ktorých sme testovali. Kontrolovali sme údaje riadok po riadku, či sú v súlade s typmi, prítomnosť poškodených údajov, celkový počet záznamov pred a po, porovnanie transformácií vykonaných procesom ETL na agregáciu, zmena názvov stĺpcov a ďalšie veci. Okrem toho boli tieto kontroly škálované na rôzne zdroje údajov, napríklad okrem SalesForce aj na MySQL.
Finálne kontroly kvality dát boli vykonané už na úrovni S3, kde boli uložené a pripravené na použitie pre trénovanie modelov strojového učenia. Na získanie údajov z konečného súboru CSV umiestneného v segmente S3 a jeho overenie bol kód napísaný pomocou .
Taktiež bola požiadavka zo strany zákazníka uložiť časť dát do jedného S3 Bucketu a časť do druhého. To si vyžiadalo aj vypísanie dodatočných kontrol na kontrolu spoľahlivosti takéhoto triedenia.
Zovšeobecnené skúsenosti z iných projektov
Príklad najvšeobecnejšieho zoznamu činností inžiniera kvality údajov:
- Pripravte testovacie údaje (platné neplatné veľké malé) prostredníctvom automatického nástroja.
- Nahrajte pripravený súbor údajov do pôvodného zdroja a skontrolujte, či je pripravený na použitie.
- Spustite procesy ETL na spracovanie množiny údajov zo zdrojového úložiska do konečného alebo prechodného úložiska pomocou určitej sady nastavení (ak je to možné, nastavte konfigurovateľné parametre pre úlohu ETL).
- Overte kvalitu údajov spracovaných procesom ETL a ich súlad s obchodnými požiadavkami.
Zároveň by sa kontrola mala sústrediť nielen na to, či dátový tok v systéme v zásade fungoval a dospel do konca (čo je súčasťou funkčného testovania), ale predovšetkým na kontrolu a validáciu dát. za splnenie očakávaných požiadaviek, identifikáciu anomálií a iné veci.
Nástroje
Jednou z techník takejto kontroly údajov môže byť organizácia reťazových kontrol v každej fáze spracovania údajov, v literatúre takzvaný „data chain“ – kontrola údajov od zdroja až po konečné použitie. Tieto typy kontrol sa najčastejšie realizujú písaním kontrolných SQL dotazov. Je jasné, že takéto dopyty by mali byť čo najjednoduchšie a kontrolovať kvalitu jednotlivých údajov (metaúdaje tabuliek, prázdne riadky, NULL, Chyby v syntaxi – ďalšie atribúty potrebné na kontrolu).
V prípade regresného testovania, pri ktorom sa používajú hotové (nemeniteľné, mierne meniteľné) súbory údajov, kód autotestu môže uchovávať hotové šablóny na kontrolu zhody údajov s kvalitou (popisy očakávaných metadát tabuliek; riadkové vzorové objekty, ktoré môžu byť náhodne vybrané počas testu atď.).
Počas testovania musíte tiež napísať testovacie procesy ETL pomocou rámcov, ako je Apache Airflow, alebo dokonca nástroj typu cloud typu black-box , A tak ďalej. Táto okolnosť núti testovacieho inžiniera, aby sa ponoril do princípov fungovania vyššie uvedených nástrojov a ešte efektívnejšie vykonal funkčné testovanie (napríklad existujúce ETL procesy na projekte) a použil ich na kontrolu údajov. Najmä Apache Airflow má pripravených operátorov napríklad na prácu s populárnymi analytickými databázami . Najzákladnejší príklad jeho použitia už bol načrtnutý , tak sa nebudem opakovať.
Okrem hotových riešení vám nikto nezakazuje implementovať vlastné techniky a nástroje. To bude prínosom nielen pre projekt, ale aj pre samotného Data Quality Engineera, ktorý si tak zlepší svoje technické obzory a kódovacie schopnosti.
Ako to funguje na reálnom projekte
Dobrým príkladom posledných odsekov o „dátovom reťazci“, ETL a všadeprítomných kontrolách je nasledujúci proces z jedného zo skutočných projektov:
Tu do vstupného „lievika“ nášho systému vstupujú rôzne údaje (samozrejme, nami pripravené): platné, neplatné, zmiešané atď., Potom sa filtrujú a skončia v medzisklade, potom opäť prechádzajú sériou transformácií. a sú umiestnené v konečnom úložisku, z ktorého sa budú následne vykonávať analýzy, budovanie dátových obchodov a vyhľadávanie obchodných informácií. V takomto systéme sa bez funkčnej kontroly fungovania ETL procesov zameriavame na kvalitu dát pred a po transformáciách, ako aj na výstup do analytiky.
Aby som zhrnul vyššie uvedené, bez ohľadu na miesta, kde som pracoval, všade, kde som bol zapojený do dátových projektov, ktoré zdieľali nasledujúce funkcie:
- Len pomocou automatizácie môžete otestovať niektoré prípady a dosiahnuť cyklus uvoľnenia prijateľný pre podnikanie.
- Tester na takomto projekte je jedným z najrešpektovanejších členov tímu, keďže prináša veľké výhody každému z účastníkov (zrýchlenie testovania, dobré dáta od Data Scientist, identifikácia defektov v počiatočných fázach).
- Nezáleží na tom, či pracujete na vlastnom hardvéri alebo v cloude – všetky zdroje sú abstrahované do klastra, ako je Hortonworks, Cloudera, Mesos, Kubernetes atď.
- Projekty sú postavené na mikroservisnom prístupe, prevládajú distribuované a paralelné výpočty.
Chcel by som poznamenať, že pri testovaní v oblasti kvality dát špecialista na testovanie presúva svoje profesionálne zameranie na kód produktu a používané nástroje.
Charakteristické črty testovania kvality údajov
Okrem toho som pre seba identifikoval nasledujúce (okamžite urobím výhradu, že ide o VEĽMI zovšeobecnené a výlučne subjektívne) charakteristické črty testovania v dátových (veľkých dátach) projektoch (systémoch) a iných oblastiach:
Užitočné odkazy
- teória: .
- EPAM
- Odporúčané materiály pre začínajúceho inžiniera kvality údajov:
- Bezplatný kurz na Stepiku: .
- Kurz vzdelávania na LinkedIn: .
- články:
- ;
- ;
- ;
- Video:
- ;
- ;
Záver
Kvalita údajov je veľmi mladý perspektívny smer, ktorého súčasťou znamená byť súčasťou startupu. Keď sa ocitnete v Data Quality, budete ponorení do veľkého množstva moderných, žiadaných technológií, ale čo je najdôležitejšie, otvoria sa vám obrovské možnosti na generovanie a realizáciu vašich nápadov. Prístup neustáleho zlepšovania budete môcť využiť nielen na projekte, ale aj pre seba, neustále sa rozvíjajúc ako špecialista.
Zdroj: hab.com