解读

面试官把 Cloud SQL 的运维痛点（CPU 用量预测）与 BigQuery ML 的能力结合起来，考察三点：

1. 能否把 Cloud SQL 原生指标（cloudsql.googleapis.com/database/cpu/utilization）通过 Cloud Monitoring Export 落到 BigQuery；
2. 能否用 BigQuery ML 时间序列模型（ARIMA_PLUS、ARIMA_PLUS_XREG）做月度粒度预测；
3. 能否把预测结果回写 Cloud SQL 或对接 Cloud Monitoring Alerting Policy，形成闭环。 国内面试场景下，还要回答合规（数据不出境）、成本（BigQuery 存储与计算按量计费）、延迟（T+1 还是实时）等追问。

知识点

• Cloud Monitoring → BigQuery 数据导出管道：使用 Monitoring Query Language(MQL) 按 1 min 粒度聚合为 1 h 粒度，避免 BigQuery 行数爆炸；落地表分区字段为 DATE(_PARTITIONTIME)，方便后续时间序列切分。
• BigQuery ML 时间序列语法：
  CREATE OR REPLACE MODEL bqml.cloudsql_cpu_arima OPTIONS(model_type='ARIMA_PLUS_XREG', time_series_timestamp_col='usage_hour', time_series_data_col='cpu_utilization', horizon=720, data_frequency='HOURLY', auto_detect_arima=True)
  其中 horizon=720 代表 30 天×24 h，直接预测下月每小时 CPU。
• 特征工程：国内业务常有晚高峰 20:00-22:00、月初结算、秒杀活动等强周期，需构造周几、是否节假日、营销活动标签等外生变量，用 ARIMA_PLUS_XREG 而非纯 ARIMA。
• 评估指标：用 MAE、MAPE、对称 MAPE 评估，国内面试官常追问“MAPE 超过 15% 怎么办”，需答回退到 Prophet 模型或把粒度从小时升到日。
• 结果落地：预测表按 DATE 分区写入 Cloud SQL 的预测库，供 Grafana 自建仪表盘或 Cloud Monitoring Alerting 调用；国内金融客户要求数据不出境，需确认 BigQuery 数据集位于 asia-southeast1 或 shanghai 区域（若已落地）。
• 成本优化：国内候选人多被问“BigQuery 扫描 1 TB 多少钱”，需答使用 CLUSTERING 字段 (instance_id, date) 并把训练集限定为近 90 天，扫描量压到 50 GB 以内，训练费用 < 5 元。
• MLOps：用 Cloud Composer（Airflow） 每日调度 bqml.model_train 与 bqml.forecast，并做数据漂移检测——若最近 7 天实际 CPU 与预测偏差持续 > 20%，触发 retrain。

答案

1. 开通 Cloud Monitoring → BigQuery 导出，MQL 示例：
   fetch cloudsql_database | metric 'cloudsql.googleapis.com/database/cpu/utilization' | group_by [resource.instance_id], [value_utilization_mean: mean(value.utilization)] | every 1h
   结果写入 monitoring.cloudsql_cpu 表，分区字段为 DATE(usage_hour)。
2. 构造训练视图：
   CREATE OR REPLACE VIEW bqml.v_cpu_train AS SELECT usage_hour, AVG(cpu_utilization) AS cpu_utilization, EXTRACT(DAYOFWEEK FROM usage_hour) AS dow, IF(EXTRACT(DAY FROM usage_hour) <= 3, 1, 0) AS is_month_start, is_promotion FROM monitoring.cloudsql_cpu WHERE usage_hour BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY) AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) GROUP BY 1,3,4,5。
3. 训练模型：
   CREATE OR REPLACE MODEL bqml.cloudsql_cpu_arima OPTIONS(model_type='ARIMA_PLUS_XREG', time_series_timestamp_col='usage_hour', time_series_data_col='cpu_utilization', horizon=720, data_frequency='HOURLY') AS SELECT * FROM bqml.v_cpu_train。
4. 生成预测：
   CREATE OR REPLACE TABLE bqml.forecast_next_month AS SELECT * FROM ML.FORECAST(MODEL bqml.cloudsql_cpu_arima, STRUCT(720 AS horizon))。
5. 回写 Cloud SQL：
   使用 Cloud SQL Auth Proxy + Dataflow 模板 JdbcIO，把 bqml.forecast_next_month 按天汇总后写入 Cloud SQL 表 prediction.cpu_forecast(date, avg_cpu, p95_cpu)。
6. 告警：在 Cloud Monitoring 新建 MQL-based Alerting Policy，若未来 24 h 预测 CPU > 80% 且持续 1 h，则通过 短信+钉钉 通知值班；国内短信通道用 Google Cloud 与阿里云短信网关对接。
7. 合规与成本：数据集指定 asia-southeast1，训练+预测每日扫描 < 50 GB，月费用 < 150 元；数据脱敏，instance_id 做哈希后再入 BigQuery。

拓展思考

• 如果业务上线 Cloud SQL Enterprise Plus 版（内存 1 TB+），单实例 CPU 核数动态扩缩，历史曲线出现结构性断点，此时 ARIMA_PLUS_XREG 会失效；可改用 BigQuery ML 的 Prophet 模型并加入 changepoint_prior_scale=0.5 自动检测断点。
• 国内电商大促（双 11、618）属于极低频高振幅事件，样本不足；可引入 Vertex AI AutoML Tables，把 BigQuery 表导出到 Vertex AI 数据集，用 时间序列回溯分割（Time Series Split） 重新训练，再与 BigQuery ML 结果做 ensemble。
• 若客户要求实时预测（5 min 级），BigQuery ML 的 10 秒调度成本过高，可改用 Cloud SQL 内置原生函数（如 PostgreSQL 的 TimescaleDB + pgml），或把特征工程下沉到 Flink CDC 流作业，走 Kafka → BigQuery Streaming → Vertex AI Prediction 的混合架构，实现 T+0 预测。