🥇Тестер за големи и малки данни: тенденции, теория, моята история

Здравейте на всички, казвам се Александър и съм инженер по качеството на данните, който проверява качеството на данните. Тази статия ще говори за това как стигнах до това и защо през 2020 г. тази област на тестване беше на гребена на вълната.

Световна тенденция

Днешният свят преживява друга технологична революция, един от аспектите на която е използването на натрупани данни от всякакви компании за насърчаване на техния собствен маховик на продажби, печалби и PR. Изглежда, че наличието на добри (качествени) данни, както и квалифицирани мозъци, които могат да правят пари от тях (правилно обработват, визуализират, изграждат модели за машинно обучение и т.н.), са се превърнали в ключ към успеха за мнозина днес. Ако преди 15-20 години големите компании се занимаваха предимно с интензивна работа с натрупване на данни и монетизация, днес това е участта на почти всички здрави хора.

В тази връзка преди няколко години всички портали, посветени на търсенето на работа по света, започнаха да се пълнят със свободни работни места за Data Scientists, тъй като всички бяха сигурни, че след като наемат такъв специалист, ще бъде възможно да се изгради супермодел на машинно обучение , предсказват бъдещето и извършват „квантов скок“ за компанията. С течение на времето хората разбраха, че този подход почти никога не работи никъде, тъй като не всички данни, които попадат в ръцете на такива специалисти, са подходящи за обучение на модели.

И започнаха молби от Data Scientists: „Да купим повече данни от тези и онези...“, „Нямаме достатъчно данни...“, „Имаме нужда от още данни, за предпочитане висококачествени...“ . Въз основа на тези заявки започнаха да се изграждат множество взаимодействия между компании, които притежават един или друг набор от данни. Естествено, това изискваше техническа организация на този процес - свързване с източника на данни, изтеглянето им, проверка дали са заредени изцяло и т.н. Броят на тези процеси започна да расте и днес имаме огромна нужда от друг вид специалисти - Инженери по качеството на данните - тези, които ще наблюдават потока от данни в системата (data pipelines), качеството на данните на входа и изхода и ще направят изводи за тяхната достатъчност, цялостност и други характеристики.

Тенденцията за инженери по качеството на данните дойде при нас от САЩ, където в разгара на бушуващата ера на капитализма никой не е готов да загуби битката за данни. По-долу съм предоставил екранни снимки от два от най-популярните сайтове за търсене на работа в САЩ: 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 свободни позиции

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

През юни 2019 г. EPAM, в отговор на нуждите на съвременния ИТ пазар, отдели Data Quality в отделна практика. Инженерите по качеството на данните, в хода на ежедневната си работа, управляват данни, проверяват поведението им в нови условия и системи, следят уместността на данните, тяхната достатъчност и уместност. С всичко това, в практически смисъл, инженерите по качеството на данните наистина отделят малко време на класическото функционално тестване, НО това до голяма степен зависи от проекта (ще дам пример по-долу).

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

Теория за качеството на данните

За да си представим по-пълно ролята на такъв инженер, нека разберем какво е качеството на данните на теория.

Качество на данните — един от етапите на управление на данни (цял свят, който ще ви оставим да изучавате сами) и отговаря за анализирането на данните според следните критерии:

Мисля, че няма нужда да дешифрирате всяка от точките (на теория те се наричат „измерения на данни“), те са доста добре описани на снимката. Но самият процес на тестване не предполага стриктно копиране на тези функции в тестови случаи и проверката им. При качеството на данните, както при всеки друг вид тестване, е необходимо преди всичко да се надграждат изискванията за качество на данните, договорени с участниците в проекта, които вземат бизнес решения.

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

Много подробно описание на управлението на данните, качеството на данните и свързаните с тях процеси е добре описано в наречената книга „DAMA-DMBOK: Съвкупност от знания за управление на данни: 2-ро издание“. Силно препоръчвам тази книга като въведение в тази тема (ще намерите връзка към нея в края на статията).

Моята история

В ИТ индустрията изкачих пътя си от младши тестер в продуктови компании до водещ инженер по качеството на данните в EPAM. След около две години работа като тестер имах твърдото убеждение, че съм правил абсолютно всички видове тестване: регресионно, функционално, стрес, стабилност, сигурност, UI и т.н. - и съм пробвал голям брой инструменти за тестване, като работи едновременно на три езика за програмиране: Java, Scala, Python.

Поглеждайки назад, разбирам защо наборът ми от умения беше толкова разнообразен – участвах в проекти, управлявани от данни, големи и малки. Това ме доведе в свят на много инструменти и възможности за растеж.

За да оцените разнообразието от инструменти и възможности за придобиване на нови знания и умения, просто погледнете снимката по-долу, която показва най-популярните в света на „Данни и AI“.

Този вид илюстрация се съставя всяка година от един от известните рискови капиталисти Мат Турк, който идва от разработката на софтуер. Тук връзка към своя блог и фирма за рисков капитал, където работи като съдружник.

Израснах професионално особено бързо, когато бях единственият тестер в проекта или поне в началото на проекта. Точно в такъв момент вие трябва да носите отговорност за целия процес на тестване и нямате възможност да се оттеглите, а само напред. Отначало беше страшно, но сега всички предимства на такъв тест са очевидни за мен:

Започвате да общувате с целия екип, както никога досега, тъй като няма прокси за комуникация: нито мениджърът на теста, нито колегите тестери.
Потапянето в проекта става невероятно дълбоко и имате информация за всички компоненти, както общо, така и в детайли.
Разработчиците не гледат на вас като на „онзи човек от тестването, който не знае какво прави“, а по-скоро като на равен, който произвежда невероятни ползи за екипа със своите автоматизирани тестове и предвиждане на грешки, появяващи се в конкретен компонент на продукт.
В резултат на това вие сте по-ефективни, по-квалифицирани и по-търсени.

С разрастването на проекта в 100% от случаите се превърнах в ментор на новите тестери, като ги обучавах и им предавах знанията, които сам бях научил. В същото време, в зависимост от проекта, не винаги получавах от ръководството специалисти по автоматично тестване на най-високо ниво и имаше нужда или да ги обучавам в автоматизация (за заинтересованите), или да създавам инструменти за използване в ежедневните дейности (инструменти за генериране на данни и зареждането им в системата, инструмент за извършване на тестове за натоварване/тестове за стабилност „бързо“ и др.).

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

За съжаление, поради задължения за неразкриване на информация, не мога да говоря подробно за проектите, по които съм работил, но ще дам примери за типични задачи на Data Quality Engineer по един от проектите.

Същността на проекта е да се внедри платформа за подготовка на данни за обучение на модели за машинно обучение, базирани на нея. Клиентът беше голяма фармацевтична компания от САЩ. Технически това беше клъстер Kubernetes, издигайки се до AWS EC2 инстанции, с няколко микроуслуги и основния проект с отворен код на EPAM - Легион, адаптиран към нуждите на конкретен клиент (сега проектът е прероден в отаху). ETL процесите са организирани с помощта на въздушен поток Apache и преместени данни от SalesForce клиентски системи в AWS S3 кофи. След това Docker изображение на модел за машинно обучение беше внедрено в платформата, която беше обучена на свежи данни и, използвайки интерфейса на REST API, създаде прогнози, които представляваха интерес за бизнеса и решиха специфични проблеми.

Визуално всичко изглеждаше така:

Имаше много функционални тестове по този проект и предвид скоростта на разработване на функции и необходимостта да се поддържа темпото на цикъла на пускане (двуседмични спринтове), беше необходимо незабавно да се помисли за автоматизиране на тестването на най-критичните компоненти на системата. По-голямата част от самата платформа, базирана на Kubernetes, беше покрита от автоматични тестове, внедрени в Рамка за роботи + Python, но също така беше необходимо да ги поддържаме и разширяваме. В допълнение, за удобство на клиента е създаден GUI за управление на моделите за машинно обучение, внедрени в клъстера, както и възможността да се посочи къде и къде трябва да се прехвърлят данни за обучение на моделите. Това обширно допълнение доведе до разширяване на автоматизираното функционално тестване, което се извършваше предимно чрез REST API извиквания и малък брой крайни 2-крайни UI тестове. Около екватора на цялото това движение към нас се присъедини ръчен тестер, който свърши отлична работа с тестовете за приемане на продуктовите версии и комуникацията с клиента относно приемането на следващото издание. Освен това, поради пристигането на нов специалист, успяхме да документираме работата си и да добавим няколко много важни ръчни проверки, които беше трудно да се автоматизират веднага.

И накрая, след като постигнахме стабилност от платформата и GUI добавката върху нея, започнахме да изграждаме ETL конвейери, използвайки Apache Airflow DAG. Автоматизираната проверка на качеството на данните беше извършена чрез писане на специални Airflow DAG, които проверяваха данните въз основа на резултатите от ETL процеса. Като част от този проект имахме късмет и клиентът ни даде достъп до анонимизирани набори от данни, върху които тествахме. Проверихме данните ред по ред за съответствие с типовете, наличието на повредени данни, общия брой записи преди и след, сравнение на трансформациите, направени от ETL процеса за агрегиране, промяна на имена на колони и други неща. В допълнение, тези проверки бяха мащабирани към различни източници на данни, например, в допълнение към SalesForce, също към MySQL.

Окончателните проверки на качеството на данните бяха извършени вече на ниво S3, където те бяха съхранени и бяха готови за използване за обучение на модели за машинно обучение. За да получите данни от крайния CSV файл, намиращ се в S3 Bucket и да го потвърдите, кодът е написан с помощта на клиенти на boto3.

Имаше и изискване от клиента част от данните да се съхраняват в една S3 Bucket и част в друга. Това също изисква писане на допълнителни проверки, за да се провери надеждността на такова сортиране.

Обобщен опит от други проекти

Пример за най-общ списък с дейности на инженер по качеството на данните:

Подгответе тестови данни (валидни невалидни големи малки) чрез автоматизиран инструмент.
Качете подготвения набор от данни в оригиналния източник и проверете дали е готов за използване.
Стартирайте ETL процеси за обработка на набор от данни от изходното хранилище до крайното или междинното хранилище, като използвате определен набор от настройки (ако е възможно, задайте конфигурируеми параметри за ETL задачата).
Проверете данните, обработени от ETL процеса, за тяхното качество и съответствие с бизнес изискванията.

В същото време основният фокус на проверките трябва да бъде не само върху факта, че потокът от данни в системата по принцип е работил и е достигнал края (което е част от функционалното тестване), но най-вече върху проверката и валидирането на данни за съответствие с очакваните изисквания, идентифициране на аномалии и други неща.

Инструменти

Една от техниките за такъв контрол на данните може да бъде организирането на верижни проверки на всеки етап от обработката на данните, така наречената в литературата „верига от данни“ - контрол на данните от източника до точката на крайна употреба. Тези видове проверки най-често се изпълняват чрез писане на проверяващи SQL заявки. Ясно е, че такива заявки трябва да бъдат възможно най-леки и да проверяват отделни части от качеството на данните (метаданни на таблици, празни редове, NULL, грешки в синтаксиса - други атрибути, необходими за проверка).

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

Освен това, по време на тестване, трябва да напишете ETL тестови процеси, като използвате рамки като Apache Airflow, Апачи Спарк или дори облачен инструмент за черна кутия GCP Dataprep, GCP поток от данни И така нататък. Това обстоятелство принуждава тестовия инженер да се потопи в принципите на работа на горепосочените инструменти и още по-ефективно да провежда функционално тестване (например съществуващи ETL процеси в даден проект) и да ги използва за проверка на данни. По-специално, Apache Airflow има готови оператори за работа с популярни аналитични бази данни, например GCP BigQuery. Най-основният пример за използването му вече е очертан тук, така че няма да се повтарям.

Освен готови решения, никой не ви забранява да прилагате собствени техники и инструменти. Това ще бъде от полза не само за проекта, но и за самия инженер по качеството на данните, който по този начин ще подобри своите технически хоризонти и умения за кодиране.

Как работи в реален проект

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

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

За да обобщя горното, независимо от местата, където работех, навсякъде участвах в проекти за данни, които споделяха следните характеристики:

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

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

Отличителни черти на тестването на качеството на данните

Освен това за себе си идентифицирах следните (веднага ще направя резервация, че те са МНОГО обобщени и изключително субективни) отличителни черти на тестването в проекти (системи) за данни (Големи данни) и други области:

Полезни връзки

теория: DAMA-DMBOK: Съвкупност от знания за управление на данни: 2-ро издание.
Тренировъчен център EPAM
Препоръчителни материали за начинаещ инженер по качеството на данните:

Заключение

Качество на данните е много младо обещаващо направление, да си част от което означава да си част от стартъп. Веднъж в Data Quality, ще се потопите в голям брой модерни, търсени технологии, но най-важното е, че пред вас ще се отворят огромни възможности да генерирате и реализирате вашите идеи. Ще можете да използвате подхода за непрекъснато усъвършенстване не само в проекта, но и за себе си, като непрекъснато се развивате като специалист.

Източник: www.habr.com

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