Тестер за големи и мали податоци: трендови, теорија, мојата приказна

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

Тестер за големи и мали податоци: трендови, теорија, мојата приказна

Глобален тренд

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

Во овој поглед, пред неколку години, сите портали посветени на барање работа ширум светот почнаа да се пополнуваат со слободни работни места за Data Scientists, бидејќи сите беа сигурни дека, со ангажирање на таков специјалист, ќе биде можно да се изгради супермодел на машинско учење , предвидете ја иднината и изведете „квантен скок“ за компанијата. Со текот на времето, луѓето сфатија дека овој пристап речиси никогаш не функционира никаде, бидејќи не сите податоци што паѓаат во рацете на таквите специјалисти се погодни за модели за обука.

И започнаа барањата од Data Scientists: „Ајде да купиме повеќе податоци од овие и оние...“, „Немаме доволно податоци...“, „Ни требаат уште некои податоци, по можност висококвалитетни...“ . Врз основа на овие барања, почнаа да се градат бројни интеракции помеѓу компаниите кои поседуваат еден или друг сет на податоци. Нормално, тоа бараше техничка организација на овој процес - поврзување со изворот на податоци, преземање, проверка дали е целосно вчитан итн. Бројот на такви процеси почна да расте, а денес имаме огромна потреба од друг вид специјалисти - Инженери за квалитет на податоци - оние кои би го следеле протокот на податоци во системот (цевководи на податоци), квалитетот на податоците на влезот и излезот и ќе извлечат заклучоци за нивната доволност, интегритет и други карактеристики.

Трендот за инженери за квалитет на податоци дојде кај нас од Соединетите Американски Држави, каде што, во средината на бесната ера на капитализмот, никој не е подготвен да ја загуби битката за податоци. Подолу дадов слики од екранот од две од најпопуларните сајтови за барање работа во САД: www.monster.com и www.dice.com — што прикажува податоци заклучно со 17 март 2020 година за бројот на објавени слободни работни места со помош на клучните зборови: Data Quality и Data Scientist.

www.monster.com

Data Scientists – 21416 слободни работни места
Квалитет на податоци – 41104 слободни работни места

Тестер за големи и мали податоци: трендови, теорија, мојата приказна
Тестер за големи и мали податоци: трендови, теорија, мојата приказна

www.dice.com

Data Scientists – 404 слободни работни места
Квалитет на податоци – слободни работни места за 2020 година

Тестер за големи и мали податоци: трендови, теорија, мојата приказна
Тестер за големи и мали податоци: трендови, теорија, мојата приказна

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

Во јуни 2019 година, ЕПАМ, одговарајќи на потребите на современиот ИТ пазар, го подели квалитетот на податоците во посебна практика. Инженерите за квалитет на податоци, во текот на нивната секојдневна работа, управуваат со податоците, го проверуваат нивното однесување во нови услови и системи, ја следат релевантноста на податоците, нивната доволност и релевантност. Со сето ова, во практична смисла, инженерите за квалитет на податоци навистина посветуваат малку време на класичното функционално тестирање, НО ова во голема мера зависи од проектот (ќе дадам пример подолу).

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

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

Тестер за големи и мали податоци: трендови, теорија, мојата приказна

Со цел поцелосно да ја замислиме улогата на таков инженер, ајде да откриеме што е Квалитет на податоци во теорија.

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

Тестер за големи и мали податоци: трендови, теорија, мојата приказна
Мислам дека нема потреба да се дешифрира секоја од точките (во теорија тие се нарекуваат „димензии на податоци“), тие се доста добро опишани на сликата. Но, самиот процес на тестирање не подразбира строго копирање на овие карактеристики во тест случаи и нивно проверување. Во квалитетот на податоците, како и во секој друг вид на тестирање, потребно е, пред сè, да се надоврзе на барањата за квалитет на податоците договорени со учесниците во проектот кои носат деловни одлуки.

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

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

Мојата историја

Во ИТ индустријата, се искачив од помлад тестер во производствени компании до водечки инженер за квалитет на податоци во EPAM. По околу две години работа како тестер, имав цврсто убедување дека сум ги направил апсолутно сите видови тестирања: регресија, функционално, стрес, стабилност, безбедност, интерфејс итн. - и пробав голем број алатки за тестирање, имајќи работеше во исто време на три програмски јазици: Java, Scala, Python.

Гледајќи наназад, разбирам зошто мојот сет на вештини беше толку разновиден - бев вклучен во проекти водени од податоци, големи и мали. Тоа е она што ме донесе во светот на многу алатки и можности за раст.

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

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

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

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

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

Пример за конкретен проект

За жал, поради обврските за необјавување, не можам детално да зборувам за проектите на кои работев, но ќе дадам примери на типични задачи на инженер за квалитет на податоци на еден од проектите.

Суштината на проектот е да се имплементира платформа за подготовка на податоци за обука на модели за машинско учење врз основа на неа. Клиент беше голема фармацевтска компанија од САД. Технички тоа беше кластер Кубернети, издигнувајќи до AWS EC2 примери, со неколку микроуслуги и основниот проект со отворен код на EPAM - Легијата, прилагодени на потребите на одреден клиент (сега проектот е прероден во одаху). ETL процесите беа организирани со користење Апачи проток на воздух и преместени податоци од Продажна сила клиенти системи во AWS S3 Кофи. Потоа, на платформата беше распоредена слика на Docker на модел за машинско учење, која беше обучена за свежи податоци и, користејќи го интерфејсот REST API, произведе предвидувања кои беа од интерес за бизнисот и решаваше конкретни проблеми.

Визуелно, сè изгледаше вака:

Тестер за големи и мали податоци: трендови, теорија, мојата приказна
Имаше многу функционални тестирања на овој проект, а со оглед на брзината на развој на функции и потребата да се одржи темпото на циклусот на објавување (двонеделни спринтови), неопходно беше веднаш да се размислува за автоматизирање на тестирањето на најкритичните компоненти на системот. Поголемиот дел од самата платформа базирана на Кубернетес беше покриена со автотестови имплементирани во Рамка за роботи + Python, но исто така беше неопходно да се поддржат и да се прошират. Дополнително, за погодност на клиентот, создаден е GUI за управување со моделите за машинско учење распоредени во кластерот, како и можност за одредување каде и каде треба да се пренесат податоците за обука на моделите. Овој обемен додаток повлекуваше проширување на автоматизираното функционално тестирање, кое главно беше направено преку повици REST API и мал број на тестови на интерфејс од 2 крај. Околу екваторот на сето ова движење, ни се придружи рачен тестер кој заврши одлична работа со тестирањето на прифаќањето на верзиите на производите и комуникацијата со клиентот во врска со прифаќањето на следното издание. Дополнително, поради доаѓањето на нов специјалист, можевме да ја документираме нашата работа и да додадеме неколку многу важни рачни проверки кои беше тешко да се автоматизираат веднаш.

И, конечно, откако постигнавме стабилност од платформата и додатокот за GUI преку неа, почнавме да градиме ETL цевководи користејќи Apache Airflow DAG. Автоматската проверка на квалитетот на податоците беше спроведена со пишување специјални ДАГ за проток на воздух кои ги проверуваа податоците врз основа на резултатите од процесот ETL. Како дел од овој проект, имавме среќа и клиентот ни даде пристап до анонимизирани сетови на податоци на кои тестиравме. Ги проверувавме податоците линија по ред за усогласеност со типовите, присуството на скршени податоци, вкупниот број на записи пред и потоа, споредба на трансформациите направени од процесот ETL за агрегација, менување на имињата на колоните и други работи. Покрај тоа, овие проверки беа размерени на различни извори на податоци, на пример, покрај SalesForce, исто така и на MySQL.

Конечните проверки на квалитетот на податоците беа извршени веќе на ниво S3, каде што беа складирани и беа подготвени за употреба за обука на модели за машинско учење. За да се добијат податоци од конечната CSV-датотека лоцирана на корпата S3 и да се валидираат, кодот беше напишан со користење клиенти на boto3.

Постоеше и барање од клиентот да складира дел од податоците во една кофа S3, а дел во друга. Ова исто така бараше пишување дополнителни проверки за да се провери веродостојноста на таквото сортирање.

Генерализирано искуство од други проекти

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

  • Подгответе податоци од тестот (валидни невалидни големи мали) преку автоматизирана алатка.
  • Поставете го подготвениот сет на податоци на оригиналниот извор и проверете дали е подготвен за употреба.
  • Стартувајте ETL процеси за обработка на збир на податоци од изворното складирање до последното или средното складирање користејќи одреден сет на поставки (ако е можно, поставете ги конфигурабилните параметри за задачата ETL).
  • Потврдете ги податоците обработени од процесот ETL за нивниот квалитет и усогласеност со деловните барања.

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

Алатки

Една од техниките за таква контрола на податоците може да биде организација на верижни проверки во секоја фаза од обработката на податоците, таканаречениот „синџир на податоци“ во литературата - контрола на податоците од изворот до точката на конечна употреба. Овие типови на проверки најчесто се имплементираат со пишување на SQL пребарувања за проверка. Јасно е дека таквите барања треба да бидат колку што е можно полесни и да проверуваат поединечни делови од квалитетот на податоците (табели метаподатоци, празни линии, NULL, Грешки во синтаксата - други атрибути потребни за проверка).

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

Исто така, за време на тестирањето, треба да ги напишете процесите за тестирање ETL користејќи рамки како Apache Airflow, Apache Spark или дури и алатка од типот облак од црна кутија Подготовка на податоци за GCP, GCP проток на податоци И така натаму. Оваа околност го принудува инженерот за тестирање да се потопи во принципите на работа на горенаведените алатки и уште поефикасно да спроведе функционално тестирање (на пример, постоечки ETL процеси на проект) и да ги користи за проверка на податоците. Особено, Apache Airflow има готови оператори за работа со популарни аналитички бази на податоци, на пример GCP BigQuery. Најосновниот пример за неговата употреба е веќе наведен тука, затоа нема да се повторувам.

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

Како функционира на вистински проект

Добра илустрација на последните параграфи за „синџирот на податоци“, ETL и сеприсутните проверки е следниов процес од еден од реалните проекти:

Тестер за големи и мали податоци: трендови, теорија, мојата приказна

Тука во влезната „инка“ на нашиот систем влегуваат различни податоци (природно, подготвени од нас): валидни, невалидни, мешани итн., потоа се филтрираат и завршуваат во средно складиште, па повторно претрпуваат низа трансформации и се сместени во последното складирање, од кое, пак, ќе се врши аналитика, градење податоци и пребарување на деловни увиди. Во таков систем, без функционална проверка на работата на ETL процесите, се фокусираме на квалитетот на податоците пред и по трансформациите, како и на излезот до аналитиката.

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

  • Само преку автоматизација можете да тестирате некои случаи и да постигнете циклус на ослободување прифатлив за бизнисот.
  • Тестерот на таков проект е еден од најпочитуваните членови на тимот, бидејќи носи големи придобивки за секој од учесниците (забрзување на тестирањето, добри податоци од Data Scientist, идентификација на дефекти во раните фази).
  • Не е важно дали работите на сопствен хардвер или во облаци - сите ресурси се апстрахирани во кластер како што се Hortonworks, Cloudera, Mesos, Kubernetes итн.
  • Проектите се изградени на микросервис пристап, дистрибуирани и паралелни пресметувања преовладуваат.

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

Карактеристични карактеристики на тестирањето на квалитетот на податоците

Дополнително, за себе ги идентификував следните (веднаш ќе направам резерва дека тие се МНОГУ генерализирани и исклучиво субјективни) карактеристични карактеристики на тестирањето во проекти (системи) со податоци (големи податоци) и други области:

Тестер за големи и мали податоци: трендови, теорија, мојата приказна

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

  1. Теорија: ДАМА-ДМБОК: Управување со податоци Тело на знаење: второ издание.
  2. Тренинг центар ЕПАМ 
  3. Препорачани материјали за почетник инженер за квалитет на податоци:
    1. Бесплатен курс на Степик: Вовед во бази на податоци
    2. Курс за учење на LinkedIn: Основи за наука за податоци: инженерство на податоци.
    3. Статии:
    4. Видео:

Заклучок

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

Извор: www.habr.com

Додадете коментар