Всім привіт, мене звуть Олександр, і я Data Quality інженер, який займається перевіркою даних щодо їх якості. У цій статті мова піде про те, як я до цього прийшов і чому у 2020 році цей напрямок тестування опинився на гребені хвилі.
Світовий тренд
Сьогоднішній світ переживає чергову технологічну революцію, одним із аспектів якої є використання різноманітними компаніями накопичених даних для розкручування власного маховика продажів, прибутків та піару. Звісно ж, що наявність хороших (якісних) даних, і навіть умілих мізків, які зможуть їх робити гроші (правильно обробити, візуалізувати, побудувати моделі машинного навчання тощо.), стали сьогодні ключем до успіху багатьом. Якщо 15-20 років тому щільною роботою з накопиченням даних та їх монетизацією займалися в основному великі компанії, то сьогодні це доля практично всіх розсудливих.
У зв'язку з цим кілька років тому всі портали, присвячені пошуку роботи по всьому світу, стали переповнюватися вакансіями Data Scientists, тому що всі були впевнені, що, отримавши собі в штат такого фахівця, можна побудувати супермодель машинного навчання, передбачити майбутнє та зробити «квантовий» стрибок» для компанії. Згодом люди зрозуміли, що такий підхід майже ніде не працює, оскільки далеко не всі дані, які потрапляють до рук таких фахівців, придатні для навчання моделей.
І почалися запити від Data Scientists: "Давайте купимо ще даних у цих і у тих. ...", "Нам не вистачає даних ...", "Потрібно ще трохи даних і бажано якісних ...". Грунтуючись цих запитах, стали вибудовуватися численні взаємодії між компаніями, які мають тим чи іншим набором даних. Природно, це зажадало технічної організації цього процесу — приєднатися до джерела даних, викачати їх, перевірити, що вони завантажені в повному обсязі тощо. 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 на одному з проектів.
Суть проекту — реалізувати платформу для підготовки даних для навчання на основі моделей машинного навчання. Замовником була велика фармацевтична компанія зі США. Технічно це був кластер , що піднімається інстансах, з кількома мікросервісами і проектом компанії EPAM, що лежить в основі Open Source , адаптованим під потреби конкретного замовника (зараз проект перероджений у ). ETL-процеси були організовані за допомогою і переміщали дані з системи замовника в Букетів. Далі на платформу деплоївся докер образ моделі машинного навчання, яка навчалася на нових даних і за 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