OLAP引擎這麼多，麻袋財富為什麼選擇用Kylin做自助分析？
AI 前線導讀：借貸資訊中介平臺麻袋財富現在已成為行業頭部平臺，龐大的業務量帶來了資料量指數級增長，原有的資料分析處理方式已遠遠不能滿足業務的需求。面對複雜的資料分析處理要求，麻袋財富選擇了 Kylin。
為什麼它會選擇 Kylin 而不是其他解決方案呢？
更多幹貨內容請關注微信公眾號“AI 前線”（ID：ai-front）專案背景
麻袋財富（原麻袋理財）成立於 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 中的表不會自動刪除，影響查詢效能，需要手動清理等。
作者介紹：
大資料平臺部門：麻袋財富大資料平臺部門負責公司企業級資料倉庫的搭建、實時監控系統、智慧化應用平臺等工作，團隊以大資料核心平臺為基礎，展開大資料管理與應用開發，落地人工智慧運用場景。