Tutorial BigQuery ML: Predicción de Series Temporales (ARIMA+) y Fallos con SQL en GCP
BigQuery ML permite llevar machine learning directamente al warehouse utilizando SQL, sin convertir necesariamente cada pipeline analítico en una plataforma Python independiente. En esta guía de nivel Senior/Staff/Architect construiremos una arquitectura práctica para predicción de series temporales, evaluación de forecasts y detección de fallos utilizando ARIMA_PLUS, SQL y Google Cloud.
Lo que aprenderás
La decisión arquitectónica: ¿modelar fuera o dentro del warehouse?
El primer error arquitectónico consiste en asumir que cualquier proyecto de forecasting necesita una plataforma externa de notebooks, contenedores, feature stores y servicios de inferencia. Para determinadas cargas analíticas, BigQuery ML reduce considerablemente esa superficie operacional.
El criterio no debe ser simplemente “SQL frente a Python”. La decisión correcta depende del volumen de series, frecuencia de reentrenamiento, necesidad de features externas, latencia de inferencia, observabilidad y modelo de ownership entre Data Engineering, Analytics y Machine Learning.
| Patrón | OLAP / ML in-warehouse | Plataforma ML externa | Latencia | Coste operativo | Cuándo elegirlo |
|---|---|---|---|---|---|
| BigQuery ML | Excelente integración con datos analíticos | No requiere runtime ML separado para el entrenamiento | Batch / near-real-time según arquitectura | Bajo a medio | Forecasting analítico, planificación, anomaly detection y grandes volúmenes SQL. |
| ARIMA_PLUS | Series temporales univariantes | Automatiza buena parte del pipeline temporal | Batch | Medio, dependiente del espacio de búsqueda | Forecasting con tendencia, estacionalidad y limpieza temporal. |
| ARIMA_PLUS_XREG | Series temporales + variables externas | Permite incorporar regresores | Batch | Medio | Cuando promociones, temperatura, precio, campañas u otras variables explican la demanda. |
| Pipeline ML externo | Flexibilidad máxima | Frameworks y modelos arbitrarios | Puede llegar a online/real-time | Medio / alto | Modelos personalizados, deep learning, serving online o necesidades avanzadas de MLOps. |
| OLTP + ML | No es el patrón ideal para entrenamiento analítico | Requiere extracción o replicación de datos | Potencialmente baja en lectura | Alto si se utiliza directamente para analytics | Debe reservarse para operaciones transaccionales; separar OLTP de workloads analíticos. |
ARIMA_PLUS: qué ocurre realmente detrás de tu SQL
ARIMA_PLUS no debe entenderse únicamente como una llamada a un algoritmo ARIMA clásico. BigQuery ML construye un pipeline de series temporales que puede inferir la frecuencia, tratar intervalos irregulares, gestionar timestamps duplicados, interpolar determinados valores ausentes y trabajar con componentes como estacionalidad, tendencia, outliers y cambios de nivel.
La fase auto.ARIMA busca automáticamente órdenes no estacionales
(p,d,q). Esto resulta extremadamente conveniente, pero tiene una consecuencia
FinOps importante: aumentar el espacio de búsqueda aumenta el trabajo computacional.
Serie temporal
La entrada debe representar una observación temporal coherente: timestamp, variable objetivo y, si es necesario, identificadores de múltiples series.
Auto.ARIMA
El entrenamiento puede evaluar candidatos y seleccionar configuraciones mediante criterios estadísticos como AIC.
Forecast + intervalos
ML.FORECAST devuelve predicciones junto con límites inferior y superior del intervalo de confianza solicitado.
Anomaly Detection
ML.DETECT_ANOMALIES permite comparar las observaciones con el comportamiento esperado por el modelo.
Modelo como asset
El modelo vive dentro del ecosistema de BigQuery, facilitando permisos, ownership y acceso desde pipelines SQL.
Series múltiples
TIME_SERIES_ID_COL permite entrenar y pronosticar múltiples series mediante un único modelo lógico.
Antipatrón crítico: “más histórico y más búsqueda siempre es mejor”
En producción, una de las decisiones más caras puede ser aparentemente inocente: incrementar indefinidamente el histórico utilizado y permitir que auto.ARIMA explore un espacio de candidatos innecesariamente amplio.
⚠️ Error de FinOps
No confundas precisión estadística con volumen de cómputo.
AUTO_ARIMA_MAX_ORDER controla el espacio de búsqueda de los términos no estacionales
p y q. Cuanto mayor sea el espacio de candidatos, mayor puede ser
el trabajo de entrenamiento y, por tanto, el coste.
La estrategia de producción debe empezar con un baseline medible. Después se incrementa progresivamente la complejidad sólo si las métricas fuera de muestra justifican el coste.
⚠️ Error de modelado: leakage temporal
Nunca utilices información que no habría estado disponible en el momento de predicción. En forecasting, un feature aparentemente inocente puede contener información futura y producir métricas excelentes durante el entrenamiento que desaparecen en producción.
La validación debe respetar la naturaleza temporal del problema: entrenar con pasado y evaluar sobre un intervalo posterior que el modelo no haya visto.
⚠️ Error operacional: usar anomaly detection como sistema de alertas completo
ML.DETECT_ANOMALIES no sustituye a un sistema de incident management. La función puede producir la señal estadística; la arquitectura debe encargarse de deduplicación, ventanas de silencio, severidad, routing, observabilidad y respuesta.
Implementación práctica: entrenamiento ARIMA_PLUS con SQL
El siguiente ejemplo utiliza una tabla hipotética de ventas diarias. El objetivo es mantener el SQL suficientemente cercano a producción para que pueda integrarse después en un pipeline de datos.
CREATE OR REPLACE MODEL
`mi_proyecto.ml_forecasting.sales_arima_plus`
OPTIONS (
MODEL_TYPE = 'ARIMA_PLUS',
-- Columna temporal.
TIME_SERIES_TIMESTAMP_COL = 'fecha',
-- Variable que queremos predecir.
TIME_SERIES_DATA_COL = 'ventas',
-- Forecast por cada producto.
TIME_SERIES_ID_COL = 'producto_id',
-- Horizonte de predicción.
HORIZON = 30,
-- Búsqueda automática de p,d,q.
AUTO_ARIMA = TRUE,
-- Limitar el espacio de búsqueda.
AUTO_ARIMA_MAX_ORDER = 3,
-- Permitir excluir soluciones completamente planas.
AUTO_ARIMA_MIN_ORDER = 1,
-- La frecuencia es diaria.
DATA_FREQUENCY = 'DAILY',
-- Si las ventas no pueden ser negativas.
FORECAST_LIMIT_LOWER_BOUND = 0
)
AS
SELECT
DATE(fecha) AS fecha,
CAST(producto_id AS STRING) AS producto_id,
CAST(ventas AS FLOAT64) AS ventas
FROM
`mi_proyecto.raw_analytics.ventas_diarias`
WHERE
fecha >= DATE_SUB(CURRENT_DATE(), INTERVAL 24 MONTH)
AND ventas IS NOT NULL;SELECT
producto_id,
forecast_timestamp,
forecast_value,
prediction_interval_lower_bound,
prediction_interval_upper_bound
FROM
ML.FORECAST(
MODEL `mi_proyecto.ml_forecasting.sales_arima_plus`,
STRUCT(
30 AS horizon,
0.95 AS confidence_level
)
)
ORDER BY
producto_id,
forecast_timestamp;SELECT
producto_id,
date,
ventas,
is_anomaly,
lower_bound,
upper_bound,
anomaly_probability
FROM
ML.DETECT_ANOMALIES(
MODEL `mi_proyecto.ml_forecasting.sales_arima_plus`,
STRUCT(
0.95 AS anomaly_prob_threshold
)
)
WHERE
is_anomaly = TRUE
ORDER BY
date DESC,
producto_id;SELECT
*
FROM
ML.EVALUATE(
MODEL `mi_proyecto.ml_forecasting.sales_arima_plus`,
(
SELECT
DATE(fecha) AS fecha,
CAST(producto_id AS STRING) AS producto_id,
CAST(ventas AS FLOAT64) AS ventas
FROM
`mi_proyecto.raw_analytics.ventas_diarias`
WHERE
fecha BETWEEN DATE '2026-07-01'
AND DATE '2026-07-30'
),
STRUCT(
30 AS horizon,
TRUE AS perform_aggregation
)
);ARIMA_PLUS frente a ARIMA_PLUS_XREG
Si la demanda depende fuertemente de variables externas, un modelo puramente univariante puede quedarse corto. Es aquí donde ARIMA_PLUS_XREG resulta especialmente interesante: añade regresores externos al componente temporal.
CREATE OR REPLACE MODEL
`mi_proyecto.ml_forecasting.sales_arimax`
OPTIONS (
MODEL_TYPE = 'ARIMA_PLUS_XREG',
TIME_SERIES_TIMESTAMP_COL = 'fecha',
TIME_SERIES_DATA_COL = 'ventas',
HORIZON = 30,
AUTO_ARIMA = TRUE,
AUTO_ARIMA_MAX_ORDER = 3,
DATA_FREQUENCY = 'DAILY'
)
AS
SELECT
fecha,
ventas,
-- Variables externas conocidas o disponibles
-- durante la inferencia.
precio_promedio,
promocion_activa,
temperatura_media
FROM
`mi_proyecto.ml_features.sales_features`
WHERE
fecha >= DATE_SUB(CURRENT_DATE(), INTERVAL 24 MONTH);La trampa de los regresores futuros
Con ARIMA_PLUS_XREG, conocer el valor histórico de una feature no significa que conozcas su valor futuro. Si quieres generar un forecast para los próximos 30 días, debes poder proporcionar los regresores necesarios para ese horizonte.
Por ejemplo, una promoción planificada puede estar disponible en el calendario comercial, mientras que una variable como “ventas reales de mañana” obviamente no puede utilizarse como feature futura sin introducir leakage.
Patrones de diseño para producción
La implementación empresarial no termina con CREATE MODEL. El modelo debe
integrarse dentro de un sistema que controle calidad de datos, entrenamiento, evaluación,
inferencia, observabilidad y consumo.
Contrato temporal
Valida granularidad, duplicados, valores nulos, saltos temporales, cardinalidad de IDs y cobertura histórica antes de entrenar.
Entrenamiento reproducible
Versiona SQL, parámetros, ventana histórica y configuración del modelo. Evita que el modelo dependa silenciosamente de cambios en tablas upstream.
Evalúa antes de publicar
No promociones un modelo sólo porque el entrenamiento terminó correctamente. Compara MAE, MSE, RMSE y errores relativos con un baseline.
Forecast materializado
Para consumidores downstream suele ser preferible materializar el forecast en una tabla versionada y estable, en lugar de recalcularlo indiscriminadamente.
Detecta degradación
Monitoriza error real frente al forecast, cobertura de intervalos, cambios de distribución y aparición de anomalías.
Controla el coste
Limita histórico, horizonte y espacio de búsqueda. Mide bytes procesados y frecuencia real de reentrenamiento antes de escalar el patrón.
Checklist de implementación empresarial
Este framework permite convertir un experimento de BigQuery ML en un pipeline gobernado.
Define el caso de negocio
Especifica qué decisión utilizará el forecast: inventario, capacidad, demanda, mantenimiento, presupuesto o detección temprana de incidentes.
Define la granularidad
Determina si la serie es horaria, diaria, semanal o de otra frecuencia soportada y garantiza que la granularidad sea coherente con el caso de uso.
Construye el dataset temporal
Estandariza timestamps, identifica series mediante claves estables y establece reglas explícitas para duplicados y datos ausentes.
Establece un baseline
Antes de aumentar la complejidad del modelo, compara contra métodos simples como persistencia, medias móviles o estacionalidad ingenua.
Entrena ARIMA_PLUS
Comienza con auto.ARIMA y un espacio de búsqueda razonable. Sólo amplíalo cuando exista evidencia de mejora fuera de muestra.
Evalúa con datos futuros
Separa temporalmente entrenamiento y evaluación. Nunca mezcles observaciones futuras en el conjunto utilizado para seleccionar el modelo.
Decide si necesitas XREG
Introduce variables externas únicamente cuando exista una hipótesis causal o predictiva razonable y sus valores futuros puedan estar disponibles durante la inferencia.
Publica forecast y anomalías
Materializa resultados en datasets de consumo y desacopla el modelo estadístico de las aplicaciones que consumen sus resultados.
Implementa observabilidad
Controla freshness, calidad, error del forecast, cobertura de intervalos, anomalías y coste de las ejecuciones.
Define una política de retraining
El reentrenamiento debe responder a una necesidad: calendario, degradación de métricas, cambio estructural o llegada de suficiente información nueva.
Arquitectura recomendada de extremo a extremo
Un patrón robusto separa claramente datos históricos, features, entrenamiento, evaluación, inferencia y consumo.
┌─────────────────────────┐
│ Fuentes de datos │
│ ERP / CRM / IoT / APIs │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ BigQuery │
│ Raw → Curated → Features│
└────────────┬────────────┘
│
┌──────────────┴──────────────┐
│ │
▼ ▼
┌─────────────────────┐ ┌─────────────────────┐
│ ARIMA_PLUS │ │ ARIMA_PLUS_XREG │
│ Serie univariante │ │ + regresores │
└──────────┬──────────┘ └──────────┬──────────┘
│ │
└──────────────┬──────────────┘
▼
┌─────────────────────────┐
│ Forecast / Evaluation │
│ ML.FORECAST / EVALUATE │
└────────────┬────────────┘
│
┌──────────────┴──────────────┐
│ │
▼ ▼
┌─────────────────────┐ ┌─────────────────────┐
│ Forecast Tables │ │ Anomaly Detection │
│ BI / Planning │ │ ML.DETECT_ANOMALIES │
└─────────────────────┘ └──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Alerting / Incident │
│ Management / SRE │
└─────────────────────┘Preguntas frecuentes sobre BigQuery ML y ARIMA+
¿Qué diferencia hay entre ARIMA_PLUS y ARIMA_PLUS_XREG en BigQuery ML?
ARIMA_PLUS está orientado principalmente a series temporales en las que la variable objetivo se modela a partir de su propio comportamiento temporal. ARIMA_PLUS_XREG extiende este patrón incorporando regresores externos. Es especialmente útil cuando factores como precio, promociones, temperatura o campañas contienen información predictiva relevante.
¿Cómo se utiliza BigQuery ML para detectar anomalías?
Después de entrenar un modelo compatible, puedes utilizar
ML.DETECT_ANOMALIES. El resultado permite trabajar con indicadores como
is_anomaly, límites esperados y probabilidad de anomalía. La señal
estadística debe integrarse después con las reglas operativas de alertado de tu empresa.
¿Cómo controlar el coste de auto.ARIMA?
El principal mecanismo consiste en controlar el espacio de búsqueda mediante
AUTO_ARIMA_MAX_ORDER y AUTO_ARIMA_MIN_ORDER. También debes
evitar históricos excesivos sin justificación, limitar el horizonte al necesario,
reducir reentrenamientos innecesarios y medir el coste real de los jobs.