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