Автор этой статьи в блоге Stack Overflow — Data QA Engineer, то есть инженер обеспечения качества данных. По его словам, у него есть друзья, занятые в сфере технологий и разработки ПО, которые не совсем понимают, что такое тестирование данных, зачем оно нужно и как оно вписывается в мир программирования.
Это вполне объяснимо: наука о данных — совершенно новая область, и даже те, кто работает с данными каждый день, должны оставаться открытыми ко всем изменениям в работе. О профессии Data QA Engineer рассказываем к старту курса по Data Engineering.
Чтобы разобраться с тем, как работает тестирование данных, сначала нужно разобраться с тем, что такое инженерия данных.
Инженерия данных и их анализ
Давайте начнём с того, что такое данные. Данные — это агрегированная информация, которая хранится в инструменте для ведения бизнеса. Будет ли это инструмент в виде электронной таблицы или базы данных, зависит от предприятия, но мы начнём именно с этого места, где данные создаются.
Сырые данные в источнике мало кому полезны. Здесь и приходит на помощь инженерия данных. Инженерией данных мы называем процесс получения сырых данных и их превращения в полезные: это извлечение, преобразование, загрузка, то есть Extract, Transform, Load — ETL.
После извлечения данных из источников их можно преобразовать согласно потребностям бизнеса и загрузить в инструменты бизнес-анализа. После этого бизнес-аналитики и финансовые аналитики смогут воспользоваться наборами данных, чтобы создать отчёты, диаграммы и другие метрики по запросу. Именно метрики информируют людей, которые принимают решения.
Преобразование данных
Преобразование данных — это, пожалуй, самый важный момент в инженерии данных. Возьмём пример — розничный бизнес с несколькими магазинами. В старых магазинах используется устаревшая система точек продаж (POS), а в новых — более современная система.
В каждом типе POS-системы транзакции записываются и хранятся по-разному и в разных базах данных. Если владелец бизнеса хочет видеть еженедельный отчёт о продажах, это потребует агрегирования транзакций из обеих систем.
Иными словами, необходим процесс преобразования, который позволит получить информацию о транзакциях из каждой системы и свести разрозненные системы воедино таким образом, чтобы они обрели смысл. Здесь возникнут вопросы о данных транзакции и о связи этих данных с отчётом продаж. Как в старой и новой системах учитываются возвраты, если сравнивать их с фактической продажей?
Посмотрим внимательнее. Старая POS хранит всё в базе данных, которая несовместима с базой данных новой POS, поэтому нет возможности просто объединить информацию. Прежде чем транзакции можно будет свести воедино, необходим этап преобразования данных. Напомню, что владелец бизнеса просто хочет получать агрегированную информацию о продажах в виде отчёта.
Потребность в отчёте о продажах и объединение разрозненных систем, — вот два важнейших элемента, которые определяют смысл набора данных. В нашем примере мы искали сначала определение "продаж", а позже нам понадобился отчёт по ним. Как вы понимаете, туманное и субъективное определение продаж бизнесом может сильно затруднить тестирование данных.
Измерение качества данных
Определить качество данных без какого-либо эталона измерения невозможно. Как правило, в рамках процессов тестирования эталоном являются отчётные показатели. Возникает вопрос: как найти нечто измеримое, чтобы проверить продукт с точки зрения данных?
Шесть измерений качества данных
Текущий отраслевой стандарт валидации [проверки корректности] данных — тестирование моделей данных при помощи шести измерений качества данных, конвейеров, архитектуры и многого другого. Эти шесть измерений впервые определены в документе «Шесть основных измерений для оценки качества данных». Документ написан британским отделением Ассоциации управления данными (DAMA) в 2013 году.
Шесть измерений — это в основном согласованная серия проверочных показателей. Эти показатели используются для оценки качества любого набора данных и помогают инженерам по качеству данных и Data-инженерам создавать измеримые показатели валидности, которые можно улучшить. Вот эти метрики:
Согласованность. Если данные копируются в несколько баз данных, систем, таблиц и отчётов, они должны оставаться неизменными, что делает их согласованными. Например, текущий почтовый индекс клиента всегда должен состоять из пяти цифр (девяти, если вы используете ZIP+4), независимо от того, где обнаружены данные.
Точность. Возможно, самый туманный показатель качества данных — это то, насколько точно они отражают реальное явление или объект. Пример: в таблице есть столбец, представляющий общую сумму в долларах по всем транзакциям клиента. Другой столбец представляет общую сумму транзакций. Значения этих столбцов должны чётко прослеживаться до источников, где возможно доказать, что итоги соответствуют транзакциям, которые имели место.
Корректность. В любом конкретном поле набора данных, скорее всего, есть требование к типу данных. Вы не ожидаете увидеть числа в поле state, значения которого ограничены двухбуквенными обозначениями штатов США: NY, CA или IL. Целое число в этом поле — некорректные данные.
Уникальность. Для каждой уникальной записи, ожидаемой в базе данных, должно существовать поле, которое уникально идентифицирует каждую запись, например номер счёта клиента в случае базы данных интернет-магазинов. Уникальность номера счёта может иметь решающее значение для идентификации повторяющихся операций по счёту одного клиента.
Полнота. Данные являются неполными, если в них отсутствуют критически важные поля. Например, в записи о финансовой транзакции, возможно, для каждой операции должна быть метка времени. Если её нет, набор данных о транзакциях неполный.
Своевременность. Своевременность данных определяется потребностями бизнеса. Например, если набор данных необходимо обновлять ежедневно, метрика тестирования своевременности набора данных также будет означать "ежедневно".
Тестирование и проверка любого набора данных должны охватывать каждое из этих измерений. Особенно это касается автоматизированных модульных тестов, но об этом позже. Если вы хотите погрузиться в тему, прочитайте эту замечательную статью.
Тестирование данных в процессе инженерии данных
Теперь, когда мы знаем о шести измерениях качества данных, о том, как инженерия данных работает в целом, а также знаем о критической важности бизнес-определений потребности в данных, задача состоит в том, чтобы собрать всё это вместе и составить план тестирования.
Инженеры по качеству данных находятся в самом центре инженерии данных; мы поддерживаем техническую работу инженеров по предоставлению набора данных и проверяем данные вместе с бизнес-аналитиками.
Типы QA-тестов данных
В тестировании ПО есть несколько распространённых типов тестов качества. Эти тесты выявляют ошибки, подтверждают работоспособность компонентов и исследуют ожидаемое поведение программного обеспечения. Такие тесты полезны и в тестировании данных. Если вы хоть немного знакомы с ними, значит, вы уже кое-что понимаете в тестировании данных. Это
Модульные тесты — это небольшие тесты, встроенные в код моделирования данных, чтобы определить небольшие точки останова внутри критических блоков кода, которые необходимы для обеспечения базовой функциональности. К примеру, возможно, есть столбец, в данных которого не должно быть значений NULL. Быстрый модульный тест может проверить поле.
Интеграционные тесты проверяют работу совокупности частей программы или конвейера, а не какой-то одной части. В примере с конвейером данных интеграционные тесты проверяют, что весь процесс ETL успешно выполняется от начала до конца.
Дымовые тесты — это быстрые тесты для проверки наиболее важных и обычных частей конвейера данных на наличие сбоев. Термин возник при тестировании компьютеров, когда первым испытанием было включить машину в сеть и проверить, не идёт ли из неё дым. Как вы понимаете, если появлялся дым, инженеры выключали машину и пробовали снова.
Регрессионные тесты — это серия тестов для проверки основных операций программы. Набор тестов рассматривает стандартные функциональные части кода, которые никогда не должны изменяться, поэтому тесты называют регрессионными. Обычно это основной набор, который выполняют перед выпуском продукта. В смысле данных регрессия обычно охватывает критически важные преобразования.
Тестирование новой функциональности — тесты для проверки новых компонентов («функций»), которые были добавлены в программу поверх её текущих операций. Они добавляются в наборы регрессионных тестов, если новые функции критичны для производственных релизов и должны оставаться неизменными.
Это обычные типы тестов, которые многие команды разработчиков ПО используют регулярно. И они могут применяться в тестировании данных.
Модульные тесты — секретное оружие валидации
Data QA Engineer должен повышать ценность работы инженеров для бизнеса и предоставлять полезную обратную связь. Data QA почти всегда начинается с ручного тестирования, особенно на предприятиях с устаревшими базами и технологиями хранилищ данных.
На ноутбуке инженера по контролю качества данных, скорее всего, будет несколько сотен SQL-скриптов. Но такое ручное тестирование по-прежнему должно проверять шесть аспектов качества данных, не становясь узким местом производственных релизов. При этом автоматизация тестирования данных вполне возможна, особенно когда речь идёт о модульных тестах и ассертах (ассерты — это тесты, которые проверяют предположения).
По моему опыту, одна из важнейших задач инженера по контролю качества данных заключается в распространении информации о модульных тестах, встроенных в конвейер данных.
Модульные тесты, реализованные инженером данных во время разработки преобразования данных, могут выявить ошибки в данных ещё до того, как инженеры по контролю качества данных увидят набор данных.
Data Engineer не привыкли к модульным тестам: это больше практика разработки ПО, но я не единственный, кто считает, что инженерии данных нужно больше модульного тестирования в плане культуры. Популярные фреймворки с открытым исходным кодом, к примеру data build tool (dbt), имеют встроенные модульные тесты, которые могут предотвратить проблемы с полнотой, уникальностью и своевременностью данных. Другие инструменты проверки с открытым исходным кодом, такие как Great Expectations, размещают поверх конвейера данных набор модульных тестов-ассертов.
Автоматизация
Автоматизация в мире качества данных — важнейший аспект. Например, используя сочетание модульного тестирования и тестирования полноты данных, Data QA Engineer могут написать небольшой, быстрый автоматизированный тест, который проверяет наличие любых значений NULL в критически важном поле данных.
Чем больше в вашем конвейере данных автоматизированных тестов, которые различными способами проверяют критические параметры качества данных, тем меньше работы приходится выполнять Data Engineer.
Что, если бы вместо генерации таблицы, просмотра её с помощью SQL каждый раз и подключения к базе данных, инженер по данным имел встроенный набор регрессионных тестов, который выполнял бы ежедневные проверки за него? Такими видами автоматизации и разработки тестов и заняты Data QA Engineer.
Итоги
Тестирование данных — это уникальная область, она развивается и изменяется каждый день. Общепризнанных стандартов качества данных не так много, и даже такие стандарты, как шесть измерений качества данных, вызывают споры. Всё больше областей Data Science, таких как машинное обучение и искусственный интеллект, развиваются и создают новые способы проверки точности, согласованности, полноты и других критериев качества данных.
Качество данных сегодня в значительной степени зависит от субъективного значения набора данных, а также от потребностей людей на том конце конвейера данных. Этот факт затрудняет поиск эталонов тестирования и улучшения качества данных, но можно воспользоваться знаниями о полезных типах тестов, а также знаниями об измерениях качества данных. Чем больше мы будем понимать, как использовать данные, тем активнее будут развиваться метрики качества данных, и тем лучше мы будем понимать тестирование данных.
Продолжить изучение Data Engineering и Data Science вы сможете на наших курсах:
Профессии и курсы
Data Science и Machine Learning
Python, веб-разработка
Мобильная разработка
Java и C#
От основ — в глубину
А также
