Важно не количество, а качество.

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

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

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

Стоит отметить, что вам рекомендуется комбинировать эти подходы и найти баланс, который лучше всего подходит для вас.

Качество › Количество

Я один из тех, кто любит создавать тесты, потому что они придают мне больше уверенности в своих решениях. Имея опыт разработки программного обеспечения, я когда-то жил под девизом «Чем больше тестов, тем лучше». Я всегда был в восторге от фреймворков данных, предлагающих простые методы создания тестов данных.

Однако я недооценил побочные эффекты чрезмерного количества тестов данных. (Есть ли вообще побочный эффект? ДА!) Давайте сначала разберемся в различиях между тестами данных и модульными тестами (то есть логическими тестами). Короче говоря, модульный тест предназначен для проверки правильности логики кода, который мы написали. Чем больше у нас модульных тестов, тем увереннее мы справляемся с пограничными случаями. Но проверка данных выходит за рамки логики кода, она также проверяет качество исходных данных, конфигурации конвейера данных, исходные зависимости и так далее. Метрики бесконечны и могут быть ошеломляющими. Заманчиво создать множество тестов на всякий случай, но они не всегда приносят пользу и могут внести ненужный шум. Например, давайте посмотрим правде в глаза, не каждый конвейер данных нуждается в ежедневном тесте на свежесть, если они используются пользователями только время от времени, и не все этапы в конвейере данных требуют одинакового теста. Только тесты дублирующихся данных приведут к избыточным оповещениям.

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

Пригодность для использования

Данные можно рассматривать как продукт. Конвейеры данных можно рассматривать как системы производства данных, принимающие ввод необработанных данных и производящие продукты данных. Хотя потребители данных не покупают данные, они могут решить, использовать их или нет, и они могут предоставить соответствующие требования и отзывы.

Концепция «пригодности к использованию» широко применяется при измерении качества. В нем подчеркивается важность улавливания мнения покупателей в полном объеме, поскольку, в конечном счете, именно потребители будут определять успех продукта. Например, при создании университетской библиотеки крайне важно помнить о студентах и ​​преподавателях, а это означает, что в ней должен быть ряд книг и ресурсов, отвечающих различным интересам и образовательным требованиям.

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

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

Параметры качества данных

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

| Accuracy     | Format           | Comparability     |
| Reliability  | Interpretability | Conciseness       |
| Timeliness   | Content          | Freedom from bias |
| Relevance    | Efficiency       | Informativeness   |
| Completeness | Importance       | Level of detail   |
| Currency     | Sufficiency      | Quantitativeness  |
| Consistency  | Usableness       | Scope             |
| Flexibility  | Usefulness       | Understandability |
| Precision    | Clarity          |                   |

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

Внешний вид

Внешний взгляд касается использования данных и их связи с организацией. Его часто считают «черным ящиком» с функциональностью, представляющей реальную систему. Измерения, попадающие во внешний вид, в значительной степени зависят от бизнеса. Иногда оценка этих параметров может быть субъективной, поэтому не всегда легко создавать для них автоматические тесты. Но давайте проверим несколько известных измерений:

  • Релевантность: степень, в которой данные применимы и полезны для анализа. Рассмотрим рыночную кампанию, направленную на продвижение нового продукта. Все атрибуты данных должны напрямую способствовать успеху кампании, например демографические данные клиентов и данные о покупках. Такие данные, как погода в городе или цены на фондовом рынке, в этом случае не имеют значения. Другой пример — уровень детализации (детализации). Если бизнес хочет, чтобы рыночные данные были на уровне дня, но они предоставлялись на уровне недели, то это неактуально и бесполезно.
  • Представление: степень, в которой данные могут быть интерпретированы для потребителей данных, а формат данных является последовательным и описательным. Важность уровня представления часто упускается из виду при доступе к качеству данных. Он включает в себя формат данных — он должен быть последовательным и удобным для пользователя, а смысл данных — быть понятным. Например, рассмотрим сценарий, в котором ожидается, что данные будут доступны в файле CSV с описательными описаниями столбцов, а значения должны быть в евро, а не в центах.
  • Своевременность. Степень свежести данных для потребителей данных. Например, бизнесу нужны данные о транзакциях продаж с максимальной задержкой в ​​1 час от точки продажи. Это указывает на необходимость частого обновления конвейера данных.
  • Точность. Насколько данные соответствуют бизнес-правилам. Метрики данных часто связаны со сложными бизнес-правилами, такими как сопоставление данных, режимы округления и т. д. Настоятельно рекомендуется использовать автоматические тесты логики данных, и чем их больше, тем лучше.

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

Внутреннее представление

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

  • Качество источника данных. Качество источника данных существенно влияет на общее качество окончательных данных. Контракт данных — отличная инициатива для обеспечения качества исходных данных. Как потребители данных источника, мы можем использовать тот же подход для мониторинга исходных данных, что и заинтересованные стороны данных при оценке продуктов данных.
  • Полнота. Степень, в которой информация сохраняется в полном объеме. По мере увеличения сложности конвейера данных возрастает вероятность потери информации на промежуточных этапах. Давайте рассмотрим финансовую систему, в которой хранятся данные о транзакциях клиентов. Тест полноты гарантирует, что все транзакции успешно проходят весь жизненный цикл, не пропуская и не пропуская их. Например, окончательный баланс счета должен точно отражать реальную ситуацию, отражая каждую транзакцию без каких-либо упущений.
  • Уникальность. Этот параметр тесно связан с проверкой полноты. В то время как полнота гарантирует, что ничего не будет потеряно, уникальность гарантирует отсутствие дублирования данных.
  • Непротиворечивость. Степень согласованности данных во внутренних системах на ежедневной основе. Расхождение — это распространенная проблема с данными, которая часто возникает из-за разрозненности данных или непоследовательных методов расчета метрик. Другой аспект проблемы согласованности возникает между днями, когда ожидается, что данные будут иметь устойчивый характер роста. Любое отклонение должно стать поводом для дальнейшего расследования.

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

До сих пор мы обсуждали размеры внешних представлений и внутренних представлений. В будущих проектах тестирования данных важно учитывать как внешнюю, так и внутреннюю точки зрения. Задавая правильные вопросы нужным людям, мы можем повысить эффективность и уменьшить недопонимание.

Дополнительные советы по тестированию данных

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

  • Неверные данные по сравнению с Нет данных.Во многих решениях для данных тесты данных обычно проводятся после обновления модели. Это означает, что к тому времени, когда мы распознаем проблему, данные уже «испорчены». Если вы предпочитаете «нет данных», а не «неправильные данные», вы можете сначала материализовать таблицу во временном месте, а затем провести тесты. Только если тесты успешно пройдены, конвейер продолжит копирование таблицы в исходное место назначения; в противном случае процесс будет остановлен.
  • Тест согласования.Тест согласования – это процесс проверки данных, в ходе которого сравнивается согласованность и точность данных между двумя или более системами, обычно между исходным и целевым набором данных. Например, для обработки транзакций предназначены два пайплайна, стоит сравнить общую сумму транзакций из обеих систем и из источника. Наличие любого несоответствия потенциально может указывать на недостатки в конвейере данных.
  • Тесты с запасом. Мы можем получить такое заявление от заинтересованных сторон: «Наличие 0 в этом столбце допустимо, но следует избегать чрезмерного количества». Это означает, что они хотят зафиксировать отклонение от последовательного шаблона. Многие современные инструменты мониторинга данных предоставляют функции обнаружения аномалий, но если это не вариант для вас, вы можете начать с создания тестов с запасом. Например, не более 5% от общего числа строк должны иметь значение 0.

Заключение

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

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

Ссылка