在近期的 Apache Kylin Meetup 北京站上，我們邀請到了一點資訊的大數據平臺高級工程師毛洪玥來分享 Kylin 在一點資訊的應用。本次分享由一點資訊 OLAP 發展歷程和系統基礎架構開始，以 Kylin 在一點資訊的業務需求和實踐經驗爲依託，分享針對數據量較大的Cube如何提高查詢響應速度，如何縮短構建時間，如何緩解 HBase 壓力來提升穩定性，及使用過程中遇到的特殊數據問題與解決方案等。
發展歷程
2016 年 9 月開始，一點資訊選擇了綜合性能優秀的 Druid 來承接大數據部門、算法部門和廣告部門的多維分析查詢需求。2017 年 9 月，接入剛剛開源的 Doris，承接明細查詢和 SQL 分析業務。
至今年 5 月，隨着業務增長和數據積累，冷數據佔比增高，機器利用率降低。大部分數據月查詢次數不超過 1 次，卻需要長期存儲，因而造成大量機器資源浪費。如何提高有限資源的利用率，支持維度高達 27 個，日誌量達 1 T/天，查詢週期長達 1 年的業務呢？經過一系列調研，一點資訊決定使用 Kylin 系統。Kylin 支持Hive、Kafka等形式的數據源，Cube存儲及查詢使用HBase，構建任務可以利用運行在Yarn上的MapReduce或Spark任務，這些都是一點資訊使用中的大數據組件，它們的存儲計算均爲PB級或以上級別，只需要再搭建輕量級 Kylin 實例即可。同時，Kylin 可以提供穩定高效的多維分析查詢，對 JDBC 接入友好。
經過一個月的調研後，一點資訊在今年 6 月份正式將第一個 Kylin cube 投入線上使用。到目前爲止，一點資訊總 Cube 數爲 75 個，總數據量達到 90 T，最大的一個 Cube 源數據條數達 2.6 萬億。部署方式爲 K8S 部署，兩個 All 實例，兩個Query 實例。K8S 部署大大減輕了運維負擔，同時雙角色雙活保證任意一個實例故障都不會影響 Kylin 的正常使用。任務引擎高可用部署方案詳見官網：http://kylin.apache.org/cn/docs/install/kylin_cluster.html
上圖是一點資訊 OLAP 服務框架。爲使公司內部各業務部門更方便地使用 OLAP 系統，一點資訊研發了自己的一站式 OLAP 分析平臺，集數據源管理、任務調度、查詢分析、權限管控、監控報警於一身。主要支撐了三個大方向業務：算法分析、數據分析、運維。
Kylin 實踐經驗
關於 Kylin 的實踐經驗，主要分享三個 Topic：大型 Cube 調優實踐，HBase 穩定性提升實踐和特殊數據導致任務失敗案例。
01 大型 cube 調優實踐
剛剛使用 Kylin 後遇到的第一個 Cube，數據源來自 27 個維度，日新增數據量高達 140 億的離線任務。
業務方要求每天十點之前出報表，且不能對其他任務產生影響，同時查詢成功率達95% 以上，支持一年數據存儲。
我們首先按照需求創建 Cube，沒有進行任何優化，嘗試構建後發現該 Cube 無法滿足業務需求。Cube 構建時長達 500 分鐘，每天下午 2 點才能構建完成。任務構建時消耗計算資源會嚴重影響其他流水線運行，業務常用查詢成功率不足 95%，空間存儲達 500 G。
爲了從各個方面入手優化 cube，我們首先調研網上權威的優化方案，調整了維度關係，rowkey 順序，一部分構建參數等。最後我們自研了智能分組策略。
我們首先找尋查詢歷史規律，發現當某維度組合 ABC 查詢頻率較高時，其子維度組合(AB,AC,BC,A,B,C)查詢頻率也會較高且都會高於原 ABC 組合。於是根據這一規律，我們設計瞭如下分組策略。
Step1. 計算各維度權值，權值含義爲將該維度添加至預分組後能夠多覆蓋的查詢次數。
Step2. 將權值最高的維度加入預分組。
Step3. 重新計算權值，重複以上步驟，直到維度權值過小或預分組維度數達到預定值。
上圖示例中，初始狀態下預分組爲空集，各維度權值即爲其查詢次數，首次將查詢次數爲105的維度A 加入預分組。更新各維度權值，C的權值增加爲 90+80，成爲當前權值最大維度，於是將 C 加入預分組，依此類推。
這一算法可以幫助我們找到各查詢維度組合之間的關係，同時保持一定的可拓展性。我們按照分組策略結果設定與之對應的Aggreation group。同時將常用明確的查詢作爲 MandatoryCuboids，以確保常用查詢維度組合cuboid 一定會被預計算。
最終效果如上圖所示，cube 查詢，構建，存儲，穩定性都有明顯提升。
02HBase穩定性的調優的實踐
隨着 Kylin 在公司內部業務量不斷攀升，在一段時間內頁面穩定性降低，經常出現頁面不響應或查詢失敗，但重新查詢即可成功、構建失敗但重啓後會成功等問題。
其真正的原因在於 HBase 穩定性降低。當時導致 HBase 穩定性差的一個重要原因是 region 數過多。生產集羣的 HBase 總數據量 90 T，但大小 region 數共16 萬+，region 劃分存在嚴重浪費。我們發現如下情況：
a) region 劃分不合理，單個 region 中數據量小於 100M 較多
b) 數據冗餘。天級查詢任務，按小時更新，不同 table 中存在相同的 rowkey。
針對以上情況我們使用瞭如下兩種手段：
（1）開啓自動 Merge 功能
針對數據冗餘情況我們使用了 Kylin 的 Merge 功能，Merge會合並不同 segment的cuboid 數據，且不需要依賴原始數據。開啓也非常方便，手動地提交一個 merge 任務或者設置 refresh settings 並開啓 auto-merge 即可。
Merge 任務有效幫助我們縮減了 50% 空間佔用，提高了 30% 查詢速度，其主要原因在於合併了相同的 key。
Merge 時，發生了一個意外。某個Merge 任務持續運行 10 小時沒有結束，頻繁生成大量只有 54B 的小文件，導致我們 HDFS namenode 的節點內存不足。
經排查發現凡涉及使用HFileOutputFormat2工具類進行BlukLoad都可能遇到這一問題。我們已將問題修復並提交至HBase社區。問題的詳細解析參考https://issues.apache.org/jira/browse/HBASE-22887。
（2）預估參數調整
對於 region 劃分不合理的情況，我們調整預估參數。Kylin 依據其預估數據兩判定生成 HTable region 數，這是因爲創建HTable在生成 cuboid 數據之前，無法準確獲知真實的數據量。
預估包括兩個部分，行數預估和大小預估，涉及參數如上圖。其中普通指標和維度的佔用空間相對固定，而 TOPN 和 count distinct 指標占用空間會依據數據形態產生較大的變化。
在我們的案例中，使用默認兩個行數預估參數，預估非常準確，誤差在 1% 以下。而大小預估誤差較大，預估大小能達到實際大小的 6.5 倍以上，我們依據實際情況將 TOPN 和 count distinct 的參數做了如上表格調整。調整後預估大小爲實際大小的 1.32 倍。
通過 merge 任務和預估參數調整的 region 數量 16 萬個降到 7 萬個，保證了 HBase 穩定運行。
03
通過 merge 任務和預估參數調整的 region 數量 16 萬個降到 7 萬個，保證了 HBase 穩定運行。
03特殊數據導致任務構建失敗案例
這一特殊數據導致任務在提取事實表的唯一列（Extract Fact Table Distinct Columns）時失敗。
提取事實表的唯一列是如何實現的呢？它將所有數據的每一列在 map 中提取出來，並分配給不同的 Reducer 去重。如上例這一步會把電影類型維度“動畫”、“主旋律”、“動作”這些放到一個 Reducer 裏面去重，大部分的情況下會在去重後構建字典。如果是 UHC（Ultra High Cardinality）列，則平均分配給不同的 Reducer 去重。另一個 Reducer 來專門負責計算預估行數等。
那麼通過什麼樣的方法來決定該將“動作”或者“動畫”分配給哪個 Reduce 呢？
- 維護每一個維度及其 Reduce 對應關係表，維度 A 就是 Reducer0，維度 B 是 Reducer1～3，計算預估行數Reducer-1。
- 普通維度：“動畫”、“主旋律”、“動作”等，都是“電影類型”維度按照對應關係會被分配給 Reduce0。
- UHD維度：而《熊出沒》和《姜子牙》通過均勻分配給不同 Reduce 。公式爲：beginId+abs(hash_code(fieldValue))%span，其中beginId爲該維度起始reducerId，span爲該維度對應reducer數，fieldValue即爲待分配的數據。
本案例中特殊數據爲“0KM2dD66”，其特點在於 hash_code(“0KM2dD66”) =-2147483648，即最小的Int值，而abs(INT_MIN)=INT_MIN。根據公式計算得出 ReducerId 爲 -1，於是這一數據錯誤地進入了負責行數預估的 Reducer -1。由於只有負責行數預估的 Reducer 中 value 不爲空，當其中混入一個 value 爲空的數據時，任務失敗。
若 UHC 列 Reducer 數不爲 3，或該維度起始 ReducerId 不爲 1，則該特殊數據可能會被分配到其他任意 Reducer 中，甚至是不存在的 Reducer，從而導致任務在提取事實表的唯一列執行失敗，必須找到該數據並剔除才能執行成功。
我們已經將問題修正提交至社區。詳情見：https://issues.apache.org/jira/projects/KYLIN/issues/KYLIN-4106
未來展望
作者簡介：毛洪玥，Kylin Contributor & HBase Contributor。就職於一點資訊，負責大數據平臺研發，OLAP 系統研發工作。
