作者：敏丞

在大數(shù)據(jù)分析領(lǐng)域，Apache Kylin 和 Apache Druid （incubating） 是兩個普遍使用的 OLAP 引擎铡原，都具有支持在超大數(shù)據(jù)上進行快速查詢的能力偷厦。在一些對大數(shù)據(jù)分析非常依賴的企業(yè)，往往同時運行著 Kylin 和 Druid 兩套系統(tǒng)燕刻，服務(wù)于不同的業(yè)務(wù)場景沪哺。

在2018年8月的Apache Kylin Meetup 活動上，美團點評技術(shù)團隊分享了他們的 Kylin On Druid 方案（簡稱 KOD）酌儒。那么，美團點評為什么要開發(fā)這樣一套混合系統(tǒng)枯途？這背后是有什么挑戰(zhàn)和考慮呢忌怎？本文將圍繞這些問題跟大家做探討籍滴，幫助讀者理解兩個OLAP 引擎之間的差異和各自優(yōu)勢。

Apache Kylin 簡介

Apache Kylin 是一個開源的分布式大數(shù)據(jù)分析引擎榴啸，在超大規(guī)模數(shù)據(jù)集上建立數(shù)據(jù)模型孽惰，構(gòu)建支持多維分析的預(yù)計算Cube，提供Hadoop 上的SQL 查詢接口及多維分析能力鸥印。并開放通用的ODBC勋功、JDBC 或Restful API 接口。這種獨特的預(yù)計算能力使Apache Kylin 可以應(yīng)對超大數(shù)據(jù)集上的查詢库说，并實現(xiàn)亞秒級查詢響應(yīng)狂鞋。

圖1 Kylin架構(gòu)圖

Apache Kylin 的優(yōu)勢

基于 Hadoop 成熟的計算引擎（MapReduce 和 Spark），提供了強大的處理超大數(shù)據(jù)集的預(yù)計算能力潜的，能夠在主流Hadoop 平臺上開箱即用骚揍。

支持 ANSI SQL，用戶可以使用 SQL 進行數(shù)據(jù)分析啰挪。

亞秒級低延遲響應(yīng)信不。

提供 OLAP 通用的星型模型和雪花模型等數(shù)據(jù)建模方式。

提供豐富的度量（Sum亡呵，Count Distinct抽活、Top N、Percentile 等）锰什。

提供智能的 Cuboid 剪枝能力下硕，減少存儲和計算資源的消耗。

支持直接跟主流 BI 工具的集成歇由，有豐富的接口卵牍。

既支持超大歷史數(shù)據(jù)的批量導(dǎo)入，也支持流數(shù)據(jù)的微批次導(dǎo)入沦泌。

Apache Druid ( incubating )簡介

Druid 誕生于 2012 年糊昙，是一個開源分布式數(shù)據(jù)存儲，其核心設(shè)計結(jié)合了分析型數(shù)據(jù)庫谢谦、時序數(shù)據(jù)庫释牺、搜索系統(tǒng)的特點，可以處理較大數(shù)據(jù)集上的數(shù)據(jù)收集和分析任務(wù)回挽。Druid 使用 Apache v2許可没咙，目前是 Apache 基金會孵化項目。

Druid 架構(gòu)

從 Druid 的部署架構(gòu)上看千劈，Druid 的進程根據(jù)角色主要分為以下三類：

Data Node（Slave 節(jié)點祭刚，數(shù)據(jù)攝入和計算）

Historical 負(fù)責(zé)加載 segment（已提交的不可變數(shù)據(jù)），接受歷史數(shù)據(jù)查詢。

Middle Manager 負(fù)責(zé)數(shù)據(jù)攝入和提交 segment涡驮，單個 task 由單獨 JVM負(fù)責(zé)暗甥。

Peon 負(fù)責(zé)完成單個 task，由Middle Manager 管理和監(jiān)控捉捅。

Query Node（查詢節(jié)點）

? Broker 接受查詢請求撤防，確定數(shù)據(jù)來自于哪些 segment，分發(fā) sub query 和merge 結(jié)果棒口。

Master Node（Master 節(jié)點寄月，作業(yè)調(diào)度和集群管理）

Coordinator 監(jiān)控 Historical，負(fù)責(zé)給Historical 分配 Segment 和監(jiān)控負(fù)載无牵。

Overlord 監(jiān)控 Middle Manager漾肮，負(fù)責(zé)給 Middle Manager 分配任務(wù)和協(xié)助發(fā)布 Segment。

外部依賴

同時 Druid 有三個可替換的外部依賴：

Deep Storage（分布式存儲）

Druid 使用 Deep storage 在 Druid 各節(jié)點間傳輸數(shù)據(jù)文件合敦。

Metadata Storage（元數(shù)據(jù)存儲）

元數(shù)據(jù)存儲了 Segment 的位置和Task 的輸出等元數(shù)據(jù)初橘。.

Zookeeper（集群管理和作業(yè)調(diào)度）

Druid 使用 Zookeeper (ZK) 來負(fù)責(zé)集群保證集群狀態(tài)的一致性。

圖2 Druid 架構(gòu)圖

Data Source 和 Segment

Druid 中的數(shù)據(jù)存放在Data Source 中充岛，Data Source 概念上等同于RDBMS中的表保檐；Data Source 概念上會根據(jù)時間戳分為若干個Chunk，同一時間區(qū)間產(chǎn)生的數(shù)據(jù)會歸屬到同一 Chunk崔梗；Chunk 內(nèi)部由若干個 Segment 組成夜只，每個 Segment 是一個物理上的數(shù)據(jù)文件，同時 Segment 是一個不可再分的存儲單元蒜魄。出于性能考慮扔亥，一個Segment 文件的大小是建議在 500mb 左右。

圖3 Data Source 和Segment

從 schema 看谈为，因為 Druid具有 OLAP 和 Time Series Database 的特性旅挤，列包含三種，分別為時間戳列伞鲫，維度列和度量列粘茄。時間戳列具有Segment 剪枝的作用，維度列和度量列在 Kylin 中有相似的概念秕脓。

圖4 Druid 中的Schema

Druid 的優(yōu)勢

具有實時攝取數(shù)據(jù)的能力柒瓣，數(shù)據(jù)進入 Druid 即可被查詢，延遲為毫秒級吠架，這也是Druid 的最大特點芙贫。

支持?jǐn)?shù)據(jù)明細查詢和聚合查詢。

數(shù)據(jù)存儲使用列式存儲格式傍药，避免不比較要的 IO磺平。

支持倒排索引魂仍，具有良好的過濾性能。

支持冷熱數(shù)據(jù)分離褪秀。

為什么美團開發(fā) Kylin on Druid

美團點評自 2015年上線使用 Apache Kylin 做為其離線 OLAP 平臺核心組件蓄诽，服務(wù)了幾乎所有業(yè)務(wù)線，數(shù)據(jù)量和查詢次數(shù)迅速增長媒吗，集群壓力越來越大。在這個過程中乙埃，美團技術(shù)團隊不斷摸索闸英，針對Kylin 所暴露出的一些問題尋找更優(yōu)方案，其中一個主要問題就是 Kylin所依賴的存儲：Apache HBase介袜。

我們知道甫何，目前的 Kylin 數(shù)據(jù)存儲使用 HBase，存儲 Cube 時將維度值和度量值轉(zhuǎn)換成 HBase 的 KeyValue遇伞。因為 HBase 不支持二級索引辙喂，只有一個行鍵 (RowKey) 索引，Kylin 的維度值會按照固定的順序拼接作為 RowKey 存儲鸠珠，那么排在 RowKey 前面的維度巍耗，就會獲得比后面的維度更好的過濾性能。下面我們來看一個例子渐排。

在測試環(huán)境使用兩個幾乎完全相同的的 Cube（Cube1 和 Cube2）炬太，它們的數(shù)據(jù)源相同，維度和度量也完全相同驯耻，兩者的唯一差別在于RowKey 中各個維度的順序：Cube1 將過濾用到的字段（P_LINEORDER.LO_CUSTKEY ）放到第一個位置亲族，而 Cube2則將該字段放到最后一個位置。

圖5 Cube1 的RowKey 順序

圖6 Cube2 的RowKey 順序

現(xiàn)在我們以相同的 SQL 在這兩個 Cube 上進行查詢可缚，比較查詢用時霎迫。

select S_SUPPKEY, C_CUSTKEY, sum(LO_EXTENDEDPRICE) as m1

from P_LINEORDER

??? left join SUPPLIER on P_LINEORDER.LO_SUPPKEY = SUPPLIER.S_SUPPKEY

??? left join CUSTOMER on P_LINEORDER.LO_CUSTKEY = CUSTOMER.C_CUSTKEY

WHERE (LO_ORDERKEY > 1799905 and? LO_ORDERKEY < 1799915)? or (LO_ORDERKEY > 1999905 and? LO_ORDERKEY < 1999935)

GROUP BY S_SUPPKEY, C_CUSTKEY;

下圖是它們查詢時的耗時和掃描的數(shù)據(jù)量。

圖7?Cube1 查詢?nèi)罩?/p>

圖8 Cube2查詢?nèi)罩?/p>

從上面的測試結(jié)果看帘靡，對于相同的 SQL 語句知给，兩者查詢用時相差兩百多倍。兩者差別的原因主要在于對 Cube2 所在HTable 進行了更大范圍的掃描测柠。

此外炼鞠，Kylin的多個度量值被存儲到一個 Key 對應(yīng)的 Value，當(dāng)只查詢單個度量時轰胁，不需要的度量也會被讀取谒主，消耗不必要的IO≡叻В總之霎肯，HBase 的局限擎颖，加大了 Kylin 對用戶，尤其是業(yè)務(wù)用戶的使用難度观游。

如果使用純列式的存儲和多維度索引搂捧，將大大提升 Kylin 查詢性能，同時減小Kylin 的使用難度懂缕。從上面的 Druid 的優(yōu)點介紹我們得知 Druid 正好符合列式+多維度索引這樣的特征允跑。因此美團 Kylin 開發(fā)團隊決定嘗試使用 Druid 替換 HBase。

到這里搪柑，讀者可能會問聋丝，為什么不直接使用 Druid 呢？美團的工程師也分享了他們的經(jīng)驗工碾，主要有以下考慮：

Druid 的原生查詢語句是自定義的 JSON 格式弱睦，不是 SQL，上手有難度渊额；雖然 Druid 社區(qū)后來加入了對 SQL 的支持况木，但是功能尚不完整，不能滿足數(shù)據(jù)分析師的復(fù)雜 SQL 查詢需求旬迹。而Kylin 原生支持 ANSI-SQL火惊，使用 Apache Calcite 做語法解析，對SQL 有很好的支持（支持 join舱权，sub query矗晃，window function 等），并且提供 ODBC/JDBC driver 等標(biāo)準(zhǔn)入口宴倍，支持跟 Tableau, Power BI, Superset张症，Redash 等工具直接對接。

Druid 只支持單表查詢鸵贬，而實際業(yè)務(wù)中多表 join 的場景非常多俗他，難以滿足業(yè)務(wù)需要；而Kylin 支持星型模型和雪花模型阔逼，能滿足多表查詢的形式兆衅。

Druid 不能支持精確去重計算；而 Kylin 既支持基于 HyperLogLog 的近似去重嗜浮，也支持基于 Bitmap 的精確去重度量羡亩，對于某些高精度要求場景，Kylin 幾乎成了唯一選擇危融。

Druid 的 rollup 功能只支持預(yù)計算出 Base Cuboid畏铆；相比而言，Kylin 可以定制更多的更豐富的維度組合吉殃，更加精確地匹配查詢辞居，利于減少現(xiàn)場計算的計算量楷怒。

此外從對 Druid 和 Kylin 的使用經(jīng)驗看，直接使用Druid 作為 OLAP 引擎在管理和運維方面有一些挑戰(zhàn)：

Druid 沒有供業(yè)務(wù)人員使用的 Web GUI瓦灶，要建立新模型鸠删，只能通過API 來完成，用戶友好度低贼陶。而 Kylin 提供了易用的 Web GUI刃泡，業(yè)務(wù)人員通過鼠標(biāo)點選就可以創(chuàng)建新模型，然后使用 SQL 進行查詢碉怔，易用性高捅僵，在進行簡單培訓(xùn)后可以交給業(yè)務(wù)人員自助使用。

Druid 沒有友好的集群監(jiān)控和管理界面眨层，運維難度較大。而 Kylin 基于Hadoop 平臺上荡，主流 Hadoop 在監(jiān)控管理上已經(jīng)非常完善趴樱，有 Ambari, Cloudera Manager 等工具使用。

Druid 需要部署和配置專門的集群酪捡，無法利用現(xiàn)有的 Hadoop 集群的計算資源叁征。而大型企業(yè)通常已經(jīng)部署了Hadoop 集群，使用 YARN/Mesos/Kubernets 等標(biāo)準(zhǔn)資源管理器統(tǒng)一管理計算資源逛薇；從這一點來說捺疼，Druid 需要單獨部署和運維。而 Kylin 基于 MapReduce 或 Spark 做數(shù)據(jù)加工永罚，能夠共享 Hadoop 集群的計算資源啤呼，做到動態(tài)調(diào)度，資源使用率高呢袱，無需額外運維成本官扣。

因此，把 Druid優(yōu)秀的列式存儲特性羞福，和 Kylin 在易用性惕蹄、兼容性和完備性相結(jié)合，看上去將是一個不錯 OLAP 解決方案治专。Druid 使用了列式存儲和倒排索引卖陵，過濾性能優(yōu)于 HBase，并且 Druid 天生具有 OLAP的特性张峰，也具有良好的二次聚合能力泪蔫。于是，美團點評技術(shù)團隊決定進行嘗試挟炬，用 Druid 替換 HBase作為 Kylin 的存儲鸥滨。

Kylin on Druid 的設(shè)計介紹

Apache Kylin 1.5 引入了可插拔架構(gòu)嗦哆，將計算和存儲等模塊做了解耦，使得開發(fā)替代 HBase 的存儲引擎變成可能婿滓。在這里我結(jié)合美團工程師康凱森的設(shè)計文檔老速，簡要介紹Kylin on Druid 的主體設(shè)計思想（圖9和圖10來自于參考[1]的附件，文字說明部分來自于參考鏈接中的[1]和[3]）凸主。

構(gòu)建Cube的流程

生成 Cuboid 數(shù)據(jù)文件前橘券，增加計算 Druid Segment 數(shù)量和更新 Druid Rule 的步驟。

和原先的構(gòu)建流程一樣卿吐，通過 MapReduce 生成Cuboid 文件旁舰。

將原有的步驟“轉(zhuǎn)換為HFile”替換為“轉(zhuǎn)換為 Druid Segment ”，該步驟將構(gòu)建好的 Cuboid 文件轉(zhuǎn)化為Druid 的列存格式嗡官，輸出到 HDFS 指定路徑（下圖 1號線條）箭窜。

發(fā)布 Druid Segment 的元數(shù)據(jù)到 Druid 元數(shù)據(jù)存儲（下圖 2號線條）。

Druid Coordinator 會周期性檢查元數(shù)據(jù)存儲的新Segment（下圖 3號線條）衍腥，發(fā)現(xiàn)新的 Segment 會通知 Historical（下圖 4號線條）磺樱，Historical 收到通知會去 HDFS 拉取 Segment 數(shù)據(jù)文件到本地并且加載（下圖 5號線條）。

等到全部 Druid Segment 被加載完畢后婆咸，Cube 完成構(gòu)建竹捉。

圖9 構(gòu)建Cube 流程

查詢 Cube 的流程

當(dāng) Kylin Query Server 查詢數(shù)據(jù)時，經(jīng)過Calcite 解析后的 query plan Druid 的查詢（scan 或者groupby）尚骄，并且將請求發(fā)送給 Druid Broker块差。

Druid Broker 會解析請求找到對應(yīng)的 Historical 分發(fā)請求，并且對 Historical 返回的結(jié)果再做一次聚合倔丈。

Kylin Query Server 通過 HTTP 獲取到 Druid Broker 返回的結(jié)果憨闰，會轉(zhuǎn)化為 Tuple 再交由 Calcite 遍歷處理。

圖10 查詢Cube 流程

Schema 映射

Kylin 的一個 Cube 會被映射到 Druid 的一個 Data Source

Kylin 的一個 Segment 會被映射到 Druid 的一到多個 Segment

Kylin 的分區(qū)時間列映射到 Druid 的時間戳列

Kylin 的 Cuboid 映射到 Druid 的單個維度列

Kylin 的維度列映射到 Druid 的維度列

Kylin 的度量列映射到 Druid 的度量列

總結(jié)

在這篇文章里乃沙，我們首先分析了Kylin 和 Druid 各自的特點和優(yōu)勢起趾，以及Kylin on HBase 在一些情況下性能不佳的原因；然后基于癥狀尋找解決辦法警儒，得出使用 Druid 作為 Kylin 存儲引擎的可行方案训裆；接下來分析了美團開發(fā)的 Kylin on Druid 的架構(gòu)和流程。關(guān)于 Kylin on Druid 的使用方式和性能分析蜀铲，以及Kylin on Druid 目前有哪些尚待完善的部分边琉，請期待下篇文章。

如何使用Kylin on Druid

準(zhǔn)備階段

? 準(zhǔn)備一個 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 的圖標(biāo)從紅色變成藍色。

圖 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 默認(rèn)的 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 有了相當(dāng)?shù)牟樵冃阅堋毛秘？梢?b>利用 Druid 高效的 filter 和 scan饭寺，Kylin 的現(xiàn)場計算能力有了十分明顯的提升。而如果 Cube 設(shè)計得當(dāng)叫挟，且計算較多 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 替換，美團近期也會提供準(zhǔn)確的 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

https://blog.bcmeng.com/post/kylin-on-druid.html

http://druid.io/docs/latest/design

原文鏈接：

https://kyligence.io/zh/blog/why-meituan-develop-kylin-on-druid-i/