PyFlink内部运行原理浅析，python+flink+java

转载：https://www.51cto.com/article/713802.html

首先，Flink能力输出到Python用户最核心问题显而易见是Python VM和Java VM的握手，他们之间要建立通讯，这是PyFlink首要解决的问题。

面对PVM和JVM通讯问题，我们选择了Py4J，在PythonVM启动一个Gateway，并且Java VM启动一个Gateway Server用于接受Python的请求，同时在Python API里面提供和Java API一样的对象，比如 TableENV， Table，等等。这样Python在写Python API的时候本质是在调用Java API，同时还有作业部署问题，我们可以用Python命令，Python shell和CLI等多种方式进行作业提交。

那么Py4J和JVM交互的原理是什么呢？其实最核心的机制是在Python端每创建一个对象，都会对应的在Java端创建一个Java对象，并生成一个对象ID，Java端利用Map保存对象ID和对象。同时将对象ID返回Python端，Python端基于对象ID和方法参数进行操作本质上都是在操作Java对象。

那么基于这样的架构有怎样的优势呢？第一个就是简单，并确保Python API语义和Java API的一致性，第二点，Python 作业可以达到和Java一样的极致性能，在刚刚结束的阿里双11狂欢节中，创造了峰值40亿的处理能力。

在完成了现有Flink功能向Python用户的输出之后，接下来我们继续探讨，如何将Python生态功能引入Flink中，进而将Python 功能分布式化。如何达成？结合现有Flink Table API的现状和现有Python类库的特点，我们可以对现有所有的Python类库功能视为 用户自定义函数（UDF），集成到Flink中。这样我们就找到了集成Python生态到Flink中的手段是将其视为UDF，那么集成的核心问题是什么？没错，那就是Python UDF的执行问题。好，我们针对这个核心问题我们如何处理呢？

解决Python UDF执行问题可不仅仅是VM之间通讯的问题了，它涉及到Python执行环境的管理，业务数据在Java和Python之间的解析，Flink State Backend能力向Python的输出，Python UDF执行的监控等等，是一个非常复杂的问题。面对这样复杂的问题，我们选择了统一编程模型Apache Beam，Beam为了解决多语言和多引擎支持问题高度抽象了一个叫 Portability Framework 的架构，如下图，Beam目前可以支持Java/Go/Python等多种语言，其中图下方 Beam Fu Runners 和 Execution之间就解决了 引擎和UDF执行环境的问题。其核心是对利用Protobuf进行数据结构抽象，利用gRPC协议进行通讯，同时封装了核心的gRPC 服务。所以这时候Beam更像是一只萤火虫，照亮了PyFlink解决UDF执行问题之路。我们接下来看看Beam到底提供了哪些gRPC服务。

如图 Runner部分是Java的算子执行，SDK Worker部分是Python的执行环境，Beam已经抽象Control/Data/State/Logging等服务。并这些服务已经在Beam的Flink runner上稳定高效的运行了很久了。所以在PyFlink UDF执行上面我们可以站在巨人的肩膀上了：），这里我们发现Apache Beam 在API层面和在UDF的执行层面都有解决方案，而PyFlink在API层面采用了Py4J解决VM通讯问题，在UDF执行需求上采用了Beam的Protability Framework解决UDF执行环境问题。这也表明了PyFlink在技术选型上严格遵循以最小的代价达成既定目标的原则，在技术选型上永远会选择最合适的，最符合PyFlink长期发展的技术架构。

下面的内容我们一起看看PyFlink的UDF架构设计。

在编写Python作业的同时，Java API也会同时被调用在提交作业之前，Java端会构建.JobGraph。然后通过CLI等多种方式将作业提交到集群进行运行。

我们再来看看运行时Python和Java的不同分工情况，首先在Java端与普通Java作业一样，JobMaster将作业分配给TaskManger，TaskManager会执行一个个Task，task里面就涉及到了Java和Python的算子执行。

在Python UDF的算子中我们会设计各种gRPC服务来完成Java VM和Python VM的各种通讯，比如 DataService 完成业务数据通讯，StateService完成Python UDF对Java Statebackend的调用，当然还有Logging和Metrics等其他服务。这些服务都是基于Beam的Fn API来构建的，最终在Python的Worker里面运行用户的UDF，运行结束之后再利用对应的gRPC服务将结果返回给Java端的PythonUDF算子。

当然Python的worker不仅仅是Process模式，可以是Docker模式甚至是External的服务集群。这种扩展机制，为后面PyFlink与Python生态的其他框架集成打下了坚实的基础。

这里最重要的是如何使用beam的基础设施来执行Python UDF。我们来看看pyflink如何集成Beam的可移植性框架来执行Python UDF。一个场景的场景是对输入数据执行一系列转换并将结果写入另一个外部存储系统。我们知道Flink是用Java 开发的，但是，用户定义的转换逻辑是Python开发的。如图示例，假设ParDo使用了Python UDF，在Beam中引入了一个ExecutableStage，它包含了用户定义的Python函数的所有必要信息，如：输入/输出数据类型、用户定义函数的有效负载、用户定义函数中使用的状态和定时器等等。同时，Beam还提供了一个Java库，可用于管理特定语言的执行环境。”forStage（）“将根据ExecutableStage中定义的信息生成执行用户定义函数所需的进程，就是SDK harness部分，这样建立runner与SDK Harness之间就建立起了通讯连接。