1. 课程导入与体系总览

在进入具体服务与实现之前，先把“大规模数据管道”这件事讲清楚。很多团队在 AWS 上做数据平台时，第一反应是选服务：S3、Glue、Kinesis、Redshift、Athena、EMR、Lambda……但真正决定项目成败的，往往不是选了哪个服务，而是是否理解数据从产生到消费的完整链路，以及这条链路上“开发”和“治理”如何协同。本课程围绕一条主线展开：用工程化方式构建可扩展的数据管道，同时用治理体系保证数据可信、可查、可控、可审计。

什么是 AWS 大规模数据管道

大规模数据管道，指的是在数据量、数据源数量、消费方数量或时效性要求达到一定规模后，仍然能够稳定运行的数据采集、传输、存储、处理、服务链路。它通常具备几个特征：数据源异构（应用日志、数据库 CDC、IoT 事件、第三方 API、批量文件）；数据形态多样（结构化、半结构化、非结构化）；处理模式混合（批处理、流处理、微批、交互式查询）；消费方多元（BI 报表、机器学习特征、实时风控、数据 API、归档合规）。

在 AWS 上，这条管道不是单一服务，而是一组托管能力的组合。典型形态是：数据先进入 S3 或 Kinesis，经过 Glue/EMR/Lambda/Flink 处理，落入 Redshift、Athena、OpenSearch 或特征存储，再通过 QuickSight、API Gateway、SageMaker 等对外服务。理解这一点很关键：管道是“端到端”的，不是“某个 ETL 作业”。

典型场景：从三条真实链路看管道形态

场景一，日志与行为分析。应用把日志写入 Kinesis Data Streams 或 Firehose，Firehose 按分钟级微批写入 S3，Glue 做分区与格式转换（JSON 转 Parquet），Athena 或 Redshift Spectrum 提供查询。这条链路的关键是分区设计、小文件合并和 schema 演进。

场景二，数据库 CDC 入湖。使用 DMS 或 Debezium 捕获 RDS/Aurora 的变更，写入 Kinesis，再由 Flink 或 Glue Streaming 做去重、打宽、聚合，最终写入 S3 的 Iceberg 表或 Redshift。这里最容易被低估的是乱序、重复和删除事件的处理。

场景三，机器学习特征管道。原始数据入湖后，用 Glue/EMR 做特征计算，写入离线特征表；实时特征则走 Kinesis + Lambda/Flink，写入在线特征存储。训练和推理必须使用同一套特征定义，否则会出现训练-服务偏差。

核心挑战：规模上来之后，问题会换一批

小数据量时，很多问题被掩盖；一旦日增 TB 级、源表上千、消费方几十个，挑战会集中暴露。第一，数据量与成本。S3 存储便宜，但请求费用、跨 AZ 传输、Glue DPU 时长、Redshift 集群空闲成本会迅速累积。第二，Schema 演进。上游加字段、改类型、删列，下游作业可能直接失败。第三，乱序与重复。流式链路中事件时间与处理时间不一致，Exactly-Once 需要靠幂等写入和事务表实现。第四，小文件与分区爆炸。Firehose 每分钟写一次，一天就是 1440 个文件；若按小时分区再按事件时间细分，元数据压力会拖垮查询。第五，治理缺失。没有数据目录，分析师找不到表；没有血缘，改一个字段不知道影响谁；没有质量规则，脏数据直接进报表。

开发与治理双轮驱动框架

本课程把能力分为两个轮子。开发轮负责“让数据流起来”：采集、传输、存储、处理、服务，关注吞吐、延迟、容错、幂等、重放。治理轮负责“让数据可信可控”：元数据与目录、权限与安全、质量与校验、可观测与成本、合规与审计。两个轮子必须同轴：每新增一条管道，就要同步登记目录、定义权限、配置质量规则、接入监控和成本标签。

一个可落地的检查清单如下，建议在每个数据管道上线前逐项确认：

最后强调一个判断标准：一条大规模数据管道是否合格，不是看它能不能跑通一次，而是看它在数据量增长 10 倍、上游改 schema、下游新增消费方、出现脏数据或作业失败时，是否仍然可恢复、可追溯、可解释。开发决定上限，治理决定下限，两者缺一不可。