1. 课程导入与平台工程全景

当企业把数据分析从“几个人跑脚本”推进到“几十个团队共享一套平台”时，问题性质就发生了变化。前者关心的是能不能算出结果，后者关心的是这套系统能否在数据量增长十倍、任务数增长百倍、参与方从 3 人变成 300 人之后，依然稳定、可控、可审计、成本可预期。本课程讨论的正是后者——Google Cloud 上的大规模数据分析平台工程。

先建立一张服务矩阵的全局认知。Google Cloud 的数据分析能力大致可以按“数据所处阶段”和“工作负载形态”两个维度来定位：

• 数据接入与流转：Pub/Sub 承担高吞吐事件流，Dataflow 负责流式与批式统一处理，Datastream 做数据库变更捕获（CDC）。
• 数据存储与湖仓：Cloud Storage 是对象存储底座，BigQuery 提供无服务器数仓与湖仓一体能力，BigLake 打通外部表与统一权限。
• 数据处理与编排：Dataproc 承载 Spark/Hadoop 生态，Cloud Composer（托管 Airflow）负责跨服务编排调度。
• 分析与智能：BigQuery ML 在数仓内做建模，Vertex AI 承接更复杂的机器学习流水线，Looker 负责语义层与可视化。
• 治理与元数据：Dataplex 做数据发现、血缘与质量，Data Catalog 提供元数据检索。

这张矩阵的关键不是记住产品名，而是理解它们之间的数据流与职责边界。下图给出一个典型的大规模分析平台的端到端拓扑，从数据源到消费端，标注了各环节的主要服务与关键接口。

从工程化视角看，这张图里真正需要投入精力的不是某个单一服务，而是服务之间的契约：数据以什么格式、什么分区粒度、什么更新频率从上游流向下游；谁拥有哪张表的写权限；任务失败后由谁负责重跑；一次查询扫描了多少字节、花了多少钱。这些契约如果只靠口头约定，平台规模一上来就会失控。

举一个具体的参数化例子。假设某电商团队要把订单事件从 Pub/Sub 接入 BigQuery，用于近实时看板。一个合理的初始设计是：Pub/Sub 主题按业务域划分，Dataflow 订阅后做窗口聚合，写入 BigQuery 时按 event_date 做时间分区、按 region 做聚簇。这样设计后，看板查询“今天华东区订单量”时，BigQuery 只需扫描当天华东分区，而不是全表。假设全表 500 GB，单分区约 1.5 GB，聚簇后实际扫描可能降到 200 MB 量级——按 BigQuery 按需计费约 $6.25/TB 估算，单次查询成本从约 $0.003 降到约 $0.0000012，差异在日查询量上万次时会被显著放大。这里的数据是用于说明量级关系的示例假设，不是实测账单。

再看编排与治理。Cloud Composer 负责把“接入—处理—写入—质量校验—通知”串成 DAG，每个任务设置重试次数与超时；Dataplex 负责给数据集打上业务域、负责人、敏感级别标签；IAM 则把“谁能读哪张表、谁能写哪个数据集”固化为策略。这三者共同构成平台的“控制面”，与 Dataflow、BigQuery 这些“数据面”分离。理解控制面与数据面的分离，是后续所有章节的基础。

本课程后续会围绕这条主线展开：从数据接入与流转开始，进入 BigQuery 建模与优化，再到 Dataflow/Dataproc 的处理模式、Composer 的编排实践、Dataplex 的治理落地，最后回到平台级的成本、SLA 与多团队协作。你现在需要记住的，是这张全景图里每个方块的位置和它们之间的箭头——后面每一章，都是在放大其中一个方块或一条箭头。