Apache Beam Fn API 处理Bundle
概述Overview
在Apache Beam Fn API 总体介绍中阐述了总体视角，列出了一系列相关的文档。本文中描述了Beam Runner和Beam SDK Harness交互的细节，使用Fn API来处理Bundle(一组乱序的数据)
单个Bundle处理请求的生命周期Life of a Single Process Bundle Request
处理Bundle
从高层的视角，处理Bundle包含了Runner注册一系列的描述Pipeline子图的UDF。Runner然后请求SDK执行定义的子图一次或者多次，每一次调用代表1个Bundle。
At a high level, processing a bundle entails the Runner registering a set of user definable functions (UDFs) describing a sub-graph of the user's pipeline. The Runner then requests that the SDK executes that sub-graph definition one or more times, each invocation representing a bundle.
需求Requirements
SDK Harness初始化，然后使用BeamFnControl连接到一个Runner。
高层视角的处理过程
- (可选)Runner注册1个ProcessBundleDescriptor 。
- Runner发到ProcessBundleRequest 到特定SDK的ProcessBundleDescriptor 。
- SDK Harness实例化在ProcessBundleDescriptor 描述的UDF。
- SDK Harness将UDF中的输入和输出组装到一起，生成一个执行子图。
- SDK harness连接和重用远程的输出流。
- SDK harness将UDF产生的数据元素进行编码封装到流中。
- SDK harness开始执行Bundle，调用UDF。
- SDK harness连接和重用远程输入流。
- Runner 使用Data Plane API 编码数据元素为数据流。
- SDK harness解码，使用子图处理数据元素。The SDK harness decodes and processes elements through the execution sub-graph
- Runner发出信号中止逻辑输入流。
- SDK harness完成UDF Bundle的执行。
- SDK harness发出信号中止所有的逻辑输出流。
- SDK成功完成ProcessBundleRequest的处理。
注册UDF用户自定义函数
设计和实现考虑
提前注册UDF函数例如Coders编码器、DoFn等，在执行一个特定Bundle时，最小化了Runner和SDK harness之间的传输的数据量。同时，能够让SDK缓存UDF中的活动变量，通过重用显著的降低性能负担。例如在Java中，某些特定的低延迟场景下，使用微小的Bundle，反序列化DoFn函数消耗了25%的CPU计算能力。
除了UDF的定义，ProcessBundleDescriptor中包含了Pipeline的子图，描述了UDF之间的相关连接关系（可以想象为一个流程图）。为了性能，SDK可能会更进一步缓存UDF的活动变量和执行子图中的活动变量。由SDK harness来负责选择活动对象的缓存技术和策略，建议Sdk Harness随着时间，根据初始化的成本和内存的紧张程度，来移除无用的实例。
由于绝大部分的设计考虑都倾向于提升性能，在实现的时候，Runner可能会为每一个ProcessBundleRequest使用1个唯一个ProcessBundleDescriptor，但是建议重用ProcessBundleDescriptor。同样的在实现SDK harness的时候，缓存活动对象不是必须的，但是能够带来性能提升。注意两者都需要通过***制来最大化带来的好处。
实现要求
ProcessBundleDescriptor的作用于与发送ProcessBundleDescriptor的BeamFnControl流的作用域一致。
无论什么原因导致在SDK harness中注册失败，都必须返回Runner一个失败的InstructionResponse。
单个Bundle处理请求的生命周期
ProcessBundleRequest设计用来代表Runner，表示一组由SDK harness处理的工作。ProcessBundleRequest允许执行特定SDK的UDF，例如DoFn、WindowFn、CombineFn等。
设计和实现考虑
ProcessBundleRequest设计的越小越好，因为Runner会频繁的产生。优化ProcessBundleRequest的处理对SDK harness的性能提升有极大的帮助。
实现要求
ProcessBundleRequest的作用域是BeamFnControl和SDK 返回ProcessBundleResponse中较短的那一个。
SDK Harness可能在在收到通过BeamFnControl传送的ProcessBundleDescriptor之前，收到通过BeamFnData流传送的数据。SDK必须要确保，收到数据，并且一旦ProcessBundleDescriptor可用之后立即处理数据。
在SDK Harness中，任何Bundle的处理失败，必须返回Runner一个失败InstructionResponse。在BeamFnControl的声明周期中，SDK Harness 必须要跟踪InstructionRequest。任何通过BeamFnControl发送的跟这个ProcessBundleDescriptor相关的请求也必须失败。Runner和SDK harness丢弃可以跟这个ProcessBundleRequest，任何通过BeamFnData传送的数据。
结束！
转载需标明文章来源！