滴滴 OLAP 引擎細分多種場景，如靈活分析、固化分析、熱點資料等，針對不同場景的特性，使用不同的場景引擎。Apache Kylin 作為滴滴 OLAP 引擎內部的固化分析場景引擎，間接服務了滴滴下游多個重要的資料產品，覆蓋了十多條業務線，為使用者提供了穩定、可靠、高效的資料分析效能。
更多幹貨內容請關注微信公眾號“AI 前線”，（ID：ai-front）
為什麼需要重視區分資料訪問場景？怎麼區分資料訪問場景？
本質上，資料訪問場景是一類資料訪問需求，資料訪問需求可以通過考察以下幾個方面進行歸類識別：
期望進行的查詢以及各個查詢的查詢頻度和佔查詢總量的比例；
每類查詢（行、列、位元組等）結果的資料量級分佈；
讀取和更新資料的關係，如讀寫比例、資料更新粒度等；
資料的工作規模以及在本機使用資料的方式；
事務以及事務隔離級別的需求；
資料副本和邏輯完整性的需求；
對每類查詢的延遲和吞吐量的需求；
等等，針對不同的資料訪問場景，需要定製不同的資料儲存、檢索、傳輸以及計算加工方案，只有這樣，才能藉助場景特性，設計更有針對性的實現方案，以更加契合該場景下的資料使用，最大化整體資料訪問效能。
典型的資料訪問場景有：OLTP（On-Line Transaction Processing）場景和 OLAP（On-Line Analysis Processing）場景，OLAP 場景下至少又可細分為以探索分析為目的的靈活分析和有嚴格資料訪問模式的固化分析兩類場景，這裡提到的嚴格資料訪問模式是指在資料產出前就已確定可對該資料執行哪些具體分析，其有明確的邊界，更具體地是指該資料存在固定的分析維度，固定的分析指標以及在指標之上有固定的聚合方式。
表 2.2-1 對靈活分析和固化分析進行了對比總結：
在網際網路企業，尤其是以資料驅動為核心的網際網路企業，靈活分析和固化分析二者不可或缺，其中固化分析的一種主要應用就是報表類資料產品（當然，並非唯一，其他應用方式也不可忽略）。靈活分析和固化分析二者的整合催生了滴滴支援多場景的 OLAP 引擎的誕生。
當前，OLAP 引擎眾多。在大資料領域，如 Hive，依賴 Hadoop 提供的可靠儲存和計算能力，為使用者提供穩定的分析服務，再比如 Presto、Spark SQL，突出記憶體計算，可以滿足使用者快速的分析需求。這些產品雖然側重不同，但都能覆蓋靈活分析和固化分析場景需求。
但從嚴格意義上講，這些產品在設計上都沒有細分兩種場景，而是將二者抽象為一類分析需求，即認為只有一種場景，這樣設計的好處是可以統一領域問題處理，但因為模糊了兩種場景各自的特點，在兩種使用場景共存的應用中，總體資料訪問效能上存在較大的提升空間。
滴滴 OLAP 引擎，區分靈活分析和固化分析，同時對於熱點資料，也作為一種特有場景進行處理。
圖 3.2-1 OLAP 引擎方案（忽略部分元件關聯連線）
如圖 3.2-1，整體方案上，查詢請求首先進入 OLAP 引擎，查詢路由會基於後設資料選擇合適的場景引擎，然後根據所選擇的場景引擎重寫查詢，完成重寫的查詢會被髮往場景引擎完成執行並返回查詢結果。
此外，OLAP 引擎還包含了一個資料轉移決策模組，可以根據使用者提供的先驗知識及自身決策將資料轉移到更契合的場景引擎。排程模組根據這一決策觸發資料在場景引擎間的“複製”，以及無效“副本”的清除。新生成的“複製副本”通常會提供比老舊“副本”更好的訪問效能，即需要花費更小的訪問 Cost（代價）。
章節 2.2 中已經分析了固化分析場景的特點，不難發現，該場景下非常適合對資料進行聚合預計算並快取聚合結果，即聚合快取。
固化分析有固定的分析維度、指標及其聚合方式，查詢邊界明確，對原始明細資料執行聚合預計算，並將結果快取到 Key-Value 儲存，不僅可以緩解每次分析查詢給叢集帶來的計算壓力，Key-Value 儲存也可以提升查詢效能。通常地，聚合預計算結果相對於原始的明細資料在規模上會有明顯的量級下降，這也是 OLAP 場景的一個特性。
章節 3.3 分析了固化分析場景的實現方案，在技術選型時選擇使用 Apache Kylin，主要因為 Kylin 提供了以下三個特性：
針對明細資料進行聚合計算；
將聚合結果儲存到 HBase；
針對明細和聚合結果支援標準的 SQL 訪問；
上述三個特性不僅提供了完備的聚合快取能力，同時也支援 SQL 訪問，因此接入成本相對較低，另外，Kylin 也提供了成熟的優化查詢的方法，如 HBase RowKey 序、字典編碼等等，在一定程度上方便了使用優化。
Kylin 作為固化分析場景引擎，主要負責對有聚合快取需求的表進行查詢加速。什麼樣的表會有這樣的需求呢？
報表類產品使用的表；
經 OLAP 引擎資料轉移決策識別認為需要進行聚合快取的表；
前者不難理解，後者則如引擎中的表，表資料規模較大，且被頻繁執行某種聚合分析，在一段時間內達到一定的頻次，引擎會識別並認為該表需要執行聚合快取，進而觸發排程將資料“複製”到 Kylin。這樣，下次針對該表的聚合分析如果可被 Kylin 的聚合快取覆蓋，就會直接查詢 Kylin 中的聚合資料“副本”而非原始的明細資料“副本”。
滴滴使用 Kylin 的方式與傳統方式有異，Kylin 在架構設計上與業務緊耦合，傳統方式中業務分析人員基於 Kylin 建模、構建立方體（Cube），然後執行分析查詢。但滴滴將 Kylin 作為固化分析場景下的引擎使用，提供針對表的聚合快取服務，這樣作為一個通用資料元件的 Kylin 就剝離了業務屬性，且與使用者相割裂，對外透明。
在最初的使用中，由於沒有控制 OLAP 引擎的內部併發，來自排程的聚合快取任務會在某些情況下高併發地執行 Kylin 的表載入、模型和立方體的建立，因為 Kylin Project 後設資料的更新機制導致操作存在失敗的可能。當前，我們通過在 OLAP 引擎內部使用佇列在一定程度上緩解了問題的發生，此外，結合重試機制，基本可以保證操作的成功完成。最後我們也注意到，該問題在最新的 Kylin 版本中已經進行了修復。
另外，Kylin 預設地，在刪除立方體時不會解除安裝 HBase 中的 Segment 表，而需定期執行指令碼進行清理。這樣，就導致引擎執行時及時解除安裝無效的立方體無法級聯到 HBase，給 HBase 造成了較大的運維壓力。因此我們也對原始碼進行了調整，在立方體刪除時增加了 HBase Segment 表清理的功能，等等。
圖 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 工具、資料地圖、資料分析平臺、建模平臺等系列產品穩定、高效地服務使用者的資料需求。