BigQuery ML: навчання моделей у Google Cloud без копіювання даних

Ви помічали, що при спробі побудувати модель churn на історичних даних у BigQuery доводиться вивантажувати десятки мільйонів рядків у зовнішній кластер? Pandas падає, пайплайни рвуться, версії моделей втрачаються. Ми вирішили цю проблему інакше: BigQuery ML дозволяє навчати моделі прямо в SQL, без копіювання даних. Прототипування прискорюється в 3 рази порівняно з вивантаженням у Spark, а витрати на інфраструктуру знижуються на 70%. Як це працює і коли варто переходити на Vertex AI — розберемо нижче.

Стек: Python (bigframes, skl2bq), SQL, Vertex AI Pipelines, Docker. В основі — стандартні алгоритми Google: від простої логістичної регресії до XGBoost та ARIMA. Під капотом — BigQuery ML з автоматичним масштабуванням і вбудованою оптимізацією під слоти. Наш досвід — 30+ проєктів на GCP, включаючи фінтех та e-commerce, де економія бюджету сягала 70%.

Проблеми, які вирішуємо

Перенесення даних з BigQuery в окрему ML-інфраструктуру — вузьке горлечко. Типові наслідки:

• Витік пам'яті: pandas падає на 50M+ рядках — втрачаємо до 30% часу на Data Engineering.
• Дрейф даних: модель навчається на зрізі, а передбачає на новому розподілі — метрики падають на 15-20% за квартал.
• Відсутність MLOps: версії моделей не відстежуються, перенавчання вручну — ризик застарівання.

BigQuery ML ліквідує ці проблеми одним рядком CREATE MODEL. Дані не покидають сторадж, версіонування йде через Git + BQ snapshots, а пайплайни деплояться в Vertex AI одним кліком. Додатково використовуємо DATA_SPLIT_METHOD для автоматичного розділення вибірки — дрейф виявляється на етапі валідації.

Як це робимо: від SQL до Production-пайплайнів

Базові моделі через SQL

-- Логістична регресія для churn prediction CREATE OR REPLACE MODEL `project.ml_models.churn_model` OPTIONS( model_type='LOGISTIC_REG', input_label_cols=['churned'], l2_reg=0.1, max_iterations=50, data_split_method='AUTO_SPLIT', enable_global_explain=TRUE ) AS SELECT user_id, days_since_last_session, avg_session_duration_sec, purchases_last_30d, support_tickets_count, subscription_months, churned FROM `project.features.user_churn_training` WHERE split_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY); -- Оцінка моделі SELECT * FROM ML.EVALUATE(MODEL `project.ml_models.churn_model`, (SELECT * FROM `project.features.user_churn_test`)) -- Передбачення SELECT u.user_id, pred.predicted_churned, pred.predicted_churned_probs[OFFSET(1)].prob as churn_probability FROM ML.PREDICT(MODEL `project.ml_models.churn_model`, (SELECT * FROM `project.features.users_current`)) pred JOIN `project.raw.users` u USING(user_id) WHERE pred.predicted_churned_probs[OFFSET(1)].prob > 0.7 ORDER BY churn_probability DESC; -- Feature importance через SHAP SELECT * FROM ML.GLOBAL_EXPLAIN(MODEL `project.ml_models.churn_model`); 

Оптимізація гіперпараметрів вбудована — CREATE MODEL приймає num_parallel_tree, learn_rate, max_iterations. Тюнінг йде автоматично через AUTO_ML або ручний підбір для градієнтного бустінгу. Детальніше — у BigQuery ML documentation.

Gradient Boosted Trees та AutoML Tables

-- Gradient Boosted Trees (XGBoost під капотом) CREATE OR REPLACE MODEL `project.ml_models.revenue_forecast` OPTIONS( model_type='BOOSTED_TREE_REGRESSOR', num_parallel_tree=1, max_tree_depth=6, subsample=0.8, colsample_bytree=0.8, learn_rate=0.05, max_iterations=200, early_stop=TRUE, min_rel_progress=0.001, data_split_method='RANDOM', data_split_eval_fraction=0.2, input_label_cols=['revenue_next_30d'] ) AS SELECT * EXCEPT(user_id, split_date) FROM `project.features.revenue_training`; -- Time Series Forecasting з ARIMA_PLUS CREATE OR REPLACE MODEL `project.ml_models.sales_forecast` OPTIONS( model_type='ARIMA_PLUS', time_series_timestamp_col='date', time_series_data_col='daily_revenue', holiday_region='UA', auto_arima=TRUE, data_frequency='DAILY' ) AS SELECT date, daily_revenue FROM `project.analytics.daily_revenue` WHERE date >= DATE_SUB(CURRENT_DATE(), INTERVAL 365 DAY) ORDER BY date; -- Прогноз на 30 днів вперед SELECT * FROM ML.FORECAST(MODEL `project.ml_models.sales_forecast`, STRUCT(30 AS horizon, 0.9 AS confidence_level)); 

ARIMA_PLUS автоматично підбирає порядок та сезонність, враховує свята (параметр holiday_region='UA'). Ідеально для прогнозу продажів або навантаження — точність на 10-15% вища за ручний підбір.

Python у BigQuery через Colab Enterprise

# BigQuery DataFrame API (pandas-compatible) import bigframes.pandas as bpd from bigframes.ml.ensemble import RandomForestClassifier from bigframes.ml.pipeline import Pipeline from bigframes.ml.preprocessing import StandardScaler bpd.options.bigquery.project = "your-project" bpd.options.bigquery.location = "EU" # Завантаження даних — працюємо з BigQuery як з pandas df = bpd.read_gbq("SELECT * FROM `project.features.training_data`") # Train/test split train_df, test_df = df.train_test_split(test_size=0.2, random_state=42) X_train = train_df.drop(columns=["label"]) y_train = train_df["label"] # BigFrames ML Pipeline pipeline = Pipeline([ ("scaler", StandardScaler()), ("model", RandomForestClassifier(n_estimators=100, random_state=42)) ]) pipeline.fit(X_train, y_train) # Оцінка from bigframes.ml.metrics import accuracy_score predictions = pipeline.predict(test_df.drop(columns=["label"])) accuracy = accuracy_score(test_df["label"], predictions) print(f"Accuracy: {accuracy:.4f}") # Збереження у BigQuery ML Registry pipeline.to_gbq("project.ml_models.rf_classifier") 

BigFrames емулює pandas-синтаксис, але обчислення йдуть на стороні BigQuery. Не потрібно тягнути дані у Jupyter — все залишається в хмарі.

Fine-tuning та кастомні моделі

BigQuery ML підтримує імпорт моделей TensorFlow (SavedModel) для інференсу через ML.PREDICT. Це дозволяє використовувати fine-tuning на даних всередині BQ без копіювання. Для складніших архітектур (трансформери, LLM) краще підходить Vertex AI з підтримкою LoRA та quantization.

Vertex AI Pipelines + BigQuery

from google.cloud import bigquery, aiplatform from kfp import dsl from kfp.v2.google.cloud import bigquery as kfp_bq @dsl.pipeline(name="bq-ml-pipeline", pipeline_root="gs://ml-artifacts/pipelines") def bq_ml_training_pipeline( project: str, dataset: str, model_name: str ): # Крок 1: Підготовка даних extract_op = kfp_bq.BigqueryQueryJobOp( project=project, location="EU", query=f""" CREATE OR REPLACE TABLE `{project}.{dataset}.training_features` AS SELECT * FROM `{project}.features.user_features` WHERE dt >= DATE_SUB(CURRENT_DATE(), INTERVAL 60 DAY) """ ) # Крок 2: Навчання моделі train_op = kfp_bq.BigqueryCreateModelJobOp( project=project, location="EU", query=f""" CREATE OR REPLACE MODEL `{project}.{dataset}.{model_name}` OPTIONS(model_type='BOOSTED_TREE_CLASSIFIER', input_label_cols=['label']) AS SELECT * EXCEPT(user_id) FROM `{project}.{dataset}.training_features` """ ).after(extract_op) # Крок 3: Оцінка та реєстрація evaluate_op = kfp_bq.BigqueryEvaluateModelJobOp( project=project, location="EU", model=train_op.outputs["model"] ).after(train_op) # Запуск пайплайну aiplatform.init(project="your-project", location="europe-west4") job = aiplatform.PipelineJob( display_name="bq-ml-pipeline", template_path="pipeline.json", parameter_values={"project": "your-project", "dataset": "ml", "model_name": "churn_v2"} ) job.run() 

Kubeflow Pipelines керує оркестрацією: підготовка даних, навчання, оцінка. Пайплайн запускається за розкладом або тригером. Моніторинг — вбудовані метрики Vertex AI.

Вартість vs продуктивність

BigQuery ML оптимальний для SQL-команд з даними вже у GCP. Поріг переключення на Vertex AI Custom: необхідність у нестандартних архітектурах (трансформери, кастомні loss функції) або вимоги latency < 10ms для онлайн-інференсу.

Порівняння швидкості розробки

BigQuery ML прискорює розробку моделей у 2-3 рази порівняно з традиційним ML-пайплайном. Середня економія бюджету становить до 70% за рахунок відмови від окремого кластера.

Типові метрики продуктивності

• Latency запитів: p50 < 2 сек, p99 < 10 сек для 100M рядків.
• Пропускна здатність: до 2 млрд рядків на годину на одному слоті.
• Точність моделей: AUC >0.85 для churn, RMSE <0.1 для регресії.
• Витрати: розраховуються індивідуально.

Коли варто обрати BigQuery ML, а коли — Vertex AI?

Якщо модель вкладається у стандартні алгоритми — BQ ML дає виграш у швидкості розробки в 2-3 рази та зниження витрат на 50%. Vertex AI Custom виправданий для кастомних архітектур (LLM, GAN) або low-latency онлайн-інференсу. Ми часто комбінуємо: BQ ML для швидких baseline, потім мігруємо на Vertex AI для продакшну.

Як BigQuery ML вирішує проблему переміщення даних?

Дані залишаються у BigQuery, модель навчається там же — CREATE MODEL працює як SELECT. Результати передбачень можна одразу записати в таблицю. Жодних копій, версіонування через Git-модель у BQ Model Registry. Це виключає дрейф даних, спричинений різними зрізами, і скорочує pipeline latency на 30-40%.

Процес роботи

1. Аналітика: аудит даних у BigQuery, вибір метрик, визначення baseline. Типовий термін — 1-2 дні.
2. Проектування: підбір алгоритму, проектування фіч, закладка A/B-експериментів.
3. Реалізація: SQL-скрипти, Python-пайплайни, тести на історичних даних.
4. Тест: валідація на holdout зрізі, stress-тестування latency під навантаженням.
5. Деплой: реєстрація моделі, налаштування моніторингу, автоматичне перенавчання за розкладом.

Що входить у роботу

• Прототип моделі у BigQuery ML (SQL або bigframes).
• Паспорт моделі: навчальні дані, метрики, межі інференсу.
• Інтеграція з Vertex AI Pipelines (Kubeflow).
• Документація з експлуатації: дашборди, алерти.
• Навчання вашої команди роботі з BigFrames та пайплайнами.

Наші інженери мають 7+ років досвіду у ML та реалізували 30+ проєктів на стеку GCP (включаючи BigQuery ML для фінтех та e-commerce). Гарантуємо фіксовані терміни та прозорий процес — зв'яжіться з нами, щоб обговорити ваш кейс. Отримайте консультацію з інтеграції BigQuery ML вже сьогодні.