Тестируйте умнее, а не усерднее: добавьте правильные тесты в ваш проект dbt

Цикл разработки аналитики (ADLC) — это рабочий процесс для улучшения зрелости и скорости работы с данными. Тестирование является ключевой фазой здесь. Многие разработчики dbt склонны сосредотачиваться на первичных ключах и свежести источников. Мы считаем, что существует более целостный и глубокий путь. Тестирование — это ключевой элемент ADLC, и оно должно способствовать качеству данных.

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

• выявление проблем гигиены данных
• выявление проблем аномалий, ориентированных на бизнес
• выявление проблем аномалий, ориентированных на статистику

После того как мы определим качество данных, мы перейдем к приоритизации этих проблем. Мы будем:

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

Кто мы?

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

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

Сегодня мы проведем вас через особенно сложную проблему: тестирование.

Зачем тестирование?

Мэрайя Роджерс заложила основу для качества данных и тестирования в своем докладе Coalesce 2022. Мы видели подобные доклады снова на Coalesce 2024, такие как этот от команды данных в Aiven и этот от соучредителя Omni Analytics. Эти доклады объединяет общая тема: чрезмерное тестирование вашего проекта dbt может быстро выйти из-под контроля, приводя к усталости от оповещений.

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

Желание найти лучший подход к качеству данных и тестированию не является просто анекдотом для Coalesce или для обучения и услуг dbt. Сообщество dbt давно призывает к более осознанному подходу к качеству данных и тестированию — качество данных на уме у индустрии! Фактически, 57% респондентов в опросе dbt 2024 State of Analytics Engineering заявили, что качество данных является преобладающей проблемой, с которой они сталкиваются в своей повседневной работе.

Что вообще значит к@чЕсТвО д@нНых?!

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

Лучшие практики в области качества данных все еще находятся на начальной стадии. Тем не менее, здесь проделана важная базовая работа. Существуют кейсы исследования по успешной реализации тестирования dbt. dbt Labs также предлагает курс Advanced Testing, подчеркивающий, что тестирование должно стимулировать действия и быть достаточно сфокусированным и информативным, чтобы помочь в решении проблем. Вы даже можете применять лучшие практики тестирования и собственные лучшие практики dbt Labs, используя пакеты dbt_meta_testing или dbt_project_evaluator и страницу Recommendations в dbt Explorer.

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

Подведем итог, мы начнем с:

• выявления проблем гигиены данных
• выявления проблем аномалий, ориентированных на бизнес
• выявления проблем аномалий, ориентированных на статистику

Далее мы будем приоритизировать. Мы будем:

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

Возьмите ручку и бумагу (или документ в Google) и присоединяйтесь к нам в создании вашей собственной структуры тестирования.

Выявление проблем качества данных в вашем конвейере

Давайте начнем нашу структуру с выявления типов проблем качества данных.

В нашей повседневной работе с клиентами мы обнаруживаем, что проблемы качества данных, как правило, попадают в одну из трех широких категорий: гигиена данных, аномалии, ориентированные на бизнес, и аномалии, ориентированные на статистику. Прочитайте описания категорий ниже и перечислите 2-3 проблемы качества данных в вашем собственном бизнес-контексте, которые попадают в каждую категорию.

Категория 1: Гигиена данных

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

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

Категория 2: Аномалии, ориентированные на бизнес

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

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

Представьте, что вы аналитик по продажам. В общем, вы знаете, что если ваша дневная сумма продаж увеличивается или уменьшается более чем на 20% в день, это плохо. Конкретно, это обычно является предупреждающим знаком о мошенничестве или сбоях в системе управления заказами (OMS). Вы устанавливаете тест в dbt, чтобы он проваливался, если сумма продаж за любой день отличается на 20% от предыдущего дня. Это работает какое-то время.

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

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

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

Вот как определить потенциальные аномалии.

Начните с вашего уровня бизнес-аналитики (BI). Выберите 1-3 панели или таблицы, которые вы знаете, что используются часто. Перечислите эти 1-3 панели или таблицы. Для каждой панели или таблицы, которую у вас есть, определите 1-3 "ожидаемых" поведения, на которые полагаются ваши конечные пользователи. Вот несколько примеров, чтобы заставить вас задуматься:

• Числа доходов не должны изменяться более чем на X% за Y период времени. Это может указывать на мошенничество или проблемы с OMS.
• Количество активных пользователей в месяц не должно снижаться более чем на X% после начального периода адаптации. Это может указывать на неудовлетворенность пользователей, проблемы с удобством использования или то, что пользователи не находят функцию ценной.
• Процент сдачи экзаменов должен оставаться выше Y%. Снижение ниже этого порога может указывать на недавние изменения в содержании или технические проблемы, влияющие на понимание или доступность.

Вы также должны учитывать, какие проблемы с данными у вас были в прошлом! Просмотрите недавние инциденты с данными и выберите 3 или 4, чтобы защититься от них в следующий раз. Они могут быть в канале #data-questions или, возможно, в личном сообщении от заинтересованного лица.

Категория 3: Аномалии, ориентированные на статистику

Аномалии, ориентированные на статистику, — это колебания, которые противоречат вашим ожидаемым объемам или метрикам. Некоторые примеры включают:

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

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

Как приоритизировать проблемы качества данных в вашем конвейере

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

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

• Являются ли ваши числа ориентированными на клиентов? Например, возможно, вы работаете с устройствами для отслеживания температуры. Ваши клиенты полагаются на эти устройства, чтобы показывать им средние температуры на скоропортящихся товарах, таких как клубника, в пути. Что произойдет, если температура клубники будет показывать 300°C, когда они знают, что их рефрижераторный грузовик работал нормально? Как это повлияет на восприятие вашего бренда, когда числа неверны?
• Являются ли ваши числа используемыми для принятия финансовых решений? Например, полагается ли маркетинговая команда на ваши числа, чтобы выбрать, как потратить средства на кампанию?
• Являются ли ваши числа ориентированными на руководителей? Будут ли руководители использовать эти числа для перераспределения средств или изменения приоритетов?

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

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

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

Вы также можете полностью удалить тесты, которые приятно знать. Тестирование данных должно приводить к действиям. Чем больше у вас оповещений в конвейере, тем меньше действий вы предпримете. Настраивайте оповещения с осторожностью!

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

Начните свой план действий

Теперь ваши проблемы качества данных перечислены и приоритизированы. Далее добавьте 1 или 2 начальных шага отладки, которые вы предпримете, если/когда проблемы возникнут. Эти шаги должны быть добавлены в ваш документ структуры. Кроме того, рассмотрите возможность добавления их в описание теста.

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

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

Вот несколько примеров из нашего списка неожиданных поведений выше.

• Для вычисляемого поля X значение выше Y или ниже Z невозможно.
  • Начальные шаги отладки
    • Используйте SQL теста dbt или недавние результаты теста в dbt Explorer, чтобы найти проблемные строки
    • Проверьте эти строки на этапе подготовки и в первой преобразованной модели
    • Определите, где впервые появляются необычные значения
• Доходы не должны изменяться более чем на X% за Y период времени.
  • Начальные шаги отладки:
    • Проверьте недавние значения доходов в модели подготовки
    • Определите транзакции, близкие к минимальным/максимальным значениям
    • Обсудите выбросы с командой операционного управления продажами

Теперь у вас есть написанный приоритизированный список проблем качества данных, а также шаги действий, которые нужно предпринять, когда каждая проблема возникнет. Далее, проконсультируйтесь с hub.getdbt.com и найдите тесты, которые решают каждую из ваших самых приоритетных проблем. dbt-expectations и dbt_utils — отличные места для начала.

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

Ваш список приоритетов качества данных — это живой справочный документ. Мы рекомендуем ссылаться на него в README вашего проекта, чтобы вы могли вернуться и редактировать его по мере изменения ваших потребностей в тестировании. Кроме того, разработчики в вашем проекте должны иметь легкий доступ к этому документу. Поддержание хорошего качества данных — это ответственность каждого!

Когда вы попробуете эти идеи, приходите в Slack сообщества dbt и дайте нам знать, что работает, а что нет. Данные — это сообщество практики, и мы с нетерпением ждем, что выйдет из вашего.