本文根據(jù)2016年4月北京Apache Kylin Meetup上的分享講稿整理，略有刪節(jié)迅办。
美團各業(yè)務線存在大量的OLAP分析場景，需要基于Hadoop數(shù)十億級別的數(shù)據(jù)進行分析应结，直接響應分析師和城市BD等數(shù)千人的交互式訪問請求，對OLAP服務的擴展性专缠、穩(wěn)定性、數(shù)據(jù)精確性和性能均有很高要求淑仆。本文主要介紹美團的具體OLAP需求涝婉，如何將Kylin應用到實際場景中，以及目前的使用方式和現(xiàn)狀蔗怠。同時也將Kylin和其它系統(tǒng)（如Presto墩弯、Druid等）進行了對比，闡述了Kylin的獨特優(yōu)勢寞射。
作為公司的平臺部門渔工，需要給各個業(yè)務線提供平臺的服務，那么如何建設一個滿足各種需求的公司平臺級OLAP分析服務呢怠惶。首先涨缚，一個開源項目在公司真正落地會遇到很多障礙轧粟，這主要是由各個業(yè)務線不同的數(shù)據(jù)特點和業(yè)務特點決定的策治，所以本文會介紹一下美團的數(shù)據(jù)場景有什么特點；其次兰吟，針對這些數(shù)據(jù)特點通惫，尤其是和Kylin設計初衷不太相符的部分，有什么樣的解決方案混蔼；第三履腋，目前OLAP領(lǐng)域還沒有所謂事實上的標準，很多引擎都可以做類似事情惭嚣，比如普通的MPP遵湖，Kylin，或者ES等晚吞。這些系統(tǒng)之間的對比情況如何延旧，應該如何選擇，我們也有部分測試數(shù)據(jù)可以分享槽地；最后迁沫，簡單討論一下未來準備在Kylin上做的工作。
1 美團的數(shù)據(jù)場景特點
第一個特點是數(shù)據(jù)規(guī)模和模型特點捌蚊。一方面從數(shù)據(jù)規(guī)模上來講集畅，事實表一般在1億到10億量級，同時還有千萬量級的維表缅糟，也就是超高基數(shù)的維表挺智。另一方面，數(shù)據(jù)模型是一開始遇到的最大困難窗宦。因為Kylin最初的設計是基于一個星形模型的赦颇，但很不幸由于各種原因谣辞，很多數(shù)據(jù)都是雪花的模型，還有其它的模型沐扳，比如所謂“星座”模型泥从，也就是中間是兩張或者三張事實表，周圍關(guān)聯(lián)了其它很多維表沪摄。業(yè)務邏輯決定了這些數(shù)據(jù)的關(guān)聯(lián)方式非常復雜躯嫉，根本無法用經(jīng)典標準的理論來解釋。
第二個是維度杨拐。維度最理想的情況是固定的祈餐，每天變化的只是事實表。但實際上維度經(jīng)常會變哄陶，這可能和行業(yè)特點有關(guān)帆阳，比如組織架構(gòu)，相關(guān)的維度數(shù)據(jù)可能每天都會變化屋吨。除此之外還可能要用今天的維度去關(guān)聯(lián)所有的歷史數(shù)據(jù)蜒谤，因此要重刷歷史數(shù)據(jù)，相應的開銷也比較大至扰。
第三個是數(shù)據(jù)回溯的問題鳍徽。比如發(fā)現(xiàn)數(shù)據(jù)生成有問題，或者上游出錯了敢课，此時就需要重跑數(shù)據(jù)阶祭。這也是和經(jīng)典理論模型有區(qū)別的。
從維度的角度來看直秆，一般維度的個數(shù)在5-20個之間濒募，相對來說還是比較適合用Kylin的。另一個特點是一般都會有一個日期維度圾结，有可能是當天瑰剃，也有可能是一個星期，一個月疫稿，或者任意一個時間段培他。另外也會有較多的層次維度，比如組織架構(gòu)從最上面的大區(qū)一直到下面的蜂窩遗座，就是一個典型的層次維度舀凛。
從指標的角度來講，一般情況下指標個數(shù)在50個以內(nèi)途蒋，相對來說Kylin在指標上的限制并沒有那么嚴格猛遍，都能滿足需求。其中有比較多的表達式指標，在Kylin里面聚合函數(shù)的參數(shù)只能是單獨的一列懊烤，像sum(if…)這種就不能支持梯醒，因此需要一些特別的解決方法。另外一個非常重要的問題是數(shù)據(jù)的精確性腌紧，目前在OLAP領(lǐng)域茸习，各個系統(tǒng)都是用hyperloglog等近似算法做去重計數(shù)，這主要是出于開銷上的考慮壁肋，但我們的業(yè)務場景要求數(shù)據(jù)必須是精確的号胚。因此這也是要重點解決的問題。
在查詢上也有比較高的要求浸遗。因為平臺的查詢服務可能直接向城市BD開放猫胁，每次會有幾十、上百萬次的訪問跛锌，所以穩(wěn)定性是首先要保證的弃秆。第二要求有很高的性能。因為用Kylin主要是為了實現(xiàn)交互式的分析髓帽，讓使用者能夠很快拿到結(jié)果菠赚，所以需要秒級響應。
另外經(jīng)常會有人問到氢卡，Kylin有沒有可視化的前端锈至，在我們內(nèi)部更多是由業(yè)務方來做晨缴，因為原來本身就有這樣的系統(tǒng)译秦，以前接的是MySQL等其它的數(shù)據(jù)源，現(xiàn)在可以直接使用Kylin的JDBC driver對接起來击碗。
以上是美團在OLAP查詢方面的一些特點筑悴。在用Kylin之前，實際上有一些方案稍途，但效果并不理想阁吝。
比如用Hive直接去查，這種情況下械拍，第一個是慢突勇，第二會消耗計算集群的資源。尤其每個月第一天坷虑，大家都要出月報甲馋，跑的SQL非常多，全提到集群上去迄损，并發(fā)度限制導致跑的比平時更慢定躏。
我們原來也做過預聚合的嘗試，這個思路跟Kylin很像，只不過是自己做這個事痊远，用Hive先把所有的維度算出來垮抗，然后導入MySQL或者HBase。但是這個方案并沒有像Kylin這么好的模型定義抽象碧聪，也沒有從配置到執(zhí)行冒版，預計算，查詢這樣整體的框架〕炎耍現(xiàn)在通過使用Kylin實現(xiàn)了低成本的解決這些問題壤玫。
2 接入Apache Kylin的解決方案
針對上述的問題，經(jīng)過大量的嘗試和驗證哼凯，目前主要的解決方案有以下幾點欲间。最重要的第一點，就是采用寬表断部。所有非標準星型的數(shù)據(jù)模型猎贴，都可以通過預處理先拉平，做成一個寬表來解決蝴光。只要能根據(jù)業(yè)務邏輯把這些表關(guān)聯(lián)起來她渴，生成一張寬表，然后再基于這張表在Kylin里做數(shù)據(jù)的聚合就可以了蔑祟。寬表不只能解決數(shù)據(jù)模型的問題趁耗，還能解決維度變化、或者超高基數(shù)的維度等問題疆虚。
第二點是表達式指標的問題苛败，也可以通過提前處理解決。把表達式單獨轉(zhuǎn)成一列径簿，再基于這列做聚合就可以了罢屈。實際上寬表和表達式變換的處理可以用hive的view，也可以生成物理表篇亭。
第三個是精確去重的問題缠捌，目前的方案是基于Bitmap译蒂。由于數(shù)據(jù)類型的限制曼月，目前只支持int類型，其它包括long柔昼、string等類型還不支持哑芹。因為需要把每個值都能映射到Bitmap里,如果是long的話開銷太大。如果用哈希的話就會沖突岳锁，造成結(jié)果不準確绩衷。另外Bitmap本身開銷也是比較大的蹦魔，尤其跑預計算的時候，如果算出來的基數(shù)很大咳燕，對應的數(shù)據(jù)結(jié)構(gòu)就是幾十兆勿决，內(nèi)存會有OOM的風險。這些問題后面我們也會想一些辦法解決招盲，也歡迎在社區(qū)里一起討論低缩。（補充說明：目前已在1.5.3版本中實現(xiàn)了全類型精確去重計數(shù)的支持。）
從整個系統(tǒng)的部署方式上來說曹货，目前Server采用了分離部署的方式咆繁。Kylin Server本質(zhì)上就是一個客戶端，并不需要太多資源顶籽，一般情況下使用虛擬機就能夠滿足需求玩般。
實際的部署情況可以看這張圖，左下角的是hadoop主集群礼饱，用于執(zhí)行每天所有hadoop作業(yè)坏为。中間最重要的是Kylin01和02這兩個server，是用于線上環(huán)境的serve镊绪。其中kylin01是生產(chǎn)環(huán)境匀伏，這個環(huán)境一方面要負責從主機群上跑計算，把數(shù)據(jù)導到HBase蝴韭，另外也要響應前端的請求够颠，從HBase里讀數(shù)據(jù)。如果想新增一個Cube的話榄鉴，需要在kylin02上操作履磨，也就是預上線環(huán)境。所有業(yè)務方人員的cube數(shù)據(jù)模型定義都是在kylin02上做牢硅，沒有問題后由管理員切到kylin01上蹬耘。
這樣做的一個好處是kylin01作為一個線上服務能保證穩(wěn)定性，甚至權(quán)限控制能更嚴格一些减余；第二，預上線環(huán)境下開發(fā)完成后惩系，管理員可以在投入生產(chǎn)前進行一次review位岔，保證cube的效率。
右上角是另外的調(diào)度系統(tǒng)堡牡。整個數(shù)據(jù)倉庫的數(shù)據(jù)生產(chǎn)都是通過這個調(diào)度系統(tǒng)來調(diào)度的抒抬，其中的任務類型很多，Kylin的cube build任務也是作為其中的一種類型晤柄。在上游的數(shù)據(jù)就緒以后擦剑，根據(jù)配置的依賴關(guān)系，自動觸發(fā)Cube建立的過程。
左上角這邊還有一個完全獨立的線下測試集群惠勒，這個集群是完全開放的赚抡，主要是給用戶做一些最開始的可行性調(diào)研或者評估的工作，但同時也不保證穩(wěn)定性纠屋。
一個開源的系統(tǒng)從社區(qū)拿回來涂臣，到真正的落地，再到上生產(chǎn)售担，這個過程相對還是比較長的赁遗，這里并沒有太多的技術(shù)問題，更多的是一些流程上的經(jīng)驗族铆。就是如何在各個階段給業(yè)務方提供更好的服務岩四，使得接入Kylin的過程更順暢，溝通成本更低哥攘。整個過程主要分為四個階段炫乓。
第一個階段是方案選型，業(yè)務方根據(jù)業(yè)務需求献丑，選擇一些方案進行調(diào)研末捣。我們在這個階段提供了需求的Checklist，從數(shù)據(jù)模型创橄，維度各個方面列出來比較詳細的點箩做，可以讓業(yè)務方自己對照，確定需求是不是能夠被滿足妥畏。
在確定Kylin能滿足需求的基礎上邦邦，接下來是第二步，線下探查醉蚁，也就是線下評估或者測試燃辖。我們提供了非常詳細的接入文檔，以及線下測試的環(huán)境网棍。
第三步是線上開發(fā)黔龟，我們也有一些文檔支持，基于抽象出來的場景滥玷，每個場景怎么配置Cube氏身，或者做哪些預處理，如何優(yōu)化等惑畴，能夠給業(yè)務方一個指導性的意見蛋欣。
最后是開發(fā)完成后的切表上線。這個過程目前還是由管理員來操作如贷，一方面是為了避免誤操作或者濫操作陷虎，另一方面也會對cube進行review到踏，幫助進行優(yōu)化。
3 主流OLAP系統(tǒng)對比分析
通過和其它同學交流尚猿，有一個感覺就是大家都覺得Kylin還不錯窝稿，但并不是特別有信心，或者不知道非要用它的理由是什么谊路，或者它和其它系統(tǒng)的對比是什么樣的讹躯？這里也有部分測試結(jié)果可以和大家分享。
整個測試基于SSB的數(shù)據(jù)集缠劝，也是完全開源的潮梯，實際上是專門用于星型模型OLAP場景下的測試。整個測試數(shù)據(jù)集是非常標準的五張表惨恭，可以配置一些參數(shù)決定生成的數(shù)據(jù)集規(guī)模秉馏，然后在不同的規(guī)模下做不同查詢場景的測試。現(xiàn)在已經(jīng)完成的測試的系統(tǒng)包括：Presto脱羡，Kylin1.3萝究，Kylin1.5和Druid。數(shù)據(jù)規(guī)模包含千萬锉罐、億帆竹、十億三種規(guī)模；維度個數(shù)為30個脓规；指標個數(shù)為50個栽连。典型的測試場景包括：上卷、下鉆侨舆，和常用的聚合函數(shù)秒紧。
這里挑選了典型的五個查詢場景：一個事實表的過濾和聚合；五張表全關(guān)聯(lián)之后的查詢挨下；兩個Count Dstinct指標和兩個Sum指標熔恢；后面兩個查詢包含8~10個的維度過濾。
這張圖是千萬規(guī)模下的一個測試結(jié)果臭笆，包括了四個系統(tǒng)叙淌。我們在用Kylin或者其它系統(tǒng)之前沒有專門用于OLAP分析的引擎，只能用通用的耗啦。Presto是其中表現(xiàn)非常好的引擎凿菩，但是在OLAP這種特定的場景下，可以看到不管跟Kylin還是Druid相比差的都比較多帜讲，所以前兩個測試包含了Presto結(jié)果，后面就沒有包含了
這里比較有趣的現(xiàn)象是在第三個查詢椒拗，Kylin1.5反而比Kylin1.3要慢一些似将。這個地方我們還沒有搞清楚是什么原因获黔，后面會詳細的看一下。當然這個也可以證明數(shù)據(jù)沒有修改過在验，是真實的測試數(shù)據(jù)玷氏。
從后面的兩個查詢上可以看到，在千萬規(guī)模的級別腋舌，和Druid還是有比較大的差距盏触。這主要和它們的實現(xiàn)模式相關(guān)，因為Druid會把所有的數(shù)據(jù)預處理完以后都加載到內(nèi)存里块饺，在做一些小數(shù)據(jù)量聚合的時候赞辩，可以達到非常快的速度授艰；但是Kylin要到HBase上讀辨嗽，相對來說它的性能要差一些，但也完全能滿足需求淮腾。
在億級的規(guī)模上情況又有了變化糟需，還是看后面兩個查詢，Kylin1.3基本上是一個線性的增長谷朝，這個數(shù)據(jù)已經(jīng)變得比較難看了洲押，這是由于Kylin1.3在掃描HBase的時候是串行方式，但是Kylin1.5反而會有更好的表現(xiàn)圆凰，這是因為Kylin1.5引入了HBase并行Scan杈帐，大大降低了掃描的時間。Kylin1.5的數(shù)據(jù)會shard到不同的region上送朱，在千萬量級上數(shù)據(jù)量還比較小娘荡，沒有明顯的體現(xiàn)，但是上億以后驶沼，隨著數(shù)據(jù)量上升炮沐，region也變多了，反而能把并發(fā)度提上去回怜。所以在這里可以看到Kylin1.5表現(xiàn)會更好大年。這里也可以看出，在數(shù)據(jù)量成數(shù)量級上升后玉雾，Kylin表現(xiàn)的更加穩(wěn)定翔试，在不同規(guī)模數(shù)據(jù)集上依然可以保持不錯的查詢性能。而Druid隨著數(shù)據(jù)量的增長性能損失也成倍增長复旬。
剛才是在性能方面做的一些分析垦缅，其實對于一個系統(tǒng)來說，性能只是一個方面驹碍，除此之外壁涎，我們也會去考量其它方面的情況凡恍，主要有以下四點。
第一怔球，功能的完備性嚼酝。剛才提到我們所有的數(shù)據(jù)必須是精確的，但是現(xiàn)在基本上沒有哪個系統(tǒng)能完全覆蓋我們這個需求竟坛。比如Druid性能表現(xiàn)確實更好闽巩，但是它去重計數(shù)沒有辦法做到精確。
第二担汤，系統(tǒng)的易用性涎跨。作為一個平臺服務，不僅要把系統(tǒng)用起來漫试，還要維護它六敬，因此要考慮部署和監(jiān)控的成本。這方面Kylin相對來說也是比較好的驾荣。Druid一個集群的角色是非常多的外构，如果要把這個系統(tǒng)用起來的話，可能光搭這個環(huán)境播掷，起這些服務都要很長的時間审编。這個對于我們做平臺來講，實際上是一個比較痛的事歧匈。不管是在部署垒酬，還是加監(jiān)控的時候，成本都是相對比較高的件炉。另外一個查詢接口方面勘究，我們最熟悉或者最標準，最好用的當然是標準SQL的接口斟冕。ES口糕、Druid這些系統(tǒng)原來都不支持SQL，當然現(xiàn)在也有一些插件磕蛇，但是在功能的完備性和數(shù)據(jù)的效率上都不如原生的支持景描。
第三，數(shù)據(jù)成本秀撇。剛才提到了有些數(shù)據(jù)需要做一些預處理超棺，比如表的拉平或者表達式列的變換，除此之外還有一些格式的轉(zhuǎn)化呵燕，比如有的系統(tǒng)只能讀TEXT格式棠绘，這樣都會帶來數(shù)據(jù)準備的成本。另一方面是數(shù)據(jù)導入的效率。從數(shù)據(jù)進入數(shù)據(jù)倉庫到真正能夠被查詢弄唧，這個時間中間有多長适肠。數(shù)據(jù)存儲和服務的時候需要多少機器資源霍衫，這個都可以歸為數(shù)據(jù)成本候引，就是使用這個數(shù)據(jù)需要付出的成本。
第四敦跌，查詢靈活性澄干。經(jīng)常有業(yè)務方問到，如果Cube沒定義的話怎么辦柠傍？現(xiàn)在當然查詢只能失敗麸俘。這個說明有的查詢模式不是那么固定的，可能突然要查一個數(shù)惧笛，但以后都不會再查了从媚。實際上在需要預定義的OLAP引擎上，這種需求普遍來講支持都不是太好患整。
這張圖是各個系統(tǒng)全方位的一個對比拜效。
從查詢效率上看，這里表現(xiàn)最不好的就是Presto各谚，表現(xiàn)最好的應該是Druid和Kylin1.5紧憾，兩者不相上下。從功能完備性上來講昌渤，確實Presto語法和UDF等等是很完備的赴穗，Kylin會稍微差一些，但比Druid好一點膀息。
系統(tǒng)易用性上區(qū)別不是太大般眉，這里主要考慮有沒有標準的SQL接口或者部署成本高不高，用戶上手能不能更快潜支，目前來看Druid接口上確實不夠友好甸赃，需要去翻它的文檔才知道怎么去寫查詢的語法。
在查詢成本上毁腿，Presto是最好的辑奈，因為幾乎不需要做什么特殊的處理，基本上Hive能讀的數(shù)據(jù)Presto也都能讀已烤，所以這個成本非常低鸠窗。Druid和Kylin的成本相對較高，因為都需要提前的預計算胯究，尤其是Kylin如果維度數(shù)特別多稍计，而且不做特別優(yōu)化的話，數(shù)據(jù)量還是很可觀的裕循。
最后從靈活性上來講臣嚣， Presto只要SQL寫出來怎么查都可以净刮，Druid和Kylin都要做一些預先模型定義的工作去团。這方面也可以作為大家選型時候的參考岭佳。
剛才比較客觀的對比了幾個系統(tǒng)，接下來再總結(jié)一下Kylin的優(yōu)勢蹲盘。
第一怎虫，性能非常穩(wěn)定暑认。因為Kylin依賴的所有服務，比如Hive大审、HBase都是非常成熟的蘸际，Kylin本身的邏輯并不復雜，所以穩(wěn)定性有一個很好的保證徒扶。目前在我們的生產(chǎn)環(huán)境中粮彤，穩(wěn)定性可以保證在99.99%以上。同時查詢時延也比較理想姜骡。我們現(xiàn)在有一個業(yè)務線需求导坟，每天查詢量在兩萬次以上，95%的時延低于1秒溶浴，99%在3秒以內(nèi)乍迄。基本上能滿足我們交互式分析的需求士败。
第二闯两，對我們特別重要的一點，就是數(shù)據(jù)的精確性要求谅将。其實現(xiàn)在能做到的只有Kylin漾狼，所以說我們也沒有什么太多其他的選擇。
第三饥臂，從易用性上來講逊躁，Kylin也有非常多的特點。首先是外圍的服務隅熙，不管是Hive還是HBase稽煤，只要大家用Hadoop系統(tǒng)的話基本都有了，不需要額外工作囚戚。在部署運維和使用成本上來講酵熙，都是比較低的。其次驰坊，有一個公共的Web頁面來做模型的配置匾二。相比之下Druid現(xiàn)在還是基于配置文件來做。這里就有一個問題，配置文件一般都是平臺方或者管理員來管理的察藐，沒辦法把這個配置系統(tǒng)開放出去皮璧，這樣在溝通成本和響應效率上都不夠理想。Kylin有一個通用的Web Server開放出來分飞，所有用戶都可以去測試和定義悴务，只有上線的時候需要管理員再review一下，這樣體驗就會好很多浸须。
第四惨寿，最后一點就是活躍開放的社區(qū)和熱心的核心開發(fā)者團隊，社區(qū)里討論非常開放删窒，大家可以提自己的意見及patch，修復bug以及提交新的功能等顺囊，包括我們美團團隊也貢獻了很多特性肌索，比如寫入不同的HBase集群等。這里特別要指出的是核心團隊都是中國人特碳，這是Apache所有項目里唯一中國人為主的頂級項目诚亚，社區(qū)非常活躍和熱心午乓，有非常多的中國工程師站宗。特別是當你貢獻越來越多的時候，社區(qū)會邀請成為committer等益愈，包括我自己及團隊成員也已經(jīng)是Apache Kylin的committer梢灭。同時也非常高興看到以韓卿為首的Apache Kylin核心團隊在今年初成立的創(chuàng)業(yè)公司Kyligence，相信可以為整個項目及社區(qū)的發(fā)展帶來更大的空間和未來蒸其。
4 未來工作
在未來工作方面敏释，我們認為Kylin還有一些不理想的方面，我們也會著力去做優(yōu)化和改進摸袁。
第一钥顽，精確去重計數(shù)。剛才提到只支持Int靠汁，接下來有一個方案會支持所有的數(shù)據(jù)類型蜂大，能夠擴展大家使用精確去重的場景范圍（補充說明：目前該功能已在1.5.3版本中實現(xiàn)）。
第二蝶怔，在查詢效率和Build效率上也看到了一些可以優(yōu)化的部分奶浦。比如隊列資源拆分，我們所有計算集群的資源都是按照業(yè)務線核算成本的添谊，但是現(xiàn)在Kylin本身還不太支持财喳，這個我們也會抓緊去做，相信在很多公司也有類似的需求。還有大結(jié)果集和分頁耳高。當結(jié)果到了上百萬的量級時扎瓶，查詢時延會上升到幾十秒。同時在查詢的時候有可能需要排序并且分頁泌枪，就是把結(jié)果全讀出來之后概荷，根據(jù)其中的一個指標再order by，這個開銷也是比較大的碌燕。我們也會想辦法進行優(yōu)化误证。
最后，Kylin1.5之后有明細數(shù)據(jù)和Streaming特性出來修壕，后面也會做這方面的嘗試愈捅。
5 Q&A
Q1：之前在Build的時候一直提到成本的問題，能給出一個估計值嗎慈鸠，如果一百億的數(shù)據(jù)蓝谨，需要多少時間？
孫業(yè)銳：有一個簡單數(shù)據(jù)青团，大概是兩億行數(shù)據(jù)譬巫，維度的話有十四五個，Build時間不超過兩個小時督笆，Build出來的數(shù)據(jù)是五六百G芦昔。
Q2：原始值是多大？
孫業(yè)銳：把這個數(shù)據(jù)抽出來之后娃肿，就是只參與Build的數(shù)據(jù)壓縮后只有幾個G咕缎。
Q3：Kerberos認證失效的問題你們遇到過沒有？
孫業(yè)銳： Kerberos認證完之后咸作，會在本地臨時目錄下有一個ticket問題锨阿，每天在外部定時刷新一下就可以了，服務是不用停的记罚。
主持人：我補充一下我們?yōu)槭裁催x擇SQL接口墅诡？Kylin解決的是真正的用戶面是誰，其實是業(yè)務人員和分析人員桐智，他只會SQL末早，幾乎那些人很少說再學個JAVA，所以能給他一個標準的SQL這個是讓他上船最快的事情说庭。其實這就是易用性很重要然磷。
剛才看到了Kylin在千萬級規(guī)模和億級規(guī)模的表現(xiàn)，如果數(shù)據(jù)規(guī)模上到十億刊驴，百億姿搜，千億的時候寡润，我相信Kylin應該會秒殺所有一切。因為我們現(xiàn)在有另一個案例舅柜，生產(chǎn)環(huán)境上千億規(guī)模的一張表梭纹，可以做到90%查詢在1.8秒以內(nèi)。另外我覺得非常好的一點致份，像美團变抽、京東這邊貢獻了很多patch，其實就是把需求提出來氮块，大家可以一起來做绍载。
作者介紹
孫業(yè)銳，美團高級工程師滔蝉，Apache Kylin Committer击儡。2012年畢業(yè)于電子科技大學，曾在奇虎360工作锰提，負責Hadoop平臺建設曙痘，2015年加入美團。目前主要負責數(shù)據(jù)生產(chǎn)和查詢引擎的改進和優(yōu)化立肘，專注于分布式計算，OLAP分析等領(lǐng)域名扛，對分布式存儲系統(tǒng)亦有豐富經(jīng)驗谅年。
原文地址：http://www.infoq.com/cn/articles/kylin-apache-in-meituan-olap-scenarios-practice
