Pinot是一個(gè)每秒可以處理數(shù)以萬計(jì)分析類查詢的系統(tǒng)，支持近實(shí)時(shí)地從流式數(shù)據(jù)源進(jìn)行數(shù)據(jù)攝取。簡單來說作為一個(gè)分析類系統(tǒng)：數(shù)據(jù)進(jìn)得快、查詢返回快。
為了達(dá)到數(shù)據(jù)消費(fèi)的實(shí)時(shí)性，Pinot采取了Lambda的架構(gòu)，Pinot把它叫做"Hybid table", 一份數(shù)據(jù)同時(shí)存在實(shí)時(shí)和離線兩部分，用戶將查詢的時(shí)候，Pinot同時(shí)查離線和實(shí)時(shí)的數(shù)據(jù)，然后把merge的結(jié)果返回給用戶，關(guān)于這種Lambda架構(gòu)的特點(diǎn)，后面還會(huì)詳細(xì)討論一下。
Pinot里面數(shù)據(jù)也是按照傳統(tǒng)的數(shù)據(jù)庫、表的形式來組織的。在物理上 Pinot 的表是被切分成一個(gè)個(gè) Segments，而這些Segments會(huì)被復(fù)制多份保存，以保證數(shù)據(jù)可用性。Segment數(shù)據(jù)是不可變的, 要插入新數(shù)據(jù)，或者對(duì)數(shù)據(jù)進(jìn)行更新是通過替換整個(gè)segment來完成。(Segment的內(nèi)容是不可變的，但是Segment整個(gè)是可以被替換掉的)。Segment里面的數(shù)據(jù)是按照列來存的，這算是分析性數(shù)據(jù)庫的標(biāo)配了，主要為了查詢的時(shí)候可以掃描最少的數(shù)據(jù)，達(dá)到更大的存儲(chǔ)壓縮比等等。
Pinot的查詢語言是標(biāo)準(zhǔn)SQL的一個(gè)子集：PQL，不支持JOIN，不支持嵌套子查詢，不支持DDL(表結(jié)構(gòu)是通過souce control工具來維護(hù)的，感覺在他們內(nèi)部可能是需要通過提申請(qǐng)才能添加新表的)，而且不支持任何單條記錄級(jí)別的創(chuàng)建、更新、刪除操作等等。
限制太多了啊，在目前這個(gè)時(shí)間點(diǎn)看來，感覺有點(diǎn)弱啊。
跟Storm設(shè)計(jì)思想類似的是，Pinot也是一個(gè)Share Nothing的架構(gòu)，所有的組件都是無狀態(tài)的，任何節(jié)點(diǎn)隨時(shí)都可以被停掉，然后再另外一臺(tái)機(jī)器起另外一個(gè)實(shí)例代替。
Lambda架構(gòu)
上面提到Pinot采用了Lambda架構(gòu)以達(dá)到數(shù)據(jù)已最快的速度可以被用戶查詢到的目的。Lambda架構(gòu)這個(gè)概念是Storm的作者Nathan Marz提出來的，它主要的目的在于讓我們可以既能及時(shí)的獲取到最新的數(shù)據(jù)(通過流計(jì)算引擎), 同時(shí)又要保證數(shù)據(jù)的準(zhǔn)確性(通過離線計(jì)算引擎)。典型的 Lambda 架構(gòu)如下圖:
每次查詢過來會(huì)分別取查詢離線和實(shí)時(shí)的數(shù)據(jù)、在合并之后返回給用戶。
但是從目前的大數(shù)據(jù)領(lǐng)域來看，Lambda架構(gòu)并不是一個(gè)特別好的方式，原因就在于它的復(fù)雜性，對(duì)于同一份數(shù)據(jù)，要同時(shí)維護(hù)離線和實(shí)時(shí)兩套代碼，而這兩套在模型上不完全一樣，但是要強(qiáng)行糅合到一起進(jìn)行配合，Pinot特性上的一些限制，比如不支持join，不支持嵌套查詢，我懷疑跟這種復(fù)雜架構(gòu)是有關(guān)系的。而且要使用好這一套架構(gòu)需要你同時(shí)對(duì)離線和實(shí)時(shí)計(jì)算引擎都非常精通，以便進(jìn)行性能調(diào)優(yōu)，問題排查。LinkedIn的Jay Kreps這段評(píng)價(jià)我深以為然:
The API meant to hide the underlying frameworks proved to be the leakiest of abstractions.
-- Jay Kreps (LinkedIn Principal Staff Engineer)
Lambda架構(gòu)(包括我們的主角Pinot)嘗試要解決的一個(gè)問題就是要通過一個(gè)系統(tǒng)把離線和實(shí)時(shí)的底層框架糅合在一起了，我感覺這個(gè)事情太難了。現(xiàn)在比較流行的，看起來應(yīng)該也是未來發(fā)展方向的是一種叫做Kappa的架構(gòu), 這種架構(gòu)認(rèn)為Lambda架構(gòu)之所以出現(xiàn)是因?yàn)樗_實(shí)解決了數(shù)據(jù)實(shí)時(shí)性 + 準(zhǔn)確性的需求，其根本原因還是在于實(shí)時(shí)計(jì)算引擎的能力問題，只要實(shí)時(shí)計(jì)算能夠:
- 有辦法以流計(jì)算引擎可讀的形式保存大量的歷史數(shù)據(jù)。
- 非常快的處理歷史數(shù)據(jù)。
- 可以非常精準(zhǔn)的處理數(shù)據(jù)。
那么完全可以把離線計(jì)算引擎那條路去掉，整個(gè)架構(gòu)就大為簡化:
而目前在Kafka, Flink等等先進(jìn)的流計(jì)算/存儲(chǔ)框架出現(xiàn)的情況下，感覺時(shí)機(jī)已經(jīng)成熟了。我覺得這個(gè)應(yīng)該是未來，因?yàn)橐皇呛唵危菍?shí)時(shí)是未來，計(jì)算引擎的方向應(yīng)該也是實(shí)時(shí)。
多租戶
正如論文里面所說，在一個(gè)大公司里面，為不同的業(yè)務(wù)、不同的場(chǎng)景搭建單獨(dú)的集群肯定是有問題的，原因有很多，一是會(huì)造成資源浪費(fèi)：不同的業(yè)務(wù)使用會(huì)有波峰波谷，搭建單獨(dú)集群使得不同集群之間資源無法在業(yè)務(wù)波谷的時(shí)候給別的業(yè)務(wù)使用。但是也不能什么措施也不做，直接混用一個(gè)集群，這會(huì)使得一個(gè)業(yè)務(wù)的過分使用導(dǎo)致其他業(yè)務(wù)得不到資源。因此多租戶是個(gè)必須要做的事情。
Pinot里面多租戶的實(shí)現(xiàn)手段非常的簡單，它給每個(gè)業(yè)務(wù)發(fā)放一些token，這些token會(huì)隨著時(shí)間的推移以一定的速度不停的發(fā)放，但是達(dá)到指定的最大值之后不再增長。每當(dāng)一個(gè)查詢過來，就從這個(gè)token池子里面消耗一些token，當(dāng)token被消耗完之后，再來新的查詢就要等待了，等待產(chǎn)生足夠的token之后再繼續(xù)執(zhí)行。
這個(gè)方法的特點(diǎn)是特別的簡單易懂，看上去很漂亮。后面要看看其它系統(tǒng)是怎么做的，有沒有更精細(xì)的做法。
Pinot VS Others
說實(shí)話從這個(gè)對(duì)比來看，Pinot對(duì)我的吸引力很小，首先我最看重的 Query Flexibility, 從前面我們知道Pinot查詢能力方面很受限制，JOIN都不支持，感覺用戶壓根就沒法用。而 "Fast ingest and indexing" 目前通過Lambda架構(gòu)首先的思路不是很好，維護(hù)的難度，運(yùn)維的復(fù)雜性都很高，如果只考慮通過Kafka接進(jìn)行寫入的思路，而把流計(jì)算那部分去掉的話倒是一個(gè)解決數(shù)據(jù)實(shí)時(shí)性的不錯(cuò)思路。
另外Pinot這里提到了一個(gè)"Offline OLAP"的概念，這里它指的是類似Hive, Impala, Presto這類引擎，之所以說作者把他們成為offline，我理解可能還是數(shù)據(jù)實(shí)時(shí)性的問題，這類系統(tǒng)接的基本都是分布式文件系統(tǒng)，數(shù)據(jù)一般都是 T - 1 的。
總結(jié)
從這篇論文里面我個(gè)人最大的收獲是兩個(gè)，一是學(xué)習(xí)了這種多租戶資源隔離的技術(shù)，非常簡單，非常優(yōu)雅，為后續(xù)讀其他論文找到了一個(gè)新的方向；另外一個(gè)是重溫了Lambda架構(gòu)，Lambda架構(gòu)本身是有它的歷史和現(xiàn)實(shí)意義的，但是由于他的復(fù)雜性，終究不會(huì)成為一種主流的架構(gòu)方式。
