1 OLAP平臺架構(gòu)演進

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

1.1 Hive2MySQL

圖片

從無到有：落地簡單。

1.1.1 問題

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

數(shù)據(jù)流程簡單，數(shù)據(jù)處理流程簡單，數(shù)據(jù)包括日志、DB log等，經(jīng)Sqoop批量或Kafka實時接入大數(shù)據(jù)平臺HDFS里，在大數(shù)據(jù)平臺進行ETL后，通過大數(shù)據(jù)調(diào)度系統(tǒng)Ooize，每天定時寫入到關(guān)系型數(shù)據(jù)庫MySQL，再以MySQL中數(shù)據(jù)為基礎產(chǎn)出各種報表。

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

1.1.2 特點

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

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

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

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

隨業(yè)務迅速發(fā)展，數(shù)據(jù)應用需求增加，數(shù)據(jù)分析任務量越來越重，Hive2MySQL問題逐步暴露，原始架構(gòu)升級改造是必然。

1.1.3 改造目標

① 解決MySQL無法支持海量數(shù)據(jù)分析查詢的問題

MySQL分析能力不足問題的問題，引入能支持大數(shù)據(jù)量的OLAP引擎（存儲與快速查詢），經(jīng)調(diào)研選擇Kylin

② 平臺化，沉淀共性能力

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

指標：業(yè)務單元細分后量化的度量值

• 維度：觀察數(shù)據(jù)的角度，如時間、地點
• 度量：需統(tǒng)計聚合的值，如GMV、帶看量

圖片

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

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

1.2 基于Kylin

引入OLAP引擎Kylin

在Kylin之上引入指標平臺：

• 對外提供統(tǒng)一的API
• 指標統(tǒng)一定義，統(tǒng)一口徑管理
• 實現(xiàn)指標查詢

應用層統(tǒng)一通過指標API來獲取數(shù)據(jù)，不直接使用SQL訪問Kylin。

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

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

2 指標平臺

2.1 指標定義

圖片

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

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

關(guān)注指標的支持維度，即允許業(yè)務方從哪些維度去看數(shù)據(jù)，如：

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

支持從組織架構(gòu)的不同層級查看集團帶看量。

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

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

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

指標類型

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

指標平臺實現(xiàn)指標的統(tǒng)一定義和口徑管理。

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

2.2 指標查詢

指標平臺對外提供統(tǒng)一的API來獲取指標數(shù)據(jù)，上圖就是一個指標調(diào)用參數(shù)示例，參數(shù)傳到指標平臺，指標平臺會根據(jù)調(diào)用參數(shù)自動轉(zhuǎn)換為Kylin查詢SQL，對Kylin發(fā)起查詢，獲得數(shù)據(jù)，并根據(jù)需求進一步處理。

左圖調(diào)用參數(shù)，轉(zhuǎn)化成對應Kylin SQL如右圖：

圖片

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

2.3 指標API應用

圖片

指標完成開發(fā)之后，就可在內(nèi)部可視化平臺利用指標配置各種報表，也可以自己開發(fā)數(shù)據(jù)應用產(chǎn)品，在產(chǎn)品里調(diào)用指標API獲取數(shù)據(jù)。

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

3 Kylin選型及簡介

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

• 支持百億級別大數(shù)據(jù)量
• 比較快的響應時間
• 能夠支持較高的并發(fā)

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

3.1 OLAP選型：Apache Kylin

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

3.2 Kylin架構(gòu)

圖片

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

3.2.1 主要模塊

① Metadata管理模塊

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

② Cube Build Engine

提供Cube構(gòu)建引擎做預計算，支持MR引擎、Spark引擎、Flink引擎，將預計算結(jié)果存到HBase。

③ 查詢引擎（Query Engine）

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

3.3 解決維度爆炸

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

這樣，在OLAP平臺就

3.3.1 建立標準的指標開發(fā)流程

圖片

• Cube定義和創(chuàng)建：Kylin
• 指標創(chuàng)建：指標平臺

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

3.3.2 指標（Kylin）使用統(tǒng)計

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

• 6000多個指標
• 日均調(diào)用量大概2000w
• 99.5%的指標調(diào)用3內(nèi)返回

3.3.3 Kylin相關(guān)工作和應用情況

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

在Kylin使用過程中，為了保障Kylin的穩(wěn)定性及提升Kylin構(gòu)建和查詢性能，圍繞Kylin做的工作：

• Kylin監(jiān)控管理平臺建設
• Kylin優(yōu)化與定制改造
• Kylin與公司內(nèi)部大數(shù)據(jù)系統(tǒng)的整合

Kylin在公司內(nèi)應用現(xiàn)狀：

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

4 新問題

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

4.1 指標支持的維度數(shù)量有限

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

4.2 Cube構(gòu)建時間長

特別是數(shù)據(jù)規(guī)模增大以后，導致指標的產(chǎn)出時間較晚

4.3 靈活性不夠

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

4.4 性能優(yōu)化困難

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

4.5 不支持實時指標

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

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

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

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

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

5.1 目標

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

5.2 架構(gòu)

圖片

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

5.3 新架構(gòu)改動關(guān)鍵

① 統(tǒng)一Cube定義與管理

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

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

② 查詢引擎

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

圖片

圖片

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

③ 標準化指標開發(fā)流程

圖片

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

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

• 對Kylin構(gòu)建Cube語義，是真實的執(zhí)行預計算
• 對Druid/CK/Doris等構(gòu)建Cube，就是一個數(shù)據(jù)源（表）導入

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

5.4 指標開發(fā)工具

圖片

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

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

6 OLAP平臺架構(gòu)演化歷程

6.1 OLAP技術(shù)選型

① 數(shù)據(jù)量

能支持多大量級的數(shù)據(jù)量，例如 TB 級甚至更大；

② 查詢性能

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

③ 靈活性

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

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

圖片

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

6.2 分類原則

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

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

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

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

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

6.3 OLAP引擎對比

圖片裂開了！

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

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

6.4 案例介紹Druid

Druid使用統(tǒng)計

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

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

圖片裂開了！

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

圖片裂開了！

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

圍繞 Druid 引擎的工作

• Druid 監(jiān)控管理平臺建設：及時發(fā)現(xiàn)和解決 Druid 各種線上問題，保障平臺的穩(wěn)定
• Druid 優(yōu)化與定制改造：

增加精確去重功能支持

大查詢監(jiān)控與處理

數(shù)據(jù)導入優(yōu)化

查詢優(yōu)化

gc調(diào)優(yōu)

• Druid 與公司內(nèi)部大數(shù)據(jù)系統(tǒng)的整合：和公司大數(shù)據(jù)系統(tǒng)、元數(shù)據(jù)管理平臺、調(diào)度系統(tǒng)等內(nèi)部系統(tǒng)進行整合；

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

7 規(guī)劃

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