2. AWS 数据管道基础组件
在 AWS 上搭建批流数据管道，最容易犯的错误不是“不会用某个服务”，而是“用错服务”。S3、Glue、Kinesis、MSK、Step Functions、MWAA 这六个组件经常同时出现在一张架构图里，但它们的职责边界其实非常清晰：有的负责存，有的负责算，有的负责传，有的负责编排。选型时如果只记住“它们都能处理数据”，就很容易把 Kinesis 当成消息队列长期存储，或者把 Step Functions 用来跑小时级 Spark 作业，最终在成本和可维护性上付出代价。
下面这张图先把六个组件按“数据面”和“控制面”分层，并标出典型的数据流向，帮助建立整体定位。
一、存储底座：S3 是数据湖的“默认答案”
S3 在这六个组件中角色最稳定：它是对象存储，不是文件系统，也不是数据库。批处理场景中，S3 通常作为原始数据区（Raw Zone）、清洗后数据区（Cleaned Zone）和聚合结果区（Curated Zone）的物理载体。流处理场景中，Kinesis 或 MSK 的数据也往往通过 Firehose、Lambda 或 Flink 最终写入 S3，形成“流接入、批沉淀”的格局。
选型时 S3 几乎不需要犹豫，但需要关注三个参数：存储类别（Standard、Intelligent-Tiering、Glacier 系列）、分区方式（按 dt=YYYY-MM-DD/hour=HH 前缀组织）和文件大小（避免大量小文件）。例如，一个典型的日志管道会按 s3://my-lake/raw/logs/dt=2025-01-15/hour=08/ 写入，每个文件控制在 128MB～512MB，便于后续 Glue 或 Athena 扫描。
二、计算与元数据：Glue 不只是 ETL
Glue 常被简单理解为“托管的 Spark”，但它实际包含三个可独立使用的部分：Glue Catalog（元数据目录）、Glue ETL（Spark 作业）和 Glue DataBrew（可视化清洗）。Catalog 是很多 AWS 分析服务的公共元数据入口，Athena、Redshift Spectrum、EMR 都依赖它。因此，即使你不用 Glue 跑 ETL，也建议把 S3 上的数据结构注册到 Catalog，形成统一的表定义。
Glue ETL 作业的典型配置包括：Worker 类型（G.1X、G.2X、G.4X）、Worker 数量、作业书签（Job Bookmark）和并发度。作业书签用于增量处理，避免重复读取已处理文件；并发度则影响同时运行的作业实例数。一个常见的批处理示例是：每天凌晨 2 点，Glue 作业读取 S3 上前一天的分区，做字段清洗和类型转换，写入 Parquet 格式到 Curated Zone，并更新 Catalog 分区。
三、流接入：Kinesis 与 MSK 的分工
Kinesis Data Streams 和 MSK 都用于实时数据接入，但设计哲学不同。Kinesis 是 AWS 原生服务，按 Shard 计费，每个 Shard 提供 1MB/s 写入和 2MB/s 读取，扩展时需要拆分或合并 Shard。MSK 则是托管的 Kafka，按 Broker 实例计费，保留 Kafka 的 Topic、Partition、Consumer Group 模型，适合已有 Kafka 技术栈或需要 Kafka 生态（如 Kafka Connect、KSQL）的团队。
选型判断可以简化为：如果团队没有 Kafka 运维经验，且数据量在每秒几 MB 到几十 MB，Kinesis 更省心；如果需要毫秒级延迟、跨 AZ 高可用、或者要复用现有 Kafka 工具链，MSK 更合适。两者都可以通过 Lambda、Flink 或 Glue Streaming 消费，最终写入 S3 或 Redshift。
四、编排层：Step Functions 与 MWAA 的边界
Step Functions 是状态机服务，适合编排“步骤明确、单步执行时间短、需要重试和分支”的流程。例如：一个文件到达 S3 后，触发 Step Functions，依次调用 Lambda 做校验、Glue 作业做转换、SNS 发通知。它的优势是可视化、内置重试、错误捕获和并行分支，但单次执行时间上限为一年，且不适合跑长时间 Spark 作业本身（只负责触发和等待）。
MWAA 是托管的 Apache Airflow，适合“定时调度、复杂依赖、需要回填（Backfill）、跨系统编排”的场景。Airflow 的 DAG 用 Python 定义，可以表达“任务 A 成功后并行执行 B 和 C，B 完成后才能执行 D”这类依赖。MWAA 的典型用法是：每天调度多个 Glue 作业、EMR 步骤和 Lambda 函数，形成完整的批处理流水线。它的成本按环境小时计费，即使没有任务运行也会产生费用，因此适合任务密度较高的场景。
五、选型对比表
| 组件 | 核心定位 | 延迟/时效 | 典型计费维度 | 优先选择场景 |
|---|---|---|---|---|
| S3 | 对象存储 / 数据湖底座 | 无延迟概念，按请求响应 | 存储量 + 请求次数 | 所有批流管道的最终落点 |
| Glue | ETL + 元数据目录 | 分钟级批处理 | DPU 小时 | Spark 清洗、Catalog 注册 |
| Kinesis | 实时流接入 | 秒级 | Shard 小时 + PUT 负载 | 无 Kafka 经验、中等吞吐 |
| MSK | Kafka 兼容流平台 | 毫秒级 | Broker 实例小时 + 存储 | 已有 Kafka 生态、高吞吐 |
| Step Functions | 状态机编排 | 毫秒级触发，步骤级重试 | 状态转换次数 | 事件驱动、短步骤、分支重试 |
| MWAA | 托管 Airflow 调度 | 分钟级调度精度 | 环境小时 + Worker 小时 | 复杂 DAG、回填、跨系统批调度 |
实际项目中，这六个组件很少单独出现。一个典型的混合管道可能是：Kinesis 接收实时点击流，Lambda 做初步过滤后写入 S3 Raw Zone；MWAA 每天凌晨调度 Glue 作业清洗 Raw Zone 并写入 Curated Zone；Step Functions 负责处理单个文件到达事件，触发校验和通知。理解每个组件的“不可替代性”，比记住它们的功能列表更重要。