Facebook Presto Connector 开发 [1]

Presto 是Facebook 为了交互式查询数据开发的一个查询引擎. 前些年开源. 最近开发了一些connector , 因此想记录一下presto plugin 的开发思路.

一个很奇怪的问题是: Facebook 早就开源了presto, 一直不怎么火. 但我最近开始关注的时候就比较喜欢这货. 可能是Facebook 大厂员工不怎么运营开源社区的缘故?

思考

不考虑数据写入, 仅仅看查询, presto 要做的事情无外乎一件:

function(data)

就是把data 作为输入, 执行function后给出结果. 单机性能无法支撑, 就要考虑如何在分布式的环境下把function 套在需要的数据上.

既然需要把 function apply 到对应的data 上, 需要做的事情有如下几件:

• metadata: 数据存储在哪里, 数据layout
• 处理分块逻辑: 既然是分布式计算, 需要'平均'分配计算任务.
• 处理读取数据逻辑. 根据查询需求, 读取响应的数据.

Presto Connector 架构

presto_arch.png

以上便是Presto 核心与一个Connector 交互的大体示意图.

• ConnectorHandlerResolver 主要是获取该connector中一些handler的类型信息
• ConnectorMetadata 主要是维护该catalog下的schema和table信息. 例如, mysql connector中的ConnectorMetadata 实现就需要负责读取该数据库配置下有哪些database和哪些table, 以及每个table中的column信息
• ConnectorSplitManger: 主要负责根据查询条件和数据存储, 将计算分解成多个Split, 交给Coordinator 调度. 类似MapReduce中计算InputSplit的概念
• Read操作可以选择实现两个接口: ConnectorPageSourceProvider 和ConnectorRecordSetProvider. 其实RecordSetProvider是更贴近通常数据库的概念的封装, 更容易理解, presto 会将RecordSetProvider返回的数据再左一层Adapter映射到PageXXX的结构上. 而PageSourceProvider 是更底层. 两个选择实现一个就可以
• Write操作同理Read操作, 选择性实现两个接口ConnectorRecordSinkProvider和ConnectorPageSinkProvider中一个接口
• ConnectorIndexResolver 负责根据查询判断是否使用索引. 选择性实现
• ConnectorAccessControl负责数据权限, 可以根据需求实现权限管理. 选择性实现

总结

因此, 要开发一个只读Presto Connector, 最简单仅仅需要实现ConnectorHandlerResolver, ConnectorMetadata, ConnectorSplitManager 和ConnectorRecordSetProvider 四个接口然后整合到一个Connector接口的实现.

备注: 由于自己开发的connector开始是基于0.125版本, 但前几天升级到0.132后发现presto代码经历了重构, 原来com.facebook.presto.spi.Connector 已经被标记为Deprecated, 新的接口是com.facebook.presto.spi.connector.Connector, 不过大体原理没有变化, 之前开发的connector在0.132版本也运行正常.

未完待续....
--EOF--