Pinot是一個每秒可以處理數(shù)以萬計分析類查詢的系統(tǒng)横殴，支持近實時地從流式數(shù)據(jù)源進行數(shù)據(jù)攝取萝快。簡單來說作為一個分析類系統(tǒng)：數(shù)據(jù)進得快、查詢返回快蚜厉。
為了達到數(shù)據(jù)消費的實時性，Pinot采取了Lambda的架構畜眨，Pinot把它叫做"Hybid table", 一份數(shù)據(jù)同時存在實時和離線兩部分昼牛，用戶將查詢的時候，Pinot同時查離線和實時的數(shù)據(jù)胶果，然后把merge的結(jié)果返回給用戶匾嘱，關于這種Lambda架構的特點，后面還會詳細討論一下早抠。
Pinot里面數(shù)據(jù)也是按照傳統(tǒng)的數(shù)據(jù)庫霎烙、表的形式來組織的。在物理上 Pinot 的表是被切分成一個個 Segments蕊连，而這些Segments會被復制多份保存悬垃，以保證數(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é)構是通過souce control工具來維護的，感覺在他們內(nèi)部可能是需要通過提申請才能添加新表的)谓松，而且不支持任何單條記錄級別的創(chuàng)建星压、更新践剂、刪除操作等等。
限制太多了啊娜膘，在目前這個時間點看來逊脯，感覺有點弱啊。
跟Storm設計思想類似的是劲绪，Pinot也是一個Share Nothing的架構男窟，所有的組件都是無狀態(tài)的，任何節(jié)點隨時都可以被停掉贾富，然后再另外一臺機器起另外一個實例代替歉眷。
Lambda架構
上面提到Pinot采用了Lambda架構以達到數(shù)據(jù)已最快的速度可以被用戶查詢到的目的。Lambda架構這個概念是Storm的作者Nathan Marz提出來的颤枪，它主要的目的在于讓我們可以既能及時的獲取到最新的數(shù)據(jù)(通過流計算引擎), 同時又要保證數(shù)據(jù)的準確性(通過離線計算引擎)汗捡。典型的 Lambda 架構如下圖:
每次查詢過來會分別取查詢離線和實時的數(shù)據(jù)、在合并之后返回給用戶畏纲。
但是從目前的大數(shù)據(jù)領域來看扇住，Lambda架構并不是一個特別好的方式，原因就在于它的復雜性盗胀，對于同一份數(shù)據(jù)艘蹋，要同時維護離線和實時兩套代碼，而這兩套在模型上不完全一樣票灰，但是要強行糅合到一起進行配合女阀，Pinot特性上的一些限制，比如不支持join屑迂，不支持嵌套查詢浸策，我懷疑跟這種復雜架構是有關系的。而且要使用好這一套架構需要你同時對離線和實時計算引擎都非常精通惹盼，以便進行性能調(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架構(包括我們的主角Pinot)嘗試要解決的一個問題就是要通過一個系統(tǒng)把離線和實時的底層框架糅合在一起了手报，我感覺這個事情太難了◎遣眨現(xiàn)在比較流行的，看起來應該也是未來發(fā)展方向的是一種叫做Kappa的架構, 這種架構認為Lambda架構之所以出現(xiàn)是因為它確實解決了數(shù)據(jù)實時性 + 準確性的需求掩蛤，其根本原因還是在于實時計算引擎的能力問題晓淀，只要實時計算能夠:
- 有辦法以流計算引擎可讀的形式保存大量的歷史數(shù)據(jù)。
- 非痴档担快的處理歷史數(shù)據(jù)。
- 可以非常精準的處理數(shù)據(jù)燥爷。
那么完全可以把離線計算引擎那條路去掉蜈亩，整個架構就大為簡化:
而目前在Kafka, Flink等等先進的流計算/存儲框架出現(xiàn)的情況下懦窘，感覺時機已經(jīng)成熟了。我覺得這個應該是未來稚配，因為一是簡單畅涂，二是實時是未來，計算引擎的方向應該也是實時道川。
多租戶
正如論文里面所說午衰，在一個大公司里面，為不同的業(yè)務冒萄、不同的場景搭建單獨的集群肯定是有問題的臊岸，原因有很多，一是會造成資源浪費：不同的業(yè)務使用會有波峰波谷尊流，搭建單獨集群使得不同集群之間資源無法在業(yè)務波谷的時候給別的業(yè)務使用帅戒。但是也不能什么措施也不做，直接混用一個集群崖技，這會使得一個業(yè)務的過分使用導致其他業(yè)務得不到資源逻住。因此多租戶是個必須要做的事情。
Pinot里面多租戶的實現(xiàn)手段非常的簡單迎献，它給每個業(yè)務發(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架構首先的思路不是很好拓提，維護的難度读恃，運維的復雜性都很高，如果只考慮通過Kafka接進行寫入的思路，而把流計算那部分去掉的話倒是一個解決數(shù)據(jù)實時性的不錯思路寺惫。
另外Pinot這里提到了一個"Offline OLAP"的概念疹吃，這里它指的是類似Hive, Impala, Presto這類引擎，之所以說作者把他們成為offline西雀，我理解可能還是數(shù)據(jù)實時性的問題萨驶，這類系統(tǒng)接的基本都是分布式文件系統(tǒng)，數(shù)據(jù)一般都是 T - 1 的艇肴。
總結(jié)
從這篇論文里面我個人最大的收獲是兩個腔呜，一是學習了這種多租戶資源隔離的技術，非常簡單再悼，非常優(yōu)雅核畴，為后續(xù)讀其他論文找到了一個新的方向；另外一個是重溫了Lambda架構帮哈，Lambda架構本身是有它的歷史和現(xiàn)實意義的膛檀，但是由于他的復雜性，終究不會成為一種主流的架構方式娘侍。
