Здравейте, аз се казвам Александър и съм инженер по качество на данните, който се занимава с проверка на данните за тяхното качество. В тази статия ще говоря за пътя, по който преминах, и защо през 2020 година това направление на тестването стана особено актуално.
Глобална тенденция
Днешният свят преживява поредна технологична революция, един от аспектите на която е използването на натрупаните данни от различни компании за увеличаване на техния оборот, печалби и публичност. Ясно е, че именно наличието на добри (качествени) данни, както и на способни умове, които могат да ги превърнат в печалба (правилна обработка, визуализация, изграждане на модели за машинно обучение и т.н.), днес са ключът към успеха за много компании. Ако преди 15-20 години плътната работа с натрупването на данни и тяхната монетизация беше основно запазена територия на големите компании, днес това е приоритет практически за всички, които са в здравия разум.
В тази връзка, преди няколко години, всички портали за търсене на работа в света започнаха да се препълват с обяви за работа за Data Scientists, тъй като всички бяха убедени, че като наемат такъв специалист, могат да изградят супермодел за машинно обучение, да предскажат бъдещето и да направят "квантов скок" за компанията. С времето хората осъзнаха, че такъв подход почти никъде не работи, тъй като не всички данни, които попадаха в ръцете на такива специалисти, са подходящи за обучение на модели.
И започнаха запитвания от Data Scientists: "Нека купим още данни от тези и онези...", "Няма ни достатъчно данни...", "Необходими са ни още малко данни и за предпочитане качествени...". Въз основа на тези запитвания започнаха да се изграждат множество взаимодействия между компании, притежаващи различни набори от данни. Естествено, това изискваше техническа организация на процеса — свързване с източника на данни, извличане на данните, проверка на тяхното цялостно зареждане и т.н. Броят на тези процеси започна да нараства, и днес наблюдаваме огромна нужда от друг тип специалисти — инженери по качество на данните — тези, които да следят потока от данни в системата (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 Quality — един от етапите на управлението на данни (цял свят, който ще оставим на вас за самостоятелно изследване) и отговаря за анализа на данните по следните критерии:
Мисля, че не е нужно да разшифроваме всеки от пунктов (теоретично се наричат „data dimensions“), те са сравнително добре описани на картинката. Но самият процес на тестване не означава строго копиране на тези характеристики в тестовите случаи и тяхната проверка. В Data Quality, както и в всяка друга форма на тестване, е необходимо най-вече да се опираме на изискванията за качество на данните, съгласувани с участниците в проекта, вземащи бизнес решения.
В зависимост от проекта инженера по Data Quality може да изпълнява различни функции: от обикновен тестер-автоматизатор с повърхностна оценка на качеството на данните до човек, провеждащ дълбоко профилиране по гореспоменатите характеристики.
Много подробно описание на процесите Data Management, Data Quality и свързаните е отлично описано в книгата на име „DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition“. Препоръчвам тази книга като въведение в тази тема (линк към нея ще намерите в края на статията).
Моята история
В IT индустрията преминах пътя от Junior тестер в продуктовите компании до Lead Data Quality Engineer в компанията EPAM. Вече около две години работа като тестер бях напълно убеден, че съм извършил абсолютно всички видове тестване: регресионно, функционално, стресово, на стабилност, сигурност, UI и т.н. — и пробвах много инструменти за тестване, работейки с три програмни езика: Java, Scala, Python.
Оглядайки се назад, разбирам защо наборът на моите професионални умения се оказа толкова разнообразен — участвах в проекти, свързани с работа с данни, големи и малки. Именно това ме доведе в света на множество инструменти и възможности за растеж.
За да оцените многообразието от инструменти и възможности за придобиване на нови знания и умения, е достатъчно просто да погледнете картинката по-долу, на която са изобразени най-популярните от тях в света на „Data & AI“.
Този вид илюстрации се съставят ежегодно от един известен рисков капиталист Matt Turck, израснал в разработката на софтуер. Ето в неговия блог и , където работи като партньор.
Особено бързо професионално напредвах, когато бях единственият тестер в проекта, или поне в началото на проекта. Именно в такъв момент трябва да поемеш отговорност за целия процес на тестване, без възможност за отстъпление, само напред. Първоначално това беше плашещо, но сега са ми ясни всички предимства на това изпитание:
- Започваш да комуникираш с целия екип както никога досега, тъй като няма прокси за общуване: нито тест-мениджър, нито колеги тестери.
- Потапянето в проекта става невероятно дълбоко и знаеш информация за всички компоненти както в общи линии, така и в детайли.
- Разработчиците не те гледат като "онзи човек от тестването, който не се знае какво прави", а по-скоро като равен, който носи невероятна полза за екипа със своите автотестове и предвиждането на възникването на бъгове в конкретен компонент на продукта.
- В резултат — ти си по-ефективен, по-квалифициран, по-търсен.
С разрастването на проекта в 100% от случаите ставам ментор за новите тестери, обучавам ги и предавам знанията, които сам съм придобил. В зависимост от проекта не винаги получавам високо квалифицирани специалисти по автоматизирано тестване от ръководството и понякога е необходимо да обучавам желаещите или да създавам инструменти, които да ползват в ежедневието си (инструменти за генериране на данни и тяхното зареждане в системата, инструмент за провеждане на натоварочно тестиране/тестиране на стабилността „бързо“ и т.н.)
Пример за конкретен проект
За съжаление, поради задълженията за неразгласяване не мога да говоря подробно за проектите, на които съм работил, но ще дам примери за типични задачи на Data Quality Engineer в един от проектите.
Същността на проекта е да се реализира платформа за подготовка на данни за обучение на базата на модели за машинно обучение. Клиентът е голяма фармацевтична компания от САЩ. Технически это е клъстер , разположен на инстанции, с няколко микросервиза и лежащ в основата на Open Source проекта на компанията EPAM — , адаптиран спрямо нуждите на конкретния клиент (сега проектът се е трансформирал в ). ETL процесите бяха организирани с помощта на и прехвърляха данни от системата на клиента в Buckets. След това на платформата беше деплойнат Docker образ на модел за машинно обучение, който се обучаваше на актуални данни и чрез REST API интерфейс предоставяше прогнози, които интересуваха бизнеса и решаваха конкретни задачи.
Визуално всичко изглеждаше приблизително така:
Функционалното тестване по този проект беше в изобилие, и предвид скоростта на разработване на нови функции и необходимостта от поддържане на темповете на релизите (двуседмични спринтове), беше нужно веднага да мислим за автоматизация на тестването на най-критичните възли на системата. Голямата част от самата платформа с основа Kubernetes беше покрита с автотестове, реализирани на + Python, но поддържането и разширяването им също беше необходимо. Освен това, за удобство на клиента, беше създаден GUI за управление на моделите на машинно обучение, деплойнати на клъстера, както и възможност да се укаже откъде и накъде е необходимо да се прехвърлят данни за обучението на моделите. Това обширно допълнение доведе до разширяване на автоматизираните функционални проверки, които основно се извършваха чрез REST API повиквания и малко end-2-end UI тестове. Приблизително по средата на всичко това към нас се присъедини ръчен тестер, който великолепно се справяше с приемочното тестване на версиите на продукта и комуникацията с клиента относно приемането на новия релиз. Освен това, благодарение на появата на новия специалист, успяхме да документираме нашата работа и да добавим няколко много важни ръчни проверки, които беше трудно веднага да автоматизираме.
И накрая, след като постигнахме стабилност на платформата и GUI интерфейса над нея, започнахме изграждането на ETL pipelines с помощта на Apache Airflow DAGs. Автоматизираната проверка на качеството на данните се осъществяваше чрез написването на специализирани Airflow DAGs, които проверяваха данните според резултатите от ETL процеса. В рамките на този проект имахме късмет, тъй като клиентът ни предостави достъп до анонимизирани набори от данни, върху които използвахме тестовете. Проверките на данните бяха на ред по ред за съответствие с типовете, наличие на повредени данни, общият брой записи преди и след, и сравнение на извършените от ETL процеса преобразования по агрегиране, промяна на имената на колоните и други. Освен това тези проверки бяха мащабирани на различни източници на данни, освен SalesForce, също така и на MySQL.
Проверки за крайното качество на данните бяха осъществявани вече на ниво S3, където те бяха съхранявани и готови за използване за обучение на модели за машинно обучение. За извличане на данните от крайния CSV файл, намиращ се на S3 Bucket и тяхната валидация, беше написан код, използващ .
Също така от страна на клиента имаше изискване част от данните да се съхраняват в един S3 Bucket, а друга част в друг. За това също така беше необходимо да се пишат допълнителни проверки, контролиращи точността на такава сортировка.
Обобщен опит по други проекти
Пример за най-общия списък от дейности на Data Quality инженера:
- Подгответе тестови данни (валидни, невалидни, големи, малки) чрез автоматизирано средство.
- Заредете подготвените набори от данни в изходния източник и проверете готовността им за употреба.
- Стартирайте ETL процесите по обработка на набора от данни от изходното хранилище в крайно или междинно с прилагането на определен набор от настройки (в случай, че е възможно да се зададат конфигурируеми параметри за ETL задачата).
- Верифицирайте обработените данни от ETL процеса по отношение на тяхното качество и съответствие с бизнес изискванията.
При това основният акцент в проверките трябва да бъде не само върху това дали потокът от данни в системата е обработен и е достигнал края (което е част от функционалното тестване), а главно върху проверката и валидирането на данните за съответствие с очакваните изисквания, откриване на аномалии и други.
Инструменти
Една от техниките за контрол на данните може да бъде организирането на вериги от проверки на всяка фаза на обработка на данните, така наречената в литературата «data chain» — контрол на данните от източника до финалното им използване. Такъв тип проверки най-често се реализират чрез написване на SQL заявки за проверка. Очевидно е, че тези заявки трябва да са максимално леки и да проверяват отделни аспекти на качеството на данните (метаданни на таблици, празни редове, NULL стойности, грешки в синтаксиса — други необходими проверки на атрибути).
При регресионното тестване, в което се използват вече готови (неподменяеми или незначително изменяеми) набори от данни, в кода на автоматичните тестове могат да бъдат съхранявани вече готови шаблони за проверка на данните за съответствие с качеството (описания на очакваните метаданни на таблиците; строчни обектни избори, които могат да бъдат случайно избрани по време на теста и други).
Също така по време на тестването се налага да се пишат тестови ETL процеси, с помощта на фреймуърк като Apache Airflow, или напълно black-box облачен инструмент като , и други. Тази обстоятелство налага тестовия инженер да се запознае с принципите на работа на споменатите инструменти и да проведе функционално тестване (например на съществуващите 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 — това е много млада и перспективна област, а да бъдеш част от нея значи да бъдеш част от някакъв стартъп. Влезе ли в Data Quality, ще се потопите в редица съвременни и търсени технологии, но най-важното е, че пред вас ще се открият огромни възможности за генериране и реализиране на вашите идеи. Ще можете да прилагате подхода на постоянното усъвършенстване не само в проекта, но и за себе си, непрекъснато развивайки се като специалист.
Източник: habr.com
