Apache Beam Fn API 处理Bundle

概述Overview

在Apache Beam Fn API 总体介绍中阐述了总体视角，列出了一系列相关的文档。本文中描述了Beam Runner和Beam SDK Harness交互的细节，使用Fn API来处理Bundle(一组乱序的数据)

处理Bundle

需求Requirements

高层视角的处理过程

注册UDF用户自定义函数

设计和实现考虑

实现要求

单个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。

高层视角的处理过程

1. (可选)Runner注册1个ProcessBundleDescriptor 。
2. Runner发到ProcessBundleRequest 到特定SDK的ProcessBundleDescriptor 。
3. SDK Harness实例化在ProcessBundleDescriptor 描述的UDF。
4. SDK Harness将UDF中的输入和输出组装到一起，生成一个执行子图。
5. SDK harness连接和重用远程的输出流。
6. SDK harness将UDF产生的数据元素进行编码封装到流中。
7. SDK harness开始执行Bundle，调用UDF。
8. SDK harness连接和重用远程输入流。
9. Runner 使用Data Plane API 编码数据元素为数据流。
10. SDK harness解码，使用子图处理数据元素。The SDK harness decodes and processes elements through the execution sub-graph
11. Runner发出信号中止逻辑输入流。
12. SDK harness完成UDF Bundle的执行。
13. SDK harness发出信号中止所有的逻辑输出流。
14. 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传送的数据。

 

结束！

转载需标明文章来源！

http://blog.csdn.net/ffjl1985/article/details/78241388