如何給 8000 人開一張報表的權限？蘇寧多維報表平臺應用實踐！
伴隨“大數據”浪潮的來臨，數據決定成敗的觀念已波及社會的各行各業，深刻影響和改變著人們的思維。在工業界，數據已成為企業核心競爭力之一，越來越多的企業已經開始不滿足於單純的收集存儲數據，都開始嘗試通過不同的途徑發掘數據寶藏。
假設數據有 10 個維度，每個維度有 10 種取值，如何做到任意組合、任意視角的分析?這正是多維分析平臺要解決的問題。
這兩年，湧現了不少的優秀開源產品：如 kylin、druid 等，linkedin 今年也開源了自家解決方案 pinot，多維分析平臺的熱度可見一斑。本文將與大家分享蘇寧多維報表平臺的探索之路。
多維報表分析的發展史
如下圖是多維報表的發展歷史。1969 年，Congnos 成立，專門做多維報表。1970 年，Express 成立，於 2000 年被 Oracle 收購，變成甲骨文的多維報表方案。1984 年，Metaphor 成立，首創了基於關系數據庫來模擬多維操作。1993 年，Olap 誕生。1999 年，微軟推出 OlapService 產品。2007 年，IBM 收購了 Cognos。
為什麽蘇寧要自研多維報表平臺?
蘇寧是一家傳統企業，早期使用 Saas 系統做報表、ERP 管理和財務數據的管理，後來采購了 WEBI 系統，來配合 SAP 系統的使用，其中 WEBI 系統於 2016 年停止維護。2013 年，蘇寧采購了 Cognos8 版本系統，目前 Cognos 上面有 2-3 千張報表，每天定時生成。
上圖是 WEBI 系統界面，下圖是 Cognos 界面，多維分析軟件的界面大多雷同，一般基於一些維度、指標，進行選項勾選，做出報表，進行可視化圖形分析等。
從蘇寧的角度來看，自研多維報表平臺，主要因為以下四點：
商業費用。
性能過慢。性能不能滿足使用需求，跟不上業務場景變化。
技術驅動。蘇寧在去 IOE，技術驅動，全面積累。
維護困難。
蘇寧多維報表平臺方案概述
蘇寧多維報表平臺設計理念
Olap 方案的最終理念歸結於數據、信息、知識三部分，首先要拿到原始數據，進行信息的提煉，再根據信息，進一步提煉出知識。
數據部分，涉及到采集、清洗、倉庫以及算法平臺等細節。
信息部分，通過數據匯總、建立模型，多維分析引擎等一系列步驟而成。
知識部分，包含自助報表、權限控制、可視化分析，是通過信息進一步提煉的結果。
蘇寧多維報表平臺的架構
如下圖是整個平臺的架構，最底層是業務系統，主要功能是采集數據，如用戶日誌，各種業務系統日誌。數據倉庫層，做建模匯總，通過數據服務對外開放。報表工具制定一個報表，來做定制化報表分析等等。藍色部分依賴於雲計算平臺。
蘇寧多維報表平臺架構的整體流程
把整體流程提煉成數據采集、數據建模、Olap 加速和報表分析四個部分。數據采集不用多說，數據建模方面，可大可小，最簡單就是提煉出所需的信息。
建模更廣泛的講，可以做標簽、算法、模型。建模的目的是為了做報表使用。只有通過 Olap 加速才能產出一個可用的報表分析。最後，是報表分析，這四步是緊密結合的一個流程。
Olap 引擎的技術選型
Olap 引擎選擇理念
市面上 Olap 種類很多，包含傳統數據庫，如 DB2，MySQL，Oracle 等。MPP 解決方案，主要涉及 Green Plum。還有一些新的技術方案，如 ES、Druid、Kylin 等。
那這麽多的加速引擎，要如何選擇呢?蘇寧的做法是適配所有方案，也就是說沒必要限制在某一個引擎上，調用那個引擎，由場景來決定，符合需求即可。
Olap 引擎之 Druid
目前，Druid 是蘇寧比較重頭的引擎，像用戶流量日誌，訂單數據，這些數據都在使用 Druid。Druid 的特點有很多，這裏主要介紹四點：
實時計算。從 kafka 實時把數據寫到集，支持實時索引和實時查詢。
時間分區。數據一定要有時間字段，就是 Log 類。
列式存儲。通過位置索引來操作。
聚合計算。像 count、distinct、sum、max、min 等等操作，已經滿足絕大部分場景。
如上圖，是 Druid 一個應用結構，可以看到必須有時間字段，以及定義維字段和指標字段。指標字段就是聚合，聚合方式是用近似算法。這裏應用到了基於 Druid 做的聚合插件，但是沒有做開源。
Olap 引擎之 Druid 高效的原因
列式存儲，快速維度過濾。列式存儲就是一行只存一列。例如，有一列肯定是姓名，這是姓名的維度。
Rollup 壓縮。在數字上，定指標。
高效的聚合算法。聚合是把多條數據聚合到一起，可以節省空間，提升效率。
Olap 引擎之 Druid 的 SQL 支持
這裏值得一提的是選用引擎標準有 SQL 接口，但 Druid 本身卻沒有 SQL 接口。這裏用到的解決方案就是 Calcite，可通過 SQL 來操作 Druid，也就是通過 SQL 定義某個指標或維度。Calcite 並不是通過任何改造都可以用。
Olap 引擎之 ES
ES 的功能主要有數據分片，高效索引和聚合計算。索引選用的是目前索引開源方案中比較不錯的 Lucence。它本身也沒有官方 SQL 接口。
ES 設計的目的是做搜索，儲存一些明細數據，而不需要時間字段。如用戶畫像數據，要快速做報表和監控之類，數據量非常大，就比較適合用 ES。而像日誌這樣的就適合用 Druid。
蘇寧多維報表平臺的性能優化
針對性能優化，我們的主要策略就是緩存。首先分幾個場景：
非日誌類數據，定時更新(典型的是用戶畫像)。
日誌類數據(append only，時間分區)：定時更新。
日誌類數據(append only，時間分區)：實時更新。
場景一：非日誌類數據，定時更新(典型的：用戶畫像)
日誌類數據(appendonly，時間分區)：定時更新、實時更新
日誌類數據的特點是：歷史數據一旦存儲好，就不會變動，針對歷史數據的查詢，可以進行加速優化：
緩存。
預計算。
針對熱門報表，如銷售，用戶經常使用的維度組合可以提前做預計算，來加速。
蘇寧多維報表平臺的業務策略與架構選擇
權限控制
蘇寧有 30+大區，500+城市公司，1500+門店，1300+易購服務站，如何給 8000 人開一張報表的權限?方法有二：
維護報表權限維度：大區、城市公司、門店等。
抽取 ERP 中人員身份信息，進行權限自動匹配。
衍生指標計算-同比、環比、占比
基礎指標：由當前數據直接計算得出，無需其他數據。
衍生指標：一般由多個基礎指標數據(不同指標或不同維度)計算得出，甚至需要第三方數據確定。
邏輯：如判斷哪一天是同比天，需要第三方邏輯數據。
衍生指標計算
復購率。
財務指標：(xx產品結構實際進銷差率- 其他產品結構進銷差額/ 其他產品結構付款金額)*變動比例(銷售占比平均值-銷售占比實際值)*產品總付。
蘇寧多維報表平臺的未來展望
未來，蘇寧平臺的 SQL 統一由 Calcite 支撐，還有多模型組合。目前，蘇寧還是單模型組合，因為用戶希望在一張報表既能看到流量，又能看到銷售數據，後期會進行多模型組合，還會做一些可視化方面的建設。
王富平
蘇寧大數據中心高級架構師
歷任百度大數據部高級工程師、 1 號店搜索與精準化部門架構師，一直從事大數據方向的研發工作，對大數據工具、機器學習有深刻的認知，在實時計算領域經驗豐富。2013 年，基於公司實時處理平臺設計開發了 SQL on Stream 解決方案。熱愛分享和技術傳播。目前關註方向為數據分析平臺建設，旨在提供一個平臺級別的數據服務，打造“數據即服務”的一站式解決方案。
以上內容根據王富平老師在 WOTA2017 “大數據應用創新”專場的演講內容整理。
本文出自 “12562290” 博客，請務必保留此出處http://12572290.blog.51cto.com/12562290/1946618
如何給 8000 人開一張報表的權限？蘇寧多維報表平臺應用實踐！