**BigQuery: что это и чем отличается от обычного хранилища**

**BigQuery: что это и чем отличается от обычного хранилища**

Google BigQuery — это управляемое облачное хранилище данных (data warehouse) с моделью оплаты за запросы и объём хранения. Внутри лежит колоночное (columnar) хранение, движок обрабатывает SQL-затросы параллельно на сотнях узлов, поэтому аналитика по миллиардам строк занимает секунды, а не часы.

Чем отличается от привычного Postgres/MySQL:
— **Postgres/MySQL** — это OLTP-системы. Они заточены под транзакции: быстро вставить, обновить, достать одну запись по ключу. Аналитический `SELECT COUNT … GROUP BY` на сотнях миллионов строк в них занимает минуты и кладёт базу.
— **BigQuery** — это OLAP-система. Она заточена под массовые агрегации, оконные функции, джойны больших таблиц. Точечные одиночные записи — не её сильная сторона, и доставать из неё «одного пользователя по id» в лендинге не надо.

Ещё важный нюанс: BigQuery — **serverless**. Нет сервера, который надо администрировать, выбирать размер диска и считать кластер. Ёмкость масштабируется сама. Это меняет роль аналитика: меньше инфраструктуры, больше логики запросов и моделей данных.

Типичные ошибки применения:
— Тащить в BigQuery сырые события из рекламных кабинетов и хранить их «как есть» без партиционирования и кластеризации. Стоимость запросов вырастает в разы.
— Использовать BigQuery как замену CRM. Для транзакционных задач и обновлений строк он не предназначен.
— Считать, что `SELECT *` бесплатен. В колоночных хранилищах цена запроса зависит от объёма прочитанных колонок, поэтому `SELECT * FROM huge_table` — дорогая привычка из обычных баз.

Пример. Маркетолог выгружает расходы из *Google Ads* (система контекстной рекламы) и *Meta Ads* (рекламная платформа компании Meta) → грузит в BigQuery → джойнит с заказами из CRM по `user_id` и `date` → строит когорты по первому касанию. Запрос на 200 млн строк отрабатывает за 5–10 секунд, в обычном SQL-сервере на ноутбуке это были бы минуты простоя.

Главный сдвиг 2026 года: privacy-first атрибуция (server-side, MMM, incrementality) требует хранить сырые события уровня пользователя долго и считать по ним сложные модели. Локальная база здесь уже бутылочное горлышко — BigQuery закрывает эту задачу из коробки.

— @BigQuery4MarketingPro