2. 数据管道架构设计原则
数据管道架构设计原则不是一组抽象口号，而是对后续每一个技术选型、每一次代码提交、每一轮容量评估的约束条件。在 AWS 上构建大规模数据管道时，如果一开始没有把这六条准则落到具体的接口、参数和判断标准上，后期往往会出现“批任务和流任务各维护一套逻辑”“上游改字段导致下游全量重跑”“成本失控却找不到是哪一段在烧钱”等典型问题。本节把六条准则拆解为可执行的设计动作，并给出一个贯穿全节的示例场景：一条从应用日志到分析仓库的管道，源端为每秒约 5000 条事件的 JSON 日志，目标端为可供 BI 查询的明细表与聚合表。
批流一体：统一逻辑，分离执行
批流一体的核心不是“用同一个引擎跑批和流”，而是让业务逻辑只定义一次，由不同的执行模式去消费。实践中常见的做法是把转换逻辑写成对“有界或无界数据集”都成立的算子，例如基于事件时间窗口的聚合、基于主键的去重、基于水位线的迟到数据处理。以示例场景为例，日志中的 event_time 作为事件时间，user_id 作为去重主键，批处理回补历史数据与流处理处理实时数据使用同一套窗口定义（如 5 分钟滚动窗口、允许 2 分钟迟到）。
在 AWS 上，批流一体通常体现为：流侧用 Kinesis Data Streams 或 MSK 承接实时事件，经 Managed Service for Apache Flink 做窗口聚合写入分析仓库；批侧用 Glue 或 EMR 对 S3 上的历史分区做同样的聚合逻辑，回补或修正结果。判断是否真正做到批流一体，可以看一个指标：同一业务口径的聚合结果，批与流两条路径在相同时间范围内的差异是否只来自迟到数据，而不是来自逻辑实现不同。
松耦合：以契约替代依赖
松耦合要求上下游之间通过稳定的数据契约交互，而不是通过“我知道你会怎么写”来交互。具体动作包括：在 S3 上按 dt=YYYY-MM-DD/hour=HH/ 分区约定路径；在 Kinesis 或 Kafka 中约定 topic 与 schema；用 Glue Data Catalog 或 Schema Registry 管理表结构与版本。示例场景中，源端日志新增一个 device_type 字段时，下游不应因为多了一个字段而失败，而应通过 schema 演进策略（如向后兼容）自动接纳。
松耦合还体现在故障隔离上。流处理作业写入 S3 的原始层，再由另一个作业做清洗入仓，而不是让流作业直接写最终表。这样当清洗逻辑需要调整时，只需重跑清洗层，不必回放整个流。判断松耦合是否达标，可以问：如果上游把字段从 string 改为 int，下游需要改几处代码？理想答案是零处，只需更新 schema 注册信息。
可扩展：分区、并行与背压
可扩展性在数据管道中主要受三个因素制约：分区键设计、并行度配置和背压处理。以 Kinesis Data Streams 为例，一个分片写入上限为 1 MB/s 或 1000 条记录/s，示例场景每秒 5000 条、每条约 1 KB，则至少需要 5 个分片才能满足写入，实际应留出 30% 余量，取 8 个分片。分区键选择 user_id 可以保证同一用户的事件有序，但若某些用户事件量极大，会造成热点分片，此时可改用 user_id + 随机后缀 打散，代价是同一用户不再严格有序。
计算侧的可扩展性体现在 Flink 的并行度与 Glue 的 worker 数量上。流作业并行度不应超过分片数，否则多余并行子任务空转；批作业则按数据量估算，例如 1 TB 数据用 10 个 G.1X worker 约需 20 分钟，若要求 10 分钟完成则需约 20 个 worker。判断可扩展性是否达标，可以观察在数据量翻倍时，是延迟线性增长，还是出现分片限流或作业反压。
可观测：指标、日志与血缘
可观测性不是“出问题再查”，而是提前定义好要观察什么。一条数据管道至少应采集三类信号：延迟（事件时间到写入时间的差值）、吞吐（每秒处理记录数）、错误率（反序列化失败、写入失败比例）。在 AWS 上，这些信号可以通过 CloudWatch 指标、Flink 的 checkpoint 与反压指标、Glue 的 job run 状态来获取。示例场景中，若流作业的 currentProcessingTime - eventTime 持续超过 5 分钟，说明处理跟不上，需要扩容或优化。
血缘与数据质量同样属于可观测范畴。用 Glue Data Catalog 记录表与作业的输入输出关系，用 Lake Formation 记录权限授予路径，可以在出现“某张表数据异常”时快速定位到上游作业。判断可观测性是否达标，可以问：如果最终表今天少了一小时数据，能否在 5 分钟内定位到是源端没发、流作业失败，还是清洗作业过滤掉了？
安全合规与成本优化：约束下的平衡
安全合规要求数据在传输、存储、访问三个环节都有控制。传输用 TLS，存储用 SSE-KMS 加密，访问用 IAM 角色与 Lake Formation 列级权限。示例场景中，日志包含 user_id 与 ip，属于个人信息，应在清洗层做脱敏或哈希后再入仓，原始层设置较短的生命周期（如 30 天）并限制访问角色。合规还要求可审计，CloudTrail 与 S3 访问日志应开启并保留足够时长。
成本优化不是一味省钱，而是在满足延迟与合规前提下的单位数据处理成本最低。主要手段包括：S3 生命周期策略把原始层从 Standard 转 IA 再转 Glacier；Kinesis 按实际吞吐选择按需或预置模式；Glue 作业使用 G.1X 而非 G.2X 除非内存确实不足；Flink 作业开启自动扩缩容。示例场景中，若原始层每天 500 GB，30 天后转 IA，90 天后转 Glacier，相比全部保留在 Standard，一年可节省约 60% 存储成本（按示例价格估算，实际以账单为准）。
六条准则的协同判断
六条准则并非彼此独立。批流一体要求逻辑统一，这本身就依赖松耦合的 schema 契约；可扩展性决定了在数据量增长时是否还能维持可观测的延迟指标；安全合规与成本优化常常相互拉扯，例如加密与审计会增加开销，但可以通过生命周期策略和按需计费来平衡。实际设计中，建议在架构评审时逐条对照：这条管道在数据量翻 10 倍时，哪一条准则会先失效？如果答案是“可扩展性”，就应优先调整分区键与并行度；如果答案是“成本”，就应检查存储分层与计算资源规格。