BigQuery: serverless DWH от Google

Если Snowflake — это история про разделение storage и compute с явным управлением warehouses, то BigQuery — это полный serverless подход. Никаких кластеров, никаких машин, никакого “запусти warehouse перед запросом”. Просто пишешь SQL — Google делает остальное.

BigQuery появился в 2010 году как коммерческое воплощение Dremel — внутренней технологии Google для анализа petascale данных. К 2026 году BigQuery — главный конкурент Snowflake и стандарт для всех, кто работает в Google Cloud.

Главная идея: serverless

В Snowflake ты создаёшь warehouse, выбираешь размер, ждёшь старта. В BigQuery — ничего этого нет:

Дополнительные особенности:

• Никаких clusters/warehouses. Просто SQL. BigQuery сам выделяет compute (slots) под запрос.
• Storage в Colossus — внутренняя распределённая файловая система Google, оптимизированная для масштаба.
• Schema нужна, но автоматически инферится из данных при загрузке.
• Партиционирование и кластеризация — есть, но опциональны (хотя на практике обязательны для cost).

Slots: единица compute

В отличие от Snowflake credits, BigQuery считает compute в slots. Slot — это абстрактная единица параллельного исполнения (примерно 1 CPU плюс RAM). Простой запрос может занять 10 slots на 0.5 секунды. Сложный — 2000 slots на 30 секунд. Сколько slots использует запрос — BigQuery решает сам, опираясь на размер таблиц и план запроса.

Pricing model: on-demand vs flat-rate

BigQuery имеет две модели оплаты compute:

On-demand: платишь за каждый просканированный байт, без учёта потраченного compute. Одинаковый запрос будет стоить одинаково независимо от загрузки кластера.

Editions (flat-rate): покупаешь slots на постоянной основе (от 100 slots/мес = около 1700 USD). Запросы используют твой резерв, лишние ждут в очереди или используют scale-up автоматически.

Колоночный storage: Capacitor

BigQuery хранит данные в собственном колоночном формате Capacitor (преемник ColumnIO):

• Колонки хранятся отдельно, со своим типом сжатия для каждой.
• Dictionary encoding для повторяющихся значений (страны, статусы).
• RLE (run-length encoding) для последовательностей одинаковых.
• Метаданные на блоки для skip-сканирования.

Это даёт мощную колонoчную обрезку: запрос SELECT name FROM users сканирует только колонку name. Если в таблице 100 колонок, экономия может быть в 100x.

Партиционирование и кластеризация

BigQuery поддерживает партиционирование таблиц для уменьшения сканируемых байтов:

CREATE TABLE my_dataset.events (
  event_id INT64,
  user_id INT64,
  event_at TIMESTAMP,
  payload JSON
)
PARTITION BY DATE(event_at)
CLUSTER BY user_id;

• PARTITION BY — физическое разделение по дате (или по integer-range). Запрос WHERE event_at >= '2026-05-01' сканирует только нужные партиции.
• CLUSTER BY — внутри партиции данные сортируются по указанным колонкам. Запросы по user_id будут эффективнее.

Critical insight: в BigQuery партиционирование обязательно для больших таблиц. Без партиционирования каждый запрос сканирует всё и стоит дорого.

BigQuery ML

С 2019 года BigQuery умеет тренировать ML-модели прямо в SQL:

-- Тренировка модели
CREATE MODEL my_dataset.churn_model
OPTIONS(model_type='LOGISTIC_REG') AS
SELECT age, monthly_spend, tenure_days, churned AS label
FROM my_dataset.customer_features;

-- Прогноз
SELECT *
FROM ML.PREDICT(MODEL my_dataset.churn_model,
  (SELECT age, monthly_spend, tenure_days FROM new_customers));

Поддерживаются типы моделей: linear/logistic regression, K-means clustering, time series (ARIMA_PLUS), DNN, boosted trees (XGBoost), AutoML, import TensorFlow models. Это не замена ML-команде с Python/PyTorch, но для бизнес-задач (churn prediction, segmentation) — отличный quick-start без MLOps-инфраструктуры.

Streaming и Storage Write API

BigQuery может принимать данные в реальном времени:

• Streaming inserts (legacy) — медленные, дорогие.
• Storage Write API (новый, рекомендуется) — быстрее, дешевле, exactly-once семантика. Поддерживает upserts через CDC.

Это позволяет строить real-time pipelines прямо в BigQuery без отдельного стримингового движка.

Сильные и слабые стороны

Плюсы:

• Полный serverless — никаких warehouses.
• Богатая функциональность: BigQuery ML, GIS, JSON functions, Storage Write API из коробки.
• Petabyte-scale работает out-of-box.
• Интеграция с GCP-сервисами: Dataflow, Vertex AI, Looker.

Минусы:

• On-demand pricing непредсказуем — одно SELECT * может стоить тысячи долларов.
• Доступен только в GCP (без multi-cloud, в отличие от Snowflake).
• DML (UPDATE/DELETE) есть, но дорогой и с лимитами.
• Без партиционирования — full scan каждого запроса.

Когда выбирать BigQuery:

• Компания на GCP.
• Нужен полный serverless, минимум DevOps.
• ML use cases прямо из SQL.
• Большой объём ad-hoc-запросов без стабильной нагрузки (on-demand).

Реальный пример SQL

-- Эффективный запрос: только нужные партиции и колонки
SELECT
  DATE(order_at) AS day,
  COUNT(*) AS orders_cnt,
  SUM(amount) AS revenue
FROM my_dataset.orders
WHERE DATE(order_at) BETWEEN '2026-05-01' AND '2026-05-17'
  AND status = 'paid'
GROUP BY day
ORDER BY day;

-- Сканирует только 17 партиций (около 17 дней)
-- и только колонки order_at, amount, status — копейки cost

Попробуй сам

Создай бесплатный GCP-аккаунт (300 USD кредитов на 90 дней). Открой BigQuery в Console. Запусти запрос к bigquery-public-data.london_bicycles.cycle_hire — это публичный датасет. Заметь, что не нужно создавать warehouse, просто пишешь SQL. Попробуй запрос с SELECT * и SELECT col1, col2 — увидишь разницу в bytes processed (это и есть твоя стоимость). Создай партиционированную таблицу и сравни performance с не-партиционированной. Поэкспериментируй с BigQuery ML — CREATE MODEL на публичных данных.