2. Google Cloud数据分析平台架构设计
在 Google Cloud 上设计数据分析平台，核心不是把 BigQuery、Pub/Sub、Dataflow、Dataproc、Looker 等产品堆在一起，而是先确定一条从数据源到消费端的完整链路，再为链路上的每一段选择匹配的组件。端到端架构通常可以拆成五个逻辑层：数据源层、摄取层、存储与处理层、分析服务层、消费与治理层。每一层都有明确的输入输出、延迟要求和成本特征，选型时应当逐层判断，而不是先选产品再补链路。
一、端到端架构的分层与数据流
数据源层包括业务数据库（如 Cloud SQL、AlloyDB、Spanner）、应用日志、事件流、第三方 SaaS 和文件系统。摄取层负责把数据搬进云平台，常见方式有 Pub/Sub 实时消息、Datastream 变更数据捕获（CDC）、Storage Transfer Service 批量迁移、Transfer Appliance 离线迁移。存储与处理层是平台的核心，BigQuery 承担分析型数仓与湖仓一体查询，Cloud Storage 作为数据湖底座，Dataflow 做流批统一处理，Dataproc 处理 Spark/Hadoop 生态任务，Dataproc Serverless 适合无集群运维的批处理。分析服务层包括 BigQuery BI Engine、Looker、Vertex AI，消费与治理层则通过 Dataplex、Data Catalog、IAM、VPC Service Controls 实现元数据、权限和边界管理。
下面这张图给出了一条典型的端到端数据流：左侧是数据源，中间经过摄取与处理，右侧到达消费端，底部是贯穿全链路的治理与安全控制面。
二、关键组件选型：按数据特征和延迟要求决策
选型时先问三个问题：数据是流式还是批量？查询是交互式还是长时批处理？团队是否愿意运维集群？如果数据以事件流为主且要求秒级可见，Pub/Sub + Dataflow + BigQuery 是标准组合；如果数据来自关系库且需要持续同步，Datastream 把 CDC 写入 Cloud Storage 或 BigQuery，避免自建同步工具。如果任务以 Spark 作业为主且需要精细控制集群，选 Dataproc；如果只是周期性 ETL 且不想管集群，选 Dataproc Serverless 或 Dataflow。如果查询以高并发 BI 为主，BigQuery 配合 BI Engine 做内存加速；如果需要低延迟点查，Bigtable 比 BigQuery 更合适。
存储选型同样要按访问模式区分。Cloud Storage 适合原始数据、半结构化数据和长期归档，配合 Nearline、Coldline、Archive 生命周期规则降低成本。BigQuery 适合结构化分析，按扫描量计费，因此分区、聚簇和列裁剪直接决定费用。Bigtable 适合高吞吐随机读写，Spanner 适合强一致事务型场景。不要把 BigQuery 当 OLTP 用，也不要把 Cloud Storage 当低延迟查询引擎用。
三、可扩展性与成本权衡
可扩展性方面，优先选择无服务器和自动扩缩组件。Pub/Sub 按消息量自动扩展，Dataflow 根据积压自动调整 worker 数量，BigQuery 通过 slot 自动分配处理并发查询，Dataproc Serverless 按作业需求分配资源。需要预留容量时，BigQuery 的 Editions 和 slot 预留可以保证关键负载的稳定性，但预留过多会浪费，过少会导致排队。一个实用的判断方法是：先按需运行两周，观察查询并发峰值和扫描量分布，再决定是否预留。
成本权衡集中在四个杠杆：存储分层、查询优化、计算资源调度、数据生命周期。存储上，把 90 天未访问的数据从 Standard 转到 Nearline 或 Coldline，成本可下降约 50%～80%。查询上，避免 SELECT *，使用分区过滤和聚簇字段，单次扫描量从 TB 级降到 GB 级是常见效果。计算上，Dataflow 使用 Streaming Engine 把状态管理移出 worker，减少 worker 数量；Dataproc 使用可抢占 VM 跑容错批处理，成本可降 60%～80%。生命周期上，用 BigQuery 表分区过期和 Cloud Storage 生命周期规则自动清理临时数据。
四、一个可参考的架构决策表
| 场景 | 推荐组件 | 延迟 | 成本特征 |
|---|---|---|---|
| 实时事件分析 | Pub/Sub + Dataflow + BigQuery | 秒级～分钟级 | 按消息量、worker 时长、扫描量计费 |
| 关系库持续同步 | Datastream + Cloud Storage/BigQuery | 分钟级 | 按 CDC 流量和存储计费 |
| Spark 批处理 | Dataproc Serverless | 分钟级～小时级 | 按作业资源时长计费，无集群空闲成本 |
| 高并发 BI | BigQuery + BI Engine | 亚秒级～秒级 | BI Engine 按内存容量计费，减少查询扫描 |
| 低延迟点查 | Bigtable | 毫秒级 | 按节点和存储计费，适合稳定高吞吐 |
| 长期归档 | Cloud Storage Archive | 小时级取回 | 存储单价最低，取回有额外费用 |
最后需要强调，架构设计不是一次性的。数据量、查询模式和成本预算会随业务变化，建议每季度复核一次：用 Cloud Monitoring 看 Pub/Sub 积压和 Dataflow 延迟，用 BigQuery 审计日志看扫描量趋势，用 Cloud Billing 看各服务成本占比。把治理控制面从一开始就纳入设计，包括 IAM 最小权限、VPC Service Controls 边界、Cloud KMS 加密和 Data Catalog 元数据，否则后期补治理的代价会远高于前期设计。