🥇 Тестер великих и малих података: трендови, теорија, моја прича

Здраво свима, моје име је Александар и ја сам инжењер квалитета података који проверава квалитет података. Овај чланак ће говорити о томе како сам дошао до овога и зашто је 2020. године ова област тестирања била на врхунцу таласа.

глобални тренд

Данашњи свет доживљава још једну технолошку револуцију, чији је један аспект коришћење акумулираних података од стране свих врста компанија за промовисање сопственог замајца продаје, профита и ПР-а. Чини се да су присуство добрих (квалитетних) података, као и вешти мозгови који од њих могу да зараде (исправно обрађују, визуелизују, праве моделе машинског учења итд.), данас многима постали кључ успеха. Ако су се пре 15-20 година велике компаније углавном бавиле интензивним радом на акумулацији података и монетизацији, данас је то судбина готово свих здравих људи.

С тим у вези, пре неколико година, сви портали посвећени тражењу посла широм света почели су да се попуњавају слободним радним местима за Дата Сциентистс, јер су сви били сигурни да ће, ангажујући таквог специјалисте, бити могуће изградити супермодел машинског учења , предвиде будућност и изврши „квантни скок“ за компанију. Временом су људи схватили да овај приступ готово никада нигде не функционише, јер нису сви подаци који падају у руке таквих стручњака погодни за моделе обуке.

И почели су захтеви Дата Сциентистс-а: „Хајде да купимо више података од ових и оних...“, „Немамо довољно података...“, „Треба нам још података, по могућству квалитетних...“ . На основу ових захтева почеле су да се граде бројне интеракције између компанија које поседују један или други скуп података. Наравно, то је захтевало техничку организацију овог процеса – повезивање са извором података, његово преузимање, проверу да ли је у потпуности учитан, итд. Број таквих процеса је почео да расте, а данас имамо огромну потребу за другом врстом специјалисти – Инжењери квалитета података – они који би пратили ток података у систему (дата пипелинес), квалитет података на улазу и излазу и извлачили закључке о њиховој довољности, интегритету и другим карактеристикама.

Тренд за инжењере квалитета података дошао нам је из САД, где, усред бесне ере капитализма, нико није спреман да изгуби битку за податке. У наставку сам дао снимке екрана са два од најпопуларнијих сајтова за тражење посла у САД: ввв.монстер.цом и ввв.дице.цом — који приказује податке са стањем на дан 17. марта 2020. о броју објављених слободних радних места примљених помоћу кључних речи: Дата Куалити и Дата Сциентист.

ввв.монстер.цом

Дата Сциентистс – 21416 слободних места
Квалитет података – 41104 слободних радних места

ввв.дице.цом

Дата Сциентистс – 404 слободна радна места
Квалитет података – слободна радна места 2020

Очигледно, ове професије се ни на који начин не такмиче једна са другом. Снимцима екрана сам само желео да илуструјем тренутну ситуацију на тржишту рада у смислу захтева за инжењере квалитета података, којих је сада потребно много више од Дата Сциентистс.

У јуну 2019. ЕПАМ је, одговарајући на потребе савременог ИТ тржишта, издвојио квалитет података у засебну праксу. Инжењери квалитета података у свакодневном раду управљају подацима, проверавају њихово понашање у новим условима и системима, прате релевантност података, њихову довољност и релевантност. Уз све ово, у практичном смислу, инжењери квалитета података заиста посвећују мало времена класичном функционалном тестирању, АЛИ ово у великој мери зависи од пројекта (навешћу пример у наставку).

Одговорности инжењера квалитета података нису ограничене само на рутинске ручне/аутоматске провере за „нулте, бројање и суме“ у табелама базе података, већ захтевају дубоко разумевање пословних потреба корисника и, сходно томе, способност трансформације доступних података у корисне пословне информације.

Теорија квалитета података

Да бисмо потпуније замислили улогу таквог инжењера, хајде да схватимо шта је квалитет података у теорији.

Квалитет података — једна од фаза управљања подацима (цео свет који ћемо вам оставити да сами проучавате) и одговоран је за анализу података према следећим критеријумима:

Мислим да нема потребе да дешифрујемо сваку од тачака (у теорији се зову „димензије података“), прилично су добро описане на слици. Али сам процес тестирања не подразумева стриктно копирање ових карактеристика у тест случајеве и њихову проверу. У квалитету података, као иу сваком другом типу тестирања, неопходно је, пре свега, градити на захтевима квалитета података договореним са учесницима пројекта који доносе пословне одлуке.

У зависности од пројекта квалитета података, инжењер може да обавља различите функције: од обичног тестера аутоматизације са површном проценом квалитета података, до особе која врши дубинско профилисање података према горе наведеним критеријумима.

Веома детаљан опис управљања подацима, квалитета података и сродних процеса добро је описан у књизи под називом „ДАМА-ДМБОК: Збор знања о управљању подацима: 2. издање“. Топло препоручујем ову књигу као увод у ову тему (линк до ње ћете наћи на крају чланка).

Моја прича

У ИТ индустрији, напредовао сам од млађег тестера у компанијама за производе до водећег инжењера квалитета података у ЕПАМ-у. После отприлике две године рада као тестер, имао сам чврсто уверење да сам урадио апсолутно све врсте тестирања: регресијско, функционално, стресно, стабилност, безбедност, корисничко сучеље, итд. – и испробао велики број алата за тестирање, имајући радио у исто време у три програмска језика: Јава, Сцала, Питхон.

Гледајући уназад, разумем зашто је мој скуп вештина био толико разнолик – био сам укључен у пројекте вођене подацима, велике и мале. То ме је довело у свет многих алата и могућности за раст.

Да бисте ценили разноврсност алата и могућности за стицање нових знања и вештина, само погледајте слику испод, која приказује најпопуларније у свету „Подаци и вештачка интелигенција“.

Овакву илустрацију сваке године саставља један од познатих ризичног капитала Мет Турк, који долази из развоја софтвера. Ево веза на свој блог и фирма ризичног капитала, где ради као партнер.

Професионално сам посебно брзо растао када сам био једини тестер на пројекту, или барем на почетку пројекта. У таквом тренутку морате бити одговорни за цео процес тестирања и немате прилику да се повучете, само напред. У почетку је било застрашујуће, али сада су ми све предности таквог теста очигледне:

Почињете да комуницирате са целим тимом као никада раније, јер нема проксија за комуникацију: ни тест менаџера ни колега тестера.
Урањање у пројекат постаје невероватно дубоко, а ви имате информације о свим компонентама, уопштено и детаљно.
Програмери не гледају на вас као на „оног типа из тестирања који не зна шта ради“, већ пре као на равног који производи невероватне предности за тим својим аутоматизованим тестовима и предвиђањем да се грешке појављују у одређеној компоненти производ.
Као резултат тога, ви сте ефикаснији, квалификованији и траженији.

Како је пројекат растао, у 100% случајева сам постајао ментор новим тестерима, подучавао их и преносио знање које сам сам научио. У исто време, у зависности од пројекта, нисам увек добијао највиши ниво специјалиста за аутотестирање од менаџмента и постојала је потреба да их обучим за аутоматизацију (за заинтересоване) или да креирам алате за коришћење у свакодневним активностима (алати за генерисање података и њихово учитавање у систем, алат за „брзо” извођење тестирања оптерећења/тестирања стабилности итд.).

Пример конкретног пројекта

Нажалост, због обавезе неоткривања података, не могу детаљније да говорим о пројектима на којима сам радио, али ћу навести примере типичних задатака инжењера квалитета података на једном од пројеката.

Суштина пројекта је имплементација платформе за припрему података за обуку модела машинског учења заснованих на њој. Купац је била велика фармацеутска компанија из САД. Технички, то је био кластер Кубернетес, дижући се до АВС ЕЦ2 инстанце, са неколико микросервиса и основним пројектом отвореног кода ЕПАМ-а - Легија, прилагођен потребама конкретног купца (сада је пројекат поново рођен у одаху). ЕТЛ процеси су организовани коришћењем Апацхе Аирфлов и премештене податке из СалесФорце системи купаца у АВС С3 Буцкетс. Затим је Доцкер слика модела машинског учења распоређена на платформу, која је обучена на свежим подацима и, користећи РЕСТ АПИ интерфејс, произвела је предвиђања која су била од интереса за посао и решавала специфичне проблеме.

Визуелно, све је изгледало отприлике овако:

На овом пројекту је било доста функционалног тестирања, а с обзиром на брзину развоја карактеристика и потребу да се одржи темпо циклуса издавања (двонедељни спринтови), било је неопходно одмах размишљати о аутоматизовању тестирања најкритичнијих компоненти систем. Већина саме платформе засноване на Кубернетесу била је покривена аутотестовима имплементираним у Робот Фрамеворк + Питхон, али их је такође било потребно подржати и проширити. Поред тога, за практичност корисника, креиран је ГУИ за управљање моделима машинског учења који су распоређени у кластер, као и могућност да се наведе где и где треба пренети податке за обуку модела. Овај обимни додатак је подразумевао проширење аутоматског функционалног тестирања, које је углавном обављено путем РЕСТ АПИ позива и малог броја енд-2-енд УИ тестова. На екватору целог овог кретања придружио нам се ручни тестер који је одлично обавио тестирање прихватљивости верзија производа и комуникацију са купцем у вези са прихватањем следећег издања. Поред тога, због доласка новог специјалисте, успели смо да документујемо свој рад и додамо неколико веома важних ручних провера које је било тешко одмах аутоматизовати.

И коначно, након што смо постигли стабилност са платформе и ГУИ додатка преко ње, почели смо да градимо ЕТЛ цевоводе користећи Апацхе Аирфлов ДАГ-ове. Аутоматизована провера квалитета података извршена је писањем специјалних ДАГ-ова протока ваздуха који су проверавали податке на основу резултата ЕТЛ процеса. У оквиру овог пројекта имали смо среће и купац нам је дао приступ анонимним скуповима података на којима смо тестирали. Проверили смо ред по ред података за усаглашеност са типовима, присуство оштећених података, укупан број записа пре и после, поређење трансформација направљених ЕТЛ процесом за агрегацију, промену назива колона и друге ствари. Поред тога, ове провере су скалиране на различите изворе података, на пример, поред СалесФорце-а, такође и на МиСКЛ.

Коначне провере квалитета података спроведене су већ на нивоу С3, где су похрањени и спремни за употребу за обуку модела машинског учења. Да би се добили подаци из коначне ЦСВ датотеке која се налази на С3 Буцкет-у и потврдили их, код је написан помоћу бото3 клијенти.

Такође је постојао захтев купца да део података складишти у једном С3 Буцкету, а део у другом. Ово је такође захтевало писање додатних провера како би се проверила поузданост таквог сортирања.

Уопштено искуство из других пројеката

Пример најопштије листе активности инжењера квалитета података:

Припремите тестне податке (важећи неважећи велики мали) преко аутоматизованог алата.
Отпремите припремљени скуп података у оригинални извор и проверите да ли је спреман за употребу.
Покрените ЕТЛ процесе за обраду скупа података од изворног складишта до коначног или међускладишта користећи одређени скуп подешавања (ако је могуће, поставите конфигурабилне параметре за ЕТЛ задатак).
Проверите податке које обрађује ЕТЛ процес за њихов квалитет и усклађеност са пословним захтевима.

При томе, главни фокус провера треба да буде не само на чињеници да је ток података у систему, у принципу, функционисао и дошао до краја (што је део функционалног тестирања), већ највише на провери и валидацији података за усаглашеност са очекиваним захтевима, идентификацију аномалија и друго.

Алат

Једна од техника за такву контролу података може бити организовање ланчаних провера у свакој фази обраде података, такозвани „ланац података” у литератури – контрола података од извора до тачке коначне употребе. Ове врсте провера се најчешће спроводе писањем СКЛ упита за проверу. Јасно је да такви упити треба да буду што лакши и да проверавају квалитет појединачних података (метаподаци табела, празни редови, НУЛЛ, грешке у синтакси – остали атрибути потребни за проверу).

У случају регресионог тестирања, које користи готове (непроменљиве, мало променљиве) скупове података, код за аутотест може да складишти готове шаблоне за проверу усклађености података са квалитетом (описи очекиваних метаподатака табеле; примери објеката редова који се могу насумично одабрано током теста, итд.).

Такође, током тестирања, морате писати ЕТЛ тестне процесе користећи оквире као што су Апацхе Аирфлов, Апацхе Спарк или чак алат типа облака црне кутије ГЦП Датапреп, ГЦП ток података И тако даље. Ова околност приморава инжењера за тестирање да се урони у принципе рада горе наведених алата и још ефикасније оба спроводе функционално тестирање (на пример, постојећи ЕТЛ процеси на пројекту) и користе их за проверу података. Конкретно, Апацхе Аирфлов има готове оператере за рад са популарним аналитичким базама података, на пример ГЦП БигКуери. Најосновнији пример његове употребе је већ наведен овде, па се нећу понављати.

Осим готових решења, нико вам не брани да имплементирате сопствене технике и алате. Ово неће бити од користи само за пројекат, већ и за самог инжењера квалитета података, који ће на тај начин побољшати своје техничке хоризонте и вештине кодирања.

Како то функционише на правом пројекту

Добра илустрација последњих параграфа о „ланцу података“, ЕТЛ-у и свеприсутним проверама је следећи процес из једног од правих пројеката:

Овде различити подаци (наравно, припремљени од нас) улазе у улазни „левак“ нашег система: валидни, неважећи, мешани итд., затим се филтрирају и завршавају у међускладишту, затим поново пролазе кроз низ трансформација и смештени су у завршну меморију, из које ће се, заузврат, вршити аналитика, изградња витрина података и тражење пословних увида. У таквом систему, без функционалне провере рада ЕТЛ процеса, фокусирамо се на квалитет података пре и после трансформације, као и на излаз у аналитику.

Да сумирамо горе наведено, без обзира на место где сам радио, свуда сам био укључен у Дата пројекте који су делили следеће карактеристике:

Само кроз аутоматизацију можете тестирати неке случајеве и постићи циклус објављивања прихватљив за пословање.
Тестер на оваквом пројекту је један од најцењенијих чланова тима, јер доноси велике користи сваком од учесника (убрзање тестирања, добри подаци од Дата Сциентист-а, идентификација недостатака у раним фазама).
Није важно да ли радите на сопственом хардверу или у облацима - сви ресурси се апстрахују у кластер као што су Хортонворкс, Цлоудера, Месос, Кубернетес итд.
Пројекти су изграђени на микросервисном приступу, преовлађују дистрибуирано и паралелно рачунарство.

Желео бих да приметим да када врши тестирање у области квалитета података, стручњак за тестирање помера свој професионални фокус на код производа и алате који се користе.

Посебне карактеристике тестирања квалитета података

Поред тога, за себе сам идентификовао следеће (одмах ћу резервисати да су ВЕОМА генерализоване и искључиво субјективне) карактеристичне карактеристике тестирања у пројектима (системима) података (Биг Дата) и другим областима:

Корисни линкови

теорија: ДАМА-ДМБОК: Збор знања о управљању подацима: 2. издање.
Центар за обуку ЕПАМ
Препоручени материјали за почетнике инжењера квалитета података:

Закључак

Квалитет података је веома млад правац који обећава, чији део значи бити део стартапа. Када једном уђете у квалитет података, бићете уроњени у велики број модерних, тражених технологија, али што је најважније, отвориће вам се огромне могућности да генеришете и имплементирате своје идеје. Бићете у могућности да користите приступ континуираног побољшања не само на пројекту, већ и за себе, континуирано се развијајући као специјалиста.

Извор: ввв.хабр.цом

Тестер великих и малих података: трендови, теорија, моја прича