Velký a malý tester dat: trendy, teorie, můj příběh

Ahoj všichni, jmenuji se Alexander a jsem inženýr kvality dat, který kontroluje kvalitu dat. Tento článek bude hovořit o tom, jak jsem k tomu přišel a proč v roce 2020 byla tato oblast testování na hřebeni vlny.

Velký a malý tester dat: trendy, teorie, můj příběh

globální trend

Dnešní svět zažívá další technologickou revoluci, jejímž jedním aspektem je využívání nashromážděných dat všemi druhy společností k propagaci vlastního setrvačníku prodeje, zisků a PR. Zdá se, že přítomnost dobrých (kvalitních) dat a také šikovné mozky, které na nich dokážou vydělat (správně zpracovat, vizualizovat, postavit modely strojového učení atd.), se dnes pro mnohé staly klíčem k úspěchu. Jestliže před 15-20 lety se velké firmy zabývaly především intenzivní prací s akumulací dat a monetizací, dnes je to úděl téměř všech příčetných lidí.

V tomto ohledu se před několika lety všechny portály věnované hledání práce po celém světě začaly zaplňovat volnými místy pro Data Scientists, protože si každý byl jistý, že po najmutí takového specialisty bude možné vybudovat supermodel strojového učení. , předvídat budoucnost a provést pro společnost „kvantový skok“. Postupem času si lidé uvědomili, že tento přístup téměř nikdy nikde nefunguje, protože ne všechna data, která spadají do rukou takových specialistů, jsou vhodná pro tréninkové modely.

A začaly požadavky Data Scientists: „Nakupme další data od těch a těch...“, „Nemáme dostatek dat...“, „Potřebujeme ještě nějaká data, nejlépe kvalitní...“ . Na základě těchto požadavků se začaly budovat četné interakce mezi společnostmi, které vlastní ten či onen soubor dat. To samozřejmě vyžadovalo technickou organizaci tohoto procesu – připojení ke zdroji dat, jeho stažení, kontrola plného načtení atd. Počet takových procesů začal narůstat a dnes máme obrovskou potřebu jiného druhu specialisté - Data Quality engineers - ti, kteří by sledovali tok dat v systému (data pipeline), kvalitu dat na vstupu a výstupu a vyvozovali závěry o jejich dostatečnosti, integritě a dalších vlastnostech.

Trend pro inženýry Data Quality k nám přišel z USA, kde uprostřed zuřící éry kapitalismu není nikdo připraven prohrát bitvu o data. Níže uvádím snímky obrazovky ze dvou nejoblíbenějších stránek pro hledání práce v USA: www.monster.com и www.dice.com — který zobrazuje údaje k 17. březnu 2020 o počtu přijatých zaslaných volných pracovních míst pomocí klíčových slov: Data Quality a Data Scientist.

www.monster.com

Data Scientists – 21416 volných pracovních míst
Kvalita dat – 41104 volných pracovních míst

Velký a malý tester dat: trendy, teorie, můj příběh
Velký a malý tester dat: trendy, teorie, můj příběh

www.dice.com

Data Scientists – 404 volných míst
Data Quality – 2020 volná místa

Velký a malý tester dat: trendy, teorie, můj příběh
Velký a malý tester dat: trendy, teorie, můj příběh

Je zřejmé, že tyto profese si v žádném případě nekonkurují. Screenshoty jsem chtěl jen ilustrovat současnou situaci na trhu práce z hlediska požadavků na inženýry Data Quality, kterých je nyní potřeba mnohem více než Data Scientists.

V červnu 2019 EPAM v reakci na potřeby moderního IT trhu oddělil Data Quality do samostatné praxe. Inženýři kvality dat v rámci své každodenní práce spravují data, kontrolují jejich chování v nových podmínkách a systémech, sledují relevanci dat, jejich dostatečnost a relevanci. Díky tomu všemu v praktickém smyslu věnují inženýři kvality dat klasickému funkčnímu testování opravdu málo času, VUT v Brně to velmi závisí na projektu (uvedu příklad níže).

Povinnosti inženýra kvality dat se neomezují pouze na rutinní manuální/automatické kontroly „nul, počtů a součtů“ v databázových tabulkách, ale vyžadují hluboké porozumění obchodním potřebám zákazníka a v souladu s tím schopnost transformovat dostupná data do užitečné obchodní informace.

Teorie kvality dat

Velký a malý tester dat: trendy, teorie, můj příběh

Abychom si lépe představili roli takového inženýra, pojďme zjistit, co je kvalita dat teoreticky.

Kvalita dat — jedna z fází správy dat (celý svět, který vám necháme prostudovat na vlastní pěst) a odpovídá za analýzu dat podle následujících kritérií:

Velký a malý tester dat: trendy, teorie, můj příběh
Myslím, že není potřeba každý z bodů dešifrovat (teoreticky se jim říká „datové dimenze“), na obrázku jsou celkem dobře popsány. Samotný proces testování však neznamená striktní kopírování těchto funkcí do testovacích případů a jejich kontrolu. V Data Quality, stejně jako v každém jiném typu testování, je nutné v první řadě vycházet z požadavků na kvalitu dat dohodnutých s účastníky projektu, kteří přijímají obchodní rozhodnutí.

V závislosti na projektu Kvalita dat může technik vykonávat různé funkce: od běžného testera automatizace s povrchním hodnocením kvality dat až po osobu, která provádí hluboké profilování dat podle výše uvedených kritérií.

Velmi podrobný popis správy dat, kvality dat a souvisejících procesů je dobře popsán v knize s názvem "DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition". Tuto knihu vřele doporučuji jako úvod do tohoto tématu (odkaz na ni najdete na konci článku).

Můj příběh

V IT průmyslu jsem se vypracoval z Junior testera v produktových společnostech na Lead Data Quality Engineer ve společnosti EPAM. Asi po dvou letech práce jako tester jsem byl pevně přesvědčen, že jsem provedl naprosto všechny typy testování: regresní, funkční, zátěžové, stabilní, bezpečnostní, uživatelské rozhraní atd. – a vyzkoušel jsem velké množství testovacích nástrojů, pracoval současně ve třech programovacích jazycích: Java, Scala, Python.

Když se ohlédnu zpět, chápu, proč byl můj soubor dovedností tak rozmanitý – podílel jsem se na projektech založených na datech, velkých i malých. To mě přivedlo do světa mnoha nástrojů a příležitostí k růstu.

Chcete-li ocenit rozmanitost nástrojů a příležitostí k získání nových znalostí a dovedností, stačí se podívat na obrázek níže, který ukazuje ty nejoblíbenější ve světě „Data & AI“.

Velký a malý tester dat: trendy, teorie, můj příběh
Tento druh ilustrace sestavuje každoročně jeden ze slavných venture kapitalistů Matt Turck, který pochází z vývoje softwaru. Tady odkaz na jeho blog a společnost rizikového kapitálu, kde působí jako společník.

Profesně jsem rostl obzvlášť rychle, když jsem byl jediným testerem na projektu, nebo alespoň na začátku projektu. Právě v takové chvíli musíte být zodpovědní za celý proces testování a nemáte možnost ustoupit, pouze vpřed. Zpočátku to bylo děsivé, ale nyní jsou mi všechny výhody takového testu zřejmé:

  • Začnete komunikovat s celým týmem jako nikdy předtím, protože neexistuje žádný proxy pro komunikaci: ani manažer testu, ani ostatní testeři.
  • Ponoření do projektu se neuvěřitelně prohloubí a vy máte informace o všech složkách, jak obecně, tak podrobně.
  • Vývojáři se na vás nedívají jako na „toho chlápka z testování, který neví, co dělá“, ale spíše jako na rovnocenného člověka, který díky svým automatickým testům a předvídání chyb, které se objeví v konkrétní komponentě, přináší neuvěřitelné výhody pro tým. produkt.
  • V důsledku toho jste efektivnější, kvalifikovanější a žádanější.

Jak projekt rostl, ve 100 % případů jsem se stal mentorem pro nové testery, učil je a předával jim znalosti, které jsem se sám naučil. Zároveň jsem v závislosti na projektu ne vždy dostával od vedení specialisty na autotest na nejvyšší úrovni a bylo potřeba je buď zaškolit v automatizaci (pro zájemce), nebo vytvořit nástroje pro použití v každodenních činnostech (nástroje pro generování dat a jejich načítání do systému, nástroj pro provádění zátěžového testování/testování stability „rychle“ atd.).

Příklad konkrétního projektu

Bohužel z důvodu mlčenlivosti nemohu podrobně mluvit o projektech, na kterých jsem pracoval, ale uvedu příklady typických úkolů Data Quality Engineer na jednom z projektů.

Podstatou projektu je implementace platformy pro přípravu dat pro trénování modelů strojového učení na jejím základě. Zákazníkem byla velká farmaceutická společnost z USA. Technicky to byl klastr Kubernetes, stoupá k AWS EC2 instance, s několika mikroslužbami a základním Open Source projektem EPAM - Legie, přizpůsobený potřebám konkrétního zákazníka (nyní se projekt přerodil do odahu). ETL procesy byly organizovány pomocí proudění vzduchu apache a přesunul data z Salesforce zákaznických systémů v AWS S3 Kbelíky. Dále byl na platformu nasazen Docker obraz modelu strojového učení, který byl trénován na čerstvých datech a pomocí rozhraní REST API vytvářel předpovědi, které byly pro firmu zajímavé a řešily konkrétní problémy.

Vizuálně vše vypadalo nějak takto:

Velký a malý tester dat: trendy, teorie, můj příběh
Na tomto projektu bylo mnoho funkčních testů a vzhledem k rychlosti vývoje funkcí a potřebě udržet tempo cyklu vydání (dvoutýdenní sprinty), bylo nutné okamžitě přemýšlet o automatizaci testování nejkritičtějších komponent systém. Většina samotné platformy založené na Kubernetes byla pokryta autotesty implementovanými v Robot Framework + Python, ale bylo potřeba je také podporovat a rozšiřovat. Kromě toho bylo pro pohodlí zákazníka vytvořeno grafické uživatelské rozhraní pro správu modelů strojového učení nasazených do clusteru a také možnost určit, kam a kam je třeba přenést data pro trénování modelů. Tento rozsáhlý doplněk znamenal rozšíření automatizovaného funkčního testování, které bylo většinou prováděno prostřednictvím volání REST API a malého počtu end-2-end UI testů. Kolem rovníku všeho toho pohybu se k nám připojil ruční tester, který odvedl skvělou práci s akceptačním testováním verzí produktů a komunikací se zákazníkem ohledně přijetí dalšího vydání. Navíc jsme díky příchodu nového specialisty mohli zdokumentovat naši práci a přidat několik velmi důležitých ručních kontrol, které bylo obtížné ihned automatizovat.

A nakonec, poté, co jsme dosáhli stability z platformy a nad ní doplňku GUI, jsme začali budovat ETL potrubí pomocí Apache Airflow DAG. Automatizovaná kontrola kvality dat byla prováděna sepsáním speciálních Airflow DAG, které kontrolovaly data na základě výsledků ETL procesu. V rámci tohoto projektu jsme měli štěstí a zákazník nám umožnil přístup k anonymizovaným datovým sadám, na kterých jsme testovali. Kontrolovali jsme řádek po řádku, zda jsou v souladu s typy, přítomnost poškozených dat, celkový počet záznamů před a po, porovnání transformací provedených procesem ETL pro agregaci, změny názvů sloupců a další věci. Tyto kontroly byly navíc škálovány na různé zdroje dat, například kromě SalesForce také na MySQL.

Finální kontroly kvality dat byly prováděny již na úrovni S3, kde byly uloženy a připraveny k použití pro trénování modelů strojového učení. Pro získání dat z konečného souboru CSV umístěného v S3 Bucket a jeho ověření byl kód napsán pomocí klienti boto3.

Ze strany zákazníka byl také požadavek uložit část dat do jednoho S3 Bucketu a část do druhého. To také vyžadovalo sepsání dodatečných kontrol pro kontrolu spolehlivosti takového třídění.

Zobecněné zkušenosti z jiných projektů

Příklad nejobecnějšího seznamu činností inženýra kvality dat:

  • Připravte testovací data (platná neplatná velká malá) pomocí automatického nástroje.
  • Nahrajte připravenou datovou sadu do původního zdroje a zkontrolujte, zda je připravena k použití.
  • Spusťte procesy ETL pro zpracování sady dat ze zdrojového úložiště do konečného nebo meziúložiště pomocí určité sady nastavení (pokud je to možné, nastavte konfigurovatelné parametry pro úlohu ETL).
  • Ověřte kvalitu dat zpracovávaných procesem ETL a jejich soulad s obchodními požadavky.

Hlavní pozornost kontrol by přitom měla být zaměřena nejen na to, že datový tok v systému v zásadě fungoval a došel do konce (což je součástí funkčního testování), ale především na kontrolu a validaci dat. pro splnění očekávaných požadavků, identifikaci anomálií a další věci.

Nástroje

Jednou z technik takové kontroly dat může být organizace řetězových kontrol v každé fázi zpracování dat, v literatuře tzv. „datový řetězec“ – kontrola dat od zdroje až po konečné použití. Tyto typy kontrol se nejčastěji realizují psaním kontrolních SQL dotazů. Je jasné, že takové dotazy by měly být co nejvíce odlehčené a kontrolovat kvalitu jednotlivých dat (metadata tabulek, prázdné řádky, NULL, Chyby v syntaxi – další atributy potřebné pro kontrolu).

V případě regresního testování, které využívá hotové (neměnné, mírně proměnlivé) datové sady, může autotestovací kód ukládat hotové šablony pro kontrolu shody dat s kvalitou (popisy očekávaných metadat tabulek; řádkové ukázkové objekty, které lze náhodně vybrané během testu atd.).

Během testování musíte také napsat testovací procesy ETL pomocí rámců, jako je Apache Airflow, Apache Spark nebo dokonce nástroj typu cloud typu black-box Dataprep GCP, Datový tok GCP A tak dále. Tato okolnost nutí testovacího inženýra ponořit se do principů fungování výše uvedených nástrojů a ještě efektivněji jak provádět funkční testování (například existující ETL procesy na projektu), tak je využívat ke kontrole dat. Apache Airflow má připravené operátory například pro práci s oblíbenými analytickými databázemi GCP BigQuery. Nejzákladnější příklad jeho použití již byl nastíněn zde, tak se nebudu opakovat.

Kromě hotových řešení vám nikdo nezakazuje implementovat vlastní techniky a nástroje. To bude přínosné nejen pro projekt, ale i pro samotného Data Quality Engineera, který si tím zlepší své technické obzory a kódovací dovednosti.

Jak to funguje na reálném projektu

Dobrým příkladem posledních odstavců o „datovém řetězci“, ETL a všudypřítomných kontrolách je následující proces z jednoho ze skutečných projektů:

Velký a malý tester dat: trendy, teorie, můj příběh

Zde vstupují do vstupního „trychtýře“ našeho systému různá data (samozřejmě námi připravená): platná, neplatná, smíšená atd., poté jsou filtrována a končí v meziúložišti, poté opět procházejí řadou transformací a jsou umístěny v konečném úložišti, ze kterého budou následně prováděny analýzy, budování datových tržišť a vyhledávání obchodních poznatků. V takovém systému, aniž bychom funkčně kontrolovali chod ETL procesů, se zaměřujeme na kvalitu dat před a po transformacích a také na výstup do analytiky.

Abych to shrnul výše, bez ohledu na místa, kde jsem pracoval, všude, kde jsem byl zapojen do datových projektů, které sdílely následující funkce:

  • Pouze prostřednictvím automatizace můžete otestovat některé případy a dosáhnout cyklu uvolňování přijatelného pro obchod.
  • Tester na takovém projektu je jedním z nejrespektovanějších členů týmu, protože přináší velké výhody každému z účastníků (urychlení testování, dobrá data od Data Scientist, identifikace defektů v raných fázích).
  • Nezáleží na tom, zda pracujete na vlastním hardwaru nebo v cloudu – všechny zdroje jsou abstrahovány do clusteru, jako je Hortonworks, Cloudera, Mesos, Kubernetes atd.
  • Projekty jsou postaveny na mikroservisním přístupu, převládají distribuované a paralelní výpočty.

Rád bych poznamenal, že při testování v oblasti kvality dat přesouvá testovací specialista své profesní zaměření na kód produktu a používané nástroje.

Charakteristické rysy testování kvality dat

Kromě toho jsem pro sebe identifikoval následující (okamžitě udělám výhradu, že jde o VELMI zobecněné a výhradně subjektivní) charakteristické rysy testování v datových (Big Data) projektech (systémech) a dalších oblastech:

Velký a malý tester dat: trendy, teorie, můj příběh

Užitečné odkazy

  1. Teorie: DAMA-DMBOK: Správa dat Základní znalosti: 2. vydání.
  2. Tréninkové centrum EPAM 
  3. Doporučené materiály pro začínajícího inženýra kvality dat:
    1. Bezplatný kurz na Stepiku: Úvod do databází
    2. Kurz na LinkedIn Learning: Základy datové vědy: datové inženýrství.
    3. Články:
    4. Video:

Závěr

Kvalita dat je velmi mladý perspektivní směr, jehož součástí znamená být součástí startupu. Jakmile se ocitnete v Data Quality, ponoříte se do velkého množství moderních, žádaných technologií, ale hlavně se vám otevřou obrovské možnosti generování a realizace vašich nápadů. Přístup neustálého zlepšování budete moci využít nejen na projektu, ale i pro sebe, neustále se rozvíjet jako specialista.

Zdroj: www.habr.com

Přidat komentář