理解成为

最近写个Presto的UDF,发现点比较有趣的地方.

因为功能上需要运行时访问外部数据,做个类似缓存的读写动作.

所以形式上来说,这是一个带状态的函数.

在SparkSQL里的话,这个处理比较简单.

由于整个execution pipeline是基于序列化的,所以只要能够提供一个某种程度上determinist的初始状态,那么各个executor是可以有一致的表现的.

当然,这个有一些前提.

主要是class版本的一致性.

这个主要是由于kyro本身的问题.

但总得来说是比较straightforward的.

但是presto不太一样.

它采取了一些可能从设计上来说,比较学院派或者说不是那么实用主义的设计.

从架构上来说,它的udf主要通过一种plugin机制扩展.

而为了比较好地.或者说便于udf的作者提供更flexible的实现,所以采用了一个独立的plug classloader的方式加载对应的实现.

这个从工程上来说,也是一个可能容易被选择的方案.

因为弱化了实现的库版本依赖的约束,允许plugin作者选择自己prefer的各种其他库.

这里它为了比较好地解决不同classloader同名类不兼容的问题,主要也是plugin spi类的可cast问题,在plugin classloader里面做了个白名单机制.

是的SPI的类从同一个classloader加载,避免隔离机制造成的互相不兼容.

不过这里形式上也提供了一种调用主classloader的实现的一些方式.

毕竟已知的白名单类可以得到app classloader,自然也就有办法使用到所有的类.

不过这算classloader这种sandbox机制的某种特性吧.

毕竟形式上来说,这也是JVM的claasloader sanbox对立统一的一面.

而且整个udf runtime和execution pipeline的执行某种程度也是依靠这种leakage来实现的.

因为它不像SparkSQL是依靠序列化传递函数实现,而是靠比较轻量的某种执行计划描述在个节点节点重构调用链的.

所以形式上来说,可能各个节点运行的版本并不严格一致.

因为jar包可能不一样.

不过这在实际场景下可能不是一个大问题.

尤其如果是用容器方式运行的话.

这里的主要问题在于它对udf函数的初始化处理.

大体上来说,是比较标准的依赖注入的思路.

扫描类的annotation来生产udf的描述信息和运行时绑定方式.

这里比较tricky的是对udf的绑定是通过method handler实现的.

这个大概率可能是一种基于性能借口的炫技.

因为对于一个generic的udf来说,入参数量和返回值是不确定的.

像SparkSQL就索性采用了一个透明的类Object/Any方式.

好处是SPI接口简单.

坏处也显而易见,不能简单地知道入参出参的类型.

Presto形式上来说也可以采用这样的方式.

而且实际上来说,如果采用这种方式的话,可能更有利于vectorize.

毕竟本身就内部pipeline的传递的page/block就是某种batch data.

但显然作者没有采用这种实用主义的手法.

而是用了method handler以便能够在udf的声明上就清晰函数的定义.

把heavy lifting的事情放在method handler的参数绑定上.

甚至炫技的地方还不单在这种类curry的functional化上.

甚至还允许函数声明根据参数类型做specialize,一定程度上做着类似template specialized的事情.

对特定类型的参数可以提供统一但优化的实现和声明.

这个炫技本身倒没什么.

只不过从实际实现上来说,它引入了一个隐性约束.

就是这个函数的implementaion部分必须是static的.

因为这样才可能在早期绑定确定的method handler.

虽然看实现上也支持非static method的绑定.

但对于hosting class的constructor有一定的限制.

而且本质上来说,这个hosting instance也是once bounded的.

作用上就是一个static的singleton.

所以没办法从这个角度去让某个udf调用带有状态.

于是要带状态的话,一种思路是把状态相关的部分作为参数inject到udf的入参里.

这个的问题主要是在explain语句的时候,会有一些可能或干扰或敏感或意义不明的部分让人confuse,或者说知道了不必知道的实现细节.

当然,这个通过override某些函数是可以redacted的.

但是总的来说,不是很便利.

另外一点就是late binding的问题.

有时候udf入参的一部分并不需要立即evaluate,而是需要在udf实现里根据情况决定是否做eval.

这个在SparkSQL因为expression是可以自定义哪些需要eval的.

不管是eval模式还是codegen模式,自主性都比较flexible.

而presto的因为前面method handler的那些magic,基本上generate出来的bytecode都是实际eval出来的结果再入参的.

也就是说,在这方面的可控性并不如SparkSQL.

如果将这些late binding需求的部分作为原始string传入,再再udf里编译的话,有几个问题.

一个是这个compile流程不算友好.

如果bytecode模式的话,需要处理多个class loader的问题.

因为前面也说了,plugin本身的class是在一个半isolated的class loader.

而bytecode generate因为使用了method handler这个builtin class,所以形式上可以不管实现,在一个独立的mini classloader就可以完成code gen.

而卒后执行的时候又是在main classloader里执行.

所以在运行时,或者说函数的调用逻辑里需要毕竟明确的知道会触发class loading的点和确保bind了正确的classloader.

而如果是interpreter模式的话同样有类似的问题.

并且除了这个问题之外,还有怎么构造compiler/interpreter也是跟问题.

因为整个presto是按照guice的inejctor构造的.

而plugin的接口和loading方式又缺乏引入injector从而获得相关依赖服务构造对应compiler/interpretor的方式,所以实际上也不太可行.

即使是强行构造了一些等价接口的话,在覆盖率上也是有所差异的.

这使得即使构造成功,可能运行时的表现也不尽如人意.

再就是即使构造成功,处于性能考虑,如何对整个compile结果缓存也是个问题.

因为前面所说的method invoke是无状态的.

不过因为本身表达式是string形态,所以缓存这方面倒相对来说更直接一点.

而如果不走这种compile/interpretor方式的话,presto倒是提供了一种间接或者说直接late binding的方式.

那就是presto sql的lambda expression.

这个倒是解决了按需evaluate的问题.

并且不需要复杂的compile/interpreter,甚至于都不需要做method handler的缓存.

意味本身就已经是bindable了的,在函数声明里就是个通用的明确的functional interface.

但这里也回到了缓存状态的问题上.

针对一个udf的调用,形式上是根据某些特定的入参生成一个确定的cache key以帮助查找的.

但是如果同时有late binding的需求的话,那么因为functional interface本身不太cache sensitive.

也就说,很难说两个functional interface是否具有相同的逻辑,从而增加了缓存的难度.

而这里因为前面说的bytecode codegen的classloader是个不关心/aware plugin classloader的.

所以实际上它接收的functional interface只能是jdk builtin的interface.

无法通过扩展的方式,使得运行时能从这个入参里得到一些比较显著的信息.

能想到的方式只能是walkaroud地再inject一个足够distinguish的比如原始expr的string参数,同时想办法在explain等场景里给它屏蔽/不显示干扰.

总的来说,核心问题可能还是在于Presto整体设计有些学院派.

不像SparkSQL更多的是秉持某种能用就行.

虽然比较讽刺的是Presto本身是Facebook这种喊出move fast break things的工程实用主义的公司搞出来的.

不过想想自己也是.

曾几何时倒也是看不太起Spark+Scala这种到处又不是不能用哲学组合的产品.

现在却是走到了理解成为的阶段.