Тестирование BigQuery можно разделить на три ключевых уровня, которые стоит реализовать в первую очередь: 1) Тестирование качества данных (Data Quality), 2) Тестирование бизнес-логики в представлениях и запросах (Logic Testing), 3) Регрессионное тестирование пайплайнов (Pipeline Regression). Для каждого из них есть простые и быстрые инструменты.
**Шаг 1: Быстрая настройка тестов качества данных (10 минут).**
Качество данных — основа достоверной аналитики. Самые критичные проверки, которые можно внедрить моментально:
* **Отсутствие NULL в ключевых полях:** Например, `user_id` или `order_id` не должны быть пустыми.
* **Уникальность первичных ключей:** В таблице фактов не должно быть дубликатов по ключу.
* **Допустимость значений (Acceptable Values):** Поле `status` должно содержать только значения из списка (‘completed’, ‘pending’, ‘cancelled’).
* **Согласованность с родительской таблицей (Referential Integrity):** `product_id` в таблице заказов должен существовать в таблице продуктов.
Как это проверить? Напишите несколько простых SQL-запросов, которые возвращают строки, нарушающие правила. Например, проверка уникальности:
`SELECT order_id, COUNT(*) as cnt FROM `project.dataset.orders` GROUP BY order_id HAVING cnt > 1;`
Если запрос возвращает 0 строк — тест пройден.
Чтобы автоматизировать и не запускать запросы вручную, используйте фреймворк **dbt (data build tool)**. За 10 минут можно инициализировать dbt-проект для BigQuery, и в папке `tests/` создать generic-тесты в виде YAML-конфигурации. dbt имеет встроенные generic-тесты (`unique`, `not_null`, `accepted_values`, `relationships`). Описание теста для поля `user_id` будет выглядеть так:
```
version: 2
models:
- name: orders
columns:
- name: user_id
tests:
- not_null
- unique
- name: status
tests:
- accepted_values:
values: ['completed', 'pending', 'cancelled']
```
Запуск `dbt test` выполнит все проверки и предоставит отчет.
**Шаг 2: Тестирование бизнес-логики в SQL (10 минут).**
Чаще всего ошибки возникают в сложных представлениях (VIEW) или материализованных представлениях, где применяются агрегации, JOIN и оконные функции. Простейший способ — это тестирование на фиксированных наборах данных.
- Создайте тестовый dataset в BigQuery (например, `project_test`).
- Наполните его небольшой тестовой фикстурой — таблицей с 5-10 строками, где заранее известен ожидаемый результат. Например, для представления, рассчитывающего дневную выручку, создайте таблицу `raw_orders_test` с несколькими заказами за разные даты.
- Запустите ваш продакшен-запрос (который лежит в основе VIEW) на этих тестовых данных, указав в FROM тестовую таблицу.
- Сравните результат с ожидаемым эталоном. Идеально — оформить это как запрос, который вернет расхождения.
```
{% test revenue_matches_source(model, column_name) %}
SELECT
date,
total_revenue
FROM {{ model }}
WHERE total_revenue != (
SELECT SUM(amount) FROM `project.raw.orders` o
WHERE DATE(o.created_at) = date
)
{% endtest %}
```
Такие тесты запускаются той же командой `dbt test`.
**Шаг 3: Регрессионное тестирование пайплайнов (10 минут).**
Когда ваш ETL/ELT-пайплайн (на Airflow, Cloud Composer, Cron) обновляет таблицу, важно убедиться, что изменения в логике не сломали существующие отчеты и не привели к резким аномалиям в данных.
- **Сравнение объемов данных:** Простейший запрос, который можно добавить в пайплайн после его выполнения: сравнить количество строк в обновленной таблице с количеством вчера. Резкое падение или рост на 50% — повод остановить пайплайн и разобраться.
- **Снепшот-тестирование (Snapshot Testing):** Инструмент dbt имеет встроенную функциональность **snapshots**. Она позволяет отслеживать изменения строк в таблице-источнике по типу SCD Type 2. Но её же можно использовать для регрессии: сделать снимок ключевых агрегатов (например, выручка по неделям) после успешного прогона пайплайна и сравнить его с предыдущим. Значительные отклонения вне ожидаемого диапазона будут видны.
- **Мониторинг основных метрик:** Настройте простой дашборд в Data Studio или Looker Studio, который отображает ключевые KPI (общее число заказов, средний чек, количество пользователей) за последний день после обновления. Визуальный осмотр перед «зеленым светом» на использование данных занимает минуту, но спасает от серьезных ошибок.
Все эти проверки должны быть интегрированы в процесс. Идеально — добавить этап `dbt test` в ваш CI/CD-пайплайн (например, в GitLab CI, GitHub Actions или Cloud Build). Каждый merge request с изменением SQL-кода будет автоматически прогонять тесты на выделенном тестовом проекте BigQuery. Это займет еще 10 минут на настройку, но сэкономит часы на отладке в будущем.
«Главное — начать с малого, — советует Петр К., data engineer в SaaS-компании. — Не пытайтесь покрыть тестами всю вашу базу сразу. Выберите одну-две самые критичные таблицы или витрины, от которых зависят ключевые бизнес-отчеты. Напишите для них 3-5 простейших тестов на качество и логику. Вы сразу почувствуете уверенность, а затем постепенно расширите покрытие».
Таким образом, потратив всего 30 минут на настройку базовых тестов с помощью инструментов вроде dbt и стандартных SQL-запросов, вы значительно повысите надежность ваших данных в BigQuery, уменьшите количество инцидентов и сможете доверять результатам своей аналитики.
Комментарии (5)