Как тестировать BigQuery: комплексный чек-лист на 30 минут для уверенности в данных

BigQuery — мощный инструмент, но ошибка в запросе или логике данных может привести к дорогостоящим решениям на основе неверной аналитики. Полноценное тестирование ETL/ELT-пайплайнов и SQL-запросов кажется монументальной задачей. Однако с правильным подходом вы можете выполнить ключевые проверки за 30 минут, обеспечив базовый уровень уверенности в ваших данных. Вот пошаговый чек-лист, который охватывает три уровня: данные, логику и производительность.

Первые 10 минут: Проверка целостности и качества данных (Data Sanity Check).

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

• Проверка объема: `SELECT COUNT(*) FROM your_project.dataset.table`. Сравните количество строк с ожидаемым (например, с вчерашним днем или с источником). Резкое падение или скачок — красный флаг.
• Проверка свежести: Найдите поле с меткой времени (например, `ingestion_timestamp` или `event_date`). Запрос `SELECT MAX(timestamp_field) FROM ...` покажет, актуальны ли данные. Убедитесь, что последние данные соответствуют ожидаемому времени обновления.
• Поиск явных аномалий: Проверьте ключевые поля на NULL там, где их быть не должно: `SELECT COUNT(*) FROM ... WHERE critical_id IS NULL`. Быстрый прогон по 3-5 самым важным столбцам.
• Проверка уникальности ключей: Для таблиц фактов или измерений проверьте, что ключевые поля уникальны, если должны: `SELECT COUNT(DISTINCT unique_key) as distinct_count, COUNT(*) as total_count FROM ...`. Если `total_count > distinct_count`, есть дубликаты.

Следующие 15 минут: Тестирование бизнес-логики и преобразований (Logic & Transformation Testing).

Если у вас есть SQL-скрипты, материализованные представления или scheduled queries, их логику нужно проверять на устойчивость.

• Тест на идемпотентность: Запустите ваш ключевой ETL-запрос дважды. Результат не должен измениться (не должно появиться дублей или неконсистентных данных). Это особенно важно для инкрементальных загрузок.
• Проверка агрегатов на известных срезах (Smoke Test): Выберите небольшой, известный сегмент данных. Например, данные только за вчерашний день или только для одного региона. Вручную посчитайте ключевую метрику (сумму продаж, количество пользователей) и сравните с результатом вашего основного запроса/представления. Совпадение — хороший знак.
• Сравнение с золотым стандартом (Golden Dataset): Если возможно, подготовьте небольшой эталонный датасет с известными входными и выходными данными. Запустите вашу логику преобразований на этих данных и сравните результат с эталоном. Это можно автоматизировать с помощью фреймворков вроде `dbt test` (который отлично интегрируется с BigQuery), но для быстрой проверки хватит и ручного сравнения.
• Проверка граничных условий: Что происходит, когда в таблице-источнике нет данных? Или когда поле принимает неожиданное значение? Добавьте в ваш пайплайн простые assertions, например, что результирующая таблица не пуста после выполнения, или что рассчитанный процент не превышает 100.

Последние 5 минут: Быстрая оценка производительности и стоимости (Performance & Cost Snapshot).

Плохой запрос может «съесть» бюджет и замедлить работу других аналитиков.

• Анализ выполненного запроса: В интерфейсе BigQuery перейдите на вкладку «History». Найдите ваш последний тяжелый запрос и посмотрите: а) Обработано данных (Bytes processed). Не превышает ли он ожидаемый объем? б) Время выполнения (Slot time). Резкий рост может указывать на проблему (CROSS JOIN, отсутствие партиционирования).
• Проверка партиций и кластеризации: Для больших таблиц убедитесь, что запросы используют фильтрацию по партициям. Простой тест: выполните `SELECT * FROM ... WHERE _PARTITIONDATE = CURRENT_DATE() LIMIT 1`. Если запрос все равно сканирует всю таблицу, возможно, партиционирование не настроено или используется не то поле.
• Визуальный осмотр плана выполнения: В том же интерфейсе выполнения запроса посмотрите на график выполнения. Огромная стадия «Read» или «Join» может указать на узкое место.

Этот 30-минутный ритуал не заменит полноценных автоматизированных тестов, но он создает мощный предохранительный слой. Внедрите его как ежедневную или предрелизную практику для ключевых пайплайнов. Со временем самые полезные проверки можно автоматизировать с помощью `dbt`, собственных скриптов на Python с использованием клиентской библиотеки BigQuery или даже настроив Scheduled Queries с уведомлениями об аномалиях. Главное — начать с малого и выработать культуру «доверия, но проверки» к данным в BigQuery.