原文链接：https://blog.csdn.net/D55dffdh/article/details/82423831
前言
这两年做 streamingpro 时，不可避免的需要对Spark做大量的增强。就如同我之前吐槽的，Spark大量使用了new进行对象的创建，导致里面的实现基本没有办法进行替换。
比如SparkEnv里有个属性叫closureSerializer，是专门做任务的序列化反序列化的，当然也负责对函数闭包的序列化反序列化。我们看看内部是怎么实现的：
这里直接new了一个JavaSerializer,并不能做配置。如果不改源码，你没有任何办法可以替换掉掉这个实现。同理，如果我想替换掉Executor的实现，基本也是不可能的。
今年有两个大地方涉及到了对Spark的【魔改】，也就是不通过改源码，使用原有发型包，通过添加新代码的方式来对Spark进行增强。
二层RPC的支持
我们知道，在Spark里，我们只能通过Task才能touch到Executor。现有的API你是没办法直接操作到所有或者指定部分的Executor。比如，我希望所有Executor都加载一个资源文件，现在是没办法做到的。为了能够对Executor进行直接的操作，那就需要建立一个新的通讯层。那具体怎么做呢?
首先，在Driver端建立一个Backend,这个比较简单，
这样，你可以理解为在Driver端启动了一个PRC Server。要运行这段代码也非常简单，直接在主程序里运行即可：
这里我们需要实现local模式和cluster模式两种。
Driver启动了一个PRC Server，那么Executor端如何启动呢?Executor端似乎没有任何一个地方可以让我启动一个PRC Server? 其实有的，只是非常trick,我们知道Spark是允许自定义Metrics的，并且会调用用户实现的metric特定的方法，我们只要开发一个metric Sink,在里面启动RPC Server，骗过Spark即可。具体时下如下：
到这里，我们就能成功启动RPC Server，并且连接上Driver中的PRC Server。现在，你就可以在不修改Spark 源码的情况下，尽情的写通讯相关的代码了，让你可以更好的控制Executor。
比如在PSExecutorBackend 实现如下代码：
接着你就可以在Spark里写如下的代码调用了：
是不是很酷。
修改闭包的序列化方式
Spark的任务调度开销非常大。对于一个复杂的任务，业务逻辑代码执行时间大约是3-7ms,但是整个spark运行的开销大概是1.3s左右。
经过详细dig发现，sparkContext里RDD转化时，会对函数进行clean操作，clean操作的过程中，默认会检查是不是能序列化(就是序列化一遍，没抛出异常就算可以序列化)。而序列化成本相当高(默认使用的JavaSerializer并且对于函数和任务序列化，是不可更改的)，单次序列化耗时就达到200ms左右，在local模式下对其进行优化，可以减少600ms左右的请求时间。
当然，需要申明的是，这个是针对local模式进行修改的。那具体怎么做的呢?
我们先看看Spark是怎么调用序列化函数的，首先在SparkContext里，clean函数是这样的：
调用的是ClosureCleaner.clean方法，该方法里是这么调用学序列化的：
SparkEnv是在SparkContext初始化的时候创建的，该对象里面包含了closureSerializer，该对象通过new JavaSerializer创建。既然序列化太慢，又因为我们其实是在Local模式下，本身是可以不需要序列化的，所以我们这里想办法把closureSerializer的实现替换掉。正如我们前面吐槽，因为在Spark代码里写死了，没有暴露任何自定义的可能性，所以我们又要魔改一下了。
首先，我们新建一个SparkEnv的子类：
接着实现一个自定义的Serializer：
接着我们需要再封装一个LocalNonOpSerializer，
现在，万事俱备，只欠东风了，我们怎么才能把这些代码让Spark运行起来。具体做法非常魔幻，实现一个enhance类：
完工。
其实还有很多
比如在Spark里，Python Worker默认一分钟没有被使用是会被杀死的，但是在StreamingPro里，这些python worker因为都要加载模型，所以启动成本是非常高的，杀了之后再启动就没办法忍受了，通过类似的方式进行魔改，从而使得空闲时间是可配置的。如果大家感兴趣，可以翻看StreamingPro相关代码。