Всем привет, меня зовут Александр, и я Data Quality инженер, который занимается проверкой данных на предмет их качества. В этой статье речь пойдёт о том, как я к этому пришёл и почему в 2020 году это направление тестирования оказалось на гребне волны.
![](https://habrastorage.org/webt/ih/ud/j3/ihudj3trmlhuvsi5m7hdiq_xyro.png)
Сегодняшний мир переживает очередную технологическую революцию, одним из аспектов которой является использование всевозможными компаниями накопленных данных для раскрутки собственного маховика продаж, прибылей и пиара. Представляется, что именно наличие хороших (качественных) данных, а также умелых мозгов, которые смогут из них делать деньги (правильно обработать, визуализировать, построить модели машинного обучения и т. п.), стали сегодня ключом к успеху для многих. Если 15-20 лет назад плотной работой с накоплением данных и их монетизацией занимались в основном крупные компании, то сегодня это удел практически всех здравомыслящих.
В связи с этим несколько лет назад все порталы, посвящённые поиску работы по всему миру, стали переполняться вакансиями Data Scientists, так как все были уверены, что, получив себе в штат такого специалиста, можно построить супермодель машинного обучения, предсказать будущее и совершить «квантовый скачок» для компании. Со временем люди поняли, что такой подход почти нигде не работает, так как далеко не все данные, которые попадают в руки такого рода специалистам, пригодны для обучения моделей.
И начались запросы от Data Scientists: «Давайте купим ещё данных у этих и у тех.…», «Нам не хватает данных...», «Нужно ещё немного данных и желательно качественных...». Основываясь на этих запросах, стали выстраиваться многочисленные взаимодействия между компаниями, владеющими тем или иным набором данных. Естественно, это потребовало технической организации этого процесса — подсоединиться к источнику данных, выкачать их, проверить, что они загружены в полном объёме и т. п. Количество таких процессов стало расти, и на сегодняшний день мы получили огромную потребность в другого рода специалистах — Data Quality инженерах — тех кто следил бы за потоком данных в системе (data pipelines), за качеством данных на входе и на выходе, делал бы выводы об их достаточности, целостности и прочих характеристиках.
Тренд на Data Quality инженеров пришёл к нам из США, где в разгар бушующей эры капитализма никто не готов проигрывать битву за данные. Ниже я представил скриншоты с двух самых популярных сайтов поиска работы в США: www.monster.com и www.dice.com — на которых отображены данные по состоянию на 17 марта 2020 года по количеству размещенных вакансий полученных, по ключевым словам: Data Quality и Data Scientist.
www.monster.com
www.dice.com
Очевидно, что эти профессии никоим образом не конкурируют друг с другом. Скриншотами я просто хотел проиллюстрировать текущую ситуацию на рынке труда в плане запросов на Data Quality инженеров, которых сейчас требуется сильно больше, чем Data Scientists.
В июне 2019 года EPAM, реагируя на потребности современного ИТ-рынка, выделил Data Quality направление в отдельную практику. Data Quality инженеры в ходе своей повседневной работы управляют данными, проверяют их поведение в новых условиях и системах, контролируют релевантность данных, их достаточность и актуальность. При всём при этом, в практическом смысле Data Quality инженеры действительно немного времени посвящают классическому функциональному тестированию, НО это сильно зависит от проекта (пример я приведу далее).
Обязанности Data Quality инженера не ограничиваются только рутинными ручными/автоматическими проверками на «nulls, count и sums» в таблицах БД, а требуют глубокого понимания бизнес нужд заказчика и, соответственно, способностей трансформировать имеющиеся данные в пригодную бизнес-информацию.
![](https://habrastorage.org/webt/k0/de/ed/k0deedq6qnauxrdpsrdilu8joz0.png)
Для того чтобы наиболее полно себе представить роль такого инженера, давайте разберёмся, что же такое Data Quality в теории.
Data Quality — один из этапов Data Management (целый мир, который мы оставим вам на самостоятельное изучение) и отвечает за анализ данных по следующим критериям:
![](https://habrastorage.org/webt/qb/jo/q8/qbjoq8tzh7y621hukdm_zw640li.png)
Думаю, не стоит расшифровывать каждый из пунктов (в теории называются «data dimensions»), они вполне хорошо описаны на картинке. Но сам процесс тестирования не подразумевает строгое копирование этих признаков в тест-кейсы и их проверку. В 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».
![](https://habrastorage.org/webt/af/1u/ga/af1ugatlnsdvuz2xnvhotb8dwwo.png)
Такого рода иллюстрации составляет ежегодно один из известных венчурных капиталистов Matt Turck, выходец из разработки ПО. Вот ссылка на его блог и фирму венчурного капитала, где он работает партнёром.
Особенно быстро я профессионально рос, когда я был единственным тестировщиком на проекте, или, по крайней мере, в начале проекта. Именно в такой момент приходится отвечать за весь процесс тестирования, и у тебя нет возможности отступить, только вперёд. Поначалу это пугало, однако теперь мне очевидны все плюсы такого испытания:
По мере разрастания проекта в 100% случаев я становился наставником для вновь пришедших на него тестировщиков, обучал их и передавал те знания, которым научился сам. При этом, в зависимости от проекта, я не всегда получал от руководства специалистов по авто тестированию высочайшего уровня и была необходимость либо обучать их автоматизации (для желающих), либо создавать инструменты для использования ими в повседневных активностях (инструменты генерации данных и их загрузки в систему, инструмент для проведения нагрузочного тестирования/тестирования стабильности «по-быстренькому» и т.п.).
К сожалению, в силу обязательств о неразглашении я не могу подробно рассказывать о проектах, на которых я работал, однако приведу примеры типичных задач Data Quality Engineer на одном из проектов.
Суть проекта — реализовать платформу для подготовки данных для обучения на их основе моделей машинного обучения. Заказчиком была крупная фармацевтическая компания из США. Технически это был кластер Kubernetes, поднимающийся на AWS EC2 инстансах, с несколькими микросервисами и лежащим в основе Open Source проектом компании EPAM — Legion, адаптированным под нужды конкретного заказчика (сейчас проект перерожден в odahu). ETL-процессы были организованы при помощи Apache Airflow и перемещали данные из SalesForce системы заказчика в AWS S3 Buckets. Далее на платформу деплоился докер образ модели машинного обучения, которая обучалась на свежих данных и по REST API интерфейсу выдавала предсказания, интересующие бизнес и решающие конкретные задачи.
Визуально всё выглядело примерно так:
![](https://habrastorage.org/webt/xx/bw/da/xxbwdai91byoppkfifghv0nuqso.jpeg)
Функционального тестирования на этом проекте было предостаточно, а учитывая скорость разработки фичей и необходимости поддержания темпов релизного цикла (двухнедельные спринты), необходимо было сразу задумываться об автоматизации тестирования самых критичных узлов системы. Большая часть самой платформы с Kubernetes основой покрывалась автотестами, реализованными на Robot Framework + 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 и их валидации, был написан код с использованием boto3 клиента.
Также со стороны заказчика было требование на хранение части данных в одном S3 Bucket’e, части в другом. Для этого также потребовалось писать дополнительные проверки, контролирующие достоверность такой сортировки.
Пример самого обобщённого перечня активностей Data Quality инженера:
При этом основной акцент проверок должен приходиться не только на то, что поток данных в системе в принципе отработал и дошёл до конца (что является частью функционального тестирования), а по большей части на проверку и валидацию данных на предмет соответствия ожидаемым требованиям, выявления аномалий и прочего.
Одной из техник такого контроля за данными может быть организация цепных проверок на каждой стадии обработки данных, так называемый в литературе «data chain» — контроль данных от источника до пункта финального использования. Такого рода проверки чаще всего реализуются за счёт написания проверяющих SQL-запросов. Понятное дело, что такие запросы должны быть максимально легковесными и проверяющими отдельные куски качества данных (tables metadata, blank lines, NULLs, Errors in syntax — другие требуемые проверки атрибуты).
В случае регрессионного тестирования, в котором используются уже готовые (неизменяемые\незначительно изменяемые) наборы данных, в коде автотестов могут храниться уже готовые шаблоны проверки данных на соответствие качеству (описания ожидаемых метаданных таблиц; строчных выборочных объектов, которые могут выбираться случайно в ходе теста, и прочее).
Также в ходе тестирования приходится писать тестовые ETL-процессы, при помощи таких фреймворков как Apache Airflow, Apache Spark или вовсе black-box cloud инструмент типа GCP Dataprep, GCP Dataflow и прочее. Это обстоятельство заставляет тест-инженера погрузиться в принципы работы вышеуказанных инструментов и ещё более эффективно как проводить функциональное тестирование (например, существующих на проекте ETL-процессов), так и использовать их для проверки данных. В частности, для Apache Airflow имеются уже готовые операторы для работы с популярными аналитическими базами данных, например GCP BigQuery. Самый базовый пример его использования уже изложен тут, поэтому не буду повторяться.
Кроме готовых решений, никто не запрещает вам реализовывать свои техники и инструменты. Это не только будет пользой для проекта, но и для самого Data Quality Engineer, который тем самым прокачает свой технический кругозор и навыки кодирования.
Хорошей иллюстрацией последних абзацев про «data chain», ETL и вездесущие проверки является следующий процесс с одного из реальных проектов:
![](https://habrastorage.org/webt/t5/7l/h8/t57lh8l4oqhofb4fzplbxo6yhum.png)
Здесь во входную «воронку» нашей системы попадают разные данные (естественно, нами и подготовленные): валидные, невалидные, смешанные и т. п., потом они фильтруются и попадают в промежуточное хранилище, затем их снова ждёт ряд преобразований и помещение в конечное хранилище, из которого, в свою очередь, и будет производится аналитика, построение витрин данных и поиск бизнес-инсайтов. В такой системе мы, не проверяя функционально работу ETL-процессов, фокусируемся на качестве данных до и после преобразований, а также на выходе в аналитику.
Резюмируя вышесказанное, вне зависимости от мест, где я работал, везде был вовлечён в Data-проекты, которые объединяли следующие черты:
Отмечу, что, занимаясь тестированием в области Data Quality, специалист по тестированию смещает свой профессиональный фокус на код продукта и используемых инструментов.
Кроме того, для себя я выделил следующие (сразу оговорюсь ОЧЕНЬ обобщённые и исключительно субъективные) отличительные черты тестирования в Data (Big Data) проектах (системах) и других направлениях:
![](https://habrastorage.org/webt/bw/hk/r8/bwhkr8xasrhsi_7wlg0u54nlqhi.png)
Data Quality — это очень молодое перспективное направление, быть частью которого означает быть частью некоего стартапа. Попав в Data Quality, вы окунётесь в большое количество современных востребованных технологий, но самое главное — перед вами откроются огромные возможности для генерирования и реализаций своих идей. Вы сможете использовать подход постоянного улучшения не только на проекте, но и для себя, непрерывно развиваясь как специалист.
![](https://habrastorage.org/webt/ih/ud/j3/ihudj3trmlhuvsi5m7hdiq_xyro.png)
Мировой тренд
Сегодняшний мир переживает очередную технологическую революцию, одним из аспектов которой является использование всевозможными компаниями накопленных данных для раскрутки собственного маховика продаж, прибылей и пиара. Представляется, что именно наличие хороших (качественных) данных, а также умелых мозгов, которые смогут из них делать деньги (правильно обработать, визуализировать, построить модели машинного обучения и т. п.), стали сегодня ключом к успеху для многих. Если 15-20 лет назад плотной работой с накоплением данных и их монетизацией занимались в основном крупные компании, то сегодня это удел практически всех здравомыслящих.
В связи с этим несколько лет назад все порталы, посвящённые поиску работы по всему миру, стали переполняться вакансиями Data Scientists, так как все были уверены, что, получив себе в штат такого специалиста, можно построить супермодель машинного обучения, предсказать будущее и совершить «квантовый скачок» для компании. Со временем люди поняли, что такой подход почти нигде не работает, так как далеко не все данные, которые попадают в руки такого рода специалистам, пригодны для обучения моделей.
И начались запросы от Data Scientists: «Давайте купим ещё данных у этих и у тех.…», «Нам не хватает данных...», «Нужно ещё немного данных и желательно качественных...». Основываясь на этих запросах, стали выстраиваться многочисленные взаимодействия между компаниями, владеющими тем или иным набором данных. Естественно, это потребовало технической организации этого процесса — подсоединиться к источнику данных, выкачать их, проверить, что они загружены в полном объёме и т. п. Количество таких процессов стало расти, и на сегодняшний день мы получили огромную потребность в другого рода специалистах — Data Quality инженерах — тех кто следил бы за потоком данных в системе (data pipelines), за качеством данных на входе и на выходе, делал бы выводы об их достаточности, целостности и прочих характеристиках.
Тренд на Data Quality инженеров пришёл к нам из США, где в разгар бушующей эры капитализма никто не готов проигрывать битву за данные. Ниже я представил скриншоты с двух самых популярных сайтов поиска работы в США: www.monster.com и www.dice.com — на которых отображены данные по состоянию на 17 марта 2020 года по количеству размещенных вакансий полученных, по ключевым словам: Data Quality и Data Scientist.
www.monster.com
Data Scientists – 21416 вакансий | Data Quality – 41104 вакансии |
---|---|
![]() |
![]() |
www.dice.com
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
![](https://habrastorage.org/webt/k0/de/ed/k0deedq6qnauxrdpsrdilu8joz0.png)
Для того чтобы наиболее полно себе представить роль такого инженера, давайте разберёмся, что же такое Data Quality в теории.
Data Quality — один из этапов Data Management (целый мир, который мы оставим вам на самостоятельное изучение) и отвечает за анализ данных по следующим критериям:
![](https://habrastorage.org/webt/qb/jo/q8/qbjoq8tzh7y621hukdm_zw640li.png)
Думаю, не стоит расшифровывать каждый из пунктов (в теории называются «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».
![](https://habrastorage.org/webt/af/1u/ga/af1ugatlnsdvuz2xnvhotb8dwwo.png)
Такого рода иллюстрации составляет ежегодно один из известных венчурных капиталистов Matt Turck, выходец из разработки ПО. Вот ссылка на его блог и фирму венчурного капитала, где он работает партнёром.
Особенно быстро я профессионально рос, когда я был единственным тестировщиком на проекте, или, по крайней мере, в начале проекта. Именно в такой момент приходится отвечать за весь процесс тестирования, и у тебя нет возможности отступить, только вперёд. Поначалу это пугало, однако теперь мне очевидны все плюсы такого испытания:
- Ты начинаешь общаться со всей командой как никогда, так как нету никакого прокси для общения: ни тест-менеджера, ни коллег тестировщиков.
- Погружение в проект становится невероятно глубоким, и ты владеешь информацией обо всех компонентах как в общем, так и в подробностях.
- Разработчики не смотрят на тебя как на «того парня из тестирования, который непонятно чем занимается», а скорее, как на равного, производящего невероятную выгоду для команды своими автотестами и предвидением появления багов в конкретном узле продукта.
- Как результат — ты более эффективен, более квалифицирован, более востребован.
По мере разрастания проекта в 100% случаев я становился наставником для вновь пришедших на него тестировщиков, обучал их и передавал те знания, которым научился сам. При этом, в зависимости от проекта, я не всегда получал от руководства специалистов по авто тестированию высочайшего уровня и была необходимость либо обучать их автоматизации (для желающих), либо создавать инструменты для использования ими в повседневных активностях (инструменты генерации данных и их загрузки в систему, инструмент для проведения нагрузочного тестирования/тестирования стабильности «по-быстренькому» и т.п.).
Пример конкретного проекта
К сожалению, в силу обязательств о неразглашении я не могу подробно рассказывать о проектах, на которых я работал, однако приведу примеры типичных задач Data Quality Engineer на одном из проектов.
Суть проекта — реализовать платформу для подготовки данных для обучения на их основе моделей машинного обучения. Заказчиком была крупная фармацевтическая компания из США. Технически это был кластер Kubernetes, поднимающийся на AWS EC2 инстансах, с несколькими микросервисами и лежащим в основе Open Source проектом компании EPAM — Legion, адаптированным под нужды конкретного заказчика (сейчас проект перерожден в odahu). ETL-процессы были организованы при помощи Apache Airflow и перемещали данные из SalesForce системы заказчика в AWS S3 Buckets. Далее на платформу деплоился докер образ модели машинного обучения, которая обучалась на свежих данных и по REST API интерфейсу выдавала предсказания, интересующие бизнес и решающие конкретные задачи.
Визуально всё выглядело примерно так:
![](https://habrastorage.org/webt/xx/bw/da/xxbwdai91byoppkfifghv0nuqso.jpeg)
Функционального тестирования на этом проекте было предостаточно, а учитывая скорость разработки фичей и необходимости поддержания темпов релизного цикла (двухнедельные спринты), необходимо было сразу задумываться об автоматизации тестирования самых критичных узлов системы. Большая часть самой платформы с Kubernetes основой покрывалась автотестами, реализованными на Robot Framework + 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 и их валидации, был написан код с использованием boto3 клиента.
Также со стороны заказчика было требование на хранение части данных в одном S3 Bucket’e, части в другом. Для этого также потребовалось писать дополнительные проверки, контролирующие достоверность такой сортировки.
Обобщённый опыт по другим проектам
Пример самого обобщённого перечня активностей Data Quality инженера:
- Подготовить тестовые данные (валидные\невалидные\большие\маленькие) через автоматизированный инструмент.
- Загрузить подготовленный набор данных в исходный источник и проверить его готовность к использованию.
- Запустить ETL-процессы по обработке набора данных из исходного хранилища в окончательное или промежуточное с применением определённого набора настроек (в случае возможности задать конфигурируемые параметры для ETL-задачи).
- Верифицировать обработанные ETL-процессом данные на предмет их качества и соответствие бизнес-требованиям.
При этом основной акцент проверок должен приходиться не только на то, что поток данных в системе в принципе отработал и дошёл до конца (что является частью функционального тестирования), а по большей части на проверку и валидацию данных на предмет соответствия ожидаемым требованиям, выявления аномалий и прочего.
Инструменты
Одной из техник такого контроля за данными может быть организация цепных проверок на каждой стадии обработки данных, так называемый в литературе «data chain» — контроль данных от источника до пункта финального использования. Такого рода проверки чаще всего реализуются за счёт написания проверяющих SQL-запросов. Понятное дело, что такие запросы должны быть максимально легковесными и проверяющими отдельные куски качества данных (tables metadata, blank lines, NULLs, Errors in syntax — другие требуемые проверки атрибуты).
В случае регрессионного тестирования, в котором используются уже готовые (неизменяемые\незначительно изменяемые) наборы данных, в коде автотестов могут храниться уже готовые шаблоны проверки данных на соответствие качеству (описания ожидаемых метаданных таблиц; строчных выборочных объектов, которые могут выбираться случайно в ходе теста, и прочее).
Также в ходе тестирования приходится писать тестовые ETL-процессы, при помощи таких фреймворков как Apache Airflow, Apache Spark или вовсе black-box cloud инструмент типа GCP Dataprep, GCP Dataflow и прочее. Это обстоятельство заставляет тест-инженера погрузиться в принципы работы вышеуказанных инструментов и ещё более эффективно как проводить функциональное тестирование (например, существующих на проекте ETL-процессов), так и использовать их для проверки данных. В частности, для Apache Airflow имеются уже готовые операторы для работы с популярными аналитическими базами данных, например GCP BigQuery. Самый базовый пример его использования уже изложен тут, поэтому не буду повторяться.
Кроме готовых решений, никто не запрещает вам реализовывать свои техники и инструменты. Это не только будет пользой для проекта, но и для самого Data Quality Engineer, который тем самым прокачает свой технический кругозор и навыки кодирования.
Как это работает на реальном проекте
Хорошей иллюстрацией последних абзацев про «data chain», ETL и вездесущие проверки является следующий процесс с одного из реальных проектов:
![](https://habrastorage.org/webt/t5/7l/h8/t57lh8l4oqhofb4fzplbxo6yhum.png)
Здесь во входную «воронку» нашей системы попадают разные данные (естественно, нами и подготовленные): валидные, невалидные, смешанные и т. п., потом они фильтруются и попадают в промежуточное хранилище, затем их снова ждёт ряд преобразований и помещение в конечное хранилище, из которого, в свою очередь, и будет производится аналитика, построение витрин данных и поиск бизнес-инсайтов. В такой системе мы, не проверяя функционально работу ETL-процессов, фокусируемся на качестве данных до и после преобразований, а также на выходе в аналитику.
Резюмируя вышесказанное, вне зависимости от мест, где я работал, везде был вовлечён в Data-проекты, которые объединяли следующие черты:
- Только через автоматизацию можно проверить некоторые кейсы и достичь приемлемого для бизнеса релизного цикла.
- Тестировщик на таком проекте — один из самых уважаемых членов команды, так как приносит огромную пользу каждому из участников (ускорение тестирования, хорошие данные у Data Scientist, выявление дефектов на ранних этапах).
- Неважно на своём железе вы работаете или в облаках — все ресурсы абстрагированы в кластер типа Hortonworks, Cloudera, Mesos, Kubernetes и т. п.
- Проекты строятся на микросервисном подходе, преобладают распределённые и параллельные вычисления.
Отмечу, что, занимаясь тестированием в области Data Quality, специалист по тестированию смещает свой профессиональный фокус на код продукта и используемых инструментов.
Отличительные особенности Data Quality тестирования
Кроме того, для себя я выделил следующие (сразу оговорюсь ОЧЕНЬ обобщённые и исключительно субъективные) отличительные черты тестирования в Data (Big Data) проектах (системах) и других направлениях:
![](https://habrastorage.org/webt/bw/hk/r8/bwhkr8xasrhsi_7wlg0u54nlqhi.png)
Полезные ссылки
- Теория: DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition.
- Тренинг-центр EPAM
- Рекомендуемые материалы для начинающего Data Quality инженера:
- Бесплатный курс на Stepik: Введение в базы данных.
- Курс на LinkedIn Learning: Data Science Foundations: Data Engineering.
- Статьи:
- Видео:
Заключение
Data Quality — это очень молодое перспективное направление, быть частью которого означает быть частью некоего стартапа. Попав в Data Quality, вы окунётесь в большое количество современных востребованных технологий, но самое главное — перед вами откроются огромные возможности для генерирования и реализаций своих идей. Вы сможете использовать подход постоянного улучшения не только на проекте, но и для себя, непрерывно развиваясь как специалист.