作者：康凱森
作者簡介：美團(tuán)大數(shù)據(jù)工程師，Apache Kylin Committer仿贬，目前主要負(fù)責(zé)美團(tuán) OLAP 系統(tǒng)（Kylin & Druid & Palo）的平臺化建設(shè)。
8月11日，由 Kyligence 主辦、美團(tuán)點評協(xié)辦的 Apache Kylin Meetup@北京较锡，在美團(tuán)公司總部圓滿落幕业稼。本文整理自當(dāng)天美團(tuán)大數(shù)據(jù)工程師、Apache Kylin Committer 康凱森的演講實錄蚂蕴，全文共6,600字低散，閱讀時間大約15分鐘。
本次分享會分為三個部分的內(nèi)容骡楼，首先會介紹 Kylin On Hbase 的問題熔号，引入我們?yōu)槭裁匆o Kylin 增加新存儲引擎的問題；接下來介紹Kylin新存儲引擎的過程鸟整，以此來說明為什么選擇 Druid 作為我們新的存儲引擎引镊；最后給大家介紹 Kylin On Druid 的核心架構(gòu)、核心原理篮条、性能和我們的初步成果弟头，以下分享中將 Kylin On Druid 簡稱 KOD。
Kylin 在美團(tuán)點評的服務(wù)現(xiàn)狀
進(jìn)入正式主題前涉茧，我先介紹下Kylin在美團(tuán)點評的現(xiàn)狀赴恨。目前我們線上 Cube 數(shù)有近1000個，Cube 單副本存儲近1PB伴栓；每天查詢量380多萬次伦连，查詢的 TP50 時延在200ms左右雨饺，TP90時延在1.2s左右。目前 Kylin 已經(jīng)覆蓋了美團(tuán)點評所有主要業(yè)務(wù)線惑淳。
Kylin on HBase 問題
隨著 Kylin 在我司的大規(guī)模使用和我們對Kylin的深入優(yōu)化改進(jìn)额港，我們發(fā)現(xiàn)了 Kylin 本身的一些痛點和問題，其中之一便是 Kylin On HBase 的性能問題汛聚。如圖：我們用同一 SQL 在同一集群查詢同一 Cube锹安，前后性能相差上千倍。 兩次查詢的唯一不同點就是 Kylin 維度在 HBase 的 RowKey 中位置不同倚舀， 耗時90ms的查詢中維度dt和poi_id 在 RowKey 前兩位叹哭，耗時100多s的查詢中維度dt和 poi_id 在 RowKey 后兩位。
下面我們來看下Kylin On HBase中前后綴過濾性能相差巨大的原因：如圖所示：Kylin中會將Cuboid+所有維度拼接成HBase的Rowkey痕貌，Kylin默認(rèn)會將所有普通指標(biāo)拼接成HBase一個Column Family中同一列的Value风罩。HBase只有單一Rowkey索引，所以只有查詢能夠匹配Rowkey的前綴時舵稠，查詢性能會十分高效超升，反之，查詢性能會比較低下哺徊，甚至?xí)霈F(xiàn)全表Scan室琢。此外，即使只需要查詢一個指標(biāo)落追，Kylin在HBase側(cè)也需要Scan所有指標(biāo)列盈滴，相比列存性能也會有較大差距。 總的來說轿钠，HBase在Kylin的查詢場景下Scan和Filter效率較低下巢钓。
對于Kylin On HBase Scan和Filter效率低下的問題，我們比較自然會想到的解法是：用列存加速Scan疗垛，用索引來加速Filter症汹。
這里我簡單介紹下列存的優(yōu)點，主要包含以下3點：
因為只需要讀取必需訪問的列贷腕，所以列存有高效的IO
因為每列數(shù)據(jù)的類型一致背镇，格式一致，所以列存可以進(jìn)行高效的編碼和壓縮
列存更容易實現(xiàn)向量化執(zhí)行泽裳，而向量化執(zhí)行相比傳統(tǒng)的火山模型芽世，函數(shù)調(diào)用次數(shù)更少，對CPU Cache和SIMD更加友好诡壁。 總的來說济瓢，列存相比HBase的KV模型更適合Kylin的查詢場景。
所以妹卿，要解決 Kylin On HBase Scan 和 Filter 效率低下的問題, 我們就需要為 Kylin 增加一個列存旺矾，有高效索引的存儲引擎蔑鹦。
Kylin 新存儲引擎探索之路
在我們?yōu)镵ylin新增一個存儲引擎之前，我們自然就需要先了解Kylin的存儲引擎組成箕宙。主要有5部分：存儲格式嚎朽，Cache，計算柬帕，調(diào)度和元數(shù)據(jù)哟忍。 計算指數(shù)據(jù)的Scan,過濾，聚合等陷寝，調(diào)度指文件增刪锅很，復(fù)制和負(fù)載均衡等，這里的元數(shù)據(jù)指的是存儲引擎本身的元數(shù)據(jù)凤跑。其中存儲格式對查詢性能影響很大爆安，也是HBase在Kylin查詢場景下的痛點，所以我們決定首先去尋找或改造一個適合Kylin的存儲格式仔引。
Kylin 新存儲引擎實現(xiàn)思路
當(dāng)時我們主要有兩個思路扔仓，一種思路是基于Spark + 存儲格式進(jìn)行演進(jìn)： 就是找到一個優(yōu)秀的存儲格式后，和Spark進(jìn)行集成咖耘。大概思路是將文件Cache到本地翘簇，用Spark來實現(xiàn)計算和查詢的調(diào)度，整個方案大體上就可以Run起來儿倒。大家對這種思路感興趣的話版保，可以參考TiDB的TiSpark項目，以及Snappydata這個系統(tǒng)义桂。
第二種思路就是找到或自研一個優(yōu)秀的存儲格式后，再參考HBase蹈垢， Druid等系統(tǒng)慷吊，逐步完善成一個完整的存儲引擎。
所以曹抬，無論哪一種思路溉瓶，我們都需要首先找到或者自研一個優(yōu)秀的適合Kylin的存儲格式。
我們在調(diào)研存儲格式時主要考慮Scan和Filter性能谤民，導(dǎo)入性能堰酿，壓縮率，集成難度這4點因素张足，其中重點關(guān)注Scan和Filter性能触创。
Kylin On Parquet POC
我們首先對Parquet進(jìn)行了調(diào)研。因為Parquet是當(dāng)前Hadoop生態(tài)列式文件的標(biāo)準(zhǔn)为牍，在Hadoop生態(tài)中廣泛使用哼绑。一個Parquet文件先按行邏輯上水平拆分成row groups岩馍，row groups內(nèi)是列存，每一列是一個Column chunks抖韩，Column chunks進(jìn)一步拆分成Page蛀恩， Page是數(shù)據(jù)訪問的最小單位。Parquet 可以通過min,max索引和字典實現(xiàn)row groups粒度的過濾茂浮，但是沒有Page粒度的索引双谆。
我們在17年5月份的時候進(jìn)行了Kylin On Parquet POC，POC的結(jié)果也符合我們的理論預(yù)期：由于Parquet是列存席揽，所以在Scan部分列時性能優(yōu)于HBase顽馋，但由于存在Tuple重組，也就是列轉(zhuǎn)行的開銷驹尼，Scan性能會隨著訪問列的個數(shù)增加而降低趣避，Scan全部列時性能不如HBase。 Filter方面新翎，Parquet在前綴和后綴過濾上性能沒有差別程帕，但是由于當(dāng)時的Parquet沒有Page粒度的細(xì)粒度索引，所以前綴過濾性能明顯比HBase差地啰。
Kylin On CarbonData
由于Parquet過濾性能不足愁拭，所以我們就Pass了Kylin On Parquet的方案。 Parquet之后亏吝，我們又調(diào)研了當(dāng)時新起的華為開源的存儲格式CarbonData岭埠。和Parquet類似，CarbonData首先將數(shù)據(jù)水平切分成若干個Blocklet蔚鸥，Blocklet內(nèi)部按列存儲惜论，每列的數(shù)據(jù)叫做一個Column Chunk。和Parquet不同的是止喷，CarbonData擁有豐富的索引：MDK索引馆类；Min，Max索引弹谁；倒排索引乾巧。MDK索引是多維度索引，類似Kylin中的維度索引预愤，整個文件會按照多個維度列進(jìn)行排序沟于，這樣對MDK列中的維度進(jìn)行前綴過濾就會很高效。
CarbonData的列存+豐富索引的設(shè)計的確是我們所期望的植康，不過CarbonData和Spark耦合較深旷太，且當(dāng)時的CarbonData沒有OutputFormat，也不是很成熟销睁，所以我們也Pass了Kylin On CarbonData的方案泳秀。
Kylin On Lucene POC
Parquet标沪，CarbonData之后。 我們差不多同時進(jìn)行了Kylin On Lucene POC 和 Kylin On Druid POC嗜傅。我們先來看下Lucene金句， Lucene大家應(yīng)該都很熟悉，是一個被廣泛使用的全文搜索庫吕嘀，其存儲格式是基于MMAP违寞，支持倒排索引的列存。
Kylin On Lucene POC的結(jié)果和我們對倒排索引的理論認(rèn)知符合：由于倒排索引是用額外的構(gòu)建成本和存儲成本換取查詢時高效的過濾性能偶房，所以Lucene的構(gòu)建性能只有HBase的1/3趁曼，存儲是HBase的4倍，但是過濾性能明顯優(yōu)于HBase棕洋。
Kylin On Druid POC
下面我們來看下Druid的存儲格式挡闰。和Lucene類似，Druid的存儲格式也是基于MMAP掰盘，支持倒排索引的列存摄悯，區(qū)別是Druid的倒排索引是基于Bitmap的，Lucene的倒排索引是基于倒排表的愧捕。Druid的存儲格式比較簡單奢驯，就是直接按列依次存儲，其中的M1,M2是指標(biāo)列次绘，D1,D2指維度列.除了數(shù)據(jù)文件之外瘪阁，還會有一個meta文件記錄每一列的offset。我們要讀取Druid文件時邮偎，就將Druid文件MMap到內(nèi)存管跺，直接根據(jù)offset讀取指定偏移量的數(shù)據(jù)。
圖中上半部分是Druid Bitmap 倒排索引的實現(xiàn)原理：我們有維度列D2, 共4行數(shù)據(jù)禾进，包含meituan,dianping兩個值豁跑，Druid會首先對維度列進(jìn)行字典編碼，圖中meituan編碼為0命迈，dianping編碼為1贩绕，然后Druid會基于維度值和字典構(gòu)建基于Bitmap的倒排索引火的，倒排索引的Key是編碼后的ID壶愤，Value是Bitmap，Bitmap的哪個bit位是1馏鹤，就表示該值出現(xiàn)在哪些行征椒。 下半部分是Druid String 維度存儲的具體內(nèi)容：包括列的元數(shù)據(jù)，維度字典湃累，維度編碼后的ID和倒排索引勃救。
圖中是Kylin On Druid POC的結(jié)果碍讨，我們可以看到Druid的過濾性能明顯優(yōu)于HBase，Scan性能和Parquet類似蒙秒，在部分列時也明顯優(yōu)于HBase勃黍。 構(gòu)建和存儲的話，和Lucene類似晕讲，會比HBase差一點覆获。
Why Kylin On Druid
在我們對Parquet，CarbonData瓢省，Lucene弄息，Druid的存儲格式和POC情況有了基本了解之后，我們來看下為什么我們當(dāng)時做出了Kylin On Druid的方案：
Parquet的索引粒度較粗勤婚，過濾性能不足摹量；
CarbonData與Spark 耦合較深，集成難度較大馒胆；
Lucene 和 Druid相比缨称，存儲膨脹率較高，還有比較重要的一點是国章，Druid不僅僅是一個存儲格式具钥，也可以作為Kylin完整的存儲引擎。
我們再來看下我們選擇Kylin On Druid的原因：
首先是Druid Scan,Filter性能很好
其次是Druid不僅僅是一個存儲格式液兽，而是可以作為一個完整的Kylin存儲引擎骂删， 比如Druid Historical節(jié)點負(fù)責(zé)Segment的Cache和 計算，Druid Coordinator節(jié)點負(fù)責(zé)Segment的增刪四啰，副本和負(fù)載均衡宁玫。這樣我們就不需要基于存儲格式再去演進(jìn)出一個存儲引擎，我們整個項目的工期會大幅縮短柑晒。
最后欧瘪，Kylin和Druid本身就是我們維護(hù)的系統(tǒng)，項目即使失敗匙赞，我們的付出也會有收獲佛掖。
Kylin On Druid
OK，前半部分主要介紹了Kylin On Druid的大背景涌庭，回答了Why Kylin On Druid芥被。 下面我們來看下How Kylin On Druid。
Kylin 可插拔架構(gòu)
在介紹Kylin On Druid之前坐榆，我們先來看下Kylin的可插拔架構(gòu)拴魄。Kylin的可插拔架構(gòu)對數(shù)據(jù)源，計算引擎， 存儲引擎都有抽象匹中，理論這3個部分都是可以替換的夏漱。目前數(shù)據(jù)源已經(jīng)支持Hive，Kafka顶捷；計算引擎支持Spark挂绰，MR； 但是存儲引擎只有HBase服赎。?所謂的Kylin On Druid就是在Kylin的可插拔架構(gòu)中用Druid替換掉HBase扮授。
Kylin On Druid 架構(gòu)
圖中是Kylin On Druid 簡化后的架構(gòu)圖，分為數(shù)據(jù)導(dǎo)入和數(shù)據(jù)查詢兩條線专肪。數(shù)據(jù)導(dǎo)入時刹勃，Kylin的JobServer會將Hive中的數(shù)據(jù)導(dǎo)入到Druid的Historical節(jié)點中；數(shù)據(jù)查詢時嚎尤，Kylin的Queryserver會通過Druid的Broker節(jié)點向Druid發(fā)起查詢荔仁。
下面我們來詳細(xì)看下KOD數(shù)據(jù)導(dǎo)入和數(shù)據(jù)查詢的過程，我們首先來看下數(shù)據(jù)導(dǎo)入過程：
和HBase一樣芽死，首先需要計算出Cuboid
生成Cuboid后乏梁，Kylin On HBase中是將Cuboid轉(zhuǎn)為HBase的HFile，KOD中則是將Cuboid轉(zhuǎn)為Druid Segment文件关贵。
向Druid的MetaData Store插入Segment元數(shù)據(jù)遇骑。下面的工作是Druid內(nèi)部的流程:
Coordinator定期從MetaData Store Pull Segment元數(shù)據(jù)，發(fā)現(xiàn)有新Segment生成時揖曾，就會通知Historical節(jié)點Load Segment
Historical節(jié)點收到Load Segment通知后落萎，就會去HDFS上下載Segment文件，然后MMap到內(nèi)存炭剪，至此整個數(shù)據(jù)導(dǎo)入過程完成练链。
KOD的數(shù)據(jù)查詢過程，Kylin和Druid如何交互我們可以有兩種方案奴拦。?一種是通過直接訪問Broker的方式和Druid集成媒鼓，一種是通過直接訪問Druid Historical節(jié)點的方式和Druid集成。 第一種方式我們只需要將Kylin的SQL翻譯成Druid的json错妖，通過Http向Druid的Broker發(fā)起查詢绿鸣。 第二種方式我們就需要在kylin中實現(xiàn)Druid Broker的功能，好處是性能會比第一種好暂氯，因為少一層網(wǎng)絡(luò)傳輸潮模，壞處是Kylin和Druid的依賴沖突會更嚴(yán)重，實現(xiàn)較復(fù)雜株旷。本著侵入性小和簡單可用的原則再登，我們選擇了第一種方案。
Kylin On Druid 實現(xiàn)細(xì)節(jié)
在了解了KOD的架構(gòu)和整個數(shù)據(jù)導(dǎo)入晾剖，數(shù)據(jù)查詢過程后锉矢，我們再具體看下我們做了哪些方面的工作：
Kylin和Druid的Schema映射
Cube 構(gòu)建側(cè)適配
Cube 查詢側(cè)適配
運維工具適配
其實這4方面的工作也是我們?yōu)镵ylin增加一個存儲引擎必須要做的工作。
Kylin和Druid的Schema映射是這樣的：Kylin的Cube對應(yīng)Druid中的DataSource齿尽，Kylin的Segment對應(yīng)Druid中的Segment沽损，維度對維度，指標(biāo)對指標(biāo)循头，需要額外增加一個Cuboid維度列绵估，Druid中沒有的指標(biāo)需要在Druid中進(jìn)行擴(kuò)展。
我們目前在Druid中增加了Kylin的精確去重指標(biāo)卡骂，Kylin的ExtendColumn指標(biāo)和Decimal指標(biāo)国裳。無論是Druid還是Kylin，我們新增一種聚合指標(biāo)所要做的事情都是類似的全跨，區(qū)別只是具體的接口和實現(xiàn)方式不同缝左。我們自定義一種聚合指標(biāo)要做這些事情：
定義指標(biāo)的元數(shù)據(jù)：指標(biāo)的名稱參數(shù)，返回類型浓若，核心數(shù)據(jù)結(jié)構(gòu)渺杉；
定義指標(biāo)的聚合方式凑兰；
定義指標(biāo)序列化和反序列化的方式膀钠；
注冊指標(biāo)葛碧，讓系統(tǒng)發(fā)現(xiàn)新指標(biāo)池摧。
Cube構(gòu)建側(cè)適配除了之前提到的將Cuboid 轉(zhuǎn)為 Druid Segment和Load Segemnt這一步煌茬，KOD中為了支持Druid層的業(yè)務(wù)隔離可柿，還增加了Update Druid Tier這一步散休，允許用戶將不同的Cube存儲到不同的Tier单鹿。在Druid Segment生成和Load這兩步馏予，都進(jìn)行了一定的優(yōu)化蔓纠。 生成Druid Segment時，由于需要生成倒排索引吗蚌，所以相比生成HBase的HFILE腿倚，就需要更多的內(nèi)存，所以這一步進(jìn)行了較多內(nèi)存升的優(yōu)化蚯妇。 在Druid Load Segment這一步敷燎，初期發(fā)現(xiàn)多個Segment 并發(fā)導(dǎo)入時，Druid Load Segment會很慢箩言。 經(jīng)過排查發(fā)現(xiàn)硬贯，主要是Druid 0.10.0版本有bug，默認(rèn)的并發(fā)度配置不生效陨收，所以整個Load是串行饭豹，后來是通過升級到Druid 0.11鸵赖，并將并發(fā)度設(shè)置為磁盤數(shù)的2倍解決的，因為Druid Load Segment的耗時99.9% 都是在從HDFS下載Segment上拄衰。
在介紹KOD對Cube查詢側(cè)的適配之前它褪，我們先簡單看下Kylin的查詢流程。Kylin的SQL解析翘悉，邏輯計劃的生成和優(yōu)化都是通過Calcite實現(xiàn)的茫打，Kylin會根據(jù)Calcite生成的查詢計劃生成HBase的Scan請求，HBase端經(jīng)過Scan妖混，F(xiàn)ilter,Agg后會一次性將結(jié)果返回給Kylin的QueryServer老赤，QueryServer會將HBase返回的結(jié)果反序列化，對維度根據(jù)字典進(jìn)行解碼生成Obejct數(shù)組制市，再將Obejct數(shù)組轉(zhuǎn)為Tuple抬旺，Tuple和Obejct數(shù)組的主要區(qū)別是Tuple有了類型信息，最后Tuple會交給Calcite的Enumerator進(jìn)行最終計算祥楣。
下面我們來看下KOD對Cube查詢側(cè)的適配嚷狞，我們拿到Calcite生成的查詢計劃后，為了實現(xiàn)謂詞下推荣堰，會首先將Kylin的Filter轉(zhuǎn)為Druid的Filter床未；其次會進(jìn)行分區(qū)裁剪，避免訪問不必要的Druid Segment振坚；然后會根據(jù)查詢的Cube薇搁，維度，指標(biāo)渡八，F(xiàn)ilter等生成Druid的查詢Json啃洋，通過Http向Druid發(fā)起查詢，Druid端經(jīng)過Scan屎鳍，F(xiàn)ilter,Agg后會按照Http Chunk的方式Pipline地將查詢結(jié)果返回給Kylin的QueryServer宏娄，下來的過程基本和HBase類似，需要注意的是逮壁，由于我們本身在Druid中存儲的就是原始值孵坚，所以查詢就不需要加載字典進(jìn)行維度的解碼。
最后我們來看下運維工具適配方面的工作窥淆，主要包括：
Cube遷移工具
Storage Cleanup工具
Cube Purge卖宠，Drop，Retention操作等忧饭。
這里我就不展開了扛伍，因為主要是一些實現(xiàn)和細(xì)節(jié)上的問題。
Kylin On Druid 成果
現(xiàn)在為止词裤，我們已經(jīng)清楚了KOD的整體架構(gòu)和核心原理刺洒。 下面我們來看下鳖宾，KOD的性能到底怎么樣。 首先我們來看下SSB測試的結(jié)果逆航，PPT中展示了我們測試的SQL樣例和測試環(huán)境鼎文。 需要特別注意的是：我們在KOD和Kylin都只計算了Base Cuboid，因為如果KOD和Kylin都充分預(yù)計算纸泡，測試性能基本上沒有意義，測試的目的就是為了對比KOD和Kylin的現(xiàn)場計算能力赖瞒。
這是KOD和Kylin只計算Base Cuboid時SSB測試的結(jié)果女揭，圖中縱軸是KOD相比Kylin的加速比，千萬量級時KOD的加速比是49栏饮，億級時KOD的加速比是130吧兔。 總的來說，KOD的現(xiàn)場計算能力相比Kylin有了兩個數(shù)量級的提升袍嬉。
這張圖展示的是我們KOD第一批Cube上線后境蔼，線上的真實數(shù)據(jù)。 我們可以看到伺通，KOD相比Kylin在查詢性能提升的同時箍土，存儲和計算資源也有了明顯的下降
前面提到，KOD的現(xiàn)場計算能力相比Kylin有了兩個數(shù)量級的提升罐监，所以對于億級及以下數(shù)據(jù)規(guī)模的數(shù)據(jù)吴藻，我們不需要再進(jìn)行復(fù)雜的優(yōu)化，只需要構(gòu)建Base Cuboid就可以弓柱，用戶的易用性有了顯著提升沟堡。
Kylin On Druid 特性
在介紹完KOD的架構(gòu)，核心原理矢空，性能后航罗，我們再總結(jié)下KOD的特性：
和Kylin完全兼容：SQL，Web 等
分區(qū)預(yù)過濾
查詢時無需加載字典：相比Kylin On HBase 查詢穩(wěn)定性更高
存儲層支持業(yè)務(wù)隔離
億級及以下數(shù)據(jù)只需構(gòu)建Base Cuboid
Kylin On Druid 未來規(guī)劃
最后屁药，我們看下KOD的未來規(guī)劃：
1?更高效粥血，更精簡的Cube構(gòu)建流程：由于Druid不依賴字典，所以KOD的Cube構(gòu)建時酿箭，就不需要構(gòu)建字典立莉，和字典相關(guān)的好幾步都可以省去
2?優(yōu)化高基數(shù)列點查詢的場景：之前的POC也體現(xiàn)了這一點，這種場景是倒排索引不適合的場景七问，卻是HBase的最佳場景蜓耻。 解決思路：參考linkedin的Pinot對Druid進(jìn)行優(yōu)化，Druid中倒排索引作為可選項械巡，添加輕量級的類似Palo刹淌，ClickHouse的前綴索引饶氏。
3?支持在線Schema變更：目前Kylin的Schema變更也是用戶使用上一大痛點，每次Schema變更都需要全量重刷數(shù)據(jù)有勾。
本次分享從Kylin On HBase 問題出發(fā)疹启，解釋了為什么我們給Kylin新增一種存儲引擎，進(jìn)而介紹了我們存儲引擎探索的過程蔼卡，最后介紹了Kylin On Druid的架構(gòu)和原理喊崖。
最后，需要注意的一點是雇逞，最新版本的Parquet已經(jīng)有了PageIndex荤懂，點查詢的性能顯著提高，所以Kylin On paquert 或許依然值得嘗試塘砸。
FAQ
Q1：為什么不直接用Druid代替Kylin节仿？
Kylin的預(yù)計算比Druid更加強(qiáng)大，Druid只能計算Base Cuboid
Kylin支持基于預(yù)計算的精確計算掉蔬，精確去重是我司強(qiáng)需求
Kylin的SQL支持更加完善
Kylin的離線導(dǎo)入更加完善
Kylin對星型模型的查詢支持更加友好
Kylin支持Join
總之廊宪，用Druid代替Kylin的工作量遠(yuǎn)遠(yuǎn)大于Kylin On Druid的工作量。
Q2：為什么沒有選擇Kylin On Kudu女轿？
Kudu 并沒有倒排索引或者二級索引
Kudu 是C++實現(xiàn)的箭启，我們團(tuán)隊的技術(shù)棧主要是Java，我們的存儲團(tuán)隊也沒有引進(jìn)Kudu
Q3：為什么沒有選擇去優(yōu)化改進(jìn)HBase?
因為要將HBase的Key-Value模型改成列存的話已經(jīng)不僅僅是優(yōu)化改進(jìn)了蛉迹，需要重新設(shè)計整個系統(tǒng)册烈。 可以參考：https://kudu.apache.org/faq.html#why-build-a-new-storage-engine-why-not-just-improve-apache-hbase-to-increase-its-scan-speed
Q4：Druid 和 Kylin 的應(yīng)用場景？
在我司婿禽，Kylin是主推的離線OLAP引擎赏僧，Druid是主推的實時OLAP引擎。
關(guān)于 CarbonData 的 DataMap特性
CarbonData在最近的版本實現(xiàn)了DataMap特性:?https://carbondata.apache.org/datamap-developer-guide.html
DataMap的主要目的是一份存儲支持多種查詢場景扭倾，實現(xiàn)CarbonData設(shè)計之初 的愿景淀零；核心思想是一份數(shù)據(jù)，多種索引膛壹，不同場景下的查詢用不同的索引進(jìn)行加速驾中，查詢時可以自動路由到相應(yīng)的索引。 目前已經(jīng)實現(xiàn)了Pre-aggregate DataMap模聋，Timeseries DataMap肩民，Lucene DataMap，BloomFilter DataMap等链方，個人比較看好CarbonData這個特性持痰。
