本文原載自大數據雜談微信公衆號。
感謝美團點評工程師高大月撰文並受權轉載。
高大月，美團點評工程師，Apache Kylin PMC成員，目前主要在美團點評數據平臺負責OLAP查詢引擎的建設。
背景
美團點評的OLAP需求大致分爲兩類：微信
即席查詢：指用戶經過手寫SQL來完成一些臨時的數據分析需求。這類需求的SQL形式多變、邏輯複雜，對響應時間沒有嚴格的要求。架構
固化查詢：指對一些固化下來的取數、看數的需求，經過數據產品的形式提供給用戶，從而提升數據分析和運營的效率。這類需求的SQL有固定的模式，對響應時間有比較高的要求 。負載均衡
咱們針對即席查詢提供了Hive和Presto兩個引擎。而固化查詢因爲須要秒級響應，很長一段時間都是經過先在數倉對數據作預聚合，再將聚合表導入MySQL提供查詢實現的。可是隨着公司業務數據量和複雜度的不斷提高，從2015年開始，這個方案出現了三個比較突出的問題：框架
隨着維度的不斷增長，在數倉中維護各類維度組合的聚合表的成本愈來愈高，數據開發效率明顯降低;性能
數據量超過千萬行後，MySQL的導入和查詢變得很是慢，常常把MySQL搞崩，DBA的抱怨很大;大數據
因爲大數據平臺缺少更高效率的查詢引擎，查詢需求都跑在Hive/Presto上，致使集羣的計算壓力大，跟不上業務需求的增加。ui
爲了解決這些痛點，咱們在2015年底開始調研更高效率的OLAP引擎，尋找固化查詢場景的解決方案。搜索引擎
爲何選擇Kylin
在調研了市面上主流的開源OLAP引擎後，咱們發現，目前尚未一個系統可以知足各類場景的查詢需求。其本質緣由是，沒有一個系統能同時在數據量、性能、和靈活性三個方面作到完美，每一個系統在設計時都須要在這三者間作出取捨。設計
例如:rest
MPP架構的系統（Presto/Impala/SparkSQL/Drill等）有很好的數據量和靈活性支持，可是對響應時間是沒有保證的。當數據量和計算複雜度增長後，響應時間會變慢，從秒級到分鐘級，甚至小時級都有可能。
搜索引擎架構的系統（Elasticsearch等）相對比MPP系統，在入庫時將數據轉換爲倒排索引，採用Scatter-Gather計算模型，犧牲了靈活性換取很好的性能，在搜索類查詢上能作到亞秒級響應。可是對於掃描聚合爲主的查詢，隨着處理數據量的增長，響應時間也會退化到分鐘級。
預計算系統（Druid/Kylin等）則在入庫時對數據進行預聚合，進一步犧牲靈活性換取性能，以實現對超大數據集的秒級響應。
有了這套框架，咱們不難結合美團點評的自身需求特色，選擇合適的OLAP引擎。
能夠看出，咱們對數據量和性能的要求是比較高的。MPP和搜索引擎系統沒法知足超大數據集下的性能要求，所以很天然地會考慮預計算系統。而Druid主要面向的是實時Timeseries數據，咱們雖然也有相似的場景，但主流的分析仍是面向數倉中按天生產的結構化表，所以Kylin的MOLAP Cube方案是最適合咱們場景的引擎。
Kylin的使用現狀
2016年初，咱們開始向各個業務線推廣基於Kylin的解決方案。通過一年的努力，Kylin已經應用到了美團點評的幾乎全部主要業務線上，而且在外賣、酒旅等數個業務線獲得了大規模的使用，Kylin已經成爲了這些業務的首選OLAP引擎。
截至16年末，生產環境共有214個Cube，包含的數據總行數爲2853億行，Cube在HBase中的存儲有59TB。日查詢次數超過了50萬次，TP50查詢時延87ms，TP99時延1266ms，很好地知足了咱們對性能的要求。
爲了支持這些需求，咱們的線上環境包含一個30節點的Kylin專屬HBase集羣，2臺用於Cube構建的物理機，和8臺8核16G的VM用做Kylin的查詢機。Cube的構建是運行在主計算集羣的MR做業，各業務線的構建任務拆分到了他們各自的資源隊列上。
因爲Kylin對外是REST接口，咱們接入了公司統一的http服務治理框架來實現負載均衡和平滑重啓。
「維度爆炸」問題在實踐中是可解的
提到MOLAP Cube方案，不少沒接觸過Kylin的人會擔憂「維度爆炸」的問題，即每增長一個維度，因爲維度組合數翻倍，Cube的計算和存儲量也會成倍增加。咱們起初其實也有一樣的擔憂，但調研和使用Kylin一陣子後發現，這個問題在實踐中並無想象的嚴重。這主要是由於
Kylin支持Partial Cube，不須要對全部維度組合都進行預計算；
實際業務中，維度之間每每存在衍生關係，而Kylin能夠把衍生維度的計算從預計算推遲到查詢處理階段。
以事實表上的衍生維度爲例，咱們業務中的不少維度都是(ID, NAME)成對出現的。查詢時須要對ID列進行過濾，但顯示時只須要取對應的NAME列。若是把這兩列都做爲維度，維度個數會翻倍。而在Kylin中，能夠把NAME做爲ID列的extendedcolumn指標，這樣Cube中的維度個數就減半了。
下面分享一些咱們線上Cube的統計數據。
能夠看到，採用衍生維度後，90%的場景能夠把Cube中的維度個數（Rowkey列數）控制在20個之內。指標個數呈現長尾分佈，小於10個指標的Cube是最多的，不過也有近一半的Cube指標數超過20。總共有382個去重指標，佔到了總指標數的10%，絕大多數都是精確去重指標。49%的Cube膨脹率小於100%，即Cube存儲量不超過上游Hive表。68%的Cube可以在1小時內完成構建，92%在2小時內完成構建。
美團外賣的使用案例
下面分享一下Kylin在美團外賣的使用案例，感謝外賣的同事 靳國衛和惠明 提供材料。
外賣數據業務對交互式的OLAP分析有着很強的需求。在使用Kylin之前，採用的是在Hive中開發聚合表再導入MySQL的方案。隨着業務數據量高速增加和需求的不斷升級，這套方案遇到了開頭提到的查詢效率和開發效率的雙重問題。
在使用Kylin後，除了查詢性能的顯著提高，外賣的數據開發方式發生了很大的改變。原來須要作繁瑣的聚合層和主題層數據，如今只須要把重點放到基礎數據的建設上，預計算的工做交給Kylin就好了。在對同一個需求同時採用老方案和Kylin方案實施後發現，使用Kylin後的數據開發效率提高了3倍。
下面是一個對流量數據應用Kylin的具體案例。咱們在Kylin 1.5.3版本添加了全局字典，實現了上億基數、任意類型字段（例如設備ID）的精確去重計數，把Kylin的使用場景擴寬到了流量數據。
平臺化經驗與思考
一個開源項目從run起來到真正做爲平臺化的服務提供出去，中間會遇到不少的挑戰和問題須要解決。下面是咱們總結的一些經驗，在這裏分享給你們，也歡迎同行們和咱們一塊兒探討。