實踐 | Kylin在滴滴OLAP引擎中的應用

做者 | 滴滴數據平臺團隊

編輯 | Vincent

AI 前線導讀：企業的生產活動會產生各類各樣的數據，數據做爲企業最重要的資產之一，價值巨大，數據價值的獲取須要對其進行不斷訪問（或讀或寫），不一樣的數據訪問需求就構成了相互區別的數據訪問場景，只有按照場景定製數據的存儲、檢索、傳輸以及計算加工方案，纔有可能提供總體最優的數據訪問性能。

滴滴 OLAP 引擎細分多種場景，如靈活分析、固化分析、熱點數據等，針對不一樣場景的特性，使用不一樣的場景引擎。Apache Kylin 做爲滴滴 OLAP 引擎內部的固化分析場景引擎，間接服務了滴滴下游多個重要的數據產品，覆蓋了十多條業務線，爲用戶提供了穩定、可靠、高效的數據分析性能。

更多幹貨內容請關注微信公衆號「AI 前線」，（ID：ai-front）

數據訪問場景

2.1 重視區分數據訪問場景

爲何須要重視區分數據訪問場景？怎麼區分數據訪問場景？

本質上，數據訪問場景是一類數據訪問需求，數據訪問需求能夠經過考察如下幾個方面進行歸類識別：

1. 指望進行的查詢以及各個查詢的查詢頻度和佔查詢總量的比例；

2. 每類查詢（行、列、字節等）結果的數據量級分佈；

3. 讀取和更新數據的關係，如讀寫比例、數據更新粒度等；

4. 數據的工做規模以及在本機使用數據的方式；

5. 事務以及事務隔離級別的需求；

6. 數據副本和邏輯完整性的需求；

7. 對每類查詢的延遲和吞吐量的需求；

等等，針對不一樣的數據訪問場景，須要定製不一樣的數據存儲、檢索、傳輸以及計算加工方案，只有這樣，才能藉助場景特性，設計更有針對性的實現方案，以更加契合該場景下的數據使用，最大化總體數據訪問性能。

2.2 典型的數據訪問場景

典型的數據訪問場景有：OLTP（On-Line Transaction Processing）場景和 OLAP（On-Line Analysis Processing）場景，OLAP 場景下至少又可細分爲以探索分析爲目的的靈活分析和有嚴格數據訪問模式的固化分析兩類場景，這裏提到的嚴格數據訪問模式是指在數據產出前就已肯定可對該數據執行哪些具體分析，其有明確的邊界，更具體地是指該數據存在固定的分析維度，固定的分析指標以及在指標之上有固定的聚合方式。

表 2.2-1 對靈活分析和固化分析進行了對比總結：

在互聯網企業，尤爲是以數據驅動爲核心的互聯網企業，靈活分析和固化分析兩者不可或缺，其中固化分析的一種主要應用就是報表類數據產品（固然，並不是惟一，其餘應用方式也不可忽略）。靈活分析和固化分析兩者的整合催生了滴滴支持多場景的 OLAP 引擎的誕生。

支持多場景的 OLAP 引擎

3.1 OLAP 引擎現狀

當前，OLAP 引擎衆多。在大數據領域，如 Hive，依賴 Hadoop 提供的可靠存儲和計算能力，爲用戶提供穩定的分析服務，再好比 Presto、Spark SQL，突出內存計算，能夠知足用戶快速的分析需求。這些產品雖然側重不一樣，但都能覆蓋靈活分析和固化分析場景需求。

但從嚴格意義上講，這些產品在設計上都沒有細分兩種場景，而是將兩者抽象爲一類分析需求，即認爲只有一種場景，這樣設計的好處是能夠統一領域問題處理，但由於模糊了兩種場景各自的特色，在兩種使用場景共存的應用中，整體數據訪問性能上存在較大的提高空間。

3.2 滴滴 OLAP 引擎

滴滴 OLAP 引擎，區分靈活分析和固化分析，同時對於熱點數據，也做爲一種特有場景進行處理。

圖 3.2-1 OLAP 引擎方案（忽略部分組件關聯連線）

如圖 3.2-1，總體方案上，查詢請求首先進入 OLAP 引擎，查詢路由會基於元數據選擇合適的場景引擎，而後根據所選擇的場景引擎重寫查詢，完成重寫的查詢會被髮往場景引擎完成執行並返回查詢結果。

此外，OLAP 引擎還包含了一個數據轉移決策模塊，能夠根據用戶提供的先驗知識及自身決策將數據轉移到更契合的場景引擎。調度模塊根據這一決策觸發數據在場景引擎間的「複製」，以及無效「副本」的清除。新生成的「複製副本」一般會提供比老舊「副本」更好的訪問性能，即須要花費更小的訪問 Cost（代價）。

3.3 固化分析場景實現方案

章節 2.2 中已經分析了固化分析場景的特色，不難發現，該場景下很是適合對數據進行聚合預計算並緩存聚合結果，即聚合緩存。

固化分析有固定的分析維度、指標及其聚合方式，查詢邊界明確，對原始明細數據執行聚合預計算，並將結果緩存到 Key-Value 存儲，不只能夠緩解每次分析查詢給集羣帶來的計算壓力，Key-Value 存儲也能夠提高查詢性能。一般地，聚合預計算結果相對於原始的明細數據在規模上會有明顯的量級降低，這也是 OLAP 場景的一個特性。

Apache Kylin 做爲固化分析場景引擎

4.1 固化分析場景引擎選型

章節 3.3 分析了固化分析場景的實現方案，在技術選型時選擇使用 Apache Kylin，主要由於 Kylin 提供瞭如下三個特性：

1. 針對明細數據進行聚合計算；

2. 將聚合結果存儲到 HBase；

3. 針對明細和聚合結果支持標準的 SQL 訪問；

上述三個特性不只提供了完備的聚合緩存能力，同時也支持 SQL 訪問，所以接入成本相對較低，另外，Kylin 也提供了成熟的優化查詢的方法，如 HBase RowKey 序、字典編碼等等，在必定程度上方便了使用優化。

4.2 Apache Kylin 在場景引擎中承擔的工做職責

Kylin 做爲固化分析場景引擎，主要負責對有聚合緩存需求的表進行查詢加速。什麼樣的表會有這樣的需求呢？

1. 報表類產品使用的表；

2. 經 OLAP 引擎數據轉移決策識別認爲須要進行聚合緩存的表；

前者不難理解，後者則如引擎中的表，表數據規模較大，且被頻繁執行某種聚合分析，在一段時間內達到必定的頻次，引擎會識別並認爲該表須要執行聚合緩存，進而觸發調度將數據「複製」到 Kylin。這樣，下次針對該表的聚合分析若是可被 Kylin 的聚合緩存覆蓋，就會直接查詢 Kylin 中的聚合數據「副本」而非原始的明細數據「副本」。

4.3 使用 Apache Kylin 遇到的挑戰

滴滴使用 Kylin 的方式與傳統方式有異，Kylin 在架構設計上與業務緊耦合，傳統方式中業務分析人員基於 Kylin 建模、構創建方體（Cube），而後執行分析查詢。但滴滴將 Kylin 做爲固化分析場景下的引擎使用，提供針對表的聚合緩存服務，這樣做爲一個通用數據組件的 Kylin 就剝離了業務屬性，且與用戶相割裂，對外透明。

在最初的使用中，因爲沒有控制 OLAP 引擎的內部併發，來自調度的聚合緩存任務會在某些狀況下高併發地執行 Kylin 的表加載、模型和立方體的建立，由於 Kylin Project 元數據的更新機制致使操做存在失敗的可能。當前，咱們經過在 OLAP 引擎內部使用隊列在必定程度上緩解了問題的發生，此外，結合重試機制，基本能夠保證操做的成功完成。最後咱們也注意到，該問題在最新的 Kylin 版本中已經進行了修復。

另外，Kylin 默認地，在刪除立方體時不會卸載 HBase 中的 Segment 表，而需按期執行腳本進行清理。這樣，就致使引擎運行時及時卸載無效的立方體沒法級聯到 HBase，給 HBase 形成了較大的運維壓力。所以咱們也對源碼進行了調整，在立方體刪除時增長了 HBase Segment 表清理的功能，等等。

4.4 Apache Kylin 在場景引擎中的使用效果

圖 4.4-1 爲 Kylin 在滴滴 OLAP 引擎中的部署狀況，Kylin 集羣包含 2 臺分佈式構建節點、8 臺查詢節點，其中 2 臺查詢節點做爲集羣接口承接 REST 請求，REST 請求主要包含兩類：構建做業狀態查詢和建立類操做，建立類操做如裝載表、建模、建立立方體以及對等的刪除操做等等。對於構建做業狀態查詢輪詢請求兩臺節點，而對建立類操做則請求其中固定的一臺節點，另外一臺做爲 Standby 存在，這樣設計的主要目的是避免集羣接口的單點問題，同時解決因 Kylin 集羣元數據同步機制致使的可能出現的建立類操做失敗問題。

圖 4.4-1 Kylin 集羣部署

目前，Kylin 集羣維護了 700+ 的立方體，每日運行 2000+ 的構建做業，平均構建時長 37 分鐘，立方體存儲總量 30+TB（已去除 HDFS 副本影響）；對未使用緩存的查詢進行統計，80% 的查詢耗時小於 500ms，90% 的查詢耗時小於 2.8 秒。須要說明的是，因爲 OLAP 引擎中「數據轉移決策」模塊會根據查詢場景觸發數據「複製」到 Kylin 中來，在近期的統計中，立方體數量一度會達到 1100+。

在業務方面，Kylin 間接服務了下游數易（面向全公司的報表類數據產品）、開放平臺（面向全公司的查詢入口）等多個重要數據產品，覆蓋了快車、專車等十多個業務線的分析使用，間接用戶 3000+，Kylin 的引入爲用戶提供了穩定、可靠、高效的固化分析性能。

總結

滴滴 OLAP 引擎細分了靈活分析、固化分析、熱點數據等幾類場景， Kylin 做爲固化分析場景引擎在滴滴 OLAP 引擎中承擔了重要角色。引擎使用 Kylin 提供的：針對明細數據進行聚合計算，將聚合結果存儲到 HBase，針對明細和聚合結果支持標準的 SQL 訪問三個特性透明地服務用戶。當前，引擎服務了下游多個重要數據產品，覆蓋了十多個業務線，爲用戶提供了穩定、可靠、高效的數據分析性能。

Kylin 做爲中國人主導的第一個 Apache 頂級開源項目，覆蓋場景重要，社區活躍，資料豐富，將來咱們將更加專一於 Kylin 在滴滴 OLAP 引擎應用場景下的穩定性以及查詢、構建優化。

做者介紹

鄭秋野，滴滴數據平臺高級專家工程師，滴滴數據系統團隊負責人。

靳國衛，滴滴數據平臺專家工程師，主要負責 OLAP 引擎建設。

張曉東，滴滴數據平臺高級工程師，主要負責 OLAP 引擎元數據設計開發以及 Apache Kylin 集羣運維。

關於滴滴數據平臺團隊

滴滴基礎平臺部數據平臺團隊負責公司數據倉庫建設、數據治理以及基礎數據工具研發等，團隊提供 OLAP 引擎、Adhoc 工具、數據地圖、數據分析平臺、建模平臺等系列產品穩定、高效地服務用戶的數據需求。