最近 Presto 社區(qū)在它的發(fā)源地 Facebook 公司舉行了它歷史上的第一次 Summit, 目前 PPT 已經(jīng)都放出來(lái)了藐翎，看了一遍，還是有不少收獲的且轨，這里介紹一下 Facebook枫耳、Starburst老客、LinkedIn以及Lyft 這幾個(gè)公司分享的內(nèi)容。
Facebook 的 Martin 分享了一下 Presto 這個(gè)項(xiàng)目目前的狀態(tài)茵臭。 從 2012年8月8日 Martin 同學(xué)寫(xiě)下第一行代碼算起疫诽，Presto 已經(jīng)有6年歷史了，目前在 Facebook 部署了 1000 多個(gè)節(jié)點(diǎn)笼恰，每天要處理 100 多 PB的數(shù)據(jù)踊沸，70%以上的新數(shù)倉(cāng)負(fù)載都是由 Presto 來(lái)承載的。
項(xiàng)目方面這一年的進(jìn)展很大社证，總的 Contributor 數(shù)是330個(gè)逼龟。安全性方面支持了客戶端證書(shū)、密碼以及JSON Web Token的認(rèn)證追葡；支持節(jié)點(diǎn)之間的數(shù)據(jù)加密腺律；支持行級(jí)別的權(quán)限控制。查詢執(zhí)行方面支持分區(qū)化的查詢執(zhí)行(Partitioned query Execution)以及分布式排序宜肉。SQL語(yǔ)法方面比較大的改進(jìn)是支持了新的 Geospatial 函數(shù)和Lateral JOIN匀钧。
將來(lái)的計(jì)劃是要支持更大的集群：超過(guò)1000個(gè)節(jié)點(diǎn)；支持故障恢復(fù)谬返；自動(dòng)處理數(shù)據(jù)傾斜之斯；工作負(fù)載重新平衡化；支持臨時(shí)表遣铝；多階段查詢執(zhí)行佑刷；語(yǔ)言方面支持UDF；支持SQL 2016的特性酿炸，比如 Row Matching 等等瘫絮。
Starburst
Starburst 的PPT是所有PPT里面最具商務(wù)氣息的，這跟它們公司成立不久填硕，需要更多的曝光度有關(guān)麦萤，它們整個(gè) PPT 的前半部分都在介紹 Starburst 這個(gè)公司。他們提的一點(diǎn)蠻有意思扁眯，說(shuō)他們公司是一個(gè)沒(méi)有風(fēng)投壮莹，員工做主，能盈利的公司恋拍，在這個(gè)風(fēng)投遍地的時(shí)代還是有點(diǎn)另類(lèi)的垛孔。他們的主要優(yōu)勢(shì)是:
- 公司是由 Presto 的 Commiter 組成的，真正的意思上的一個(gè)技術(shù)型公司施敢。
- 他們對(duì) Presto 已經(jīng)有了3年多的貢獻(xiàn)歷史周荐。
- 他們支持了大型的企業(yè)用戶狭莱。
- 他們貢獻(xiàn)了一些很關(guān)鍵的特性，比如“spill to disk”, CBO優(yōu)化器等等概作。
真正的技術(shù)分享篇幅倒是很短腋妙，簡(jiǎn)單介紹了一下最近開(kāi)發(fā)的關(guān)鍵特性: Cost-Base Optimizer, 主要是因?yàn)镃BO本身在數(shù)據(jù)處理領(lǐng)域不是一個(gè)新概念，而且他們之前也有專(zhuān)門(mén)文章介紹過(guò)讯榕，感興趣的可以看下他們之前的博客: Introduction to Presto Cost-Based Optimizer骤素。
Linkedin 介紹的角度是作為一個(gè)新使用 Presto 的公司，如何解決碰到的各種問(wèn)題愚屁。對(duì)于想要采用 Presto 的公司比較有參考意義济竹。
剛開(kāi)始的時(shí)候 Linkedin 的數(shù)據(jù)都是以 Hadoop 為中心來(lái)組織的，為了使用 Presto 霎槐， 部署了單獨(dú)的 Presto 集群送浊，為了能夠把數(shù)據(jù)灌到這個(gè)集群里面去，需要做一些數(shù)據(jù)集成的事情丘跌，比如數(shù)據(jù)復(fù)制袭景。LinkedIn 是采用 Apache Gobblin 來(lái)簡(jiǎn)化這些問(wèn)題。Gobblin 是一個(gè)分布式的數(shù)據(jù)集成框架闭树，它能簡(jiǎn)化關(guān)于數(shù)據(jù)集成的方方面面耸棒，比如數(shù)據(jù)攝取，數(shù)據(jù)復(fù)制报辱，數(shù)據(jù)組織与殃，以及生命周期管理，比較牛的地方是它不止支持離線數(shù)據(jù)碍现，還支持實(shí)時(shí)數(shù)據(jù)奈籽。
引入一個(gè)新的框架之后，很關(guān)鍵的一點(diǎn)是要看看用戶對(duì)這個(gè)新的框架的感受如何鸵赫，在這一點(diǎn)上面他們利用了 Presto 的 EventListener 機(jī)制記錄下了用戶使用過(guò)程中的各種元數(shù)據(jù)，比如多少用戶在用躏升，哪些查詢耗費(fèi)了大量的資源辩棒，數(shù)據(jù)的血緣關(guān)系是什么樣的，用戶使用數(shù)據(jù)的時(shí)候碰到了什么問(wèn)題等等膨疏。
public interface EventListener {
void queryCreated(QueryCreatedEvent queryCreatedEvent);
void queryCompleted(QueryCompletedEvent queryCompletedEvent);
void splitCompleted(SplitCompletedEvent splitCompletedEvent);
}
通過(guò)這個(gè)接口把數(shù)據(jù)灌進(jìn) Kafka 一睁，之后再把數(shù)據(jù)倒回 Presto 進(jìn)行分析，也算是 Dog eat dog‘s food 了佃却。
在最初驗(yàn)證完概念之后者吁，如何進(jìn)一步推進(jìn) Presto 的使用? 要把數(shù)據(jù)全部都導(dǎo)入 Presto 是不現(xiàn)實(shí)的，因?yàn)闆](méi)有人愿意花那么大代價(jià)把數(shù)據(jù)從 Hadoop 搬到 Presto 上面來(lái)饲帅；同時(shí)也要考慮怎么讓這個(gè) Presto 的新框架能夠與公司內(nèi)部老的工具很好的集成复凳；而且公司內(nèi)的數(shù)據(jù)除了 Hadoop, Presto上的瘤泪，還有各種其他的數(shù)據(jù)源，比如 JDBC, Kafaka, Elasticsearch 等等育八。他們做了一個(gè) Federation Connector对途，充當(dāng)數(shù)據(jù) Connector 的門(mén)面，查詢進(jìn)來(lái)之后髓棋，這個(gè) Federation Connector 會(huì)根據(jù)實(shí)際的數(shù)據(jù)類(lèi)型對(duì)數(shù)據(jù)進(jìn)行路由实檀。
LinkedIn 還開(kāi)發(fā)了一個(gè)叫做 Dali View 的東西， 這個(gè) Dali View 就像數(shù)據(jù)庫(kù)里面的視圖一樣按声，通過(guò)在數(shù)據(jù)之上封裝一層膳犹，讓整個(gè)公司里面所有的數(shù)據(jù)看起來(lái)像是在一個(gè)同構(gòu)的數(shù)據(jù)庫(kù)里面一樣。用戶可以通過(guò)各種客戶端來(lái)對(duì)這些數(shù)據(jù)進(jìn)行查詢签则。如果訪問(wèn)到的是一個(gè) Presto 的表须床，那么直接路由到底層的 Presto，如果是一個(gè) Hive View怀愧，那么先把請(qǐng)求轉(zhuǎn)給 Hive 的 Analyzer侨颈，再通過(guò) Calcite 生成 Presto 的 SQL，再丟給 Presto 去執(zhí)行芯义，這樣可以把所有的計(jì)算收到 Presto 這一個(gè)地方哈垢，運(yùn)維團(tuán)隊(duì)幾種精力優(yōu)化 Presto 這一個(gè)系統(tǒng)就好了。
統(tǒng)一了 SQL 查詢之后扛拨，LinkedIn 還對(duì) UDF 進(jìn)行了統(tǒng)一耘分，因?yàn)槊總€(gè)平臺(tái)都有自己的 UDF API，他們搞了一個(gè)通用的抽象绑警，使得用戶只要寫(xiě)一份 UDF求泰，就可以在各個(gè)平臺(tái)上運(yùn)行。
Lyft
最后一個(gè)想聊一下的是 Lyft计盒，他們的 PPT 是最長(zhǎng)的渴频，其它人 PPT 只有20來(lái)頁(yè)，而他們的 PPT 是70多頁(yè)(其實(shí)很多是PPT是為了頁(yè)面過(guò)度效果)北启。Lyft 的數(shù)倉(cāng)在 2013 年的時(shí)候是完全基于 Redshift的卜朗，到了2018年 Redshift(以及Hive) 只管批量計(jì)算，而用戶的交互式查詢完全交給了 Presto 和 Druid咕村。他們的數(shù)據(jù)量級(jí)在 10 PB以上场钉，保存在S3上面，使用的 Parquet 格式懈涛，通過(guò)日期對(duì)數(shù)據(jù)進(jìn)行分區(qū)逛万，表的總數(shù)在50000以上。
他們使用 Presto 主要還是用來(lái)交互式的數(shù)據(jù)查詢以及每天定時(shí)的報(bào)表生成批钠，不進(jìn)行數(shù)據(jù)清洗宇植，使用高峰時(shí)間是在白天上班時(shí)間得封。
他們開(kāi)發(fā)的一個(gè)比較有意思的特性是 Presto Gateway，這個(gè) Gateway 的來(lái)由是這樣的：上面提到過(guò)当纱，在 Lyft 用戶對(duì) Presto 的使用模式分兩種: 交互式查詢以及定時(shí)報(bào)表生成呛每，這兩種使用模式對(duì)于服務(wù)響應(yīng)速度的需求是不一樣的，為了他們不要相互影響而把 Presto 分成了多個(gè)集群坡氯，但是他們不想讓用戶知道這種底層細(xì)節(jié)晨横。因此他們開(kāi)發(fā)了一個(gè) Gateway，所有的請(qǐng)求都提交到這個(gè) Gateway箫柳，然后這個(gè) Gateway 會(huì)根據(jù)一些路由規(guī)則把請(qǐng)求自動(dòng)路由到正確的集群手形。
這個(gè)架構(gòu)圖畫(huà)的確實(shí)有點(diǎn)樸素...
他們還做了一個(gè)很有意思的查詢保護(hù)機(jī)制，保護(hù)整個(gè)集群不至于被某些慢查詢拖垮悯恍，這里使用的也是 Presto 的插件機(jī)制库糠，對(duì)用戶的查詢進(jìn)行分析，分析完成之后應(yīng)用一些預(yù)先定義的規(guī)則對(duì)查詢進(jìn)行阻止涮毫，比如查表的時(shí)候不帶分區(qū)瞬欧，一些預(yù)先知道的很差的Query。
總結(jié)
Presto 界目前有兩大玩家: Facebook 和 Starburst罢防，F(xiàn)acebook 是 Presto 的締造者艘虎，地位自不用說(shuō)；Starburst 則是由 Presto 的一些 Committer 組建的一個(gè)公司咒吐，目前在 Presto 商業(yè)版本的一些事情, 一些很關(guān)鍵的特性比如 Presto 的 Cost Base Optimizer 就是由他們貢獻(xiàn)的野建。其實(shí)阿里在 Presto 上面也有很大的研發(fā)投入，只是我們?cè)陂_(kāi)源方面發(fā)聲不多恬叹，有點(diǎn)可惜候生。
Presto 雖然已經(jīng)有了6年的歷史，但是社區(qū)還不是很大绽昼，Summit 也是才開(kāi)第一次唯鸭。但是這種網(wǎng)絡(luò)帶寬越來(lái)越大，計(jì)算跟存儲(chǔ)逐漸分離硅确，這種可以對(duì)各種不同格式的肿孵、保存在各種不同存儲(chǔ)里面的數(shù)據(jù)進(jìn)行分析的計(jì)算引擎應(yīng)該會(huì)越來(lái)越受歡迎。
