貝殼 OLAP 平臺架構演進

**導讀：**隨着大數據的持續發展及數字化轉型的興起，大數據 OLAP 分析需求越來越迫切，不論是大型互聯網企業，還是中小型傳統企業，都在積極探索及實踐 OLAP 引擎選型及平臺架構建設，大數據技術的蓬勃發展過程中產生了大量優秀的 OLAP 引擎，其帶來的好處是，大家在做 OLAP 架構是可以有多種選擇，其帶來的弊端是，如何在衆多 OLAP 引擎中選擇適合業務需求的現狀及後續發展，成爲解決這一行業性難題的關鍵能力。今天會和大家分享下貝殼 OLAP 平臺架構及演進。

今天的分享會圍繞下面三點展開：

OLAP 平臺架構演化歷程

首先和大家分享 OLAP 平臺架構演化歷程，貝殼的 OLAP 平臺架構發展歷程大概可分成三個階段。

第一個階段是 2015 年到 2016 年中期，我們稱之 Hive to MySQL 初級階段；第二個階段是 2016 年到 2019 年初，基於 Kylin 的 OLAP 平臺建設階段，這個階段 OLAP 平臺建設是圍繞 Kylin 引擎來進行的，Kylin 是唯一支持的 OLAP 引擎；第三個階段是 2019 到現在，支持多種 OLAP 引擎的平臺建設階段，該階段是第二個階段的增強與擴展，解耦了 OLAP 平臺與 Kylin 引擎的強耦合，能夠靈活支持除 Kylin 之外的其他 OLAP 引擎。

1. 第 0 階段 - Hive2MySQL 初級階段

Hive2MySQL 初期階段的數據流程很簡單，在這個階段，數據處理流程比較簡單，數據包括日誌、DB log 等，經過 Sqoop 批量或 Kafka 實時接入大數據平臺 HDFS 裏，在大數據平臺進行 ETL 處理後，通過大數據調度系統 Ooize，每天定時寫入到關係型數據庫 MySQL 中，然後再以 MySQL 中的數據爲基礎產出各種報表。

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

① 架構簡單，找幾個初級甚至中級的工程師就能夠搭建好，很快能夠落地跑通。

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

③ 需求驅動、高層抽象不足，缺少共性能力的沉澱，case by case 的開發模式，即按業務數據需求，從數據採集接入、數據處理、數據調度全流程 “煙囪式” 開發，沒有將共性的數據處理方法或手段沉澱，導致每一個需求的開發時間都會比較長，存在大量重複工作。我們之所以稱這個階段是第 0 階段。因爲該階段，沒有沉澱共性的數據處理方法，還不具備平臺化能力。

隨着貝殼業務的迅速發展，數據應用需求的不斷增加，數據分析的任務量也越來越重，Hive2MySQL 的問題逐步暴露，對這種原始架構進行升級改造是一個必然的選擇。改造的目標很直接，解決 MySQL 無法支持海量數據分析查詢的問題；第二就是要平臺化，沉澱共性能力。

對於第一個 MySQL 分析能力不足問題的問題，解決思路很直接，就是引入一個能夠支持大數據量的 OLAP 引擎，這塊經過一系列對比調研，我們選擇了 Kylin，後面會有介紹。

對於需求驅動、缺少共性沉澱，平臺化不夠的問題，我們一方面規範化數倉建模，沉澱一些可複用性的中間層表，即借鑑業界通用經驗分爲 ODS、DWD、DWS、OLAP 等層，鑑於時間關係，就不詳細介紹每一層內容；另一方面引入了一個指標和指標平臺，通過指標來向公司各業務線提供數據分析服務。指標是業務單元細分後量化的度量值，包括維度（即看數的角度）和度量（需要統計聚合的值）。指標平臺將數倉開發人員的維度建模（星型或雪花模型）暴露成業務方容易理解的指標。

2. 第 1 階段 - 基於 Kylin 的 OLAP 平臺架構

基於前面所述的思考，就有了我們第 1 階段，基於 Kylin 的 OLAP 平臺架構。OLAP 平臺的架構如上圖所示，從底向上分爲 3 層：1、 OLAP 引擎層，這裏就是 Apache Kylin，只支持 Apache Kylin 引擎；2、在 Kylin 之上是指標平臺，它對外提供統一 API、指標統一定義和口徑管理以，支持指標的高效查詢；3、在最上面是應用層，就是奧丁（這是我們一個數據可視化產品）和各種數據應用產品，它們通過統一的指標 API 來獲得數據，不直接使用 SQL 訪問 Kylin。另外，Kylin 下面的 Hive 數據倉庫層，裏面有 ODS、DWD、DWS、OLAP 各層數倉表，這裏就不仔細介紹了。

接下來，介紹指標平臺中指標定義功能，每個指標通過很多維度去描述，上圖展示了一個指標包含基本信息及血緣，基本信息包含指標名稱，如帶看量_集團？因爲貝殼是一個房產相關的公司，就是賣房租房都要帶客去看，所以這是一個很重要的一個指標。比較關鍵的信息是，關注指標的支持維度，就是說允許業務方從哪些維度去看數據，例如分公司編碼維度，代表一個分公司的帶看量，運營管理大區編碼維度，代表運營管理大區的帶看量，也可以查看區域的帶看量，可以看某個具體人的帶看量，可以看到 20 多個維度的帶看量。另外比較關鍵的信息，指標的口徑描述了指標計算方式。通過這個指標定義，可以方便的瞭解到指標信息及直觀定義。

在前面提到，指標是指是對維度建模（星型或雪花模型）的抽象，指標包括維度和度量，分別對應維度建模中的度量和維度。在這裏我們看一個指標的具體示例，例如，“帶看量_集團” 指標，可以看到它的度量是對 show_num 字段 count distinct 排重計數，支持的近 20 個維度，包括分公司編碼維度， 運營管理大區編碼等維度，支持從組織架構的不同層級查看集團帶看量。另外還可以看到許多使用指標時需要了解的重要信息，例如指標的口徑描述了指標計算方式。

指標定義中，指標可以分成三類，第一類是原子指標，即基礎指標；第二類是派生指標，對於一個已有的指標，不管是原子還是派生的還是複合的，都可以對它進行再派生，加一些條件，就可以得到一個新的派生指標；第三類就是複合指標，通過指標四則運算生成新的指標。

上圖中右側部分，以 “帶看量_集團“指標爲基礎，在它之上定義了很多的派生指標，這圖也是指標血緣關係的一個展示，比如說” 德佑帶看貝殼房源量 “指標是對“帶看量_集團“指標加上” 經紀人是德佑 “和” 房源是貝殼 “兩個限制條件派生得到的。同樣” 鏈家帶看貝殼房源量 “也是一個類似的派生指標。上圖中“二看佔比_集團“，是一個複合指標，是” 帶看量_集團 “與” 二看量_集團指標“基礎指標的求和。

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

接下來我們看一下指標查詢，前面有說過，指標平臺對外提供統一的 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 這類層級維度。

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

3. Kylin 選型及簡介

介紹指標之後，簡單介紹貝殼第二階段 OLAP 平臺，爲什麼要選擇 Kylin？根據第一階段的問題，我們的需求是：1）支持百億級別大數據量，2）比較快的響應時間，3）能夠支持較高的併發。通過選型測試 Kylin 正好滿足我們的 3 個需求。Kylin 的詳細介紹見以下 PPT。

Kylin 的核心思想就是預計算，對多維分析可能用到度量進行預計算，把預計算的結果存在保存 Cube 中，供後續查詢。Kylin 的整體架構如上圖所示，主要包括三個模塊：

① 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 的查詢。

預計算的一個最大的問題就是 “維度爆炸”，也就維度組合太多，計算量過大。Kylin 提供了很多優化技巧來緩解這個問題。Kylin 的大概原理就是這樣，其實這種方法並不是 Kylin 發明了，只是 Kylin 基於大數據平臺來實現了這一套，使得它可以支持海量的數據，而之前基於這種預計算方式的引擎支持的數據量很有限。

這樣，在 OLAP 平臺就建立了標準的指標開發流程。整個流程如上圖所示。從上面的流程上看：有在 Kylin 中操作的部分，也有在指標平臺操作的部分。這也是爲什麼說是圍繞 Kylin 來構建的ＯＬＡＰ平臺。

經過兩三年推廣，基於 Kylin 的 OLAP 平臺在公司得到了較廣泛的應用，基本上支撐整個公司指標體系的建立，覆蓋了所有的業務線。目前，平臺上有 6000 多個指標，日均的調用量大概 2000 萬以上。99.5% 的指標調用 3 內返回。

在 Kylin 使用過程中，爲了保障 Kylin 的穩定性及提升 Kylin 構建和查詢性能，貝殼也圍繞 Kylin 做了很多工作，主要包括：

也有把相關的優化反饋給社區。

目前，Kylin 在貝殼的應用現狀如下：大概有 800 多個 Cube，300 多 TB 的存儲量，總的數據量大約 1600 億以上，單個 Cube 最大有 60 個億以上；日查詢 2000 萬 +。Kylin 的實例大概在 100 以上，30 個以上 HBase 節點。關於 Kylin 的介紹就簡單介紹到這裏，如果需要了解更多 Kylin 在貝殼的應用情況，可以參考我們公司張如松、馮亮等其他同事之前關於 Kylin 的分享內容。

4. 面臨新的問題

那麼到這裏爲止的話，是不是問題都解決了呢？不是。在指標大量推廣使用後，業務方也反饋了許多的問題。簡單總結一下，主要包括一下幾個方面：

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

② Cube 構建時間長，特別是數據規模增大以後，導致指標的產出時間較晚；

③ 靈活性不夠，每次修改 Cube（維度變更）需全量回刷 Cube，耗時時間長；

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

⑤ 不支持實時指標，Kylin3.0 引入了實時指標支持；

通過分析，我們總結出，問題的根源在於 Kylin 的預計算原理，全量預計算，一方面計算量大，耗時長；另外一方面如有部分變更就需要重算，如果只依賴 Kylin 是沒法解決的。因此，我們認爲單一 Kylin 引擎無法滿足公司不同業務場景下的應用需求，OLAP 平臺需要能夠針對不同的業務場景使用不同的 OLAP 引擎。

5. 第 3 階段 - 支持多種 OLAP 引擎的 OLAP 平臺

爲了支持新的 OLAP 引擎，需要升級第 2 階段 OLAP 平臺架構，這樣就到了第 3 階段 - 支持多種 OLAP 引擎的 OLAP 平臺，其架構如下圖所示：

這個階段 OLAP 平臺將實現以下幾個目標：

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

新架構中，具體改動的幾個關鍵點是：

① 統一 Cube 定義與管理，將 Cube 定義和管理從 Kylin 中解耦到指標平臺中。爲了兼容用戶的使用習慣，指標平臺設計中參考 Kylin、Mondrian 等 Cube 定義原理，在指標平臺及底層 OLAP 引擎中引入抽象層，實現 Cube 動態綁定到不同的 OLAP 引擎。

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

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

這樣一來，指標開發流程變得更加通用，雖然各個節點都不變，但是所有的工作都是在我們指標平臺上實現，不用強依賴 Kylin。整個開發流程語義是有些變化，比如對於 Kylin 構建 Cube 語義，是真實的執行預計算。對於 Druid/CK/Doris 等構建 Cube，就是一個數據源（表）導入。具體而言，Druid 引擎構建 Cube，就轉換爲根據 Cube 中的 Join 關係生成寬表，指標平臺會把對指標的查詢轉換照寬表查詢。針對 Doris 引擎，支持較好的關係關聯 Join 查詢，就不用轉換爲寬表，直接把幾個維表和事實表都導入，直接執行 Join 查詢。因此，不同的引擎有不同的語義。

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

現在 OLAP 平臺能夠靈活地支持不同的 OLAP 引擎，那該選擇哪些 OLAP 引擎？這就到了我們要分享的第 2 部分 OLAP 引擎選型與實踐。

02

OLAP 選型一般關注三個方面：

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

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

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

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

上圖中給出了一些常見的開源 OLAP 引擎。目前開源 OLAP 引擎數量比較多，往好的說是百花齊放，但其實也說明了這塊很混亂。我們對它們進行了一個大概的分類，分類原則第一是看它的架構原理，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，其比較如下圖所示。

對於數據量和查詢性能（包括響應時間和高併發），這幾個引擎的支持都是不錯的，可以滿足公司 TB 級的需求。靈活性關注的幾個方面主要包括對 SQL 的支持、實時數據導入、實時更新、Online Schema 變更等特性，這些是在業務需求處理中經常需要用到的特性。接下來我簡單介紹一下這幾個引擎以及其在貝殼的應用情況，由於時間有限，將主要介紹 Druid。

目前 Druid 主要用於離線指標，實時指標還在測試，大概承擔了平臺 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 的原理（即用空間換時間）所決定的。

與 Kylin 類似，圍繞 Druid 引擎我們做了很多工作，也主要包括以下 3 個方面：

lDruid 監控管理平臺建設：及時發現和解決 Druid 各種線上問題，保障平臺的穩定；

lDruid 優化與定製改造：增加精確去重功能支持、大查詢監控與處理、數據導入優化、查詢優化等；

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

這方面工作，由於時間關係，此處不再詳述。有機會可以單獨交流討論。

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

03

未來工作規劃

現在整個 OLAP 平臺的基本架構已經確定了，能夠支持 Druid、Clickhouse、Doris 等不同引擎，下一步工作將主要包括以下幾個方面：

今天的分享就到這裏，謝謝大家。

分享嘉賓：

肖贊

貝殼 | 資深工程師

肖贊，貝殼找房數據智能中心資深研發工程師。畢業於北京大學，獲得博士學位。在分佈式系統、JavaEE 中間件和大數據系統等方面有多年的研究和實踐經驗，擁有完整的大數據平臺和基礎架構研發經驗，對分佈式存儲、數據平臺架構、數據倉庫等領域有深入的理解和豐富的實踐經驗。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/qgrTKojDeexC0BMoP_6aMQ

猜你喜歡