1. 课程导入与全景认知

在真实的数据平台里，数据很少只以一种方式到达。订单库的变更需要秒级同步到搜索与风控系统，这是流；而每天凌晨要把前一天的全部交易、退款、结算明细汇总成财务口径的报表，这是批。两者共用同一批业务事实，却对时效、成本、容错和一致性提出完全不同的要求。所谓“批流数据管道”，不是把批和流简单并列，而是让同一份数据在两条路径上各得其所，并在需要时汇合到同一张明细表或同一个指标口径上。

从业务价值看，批流管道解决三类问题。第一类是时效分层：核心风控、库存扣减、实时推荐走流式，分钟级到秒级；经营分析、对账、结算走批式，小时级到天级。第二类是口径统一：如果实时看板和离线报表各算各的，同一指标会出现两个数字，业务方无法决策。第三类是成本与可靠性平衡：流式常驻资源贵，批式可弹性伸缩、可重跑，把不要求实时的计算放到批侧，是常见的成本优化手段。

AWS 的数据集成服务矩阵可以按“采集—传输—转换—编排—分析”五个位置来理解，而不是记一串产品名。采集侧，AWS DMS 负责数据库的持续复制（CDC），Kinesis Data Streams / Data Firehose 负责日志与事件流的接入；传输与缓冲侧，Amazon S3 是批流共同的落地层，Amazon MSK 提供 Kafka 兼容的高吞吐管道；转换侧，AWS Glue 提供 Spark 作业与 Data Catalog，Glue Streaming 可消费 Kinesis/MSK 做微批处理；编排侧，AWS Step Functions 负责有状态的任务编排，Amazon MWAA 承载 Airflow DAG；分析侧，Athena 做交互式查询，Redshift 做数仓聚合，OpenSearch 支撑检索。理解这张矩阵的关键，是知道每个服务在管道中的“位置”和“职责边界”，而不是孤立地背特性。

任务编排的核心挑战往往不在单个作业内部，而在作业之间。第一是依赖与触发：上游 S3 分区就绪、DMS 复制延迟归零、Kinesis 分片积压低于阈值，才允许下游启动。第二是幂等与重跑：批作业失败后重跑不能产生重复数据，通常靠分区覆盖写或主键去重实现。第三是状态与补偿：流式任务失败后从检查点恢复，批任务失败后按分区重算，两者的恢复语义不同。第四是可观测性：没有统一的运行状态、延迟指标和告警，管道会在“看起来在跑”的状态下悄悄产出错误数据。

把这张全景图落到具体操作上，一个典型的批流管道可以这样起步。假设业务库是 MySQL，需要把订单变更实时同步到 OpenSearch 供客服检索，同时每天生成订单汇总表供财务对账。第一步，用 DMS 创建复制实例，源端 MySQL 开启 binlog，目标端选择 Kinesis Data Streams，这样变更事件以流的形式进入。第二步，用 Glue Streaming 作业消费该流，做字段清洗和脱敏后写入 OpenSearch，作业开启检查点，失败后从最近检查点恢复。第三步，用 Firehose 把同一份流数据以微批方式投递到 S3 的 raw/orders/dt=YYYY-MM-DD/ 分区，形成批处理的原始层。第四步，用 Glue ETL 作业每天读取前一天分区，做聚合后覆盖写入 Redshift 的 dws_order_summary 表，覆盖写保证重跑幂等。第五步，用 Step Functions 编排：先检查 S3 分区是否就绪，再触发 Glue ETL，成功后发送 SNS 通知，失败则重试两次并告警。

这里有几个容易踩的坑值得提前记住。DMS 到 Kinesis 的复制延迟需要监控 CDCLatencySource 和 CDCLatencyTarget，延迟升高时下游流作业会读到滞后数据。Glue Streaming 的微批间隔决定延迟与吞吐的平衡，间隔太小会产生大量小文件，太大则实时性下降。S3 分区命名必须与 Glue 分区投影或 Crawler 的识别规则一致，否则 ETL 读不到数据。Redshift 覆盖写要确保事务边界正确，避免中途失败留下半份数据。

本课程的学习路线图按“认知—单点—串联—治理”推进。前几章建立批流管道的整体认知与 AWS 服务矩阵；随后分别深入 DMS 与 Kinesis 的采集与传输、Glue 的批式与流式转换、Step Functions 与 MWAA 的编排；再进入批流汇合、数据湖分层、幂等与重跑、延迟与积压监控等工程问题；最后落到成本优化、安全权限与故障排查。每一章都会给出可操作的参数、示例数据和判断依据，帮助你把“知道有这个服务”变成“知道怎么接、怎么调、怎么判断它是否正常”。