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='RU',
  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='RU'). Идеально для прогноза продаж или нагрузки — точность на 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 для регрессии.
• Затраты: низкие — менее 1 USD за 1M строк обучения (в зависимости от типа модели).

Когда стоит выбрать 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 уже сегодня.

Data Engineering для ML: пайплайны, разметка и качество данных

«У нас много данных» — фраза, которая на деле часто означает «у нас много сырых логов в S3, которые никто не трогал два года». Перед тем как обучить модель, нужно понять, что вообще есть: какова структура, есть ли дубли, как часто меняется схема, насколько репрезентативна выборка.

Data Engineering для ML — не просто ETL. Это построение воспроизводимой инфраструктуры данных, которая делает обучение моделей надёжным, а переобучение — предсказуемым. По опыту нашей команды (8 лет в дата-инжиниринге, более 30 проектов в ML) каждая вторая проблема в продакшене связана не с архитектурой модели, а с качеством данных.

ETЛ-пайплайны для ML: чем отличаются от BI

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

Инструменты. Apache Spark (Wikipedia) для больших объёмов (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% качества модели на валидации.

Инкрементальные пайплайны. Модель переобучается еженедельно на новых данных. Нужен пайплайн, который инкрементально добавляет новые записи к обучающей выборке, не перегружая всё с нуля. 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.

Синтетические данные. Когда реальных данных мало или получить их дорого. Для 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.

Что входит в проект по дата-инжинирингу для ML

Мы предоставляем полный цикл:

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

Как мы строим пайплайн: пошагово

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

Почему стоит доверить это нам

Мы занимаемся дата-инжинирингом и ML с 2016 года. За это время реализовали более 40 проектов — от построения пайплайнов для NLP-моделей до разметки датасетов для компьютерного зрения. Гарантируем воспроизводимость пайплайнов и полную прозрачность процессов. В каждом проекте используем инструменты с открытым исходным кодом, чтобы вы не были привязаны к вендору.

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