1 OLAP平臺架構演進

• Hive to MySQL
• 基于Kylin的OLAP平臺建設階段
• 支持多種OLAP引擎的平臺建設階段

1.1 Hive2MySQL

圖片

從無到有：落地簡單。

1.1.1 問題

• 受限于MySQL能力，無法支持大數據量的存儲與快速查詢
• 缺少共性能力沉淀，需求驅動，Case byCase解決問題，定制開發時間較長

數據流程簡單，數據處理流程簡單，數據包括日志、DB log等，經Sqoop批量或Kafka實時接入大數據平臺HDFS里，在大數據平臺進行ETL后，通過大數據調度系統Ooize，每天定時寫入到關系型數據庫MySQL，再以MySQL中數據為基礎產出各種報表。

該階段是OLAP平臺架構從無到有的一個過程，很多公司在初始的時候都是按該架構設計實現

1.1.2 特點

① 架構簡單，幾個初級甚至中級工程師就能搭好，快速落地跑通

② 報表查詢性能差，所有結果數據都存儲在OLTP型MySQL，MySQL無法支持大數據量查詢，百萬級到千萬級別數量，MySQL性能明顯下降

③ 需求驅動、高層抽象不足，缺少共性能力沉淀，case by case的開發模式，即按業務數據需求，從數據采集接入、數據處理、數據調度全流程“煙囪式”開發，沒有將共性的數據處理方法或手段沉淀，導致每個需求開發時間都長，大量重復工作。

總之，該階段無沉淀共性的數據處理方法，不具備平臺化。

隨業務迅速發展，數據應用需求增加，數據分析任務量越來越重，Hive2MySQL問題逐步暴露，原始架構升級改造是必然。

1.1.3 改造目標

① 解決MySQL無法支持海量數據分析查詢的問題

MySQL分析能力不足問題的問題，引入能支持大數據量的OLAP引擎（存儲與快速查詢），經調研選擇Kylin

② 平臺化，沉淀共性能力

需求驅動，平臺化不夠，需建設公司級OLAP 平臺，即指標平臺。

指標：業務單元細分后量化的度量值

• 維度：觀察數據的角度，如時間、地點
• 度量：需統計聚合的值，如GMV、帶看量

圖片

對需求驅動、缺少共性沉淀，平臺化不夠：

• 一方面規范化數倉建模，沉淀一些可復用性的中間層表，即借鑒業界通用經驗分為ODS、DWD、DWS、OLAP等層
• 另一方面引入一個指標和指標平臺，通過指標向公司各業務線提供數據分析服務。指標是業務單元細分后量化的度量值，包括維度（即看數的角度）和度量（需要統計聚合的值）。指標平臺將數倉開發人員的維度建模（星型或雪花模型）暴露成業務方容易理解的指標。

1.2 基于Kylin

引入OLAP引擎Kylin

在Kylin之上引入指標平臺：

• 對外提供統一的API
• 指標統一定義，統一口徑管理
• 實現指標查詢

應用層統一通過指標API來獲取數據，不直接使用SQL訪問Kylin。

基于前面思考，就有基于Kylin的OLAP平臺架構。從底向上分3層：

• OLAP引擎層，此處即Apache Kylin，只支持Apache Kylin引擎
• Kylin之上是指標平臺，對外提供統一API、指標統一定義和口徑管理以，支持指標高效查詢
• 最上面應用層，XX一個數據可視化產品和各種數據應用產品，它們通過統一的指標API來獲得數據，不直接使用SQL訪問Kylin。Kylin下面的Hive數據倉庫層里有ODS、DWD、DWS、OLAP各層數倉表

2 指標平臺

2.1 指標定義

圖片

每個指標通過很多維度去描述，上圖展示一個指標包含基本信息及血緣。

基本信息包含指標名稱，如帶看量_集團？若是房產相關公司，就是賣房租房都要帶客去看，所以這是重要指標。

關注指標的支持維度，即允許業務方從哪些維度去看數據，如：

• 分公司編碼，代表一個分公司的帶看量
• 運營管理大區編碼維度，代表運營管理大區的帶看量

支持從組織架構的不同層級查看集團帶看量。

也可以查看區域的帶看量，可以看某個具體人的帶看量，可以看到20多個維度的帶看量。另外比較關鍵的信息，指標的口徑描述了指標計算方式。通過這個指標定義，方便了解指標信息及直觀定義。

指標是指是對維度建模（星型或雪花模型）的抽象，指標包括維度和度量，分別對應維度建模中的度量和維度。

許多使用指標時需要了解的重要信息，如指標的口徑描述了指標計算方式。

指標類型

• 原子指標，即基礎指標
• 派生指標：基礎指標+業務限定。對于一個已有的指標，不管是原子還是派生的還是復合的，都可以對它進行再派生，加一些條件，就可以得到一個新的派生指標
• 復合指標：通過指標四則運算生成新的指標。

指標平臺實現指標的統一定義和口徑管理。

所有的指標的定義和口徑都是在指標平臺進行管理的。各個業務方都主要通過在OLAP平臺上定義和使用指標，來實現多維數據分析的。

2.2 指標查詢

指標平臺對外提供統一的API來獲取指標數據，上圖就是一個指標調用參數示例，參數傳到指標平臺，指標平臺會根據調用參數自動轉換為Kylin查詢SQL，對Kylin發起查詢，獲得數據，并根據需求進一步處理。

左圖調用參數，轉化成對應Kylin SQL如右圖：

圖片

左邊的指標調用參數，JSON直觀。如startDatae為開始日期，endDate為截止日期，描述需查詢哪個時間范圍的指標數據；filter表示過濾條件，如city_code等于11000，表示要查看北京的帶看量。Json中還可以配置是否分頁，是否需要計算同環比。Json查詢參數傳送到指標平臺，指標平臺負責將調用參數轉換成對底層OLAP查詢引擎Kylin的查詢語句。從生成的Kylin SQL中可以看到，startDate及endDate被轉換成了一個SQL中的過濾條件，dim描述的city_code轉換為groupby聚合語句。參數與SQL的這類轉換映射關系，在指標開發的時候，通過在Kylin的Cube模型里面定義的，調用人員就不需要顯示指定。為提高查詢性能，Kylin也會做一些維度補全的工作，如示例中的sun_dt及month這類層級維度。

2.3 指標API應用

圖片

指標完成開發之后，就可在內部可視化平臺利用指標配置各種報表，也可以自己開發數據應用產品，在產品里調用指標API獲取數據。

上圖展示利用指標在可視化平臺中配置報表的救命，通過在數據源中選擇一個指標，指標對應的維度和度量呈現出來。通過拖拽維度、度量便能快速完成報表。內部也有大量的數據產品通過調用指標API來獲取指標數據。

3 Kylin選型及簡介

為什么選擇Kylin？根據第一階段的問題，需求是：

• 支持百億級別大數據量
• 比較快的響應時間
• 能夠支持較高的并發

通過選型測試Kylin正好滿足。

3.1 OLAP選型：Apache Kylin

• 最初由eBay開發貢獻至Apache開源社區
• 支持大規模數據，能夠處理TB乃至PB級別的分析任務，支持高并發、亞秒級查詢
• 其核心思想是預計算，即對多維分析可能用到的度量進行預計算，將計算好的結果保存成cube，供之后查詢

3.2 Kylin架構

圖片

核心思想就是預計算，對多維分析可能用到度量進行預計算，把預計算結果存在Cube，供后續查詢。Kylin整體架構如上。

3.2.1 主要模塊

① Metadata管理模塊

先要知道咋預計算，即知曉哪些維度和度量，Kylin要求用戶先定義Cube來獲得這些信息，Cube定義支持星型或雪花模型，由Metadata模塊管理。

② Cube Build Engine

提供Cube構建引擎做預計算，支持MR引擎、Spark引擎、Flink引擎，將預計算結果存到HBase。

③ 查詢引擎（Query Engine）

用戶可通過REST API及JDBC/ODBC來查詢Kylin，利用SQL來查詢Cube數據，Kylin的Query Engine會把SQL等查詢請示自動轉化為對底層HBase查詢。

3.3 解決維度爆炸

預計算一個最大問題“維度爆炸”，維度組合太多，計算量過大。Kylin咋優化呢？只是Kylin基于大數據平臺實現這套，使它可支持海量數據，而之前基于這種預計算方式的引擎支持的數據量很有限。

這樣，在OLAP平臺就

3.3.1 建立標準的指標開發流程

圖片

• Cube定義和創建：Kylin
• 指標創建：指標平臺

有在Kylin中操作的部分，也有在指標平臺操作的部分。所以是圍繞Kylin來構建的OLAP平臺。

3.3.2 指標（Kylin）使用統計

經過兩三年推廣，基于Kylin的OLAP平臺在公司得到了較廣泛的應用，支撐整個公司指標體系的建立，覆蓋所有業務線。目前，平臺上有：

• 6000多個指標
• 日均調用量大概2000w
• 99.5%的指標調用3內返回

3.3.3 Kylin相關工作和應用情況

https://www.slidestalk.com/Kyligence/ApacheKylinInBeike

在Kylin使用過程中，為了保障Kylin的穩定性及提升Kylin構建和查詢性能，圍繞Kylin做的工作：

• Kylin監控管理平臺建設
• Kylin優化與定制改造
• Kylin與公司內部大數據系統的整合

Kylin在公司內應用現狀：

• 800多個Cube
• 300多TB的存儲量，總的數據量大約1600億以上，單個Cube最大有60個億以上
• 日查詢2000萬+
• Kylin的實例大概在100以上，30個以上HBase節點

4 新問題

指標大量推廣使用后，業務方也反饋許多問題：

4.1 指標支持的維度數量有限

很多業務方的指標一般有30-40個維度；為了滿足需求，數倉開發人員只能把一個指標拆成幾個指標，限制每個指標的維度數量，導致指標維護和管理困難

4.2 Cube構建時間長

特別是數據規模增大以后，導致指標的產出時間較晚

4.3 靈活性不夠

每次修改Cube（維度變更）需全量回刷Cube，耗時時間長

4.4 性能優化困難

Kylin基于HBase存儲預計算結果，Rowkey的設計對性能影響很大，性能可以相差幾十上百甚至上千倍。指標的開發人員往往是一些數倉人員，對HBase的理解不夠深刻，難以進行性能優化

4.5 不支持實時指標

Kylin3.0引入了實時指標支持。

通過分析，我們總結出，問題的根源在于Kylin的預計算原理，全量預計算：

• 計算量大，耗時長
• 如有部分變更就需要重算，如果只依賴Kylin是沒法解決的

因此，團隊認為單一Kylin引擎無法滿足公司不同業務場景下的應用需求，OLAP平臺需要能夠針對不同的業務場景使用不同的OLAP引擎。

5 最終階段-支持多種OLAP引擎的OLAP平臺

5.1 目標

• 靈活支持各種引擎，可插拔OLAP引擎綁定
• 指標平臺與OLAP引擎解耦，支持動態切換OLAP引擎
• 應用接口層保持一致

5.2 架構

圖片

引入其他引擎如Druid、Clickhouse、Doris，中間增加查詢引擎層，其中標紅的是Cube管理負責管理Kylin中遷移過來的指標。統一指標API屏蔽了底層接口，保證兼容性，應用層保持不變。

5.3 新架構改動關鍵

① 統一Cube定義與管理

將Cube定義和管理從Kylin中解耦到指標平臺：

• 為了兼容用戶的使用習慣，指標平臺設計中參考Kylin、Mondrian等Cube定義原理
• 在指標平臺及底層OLAP引擎中引入抽象層
• 實現Cube動態綁定到不同的OLAP引擎

② 查詢引擎

• 在指標平臺與底層OLAP引擎之間引入統一的查詢接口（結構化）
• 屏蔽不同引擎查詢語言的差異，保證數據應用層，如XX可視化、圖靈等數據應用產品也不受底層多引擎切換影響
• 查詢引擎把統一的查詢請求轉換到特定的一個引擎，同時，提供路由、壟斷能力

圖片

圖片

查詢引擎會根據傳入的指標調用參數自動生成不同引擎的查詢語句，指標平臺不用再承擔這部分工作。

③ 標準化指標開發流程

圖片

• 構建Cube：對Druid/CK/Doris就是完成數據源(表)的導入
• 以Druid引擎為例：構建Cube就是根據Cube中的Join關系生成臨時寬表，將寬表導入Druid

這樣一來，指標開發流程變得更加通用，雖各節點不變，但所有工作都在指標平臺實現，不用強依賴Kylin。整個開發流程語義有變，如：

• 對Kylin構建Cube語義，是真實的執行預計算
• 對Druid/CK/Doris等構建Cube，就是一個數據源（表）導入

具體而言，Druid引擎構建Cube，就轉換為根據Cube中的Join關系生成寬表，指標平臺會把對指標的查詢轉換照寬表查詢。針對Doris引擎，支持較好的關系關聯Join查詢，就不用轉換為寬表，直接把幾個維表和事實表都導入，直接執行Join查詢。因此，不同引擎有不同語義。

5.4 指標開發工具

圖片

為更好實現指標開發，我們開發了一站式指標開發工具VILI，整個指標開發過程，包括數倉規劃和建模，Cube建模，指標定義、指標加工，復合指標加工等都在該工具上實現。類似于實現阿里的OneData體系。

現在 OLAP 平臺能夠靈活地支持不同的 OLAP 引擎，該選啥 OLAP 引擎？

6 OLAP平臺架構演化歷程

6.1 OLAP技術選型

① 數據量

能支持多大量級的數據量，例如 TB 級甚至更大；

② 查詢性能

• 響應時間快不快，是否支持亞秒級響應
• 支持的 QPS，在高 QPS 的情況下整體查詢的性能怎么樣

③ 靈活性

靈活性沒有具體的標準， OLAP 引擎是否支持 SQL、是否支持實時導入、是否支持實時更新、是否支持實時動態變更等等，這些都是靈活性的體現，具體要求是根據自己的應用需求來確定；

目前沒有一種開源 OLAP 引擎能夠同時滿足這三個方面，在 OLAP 引擎選型時，需要在這三個方面之間進行折衷，3選2。

圖片

目前開源 OLAP 引擎數量比較多，往好說百花齊放，但也說明這塊很混亂。

6.2 分類原則

• 第一看架構原理，MPP或批處理
• 第二看是否有自定義存儲格式，管理自己的數據，即是否存儲與計算分離

首先是 SQL on Hadoop，它又可分兩類：

• SQL on Hadoop – MPP，基于 MPP 原理實現的引擎，像Presto、Impala、Drill，特點是通過 MPP 的方式去執行 SQL，且不自己管理存儲，一般查 HDFS，支持 Parquet 或 ORC 通用列式存儲格式；它可以支持較大的數據量，具有較快的響應時間，但是支持的 QPS 不高，往往具有較好的靈活性，支持 SQL、Join
• SQL on Hadoop – Batch，即Spark SQL 或 Hive，把 SQL 轉換成 MR 或 Spark 任務執行，可以支持非常大的數據量，靈活性強，對 SQL 支持度高，但是響應時間較長，無法支持亞秒級響應

存儲計算不分離的，即引擎自己管理存儲的，其架構可能基于 MPP 或 Scatter-Gatter 的或預計算的，這類 OLAP 引擎的特點是，可以支持較大的數據量，具有較快的響應時間和較高的 QPS，靈活性方面各 OLAP 不同，各有特點，如有些對 SQL 支持較好，有些支持 Join，有些 SQL 支持較差。

了解這些，再結合業務權衡。公司業務方一般對響應時間和 QPS 要求均較高，所以基本只能在自帶存儲引擎里的類型中選擇。Kylin 是已經在用，其他主要關注 Druid，Clickhouse 和 Doris。

6.3 OLAP引擎對比

圖片裂開了！

對于數據量和查詢性能（包括響應時間和高并發），這幾個引擎的支持都是不錯的，可以滿足公司 TB 級的需求。

靈活性關注的幾個方面主要包括對 SQL 的支持、實時數據導入、實時更新、Online Schema 變更等特性，這些是在業務需求處理中經常需要用到的特性。

6.4 案例介紹Druid

Druid使用統計

• 目前 Druid 主要用于離線指標
• 實時指標測試中(不支持實時精確去重和實時Update)
• 大概承擔了平臺 50% 左右的流量，性能還不錯
• 3s 的返回率大概在 99.7%
• 相比于 Kylin，Druid 引擎在 Cube 構建速度和存儲空間使用方面均有較大的優勢，能夠有效解決 Cube 構建時間長，指標產出較晚，和指標變更耗時的問題。

以目前在 Druid 平臺上訪問量 Top 12 的表（Datasource）為對象，對比分析它們在 Kylin 和 Druid 上的數據導入時長和數據膨脹率情況。

圖片裂開了！

大部分表的 Cube 構建時長在 Druid 要比在 Kylin 上快 1 倍以上，而對一些維度多、基數大的表，Kylin 的預計算量巨大，Druid 上的導入時間要比 Kylin 上快 3、4 倍。

圖片裂開了！

Kylin上數據的膨脹率遠大于Druid，一般是幾倍，十幾倍，甚至幾百倍，這也是由Kylin的原理（即用空間換時間）所決定的。

圍繞 Druid 引擎的工作

• Druid 監控管理平臺建設：及時發現和解決 Druid 各種線上問題，保障平臺的穩定
• Druid 優化與定制改造：

增加精確去重功能支持

大查詢監控與處理

數據導入優化

查詢優化

gc調優

• Druid 與公司內部大數據系統的整合：和公司大數據系統、元數據管理平臺、調度系統等內部系統進行整合；

CK 和 Doris 都是基于 MPP 的，有自定義的存儲格式。目前主要用于實時指標和明細數據查詢，承擔了小部分流量，在 1%-2% 左右，現在還在進一步深度測試。

7 規劃

• 推廣應用 Druid、Clickhouse、Doris 等不同引擎，進一步完善各 OLAP 引擎監控管理平臺，優化和完善引擎能力
• 實現多個 OLAP 引擎的智能路由，能夠根據數據量、查詢特征（例如 QPS 等）之間做自動/半自動的遷移和路由
• 與 Adhoc 平臺實現融合，對一些頻率高查詢慢的查詢可以路由到 OLAP 平臺上
• 進一步完善和優化實時指標支持，目前實時指標只是基本上把整個流程走通了，引入多種 OLAP 引擎后將進一步考慮如何更好的支持實時指標