Работали ли вы с Great Expectations и dbt tests для проверки качества данных

Что проверяют

Есть ли у вас привычка проверять данные автоматически, а не глазами и по жалобе от бизнеса. Заодно смотрят, различаете ли вы два инструмента: один живёт внутри трансформаций хранилища, другой проверяет данные где угодно, но требует своей обвязки.

Как отвечать

Про dbt: тест это обычная SQL-проверка рядом с моделью, возвращающая строки-нарушители. Встроенные закрывают типовое, not_null, unique, accepted_values, relationships, остальное добирается пакетами или одиночным тестом на своём запросе. У теста есть уровень строгости, поэтому косметика может предупреждать, а нарушение ключа ронять прогон. При сборке по графу тесты идут сразу за своей моделью и не дают считать сломанное дальше.

Про Great Expectations: набор ожиданий поверх источника, не обязательно SQL. Он уместен, когда проверять надо файлы, поток или датафрейм до загрузки в хранилище, и когда нужны читаемые человеком отчёты о проверках.

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

Где спотыкаются

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

Ставят всем проверкам максимальную строгость и получают конвейер, который стоит из-за одной пустой строки в справочнике. Обратная крайность не лучше: если всё только предупреждает, предупреждения перестают читать на второй неделе.

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