卷皮OLAP平臺進化史：Apache Kylin在卷皮網大資料平臺的運用
AI 前線導讀：“卷皮網”是一家專注高性價比商品的移動電商 ，日活躍高達 1000 多萬，隨著卷皮網的快速發展，資料規模快速增長，叢集資料儲存量成指數倍增大，伺服器規模達到 100+ 臺，與此同時公司的運營成員急劇增加，資料需求也隨著業務的發展落地不斷增長，如統計分析、運營報表、取數需求任務日益增大。為了節省取數工作的時間和人員開支，及時響應運營等部門同學資料需求的快速響應，於是開發了以自助資料分析為目標的 OLAP 平臺。本文將詳解 Apache Kylin 在卷皮網大資料平臺的運用。
更多優質內容請關注微信公眾號“AI 前線”（ID：ai-front）
前言
在開始案例分享前，先簡單介紹一下“卷皮網”以及“卷皮網”的大資料團隊“卷皮網”是一家專注高性價比商品的移動電商 ，日活躍高達 1000 多萬“卷皮網”的大資料團隊規模在 40 人左右，主要負責公司的底層資料倉庫建設、OLAP 平臺、報表系統等資料視覺化工具，以及資料探勘在搜尋排序推薦上的應用、爬蟲物流平臺的建設、鷹眼風控系統、撥雲日誌系統等。
隨著卷皮網的快速發展，資料規模快速增長，叢集資料儲存量成指數倍增大，伺服器規模達到 100+ 臺，與此同時公司的運營成員急劇增加，資料需求也隨著業務的發展落地不斷增長，如統計分析、運營報表、取數需求任務日益增大。為了節省取數工作的時間和人員開支，及時響應運營等部門同學資料需求的快速響應，我們於是開發了以自助資料分析為目標的 OLAP 平臺。隨著公司業務的日益擴增，平臺經歷瞭如下發展過程。
早期的 ROLAP
起初，資料規模較小，業務線比較簡單，而且需求比較碎，故主要採取如下 ROLAP 引擎支撐：
具體流程: 通過埋點採集使用者行為資料，通過 Datax 和 Otter 同步資料到 Hive 叢集和 SQL/">MySQL 叢集，資料開發工程師通過 Etl 指令碼 (Hive 指令碼和 MySQL 儲存過程) 兩種方式將最終結果資料落地到 MySQL 資料庫，最終呈現給業務方使用，還有一部分靈活定製的是通過郵件平臺每日生成 Excel 附件，郵件推送給業務方
以 Presto+Mondrian 為核心的 MOLAP 平臺
隨著資料規模的增長和需求的增多，瓶頸逐漸顯現。每個需求都要開發資料指令碼，維度增加，開發週期拉長，同時需要耗費更多的人力，無法快速產出資料和響應需求變化。我們採用了 Saiku+Mondrian+Presto+Hive 的技術架構，通過分隔不同的業務線，最終生成若干個 Cube，提供給運營的同學使用，基本滿足了業務方 90% 的資料需求。
使用 Kylin 解決超大規模資料分析
Kylin v1.6
由於 Presto 是線上運算執行查詢的，在日增上億資料查詢的時候，表現極為吃力。於是我們於 2016年 8 月份開始引入 Apache Kylin（以下簡稱 Kylin），將使用者行為資料等超大規模資料遷移到 Kylin 上，同時大大緩解 Presto 叢集的壓力。
由於 Kylin 的基本原理是通過預計算實現空間換時間，Presto 需要線上查詢源資料，所以 Kylin 的效能遠遠好於 Presto，Kylin 和 Presto 的查詢效能對比。
該版本只支援星型模式，在 MR 上進行構建 Cube。起初我們根據業務線設計 Cube，其中最大的一個 Cube，維表 20+，其中包含若干高基數維，我們在預聚合的時候發現該 Cube 處理時間非常長，甚至造成記憶體溢位。於是我們對 Cube 進行了優化，以下是用到的一些優化手段：
1. 我們將該 Cube 根據業務細分成若干個 Cube, 同時對高基數維度做了優化
2. 使用了 Cube 構建的高階設定。這些高階設定包括聚合組（Aggregation Group）、聯合維度（Joint Dimension）、層級維度（Hierarchy Dimension）和必要維度（Mandatory Dimension）等。基於這些設定，我們對拆分後的 Cube 進行了進一步的優化
（1） Mandatory Dimension
一般設定查詢時經常使用的維度，我們使用了日期作為必需維度
（2）Hierarchy Dimension
如果維度關係有一定層級性、基數由小到大的情況可以使用層級維度。比如年月日，省市區，一級類目二級類目三級類目等等
（3）Joint Dimension
如果維度之間是同時出現的關係，即查詢階段，絕大部分情況都是同時出現的。可以使用 聯合維度。
根據高階配置後，雖然犧牲了部分查詢的查詢效能，但是極大的優化了預聚合的效能。以下是優化之後的效能指標：
Apache Kylin v2.x 版本升級
2017 年 4 月 30 號 Kylin v2.0 版本釋出，不到三個月的時間，v2.1 版本正式釋出。這兩個版本主要有使用 Spark 做預聚合，支援雪花模型等新特性，對於我們解決 OLAP 預聚合慢的需求可以提供更多支援，並解決老版本的 Cube 構建時長、構建不穩定等問題。以下是 v1.6 版本和 v2.1 版本的一個對比：
場景 1：新版本 MR 構建效能對比
事實事匯入 2kw(2g) 測試資料, 使用 19 個維度 (維度基數在 1w 以下)，6 個 Count Distinct(Bitmap)，8 個普通指標，聚合方式:2^10 （無 Join Dimension, 無 Mandatory Dimensions），以 MR 引擎進行構建。
場景 2：Spark 構建效能以及 Join Dimension
事實事匯入 1kw(1.4g) 測試資料, 使用 16 個維度 (維度基數在 1w 以下)，4 個普通指標，聚合方式 : (2^3 + 2^4 + 2) （有 Join Dimension, 有 Mandatory Dimensions），以 Spark 和 MR 引擎分別進行構建。
場景 3：維表數量對效能的影響
事實事匯入 3kw(3g) 測試資料, 使用 15 個維表，30+ 維度 (維度基數在 1w 以下)，12 個 Count Distinct(bitmap),8 個普通指標，聚合方式:2^5 + 2^5 + 2^5 （有 Join Dimension, 無 Mandatory Dimensions），以 MR 引擎進行構建。
由於這兩個版本的 MR 構建效能差異較大，單獨對比各階段的耗時，發現 v2.1 有了全面的提升。
應用場景
我們的業務場景根據資料規模和業務複雜度來使用不同的技術框架。趨勢如下:
資料業務需求視覺化結構
曝光轉化分析是對平臺坑位的曝光點選率做多維分析的 Cube，日增資料量在數億級別。使用者畫像分析是對基於平臺所有使用者的屬性做多維分析的 Cube，日增資料在三千萬左右。
以下我們成單路徑分析為例做詳細介紹:
簡介: 成單路徑是圍繞使用者從瀏覽頁面到最終下單到支付的整個生命週期的使用者行為路徑分析。採用的是歸因演算法。我們採用的歸因方法是事先對我們平臺的頁面進行劃分層級，使用者在返回上一層級的時候重新覆蓋。這樣我們在計算最終轉化率能達到，一個訂單最終只歸到一條下單路徑，具體的頁面劃分層級如下:
下表是成單路徑的維度和指標說明
初期我們使用 Presto 來做成單路徑分析，當時資料量日增還在 1 千萬左右，90% 查詢在 10 秒以內。隨著公司使用者規模的增長，行為資料呈指數級增加，資料高峰時期日增達到上億級別，Presto 的查詢顯得有點力不從心，我們引進了 Kylin，大大得緩解了問題，90% 的查詢的效能迴歸到 1 秒以內。後記:
卷皮 OLAP 一年多時間經歷了三次重大的變革，目前平臺採用 Presto 和 Kylin 兩種引擎並用，事實表日增數量級在千萬級別或以下，維表數多在 15 張以上最好採用 Presto，而事實表日增數量級在千萬級別以上乃至上億，維表數小於 15 個時候可以採用 Kylin。採用 Kylin 一定要將模型提前設計周全，不要頻繁變更，因為每次模型變更資料都需要重刷，重新聚合，費時費力。
作者簡介
許湘楠, 畢業於武漢大學， 有多年的 WEB 系統開發經驗，現就職於武漢奇米網路科技公司 (卷皮網), 擔任大資料開發工程師，主要負責公司 OLAP 平臺研發。