關(guān)于名字的來歷

Pinot團(tuán)隊的Team Lead Kishore解釋說：

1均唉，團(tuán)隊的人都喜歡黑皮諾趣避。

2晚顷，黑皮諾是紅葡萄酒中最挑剔和難照料的品種峰伙，但是你可以用它產(chǎn)生最為復(fù)雜的葡萄酒，就像數(shù)據(jù)一樣该默，收集和分析都很困難瞳氓，但是當(dāng)你使得數(shù)據(jù)能夠正確的處理和工作，就能夠產(chǎn)生巨大的用途。

Pinot的Github地址

https://github.com/linkedin/pinot

Pinot特性

1. 一個面向列式存儲的數(shù)據(jù)庫匣摘，支持RunLength Encoding和Fixed Bit Length Encoding的壓縮

2. 可插入的索引技術(shù) – SortedIndex, Bitmap Index, Inverted Index

3. 可以根據(jù)Query和Segment元數(shù)據(jù)進(jìn)行查詢和執(zhí)行計劃的優(yōu)化

4. 從kafka的準(zhǔn)實時數(shù)據(jù)灌入和從hadoop的批量數(shù)據(jù)灌入

5. 類似于SQL的查詢語言店诗，支持在事實表上的selection, aggregation, filtering, group by, order by, distinct

6. 支持多值字段

7. 水平擴(kuò)展和容錯

需要注意的是Pinot適合的是在數(shù)據(jù)不變的append only的大規(guī)模數(shù)據(jù)集上進(jìn)行低延時的分析。

Pinot的幾個重要的概念：

Table– 在Pinot中音榜，table是一組有關(guān)系的數(shù)據(jù)的邏輯抽象庞瘸，它包含行和列。Table的schema定義列名和它的的元數(shù)據(jù)描述赠叼，這個和數(shù)據(jù)庫中的table概念是一樣的擦囊。

Segment– 一個邏輯表(Table)可以分為多個物理單元，叫做Segment嘴办，實際上是數(shù)據(jù)的真實存儲瞬场。

Pinot包含如下的組件：

PinotController– 它管理集群中的節(jié)點，職責(zé)包括：

涧郊。對Table和Segment的創(chuàng)建贯被、更新和刪除操作的處理

。計算Table和Segment在Pinot Server上的分配

PinotServer– 保存一個或者多個物理的Segment妆艘，職責(zé)包括：

彤灶。當(dāng)被分配一個預(yù)先創(chuàng)建的segment,下載并且裝載這個Segment，當(dāng)被分配一個Kafka Topic批旺，從kafka的partion的一個子集中消費數(shù)據(jù)

幌陕。執(zhí)行查詢請求并將結(jié)果返回給PinotBroker

Pinot Broker– 接收客戶端的查詢請求，并且將他們路由到多個服務(wù)上（根據(jù)路由策略）朱沃， 合并接收的查詢結(jié)果并返回給客戶端苞轿。

Pinot的架構(gòu)：

Pinot比較high level的架構(gòu)如下：

看到這個架構(gòu)，不由得不去和另外一個準(zhǔn)實時分布式OLAP系統(tǒng)Druid進(jìn)行對比逗物，下邊是Druid的架構(gòu)：

兩個架構(gòu)非常的相似搬卒，Pinot Controller和Druid的Coordinator Node角色類似。Pinot Broker則和Druid中的Broker Node功能差不多翎卓。而在Pinot和Druid中契邀，都有RealTime Nodes和Historical Nodes，分別處理從消息總線(Kafka)來的準(zhǔn)實時數(shù)據(jù)和存儲歷史的Segment（二者都用Segment這個概念失暴，并且都是按照時間來劃分）坯门。另外二者都支持流式和批量的數(shù)據(jù)裝入《喊牵回到Pinot古戴，歷史數(shù)據(jù)處理數(shù)據(jù)流圖如下：

在HDFS上的文件通過MR任務(wù)將數(shù)據(jù)變成有索引的Segment，然后推送到Pinot的集群的歷史節(jié)點矩肩，去提供Query的能力现恼。有索引的Segment可以配置保留日期，在過期后可以被自動的刪除。對于實時數(shù)據(jù)的裝入叉袍，數(shù)據(jù)流圖如下：

實時數(shù)據(jù)處理是直接消費Kafka的數(shù)據(jù)始锚，然后在內(nèi)存中生成Segment索引，然后定期將數(shù)據(jù)flush到磁盤中喳逛。實時節(jié)點的數(shù)據(jù)的保留日期會相對比較短瞧捌，比如保留3天的數(shù)據(jù)，實時節(jié)點的數(shù)據(jù)在時效前會存儲到歷史節(jié)點中润文。

查詢路由

用戶的所有的查詢會發(fā)送到Pinot Broker姐呐，用戶并不需要關(guān)心查詢是被發(fā)往實時還是歷史節(jié)點。PinotBroker會根據(jù)Query的情況自動的將請求切分然后按照需要發(fā)送給實時節(jié)點和歷史節(jié)點转唉，并且能夠?qū)⒔Y(jié)果進(jìn)行自動的合并皮钠。比如：select count(*) from table where time >T會被分為兩個Query，第一個Query是select count(*) from table where time >T and time from table where time> T1赠法。

第一個Query會被送到歷史節(jié)點執(zhí)行，第二個Query則會被送到實時節(jié)點執(zhí)行乔夯。

Pinot更細(xì)粒度的組件架構(gòu)圖如下：

可以看到砖织，整個系統(tǒng)利用Apache Helix作為集群的管理，還利用了Zookeeper存儲集群的狀態(tài)末荐，同時保存Helix和Pinot的配置侧纯。另外，Pinot利用NFS來將在HDFS上用MR產(chǎn)生的Segment推到PinotServer上甲脏。

對于歷史節(jié)點眶熬，數(shù)據(jù)流程如下圖：

從上圖可以看到，原始的數(shù)據(jù)存儲在HDFS上块请，然后被分成數(shù)據(jù)分片娜氏，分片的大小一般是256M或者512M。Pinot索引創(chuàng)建任務(wù)會對每個分片生成一個mapper任務(wù)去生成新的索引化的Segment墩新。Segment在Hadoop上建立之后贸弥，需要發(fā)送到線上Pinot服務(wù)上去。這個過程是通過Pinot提供的推送任務(wù)來完成的海渊。推送任務(wù)不是hadoop map任務(wù)绵疲，而是一個由Azkaban調(diào)度的java任務(wù)。它從HDFS讀取數(shù)據(jù)臣疑，通過httppost送到Pinot Controller服務(wù)機(jī)器上盔憨。PinotController會將Segment存儲在mount在Pinot Controller機(jī)器上的NFS中。然后Pinot Controller會將Segment分配給一個Pinot Server讯沈，而分配的相關(guān)信息則是由Helix來維護(hù)和管理郁岩。

Helix會監(jiān)控Pinot Server的存活狀態(tài)，當(dāng)一個server啟動時，Helix會通知PinotServer分配給該Server的segment驯用。Pinot Server通過Helix獲取Segment相關(guān)的元數(shù)據(jù)以及下載uri等信息脸秽，然后從Controller Server下載Segment并且裝入到本地的磁盤中。解壓縮的Segment中包含元數(shù)據(jù)以及每列的正排和倒排索引蝴乔。根據(jù)裝載模式（內(nèi)存记餐，mmap）,索引或者被裝載到內(nèi)存中，或者被mmap到服務(wù)器上薇正。Segment裝載過程是由Helix觸發(fā)的離線在線切換片酝，當(dāng)切換完成，Helix會通知Broker節(jié)點改Segment可以在該服務(wù)器被使用挖腰，Broker會在查詢時將查詢路由到該服務(wù)器雕沿。

大部分的Pinot數(shù)據(jù)是按照時間進(jìn)行分區(qū)的，保留時間可以按照用例來配置（天猴仑、月审轮、年粒度）。Pinot控制服務(wù)有一個后臺清理線程去根據(jù)元數(shù)據(jù)刪除過期的Segment辽俗。刪除Segment會清理掉Controller服務(wù)中NFS上的數(shù)據(jù)疾渣，以及Helix服務(wù)上的元數(shù)據(jù)信息，Helix會通知Pinot Server對Segment進(jìn)行在線離線切換崖飘，將Segment變?yōu)殡x線狀態(tài)榴捡，然后變?yōu)閯h除狀態(tài)，從本地磁盤刪掉數(shù)據(jù)朱浴。

對于實時節(jié)點吊圾，數(shù)據(jù)流圖如下：

實時節(jié)點是從Kafka消費數(shù)據(jù)，當(dāng)在Pinot上創(chuàng)建一個resource時翰蠢，Pinot會分配一組實例從Kafka topic消費數(shù)據(jù)项乒。Pinot采用Kafka High Level API消費數(shù)據(jù)從而實現(xiàn)對Kafka數(shù)據(jù)消費的分布性。當(dāng)Pinot消費了預(yù)先配置好數(shù)量的事件后躏筏，會在內(nèi)存中將數(shù)據(jù)轉(zhuǎn)變?yōu)殡x線Segment板丽。當(dāng)Segment創(chuàng)建成功后，Pinot commit offset到Kafka趁尼，如果失敗埃碱，Pinot會從上次的checkpoint重新生成Segment。實時節(jié)點生成的Segment的格式和歷史節(jié)點生成Segment格式相同酥泞，從而方便segment從實時節(jié)點到歷史節(jié)點的重新分發(fā)砚殿。實時節(jié)點的Segment有效期的粒度只有天，而且會比較短芝囤。具體原因是從Kafka消費實時數(shù)據(jù)很難做到在離線節(jié)點相同的優(yōu)化似炎，另外這些Segment可以轉(zhuǎn)到離線節(jié)點進(jìn)行進(jìn)一步的優(yōu)化辛萍。還有就是Kafka很難保證消息只是消費一次，這樣可能會造成數(shù)據(jù)精確性的問題羡藐，這些問題也可以在離線節(jié)點進(jìn)行修復(fù)贩毕。

Pinot集群管理

Pinot是通過通用集群管理軟件Helix進(jìn)行集群管理的。在Helix中仆嗦，節(jié)點被分為三種類型：

1.參與者– 實際提供分布式資源和能力的節(jié)點

2.觀察者– 觀察每個參與者狀態(tài)的節(jié)點辉阶，并且將請求路由給參與者。

3.控制者– 觀察和控制參與者節(jié)點瘩扼，負(fù)責(zé)維護(hù)整個集群的狀態(tài)正常和穩(wěn)定谆甜。

在Pinot當(dāng)中，Pinot Server是Helix中的參與者角色集绰，Pinot Broker是觀察者角色规辱，Pinot Controller則是控制者角色。

Pinot索引Segment

Pinot 索引Segment是將原始的數(shù)據(jù)通過列式進(jìn)行表達(dá)栽燕。原始數(shù)據(jù)一般都是行式表達(dá)的數(shù)據(jù)罕袋，將行式數(shù)據(jù)轉(zhuǎn)化為列式可以減少存儲開銷并且可以提供對列的更快速的訪問。

查詢處理過程

Pinot查詢處理過程如上圖

Pinot支持類似于SQL的PQL碍岔。PQL是SQL的子集炫贤，目前PQL不支持join，嵌套子查詢付秕。Pinot使用Antlr進(jìn)行PQL的Parser，將查詢語句翻譯成一個語法樹侍郭。語法樹會被Logical Planner進(jìn)一步翻譯成邏輯計劃樹询吴。邏輯計劃樹在物理計劃階段會進(jìn)行優(yōu)化，將執(zhí)行計劃按照segment進(jìn)行處理亮元，形成每個Segment的一個物理執(zhí)行計劃猛计。最后，物理執(zhí)行計劃會根據(jù)segment所屬的server爆捞，交給pinotserver進(jìn)行執(zhí)行奉瘤。

Pinot編譯和安裝

Pinot是純粹用Java開發(fā)的，可以直接從git上獲取源代碼進(jìn)行安裝和部署煮甥，假設(shè)你在linux上盗温，需要你先安裝mvn，筆者采用的是最新的mvn 3.3.3成肘，具體下載安裝過程如下：

git clone https://github.com/linkedin/pinot.git

cd pinot

mvn install package ?-Dskip.Tests

需要注意的是卖局，pinot支持的是JDK1.7以上的版本，JDK 1.6在mvn編譯過程中就會發(fā)生錯誤双霍。

如果mvn成功砚偶，則可以

cd pinot-distribution /target/pinot-0.016-pkg

然后執(zhí)行：

bin/quick-start-offline.sh

這樣就可以體驗pinot了批销，pinot會啟動一個web服務(wù)，默認(rèn)監(jiān)聽9000端口染坯。訪問http://{yourhost}:9000/query/index.html,可以進(jìn)入一個交互式查詢的web頁面：

在這里均芽，可以執(zhí)行SQL，執(zhí)行的結(jié)果會以JSON的格式返回单鹿。

總結(jié)

LinkedIn Pinot的出現(xiàn)實際上也代表了當(dāng)前大數(shù)據(jù)分析的潮流掀宋，越來越多的實時分析的要求促進(jìn)了大數(shù)據(jù)技術(shù)的進(jìn)一步發(fā)展。Hadoop MR解決了大數(shù)據(jù)分析從不能到能的問題羞反，但是如果想要更好布朦、更快的進(jìn)行分析，原來Hadoop MR粗獷的數(shù)據(jù)分析模式則不能夠適應(yīng)要求昼窗。各個公司于是都開始探索如何能夠解決實時的OLAP的需求是趴，Druid和Pinot都是為了這個而產(chǎn)生出來的。而這兩個的技術(shù)架構(gòu)很類似澄惊，甚至我們自己在解決問題時用的方法也是類似的唆途。核心點是將數(shù)據(jù)分為實時和歷史兩個部分，實時部分從消息隊列消費數(shù)據(jù)掸驱，數(shù)據(jù)消費時就對數(shù)據(jù)進(jìn)行分區(qū)和索引肛搬，存儲轉(zhuǎn)化為列式存儲從而方便OLAP類型的查詢。由于數(shù)據(jù)的分區(qū)采用的是基于時間的分區(qū)毕贼，在查詢執(zhí)行時温赔，可以方便的路由查詢到實時和歷史節(jié)點，然后將結(jié)果進(jìn)行合并返回鬼癣。兩個產(chǎn)品都不支持Join陶贼，對于OLAP來講，這還是很大的限制待秃。如果想實現(xiàn)join的效果拜秧，則只能構(gòu)造巨大的事實表來解決。

回到當(dāng)前的現(xiàn)狀章郁，如果設(shè)計一個類似的系統(tǒng)枉氮，我想架構(gòu)會是類似的，不過技術(shù)的選擇則更為豐富暖庄。生成Segment采用Spark將會變得更為快捷和方便聊替。而TalkingData采用Bitmap索引來進(jìn)行Segment創(chuàng)建，在多維度交叉上無疑更為快速和方便雄驹。