Усім прывітанне, мяне клічуць Аляксандр, і я Data Quality інжынер, які займаецца праверкай дадзеных на прадмет іх якасці. У гэтым артыкуле гаворка пойдзе пра тое, як я да гэтага прыйшоў і чаму ў 2020 годзе гэты накірунак тэставання апынуўся на грэбні хвалі.
Сусветны трэнд
Сённяшні свет перажывае чарговую тэхналагічную рэвалюцыю, адным з аспектаў якой з'яўляецца выкарыстанне разнастайнымі кампаніямі назапашаных дадзеных для раскруткі ўласнага махавік продажаў, прыбыткаў і піяру. Уяўляецца, што менавіта наяўнасць добрых (якасных) дадзеных, а таксама ўмелых мазгоў, якія змогуць з іх рабіць грошы (правільна апрацаваць, візуалізаваць, пабудаваць мадэлі машыннага навучання і т. п.), сталі сёння ключом да поспеху для шматлікіх. Калі 15-20 гадоў таму шчыльнай працай з назапашваннем дадзеных і іх манетызацыяй займаліся ў асноўным буйныя кампаніі, то сёння гэта доля практычна ўсіх разважных.
У сувязі з гэтым некалькі гадоў таму ўсе парталы, прысвечаныя пошуку працы па ўсім свеце, сталі перапаўняцца вакансіямі Data Scientists, бо ўсе былі ўпэўненыя, што, атрымаўшы сабе ў штат такога адмыслоўца, можна пабудаваць супермадэль машыннага навучання, прадказаць будучыню і здзейсніць «квантавы». скачок» для кампаніі. З часам людзі зразумелі, што такі падыход амаль нідзе не працуе, бо далёка не ўсе дадзеныя, якія пападаюць у рукі такога роду спецыялістам, прыдатныя для навучання мадэляў.
І пачаліся запыты ад Data Scientists: "Давайце купім яшчэ дадзеных у гэтых і ў тых.…", "Нам не хапае дадзеных…", "Трэба яшчэ крыху дадзеных і пажадана якасных…". Грунтуючыся на гэтых запытах, сталі выбудоўвацца шматлікія ўзаемадзеянні паміж кампаніямі, якія валодаюць тым ці іншым наборам дадзеных. Натуральна, гэта запатрабавала тэхнічнай арганізацыі гэтага працэсу - падлучыцца да крыніцы дадзеных, выпампаваць іх, праверыць, што яны загружаны ў поўным аб'ёме і т. п. Колькасць такіх працэсаў стала расці, і на сённяшні дзень мы атрымалі вялікую патрэбу ў іншага роду спецыялістах - Data Quality інжынерах – тых хто сачыў бы за патокам дадзеных у сістэме (data pipelines), за якасцю дадзеных на ўваходзе і на выхадзе, рабіў бы высновы аб іх дастатковасці, цэласнасці і іншых характарыстыках.
Трэнд на Data Quality інжынераў прыйшоў да нас з ЗША, дзе ў разгар бушуючай эры капіталізму ніхто не гатовы прайграваць бітву за дадзеныя. Ніжэй я прадставіў скрыншоты з двух самых папулярных сайтаў пошуку працы ў ЗША: и - На якіх адлюстраваны дадзеныя па стане на 17 сакавіка 2020 года па колькасці размешчаных вакансій атрыманых, па ключавых словах: Data Quality і Data Scientist.
Data Scientists – 21416 вакансій
Data Quality – 41104 вакансіі
Data Scientists – 404 вакансіі
Data Quality - 2020 вакансій
Відавочна, што гэтыя прафесіі ніякім чынам не канкуруюць адна з адной. Скрыншотамі я проста жадаў праілюстраваць бягучую сітуацыю на рынку працы ў плане запытаў на Data Quality інжынераў, якіх зараз патрабуецца моцна больш, чым Data Scientists.
У чэрвені 2019 года EPAM, рэагуючы на патрэбы сучаснага ІТ-рынку, вылучыў Data Quality кірунак у асобную практыку. Data Quality інжынеры падчас сваёй паўсядзённай працы кіруюць дадзенымі, правяраюць іх паводзіны ў новых умовах і сістэмах, кантралююць рэлевантнасць дадзеных, іх дастатковасць і актуальнасць. Пры ўсім пры гэтым, у практычным сэнсе Data Quality інжынеры сапраўды трохі чакай прысвячаюць класічнаму функцыянальнаму тэставанню, АЛЕ гэта моцна залежыць ад праекту (прыклад я прывяду далей).
Абавязкі Data Quality інжынера не абмяжоўваюцца толькі руціннымі ручнымі / аўтаматычнымі праверкамі на "nulls, count і sums" у табліцах БД, а патрабуюць глыбокага разумення бізнес патрэб заказчыка і, адпаведна, здольнасцяў трансфармаваць наяўныя дадзеныя ў прыдатную бізнес-інфармацыю.
Тэорыя Data Quality
Для таго каб найболей досыць сабе ўявіць ролю такога інжынера, давайце разбярэмся, што ж такое Data Quality у тэорыі.
якасць дадзеных - Адзін з этапаў Data Management (цэлы свет, які мы пакінем вам на самастойнае вывучэнне) і адказвае за аналіз дадзеных па наступных крытэрыях:
Думаю, не варта расшыфроўваць кожны з пунктаў (у тэорыі завуцца "data dimensions"), яны цалкам добра апісаны на малюнку. Але сам працэс тэставання не мае на ўвазе строгае капіраванне гэтых прыкмет у тэст-кейсы і іх праверку. У Data Quality, як і ў любым іншым выглядзе тэсціравання, неабходна перш за ўсё адштурхоўвацца ад патрабаванняў па якасці дадзеных, узгодненых з удзельнікамі праекта, якія прымаюць бізнес-рашэнні.
У залежнасці ад праекта Data Quality інжынер можа выконваць розныя функцыі: ад звычайнага тэсціроўшчыка-аўтаматызатара з павярхоўнай ацэнкай якасці дадзеных, да чалавека, які праводзіць іх глыбокае прафіляванне па вышэйпаказаных прыкметах.
Вельмі падрабязнае апісанне працэсаў Data Management, Data Quality і сумежных выдатна апісаны ў кнізе пад назвай "DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition". Вельмі рэкамендую дадзеную кнігу як уступную ў гэтай тэматыцы (спасылку на яе знойдзеце ў канцы артыкула).
мая гісторыя
У ІТ-індустрыі я мінуў шлях ад Junior тэстыравальніка ў прадуктовых кампаніях да Lead Data Quality Engineer у кампаніі EPAM. Ужо прыкладна гады праз два працы ў якасці тэстыравальніка ў мяне было цвёрдае перакананне ў тым, што я рабіў абсалютна ўсе выгляды тэставання: рэгрэсійнае, функцыянальнае, стрэсавае, стабільнасці, бяспекі, UI і т. д. - і перакаштаваў вялікую колькасць прылад тэставання, папрацаваўшы пры гэтым на трох мовах праграмавання: Java, Scala, Python.
Азіраючыся назад, я разумею, чаму набор маіх прафесійных навыкаў аказаўся такім разнастайным — я ўдзельнічаў у праектах, завязаных на працы з дадзенымі, вялікімі і маленькімі. Менавіта гэта прывяло мяне ў свет вялікай колькасці інструментаў і магчымасцей для росту.
Каб ацаніць разнастайнасць інструментаў і магчымасцяў атрымання новых ведаў і навыкаў, дастаткова проста зірнуць на карцінку ніжэй, на якой намаляваны самыя папулярныя з іх у свеце "Data & AI".
Такога роду ілюстрацыі складае штогод адзін з вядомых венчурных капіталістаў Matt Turck, выхадзец з распрацоўкі ПЗ. Вось на яго блог і , дзе ён працуе партнёрам.
Асабліва хутка я прафесійна рос, калі я быў адзіным тэсціроўшчыкам на праекце, ці, па меншай меры, у пачатку праекта. Менавіта ў такі момант даводзіцца адказваць за ўвесь працэс тэсціравання, і ў цябе няма магчымасці адступіць, толькі наперад. Спачатку гэта пудзіла, аднак зараз мне відавочныя ўсе плюсы такога выпрабавання:
- Ты пачынаеш мець зносіны з усёй камандай як ніколі, бо няма ніякага проксі для зносін: ні тэст-мэнэджара, ні калегаў тэстыравальнікаў.
- Апусканне ў праект становіцца неверагодна глыбокім, і ты валодаеш інфармацыяй аб усіх кампанентах як увогуле, так і ў падрабязнасцях.
- Распрацоўнікі не глядзяць на цябе як на «таго хлопца з тэставання, які незразумела чым займаецца», а хутчэй, як на роўнага, які вырабляе неверагодную выгаду для каманды сваімі аўтатэстамі і прадбачаннем з'яўлення багаў у пэўным вузле прадукта.
- Як вынік - ты больш эфектыўны, больш кваліфікаваны, больш запатрабаваны.
Па меры разрастання праекту ў 100% выпадкаў я станавіўся настаўнікам для ізноў якія прыйшлі на яго тэстыравальнікаў, навучаў іх і перадаваў тыя веды, якім навучыўся сам. Пры гэтым, у залежнасці ад праекту, я не заўсёды атрымліваў ад кіраўніцтва адмыслоўцаў па аўта тэставанні найвышэйшага ўзроўня і была неабходнасць альбо навучаць іх аўтаматызацыі (для жадаючых), альбо ствараць прылады для выкарыстання імі ў паўсядзённых актыўнасцях (прылады генерацыі дадзеных і іх загрузкі ў сістэму , інструмент для правядзення нагрузачнага тэсціравання / тэсціравання стабільнасці «па-хуценькаму» і да т.п.).
Прыклад канкрэтнага праекта
Нажаль, у сілу абавязанняў аб невыдаванні я не магу падрабязна распавядаць аб праектах, на якіх я працаваў, аднак прывяду прыклады тыповых задач Data Quality Engineer на адным з праектаў.
Сутнасць праекта - рэалізаваць платформу для падрыхтоўкі даных для навучання на іх аснове мадэлей машыннага навучання. Замоўцам была буйная фармацэўтычная кампанія з ЗША. Тэхнічна гэта быў кластар , які падымаецца на інстансах, з некалькімі мікрасэрвісамі і ляжалым у аснове Open Source праектам кампаніі EPAM , адаптаваным пад патрэбы канкрэтнага заказчыка (цяпер праект перароджаны ў ). ETL-працэсы былі арганізаваны пры дапамозе і перамяшчалі дадзеныя з сістэмы заказчыка ў Buckets. Далей на платформу деплоился докер выява мадэлі машыннага навучання, якая навучалася на свежых дадзеных і па REST API інтэрфейсу выдавала прадказанні, якія цікавяць бізнэс і вырашальныя пэўныя задачы.
Візуальна ўсё выглядала прыкладна так:
Функцыянальнага тэсціравання на гэтым праекце было дастаткова, а ўлічваючы хуткасць распрацоўкі фічаў і неабходнасці падтрымання тэмпаў рэлізнага цыкла (двухтыднёвыя спрынты), неабходна было адразу задумвацца аб аўтаматызацыі тэсціравання самых крытычных вузлоў сістэмы. Вялікая частка самай платформы з Kubernetes асновай пакрывалася аўтатэстамі, рэалізаванымі на + Python, але падтрымліваць і пашыраць іх таксама было трэба. Акрамя таго, для выгоды замоўца, быў створаны GUI для кіравання мадэлямі машыннага навучання, задэплоенымі на кластар, а таксама магчымасць паказаць адкуль і куды неабходна перанесці дадзеныя для навучання мадэляў. Гэты шырокі дадатак пацягнула за сабой пашырэнне аўтаматызаваных функцыянальных праверак, якія па большай частцы рабіліся праз REST API выклікі і невялікая колькасць end-2-end UI-тэстаў. Прыкладна на экватары ўсяго гэтага руху да нас далучыўся ручны тэсціроўшчык, які выдатна спраўляўся з прыёмачным тэсціраваннем версій прадукту і зносінамі з заказчыкам з нагоды прыёмкі чарговага рэлізу. Акрамя таго, за кошт з'яўлення новага адмыслоўца мы змаглі дакументаваць нашу працу і дадаць некалькі вельмі важных ручных праверак, якія было цяжка адразу аўтаматызаваць.
І нарэшце, пасля таго як мы дабіліся стабільнасці ад платформы і GUI надбудовай над ёй мы прыступілі да пабудовы ETL pipelines пры дапамозе Apache Airflow DAGs. Аўтаматызаваная праверка якасці дадзеных ажыццяўлялася пры дапамозе напісання спецыяльных Airflow DAGs якія правяралі дадзеныя па выніках працы ETL працэсу. У рамках гэтага праекта нам пашанцавала, і заказчык даў нам доступ да абязлічаных набораў даных, на якіх мы і тэсціраваліся. Правяралі дадзеныя парадкова на адпаведнасць тыпам, наяўнасць бітых дадзеных, агульная колькасць запісаў да і пасля, параўнанне вырабленых ETL-працэсам пераўтварэнняў па агрэгацыі, змене назваў калонак і іншага. Акрамя таго, гэтыя праверкі былі маштабаваны на розныя крыніцы дадзеных, напрыклад, акрамя SalesForce яшчэ і на MySQL.
Праверкі канчатковай якасці даных ажыццяўляліся ўжо на ўзроўні S3, дзе яны захоўваліся і былі ў стане ready-to-use для навучання мадэлей машыннага навучання. Для атрымання дадзеных з канчатковага CSV файла, які ляжыць на S3 Bucket і іх валідацыі, быў напісаны код з выкарыстаннем .
Таксама са боку замоўца было патрабаванне на захоўванне часткі дадзеных у адным S3 Bucket'e, часткі ў іншым. Для гэтага таксама спатрэбілася пісаць дадатковыя праверкі, якія кантралююць дакладнасць такога сартавання.
Абагульнены вопыт па іншых праектах
Прыклад самага абагульненага пераліку актыўнасцяў Data Quality інжынера:
- Падрыхтаваць тэставыя дадзеныя (валідныя невалідныя вялікія маленькія) праз аўтаматызаваны інструмент.
- Загрузіць падрыхтаваны набор дадзеных у зыходную крыніцу і праверыць яго гатоўнасць да выкарыстання.
- Запусціць ETL-працэсы па апрацоўцы набору дадзеных з зыходнага сховішча ў канчатковае ці прамежкавае з ужываннем вызначанага набору налад (у выпадку магчымасці задаць канфігуруемыя параметры для ETL-задачы).
- Верыфікаваць апрацаваныя ETL-працэсам дадзеныя на прадмет іх якасці і адпаведнасць бізнэс-патрабаванням.
Пры гэтым асноўны акцэнт праверак павінен прыходзіцца не толькі на тое, што паток даных у сістэме ў прынцыпе адпрацаваў і дайшоў да канца (што з'яўляецца часткай функцыянальнага тэсціравання), а па большай частцы на праверку і валідацыю даных на прадмет адпаведнасці чаканым патрабаванням, выяўленню анамалій і іншага.
Інструменты
Адной з тэхнік такога кантролю за дадзенымі можа быць арганізацыя ланцужных праверак на кожнай стадыі апрацоўкі дадзеных, так званы ў літаратуры data chain - кантроль дадзеных ад крыніцы да пункта фінальнага выкарыстання. Такія праверкі часцей за ўсё рэалізуюцца за кошт напісання правяраючых SQL-запытаў. Зразумелая справа, што такія запыты павінны быць максімальна легкаважнымі і правяраючымі асобныя кавалкі якасці дадзеных (tables metadata, blank lines, NULLs, Errors in syntax – іншыя патрабаваныя праверкі атрыбуты).
У выпадку рэгрэсійнага тэставання, у якім выкарыстоўваюцца ўжо гатовыя (нязменныя нязначна змяняныя) наборы дадзеных, у кодзе аўтатэстаў могуць захоўвацца ўжо гатовыя шаблоны праверкі дадзеных на адпаведнасць якасці (апісанні чаканых метададзеных табліц; малых выбарачных аб'ектаў, якія могуць выбірацца выпадкова падчас тэсту, і іншае ).
Таксама падчас тэставанняў прыходзіцца пісаць тэставыя ETL-працэсы, пры дапамозе такіх фрэймворкаў як Apache Airflow, ці зусім black-box cloud інструмент тыпу , і іншае. Гэтая акалічнасць прымушае тэст-інжынера пагрузіцца ў прынцыпы працы вышэйназваных інструментаў і яшчэ больш эфектыўна як праводзіць функцыянальнае тэсціраванне (напрыклад, існуючых на праекце ETL-працэсаў), так і выкарыстоўваць іх для праверкі дадзеных. У прыватнасці, для Apache Airflow ёсць ужо гатовыя аператары для працы з папулярнымі аналітычнымі базамі дадзеных, напрыклад . Самы базавы прыклад яго выкарыстання ўжо выкладзены , таму не буду паўтарацца.
Акрамя гатовых рашэнняў, ніхто не забараняе вам рэалізоўваць свае тэхнікі і прылады. Гэта не толькі будзе карысцю для праекту, але і для самога Data Quality Engineer, які тым самым прапампуе свой тэхнічны кругагляд і навыкі кадавання.
Як гэта працуе на рэальным праекце
Добрай ілюстрацыяй апошніх абзацаў пра "data chain", ETL і ўсюдыісныя праверкі з'яўляецца наступны працэс з аднаго з рэальных праектаў:
Тут ва ўваходную "варонку" нашай сістэмы трапляюць розныя дадзеныя (натуральна, намі і падрыхтаваныя): валідныя, невалідныя, змешаныя і т. п., потым яны фільтруюцца і трапляюць у прамежкавае сховішча, затым іх зноў чакае шэраг пераўтварэнняў і памяшканне ў канчатковае сховішча. , З якога, у сваю чаргу, і будзе праводзіцца аналітыка, пабудова вітрын дадзеных і пошук бізнес-інсайтаў. У такой сістэме мы, не правяраючы функцыянальна працу ETL-працэсаў, факусуемся на якасці дадзеных да і пасля пераўтварэнняў, а таксама на вынахадзе ў аналітыку.
Рэзюмуючы вышэйсказанае, незалежна ад месцаў, дзе я працаваў, усюды быў уцягнуты ў Data-праекты, якія аб'ядноўвалі наступныя рысы:
- Толькі праз аўтаматызацыю можна праверыць некаторыя кейсы і дасягнуць прымальнага для бізнэсу рэлізнага цыклу.
- Тэстыравальнік на такім праекце – адзін з самых паважаных чальцоў каманды, бо прыносіць велізарную карысць кожнаму з удзельнікаў (паскарэнне тэставання, добрыя дадзеныя ў Data Scientist, выяўленне дэфектаў на ранніх этапах).
- Усё роўна на сваім жалезе вы працуеце ці ў аблоках - усе рэсурсы абстрагаваныя ў кластар тыпу Hortonworks, Cloudera, Mesos, Kubernetes і т. п.
- Праекты будуюцца на мікрасэрвісным падыходзе, пераважаюць размеркаваныя і паралельныя вылічэнні.
Адзначу, што, займаючыся тэставаннем у вобласці Data Quality, адмысловец па тэставанні ссоўвае свой прафесійны фокус на код прадукта і выкарыстоўваных прылад.
Адметныя асаблівасці Data Quality тэсціравання
Акрамя таго, для сябе я вылучыў наступныя (адразу абмоўлюся ВЕЛЬМІ абагульненыя і выключна суб'ектыўныя) адметныя рысы тэсціравання ў Data (Big Data) праектах (сістэмах) і іншых напрамках:
Карысныя спасылкі
- Тэорыя: .
- EPAM
- Рэкамендуемыя матэрыялы для пачаткоўца Data Quality інжынера:
- Бясплатны курс на Stepik: .
- Курс на LinkedIn Learning: .
- Артыкулы:
- ;
- ;
- ;
- Відэа:
- ;
- ;
Заключэнне
якасць дадзеных - гэта вельмі малады перспектыўны кірунак, быць часткай якога азначае быць часткай нейкага стартапа. Патрапіўшы ў Data Quality, вы акуняцеся ў вялікую колькасць сучасных запатрабаваных тэхналогій, але самае галоўнае – перад вамі адкрыюцца велізарныя магчымасці для генеравання і рэалізацый сваіх ідэй. Вы зможаце выкарыстоўваць падыход пастаяннага паляпшэння не толькі на праекце, але і для сябе, бесперапынна развіваючыся як спецыяліст.
Крыніца: habr.com