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 вже сьогодні.

Чому дата-інжиніринг визначає успіх ML-моделі

Минулого року до нас звернулася компанія, яка витратила $50 000 на навчання NLP-моделі, але отримала лише 60% точності на продакшені. Причина — data leakage через випадковий split часових даних. Перед тим як навчати модель, потрібно зрозуміти структуру даних: чи є дублі, як часто змінюється схема, наскільки репрезентативна вибірка. Дата-інжиніринг для ML — це не просто ETL, а побудова відтворюваної інфраструктури, яка робить навчання надійним, а перенавчання — передбачуваним. За досвідом нашої команди (понад 8 років у дата-інжинірингу, 30+ проектів у ML) кожна друга проблема в продакшені пов’язана не з архітектурою моделі, а з якістю даних. Замовте аудит ваших даних — оцінимо поточний пайплайн безкоштовно.

Як ETL-пайплайни для ML відрізняються від BI

ETL для аналітики та ETL для ML — різні завдання. В аналітиці важлива агрегація, у ML — індивідуальні записи з історією. В аналітиці train/val/test split не потрібен, у ML — критичний. В аналітиці skew даних заважає інтерпретації, у ML — безпосередньо впливає на якість моделі.

Інструменти. Apache Spark для великих обсягів (10GB+): PySpark з DataFrames, оптимізації через partitioning та caching. dbt для трансформацій поверх DWH (Snowflake, BigQuery, Redshift) — декларативно, версіонується, тестується. Pandas + Polars для обсягів до кількох GB — Polars у 5–10x швидше за Pandas на типових трансформаціях.

Temporal splits. Для ML важливо, що split за часом, а не випадковий. Якщо дані часові (транзакції, події користувачів), випадковий split дає data leakage: модель бачить «майбутні» дані при навчанні. Правило: train на періоді T1–T2, validation на T2–T3 (з gap для запобігання leakage), test на T3–T4. Неправильний split може коштувати 10–15% якості моделі на валідації. Temporal split best practices (scikit-learn docs)

Інкрементальні пайплайни. Модель перенавчається щотижня на нових даних. Потрібен пайплайн, який інкрементально додає нові записи до навчальної вибірки, не перевантажуючи все з нуля. Delta Lake або Apache Iceberg — формати з ACID-транзакціями, Change Data Capture, time travel.

Як уникнути training-serving skew за допомогою Feature Store

Feature Store вирішує проблему розсинхронізації між навчанням та інференсом. Найпідступніша помилка в ML-інфраструктурі — training-serving skew: ознака обчислюється по-різному в навчанні та в продакшені. Модель вчиться на «правильних» даних, а інференс отримує інші.

Feast (open source) — офлайн store на Parquet/Delta в S3 для навчання, онлайн store на Redis для low-latency інференсу (<10ms). Feature definitions як Python-код:

from feast import FeatureView, Field
from feast.types import Float32, Int64

user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="avg_session_duration", dtype=Float32),
    ],
    ttl=timedelta(days=7),
    source=user_features_source,
)

Один definition використовується всюди — немає розбіжностей.

Потокові ознаки. Коли ознака має оновлюватися в реальному часі (кількість транзакцій за останні 10 хвилин), потрібна потокова обробка. Apache Kafka + Apache Flink або Kafka Streams для обчислення ознак у реальному часі → запис в онлайн store. Складніше, дорожче, потрібно лише коли staleness ознак критична для якості.

Розмітка даних: як не витратити бюджет даремно

Розмітка — найтрудомісткіша та недооцінювана частина ML-проекту. Погано розмічені дані не виправить жодна архітектура.

Label Studio — open source, підтримує розмітку зображень (bounding box, polygon, segmentation), тексту (NER, класифікація), аудіо, відео. Піднімається за 10 хвилин через Docker. Для невеликих команд — перший вибір.

Оцінка якості розмітки. Inter-annotator agreement — наскільки згодні розмітники між собою. Cohen's Kappa > 0.8 — добре, 0.6–0.8 — прийнятно, < 0.6 — завдання неоднозначне або інструкція погана. Перетин розміток (10–20% прикладів розмічають два незалежних анотатори) — обов'язкова практика.

Active learning. Не розмічати випадкові приклади, а вибирати ті, на яких модель найбільш невпевнена (low confidence, high uncertainty). Дозволяє досягти тієї ж якості при 50–70% обсягу розмітки. Modals, Prodigy, Label Studio підтримують active learning workflows. На одному з проектів для NLP ми скоротили бюджет на розмітку в 2,5 рази завдяки active learning — економія склала $15 000 на 100 000 розмічених прикладів.

Синтетичні дані. Коли реальних даних мало або отримати їх дорого. Для CV: рендеринг у Blender/Unity з реалістичними текстурами (domain randomization). Для NLP: parafrase через LLM, backtranslation. Ризик: модель навчається на distribution синтетичних даних, а не реальних — потрібна обережність і перевірка на реальному holdout.

Якість даних: валідація та моніторинг

Great Expectations — de facto стандарт для data validation у ML-пайплайнах. Expectations — це декларативні твердження про дані: «колонка age містить значення від 0 до 120», «колонка user_id не містить null», «розподіл amount не відхиляється більш ніж на 20% від baseline». Запускається в пайплайні, при провалі — блокує проходження.

Pandera — Pythonic alternative для pandas/polars DataFrames. Schema-based validation з type hints:

import pandera as pa

schema = pa.DataFrameSchema({
    "user_id": pa.Column(int, nullable=False),
    "score": pa.Column(float, pa.Check.between(0, 1)),
    "label": pa.Column(str, pa.Check.isin(["positive", "negative", "neutral"])),
})

Data freshness. Модель очікує дані за останні N днів. ETL впав, дані не оновилися — модель використовує застарілі ознаки. Моніторинг свіжості даних: timestamp останнього запису в кожній таблиці, алерт при затримці > порога.

Дедуплікація. Дублікати в навчальній вибірці завищують метрики (одні й ті самі приклади в train і val) і спотворюють ваги моделі. MinHash LSH для наближеної дедуплікації великих датасетів. Для точної — хеш за нормалізованим контентом.

Сховища та формати

Для більшості ML-проектів на старті: Parquet в S3 + DVC для версіонування. Delta Lake або Iceberg — коли з'являється потреба в інкрементальних оновленнях або time travel.

Типові помилки при побудові пайплайнів

• Пропуск перевірки свіжості даних. Якщо ETL падає вночі, а модель запускається вранці — вона отримує дані 24-годинної давності. Рішення: алерт при затримці > 30 хвилин.
• Відсутність версіонування даних. Не можна відтворити експеримент, бо дані змінилися. DVC або Delta Lake time travel виправляють це.
• Забувають про schema evolution. Нове поле з’являється, а пайплайн падає. Автоматичне виявлення змін схеми через Great Expectations.

Active learning дозволяє скоротити бюджет на розмітку до 50–70%. На одному проекті це склало економію $15 000 на 100 000 розмічених прикладів. Закажіть консультацію — розрахуємо потенційну економію для вашого кейсу.

Що входить у проект з дата-інжинірингу для ML

Ми надаємо повний цикл:

• Аудит існуючих даних та пайплайнів (1 тиждень).
• Проектування архітектури: вибір інструментів, форматів, способів розмітки.
• Реалізація ETL/ELT пайплайну з валідацією та моніторингом.
• Документація коду та процесів (model card, data card).
• Навчання вашої команди роботі з пайплайном.
• SLA на супровід та підтримку.

Терміни: від 2 до 6 тижнів залежно від обсягу даних і складності інтеграцій.

Як ми будуємо пайплайн: покроково

1. Аудит існуючих даних. Профілювання: ydata-profiling (колишній pandas-profiling) генерує HTML-репорт зі статистиками, дистрибуціями, кореляціями, missing values за хвилини.
2. Проектування пайплайну. Визначаємо джерела даних, частоту оновлення, вимоги до latency ознак, обсяги.
3. Реалізація та тестування. Unit-тести на трансформації, integration-тести на пайплайн, data validation через Great Expectations.
4. Деплой та моніторинг. Алерти на freshness, quality checks, аномалії в обсягах даних.

Чому варто довірити це нам

Ми займаємося дата-інжинірингом та ML з понад 8-річним досвідом. За цей час реалізували понад 40 проектів — від побудови пайплайнів для NLP-моделей до розмітки датасетів для комп’ютерного зору. Гарантуємо відтворюваність пайплайнів та повну прозорість процесів. У кожному проекті використовуємо інструменти з відкритим кодом, щоб ви не були прив’язані до вендора.

Зв’яжіться з нами для безкоштовного аудиту ваших даних — оцінимо поточний пайплайн і запропонуємо roadmap. Замовте побудову ML-пайплайну під ключ.