分佈式大數據多維分析引擎：Kylin 在百度地圖的實踐

時間 2019-11-13

原文原文鏈接

1. 前言

百度地圖開放平臺業務部數據智能組主要負責百度地圖內部相關業務的大數據計算分析，處理平常百億級規模數據，爲不一樣業務提供單條SQL毫秒級響應的OLAP多維分析查詢服務。前端

對於Apache Kylin在實際生產環境中的應用，在國內，百度地圖數據智能組是最先的一批實踐者之一。Apache Kylin在2014年11月開源，當時，咱們團隊正須要搭建一套完整的大數據OLAP分析計算平臺，用來提供百億行級數據單條SQL毫秒到秒級的多維分析查詢服務，在技術選型過程當中，咱們參考了Apache Drill、Presto、Impala、Spark SQL、Apache Kylin等。對於Apache Drill和Presto因生產環境案例較少，考慮到後期遇到問題難以交互討論，且Apache Drill總體發展不夠成熟。對於Impala和Spark SQL，主要基於內存計算，對機器資源要求較高，單條SQL可以知足秒級動態查詢響應，但交互頁面一般含有多條SQL查詢請求，在超大規模數據規模下，動態計算亦難以知足要求。後來，咱們關注到了基於MapReduce預計算生成Cube並提供低延遲查詢的Apache Kylin解決方案，並於2015年2月左右在生產環境完成了Apache Kylin的首次完整部署。java

Apache Kylin是一個開源的分佈式分析引擎，提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規模數據，最初由eBay Inc. 開發並貢獻至開源社區，並於2015年11月正式畢業成爲Apache頂級項目。node

2. 大數據多維分析的挑戰

咱們在Apache Kylin集羣上跑了多個Cube測試，結果代表它可以有效解決大數據計算分析的3大痛點問題。android

痛點一：百億級海量數據多維指標動態計算耗時問題，Apache Kylin經過預計算生成Cube結果數據集並存儲到HBase的方式解決。ios

痛點二：複雜條件篩選問題，用戶查詢時，Apache Kylin利用router查找算法及優化的HBase Coprocessor解決；算法

痛點三：跨月、季度、年等大時間區間查詢問題，對於預計算結果的存儲，Apache Kylin利用Cube的Data Segment分區存儲管理解決。apache

這3個痛點的解決，使咱們可以在百億級大數據規模下，且數據模型肯定的具體多維分析產品中，達到單條SQL毫秒級響應。所以，咱們對Apache Kylin產生了較高的興趣，大數據計算查詢分析的應用中，一個頁面一般須要多條SQL查詢，假設單條SQL查詢須要2秒響應，頁面共有5個SQL請求，總共就須要10秒左右，這是不可接受的。而此時，Apache Kylin對於一個頁面多條SQL查詢響應的優點就尤其突出。服務器

在實踐過程當中，根據公司不一樣業務的需求，咱們數據智能團隊的大數據OLAP平臺後臺存儲與查詢引擎採用了由Apache Kylin、Impala及Spark SQL組成，在中小數據規模且分析維度指標較爲隨機的狀況下，平臺可提供Impala或Spark SQL服務；在超大規模百億級行數據的具體產品案例上，因查詢性能需求較高，同時具體產品對其須要分析的維度和指標較爲明確，咱們使用Apache Kylin解決方案。下文將主要介紹Apache Kylin在百度地圖內部的實踐使用。架構

3. 大數據OLAP平臺系統架構

(點擊放大圖像)app

3.1 主要模塊

數據接入：主要負責從數據倉庫端獲取業務所需的最細粒度的事實表數據。

任務管理：主要負責Cube的相關任務的執行、管理等。

任務監控：主要負責Cube任務在執行過程當中的狀態及相應的操做管理。

集羣監控：主要包括Hadoop生態進程的監控及Kylin進程的監控。

3.2 集羣環境

因業務特殊性，咱們並未採用公司內部的Hadoop集羣進行計算、存儲和查詢，而是獨立部署一臺完整的集羣，並獨立維護。

集羣機器：共4臺，1臺master(100G內存) + 3臺slaves(30G內存)。

軟件環境：CDH + Hive + HBase + Kylin 0.71

4. 基於Apache Kylin的二次開發

4.1 數據接入模塊二次開發

對於任何一個數據計算處理平臺，數據的接入十分關鍵，就像熟知的Spark，對數據接入也是十分重視。目前，咱們的大數據OLAP平臺能夠支持2種數據源的引入： MySQL數據源及HDFS數據源。在實踐中，咱們遇到一個問題，假設MySQL及HDFS數據源沒有標識表示T-1天的數據已經計算完成的狀況下，如何肯定T-1天的數據已經準備就緒。對於Hive數據源，查詢數據所在Hive Meta的partition是否就緒；對於MySQL，咱們目前想到的辦法是間隔必定時間循環探測當天數據行數是否變化，若是沒有變化，咱們基本可以簡單認爲第T-1天的數據已經由數據倉庫計算完畢，接下來就能夠觸發數據拉取模塊邏輯將數據拉取到Master節點的本地文件系統中，根據業務判斷是否須要對這些數據細加工，而後，導入到Master的Hive中，觸發事實表對應任務涉及到的全部cube，啓動MapReduce計算，計算結束後，前端能夠刷新訪問最新數據。另外，若是到了指定時間，發現數據倉庫端的數據仍舊沒有準備好，數據接入模塊會短信報警給倉庫端，並繼續循環檢測直至指定時刻退出。

(點擊放大圖像)

數據引入模塊

4.2 任務管理模塊二次開發

任務管理對於計算型平臺服務十分重要，也是咱們大數據OLAP多維分析平臺的核心擴展工做之一。對於用戶而言，Apache Kylin對於Cube的最小存儲單位爲data segment，相似於Hive的partition，data segment採用左閉右開區間表示，如[2015-11-01，2015-11-02)表示含有2015-11-01這一天的數據。對於Cube數據的管理主要基於data segment粒度，大體分爲3種操做: 計算(build)、更新(refresh)、合併(merge)。對於一個具體產品來講，它的數據是須要天天例行計算到cube中，正常例行下，天天會生成1個data segment，但可能會由於數據倉庫的任務延遲，2天或多天生成1個segment。隨着時間推移，一方面，大量的data segment嚴重影響了性能，另外一方面，這也給管理帶來了困難和麻煩。所以，對於1個cube，咱們按照1個天然月爲1個data segment，清晰且易管理。

假設咱們有1個月30天的數據，共23個data segment數據片斷，如：[2015-11-01，2015-11-02)， [2015-11-02，2015-11-04)， [2015-11-04，2015-11-11)， [2015-11-11，2015-11-12)， [2015-11-12，2015-11-13)，。。。[2015-11-30，2015-12-01)

問題1: 假設由於數據有問題，須要回溯2015-11-01的數據，由於咱們可以在cube中找到[2015-11-01，2015-11-02)這樣一個data segment，知足這個時間區間，因而，咱們能夠直接界面操做或者Rest API啓動這個data segment的refresh更新操做。

問題2: 假設咱們須要回溯2015-11-02到2015-11-03的數據，同理，能夠找到一個符合條件的data segment [2015-11-02，2015-11-04)，而後refresh更新這個data segment。

問題3: 假設咱們須要回溯2015-11-01到2015-11-02的數據，咱們找不到直接知足時間區間的data segment。因而咱們有2種解決方案，第1種方案是分別依次refresh更新 [2015-11-01，2015-11-02)， [2015-11-02，2015-11-04)這2個data segment實現；第2種方案是先合併(merge)[2015-11-01，2015-11-02)， (2015-11-02，2015-11-04)這兩個data segment，合併後獲得[2015-11-01，2015-11-04)這樣1個data segment，而後咱們再拉取新數據後執行更新操做，便可知足需求。

問題4: 假設咱們須要刷新2015-11-01~2015-11-30這1個月的數據，咱們在另1套集羣上基於Kylin 1.1.1對同一個cube進行測試，若是採用問題3中的第1種方案，咱們須要逐步刷新cube的23個data segment，大約耗時17.93min X 30=537分鐘；若是咱們採用問題3中的第2種方案，那麼咱們只須要將23個data segment合併成[2015-11-01，2015-12-01)這1個data segment，計1次操做。而後再執行1次更新操做，共2次操做便可完成需求，整體上，耗時約83.78分鐘，較第1種方法性能上提升不少。

基於上面的問題，目前咱們平臺對Apache Kylin進行了二次開發，擴展出了任務管理模塊。

對於cube的計算(build)操做，假設數據倉庫2015-11-29～2015-12-02的數據因故延遲，在2015年12-03天產出了(T-1天的數據)，若是不判斷處理，就會例行計算生成一個時間區間爲[2015-11-29，2015-12-03)的data segment。因此，在每一個cube計算前，咱們的邏輯會自動檢測跨天然月問題，並生成[2015-11-29，2015-12-01)和[2015-12-01，2015-12-03)兩個data segment.

對於cube的更新(refresh)操做，咱們會採用問題三、問題4中提到的第2種方案，自動合併(merge)data segment後再執行更新refresh操做。由於上面已經保證了不會有跨月data segment的生成，這裏的自動合併也不會遇到生成跨天然月的狀況。

對於cube的合併(merge)操做，若是天天都自動合併該天然月內前面日期已有的全部data segment，假設咱們想回溯更新2015-11-11這一天的數據，那麼就須要回溯(2015-11-01，2015-11-12)（由於這個時間區間的data segment天天都被自動合併了），其實，咱們沒有必要回溯2015-11-01~2015-11-10這10天的數據。因此，對於1個天然月內的cube的數據，在當月，咱們先保留了1天1個data segment的碎片狀態，由於在當月發現前面某幾天數據有問題的機率大，回溯某個data segment小碎片就更加合理及性能更優。對於上個月整個月的數據，在下個月的中上旬時數據已經比較穩定，回溯的機率較小，一般要回溯也是上個月整月的數據。所以，在中上旬總體合併上1個月的數據而不是天天合併更合理。

(點擊放大圖像)

任務管理模塊

4.3 平臺監控模塊二次開發

4.3.1 任務監控

一般，1個產品對應多個頁面，1頁面對應1個事實表，1個事實表對應多個cube，那麼一個產品一般會包含多個cube，上面提到的cube基於data segment的3種任務狀態，很難人爲去核查，因此對於任務執行的監控是很是必要的，當任務提交後，每隔一段時間檢測一次任務的狀態，任務狀態中間失敗或者最後成功後，則會發送郵件或者短信報警通知用戶。

4.3.2 集羣監控

因爲咱們的服務器是團隊內部獨自部署維護，爲了高效監控整套Hadoop集羣、Hive，HBase、Kylin的進程狀態，以及處理海量臨時文件的問題，咱們單獨開發了監控邏輯模塊。一旦集羣出現問題，可以第一時間收到報警短信或者郵件。

(點擊放大圖像)

平臺監控模塊

4.4 資源隔離二次開發

因爲咱們以平臺方式提供給各個業務線使用，當某個業務線的業務數據計算規模較大，會形成平臺現有資源緊張時，咱們會根據實際狀況，要求業務方提供機器資源，隨之而來的就是如何根據業務方提供的機器資源分配對應的計算隊列的資源隔離問題。目前，官方的Apache Kylin版本對於整個集羣只能使用1個kylin_job_conf.xml, 平臺上全部項目的全部Cube的3種操做只能使用同一個隊列。因而，咱們基於kylin-1.1.1-incubating這個tag的源碼作了相關修改，支持了以項目爲粒度的資源隔離功能，並提交issue到https://issues.apache.org/jira/browse/KYLIN-1241，方案對於咱們平臺管理員自身也參與項目開發的應用場景下很是適用。對於某個項目，若是不須要指定特定計算隊列，無需在$KYLIN_HOME下指定該項目的kylin_job_conf.xml文件，系統會自動調用官方原有的邏輯，使用默認的Hadoop隊列計算。

(點擊放大圖像)

資源隔離

4.5 Hadoop及HBase優化

因獨立部署的Hadoop集羣硬件配置不高，內存十分有限，因此，在項目實踐過程當中也遇到很多問題。

4.5.1 Hadoop任務內存資源不夠，cube計算失敗

調整MapReduce分配資源參數：在cube計算過程當中，會出現mr任務失敗，根據日誌排查，主要因mr的內存分配不足致使，因而，咱們根據任務實際狀況總體調整了yarn.nodemanager.resource.memory-mb,mapreduce.map.memory.mb, mapreduce.map.java.opts, mapreduce.reduce.memory.mb及mapreduce.reduce.java.opts等參數。

4.5.2 HBase RegionServer在不一樣節點隨機down掉

因爲機器總體資源限制，咱們給HBase配置的HBASE_HEAPSIZE值較小，隨着時間推移，平臺承載的項目愈來愈多，對內存及計算資源要求也逐步提升。後來平臺在運行過程當中，HBase的RegionServer在不一樣節點上出現隨機down掉的現象，致使HBase不可用，影響了Kylin的查詢服務，這個問題困擾了團隊較長時間，經過網上資料及自身的一些經驗，咱們對HBase和Hadoop相關參數作了較多優化。

A. HBase的JVM GC相關參數調優，開啓了HBase的mslab參數：能夠經過GC調優得到更好的GC性能，減小單次GC的時間和FULL GC頻率；

B. HBase的ZK鏈接超時相關參數調優：默認的ZK超時設置過短，一旦發生FULL GC，極其容易致使ZK鏈接超時；

C. ZK Server調優，提升maxSessionTimeout：ZK客戶端（好比Hbase的客戶端）的ZK超時參數必須在服務端超時參數的範圍內，不然ZK客戶端設置的超時參數起不到效果；

D. HBASE_OPTS參數調優：開啓CMS垃圾回收期，增大了PermSize和MaxPermSize的值；
Hadoop及HBase優化

(點擊放大圖像)

Hadoop及HBase優化

5. Apache Kylin項目實踐

5.1 基於倉庫端join好的fact事實表建Cube，減小對小規模集羣帶來的hive join壓力

對於Cube的設計，官方有專門的相關文檔說明，裏面有較多的指導經驗，好比: cube的維度最好不要超過15個，對於cardinality較大的維度放在前面，維度的值不要過大，維度Hierarchy的設置等等。

實踐中，咱們會將某個產品需求分爲多個頁面進行開發，每一個頁面查詢主要基於事實表建的cube，每一個頁面對應多張維度表和1張事實表，維度表放在MySQL端，由數據倉庫端統一管理，事實表計算後存放在HDFS中，事實表中不存儲維度的名稱，僅存儲維度的id，主要基於3方面考慮，第一：減小事實表體積；第二：因爲咱們的Hadoop集羣是本身單獨部署的小集羣，MapReduce計算能力有限，join操做但願在倉庫端完成，避免給Kylin集羣帶來的Hive join等計算壓力；第三：減小回溯代價。假設咱們把維度名稱也存在Cube中，若是維度名稱變化必然致使整個cube的回溯，代價很大。這裏可能有人會問，事實表中只有維度id沒有維度name，假設咱們須要join獲得查詢結果中含有維度name的記錄，怎麼辦呢？對於某個產品的1個頁面，咱們查詢時傳到後臺的是維度id，維度id對應的維度name來自MySQL中的維度表，能夠將維度name查詢出來並和維度id保存爲1個維度map待後續使用。同時，一個頁面的可視範圍有限，查詢結果雖然總量不少，可是每一頁返回的知足條件的事實表記錄結果有限，那麼，咱們能夠經過以前保存的維度map來映射每列id對應的名稱，至關於在前端邏輯中完成了傳統的id和name的join操做。

5.2 Aggregation cube輔助中高維度指標計算，解決向上彙總計算數據膨脹問題

好比咱們的事實表有個detail分區數據，detail分區包含最細粒度os和appversion兩個維度的數據(注意: cuid維度的計算在倉庫端處理)，咱們的cube設計也選擇os和appversion，hierarchy層次結構上，os是appversion的父親節點，從os+appversion(group by os, appversion)組合維度來看，統計的用戶量沒有問題，可是按照os(group by os)單維度統計用戶量時，會從基於這個detail分區創建的cube向上彙總計算，設上午用戶使用的是android 8.0版本，下午大量用戶升級到android 8.1版本，android 8.0組合維度 + android 8.1組合維度向上計算彙總獲得os=android(group by os, where os=android)單維度用戶，數據會膨脹且數據不許確。所以咱們爲事實表增長一個agg分區，agg分區包含已經從cuid粒度group by去重後計算好的os單維度結果。這樣，當用戶請求os維度彙總的狀況下，Apache Kylin會根據router算法，計算出符合條件的候選cube集合，並按照權重進行優選級排序(熟悉MicroStrategy等BI產品的同窗應該知道這類案例)，選擇器會選中基於agg分區創建的os單維度agg cube，而不從detail這個分區創建的cube來自底向上從最細粒度往高彙總，從而保證了數據的正確性。

5.3 新增留存類分析，如何更高效更新歷史記錄？

對應小規模集羣，計算資源是很是寶貴的，假設咱們對於某個項目的留存分析到了日對1日到日對30日，日對1周到日對4周，日對1月到日對4月，周對1周到周對4周，月對1月到月對4月。那麼對於傳統的存儲方案，咱們將遇到問題。

5.3.1 傳統方案

假現在天是2015-12-02，咱們計算實際獲得的是2015-12-01的數據

(點擊放大圖像)

上面數據存儲方案的思路是，當今天是2015-12-02，那麼2015-12-01能夠計算活躍用戶了，因而，咱們會將2015-11-30的日對第1日留存， 2015-11-29的日對第2日， 2015-11-28的日對第3日等的這些列指標數據進行更新(如上紅色對角線部分)，這是由於天天數據的每1列都是以當天爲基準，等從此第n天到了，再回填這1天的這些第x日留存，如此，對於1個任務會級聯更新以前的多天曆史數據，如上紅色對角線的數據。

此方案的優點：

a, 若是要查看某個時間範圍內的某一個或者多個指標，能夠直接根據時間區間，選擇須要的列指標便可。

b, 若是要查看某1天的多個指標，也能夠直接選擇那1天的多個指標便可

此方案的缺點：

a, 天天都須要更新歷史數據，如上紅色對角線的數據，形成大量MapReduce任務預計算cube，須要較多的機器計算資源支持。

b, 若是從此增長新的留存，好比半年留存，年留存，那麼對角線長度就更長，天天就須要回溯更新更多天數的歷史數據，須要更多時間跑任務。

c, 對於級聯更新的大量的歷史數據任務，其實依賴性很強，如何保證留存項目多個cube每一天的多個data segment級聯更新正確，很是複雜，難以維護和監控，對於數據倉庫端也易遇到如此問題。

d, 對於須要批量回溯一個較大時間區間的歷史數據時，問題3中涉及的任務計算難點和困難尤其突出。

5.3.2 變通方案

假現在天是2015-12-02，咱們計算實際獲得的是2015-12-01的數據（可和上面的結構對比）

(點擊放大圖像)

此方案的思路是，當今天是2015-12-02，實際是2015-12-01的數據，如上示例存儲，但日對第n日的留存表示的是n日前對應的那個日期的留存量，至關於旋轉了紅色對角線。

此方案的優點：

a, 若是要查看某個時間範圍內的某1個指標，直接選擇該範圍的該列指標便可

b, 若是從此增長新的留存，好比半年留存，年留存等指標，不須要級聯更新歷史天數的數據，只須要更新2015-12-01這1天的數據，時間複雜度O(1)不變，對物理機器資源要求不高。

此方案的缺點：

a, 若是涉及到某1天或者某個時間範圍的多列指標查詢，須要前端開發留存分析特殊處理邏輯，根據相應的時間窗口滑動，從不一樣的行，選擇不一樣的列，而後渲染到前端頁面。

目前，咱們在項目中採用變通的存儲方案。

6. 總結

目前，咱們大數據OLAP多維分析平臺承載百度地圖內部多個基於Apache Kylin引擎的億級多維分析查詢項目，共計約80個cube，平均半年時間的歷史數據，共計約50億行的源數據規模，單表最大數據量爲20億+條源數據，知足大時間區間、複雜條件過濾、多維彙總聚合的單條SQL查詢毫秒級響應，較爲高效地解決了億級大數據交互查詢的性能需求，很是感謝由eBay貢獻的Apache Kylin，從預計算和索引的思路爲大數據OLAP開源領域提供了一種樸素實用的解決方案，也很是感謝Apache Kylin社區提供的支持和幫助。

做者簡介：王冬，百度地圖數據智能組成員，北京理工大學計算機本碩畢業，2012加入Microstrategy，負責BI Server核心組件SQL Engine相關開發。並於2014年加入百度地圖數據智能組，主要負責大數據OLAP多維分析計算方向研究，熱愛大數據離線、實時平臺建設應用、Spark生態應用等。