Настройки сookie
Файлы cookie, необходимые для правильной работы сайта, всегда разрешены.
Как построить систему контроля качества данных: опыт работы с dbt и Soda
На этапе активной разработки, основные усилия команды обычно направлены на реализацию функциональности, но как только проект переходит в фазу поддержки, становится очевидным, что без системного контроля качества доверие к данным начинает снижаться. Для обеспечения качества данных на проекте существует широкий спектр подходов и инструментов. Один из распространённых вариантов — использование проверочных SQL- или Python-скриптов, которые запускаются вручную по мере необходимости или автоматически по расписанию с помощью оркестраторов (например, Airflow, NiFi, Pentaho и др.). Такой подход уже успешно применяется в ряде проектов нашей компании и эффективно покрывает ключевые требования к контролю качества данных.
Так же существует целый класс специализированных инструментов, помогающих формализовать и автоматизировать проверки качества данных. На российском рынке наиболее популярные из них – dbt и Soda. О том, как эти инструменты используются на проектах и поговорим в данной статье.
dbt
dbt – это многофункциональный open-source универсальный инструмент для построения и управления процессами трансформации данных, и его возможности далеко не ограничиваются проверками качества.
Он позволяет разрабатывать модели данных, управлять зависимостями, документировать логику и автоматизировать сборку витрин. Контроль качества данных является одним из направлений его применения. DBT позволяет встроить тесты прямо в процесс трансформации, описывая проверки в виде декларативных SQL-тестов.
Проверки делятся на два типа: встроенные (standart) и самописные (custom).
Ко встроенными относятся: проверка уникальности ключей (unique), проверка заполняемости колонки (not null), проверка допустимых значений атрибутов (accepted_values) и проверка целостности связей (relationships).
Самописные проверки можно делать двумя способами. Первый – написать SQL-запрос, который должен вернуть строки, не соответствующие ожиданиям. Если запрос возвращает хотя бы одну строку – тест провален. Второй – создать параметризованный макрос, который потом можно вызвать из любой модели.
Пример создания простейших проверок с использованием dbt
Пример будет рассмотрен в СУБД – PostgreSQL, ОС – Linux.
Создадим таблицу пользователей. Структура таблицы:
CREATE TABLE IF NOT EXISTS edu.users (
user_id SERIAL, -- уникальный идентификатор
name VARCHAR(255),
email VARCHAR(255),
status VARCHAR(50),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);Для работы dbt необходимо, чтобы был установлен Python. Если не установлен, то выполняем:
sudo apt update
sudo apt install -y python3 python3-pipДалее создаем виртуальное окружение для работы с dbt:
python3 -m venv dbt-envЕсли dbt не установлен, то устанавливаем dbt на машину (в нашем случае сразу под БД PostgerSQL):
pip install dbt-postgresДалее инициализируем проект dbt:
dbt init my_dbt_projectСоздаем в каталоге /.dbt/ файл profiles.yml.
В нем необходимо указать параметры подключения к базе:
В нем необходимо указать параметры подключения к базе:
test_prj:
target: dev
outputs:
dev:
type: postgres
threads: 4
host: "localhost"
port: 5432
user: "your_username"
pass: "your_password"
dbname: "datadb"
schema: "edu"
keepalives_idle: 0
connect_timeout: 10
search_path: publicПосле его создания, можно проверить его валидность командой:
dbt debugЕсли все «ок», то результат команды будет:
Connection test: [OK connection ok]Теперь все готово для создания моделей проверок. Внутри папки проекта создаем структуру каталогов models/staging. В каталоге staging создаём два файла:
1. Файл модели stg_users.sql:
{{ config(
materialized='table'
) }}
select user_id,
name,
email,
status,
created_at
from edu.usersВ данном файле описывается подключение к «сырой» таблице edu.users. В запросе можно переименовывать поля, преобразовать типы, отфильтровывать ненужные значения. В итоге создаётся staging-модель stg_users, которую потом могут использовать другие модели.
2. Файл тестов stg_users.yml:
version: 2
models:
- name: stg_users
description: "Таблица пользователей после первичной очистки"
columns:
- name: user_id
description: "Уникальный идентификатор пользователя"
tests:
- not_null
- unique
- name: email
description: "Email пользователя"
tests:
- not_null
- unique
- name: status
description: "Статус пользователя"
tests:
- accepted_values:
values: ['active', 'inactive', 'banned']
Файл тестов описывает структуру модели и автоматические проверки качества данных (тесты).
Как видно, мы ограничились стандартными проверками, а именно:
Как видно, мы ограничились стандартными проверками, а именно:
- Поле user_id – заполнено и уникально.
- Поле email – заполнено и уникально.
- Поле status – содержит значения из списка ['active', 'inactive', 'banned'].
В dbt можно создать модели на все необходимые для проверки таблицы. Главное правило: одна модель – одна сущность. Если нужно объединить несколько таблиц, то создается новая модель на основе уже существующих.
Когда все модели созданы, их можно запустить. Ниже команда запуска всех моделей:
dbt run
dbt testЕсли хотим запустить конкретную модель, команда выглядит так:
dbt run --select stg_users
dbt test --select stg_usersРезультатом будет описание статусов проверок:
Таким образом, мы рассмотрели пример простенькой проверки в dbt.
Soda
Soda – это специализированный open-source инструмент, изначально разработанный для мониторинга и обеспечения качества данных.
Его основная идея – позволить командам описывать правила качества в простом декларативном формате, не углубляясь в программирование. Проверки в Soda определяются в YAML-файлах и так же, как в dbt, есть стандартные и custom-ные проверки. Рассмотрим создание проверок в Soda. За основу возьмем ту же таблицу users.
Пример создания простейших проверок с использованием Soda
За основу возьмем ту же таблицу users.
Для начала установим Soda для PostgreSQL:
pip install soda-core-postgresСоздаем папку проекта:
mkdir soda_project && cd soda_projectДальше создаем в этой папке проекта файл connection.yml, в котором описываем параметры соединения:
data_source postgres_connection:
type: postgres
connection:
host: localhost
port: 5432
username: your_username
password: your_pass
database: datadb
schema: eduИ создаем файл проверок checks.yml:
checks for users:
- missing_count(user_id) = 0
- duplicate_count(user_id) = 0
- missing_count(email) = 0
- duplicate_count(email) = 0
- missing_percent(status) = 100%:
missing values: ['active', 'inactive', 'banned']На этом все. Остается только запустить проверки:
soda scan -d postgres_connection -c connection.yml checks.ymlРезультат будет примерно такой:
Как мы видим, оба инструмента достаточно просты как в установке, так и в использовании. По сути, в каждом из них нужно создать лишь файл с подключением к БД и файл с проверками. Сами инструменты тоже очень похожи в части проверок DQ. Возникает вопрос: какой из них выбрать для своего проекта? Точного ответа нет. Но есть рекомендации.
Рекомендации
Если основная часть работы с данными сосредоточена в трансформационном слое – например, при построении витрин и аналитических моделей, то dbt позволяет естественным образом встроить тесты в существующий pipeline или сломать его в случае не пройденного теста, а также использовать единую экосистему для разработки, документации и контроля качества.
Если же команда хочет реализовать независимый слой мониторинга, который отслеживает качество данных в различных системах и на разных этапах обработки, то Soda подойдет лучше. Он позволяет гибко описывать проверки (например, специфические, вида: количество заказов с отрицательной суммой не должно превышать 0,1%), запускать их отдельно от ETL-процессов и интегрировать результаты с системами оповещений. Также Soda подойдет лучше, если у тебя несколько систем, не только dbt. Soda может подключаться к Postgres, Snowflake, MS SQL, BigQuery и т.д. без зависимости от dbt.
Так же можно использовать комбинированный подход: базовые проверки реализуются в dbt, а для более широкого мониторинга и аналитики качества данных применяется Soda. Такой вариант позволяет достичь баланса между прозрачностью, удобством и глубиной контроля, но предполагает, что придется создавать больше проверок в разных инструментах.