В BigQuery дашборды нужно обновлять чаще для "свежести", но каждый лишний запуск увеличивает счёт за обработанные байты. Как принять решение о частоте обновления и донести его до команды?

Короткий ответ

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

Как это работает подробнее

В BigQuery стоимость on-demand в основном определяется сканируемыми байтами. Оцените dry run, историю jobs и объём партиций, затем сравните сценарии расписания в месячном бюджете.

Разделите тяжёлую подготовку и лёгкий serving-слой: инкрементально обновляйте агрегаты по новым партициям, а дашборд пусть читает небольшую таблицу. Кэширование и materialized views полезны, если подходят ограничениям запроса.

Пример кода

bigquery_job_cost.sqlКопировать

SELECT DATE(creation_time) AS run_date,
       COUNT(*) AS runs,
       SUM(total_bytes_billed) / POW(1024, 4) AS tebibytes_billed
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND labels.key = 'dashboard'
GROUP BY run_date
ORDER BY run_date;

Что использовать на практике

• Считайте сценарии. Покажите стоимость обновления раз в сутки, час и пятнадцать минут.
• Ограничивайте сканирование. Фильтруйте партиции, избегайте SELECT * и пересчитывайте только изменившиеся окна.
• Пересматривайте SLA. Рост таблиц меняет цену даже при неизменном расписании.

Подводные камни

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