BigQuery переходит на самонастройку: сокращение слотов на 40% и посекундная тарификация

Google заявляет о сокращении использования слотов BigQuery до 40 процентов на стандартных бенчмарках по итогам 2025 года, а также о повышении производительности запросов на 35 процентов за тот же период. Это улучшения на уровне движка, которые не требуют от клиентов переписывать ни строчки SQL — и они дополняются новым самообучающимся оптимизатором, который, по словам Google, продолжит наращивать эти показатели в 2026 году. Для хранилища с тарификацией по слот-секундам разница в эффективности на 40 процентов — это не маркетинговая цифра. Это прямая строка в счёте.

Цифры

Как сообщило IT Brief Australia, BigQuery обеспечил улучшение производительности запросов до 35 процентов в течение 2025 года и сократил затраты на обработку — измеряемые в использовании слотов — до 40 процентов на стандартных бенчмарках. Google объясняет эти достижения тремя составляющими: процессором запросов, движком выполнения и моделью автомасштабирования. Обновление 2026 года добавляет поверх этой основы самообучающуюся систему под названием history-based optimisations.

Данные по отдельному клиенту, которые Google решил раскрыть, интереснее агрегированного бенчмарка. У одной неназванной компании время выполнения P90 сократилось до 50 процентов, использование слотов снизилось на 15 процентов — и это без каких-либо регрессий. Вдумайтесь в эти цифры. Улучшение P90 на 50 процентов при снижении слотов всего на 15 процентов означает, что выигрыш обеспечили более умные планы выполнения, а не сокращение вычислительных ресурсов. Система стала одновременно быстрее и дешевле, однако экономия была меньшей частью этой истории для данной нагрузки.

Новая advanced runtime идёт дальше: заявляется улучшение до 10x на подходящих запросах и сокращение общего времени слотов до 40 процентов. Быстрый путь для коротких запросов обещает снижение использования слотов до 10x для малых запросов, латентность P99 менее секунды и пропускную способность до 3x выше при некоторых пользовательских нагрузках. Fluid scaling — посекундная модель тарификации потреблённых слотов — позиционируется как инструмент со средним снижением затрат до 34 процентов для нагрузок с автомасштабированием.

Единственный названный клиент — компания RISE из сферы ad-tech — сообщает о сокращении инфраструктурных затрат на 25 процентов только за счёт fluid scaling при нагрузке, обрабатывающей более 1 петабайта данных в день и 3 триллиона ставок в месяц. Это наиболее близкая к реальному миру точка отсчёта в анонсе, и она ниже собственного показателя Google «до 34 процентов» в среднем. Источник не раскрывает, какова была структура слот-коммитов RISE до fluid scaling, а это важно: посекундная тарификация помогает нагрузкам с всплесками значительно больше, чем стабильным. Моя грубая оценка: компании с соотношением пик/минимум при автомасштабировании выше 3x могут рассчитывать на экономию в духе RISE, компании ниже 1,5x в лучшем случае увидят однозначные проценты улучшения.

Что действительно нового

Если убрать маркетинг, в этом цикле по-настоящему новыми являются три вещи.

Первое — history-based optimisations. Традиционные оптимизаторы на основе стоимости опираются на статическую статистику, собранную операциями типа ANALYZE, плюс оценки кардинальности, которые становятся всё менее точными по мере углубления джойнов. Каждый, кто отлаживал смену плана в Postgres на таблице, выросшей в 10 раз за неделю, знает этот сценарий. BigQuery теперь записывает runtime-статистику из предыдущих выполнений и использует её при планировании похожих запросов. Принципиально важно, что Google утверждает: система отменяет любую оптимизацию, которая не улучшает производительность или вызывает регрессию. Именно это поведение с замкнутым циклом является ключевым. Адаптивное выполнение запросов — не новинка (Spark и Snowflake имеют свои варианты), но самоотменяющийся оптимизатор с постоянной памятью между выполнениями запросов — это шаг вперёд по сравнению с адаптацией в рамках одного запроса.

Второе — быстрый путь для коротких запросов. Сокращение этапов выполнения и уменьшение перемешивания данных для достижения латентности P99 менее секунды — это признание BigQuery в том, что дашбордные и прикладные нагрузки плохо обслуживались его архитектурой с приоритетом на распределённость. Заявленное снижение слотов в 10x для коротких запросов показательно: такие запросы были чрезмерно избыточны в старой модели выполнения. Распределённое перемешивание для запроса, затрагивающего 10 000 строк — чистые накладные расходы. BigQuery движется на территорию, которую ClickHouse и другие OLAP-движки занимали для высококонкурентного обслуживания.

Третье — fluid scaling с посекундной тарификацией слотов. BigQuery всегда тарифицировал по слот-секундам в принципе, но гранулярность автомасштабирования имела огромное значение для фактического счёта. Переход к реальной посекундной тарификации потреблённых слотов устраняет налог на округление, который сильнее всего бил по нагрузкам с всплесками. Это изменение быстрее всего отразится на счетах при минимальных инженерных усилиях со стороны клиентов.

Advanced runtime с расширенным использованием SIMD и векторизованным выполнением — это догоняющее движение до уровня обязательного минимума, а не новаторство. Каждый серьёзный аналитический движок прошёл этот путь. Это важно для общего утверждения о 40-процентном сокращении времени слотов, но не является дифференциатором.

Что уже учтено командами по работе с данными

Большинство старших руководителей дата-платформ ожидали появления самонастройки на уровне хранилища. Экономика вынуждала к этому. Когда AI-агенты и автоматизированные конвейеры генерируют на порядки больше запросов, чем аналитики-люди, ручные подсказки по индексам, управление материализованными представлениями и переписывание запросов не масштабируются. Databricks движется в том же направлении с predictive optimisation, а Snowflake добавляет всё больше автоматизации в свой сервис ускорения запросов. Так что направление уже учтено рынком.

Что не учтено: конкретное заявление о том, что history-based optimisations работают без изменений SQL или схем и самостоятельно отменяются при регрессии. Если это выдержит проверку в продакшне на реальных нагрузках, это изменит операционный профиль BigQuery-инсталляций. Команды, которые сейчас держат выделенных performance-инженеров для просмотра дашбордов медленных запросов, смогут перераспределить этот ресурс. DBA-смежные роли в крупных BigQuery-компаниях получили более трудный вопрос о своих следующих 24 месяцах.

Также недооценён аспект Iceberg. Google явно заявил, что те же оптимизации — включая проталкивание фильтров, обрезку на основе метаданных, пропуск страниц и асинхронное чтение — применяются к таблицам Apache Iceberg и нативному хранилищу BigQuery. Это Google заранее отвечает на сценарий перехода к lakehouse. Если можно получить оптимизацию запросов уровня хранилища над таблицами Apache Iceberg в объектном хранилище, аргумент в пользу хранения данных в проприетарном формате слабеет. Для команд, уже запускающих трансформации dbt поверх BigQuery, это делает формат-агностичное моделирование более жизнеспособным без потери производительности.

Открытый вопрос, который я бы выделил особо для любого CTO, оценивающего это решение: Google не раскрыл, как history-based optimisations ведут себя на нагрузках с высокой семантической изменчивостью, где «похожие» запросы сложно сопоставить. Если эвристика сопоставления консервативна, функция помогает узкому кругу повторяющихся запросов. Если она агрессивна, ложные срабатывания могут порождать регрессии, которые системе отмены потребуется устранять. Источник не говорит, сколько времени занимает сходимость цикла обратной связи, а это важно, поскольку эта латентность определяет максимально возможные потери от неудачного решения по оптимизации.

Контрарный взгляд

Очевидная интерпретация: самонастраивающиеся хранилища превращают навыки дата-инженерии в товар и смещают переговорную силу обратно к облачному провайдеру. Контрарная интерпретация — противоположная: самонастройка усложняет прогнозирование затрат, а не упрощает его.

Представьте, что означает fluid scaling плюс history-based optimisations для финансовой команды, формирующей бюджет. Вычислительные ресурсы удерживаются меньше времени. Оптимизации применяются и отменяются на основе runtime-обратной связи, которую клиент не видит. Потребление слотов становится функцией внутренних решений Google о том, каким историческим паттернам доверять. Счёт в среднем снижается, но дисперсия вокруг этого среднего, вероятно, возрастает. Для нагрузок с жёсткими SLA по стоимости одного запроса (real-time bidding в ad-tech, расчёт финансовых рисков, вычисление коэффициентов в iGaming) дисперсия важнее среднего.

Есть и аргумент о привязке к платформе. Чем больше движок настраивает себя на основе вашей конкретной истории запросов, тем дороже обходится миграция. Ваша эффективная производительность в BigQuery включает месяцы накопленной runtime-статистики, которая не переносится на другой движок. Это более прочный ров, чем проприетарные диалекты SQL когда-либо создавали.

Моё мнение: для компаний со стабильными, хорошо понятными нагрузками тезис «ручная настройка мертва» преувеличен. Для компаний с нагрузками, генерируемыми агентами или высоковариативными, это меняет операционную модель так, что для полного осмысления потребуется полный бюджетный цикл. Если заявления Google подтвердятся, мы должны увидеть ускорение удержания чистой выручки BigQuery среди клиентов верхнего квартиля в течение следующих четырёх кварталов, а также как минимум один крупный публичный кейс миграции с Snowflake или Redshift на BigQuery с явным указанием на эти функции. Если ни того ни другого не произойдёт к третьему кварталу 2027 года, практическое значение анонса оказалось меньше заявленного.

Ключевые выводы

• Заявленное Google сокращение затрат на слоты на 40 процентов по итогам 2025 года — это цифра, которая имеет значение. При тарификации по слот-секундам эффективность движка напрямую отражается в счёте.
• History-based optimisations с автоматической отменой — по-настоящему новый элемент. Адаптивное выполнение не ново, но постоянное обучение между запросами с самостоятельным откатом — шаг вперёд по сравнению с текущими аналогами Snowflake и Spark.
• Быстрый путь для коротких запросов (снижение слотов в 10x, P99 менее секунды) — это BigQuery, выходящий на территорию ClickHouse-стиля обслуживания. Нагрузки дашбордов с высокой конкурентностью должны пересмотреть экономику затрат.
• Посекундная тарификация fluid scaling больше всего выгодна нагрузкам с всплесками. Кейс RISE показывает сокращение инфраструктурных затрат на 25 процентов — ниже среднего показателя в 34 процента, что говорит о высокой вариативности в зависимости от типа нагрузки.
• Открытый вопрос: Google не раскрыл, как быстро сходятся history-based optimisations и как они справляются с семантической изменчивостью. Если сходимость занимает недели, функция помогает повторяющимся нагрузкам намного больше, чем исследовательским. Проверяемый прогноз: ждите как минимум одного крупного публичного кейса миграции с упоминанием этих функций к третьему кварталу 2027 года — иначе практический эффект был преувеличен.