3. 数据接入与存储选型

在机器学习平台建设中，数据接入与存储选型往往决定了后续训练、推理和监控的复杂度。Google Cloud 提供了三类核心数据服务：Cloud Storage（GCS）、BigQuery 和 Pub/Sub。它们并非互相替代，而是分别承担“对象存储”“分析型数据仓库”“消息流”三种角色。理解它们在 ML 流水线中的位置，是做出合理选型的前提。

三类服务在 ML 流水线中的角色定位

Cloud Storage 是 GCS 中的对象存储，适合存放原始文件、图像、音频、TFRecord、模型权重、检查点以及训练脚本。它的特点是高吞吐、低成本、强一致，并且与 Vertex AI、Dataflow、Dataproc 等组件天然集成。在 ML 流水线中，GCS 通常作为“数据湖底座”和“模型产物仓库”。

BigQuery 是 Serverless 分析型数据仓库，适合结构化、半结构化数据的 SQL 分析、特征工程和批量导出。它可以直接被 BigQuery ML 使用，也可以通过 BigQuery Storage API 高速读取到训练作业中。在 ML 流水线中，BigQuery 常作为“特征仓库”和“训练数据准备层”。

Pub/Sub 是全局分布式的消息队列，适合实时事件接入、流式数据缓冲和异步解耦。它不存储长期数据，而是提供“至少一次”投递语义。在 ML 流水线中，Pub/Sub 通常作为“实时数据入口”，将事件推送到 Dataflow 或 Cloud Functions 进行预处理，再写入 GCS 或 BigQuery。

选型依据：从数据形态与时效性出发

选型的第一维度是数据形态。如果数据是非结构化文件（图像、音频、视频、文本、模型文件），GCS 是唯一合理选择；如果数据是结构化表格且需要频繁 SQL 查询、聚合、连接，BigQuery 更合适；如果数据是持续产生的事件流（点击、传感器、交易），Pub/Sub 是入口。

第二维度是时效性。批量场景下，GCS 和 BigQuery 都能胜任；实时场景下，Pub/Sub 负责接入，Dataflow 负责窗口聚合和特征计算，最终可以同时写入 GCS（归档）和 BigQuery（在线分析）。

第三维度是访问模式。训练作业通常需要高吞吐顺序读取，GCS 和 BigQuery Storage API 都能满足；在线推理需要低延迟点查，BigQuery 或 Vertex AI Feature Store 更合适；流式推理则需要从 Pub/Sub 拉取事件。

典型组合模式与参数示例

以下是一个电商推荐场景的示例配置，用于说明三类服务如何协同。假设实时点击事件通过 Pub/Sub 接入，Dataflow 做 5 分钟窗口聚合，结果写入 BigQuery 作为特征表，同时原始事件归档到 GCS。

# Pub/Sub 主题与订阅示例
gcloud pubsub topics create click-events
gcloud pubsub subscriptions create click-events-sub \
  --topic=click-events \
  --ack-deadline=60 \
  --message-retention-duration=7d

# Dataflow 流式作业关键参数（示例）
--streaming
--windowSize=5m
--triggeringFrequency=1m
--outputTable=project.dataset.click_features
--outputGCS=gs://bucket/click-archive/

# BigQuery 特征表分区与聚类（示例）
CREATE TABLE dataset.click_features
PARTITION BY DATE(event_time)
CLUSTER BY user_id
AS SELECT ...;

在这个示例中，Pub/Sub 的 ack-deadline 设为 60 秒，意味着消费者有 60 秒处理消息；message-retention-duration 设为 7 天，保证故障后可重放。Dataflow 的窗口大小 5 分钟、触发频率 1 分钟，是在延迟与完整性之间的折中。BigQuery 表按日期分区、按用户聚类，可以显著降低点查和训练数据导出的扫描量。

成本与运维的权衡

GCS 的成本主要是存储和操作费用，适合冷热分层；BigQuery 按扫描字节数和存储计费，适合高频查询但需要控制分区和聚类；Pub/Sub 按消息量和订阅吞吐计费，适合事件驱动但要注意消息保留和死信队列。选型时不能只看单价，还要看数据移动成本、跨区域复制和运维复杂度。

选型决策表

总结来说，Cloud Storage、BigQuery 和 Pub/Sub 在 ML 流水线中分别对应“文件底座”“分析层”和“实时入口”。选型时先看数据形态，再看时效性和访问模式，最后结合成本与运维复杂度做权衡。三者组合使用，才能支撑从数据接入到模型部署的完整链路。