美團(tuán)各業(yè)務(wù)線存在大量的OLAP分析場景，需要基于Hadoop數(shù)十億級別的數(shù)據(jù)進(jìn)行分析泻拦，直接響應(yīng)分析師和城市BD等數(shù)千人的交互式訪問請求争拐，對OLAP服務(wù)的擴(kuò)展性架曹、穩(wěn)定性绑雄、數(shù)據(jù)精確性和性能均有很高要求万牺。本文主要介紹美團(tuán)的具體OLAP需求杏愤，如何將Kylin應(yīng)用到實際場景中珊楼，以及目前的使用方式和現(xiàn)狀厕宗。同時也將Kylin和其它系統(tǒng)（如Presto、Druid等）進(jìn)行了對比曲聂，闡述了Kylin的獨(dú)特優(yōu)勢。
作為公司的平臺部門旭咽，需要給各個業(yè)務(wù)線提供平臺的服務(wù)赌厅，那么如何建設(shè)一個滿足各種需求的公司平臺級OLAP分析服務(wù)呢仲墨。首先目养，一個開源項目在公司真正落地會遇到很多障礙混稽，這主要是由各個業(yè)務(wù)線不同的數(shù)據(jù)特點和業(yè)務(wù)特點決定的，所以本文會介紹一下美團(tuán)的數(shù)據(jù)場景有什么特點膳叨；其次菲嘴，針對這些數(shù)據(jù)特點龄坪，尤其是和Kylin設(shè)計初衷不太相符的部分健田，有什么樣的解決方案妓局；第三好爬，目前OLAP領(lǐng)域還沒有所謂事實上的標(biāo)準(zhǔn)存炮，很多引擎都可以做類似事情尚蝌，比如普通的MPP充尉，Kylin驼侠，或者ES等倒源。這些系統(tǒng)之間的對比情況如何热某，應(yīng)該如何選擇昔馋，我們也有部分測試數(shù)據(jù)可以分享秘遏；最后邦危，簡單討論一下未來準(zhǔn)備在Kylin上做的工作。
1陵且、美團(tuán)的數(shù)據(jù)場景特點
第一個特點是數(shù)據(jù)規(guī)模和模型特點滩报。一方面從數(shù)據(jù)規(guī)模上來講脓钾，事實表一般在1億到10億量級昌妹，同時還有千萬量級的維表飞崖，也就是超高基數(shù)的維表固歪。另一方面牢裳，數(shù)據(jù)模型是一開始遇到的最大困難蒲讯。因為Kylin最初的設(shè)計是基于一個星形模型的判帮，但很不幸由于各種原因晦墙，很多數(shù)據(jù)都是雪花的模型偎痛，還有其它的模型，比如所謂“星座”模型氓癌，也就是中間是兩張或者三張事實表，周圍關(guān)聯(lián)了其它很多維表卢肃。業(yè)務(wù)邏輯決定了這些數(shù)據(jù)的關(guān)聯(lián)方式非常復(fù)雜疲迂，根本無法用經(jīng)典標(biāo)準(zhǔn)的理論來解釋才顿。
第二個是維度。維度最理想的情況是固定的尤蒿，每天變化的只是事實表郑气。但實際上維度經(jīng)常會變，這可能和行業(yè)特點有關(guān)腰池，比如組織架構(gòu)尾组，相關(guān)的維度數(shù)據(jù)可能每天都會變化。除此之外還可能要用今天的維度去關(guān)聯(lián)所有的歷史數(shù)據(jù)，因此要重刷歷史數(shù)據(jù)囱皿，相應(yīng)的開銷也比較大爹橱。
第三個是數(shù)據(jù)回溯的問題组砚。比如發(fā)現(xiàn)數(shù)據(jù)生成有問題柒爸，或者上游出錯了葡公，此時就需要重跑數(shù)據(jù)蛆楞。這也是和經(jīng)典理論模型有區(qū)別的。
從維度的角度來看，一般維度的個數(shù)在5-20個之間蹬癌，相對來說還是比較適合用Kylin的董济。另一個特點是一般都會有一個日期維度，有可能是當(dāng)天，也有可能是一個星期胯杭，一個月顽频，或者任意一個時間段怠惶。另外也會有較多的層次維度逃延，比如組織架構(gòu)從最上面的大區(qū)一直到下面的蜂窩府树，就是一個典型的層次維度。
從指標(biāo)的角度來講牡整，一般情況下指標(biāo)個數(shù)在50個以內(nèi)，相對來說Kylin在指標(biāo)上的限制并沒有那么嚴(yán)格，都能滿足需求。其中有比較多的表達(dá)式指標(biāo)旬盯，在Kylin里面聚合函數(shù)的參數(shù)只能是單獨(dú)的一列，像sum(if…)這種就不能支持碎绎，因此需要一些特別的解決方法嗡综。另外一個非常重要的問題是數(shù)據(jù)的精確性，目前在OLAP領(lǐng)域延都，各個系統(tǒng)都是用hyperloglog等近似算法做去重計數(shù)验夯，這主要是出于開銷上的考慮挥转，但我們的業(yè)務(wù)場景要求數(shù)據(jù)必須是精確的。因此這也是要重點解決的問題挡逼。
在查詢上也有比較高的要求儡遮。因為平臺的查詢服務(wù)可能直接向城市BD開放暗赶，每次會有幾十鄙币、上百萬次的訪問肃叶，所以穩(wěn)定性是首先要保證的。第二要求有很高的性能十嘿。因為用Kylin主要是為了實現(xiàn)交互式的分析因惭，讓使用者能夠很快拿到結(jié)果，所以需要秒級響應(yīng)绩衷。
另外經(jīng)常會有人問到蹦魔，Kylin有沒有可視化的前端，在我們內(nèi)部更多是由業(yè)務(wù)方來做唇聘，因為原來本身就有這樣的系統(tǒng)版姑，以前接的是MySQL等其它的數(shù)據(jù)源，現(xiàn)在可以直接使用Kylin的JDBC driver對接起來迟郎。
以上是美團(tuán)在OLAP查詢方面的一些特點。在用Kylin之前聪蘸，實際上有一些方案宪肖，但效果并不理想。比如用Hive直接去查健爬，這種情況下控乾，第一個是慢，第二會消耗計算集群的資源娜遵。尤其每個月第一天蜕衡，大家都要出月報，跑的SQL非常多设拟，全提到集群上去慨仿，并發(fā)度限制導(dǎo)致跑的比平時更慢。我們原來也做過預(yù)聚合的嘗試纳胧，這個思路跟Kylin很像镰吆，只不過是自己做這個事，用Hive先把所有的維度算出來跑慕，然后導(dǎo)入MySQL或者HBase万皿。但是這個方案并沒有像Kylin這么好的模型定義抽象，也沒有從配置到執(zhí)行核行，預(yù)計算牢硅，查詢這樣整體的框架。現(xiàn)在通過使用Kylin實現(xiàn)了低成本的解決這些問題芝雪。
2减余、接入Apache Kylin的解決方案
針對上述的問題，經(jīng)過大量的嘗試和驗證绵脯，目前主要的解決方案有以下幾點佳励。
最重要的第一點休里，就是采用寬表。所有非標(biāo)準(zhǔn)星型的數(shù)據(jù)模型赃承，都可以通過預(yù)處理先拉平妙黍，做成一個寬表來解決。只要能根據(jù)業(yè)務(wù)邏輯把這些表關(guān)聯(lián)起來，生成一張寬表痹筛，然后再基于這張表在Kylin里做數(shù)據(jù)的聚合就可以了意鲸。寬表不只能解決數(shù)據(jù)模型的問題，還能解決維度變化做粤、或者超高基數(shù)的維度等問題。
第二點是表達(dá)式指標(biāo)的問題捉撮，也可以通過提前處理解決怕品。把表達(dá)式單獨(dú)轉(zhuǎn)成一列，再基于這列做聚合就可以了巾遭。實際上寬表和表達(dá)式變換的處理可以用hive的view肉康，也可以生成物理表。
第三個是精確去重的問題灼舍，目前的方案是基于Bitmap吼和。由于數(shù)據(jù)類型的限制，目前只支持int類型骑素，其它包括long炫乓、string等類型還不支持。因為需要把每個值都能映射到Bitmap里,如果是long的話開銷太大献丑。如果用哈希的話就會沖突末捣，造成結(jié)果不準(zhǔn)確。另外Bitmap本身開銷也是比較大的阳距，尤其跑預(yù)計算的時候塔粒，如果算出來的基數(shù)很大，對應(yīng)的數(shù)據(jù)結(jié)構(gòu)就是幾十兆筐摘，內(nèi)存會有OOM的風(fēng)險卒茬。這些問題后面我們也會想一些辦法解決，也歡迎在社區(qū)里一起討論咖熟。（補(bǔ)充說明：目前已在1.5.3版本中實現(xiàn)了全類型精確去重計數(shù)的支持圃酵。）
從整個系統(tǒng)的部署方式上來說，目前Server采用了分離部署的方式馍管。Kylin Server本質(zhì)上就是一個客戶端郭赐，并不需要太多資源，一般情況下使用虛擬機(jī)就能夠滿足需求确沸。
實際的部署情況可以看這張圖捌锭，左下角的是hadoop主集群俘陷，用于執(zhí)行每天所有hadoop作業(yè)。中間最重要的是Kylin01和02這兩個server观谦，是用于線上環(huán)境的serve拉盾。其中kylin01是生產(chǎn)環(huán)境，這個環(huán)境一方面要負(fù)責(zé)從主機(jī)群上跑計算豁状，把數(shù)據(jù)導(dǎo)到HBase捉偏，另外也要響應(yīng)前端的請求，從HBase里讀數(shù)據(jù)泻红。如果想新增一個Cube的話夭禽，需要在kylin02上操作，也就是預(yù)上線環(huán)境谊路。所有業(yè)務(wù)方人員的cube數(shù)據(jù)模型定義都是在kylin02上做讹躯，沒有問題后由管理員切到kylin01上。
這樣做的一個好處是kylin01作為一個線上服務(wù)能保證穩(wěn)定性缠劝，甚至權(quán)限控制能更嚴(yán)格一些蜀撑；第二，預(yù)上線環(huán)境下開發(fā)完成后剩彬，管理員可以在投入生產(chǎn)前進(jìn)行一次review，保證cube的效率矿卑。
右上角是另外的調(diào)度系統(tǒng)喉恋。整個數(shù)據(jù)倉庫的數(shù)據(jù)生產(chǎn)都是通過這個調(diào)度系統(tǒng)來調(diào)度的，其中的任務(wù)類型很多母廷，Kylin的cube build任務(wù)也是作為其中的一種類型轻黑。在上游的數(shù)據(jù)就緒以后，根據(jù)配置的依賴關(guān)系琴昆，自動觸發(fā)Cube建立的過程氓鄙。
左上角這邊還有一個完全獨(dú)立的線下測試集群，這個集群是完全開放的业舍，主要是給用戶做一些最開始的可行性調(diào)研或者評估的工作抖拦，但同時也不保證穩(wěn)定性。
一個開源的系統(tǒng)從社區(qū)拿回來舷暮，到真正的落地态罪，再到上生產(chǎn)，這個過程相對還是比較長的下面，這里并沒有太多的技術(shù)問題复颈，更多的是一些流程上的經(jīng)驗。就是如何在各個階段給業(yè)務(wù)方提供更好的服務(wù)沥割，使得接入Kylin的過程更順暢耗啦，溝通成本更低凿菩。整個過程主要分為四個階段。
第一個階段是方案選型帜讲，業(yè)務(wù)方根據(jù)業(yè)務(wù)需求衅谷，選擇一些方案進(jìn)行調(diào)研。我們在這個階段提供了需求的Checklist舒帮，從數(shù)據(jù)模型会喝，維度各個方面列出來比較詳細(xì)的點，可以讓業(yè)務(wù)方自己對照玩郊，確定需求是不是能夠被滿足肢执。
在確定Kylin能滿足需求的基礎(chǔ)上，接下來是第二步译红，線下探查预茄，也就是線下評估或者測試。我們提供了非常詳細(xì)的接入文檔侦厚，以及線下測試的環(huán)境耻陕。第三步是線上開發(fā)，我們也有一些文檔支持刨沦，基于抽象出來的場景诗宣，每個場景怎么配置Cube，或者做哪些預(yù)處理想诅，如何優(yōu)化等召庞，能夠給業(yè)務(wù)方一個指導(dǎo)性的意見。
最后是開發(fā)完成后的切表上線来破。這個過程目前還是由管理員來操作篮灼，一方面是為了避免誤操作或者濫操作，另一方面也會對cube進(jìn)行review徘禁，幫助進(jìn)行優(yōu)化诅诱。
3、主流OLAP系統(tǒng)對比分析
通過和其它同學(xué)交流送朱，有一個感覺就是大家都覺得Kylin還不錯娘荡，但并不是特別有信心，或者不知道非要用它的理由是什么骤菠，或者它和其它系統(tǒng)的對比是什么樣的它改？這里也有部分測試結(jié)果可以和大家分享。
整個測試基于SSB的數(shù)據(jù)集商乎，也是完全開源的央拖，實際上是專門用于星型模型OLAP場景下的測試。整個測試數(shù)據(jù)集是非常標(biāo)準(zhǔn)的五張表，可以配置一些參數(shù)決定生成的數(shù)據(jù)集規(guī)模鲜戒，然后在不同的規(guī)模下做不同查詢場景的測試∽兀現(xiàn)在已經(jīng)完成的測試的系統(tǒng)包括：Presto，Kylin1.3遏餐，Kylin1.5和Druid伦腐。數(shù)據(jù)規(guī)模包含千萬、億失都、十億三種規(guī)模柏蘑；維度個數(shù)為30個；指標(biāo)個數(shù)為50個粹庞。典型的測試場景包括：上卷咳焚、下鉆，和常用的聚合函數(shù)庞溜。
這里挑選了典型的五個查詢場景：一個事實表的過濾和聚合革半；五張表全關(guān)聯(lián)之后的查詢；兩個Count Dstinct指標(biāo)和兩個Sum指標(biāo)流码；后面兩個查詢包含8~10個的維度過濾又官。
這張圖是千萬規(guī)模下的一個測試結(jié)果，包括了四個系統(tǒng)漫试。我們在用Kylin或者其它系統(tǒng)之前沒有專門用于OLAP分析的引擎六敬，只能用通用的。Presto是其中表現(xiàn)非常好的引擎驾荣，但是在OLAP這種特定的場景下觉阅，可以看到不管跟Kylin還是Druid相比差的都比較多，所以前兩個測試包含了Presto結(jié)果秘车，后面就沒有包含了。
這里比較有趣的現(xiàn)象是在第三個查詢劫哼，Kylin1.5反而比Kylin1.3要慢一些叮趴。這個地方我們還沒有搞清楚是什么原因，后面會詳細(xì)的看一下权烧。當(dāng)然這個也可以證明數(shù)據(jù)沒有修改過眯亦，是真實的測試數(shù)據(jù)。
從后面的兩個查詢上可以看到般码，在千萬規(guī)模的級別妻率，和Druid還是有比較大的差距。這主要和它們的實現(xiàn)模式相關(guān)板祝，因為Druid會把所有的數(shù)據(jù)預(yù)處理完以后都加載到內(nèi)存里宫静，在做一些小數(shù)據(jù)量聚合的時候，可以達(dá)到非常快的速度孤里；但是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)的易用性苛茂。作為一個平臺服務(wù)，不僅要把系統(tǒng)用起來身害，還要維護(hù)它味悄，因此要考慮部署和監(jiān)控的成本。這方面Kylin相對來說也是比較好的塌鸯。Druid一個集群的角色是非常多的侍瑟，如果要把這個系統(tǒng)用起來的話，可能光搭這個環(huán)境丙猬，起這些服務(wù)都要很長的時間涨颜。這個對于我們做平臺來講，實際上是一個比較痛的事茧球。不管是在部署庭瑰，還是加監(jiān)控的時候，成本都是相對比較高的抢埋。另外一個查詢接口方面弹灭，我們最熟悉或者最標(biāo)準(zhǔn)，最好用的當(dāng)然是標(biāo)準(zhǔn)SQL的接口揪垄。ES穷吮、Druid這些系統(tǒng)原來都不支持SQL，當(dāng)然現(xiàn)在也有一些插件饥努，但是在功能的完備性和數(shù)據(jù)的效率上都不如原生的支持捡鱼。
第三，數(shù)據(jù)成本酷愧。剛才提到了有些數(shù)據(jù)需要做一些預(yù)處理驾诈，比如表的拉平或者表達(dá)式列的變換，除此之外還有一些格式的轉(zhuǎn)化溶浴，比如有的系統(tǒng)只能讀TEXT格式乍迄，這樣都會帶來數(shù)據(jù)準(zhǔn)備的成本。另一方面是數(shù)據(jù)導(dǎo)入的效率士败。從數(shù)據(jù)進(jìn)入數(shù)據(jù)倉庫到真正能夠被查詢就乓，這個時間中間有多長。數(shù)據(jù)存儲和服務(wù)的時候需要多少機(jī)器資源拱烁，這個都可以歸為數(shù)據(jù)成本，就是使用這個數(shù)據(jù)需要付出的成本噩翠。
第四戏自，查詢靈活性。經(jīng)常有業(yè)務(wù)方問到伤锚，如果Cube沒定義的話怎么辦擅笔？現(xiàn)在當(dāng)然查詢只能失敗志衣。這個說明有的查詢模式不是那么固定的，可能突然要查一個數(shù)猛们，但以后都不會再查了念脯。實際上在需要預(yù)定義的OLAP引擎上，這種需求普遍來講支持都不是太好弯淘。
這張圖是各個系統(tǒng)全方位的一個對比绿店。
從查詢效率上看，這里表現(xiàn)最不好的就是Presto庐橙，表現(xiàn)最好的應(yīng)該是Druid和Kylin1.5假勿，兩者不相上下。從功能完備性上來講态鳖，確實Presto語法和UDF等等是很完備的转培，Kylin會稍微差一些，但比Druid好一點浆竭。
系統(tǒng)易用性上區(qū)別不是太大浸须，這里主要考慮有沒有標(biāo)準(zhǔn)的SQL接口或者部署成本高不高，用戶上手能不能更快邦泄，目前來看Druid接口上確實不夠友好删窒，需要去翻它的文檔才知道怎么去寫查詢的語法。
在查詢成本上虎韵，Presto是最好的易稠，因為幾乎不需要做什么特殊的處理，基本上Hive能讀的數(shù)據(jù)Presto也都能讀包蓝，所以這個成本非常低驶社。Druid和Kylin的成本相對較高，因為都需要提前的預(yù)計算测萎，尤其是Kylin如果維度數(shù)特別多亡电，而且不做特別優(yōu)化的話，數(shù)據(jù)量還是很可觀的硅瞧。
最后從靈活性上來講份乒， Presto只要SQL寫出來怎么查都可以，Druid和Kylin都要做一些預(yù)先模型定義的工作腕唧。這方面也可以作為大家選型時候的參考或辖。
剛才比較客觀的對比了幾個系統(tǒng)，接下來再總結(jié)一下Kylin的優(yōu)勢枣接。
第一颂暇，性能非常穩(wěn)定。因為Kylin依賴的所有服務(wù)但惶，比如Hive耳鸯、HBase都是非常成熟的湿蛔，Kylin本身的邏輯并不復(fù)雜，所以穩(wěn)定性有一個很好的保證县爬。目前在我們的生產(chǎn)環(huán)境中阳啥，穩(wěn)定性可以保證在99.99%以上。同時查詢時延也比較理想财喳。我們現(xiàn)在有一個業(yè)務(wù)線需求察迟，每天查詢量在兩萬次以上，95%的時延低于1秒纲缓，99%在3秒以內(nèi)卷拘。基本上能滿足我們交互式分析的需求祝高。
第二栗弟，對我們特別重要的一點，就是數(shù)據(jù)的精確性要求工闺。其實現(xiàn)在能做到的只有Kylin乍赫，所以說我們也沒有什么太多其他的選擇。
第三陆蟆，從易用性上來講雷厂，Kylin也有非常多的特點。首先是外圍的服務(wù)叠殷，不管是Hive還是HBase改鲫，只要大家用Hadoop系統(tǒng)的話基本都有了，不需要額外工作林束。在部署運(yùn)維和使用成本上來講像棘，都是比較低的。其次壶冒，有一個公共的Web頁面來做模型的配置缕题。相比之下Druid現(xiàn)在還是基于配置文件來做。這里就有一個問題胖腾，配置文件一般都是平臺方或者管理員來管理的烟零，沒辦法把這個配置系統(tǒng)開放出去，這樣在溝通成本和響應(yīng)效率上都不夠理想咸作。Kylin有一個通用的Web Server開放出來锨阿，所有用戶都可以去測試和定義，只有上線的時候需要管理員再review一下记罚，這樣體驗就會好很多墅诡。
第四，最后一點就是活躍開放的社區(qū)和熱心的核心開發(fā)者團(tuán)隊毫胜，社區(qū)里討論非常開放书斜，大家可以提自己的意見及patch，修復(fù)bug以及提交新的功能等酵使，包括我們美團(tuán)團(tuán)隊也貢獻(xiàn)了很多特性荐吉，比如寫入不同的HBase集群等。這里特別要指出的是核心團(tuán)隊都是中國人口渔，這是Apache所有項目里唯一中國人為主的頂級項目样屠，社區(qū)非常活躍和熱心缺脉，有非常多的中國工程師痪欲。特別是當(dāng)你貢獻(xiàn)越來越多的時候，社區(qū)會邀請成為committer等攻礼，包括我自己及團(tuán)隊成員也已經(jīng)是Apache Kylin的committer业踢。同時也非常高興看到以韓卿為首的Apache Kylin核心團(tuán)隊在今年初成立的創(chuàng)業(yè)公司Kyligence，相信可以為整個項目及社區(qū)的發(fā)展帶來更大的空間和未來礁扮。
4知举、未來工作
在未來工作方面，我們認(rèn)為Kylin還有一些不理想的方面太伊，我們也會著力去做優(yōu)化和改進(jìn)雇锡。
第一，精確去重計數(shù)僚焦。剛才提到只支持Int锰提，接下來有一個方案會支持所有的數(shù)據(jù)類型，能夠擴(kuò)展大家使用精確去重的場景范圍（補(bǔ)充說明：目前該功能已在1.5.3版本中實現(xiàn)）芳悲。
第二立肘，在查詢效率和Build效率上也看到了一些可以優(yōu)化的部分。比如隊列資源拆分芭概，我們所有計算集群的資源都是按照業(yè)務(wù)線核算成本的赛不，但是現(xiàn)在Kylin本身還不太支持，這個我們也會抓緊去做罢洲，相信在很多公司也有類似的需求踢故。還有大結(jié)果集和分頁。當(dāng)結(jié)果到了上百萬的量級時惹苗，查詢時延會上升到幾十秒殿较。同時在查詢的時候有可能需要排序并且分頁，就是把結(jié)果全讀出來之后桩蓉，根據(jù)其中的一個指標(biāo)再order by淋纲，這個開銷也是比較大的。我們也會想辦法進(jìn)行優(yōu)化院究。
最后洽瞬，Kylin1.5之后有明細(xì)數(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認(rèn)證失效的問題你們遇到過沒有醒串？
孫業(yè)銳： Kerberos認(rèn)證完之后，會在本地臨時目錄下有一個ticket問題鄙皇，每天在外部定時刷新一下就可以了芜赌，服務(wù)是不用停的。
主持人：我補(bǔ)充一下我們?yōu)槭裁催x擇SQL接口伴逸？Kylin解決的是真正的用戶面是誰缠沈，其實是業(yè)務(wù)人員和分析人員，他只會SQL错蝴，幾乎那些人很少說再學(xué)個JAVA洲愤，所以能給他一個標(biāo)準(zhǔn)的SQL這個是讓他上船最快的事情。其實這就是易用性很重要顷锰。
剛才看到了Kylin在千萬級規(guī)模和億級規(guī)模的表現(xiàn)柬赐，如果數(shù)據(jù)規(guī)模上到十億，百億官紫，千億的時候肛宋，我相信Kylin應(yīng)該會秒殺所有一切。因為我們現(xiàn)在有另一個案例束世，生產(chǎn)環(huán)境上千億規(guī)模的一張表酝陈，可以做到90%查詢在1.8秒以內(nèi)。另外我覺得非常好的一點毁涉，像美團(tuán)沉帮、京東這邊貢獻(xiàn)了很多patch，其實就是把需求提出來，大家可以一起來做穆壕。
作者介紹
孫業(yè)銳待牵，美團(tuán)高級工程師，Apache Kylin Committer喇勋。2012年畢業(yè)于電子科技大學(xué)洲敢，曾在奇虎360工作，負(fù)責(zé)Hadoop平臺建設(shè)茄蚯，2015年加入美團(tuán)。目前主要負(fù)責(zé)數(shù)據(jù)生產(chǎn)和查詢引擎的改進(jìn)和優(yōu)化睦优，專注于分布式計算渗常，OLAP分析等領(lǐng)域，對分布式存儲系統(tǒng)亦有豐富經(jīng)驗汗盘。
