作者：敏丞
前言
在上篇文章里，我們比較了 Kylin 和 Druid 這兩個重要的 OLAP引擎的特點，也分析了 Kylin on HBase 的不足，得出了使用 Druid 代替 HBase 作為 Kylin 存儲的方案，最后介紹了美團開發(fā)的 Kylin on Druid 的架構(gòu)和流程。在這篇文章中，我們接著上篇文章，將介紹如何使用 Kylin on Druid，Kylin on Druid 的性能表現(xiàn)，以及在使用過程中總結(jié)的一些經(jīng)驗。
如何使用Kylin on Druid
準備階段
準備一個 Druid 集群，并且注意以下幾點：
a) 使用 MySQL 作為元數(shù)據(jù)存儲
b) 使用 HDFS 作為 Deep Storage
c) Druid 版本至少為 0.11
d) 因為數(shù)據(jù)存儲和聚合都在 Historical 執(zhí)行，需要將主要的資源分配給 Historical（Middle Manager 和 Overload 在 KOD 中并不被使用）
從 Kylin 的 Github 倉庫獲取 kylin-on-druid 分支的最新代碼并打包。
修改 kylin.properties，增加配置項。
請參考：
https://github.com/apache/kylin/blob/kylin-on-druid/storage-druid/README.md，以下僅列舉主要配置
a) kylin.storage.druid.coordinator-addresses 指定了 Druid 的 coordinator 節(jié)點地址
b) kylin.storage.druid.broker-host 指定了 Druid 的 Broker 節(jié)點地址
c) kylin.storage.druid.mysql-url 指定了作為 Druid 元數(shù)據(jù)存儲的 MySQL 的 JDBC url
d) kylin.storage.druid.mysql-seg-table 指定了 Druid 元數(shù)據(jù)存儲 segment 信息的 MySQL 表名
e) kylin.storage.druid.hdfs-location 指定了 Druid Segment 文件在 HDFS 的存儲路徑
以下是測試環(huán)境的配置：
圖 1 Kylin 配置文件
按照正常的啟動方式啟動Kylin。
構(gòu)建 Cube 階段
1. 在 Cube Design 界面的第五步（高級設(shè)置）設(shè)置 Cube Engine 和 Cube Storage 分別為 MapReduce 和 Druid。Cube 設(shè)置全部完成后，選擇“ Build Cube ”。
圖 2 高級設(shè)置中的 Cube Storage 選項
2. 觀察 Cube 構(gòu)建過程，等待構(gòu)建完成，以下展示了構(gòu)建 Cube 各個新增步驟的說明和步驟運行成功時的輸出信息：
a) “Calculate Shards Info”根據(jù)配置項，計算出 Druid Segment File 的數(shù)量。
圖 3 Calculate Shards Info
從 Output 看出這里設(shè)置為 2 個 Segment File，每個約 500 MB。
圖 4 Calculate Shards Info 輸出
b) “Update Druid Tier” 更新 Druid Tier 的 Rule
圖 5 Update Druid Tier
圖 6 Update Druid Tier 輸出
c) “Convert Cuboid to Druid” 啟動一個 MapReduce Job，將 Cuboid 文件轉(zhuǎn)為 Druid 的列式存儲格式，生成數(shù)據(jù)放到 HDFS 的指定目錄
圖 7 Convert Cuboid to Druid
MapReduce Job 的統(tǒng)計數(shù)據(jù)
圖 8 Convert Cuboid to Druid 輸出
該步驟結(jié)束時可以檢查到文件已經(jīng)存在于 HDFS 上。
圖 9 Convert Cuboid to Druid 生成文件
d) “Load Segment to Druid” 通過 MySQL 來向 Druid 集群 announce 新的 Druid Segment，等到 Segment 已經(jīng)完全被分發(fā)到各個 Druid Historical 才結(jié)束該 step。
圖 10 Load Segment to Druid
從 Output 看到，首先修改 MySQL 元數(shù)據(jù)信息花費了 0.11 秒，然后等待 Druid 集群將上步生成的兩個 segment 文件 download 到 Historical，這個過程時間約為兩分鐘。
圖 11 Load Segment to Druid 輸出
運行過程中觀察 Coordinator Web UI，可以看到 Data Source 的圖標從紅色變成藍色。
圖 12 Coordinator Web UI
e) Cube 構(gòu)建完成
圖 13 Cube 構(gòu)建完成
f) 檢查 Druid Segment 狀態(tài)和分布，檢查 Schema 是否正確（可選）；通過 Druid API 查看 Cube 對應(yīng)的 Druid Data Source 的元數(shù)據(jù)。
圖 14 Data Source Schema
通過 Druid API 查看 Druid Segments 的明細數(shù)據(jù)。
圖 15 Data Source Data
檢查單個節(jié)點的上已經(jīng)從 Deep Storage 下載下來的 Segment 數(shù)據(jù)文件。
圖 16 Local Cache
Kylin on Druid 的查詢時長對比
我們在測試環(huán)境下基于 SSB 數(shù)據(jù)構(gòu)建不同 Cube，通過比較在不同 Cube 上相同 SQL 的查詢用時，來了解使用 Kylin on Druid 對查詢用時的影響。
我們使用 SSB 生成測試數(shù)據(jù)，數(shù)據(jù)量 29,999,795。
Druid 集群規(guī)格如下：
8 臺虛擬機（8core, 65GB Memory），其中一臺部署 Overlord 和 Coordinator，1 臺部署 Broker，6 臺部署 Middle Manager 和 Historical，其中 Historical 配置參數(shù)如下。
圖 17 Historical JVM 參數(shù)
圖 18 Historical 參數(shù)
以下為三種 Cube 構(gòu)建方案的描述：
Druid Base（綠色列）指的是使用 Druid 作為存儲，只構(gòu)建 Base Cuboid
HBase Base（藍色列）指的是使用 HBase 作為存儲，只構(gòu)建 Base Cuboid
HBase Default（紅色列）指的是使用 kylin-ssb 默認的 cube 元數(shù)據(jù)的構(gòu)建方案
下圖為三種方案構(gòu)建的 Cube 在不同查詢語句下的平均查詢用時對比
圖 19 SSB 查詢時長
圖 20 SSB 查詢時長-折線圖
結(jié)論
關(guān)于構(gòu)建 Cube 時間和 MapReduce 內(nèi)存，使用 Druid 占用資源略多。基于 Druid 只構(gòu)建 base cuboid 得到的 Cube，與基于 HBase 根據(jù)復(fù)雜剪枝設(shè)置得到的 Cube 有了相當?shù)牟樵冃阅堋？梢?b>利用 Druid 高效的 filter 和 scan，Kylin 的現(xiàn)場計算能力有了十分明顯的提升。而如果 Cube 設(shè)計得當，且計算較多 Cuboid 的話，HBase 的性能跟 Druid 不分伯仲。
美團 Kylin on Druid 的線上環(huán)境表現(xiàn)
美團點評是 Apache Kylin 的重度用戶，Kylin 覆蓋了美團點評主要業(yè)務(wù)線，截止 2018 年 8 月的數(shù)字，每天的查詢次數(shù)超過 380 萬次。美團第一批上線使用 Kylin on Druid 后，Cube 存儲使用減少了約 79%，構(gòu)建過程的內(nèi)存和 CPU 使用減少了 20% 左右；從查詢時長觀察，大部分的查詢用時減少了 50% 以上（圖21來自于 Kylin 北京 Meetup 上康凱森的分享內(nèi)容）。
圖 21 Kylin Meetup PPT
Kylin on Druid 的總結(jié)
目前 Kylin on Druid 的限制和要求
要求 Druid 使用 MySQL 作為元數(shù)據(jù)存儲，使用 HDFS 作為分布式存儲
Druid 需要 0.11 版本或者以上，Java 需要 JDK8 或者以上
Cube 構(gòu)建目前只支持 MapReduce
Cuboid 數(shù)量相同時，Kylin on Druid 較使用 HBase 構(gòu)建 Cube 而言，時間和計算資源使用一般稍多
Measure 尚不能完全支持，美團近期即將開源的包括 EXTENDED_COLUMN、Count Distinct(BitSet)，這些 Measure 需要以向 Druid 添加擴展的方式支持；Count Distinct(HyperLogLog) 后續(xù)根據(jù)需求開發(fā)
Decimal 類型在 Druid 端使用 double 替換，美團近期也會提供準確的 Decimal 類型支持
轉(zhuǎn)換為 Druid Segment 步驟使用內(nèi)存比轉(zhuǎn)HFile更多，一般需要分配更多內(nèi)存
Kylin on Druid 的優(yōu)勢
1. 查詢時無需加載字典，因此相比 Kylin on HBase 查詢穩(wěn)定性更高
2. 存儲層支持業(yè)務(wù)隔離
3. 億級及以下數(shù)據(jù)只需構(gòu)建 Base Cuboid
4. 構(gòu)建資源使用減少（因為需要構(gòu)建的 Cuboid 數(shù)量減少了），查詢時長減少（因為現(xiàn)場計算能力有了比較好的提升）
何時使用Kylin on Druid
1. 對 Druid 有充分的理解，有足夠的經(jīng)驗去部署和運維 Druid 集群
2. 有足夠的機器資源部署Druid
3. 查詢沒有較為固定的模式，因此大部分查詢難以精確匹配Cube預(yù)計算得到的維度組合，可以利用Kylin on Druid來加速現(xiàn)場計算能力
4. 對查詢響應(yīng)速度有較高的要求
總結(jié)
在這兩篇文章中，我們一步一步分析 Kylin 目前使用 HBase 作為存儲的不足之處，同時比較了 Kylin 和 Druid 各自的特點，得出了將兩者相結(jié)合的 Kylin on Druid 的方案。
隨后介紹了美團開發(fā)的 KOD 使用方式，通過不同 Cube 構(gòu)建方案的查詢時長對比，得出 KOD 較原有 HBase 存儲有較大性能和易用性提升的結(jié)論。最后總結(jié)了 KOD 的優(yōu)勢和使用經(jīng)驗，也了解到 KOD 目前有部分功能尚未完成。
目前這部分代碼在 Kylin 的 Git 倉庫的“ kylin-on-druid ”分支，歡迎廣大開發(fā)者試用并積極參與開發(fā)和改進，更多問題可以發(fā)送到 Kylin 開發(fā)者郵件群組 dev@kylin.apache.org 進行討論，謝謝大家。
參考鏈接
https://issues.apache.org/jira/projects/KYLIN/issues/KYLIN-3694
https://github.com/apache/kylin/tree/kylin-on-druid
