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 іде ще далі, заявляючи про покращення до 10 разів на відповідних запитах і скорочення загального часу слотів до 40 відсотків. Шлях виконання коротких запитів обіцяє до 10 разів нижче використання слотів для малих запитів і затримку P99 менше секунди, а пропускна здатність у деяких клієнтських навантаженнях — до 3 разів вища. Fluid scaling, модель посекундної тарифікації за спожиті слоти, позиціонується як таке, що в середньому скорочує витрати до 34 відсотків для навантажень з автомасштабуванням.

Єдиний названий клієнт, ad-tech компанія RISE, повідомляє про 25-відсоткове скорочення інфраструктурних витрат лише від fluid scaling на навантаженні, що обробляє понад 1 петабайт даних на день і 3 трильйони ставок на місяць. Це найближче до реального контрольного показника в анонсі, і він нижчий за власний середній показник Google «до 34 відсотків». Джерело не розкриває, якою була позиція RISE щодо зобов'язань по слотах до впровадження fluid scaling, а це важливо, оскільки посекундна тарифікація допомагає нерівномірним навантаженням набагато більше, ніж рівномірним. Моя груба оцінка: команди з коефіцієнтом автомасштабування вище 3x між піком і мінімумом можуть очікувати економії в діапазоні RISE, команди нижче 1,5x в кращому разі отримають покращення в одиниці відсотків.

Що Насправді Нового

Якщо відкинути маркетинг, у цьому циклі по-справжньому нові три речі.

По-перше, history-based optimisations. Традиційні оптимізатори на основі вартості покладаються на статичну статистику, зібрану операціями типу ANALYZE, плюс оцінки кардинальності, які прогресивно погіршуються зі збільшенням глибини з'єднань. Будь-хто, хто налагоджував перемикання планів Postgres на таблиці, що виросла в 10 разів за тиждень, знає цей режим відмови. BigQuery тепер записує статистику виконання з попередніх запусків і повертає її в планування для схожих запитів. Важливо те, що Google стверджує: система скасовує будь-яку оптимізацію, яка не покращує продуктивність або спричиняє регресію. Ця поведінка із замкнутим циклом і є головним. Адаптивне виконання запитів не є новинкою (Spark і Snowflake мають власні варіанти), але самоскасовуючий оптимізатор із постійною пам'яттю між виконаннями запитів — це крок далі, ніж адаптація в рамках одного запиту.

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

По-третє, fluid scaling з посекундною тарифікацією слотів. BigQuery завжди тарифікував за слот-секунди теоретично, але гранулярність автомасштабувальника мала величезне значення для фактичного рахунку. Перехід до справжньої посекундної тарифікації спожитих слотів усуває податок на округлення, який найбільше бив по нерівномірних навантаженнях. Це зміна, яка найшвидше відобразиться на рахунках з мінімальними інженерними зусиллями з боку клієнтів.

Advanced runtime із ширшим використанням SIMD та векторизованим виконанням — це наздоганяння до базового рівня, а не новизна. Кожен серйозний аналітичний рушій пройшов цим шляхом. Це важливо для сукупного заявленого скорочення часу слотів на 40 відсотків, але це не диференціатор.

Що Вже Закладено в Очікуваннях Data-команд

Більшість старших керівників дата-платформ очікували появи самоналаштування на рівні сховища. Економіка змушувала до цього. Коли AI-агенти та автоматизовані пайплайни генерують на порядки більше запитів, ніж людини-аналітики, підказки з індексами вручну, керування матеріалізованими представленнями та переписування запитів не масштабуються. Databricks рухається в тому ж напрямку з предиктивною оптимізацією, а Snowflake нашаровує більше автоматизації у свій сервіс прискорення запитів. Тож напрямок уже врахований в очікуваннях.

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

Також недооціненим є аспект Iceberg. Google прямо заявив, що ті ж оптимізації — включно з просуванням фільтрів, обрізанням на основі метаданих, пропуском сторінок та асинхронним читанням — застосовуються до таблиць Apache Iceberg і рідного сховища BigQuery. Це Google враховує сценарій відходу до лейкхаусу. Якщо можна отримати оптимізацію запитів рівня сховища для таблиць Iceberg в об'єктному сховищі, аргумент на користь зберігання даних у пропрієтарному форматі слабшає. Для команд, які вже запускають трансформації dbt поверх BigQuery, це робить агностичне до формату моделювання більш реальним без штрафу за продуктивність.

Невирішене питання, яке я б підняв першим для будь-якого CTO, що оцінює це рішення: Google не розкрив, як history-based optimisations поводяться на навантаженнях із запитами з високим семантичним дрейфом, де «схожі» запити важко зіставити. Якщо евристика зіставлення консервативна, функція допомагає вузькому колу повторюваних запитів. Якщо агресивна, хибні спрацьовування можуть призводити до регресій, які потім має перехоплювати система скасування. Джерело не вказує, скільки часу займає конвергенція зворотного зв'язку, а це важливо, оскільки ця затримка обмежує найгірший сценарій витрат від невдалого рішення з оптимізацією.

Альтернативна Думка

Очевидне трактування: самоналаштовувані сховища перетворюють навички дата-інженерії на товар і повертають переговорну силу до хмарного провайдера. Альтернативне трактування — протилежне: самоналаштування ускладнює прогнозування витрат, а не спрощує.

Подумайте, що fluid scaling плюс history-based optimisations означає для фінансової команди, яка намагається скласти бюджет. Обчислення утримують ресурси менше часу. Оптимізації застосовуються та скасовуються на основі зворотного зв'язку під час виконання, якого клієнт не бачить. Споживання слотів стає функцією внутрішніх рішень Google про те, яким історичним патернам довіряти. Рахунок у середньому зменшується, але дисперсія навколо цього середнього, мабуть, зростає. Для навантажень із суворими SLA щодо вартості одного запиту (ставки ad-tech в реальному часі, розрахунки фінансових ризиків, обчислення коефіцієнтів в iGaming) дисперсія важливіша за середнє.

Також варто розглянути аргумент про прив'язку до вендора. Чим більше рушій налаштовується на основі вашої конкретної історії запитів, тим дорожчим стає міграція. Ваша ефективна продуктивність у BigQuery включає місяці накопиченої статистики виконання, яка не переноситься на інший рушій. Це міцніший захисний рів, ніж будь-коли були пропрієтарні діалекти SQL.

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

Ключові Висновки

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