OLAP引擎這麼多，麻袋財富爲何選擇用Kylin作自助分析？

項目背景

麻袋財富（原麻袋理財）成立於 2014 年 12 月底，是中信產業基金控股的網絡借貸信息中介平臺，通過 4 年平穩而快速的發展，截至目前，累計交易金額達 750 億，已成爲行業頭部平臺。龐大的業務量帶來了數據量指數級增加，原有的數據分析處理方式已遠遠不能知足業務的需求：

• 流程耗時長：邏輯比較複雜的數據需求，可能會涉及到開發，產品經理，BI 等多方相關人員，經過反覆的溝通，確認才能完成，而涉及人員過多增長了溝通成本，拉長項目週期

• 資源浪費：爲了促進平臺的銷量增加，運營會設計各類產品促銷或用戶促活的短時間活動， 每次活動後都會進行復盤，沒有產品化的活動分析一般會致使分析人員的人力浪費

• 集羣壓力大：一些須要長期監測的複雜指標，天天都要進行重複的查詢，並且天天都有幾百個臨時 SQL 提交到集羣中處理，形成集羣計算壓力大，影響集羣性能

• 查詢慢：隨着數據量愈來愈大，每每一條聚合 SQL 須要幾分鐘才能出結果，數據分析師須要的快速響應要求已遠遠不能知足

針對上述痛點，咱們但願尋找一個工具可以給用戶提供高效、穩定、便利的數據分析性能。

爲何選擇 Kylin

咱們調研了市面上主流的 OLAP 引擎，對比詳情以下所示： 　

結合公司業務需求：

• 以 T+1 離線數據爲主

• 能夠整合 Tableau 使用，實現自助分析

• 經常使用 30 個左右的維度，100 個左右的指標，任意交叉組合，覆蓋 80%+ 的固定和臨時需求

• 業務方須要觀察用戶從進入到離開的整個生命週期的特徵，涉及數據量大，但要快速響應

咱們選擇了 Kylin 做爲 OLAP 分析引擎，緣由以下：

• Kylin 使用預計算，以空間換時間，可以實現用戶查詢請求秒級響應

• 能夠結合現有 BI 工具——Tableau，實現自助分析

• 原本須要耗時一週的需求在幾分鐘內出結果，開發效率提高了 10 倍以上

本文主要介紹麻袋財富基於 CDH 大數據平臺的自助分析項目實施，如何將 Apache Kylin 應用到實際場景中，目前的使用現狀以及將來準備在 Kylin 上作的工做。

技術架構

系統部署方面，主要分生產環境和預上線環境，生產環境主要負責查詢分析，從生產集羣 Hive 上跑計算，把預計算結果存儲到 HBase。若是想新增一個 Cube 的話，須要分析人員先在預上線環境上操做，再由專人對 Cube 進行優化後遷移到生產環境。

麻袋財富的自助分析架構以下圖所示：

• 數據同步：Sqoop（離線場景）、Kafka（近實時場景）

• 數據源：Hive（離線場景）、Streaming Table（近實時場景）

• 計算引擎：MapReduce/Spark

• 預計算結果存儲：HBase

• 自助分析工具：Tableau

• 調度系統：Azkaban

Apache Kylin的解決方案

公司業務很是複雜，數據團隊將各類業務需求高度抽象，肯定好維度和度量，只需構建一個 Cube，基於該 Cube，造成通用的平臺化數據產品，解放數據分析師，下降重複性工做。

Kylin 的離線構建 （1）數據建模

數據建模對 Kylin 實施來講是最重要的工做。通常使用關係數據庫模型中的星型模型，可是現實中因爲業務的多樣性，維表的基數很大，因此通常咱們把表處理成寬表而且基於寬表建 OLAP 模型，寬表不只能解決數據模型的數據粒度問題，還能解決多表 join 的性能問題，以及維度變化、或者超高基數維度等問題。

各個業務線不一樣的數據特色和業務特色決定了 Kylin 的使用場景及模型設計優化方式：

• 是數據規模和模型特色。從數據規模上來說，寬表的數據量近百億，天天的增量數據千萬級以上。咱們根據業務指標經過 OLAP 建模的高度抽象分析，定義了維度和度量值的關係以及底層數據粒度。

• 維度基數特色。維度基數最理想的狀況是相對較小，但實際上有些維度超過了百萬級接近千萬級，這和業務需求及行業特色有關。除此以外指標上要用部分維度之間的笛卡爾積組合，形成很難簡化 OLAP 模型，生成數據相應的開銷也比較大。

• 維度粒度特色。從維度的角度來看，地域維度包含省份和城市；時間維度上須要一級劃分年月日，增長了維度的複雜度。

• 指標也是維度特色。有一些指標既是維度也是度量，例如：咱們須要分析在投金額爲 0 的用戶的行爲，又須要計算用戶的在投金額，因此在投金額即爲維度又是度量。

 （2）Kylin Cube 設計

從 Kylin Cube 模型上來講，因爲 Cube 須要知足多種場景的需求，業務上須要多個維度互相靈活組合，與分析人員反覆溝通，最終確認 Cube 的維度及度量。

Cube 模型概況：

• 19 個維度：包括省市、操做系統、設備型號、性別、綁卡狀態、投資等級等

• 10 個度量：包括數據量、訪問次數、登陸用戶數、瀏覽量、投資金額、年化金額等

• 增量構建：某一 Cube 源數據增量爲 300 萬，Build 完一天數據 Cube 大小爲 87.79GB

 （3）Cube 設計的優化

Cube Build 過程當中常見遇到的是性能問題，例如 SQL 查詢過慢、Cube 構建時間過長甚至失敗、 Cube 膨脹率太高等等。究其緣由，大多數問題都是因爲 Cube 設計不當形成的。所以，合理地進行 Cube 優化就顯得尤其重要。

優化方案：

• 維度精簡：去除查詢中不會出現的維度，如數據建立日期

• 強制維度：把每次查詢都須要的維度設爲強制維度（Mandatory Dimensions）

• 層次維度： 把有層次的維度（省市或年月日）設爲層次維度（Hierarchy Dimensions）

• 聯合維度：把用戶關心的維度組合設成聯合維度（Joint Dimensions）

• 調整聚合組：設置多個聚合組，每一個聚合組內設置多組聯合維度。不會同時在查詢中出現的維度分別包含在不一樣聚合組。

• 調整 Rowkeys 排序，對於基數高的維度，若在這個維度上有過濾、查詢，則放在前面，經常使用的維度放在前面。

 （4）Cube 優化成果

根據上面的優化方案， 把 assist_date 和 source 設爲強制維度，把 province，city 設爲層次維度，再根據使用頻率和基數高低排序，最終的優化成果以下：

• 查詢性能：秒級響應

• 構建時間：縮短 31%

• Cube 大小：減少 42%

查詢性能詳情：業務明細表：10 億

SQL 語句：求每一個城市的在投金額

Kylin 實時增量構建

爲了減低 OLAP 分析的延時，在 Kylin 中添加 Streaming Table 實現準實時分析的功能，Kylin 以 Streaming Table 爲數據源，Streaming Table 消費 Kafka 中的數據。模型中多增長一個 timestamp 類型的字段，用做時間序列。在實踐過程當中，模型優化了以下參數：

kylin.Cube.algorithm=inmem

kylin.Cube.algorithm.inmem-concurrent-threads=8

kylin.Cube.max-building-segments=600

Kylin 整合 Tableau

公司採用 Kylin 2.4.0 版本和 Tableau 9.0 版本, 在前者提供預計算結果的前提下, 但願結合 Tableau 可以給數據分析師提供更方便、快速的數據自助分析。

在本機上安裝與 Tableau 版本對應的 Kylin ODBC Drive，Tableau 鏈接 Kylin 時選擇 Kylin 的 ODBC Driver，而後選擇 Kylin 的數據源 Fact Table 和 Join Table，並按 Kylin Cube 模型 join 起來，就能夠實現拖拉出結果的即席查詢，上鑽、下鑽、旋轉等目標。分析人員擺脫了編寫冗長 SQL，漫長等待的過程，能夠根據本身的需求進行數據分析。其中一個使用場景以下圖所示，展現每一個地區的活躍人數：

實施中的經驗總結

1) Tableau 拖拉維度出結果慢

解決：查看 kylin.log，發現耗時最長的都是 select * from fact，因此讓這條 SQL 儘量快的失敗，能夠修改 kylin.properties 的參數:

kylin.query.max-scan-bytes 設置爲更小的值

kylin.storage.partitin.max-scan-bytes 設置成更小的值

2) Kylin 整合 Tableau 建立的計算字段必定是 Cube 中包含的，若 Cube 中沒有包含該計算字段，那麼在 Tableau 中計算會顯示通訊錯誤，由於 Cube 的預計算中不含此值。

3)  使用實時增量時報錯：

解決：這是因爲 Kylin 2.4.0 版本和 Kafka 的 3.0.0 版本不匹配，把 Kylin 降了一個版本 Kylin 2.3.2 便可。

4)  字段類型轉換：在 double 類型的數據轉換爲 String 時，會自動轉換爲保留一位小數的字符串，例如 112 轉換成了 112.0，致使 join 的時候沒法 join 成功。

解決：當咱們要轉換的數值只有整形沒有小數時，咱們能夠先把數值類型轉換成 bigint    類型，使用 bigint 類型存儲的數值不會採用科學計數法表示。

5)  空值產生的數據傾斜：行爲表中對遊客的 user_id 是置空的，若是取其中的 user_id 和 用戶表中的 user_id 關聯，會碰到數據傾斜的問題。

解決：把空值的 user_id 變成一個字符串加上隨機數，把傾斜的數據分到不一樣的 reduce 上，因爲 null 值關聯不上，處理後並不影響最終結果。

6) Kylin ODBC Driver 安裝是根據 Tableau 版本的，不是根據操做系統而定的。例如，windows 版本是 64 位的，Tableau 版本是 32 位，就須要裝 32 位的 ODBC。

將來規劃

Kylin 給咱們帶來了不少便利，節約了查詢時間和精力。隨着技術的不斷進步，還有許多問題須要解決，還須要不斷探索和優化，例如 Kylin 對明細數據的查詢支持不理想，可是有時須要查詢明細數據；刪除 Cube，HBase 中的表不會自動刪除，影響查詢性能，須要手動清理等。