BigQuery ML Tutorial en Español: Machine Learning con SQL y Dataform

¿Qué es BigQuery ML?

BigQuery ML es el enfoque de Machine Learning integrado en el ecosistema analítico de BigQuery. Su principal ventaja arquitectónica es sencilla: los datos y el entrenamiento pueden permanecer en el mismo motor analítico.

Esto cambia radicalmente el diseño de determinados proyectos. En un pipeline tradicional, podríamos extraer datos desde el Data Warehouse, convertirlos a DataFrames, transferirlos a una plataforma de entrenamiento y posteriormente devolver las predicciones al sistema analítico.

Con BigQuery ML, una parte importante de ese movimiento desaparece. SQL puede utilizarse para seleccionar observaciones, construir variables, entrenar el modelo, evaluar sus métricas y ejecutar predicciones.

Matriz de decisión: ¿BigQuery ML o Machine Learning externo?

La decisión no debe basarse en qué herramienta tiene más funcionalidades, sino en dónde están los datos, qué modelo necesitamos y cuál es el coste operacional de mantener el pipeline.

Arquitectura recomendada: Dataform + BigQuery ML

Una arquitectura robusta separa claramente el dato fuente, las transformaciones, las features, el entrenamiento y las predicciones. No conviene convertir una única consulta SQL gigante en todo el pipeline de Machine Learning.

Antipatrones: cómo disparar el coste de BigQuery ML

Implementación práctica: Machine Learning con SQL en BigQuery

El siguiente ejemplo utiliza regresión logística para predecir si una entidad pertenece a una clase determinada. El patrón es deliberadamente modular: primero construimos features, después creamos el modelo y finalmente generamos predicciones.

-- ============================================================
-- 1. Dataset de features
-- ============================================================

CREATE OR REPLACE TABLE `project.analytics.ml_features` AS

SELECT
  customer_id,

  -- Variables numéricas
  COUNTIF(event_type = 'purchase') AS purchases,
  SUM(revenue) AS total_revenue,
  AVG(session_duration) AS avg_session_duration,

  -- Variable temporal
  DATE_DIFF(
    CURRENT_DATE(),
    MAX(event_date),
    DAY
  ) AS days_since_last_event,

  -- Variable objetivo
  MAX(CASE
    WHEN churned = TRUE THEN 1
    ELSE 0
  END) AS label

FROM `project.analytics.customer_events`

GROUP BY customer_id;


-- ============================================================
-- 2. Entrenamiento del modelo
-- ============================================================

CREATE OR REPLACE MODEL `project.ml.customer_churn_model`

OPTIONS (
  model_type = 'LOGISTIC_REG',
  input_label_cols = ['label']
) AS

SELECT
  purchases,
  total_revenue,
  avg_session_duration,
  days_since_last_event,
  label

FROM `project.analytics.ml_features`;


-- ============================================================
-- 3. Evaluación
-- ============================================================

SELECT *
FROM ML.EVALUATE(
  MODEL `project.ml.customer_churn_model`,
  (
    SELECT
      purchases,
      total_revenue,
      avg_session_duration,
      days_since_last_event,
      label
    FROM `project.analytics.ml_features`
  )
);


-- ============================================================
-- 4. Predicción
-- ============================================================

SELECT
  customer_id,
  predicted_label,
  predicted_label_probs

FROM ML.PREDICT(
  MODEL `project.ml.customer_churn_model`,
  (
    SELECT
      customer_id,
      purchases,
      total_revenue,
      avg_session_duration,
      days_since_last_event
    FROM `project.analytics.ml_features`
  )
);

Dataform Google Cloud: convertir SQL en un pipeline mantenible

Si el objetivo es construir un proyecto empresarial, ejecutar SQL manualmente no es suficiente. Necesitamos controlar dependencias, versiones, materializaciones y validaciones. Ahí es donde Dataform encaja especialmente bien con BigQuery.

Una estrategia limpia consiste en separar el proyecto en diferentes capas. Por ejemplo, podemos tener una tabla de eventos normalizados, otra tabla con las features y posteriormente una relación lógica con el proceso de Machine Learning.

El principio fundamental es que el modelo no debería depender de una consulta improvisada ejecutada desde la consola. Las transformaciones que generan las features deben estar versionadas como código.

config {
  type: "table",
  schema: "ml",
  name: "customer_features",
  description: "Features utilizadas por el modelo de churn"
}

SELECT
  customer_id,

  COUNTIF(event_type = 'purchase') AS purchases,

  SUM(revenue) AS total_revenue,

  AVG(session_duration) AS avg_session_duration,

  DATE_DIFF(
    CURRENT_DATE(),
    MAX(event_date),
    DAY
  ) AS days_since_last_event,

  MAX(
    CASE
      WHEN churned = TRUE THEN 1
      ELSE 0
    END
  ) AS label

FROM ${ref("customer_events")}

GROUP BY customer_id

El beneficio no está simplemente en sustituir una consulta SQL por un fichero SQLX. El verdadero valor aparece cuando Dataform se convierte en la capa de transformación: las dependencias quedan explícitas, los cambios se revisan mediante control de versiones y el dataset de features se convierte en un artefacto reproducible.

Patrones de diseño y mejores prácticas

De tutorial a producción: qué cambia

Crear un modelo en BigQuery ML puede ser relativamente sencillo. Operarlo correctamente durante meses es el verdadero problema de arquitectura.

En producción necesitamos considerar la frecuencia de entrenamiento, la estabilidad del esquema, la evolución de las features, el coste de procesamiento, la monitorización de predicciones y el mecanismo mediante el que los consumidores acceden al resultado.

También es importante separar el concepto de modelo del concepto de dataset de predicciones. El modelo puede actualizarse con una determinada frecuencia mientras que las predicciones pueden generarse con otra cadencia.

Checklist de implementación empresarial

Preguntas frecuentes sobre BigQuery ML

Conclusión: BigQuery ML es una decisión de arquitectura

Aprender BigQuery ML no consiste únicamente en memorizar la sintaxis de CREATE MODEL. El verdadero salto profesional aparece cuando entendemos qué datos utilizar, cómo construir features reproducibles, cómo evitar leakage, cuánto cuesta procesar el dataset y cómo automatizar todo el ciclo.

Para equipos que ya utilizan Google Cloud y BigQuery como plataforma analítica, combinar BigQuery ML + SQL + Dataform puede reducir considerablemente la complejidad de determinados pipelines de Machine Learning.

La clave es no convertir BigQuery ML en una solución universal. Cuando el problema encaja, mantener los datos y gran parte del ciclo de ML dentro del mismo ecosistema puede ser una ventaja arquitectónica enorme. Cuando no encaja, debemos reconocerlo y utilizar una plataforma de ML más especializada.