Как проверить SQL, который написал ИИ, до запуска в BigQuery

ИИ подготовил SQL для рекламного отчёта, и запрос выглядит убедительно. До запуска проверьте четыре риска: сможет ли он изменить данные, сколько байтов прочитает, совпадает ли результат с контрольной выборкой и останется ли запись о выполнении. Такая приёмка занимает меньше времени, чем восстановление таблицы или поиск причины завышенного CPL.

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

Что проверяет dry run

BigQuery умеет проверить запрос без выполнения. В консоли валидатор показывает синтаксическую ошибку или оценку объёма данных; через CLI используется флаг --dry_run. Google рекомендует оценивать стоимость до запуска. Для тарификации по объёму чтения оценка служит верхней границей, поэтому фактическое число оплаченных байтов может оказаться ниже.

Dry run отвечает только на часть вопросов:

Зелёная галочка рядом с запросом подтверждает, что BigQuery способен его разобрать. Она не подтверждает бизнес-логику.

Сначала ограничьте последствия ошибки

Проверяйте новый запрос под учётной записью без права менять производственные таблицы. Роль roles/bigquery.dataViewer, выданная на набор данных, разрешает читать и запрашивать таблицы. Для запуска задания отдельно нужна роль roles/bigquery.jobUser на проекте. Конкретную схему доступа согласует администратор: набор данных может содержать дополнительные ограничения, представления и политики по строкам.

Перед запуском найдите операторы, которые записывают или удаляют данные:

INSERT  UPDATE  DELETE  MERGE
CREATE OR REPLACE  DROP  TRUNCATE

Для первого прогона оставьте только SELECT и временные CTE. Если результат нужно записать, сначала проверьте чтение, затем направьте вывод в отдельную тестовую таблицу с понятным сроком хранения. Копия SQL от ИИ не должна получать более широкие права, чем требует задача.

Учебный запрос с известным ответом

Проверим расчёт по четырём строкам. Параметры дат передаются отдельно, а деление защищено SAFE_DIVIDE на случай нулевого числа лидов.

WITH ad_daily AS (
  SELECT * FROM UNNEST([
    STRUCT(DATE '2026-10-01' AS report_date,
      'search' AS campaign, 120.00 AS spend, 80 AS clicks, 6 AS leads),
    STRUCT(DATE '2026-10-02', 'search', 84.00, 56, 4),
    STRUCT(DATE '2026-10-01', 'remarketing', 72.00, 45, 5),
    STRUCT(DATE '2026-10-02', 'remarketing', 49.00, 28, 2)
  ])
)
SELECT
  campaign,
  SUM(spend) AS spend,
  SUM(clicks) AS clicks,
  SUM(leads) AS leads,
  SAFE_DIVIDE(SUM(spend), SUM(leads)) AS cpl
FROM ad_daily
WHERE report_date BETWEEN @date_from AND @date_to
GROUP BY campaign
ORDER BY campaign;

При date_from = 2026-10-01 и date_to = 2026-10-02 ожидается:

Итоговый CPL считается как 325 / 17, а не как среднее двух CPL. Если запрос вернул другой результат, остановитесь на тестовой выборке и найдите расхождение до подключения рабочих таблиц.

Схема отделяет техническую проверку запроса от проверки бизнес-логики.

Передавайте значения параметрами

В BigQuery параметры заменяют значения выражений и помогают защищать запросы, собранные из пользовательского ввода. Имена столбцов, таблиц и другие идентификаторы параметрами заменить нельзя. Поэтому диапазон дат и название кампании можно передать как @date_from и @campaign, а выбор таблицы должен оставаться в проверенном коде или белом списке.

Проверьте три вещи:

1. Параметр имеет ожидаемый тип: DATE, STRING, INT64.
2. Пустое значение обрабатывается явно, а не расширяет период на всю историю.
3. Значение не склеивается со строкой SQL через шаблон или конкатенацию.

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

Поставьте предел стоимости

Для on-demand BigQuery позволяет задать maximum bytes billed. Если оценка превышает предел, запрос завершается до выполнения и не создаёт оплату за этот запуск. В CLI параметр выглядит так:

bq query \
  --use_legacy_sql=false \
  --dry_run \
  'SELECT ...'

bq query \
  --use_legacy_sql=false \
  --maximum_bytes_billed=1000000000 \
  'SELECT ...'

Число 1 000 000 000 здесь учебное, около одного гигабайта в десятичной записи. Рабочий предел задайте по размеру своих партиций, модели оплаты и допустимому расходу. На capacity-based модели объём байтов не переводится напрямую в точную цену отдельного запроса.

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

Проверьте результат на пяти контрольных условиях

После dry run выполните запрос на тестовом наборе или коротком фиксированном периоде. Сохраните ожидаемый результат заранее.

1. Одна строка результата соответствует заявленной единице: кампания, дата или объявление.
2. Число кампаний совпадает со списком контрольного периода.
3. Аддитивные показатели — расход, клики и лиды — сходятся с исходником.
4. CTR, CPC, CPL и конверсия пересчитаны из итоговых числителя и знаменателя.
5. Нулевые значения, NULL, отменённые лиды и неизвестные кампании имеют явное правило.

Для объединения рекламных расходов с лидами дополнительно проверьте детализацию и ключи по инструкции почему расходы удваиваются после объединения таблиц. Если ИИ сначала собрал сводную таблицу, используйте проверку row_id и контрольных сумм.

Сохраните след выполнения

После запуска запишите:

• текст или версию SQL;
• параметры и часовой пояс периода;
• проект, набор данных и регион;
• время запуска и job_id;
• оценку и фактический объём обработанных байтов;
• число строк результата;
• контрольные суммы и найденные исключения.

В INFORMATION_SCHEMA.JOBS доступны поля statement_type, total_bytes_billed, total_bytes_processed, состояние и сообщение об ошибке. Это помогает разобрать уже выполненный запрос и найти дорогие задания. Доступ к представлению зависит от области запроса и разрешений пользователя.

Критерий готовности

SQL от ИИ готов к рабочему запуску, когда у проверяющего нет прав изменять производственные данные, тип оператора понятен, dry run проходит с приемлемой оценкой, стоимость ограничена, контрольный набор даёт ожидаемые строки и суммы, а job_id и параметры сохраняются в журнале. После этого запрос можно подключать к расписанию или дашборду с отдельным владельцем и процедурой отката.

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

Источники

• Источник 1
• Источник 2
• Источник 3
• Источник 4
• Источник 5
• Источник 6
• Источник 7
• Источник 8
• Источник 9

Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.