Presto 是Facebook 為了交互式查詢數(shù)據(jù)開發(fā)的一個查詢引擎. 前些年開源. 最近開發(fā)了一些connector , 因此想記錄一下presto plugin 的開發(fā)思路.
一個很奇怪的問題是: Facebook 早就開源了presto, 一直不怎么火. 但我最近開始關注的時候就比較喜歡這貨. 可能是Facebook 大廠員工不怎么運營開源社區(qū)的緣故?
思考
不考慮數(shù)據(jù)寫入, 僅僅看查詢, presto 要做的事情無外乎一件:
function(data)
就是把data 作為輸入, 執(zhí)行function后給出結果. 單機性能無法支撐, 就要考慮如何在分布式的環(huán)境下把function 套在需要的數(shù)據(jù)上.
既然需要把 function apply 到對應的data 上, 需要做的事情有如下幾件:
- metadata: 數(shù)據(jù)存儲在哪里, 數(shù)據(jù)layout
- 處理分塊邏輯: 既然是分布式計算, 需要'平均'分配計算任務.
- 處理讀取數(shù)據(jù)邏輯. 根據(jù)查詢需求, 讀取響應的數(shù)據(jù).
Presto Connector 架構
以上便是Presto 核心與一個Connector 交互的大體示意圖.
-
ConnectorHandlerResolver主要是獲取該connector中一些handler的類型信息 -
ConnectorMetadata主要是維護該catalog下的schema和table信息. 例如, mysql connector中的ConnectorMetadata實現(xiàn)就需要負責讀取該數(shù)據(jù)庫配置下有哪些database和哪些table, 以及每個table中的column信息 -
ConnectorSplitManger: 主要負責根據(jù)查詢條件和數(shù)據(jù)存儲, 將計算分解成多個Split, 交給Coordinator 調(diào)度. 類似MapReduce中計算InputSplit的概念 - Read操作可以選擇實現(xiàn)兩個接口:
ConnectorPageSourceProvider和ConnectorRecordSetProvider. 其實RecordSetProvider是更貼近通常數(shù)據(jù)庫的概念的封裝, 更容易理解, presto 會將RecordSetProvider返回的數(shù)據(jù)再左一層Adapter映射到PageXXX的結構上. 而PageSourceProvider 是更底層. 兩個選擇實現(xiàn)一個就可以 - Write操作同理Read操作, 選擇性實現(xiàn)兩個接口
ConnectorRecordSinkProvider和ConnectorPageSinkProvider中一個接口 -
ConnectorIndexResolver負責根據(jù)查詢判斷是否使用索引. 選擇性實現(xiàn) -
ConnectorAccessControl負責數(shù)據(jù)權限, 可以根據(jù)需求實現(xiàn)權限管理. 選擇性實現(xiàn)
總結
因此, 要開發(fā)一個只讀Presto Connector, 最簡單僅僅需要實現(xiàn)ConnectorHandlerResolver, ConnectorMetadata, ConnectorSplitManager 和ConnectorRecordSetProvider 四個接口然后整合到一個Connector接口的實現(xiàn).
備注: 由于自己開發(fā)的connector開始是基于
0.125版本, 但前幾天升級到0.132后發(fā)現(xiàn)presto代碼經(jīng)歷了重構, 原來com.facebook.presto.spi.Connector已經(jīng)被標記為Deprecated, 新的接口是com.facebook.presto.spi.connector.Connector, 不過大體原理沒有變化, 之前開發(fā)的connector在0.132版本也運行正常.
--EOF--
