Presto 是Facebook 为了交互式查询数据开发的一个查询引擎. 前些年开源. 最近开发了一些connector , 因此想记录一下presto plugin 的开发思路.
一个很奇怪的问题是: Facebook 早就开源了presto, 一直不怎么火. 但我最近开始关注的时候就比较喜欢这货. 可能是Facebook 大厂员工不怎么运营开源社区的缘故?
思考
不考虑数据写入, 仅仅看查询, presto 要做的事情无外乎一件:
function(data)
就是把data 作为输入, 执行function后给出结果. 单机性能无法支撑, 就要考虑如何在分布式的环境下把function 套在需要的数据上.
既然需要把 function apply 到对应的data 上, 需要做的事情有如下几件:
- metadata: 数据存储在哪里, 数据layout
- 处理分块逻辑: 既然是分布式计算, 需要'平均'分配计算任务.
- 处理读取数据逻辑. 根据查询需求, 读取响应的数据.
Presto Connector 架构
以上便是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--
