用途
当 Apache Beam 作为批处理和流处理的统一抽象层时，可使用本技能。它帮助智能体在保持可移植性的同时，不隐藏时间语义或运行器特定约束。
何时使用
- 为批处理、流处理或统一工作负载构建 Apache Beam 流水线
- 面向多个运行器，如 Dataflow、Flink、Spark 或 Direct Runner
- 在批处理和流处理模式间共享转换逻辑
- 管理窗口、水位线、触发器和迟到数据处理
- 设计必须跨环境运行的便携式流水线
当工作负载锁定到单一运行器且 Beam 可移植性不是目标时，不应使用本技能。
工作流程
1. 定义流水线契约和时间语义
包括：
- 输入 PCollections 及其有界或无界性质
- 事件时间与处理时间的预期
- 输出模式、粒度和新鲜度要求
- 下游消费者期望的投递保证
2. 将可移植流水线逻辑与运行器特定部署分离
- 保持转换、DoFn 和组合器与运行器无关
- 将运行器配置（并行度、自动扩缩、资源提示）隔离到流水线选项中
- 记录支持并测试了哪些运行器
- 除非明确牺牲可移植性，否则避免使用运行器特定 API
3. 显式设计窗口和触发器策略
考虑：
- 固定、滑动、会话或全局窗口
- 触发器行为：何时发出、累积或丢弃
- 允许的迟到和迟到数据路由
- 每个源的水位线推进假设
4. 谨慎处理状态和侧输入
- 有状态 DoFn 绑定到特定键空间——记录键基数
- 侧输入在规模上可能成为瓶颈——优先使用有界且小的侧输入
- 定时器必须考虑水位线驱动与处理时间语义
- 无界流水线的状态清理必须显式
5. 将测试和本地验证纳入工作流程
- 使用 DirectRunner 进行正确性测试
- 通过合成水位线推进验证窗口行为
- 通过流水线排空和重启测试精确一次语义
- 确认至少一次运行器的输出幂等性
6. 规划部署、扩展和运维可观测性
- 定义每个运行器的自动扩缩边界和成本限制
- 暴露转换级指标，用于延迟、吞吐量和积压
- 为流处理流水线规划排空和更新策略
- 记录回滚：流水线能否安全地重新部署到较早版本？
常见合理化误区
- “Beam 是可移植的，所以我们不需要考虑运行器。”——运行器在自动扩缩、状态后端、shuffle 行为和融合方面的差异会影响正确性和成本。在单一运行器上测试并不能证明可移植性。
- “我们可以对批处理和流处理使用相同的流水线而不做更改。”——有界和无界 PCollections 在窗口、触发器和水位线方面行为不同。统一并不意味着完全相同。
- “DirectRunner 测试就够了。”——DirectRunner 不会暴露并行度、shuffle 或扩展问题。生产信心需要在目标运行器上进行集成测试。
- “迟到数据可以以后再处理。”——迟到数据处理必须作为初始窗口和触发器设计的一部分。在消费者依赖输出后再改造允许的迟到是破坏性的。
危险信号
- 流水线仅在 DirectRunner 上运行，从未在生产运行器上测试过
- 窗口策略未定义，或对无界源使用全局窗口
- 没有文档说明支持或测试了哪些运行器
- 有状态 DoFn 没有键基数分析或状态清理计划
- 流水线更新需要完全重新处理，因为没有排空或保存点策略
- 侧输入无界或无限增长
- 除运行器提供的默认值外，没有指标或可观测性
验证清单
- 流水线契约定义了输入、输出、时间语义和投递保证
- 窗口、触发器和允许的迟到已明确设计并测试
- 运行器特定配置与可移植转换逻辑隔离
- 状态和侧输入有界，并有清理或驱逐计划
- 流水线已在目标生产运行器上测试，而不仅仅是 DirectRunner
- 排空、更新和回滚策略已记录
- 运维指标覆盖每个转换的延迟、吞吐量、积压和错误率