作為公司的平臺(tái)部門(mén)瞒窒，需要給各個(gè)業(yè)務(wù)線提供平臺(tái)的服務(wù)啼止，那么如何建設(shè)一個(gè)滿(mǎn)足各種需求的公司平臺(tái)級(jí)OLAP分析服務(wù)呢。首先砂沛，一個(gè)開(kāi)源項(xiàng)目在公司真正落地會(huì)遇到很多障礙，這主要是由各個(gè)業(yè)務(wù)線不同的數(shù)據(jù)特點(diǎn)和業(yè)務(wù)特點(diǎn)決定的孔庭，所以本文會(huì)介紹一下美團(tuán)的數(shù)據(jù)場(chǎng)景有什么特點(diǎn)尺上；其次，針對(duì)這些數(shù)據(jù)特點(diǎn)圆到，尤其是和Kylin設(shè)計(jì)初衷不太相符的部分怎抛，有什么樣的解決方案；第三芽淡，目前OLAP領(lǐng)域還沒(méi)有所謂事實(shí)上的標(biāo)準(zhǔn)马绝，很多引擎都可以做類(lèi)似事情，比如普通的MPP挣菲，Kylin富稻，或者ES等掷邦。這些系統(tǒng)之間的對(duì)比情況如何，應(yīng)該如何選擇椭赋，我們也有部分測(cè)試數(shù)據(jù)可以分享抚岗；最后，簡(jiǎn)單討論一下未來(lái)準(zhǔn)備在Kylin上做的工作哪怔。
文章目錄 [hide]
1 美團(tuán)的數(shù)據(jù)場(chǎng)景特點(diǎn)
2 接入Apache Kylin的解決方案
3 主流OLAP系統(tǒng)對(duì)比分析
4 未來(lái)工作
5 Q&A
美團(tuán)的數(shù)據(jù)場(chǎng)景特點(diǎn)
第一個(gè)特點(diǎn)是數(shù)據(jù)規(guī)模和模型特點(diǎn)宣蔚。一方面從數(shù)據(jù)規(guī)模上來(lái)講，事實(shí)表一般在1億到10億量級(jí)认境，同時(shí)還有千萬(wàn)量級(jí)的維表胚委，也就是超高基數(shù)的維表。另一方面叉信，數(shù)據(jù)模型是一開(kāi)始遇到的最大困難亩冬。因?yàn)镵ylin最初的設(shè)計(jì)是基于一個(gè)星形模型的，但很不幸由于各種原因硼身，很多數(shù)據(jù)都是雪花的模型硅急，還有其它的模型，比如所謂“星座”模型鸠姨，也就是中間是兩張或者三張事實(shí)表铜秆，周?chē)P(guān)聯(lián)了其它很多維表淹真。業(yè)務(wù)邏輯決定了這些數(shù)據(jù)的關(guān)聯(lián)方式非常復(fù)雜讶迁，根本無(wú)法用經(jīng)典標(biāo)準(zhǔn)的理論來(lái)解釋。
第二個(gè)是維度核蘸。維度最理想的情況是固定的巍糯，每天變化的只是事實(shí)表。但實(shí)際上維度經(jīng)常會(huì)變客扎，這可能和行業(yè)特點(diǎn)有關(guān)祟峦，比如組織架構(gòu)，相關(guān)的維度數(shù)據(jù)可能每天都會(huì)變化徙鱼。除此之外還可能要用今天的維度去關(guān)聯(lián)所有的歷史數(shù)據(jù)宅楞，因此要重刷歷史數(shù)據(jù)，相應(yīng)的開(kāi)銷(xiāo)也比較大袱吆。
第三個(gè)是數(shù)據(jù)回溯的問(wèn)題厌衙。比如發(fā)現(xiàn)數(shù)據(jù)生成有問(wèn)題，或者上游出錯(cuò)了绞绒，此時(shí)就需要重跑數(shù)據(jù)婶希。這也是和經(jīng)典理論模型有區(qū)別的。
從維度的角度來(lái)看蓬衡，一般維度的個(gè)數(shù)在5-20個(gè)之間喻杈，相對(duì)來(lái)說(shuō)還是比較適合用Kylin的彤枢。另一個(gè)特點(diǎn)是一般都會(huì)有一個(gè)日期維度，有可能是當(dāng)天筒饰，也有可能是一個(gè)星期缴啡，一個(gè)月，或者任意一個(gè)時(shí)間段瓷们。另外也會(huì)有較多的層次維度盟猖，比如組織架構(gòu)從最上面的大區(qū)一直到下面的蜂窩，就是一個(gè)典型的層次維度换棚。
從指標(biāo)的角度來(lái)講式镐，一般情況下指標(biāo)個(gè)數(shù)在50個(gè)以?xún)?nèi)，相對(duì)來(lái)說(shuō)Kylin在指標(biāo)上的限制并沒(méi)有那么嚴(yán)格固蚤，都能滿(mǎn)足需求娘汞。其中有比較多的表達(dá)式指標(biāo)，在Kylin里面聚合函數(shù)的參數(shù)只能是單獨(dú)的一列夕玩，像sum(if…)這種就不能支持你弦，因此需要一些特別的解決方法。另外一個(gè)非常重要的問(wèn)題是數(shù)據(jù)的精確性燎孟，目前在OLAP領(lǐng)域禽作，各個(gè)系統(tǒng)都是用hyperloglog等近似算法做去重計(jì)數(shù)，這主要是出于開(kāi)銷(xiāo)上的考慮揩页，但我們的業(yè)務(wù)場(chǎng)景要求數(shù)據(jù)必須是精確的旷偿。因此這也是要重點(diǎn)解決的問(wèn)題。
在查詢(xún)上也有比較高的要求爆侣。因?yàn)槠脚_(tái)的查詢(xún)服務(wù)可能直接向城市BD開(kāi)放萍程，每次會(huì)有幾十、上百萬(wàn)次的訪問(wèn)兔仰，所以穩(wěn)定性是首先要保證的茫负。第二要求有很高的性能。因?yàn)橛肒ylin主要是為了實(shí)現(xiàn)交互式的分析乎赴，讓使用者能夠很快拿到結(jié)果忍法，所以需要秒級(jí)響應(yīng)。
另外經(jīng)常會(huì)有人問(wèn)到榕吼，Kylin有沒(méi)有可視化的前端饿序，在我們內(nèi)部更多是由業(yè)務(wù)方來(lái)做，因?yàn)樵瓉?lái)本身就有這樣的系統(tǒng)友题，以前接的是MySQL等其它的數(shù)據(jù)源嗤堰，現(xiàn)在可以直接使用Kylin的JDBC driver對(duì)接起來(lái)。
以上是美團(tuán)在OLAP查詢(xún)方面的一些特點(diǎn)。在用Kylin之前踢匣，實(shí)際上有一些方案告匠，但效果并不理想。
比如用Hive直接去查离唬，這種情況下后专，第一個(gè)是慢，第二會(huì)消耗計(jì)算集群的資源输莺。尤其每個(gè)月第一天戚哎，大家都要出月報(bào)，跑的SQL非常多嫂用，全提到集群上去型凳，并發(fā)度限制導(dǎo)致跑的比平時(shí)更慢。
我們?cè)瓉?lái)也做過(guò)預(yù)聚合的嘗試嘱函，這個(gè)思路跟Kylin很像甘畅，只不過(guò)是自己做這個(gè)事，用Hive先把所有的維度算出來(lái)往弓，然后導(dǎo)入MySQL或者HBase疏唾。但是這個(gè)方案并沒(méi)有像Kylin這么好的模型定義抽象，也沒(méi)有從配置到執(zhí)行函似，預(yù)計(jì)算槐脏，查詢(xún)這樣整體的框架。現(xiàn)在通過(guò)使用Kylin實(shí)現(xiàn)了低成本的解決這些問(wèn)題撇寞。
接入Apache Kylin的解決方案
針對(duì)上述的問(wèn)題顿天，經(jīng)過(guò)大量的嘗試和驗(yàn)證，目前主要的解決方案有以下幾點(diǎn)重抖。最重要的第一點(diǎn)露氮，就是采用寬表祖灰。所有非標(biāo)準(zhǔn)星型的數(shù)據(jù)模型钟沛，都可以通過(guò)預(yù)處理先拉平，做成一個(gè)寬表來(lái)解決局扶。只要能根據(jù)業(yè)務(wù)邏輯把這些表關(guān)聯(lián)起來(lái)恨统，生成一張寬表，然后再基于這張表在Kylin里做數(shù)據(jù)的聚合就可以了三妈。寬表不只能解決數(shù)據(jù)模型的問(wèn)題畜埋，還能解決維度變化、或者超高基數(shù)的維度等問(wèn)題畴蒲。
第二點(diǎn)是表達(dá)式指標(biāo)的問(wèn)題悠鞍，也可以通過(guò)提前處理解決。把表達(dá)式單獨(dú)轉(zhuǎn)成一列模燥，再基于這列做聚合就可以了咖祭。實(shí)際上寬表和表達(dá)式變換的處理可以用hive的view掩宜，也可以生成物理表。
第三個(gè)是精確去重的問(wèn)題么翰，目前的方案是基于Bitmap牺汤。由于數(shù)據(jù)類(lèi)型的限制，目前只支持int類(lèi)型浩嫌，其它包括long檐迟、string等類(lèi)型還不支持。因?yàn)樾枰衙總€(gè)值都能映射到Bitmap里,如果是long的話開(kāi)銷(xiāo)太大码耐。如果用哈希的話就會(huì)沖突追迟，造成結(jié)果不準(zhǔn)確。另外Bitmap本身開(kāi)銷(xiāo)也是比較大的骚腥，尤其跑預(yù)計(jì)算的時(shí)候怔匣，如果算出來(lái)的基數(shù)很大，對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)就是幾十兆桦沉，內(nèi)存會(huì)有OOM的風(fēng)險(xiǎn)每瞒。這些問(wèn)題后面我們也會(huì)想一些辦法解決，也歡迎在社區(qū)里一起討論纯露。（補(bǔ)充說(shuō)明：目前已在1.5.3版本中實(shí)現(xiàn)了全類(lèi)型精確去重計(jì)數(shù)的支持剿骨。）
從整個(gè)系統(tǒng)的部署方式上來(lái)說(shuō)，目前Server采用了分離部署的方式埠褪。Kylin Server本質(zhì)上就是一個(gè)客戶(hù)端浓利，并不需要太多資源，一般情況下使用虛擬機(jī)就能夠滿(mǎn)足需求钞速。
實(shí)際的部署情況可以看這張圖贷掖，左下角的是hadoop主集群，用于執(zhí)行每天所有hadoop作業(yè)渴语。中間最重要的是Kylin01和02這兩個(gè)server苹威，是用于線上環(huán)境的serve。其中kylin01是生產(chǎn)環(huán)境驾凶，這個(gè)環(huán)境一方面要負(fù)責(zé)從主機(jī)群上跑計(jì)算牙甫，把數(shù)據(jù)導(dǎo)到HBase，另外也要響應(yīng)前端的請(qǐng)求调违，從HBase里讀數(shù)據(jù)窟哺。如果想新增一個(gè)Cube的話，需要在kylin02上操作技肩，也就是預(yù)上線環(huán)境且轨。所有業(yè)務(wù)方人員的cube數(shù)據(jù)模型定義都是在kylin02上做，沒(méi)有問(wèn)題后由管理員切到kylin01上。
這樣做的一個(gè)好處是kylin01作為一個(gè)線上服務(wù)能保證穩(wěn)定性旋奢，甚至權(quán)限控制能更嚴(yán)格一些阿蝶；第二，預(yù)上線環(huán)境下開(kāi)發(fā)完成后黄绩，管理員可以在投入生產(chǎn)前進(jìn)行一次review羡洁，保證cube的效率。
右上角是另外的調(diào)度系統(tǒng)爽丹。整個(gè)數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)生產(chǎn)都是通過(guò)這個(gè)調(diào)度系統(tǒng)來(lái)調(diào)度的筑煮，其中的任務(wù)類(lèi)型很多，Kylin的cube build任務(wù)也是作為其中的一種類(lèi)型粤蝎。在上游的數(shù)據(jù)就緒以后真仲，根據(jù)配置的依賴(lài)關(guān)系，自動(dòng)觸發(fā)Cube建立的過(guò)程初澎。
左上角這邊還有一個(gè)完全獨(dú)立的線下測(cè)試集群秸应，這個(gè)集群是完全開(kāi)放的，主要是給用戶(hù)做一些最開(kāi)始的可行性調(diào)研或者評(píng)估的工作碑宴，但同時(shí)也不保證穩(wěn)定性软啼。
一個(gè)開(kāi)源的系統(tǒng)從社區(qū)拿回來(lái)，到真正的落地延柠，再到上生產(chǎn)祸挪，這個(gè)過(guò)程相對(duì)還是比較長(zhǎng)的，這里并沒(méi)有太多的技術(shù)問(wèn)題贞间，更多的是一些流程上的經(jīng)驗(yàn)贿条。就是如何在各個(gè)階段給業(yè)務(wù)方提供更好的服務(wù)，使得接入Kylin的過(guò)程更順暢增热，溝通成本更低整以。整個(gè)過(guò)程主要分為四個(gè)階段。
第一個(gè)階段是方案選型峻仇，業(yè)務(wù)方根據(jù)業(yè)務(wù)需求公黑，選擇一些方案進(jìn)行調(diào)研。我們?cè)谶@個(gè)階段提供了需求的Checklist础浮，從數(shù)據(jù)模型帆调，維度各個(gè)方面列出來(lái)比較詳細(xì)的點(diǎn)，可以讓業(yè)務(wù)方自己對(duì)照豆同，確定需求是不是能夠被滿(mǎn)足。
在確定Kylin能滿(mǎn)足需求的基礎(chǔ)上含鳞，接下來(lái)是第二步影锈，線下探查，也就是線下評(píng)估或者測(cè)試。我們提供了非常詳細(xì)的接入文檔鸭廷，以及線下測(cè)試的環(huán)境枣抱。
第三步是線上開(kāi)發(fā)，我們也有一些文檔支持辆床，基于抽象出來(lái)的場(chǎng)景佳晶，每個(gè)場(chǎng)景怎么配置Cube，或者做哪些預(yù)處理讼载，如何優(yōu)化等轿秧，能夠給業(yè)務(wù)方一個(gè)指導(dǎo)性的意見(jiàn)。
最后是開(kāi)發(fā)完成后的切表上線咨堤。這個(gè)過(guò)程目前還是由管理員來(lái)操作菇篡，一方面是為了避免誤操作或者濫操作，另一方面也會(huì)對(duì)cube進(jìn)行review一喘，幫助進(jìn)行優(yōu)化驱还。
主流OLAP系統(tǒng)對(duì)比分析
通過(guò)和其它同學(xué)交流，有一個(gè)感覺(jué)就是大家都覺(jué)得Kylin還不錯(cuò)凸克，但并不是特別有信心议蟆，或者不知道非要用它的理由是什么，或者它和其它系統(tǒng)的對(duì)比是什么樣的萎战？這里也有部分測(cè)試結(jié)果可以和大家分享咪鲜。
整個(gè)測(cè)試基于SSB的數(shù)據(jù)集，也是完全開(kāi)源的撞鹉，實(shí)際上是專(zhuān)門(mén)用于星型模型OLAP場(chǎng)景下的測(cè)試疟丙。整個(gè)測(cè)試數(shù)據(jù)集是非常標(biāo)準(zhǔn)的五張表，可以配置一些參數(shù)決定生成的數(shù)據(jù)集規(guī)模鸟雏，然后在不同的規(guī)模下做不同查詢(xún)場(chǎng)景的測(cè)試∠斫迹現(xiàn)在已經(jīng)完成的測(cè)試的系統(tǒng)包括：Presto，Kylin1.3孝鹊，Kylin1.5和Druid炊琉。數(shù)據(jù)規(guī)模包含千萬(wàn)、億又活、十億三種規(guī)模苔咪；維度個(gè)數(shù)為30個(gè)；指標(biāo)個(gè)數(shù)為50個(gè)柳骄。典型的測(cè)試場(chǎng)景包括：上卷团赏、下鉆，和常用的聚合函數(shù)耐薯。
這里挑選了典型的五個(gè)查詢(xún)場(chǎng)景：一個(gè)事實(shí)表的過(guò)濾和聚合舔清；五張表全關(guān)聯(lián)之后的查詢(xún)丝里；兩個(gè)Count Dstinct指標(biāo)和兩個(gè)Sum指標(biāo)；后面兩個(gè)查詢(xún)包含8~10個(gè)的維度過(guò)濾体谒。
這張圖是千萬(wàn)規(guī)模下的一個(gè)測(cè)試結(jié)果杯聚，包括了四個(gè)系統(tǒng)。我們?cè)谟肒ylin或者其它系統(tǒng)之前沒(méi)有專(zhuān)門(mén)用于OLAP分析的引擎抒痒，只能用通用的幌绍。Presto是其中表現(xiàn)非常好的引擎，但是在OLAP這種特定的場(chǎng)景下故响，可以看到不管跟Kylin還是Druid相比差的都比較多傀广，所以前兩個(gè)測(cè)試包含了Presto結(jié)果，后面就沒(méi)有包含了
這里比較有趣的現(xiàn)象是在第三個(gè)查詢(xún)被去，Kylin1.5反而比Kylin1.3要慢一些主儡。這個(gè)地方我們還沒(méi)有搞清楚是什么原因，后面會(huì)詳細(xì)的看一下惨缆。當(dāng)然這個(gè)也可以證明數(shù)據(jù)沒(méi)有修改過(guò)糜值，是真實(shí)的測(cè)試數(shù)據(jù)。
從后面的兩個(gè)查詢(xún)上可以看到坯墨，在千萬(wàn)規(guī)模的級(jí)別寂汇，和Druid還是有比較大的差距。這主要和它們的實(shí)現(xiàn)模式相關(guān)捣染，因?yàn)镈ruid會(huì)把所有的數(shù)據(jù)預(yù)處理完以后都加載到內(nèi)存里骄瓣，在做一些小數(shù)據(jù)量聚合的時(shí)候，可以達(dá)到非乘Ｈ粒快的速度榕栏；但是Kylin要到HBase上讀，相對(duì)來(lái)說(shuō)它的性能要差一些蕾各，但也完全能滿(mǎn)足需求扒磁。
在億級(jí)的規(guī)模上情況又有了變化，還是看后面兩個(gè)查詢(xún)式曲，Kylin1.3基本上是一個(gè)線性的增長(zhǎng)妨托，這個(gè)數(shù)據(jù)已經(jīng)變得比較難看了，這是由于Kylin1.3在掃描HBase的時(shí)候是串行方式吝羞，但是Kylin1.5反而會(huì)有更好的表現(xiàn)兰伤，這是因?yàn)镵ylin1.5引入了HBase并行Scan，大大降低了掃描的時(shí)間钧排。Kylin1.5的數(shù)據(jù)會(huì)shard到不同的region上敦腔，在千萬(wàn)量級(jí)上數(shù)據(jù)量還比較小，沒(méi)有明顯的體現(xiàn)卖氨，但是上億以后会烙，隨著數(shù)據(jù)量上升负懦，region也變多了筒捺，反而能把并發(fā)度提上去柏腻。所以在這里可以看到Kylin1.5表現(xiàn)會(huì)更好。這里也可以看出系吭，在數(shù)據(jù)量成數(shù)量級(jí)上升后五嫂，Kylin表現(xiàn)的更加穩(wěn)定，在不同規(guī)模數(shù)據(jù)集上依然可以保持不錯(cuò)的查詢(xún)性能肯尺。而Druid隨著數(shù)據(jù)量的增長(zhǎng)性能損失也成倍增長(zhǎng)沃缘。
剛才是在性能方面做的一些分析，其實(shí)對(duì)于一個(gè)系統(tǒng)來(lái)說(shuō)则吟，性能只是一個(gè)方面槐臀，除此之外，我們也會(huì)去考量其它方面的情況氓仲，主要有以下四點(diǎn)水慨。
第一，功能的完備性敬扛。剛才提到我們所有的數(shù)據(jù)必須是精確的晰洒，但是現(xiàn)在基本上沒(méi)有哪個(gè)系統(tǒng)能完全覆蓋我們這個(gè)需求。比如Druid性能表現(xiàn)確實(shí)更好啥箭，但是它去重計(jì)數(shù)沒(méi)有辦法做到精確谍珊。
第二，系統(tǒng)的易用性急侥。作為一個(gè)平臺(tái)服務(wù)砌滞，不僅要把系統(tǒng)用起來(lái)，還要維護(hù)它坏怪，因此要考慮部署和監(jiān)控的成本贝润。這方面Kylin相對(duì)來(lái)說(shuō)也是比較好的。Druid一個(gè)集群的角色是非常多的陕悬，如果要把這個(gè)系統(tǒng)用起來(lái)的話题暖，可能光搭這個(gè)環(huán)境，起這些服務(wù)都要很長(zhǎng)的時(shí)間捉超。這個(gè)對(duì)于我們做平臺(tái)來(lái)講胧卤，實(shí)際上是一個(gè)比較痛的事。不管是在部署拼岳，還是加監(jiān)控的時(shí)候枝誊，成本都是相對(duì)比較高的。另外一個(gè)查詢(xún)接口方面惜纸，我們最熟悉或者最標(biāo)準(zhǔn)叶撒，最好用的當(dāng)然是標(biāo)準(zhǔn)SQL的接口绝骚。ES、Druid這些系統(tǒng)原來(lái)都不支持SQL祠够，當(dāng)然現(xiàn)在也有一些插件压汪，但是在功能的完備性和數(shù)據(jù)的效率上都不如原生的支持。
第三古瓤，數(shù)據(jù)成本止剖。剛才提到了有些數(shù)據(jù)需要做一些預(yù)處理，比如表的拉平或者表達(dá)式列的變換落君，除此之外還有一些格式的轉(zhuǎn)化穿香，比如有的系統(tǒng)只能讀TEXT格式，這樣都會(huì)帶來(lái)數(shù)據(jù)準(zhǔn)備的成本绎速。另一方面是數(shù)據(jù)導(dǎo)入的效率皮获。從數(shù)據(jù)進(jìn)入數(shù)據(jù)倉(cāng)庫(kù)到真正能夠被查詢(xún)，這個(gè)時(shí)間中間有多長(zhǎng)纹冤。數(shù)據(jù)存儲(chǔ)和服務(wù)的時(shí)候需要多少機(jī)器資源洒宝，這個(gè)都可以歸為數(shù)據(jù)成本，就是使用這個(gè)數(shù)據(jù)需要付出的成本赵哲。
第四待德，查詢(xún)靈活性。經(jīng)常有業(yè)務(wù)方問(wèn)到枫夺，如果Cube沒(méi)定義的話怎么辦将宪？現(xiàn)在當(dāng)然查詢(xún)只能失敗。這個(gè)說(shuō)明有的查詢(xún)模式不是那么固定的橡庞，可能突然要查一個(gè)數(shù)较坛，但以后都不會(huì)再查了。實(shí)際上在需要預(yù)定義的OLAP引擎上扒最，這種需求普遍來(lái)講支持都不是太好丑勤。
這張圖是各個(gè)系統(tǒng)全方位的一個(gè)對(duì)比。
從查詢(xún)效率上看吧趣，這里表現(xiàn)最不好的就是Presto法竞，表現(xiàn)最好的應(yīng)該是Druid和Kylin1.5，兩者不相上下强挫。從功能完備性上來(lái)講岔霸，確實(shí)Presto語(yǔ)法和UDF等等是很完備的，Kylin會(huì)稍微差一些俯渤，但比Druid好一點(diǎn)呆细。
系統(tǒng)易用性上區(qū)別不是太大，這里主要考慮有沒(méi)有標(biāo)準(zhǔn)的SQL接口或者部署成本高不高八匠，用戶(hù)上手能不能更快絮爷，目前來(lái)看Druid接口上確實(shí)不夠友好趴酣，需要去翻它的文檔才知道怎么去寫(xiě)查詢(xún)的語(yǔ)法。
在查詢(xún)成本上坑夯，Presto是最好的岖寞，因?yàn)閹缀醪恍枰鍪裁刺厥獾奶幚恚旧螲ive能讀的數(shù)據(jù)Presto也都能讀渊涝，所以這個(gè)成本非常低慎璧。Druid和Kylin的成本相對(duì)較高床嫌，因?yàn)槎夹枰崆暗念A(yù)計(jì)算跨释，尤其是Kylin如果維度數(shù)特別多，而且不做特別優(yōu)化的話厌处，數(shù)據(jù)量還是很可觀的鳖谈。
最后從靈活性上來(lái)講， Presto只要SQL寫(xiě)出來(lái)怎么查都可以阔涉，Druid和Kylin都要做一些預(yù)先模型定義的工作缆娃。這方面也可以作為大家選型時(shí)候的參考。
剛才比較客觀的對(duì)比了幾個(gè)系統(tǒng)瑰排，接下來(lái)再總結(jié)一下Kylin的優(yōu)勢(shì)贯要。
第一，性能非常穩(wěn)定椭住。因?yàn)镵ylin依賴(lài)的所有服務(wù)崇渗，比如Hive、HBase都是非常成熟的京郑，Kylin本身的邏輯并不復(fù)雜宅广，所以穩(wěn)定性有一個(gè)很好的保證。目前在我們的生產(chǎn)環(huán)境中些举，穩(wěn)定性可以保證在99.99%以上跟狱。同時(shí)查詢(xún)時(shí)延也比較理想。我們現(xiàn)在有一個(gè)業(yè)務(wù)線需求户魏，每天查詢(xún)量在兩萬(wàn)次以上驶臊，95%的時(shí)延低于1秒，99%在3秒以?xún)?nèi)叼丑」佤幔基本上能滿(mǎn)足我們交互式分析的需求。
第二幢码，對(duì)我們特別重要的一點(diǎn)笤休，就是數(shù)據(jù)的精確性要求。其實(shí)現(xiàn)在能做到的只有Kylin症副，所以說(shuō)我們也沒(méi)有什么太多其他的選擇店雅。
第三政基，從易用性上來(lái)講，Kylin也有非常多的特點(diǎn)闹啦。首先是外圍的服務(wù)沮明，不管是Hive還是HBase，只要大家用Hadoop系統(tǒng)的話基本都有了窍奋，不需要額外工作荐健。在部署運(yùn)維和使用成本上來(lái)講，都是比較低的琳袄。其次江场，有一個(gè)公共的Web頁(yè)面來(lái)做模型的配置。相比之下Druid現(xiàn)在還是基于配置文件來(lái)做窖逗。這里就有一個(gè)問(wèn)題址否，配置文件一般都是平臺(tái)方或者管理員來(lái)管理的，沒(méi)辦法把這個(gè)配置系統(tǒng)開(kāi)放出去碎紊，這樣在溝通成本和響應(yīng)效率上都不夠理想佑附。Kylin有一個(gè)通用的Web Server開(kāi)放出來(lái)，所有用戶(hù)都可以去測(cè)試和定義仗考，只有上線的時(shí)候需要管理員再review一下音同，這樣體驗(yàn)就會(huì)好很多。
第四秃嗜，最后一點(diǎn)就是活躍開(kāi)放的社區(qū)和熱心的核心開(kāi)發(fā)者團(tuán)隊(duì)权均，社區(qū)里討論非常開(kāi)放，大家可以提自己的意見(jiàn)及patch痪寻，修復(fù)bug以及提交新的功能等螺句，包括我們美團(tuán)團(tuán)隊(duì)也貢獻(xiàn)了很多特性，比如寫(xiě)入不同的HBase集群等橡类。這里特別要指出的是核心團(tuán)隊(duì)都是中國(guó)人蛇尚，這是Apache所有項(xiàng)目里唯一中國(guó)人為主的頂級(jí)項(xiàng)目，社區(qū)非彻嘶活躍和熱心取劫，有非常多的中國(guó)工程師。特別是當(dāng)你貢獻(xiàn)越來(lái)越多的時(shí)候研侣，社區(qū)會(huì)邀請(qǐng)成為committer等谱邪，包括我自己及團(tuán)隊(duì)成員也已經(jīng)是Apache Kylin的committer。同時(shí)也非常高興看到以韓卿為首的Apache Kylin核心團(tuán)隊(duì)在今年初成立的創(chuàng)業(yè)公司Kyligence庶诡，相信可以為整個(gè)項(xiàng)目及社區(qū)的發(fā)展帶來(lái)更大的空間和未來(lái)惦银。
未來(lái)工作
在未來(lái)工作方面，我們認(rèn)為Kylin還有一些不理想的方面，我們也會(huì)著力去做優(yōu)化和改進(jìn)扯俱。
第一书蚪，精確去重計(jì)數(shù)。剛才提到只支持Int迅栅，接下來(lái)有一個(gè)方案會(huì)支持所有的數(shù)據(jù)類(lèi)型殊校，能夠擴(kuò)展大家使用精確去重的場(chǎng)景范圍（補(bǔ)充說(shuō)明：目前該功能已在1.5.3版本中實(shí)現(xiàn)）。
第二读存，在查詢(xún)效率和Build效率上也看到了一些可以?xún)?yōu)化的部分为流。比如隊(duì)列資源拆分，我們所有計(jì)算集群的資源都是按照業(yè)務(wù)線核算成本的让簿，但是現(xiàn)在Kylin本身還不太支持敬察，這個(gè)我們也會(huì)抓緊去做，相信在很多公司也有類(lèi)似的需求拜英。還有大結(jié)果集和分頁(yè)静汤。當(dāng)結(jié)果到了上百萬(wàn)的量級(jí)時(shí)，查詢(xún)時(shí)延會(huì)上升到幾十秒居凶。同時(shí)在查詢(xún)的時(shí)候有可能需要排序并且分頁(yè)，就是把結(jié)果全讀出來(lái)之后藤抡，根據(jù)其中的一個(gè)指標(biāo)再order by侠碧，這個(gè)開(kāi)銷(xiāo)也是比較大的。我們也會(huì)想辦法進(jìn)行優(yōu)化缠黍。
最后弄兜，Kylin1.5之后有明細(xì)數(shù)據(jù)和Streaming特性出來(lái)，后面也會(huì)做這方面的嘗試瓷式。
Q&A
Q1：之前在Build的時(shí)候一直提到成本的問(wèn)題替饿，能給出一個(gè)估計(jì)值嗎，如果一百億的數(shù)據(jù)贸典，需要多少時(shí)間视卢？
孫業(yè)銳：有一個(gè)簡(jiǎn)單數(shù)據(jù)，大概是兩億行數(shù)據(jù)廊驼，維度的話有十四五個(gè)据过，Build時(shí)間不超過(guò)兩個(gè)小時(shí)，Build出來(lái)的數(shù)據(jù)是五六百G妒挎。
Q2：原始值是多大绳锅？
孫業(yè)銳：把這個(gè)數(shù)據(jù)抽出來(lái)之后，就是只參與Build的數(shù)據(jù)壓縮后只有幾個(gè)G酝掩。
Q3：Kerberos認(rèn)證失效的問(wèn)題你們遇到過(guò)沒(méi)有鳞芙？
孫業(yè)銳： Kerberos認(rèn)證完之后，會(huì)在本地臨時(shí)目錄下有一個(gè)ticket問(wèn)題，每天在外部定時(shí)刷新一下就可以了原朝，服務(wù)是不用停的闯割。
主持人：我補(bǔ)充一下我們?yōu)槭裁催x擇SQL接口？Kylin解決的是真正的用戶(hù)面是誰(shuí)竿拆，其實(shí)是業(yè)務(wù)人員和分析人員宙拉，他只會(huì)SQL，幾乎那些人很少說(shuō)再學(xué)個(gè)JAVA丙笋，所以能給他一個(gè)標(biāo)準(zhǔn)的SQL這個(gè)是讓他上船最快的事情谢澈。其實(shí)這就是易用性很重要。
剛才看到了Kylin在千萬(wàn)級(jí)規(guī)模和億級(jí)規(guī)模的表現(xiàn)御板，如果數(shù)據(jù)規(guī)模上到十億锥忿，百億，千億的時(shí)候怠肋，我相信Kylin應(yīng)該會(huì)秒殺所有一切敬鬓。因?yàn)槲覀儸F(xiàn)在有另一個(gè)案例，生產(chǎn)環(huán)境上千億規(guī)模的一張表笙各，可以做到90%查詢(xún)?cè)?.8秒以?xún)?nèi)钉答。另外我覺(jué)得非常好的一點(diǎn)，像美團(tuán)杈抢、京東這邊貢獻(xiàn)了很多patch数尿，其實(shí)就是把需求提出來(lái)，大家可以一起來(lái)做惶楼。
作者介紹：孫業(yè)銳右蹦，美團(tuán)高級(jí)工程師，Apache Kylin Committer歼捐。2012年畢業(yè)于電子科技大學(xué)何陆，曾在奇虎360工作，負(fù)責(zé)Hadoop平臺(tái)建設(shè)豹储，2015年加入美團(tuán)贷盲。目前主要負(fù)責(zé)數(shù)據(jù)生產(chǎn)和查詢(xún)引擎的改進(jìn)和優(yōu)化，專(zhuān)注于分布式計(jì)算颂翼，OLAP分析等領(lǐng)域晃洒，對(duì)分布式存儲(chǔ)系統(tǒng)亦有豐富經(jīng)驗(yàn)。
