Home

Автор: Корисса Е. Оури (Corissa E. Haury)
Оригинал статьи
Перевод: Ольга Алифанова

Когда меня спрашивают, чем я зарабатываю на жизнь, я отвечаю, что я инженер по управлению качеством данных. Люди не особо понимают, что это значит. Я пытаюсь объяснить, что тестирую данные - зачастую это не помогает. У меня есть друзья в технических отделах и отделах разработки, которые не очень понимают, что такое тестирование данных, почему это необходимо, и где его место в мире программирования. Это и понятно, так как аналитика данных - свеженькая область, и даже те, кто ежедневно работает с данными, должны быть готовыми к тому, что что угодно в нашей работе может измениться в любой момент.

Чтобы понимать, как работает тестирование данных, нужно вначале разобраться, что такое дата-инжиниринг. Затем мы углубимся в качество данных и то, как оно измеряется.

Инжиниринг и анализ данных

Чтобы понимать, где начинается тестирование данных, надо разобраться, как данные проектируются, и что отличает их от других видов программирования вроде разработки ПО. Начнем с того, что такое данные. Данные - это некий вид агрегированной информации, содержащейся в бизнес-инструменте. Неважно, таблица это или база данных - это зависит от бизнеса, но мы начинаем с исходной точки, где хранятся данные.

Сырые данные довольно-таки бесполезны в качестве источника, и тут вступает в игру инжиниринг данных. В ходе дата-инжиниринга мы получаем эти данные и делаем их полезными, извлекая их, трансформируя, загружая - еще это называется ETL (Extract, Transform, Load). Как только данные извлечены из источников, их можно трансформировать согласно нуждам бизнеса, и загружать в инструменты бизнес-анализа. Теперь у бизнес-аналитиков и финансовых аналитиков есть возможность использовать наборы данных для создания отчетов, графиков и других необходимых для принятия бизнес-решений метрик.

Т - Трансформация

Трансформация - это, возможно, наиболее критическая точка в процессе дата-инжиниринга. Возьмем для примера розничный бизнес с несколькими магазинами. Допустим, там есть магазины постарше, использующие устаревшую систему точки продаж (POS), в то время как более новые магазины пользуются более современной системой. Транзакции записываются и хранятся в каждом типе POS-системы по-разному в разных базах данных. Если владелец бизнеса хочет увидеть еженедельный отчет о продажах, это потребует агрегации транзакций из обеих систем.

Чтобы этого добиться, необходим трансформационный процесс, получающий информацию о транзакциях из каждой POS-системы и объединяющий ее осмысленным образом. Более того, быстро возникнут вопросы о данных транзакций и их отношению к отчету о продажах. Задам всего один: как в каждой системе считаются возвраты по отношению к актуальным продажам?

Разовьем этот пример далее. Магазины с оригинальной POS-системой хранят все в типе базы данных, несовместимым с базой данных более новой POS-системы, поэтому просто объединить информацию нельзя. Теперь стадия трансформации должна включать некую конверсию данных, прежде чем можно будет объединить транзакции. По сути, владелец бизнеса просто хочет получить агрегированную информацию в отчете, и поначалу это выглядело простой задачей.

Нужда в данных (отчете о продажах) и техническая работа, требующаяся для превращения данных в нечто осмысленное (объединение разделенных систем) — это два критических элемента, определяющих набор данных. В нашем случае мы разбирались, что такое “продажи”, а затем нам понадобился отчет о них. Как можно видеть, туманное и субъективное бизнес-определение может сильно усложнить тестирование данных.

Измерение качества данных

Теперь мы имеем представление о том, что такое данные и дата-инжиниринг. Нельзя определить, что такое качество данных, без некоторого стандарта, относительно которого качество будет измеряться. Как правило, в мире тест-процессов этот стандарт — это набор метрик с отчетными данными. Как же найти что-то измеримое, чтобы валидировать продукт в мире данных?

Шесть измерений качества данных

Современный индустриальный стандарт валидации данных — это использование некоторой формы шести измерений качества данных для тестирования моделей данных, процессов, архитектуры, и т. п. Эти метрики качества данных были исходно определены в работе о качестве данных “Шесть основных измерений для оценки качества данных”, написанной британским подразделением Ассоциации менеджмента данных (DAMA) в 2013 году. Шесть измерений — это широко признанная серия метрик валидации, использующаяся для исследования качества любого набора данных. Они помогают инженерам по качеству и дата-инженерам создавать измеримые метрики валидации, относительно которых данные можно улучшать.

Шесть измерений - это:

• Постоянство. Если данные копируются из нескольких баз, систем, таблиц и отчетов, они должны оставаться такими же, обеспечивая постоянство. К примеру, текущий почтовый индекс покупателя должен всегда быть пятизначным (девятизначным, если используется ZIP+4) вне зависимости от того, где вы его нашли.
• Точность. Возможно, это самая туманная метрика качества данных. Точность - это степень, до которой исследуемые данные описывают реальное событие или объект. Допустим, у нас есть колонка, в которой хранится агрегированная сумма в долларах для всех транзакций покупателя, а также колонка, в которой суммируются все транзакции. Каждое из этих значений должно быть возможно отследить до его источника, а также доказать, что суммы точно соответствуют реально осуществленным транзакциям.
• Валидность. Для любого поля в наборе данных, вероятно, существует некое требование к типу данных. Мы не ожидаем увидеть цифры в поле штата, ограниченном двухбуквенными аббревиатурами штатов США вроде NY, CA или IL. Если бы в этом поле было число — это бы нарушило валидность данных.
• Уникальность. Для каждой уникальной записи в базе данных ожидается наличие поля, которое уникально определяет каждую запись - например, номер учетной записи пользователя в базе онлайн-магазина. Уникальность номера учетной записи может быть критически важна для идентификации повторяющихся транзакций у одной и той же учетки.
• Полнота. Дата считается неполной, если в ней отсутствуют критически важные поля. Возможно, в записи о бизнес-транзакции необходимо наличие временной отметки. Если она отсутствует, набор данных о транзакциях считается неполным.
• Своевременность. Что ожидается от получения данных для каждого отчета? Своевременность данных определяется нуждами бизнеса. К примеру, если набор данных должен обновляться ежедневно, тест-метрика своевременности для этого набора данных также становится ежедневной.

Тесты данных и их валидация должны покрывать все эти измерения для каждого набора данных. Особенно это касается автоматизированных юнит-тестов, но к этому мы вернемся позже. Если вас интересует более подробная информация о шести измерениях качества данных, прочитайте этот прекрасный текст в Towards Data Science.

Тестирование данных в процессе инжиниринга

Мы разобрались в шести измерениях качества данных, в том, как в целом работает инжиниринг данных, и в критической важности бизнес-определений нужды в данных. Теперь наша задача - объединить все это и создать тест-план. Инженеры по качеству данных — это сердце процесса дата-инжиниринга; они помогают техническим инженерам предоставить запрошенный набор данных, и работают с бизнес-аналитиками, чтобы валидировать эти данные.

Типы тестов качества данных

В мире тестирования существует несколько распространенных типов тестов качества, идентифицирующих баги, подтверждающих работу компонентов, и исследующих ожидаемое поведение приложения. Эти типы тестов все еще критически важны и в мире тестирования данных, поэтому, если вы уже знаете об этих тест-категориях, то уже что-то понимаете в тестировании данных.

Типы тестов включают, но не ограничиваются:

• Юнит-тесты. Небольшие тесты, встроенные в моделирующий данные код, которые используются для идентификации маленьких разрывов между критическими блоками кода, которые необходимы для базовой функциональности. К примеру, возможно, есть колонка, в которой не должно быть NULL-данных. Быстрый юнит-тест проверит поле на наличие NULL и убедится, что такие значения там отсутствуют.
• Интеграционные тесты. Это тесты, которые рассматривают работу нескольких компонентов программы или процесса, а не один из них. Пример, связанный с данными: интеграционные тесты проверяют, что весь ETL-процесс успешно выполняется от старта до финиша.
• Смоук-тесты. Быстрые тесты, которые используются для эффективной проверки наиболее важных и, как правило, общих частей процесса работы с данными. Термин зародился в тестировании компьютерного железа - первым тестом было подключение машины к сети и поиск дыма от механических компонентов. Если дыма не было, железо проходило тест. Если же дым был… Как можно представить, машину выключали и пробовали снова.
• Регрессионные тесты. Серия тестов, проверяющих основные операции программы. Называется “регрессом”, так как набор тестов смотрит на стандартные функциональные части кода, которые не должны меняться. Обычно этот набор используется перед продуктовым релизом. В случае с данными регресс обычно покрывает критические трансформации.
• Фича-тесты. Тесты, проверяющие любые новые компоненты (“фичи”), добавленные в программу поверх уже вышедших в релиз операций. Они добавляются в набор регрессионных тестов, если эти фичи критичны для релизов продукта и должны оставаться неизменными при продвижении вперед.

Возможно, вы знакомы с некоторыми из этих типов, а также с другими, не перечисленными тут. Это распространенные, полезные типы тестов, которыми множество команд разработки ПО пользуется на постоянной основе. Все они применимы к тестированию данных.

Юнит-тесты - секретное оружие валидации данных

Как и в случае с прочими QA-ролями, проверка качества инжиниринга данных должна добавлять ценности к работе команде инжиниринга, а также предоставлять обратную связь полезным образом. Инженеры по тестированию данных практически всегда начинают с ручного тестирования, особенно на предприятиях с легаси-базой данных и технологией хранилища данных. Скорее всего, на ноутбуке инженера по качеству данных будет пара сотен лишних SQL-скриптов. Однако такое ручное тестирование все еще должно проверить все шесть измерений качества данных, не став при этом бутылочным горлом для релизов. Однако, несмотря на это, автоматизация тестирования данных - вещь возможная, особенно в плане юнит-тестов и простых проверок.

По моему опыту, одна из главных задач инженера по качеству данных — это евангелизация юнит-тестов, встроенных в процесс работы с данными. Юнит-тесты внедряются инженером данных в ходе разработки трансформаций данных, и могут поймать ошибки в данных задолго до того, как инженер по качеству впервые взглянет на набор данных. Обычно дата-инженеры не привычны к юнит-тестам — это больше практика разработки ПО. Однако я не одинока во мнении, что культуре дата-инжиниринга нужно больше юнит-тестов. Популярные фреймворки с открытым исходным кодом вроде data build tool (dbt) имеют встроенные юнит-тесты, помогающие предотвратить проблемы с полнотой, уникальностью и своевременностью. Другие инструменты с открытым исходным кодом вроде Great Expectations покрывают набором проверяющих данные юнит-тестов весь процесс работы с данными.

Автоматизация

Автоматизация критически важна для качества данных и их соответствия шести измерениям качества. К примеру, смесь юнит-тестирования и тестирования полноты данных помогает инженерам качества данных написать быстрый автоматизированный тест, ищущий NULL-значения в критически важном поле. Чем больше в вашем процессе автоматизированных тестов, проверяющих измерения качества критических данных разными способами, тем меньше работы остается дата-инженерам.

Что, если вместо генерации таблицы и постоянного ее просмотра посредством SQL и соединения с базой данных, дата-инженер обзаведется встроенным набором регрессионных тестов, прогоняющих ежедневные проверки вместо него? Это полезные основы автоматизации и тест-инжиниринга, которые воплощаются дата-инженерами.

Заключение

Тестирование данных - уникальная область, которая ежедневно растет и меняется. Широко признанных стандартов качества данных пока что особо не существует, и даже стандарты вроде шести измерения качества вызывают споры. Подрастают другие поля анализа данных вроде машинного обучения и искусственного интеллекта, которые порождают новые способы валидации точности, полноты, постоянства данных, и т. п.

Мы точно знаем, что прямо сейчас качество данных сильно зависит от субъективного смысла запрошенного набора данных, а также от нужд людей, стоящих в конце процесса работы с данными. По этой причине сложно найти подходящие для тестирования и улучшения качества метрики, однако мы все еще можем пользоваться знаниями о полезных типах тестов и измерениях качества данных, чтобы валидировать ежедневно используемые данные. С развитием нашего понимания использования данных будут развиваться и метрики качества данных, и наше понимание тестирования данных.

Обсудить в форуме