有了解過 Kylin 的都知道其主要是在離線方面的處理，在實時方面的處理大家知之甚少，我希望把自己最近學到的分享給大家。
社區其實在 1.6 版本中已經提供了近實時的方案，其存在分鐘級別的準備時間，在對實時要求比較迫切的場景，這種是不能容忍的，於此同時其實現方式是通過每一個批次數據創建一個 segment，一個 segment 對應一個 HBase Table，長期以往會導致大量的 HBase Table 存在和 MR Job 數據。基於以上的原因，Kylin 考慮實時流處理的技術研究與實現。
架構解析
實時流處理主要由 Streaming Receivers、Streaming Coordinator、Query Engine、Build Engine、Metadata Store 構成。
**Streaming Receivers：**用於消費 Kafka topic 中某個 partition 數據，可以由一個或多個 Streaming Receivers 消費同一個 partition，以保證 HA，Streaming Receivers 以集羣的形式存在；
**Streaming Coordinator：**作爲 Streaming Receivers 的協調器。指定 Streaming Receivers 負責消費 topic 數據；
**Query Engine：**數據查詢引擎。提供數據查詢能力。
**Build Engine：**構建引擎。負責將數據提交到歷史數據中。
**Metadata Store：**元數據存儲。存儲一些元數據信息，例如 Receivers 分配信息、高可用信息等。
數據架構
從圖中可以看出，數據從 Kafka 這類消息組件中流入內存中，當數據達到指定閾值或者一個固定時間（默認是一個小時）之後，會將內存數據刷寫到硬盤中，過一段時間後會將磁盤數據，通過 MapReduce 任務，將數據同步到 HBase。
因而，如果要進行數據查詢，需要聚合內存、硬盤和 HBase 三方的數據。
存儲流程
實時數據會消費到 Streaming Receivers，通過 Streaming Coordinator 指定 Receivers 消費與 Cube 相關的 Topic 中 Partition 的數據，Receivers 會做 Base Cuboid 的構建，另外可以支持創建一些常用的 Cuboid，以提高查詢的性能。過一段時間之後，會將數據從本地數據刷寫到 HDFS 上，並通知 Coordinator ，待全部的 Replica Set 把 Cube Segment 的所有實時數據上傳到 HDFS 後，Coordinator 觸發 MapReduce Job 進行一個批量的構建。Job 會從 HDFS 中拉取實時數據進行構建，做一些合併工作並將 Cuboid 同步到 HBase 中，當同步完成之後，Coordinator 會通知實時集羣將相應的數據刪除。
數據查詢
當 QueryServer 接受新查詢後，會請求 Coordinator 查詢的 Cube 是不是實時 Cube，會根據請求是否是實時 Cube 類型，進行分別處理。離線 Cube 會直接查詢 HBase 中數據，實時 Cube 請求若數據不在實時數據中，就發 RPC 請求到 HBase，並且同時發查詢請求到實時集羣，將結果彙總到查詢引擎做一個聚合，再返回給用戶。
無論實時Cube 還是非實時 Cube 請求都會要通過Coordinator，QueryServer 是作爲一個統一的請求入口，之後纔是根據實時和非實時兩種場景進行不同的處理。
實現細節
Fragment File 存儲格式
在上文中已經提到內存數據會刷寫到硬盤中， 而 Fragment File 就是相應持久化的文件模式。
Segmnet Name 由起始時間和結束時間組成。每一次增加 Fragment 文件都會生成一個 Fragment ID，這是一個遞增的值。
Fragment 文件結構是一個列式結構，包括兩個文件，Fragment 的數據文件，和 Metadata 文件。數據文件可以包含多個 Cuboid 的數據，默認只會構建一個 Base cuboid，如果有配置其它 mandatory cuboid 的話，會根據配置生成多個 Cuboid；這裏的數據是多個 Cuboid 依次來保存的，每一個 Cuboid 內是以列式存儲，相同列的數據存在一起。基本上現在的 OLAP 存儲爲了性能通常都是列式存儲。每一個維度的數據包括這三部分：
- 第一部分是 Dictionary，是對維度值做字典的。
- 第二部分是值，經過編碼的。
- 第三部分是倒排索引。
Metadata 文件裏面存有重要的元數據，例如一些 Offset，包含這個維度的數據是從哪個位置開始是這個數據，數據長度是多少，Index，也就是反向索引的長度是多少等等，方便以後查詢的時候比較快的定位到。元數據還包含一些壓縮信息，指定了數據文件是用什麼樣的方法進行壓縮的。
壓縮
- 像時間相關的維度，它們的數據基本上都是類似的，或者是遞增的。還有設計 Cube 的時候也有設計 Row Key，在 Row Key 的順序排在第一位的，使用 run length 壓縮效率會比較高，讀取的時候效率也會比較高。
- 對其他的數據默認都會用 LZ4 的壓縮方式，雖然其它壓縮算法的壓縮率可能比 LZ4 高，但是 LZ4 解壓性能更好，我們選擇 LZ4 是主要從查詢方面去考慮的，所以從其他角度考慮可能會有一些其它結論。
高可用
高可用通過引入 Replica Set 概念來實現。一個 Replica Set 可以包含多個 Receiver，一個 Replica Set 的所有的 Receiver 是共享 Assignment 數據的，Replica Set 下面的 Receiver 消費相同的數據。一個 Replica Set 中存在一個 Leader 做額外的工作，這個工作，是指把這些實時的數據存到 HDFS，Leader 選舉是用 Zookeeper 來做的。以上是實時集羣如何實現 HA 的，可以防止宕掉了對查詢和構建造成影響。
check point
check point 作爲錯誤恢復、保證在服務重啓的時候不會出現數據丟失的情況發生，其主要有兩種方式來保證，一種是Local Check Point，以本地存儲方式，每5分鐘在本地做一個 check point，把消息的信息存到一個文件裏，信息包含消費的 offset 信息，本地磁盤信息，例如最大的 Fragments ID 是多少；重新啓動的時候根據這個去恢復。第二種是 Remote Check Point 方式，把一些消費狀態信息存在 HBase 的 Segment 裏面，保存歷史的 Segment 信息的時候，會把這些消費信息存在 Segment 的元數據裏面，構建這個 Segment 的時候，最早是消費到哪個數據的，信息存在那裏。
小結測試題
1、Kylin 實時流數據涉及哪些位置？
本地內存、HDFS（硬盤）、HBase 三方面。
2、簡要說說 Streaming Coordinator 作用有哪些？
- 協調 Consumers 消費 Partition 數據
- 通知 Build Engine 啓動 MR Job 處理 HDFS 上存儲的實時數據
- 當實時數據存儲到 HBase 之後，通知 Build Engine 刪除 HDFS 上數據
- 查詢的時候，協調不同的查詢類型，進行不同的處理邏輯
3、在進行構建的時候，Cuboid 方面是怎麼處理的？
實時數據默認會被構建成 Base Cuboid，但如果存在其他的 mandatory cuboid，也是支持進行配置。
4、爲什麼使用 LZ4 壓縮格式？
爲了查詢效率比較高，進行了相應的妥協。
5、Fragment File 存有哪些信息？
Cube 名稱、根據時間劃分的 Segmnet Name、主要文件爲 .data 和 .meta ，在data文件中存有倒排索引、經過編碼後的值、字典，meta 文件存有元數據相關信息。
原文地址：https://www.infoq.cn/article/AafpvXOrZcYWUm-kIkVi