'滴滴：Apache Kylin 自助式治理與演進之路'

kylin在滴滴的應用，在7月份的技術論壇上，滴滴出行的技術專家靳國衛分享了kylin在滴滴的應用。

PPT 主要分為四個部分，第一部分講一下 Kylin 架構在滴滴的實際情況，展示集群數據規模，進而引出一些問題；第二部分講在滴滴如何進行集群的治理；第三部分結合具體實際場景講為什麼做字典改造，及其改造的過程和收益；最後留一些時間回答下大家的提問。

平臺架構、數據展示

此圖是 Kylin 數據服務架構。滴滴的數據場景大部分都是自助服務式的。主要過程如下：

1. 用戶自己通過可視化平臺完成數據分析、報表發佈。這個過程動態產生數據模型、ETL 數據生產、Cube 創建與調度等。
2. 建模、資源隔離、智能調度、版本管理模塊負責數據的生產。比如，用戶自助創建了一張報表，這時候平臺需要根據用戶的操作過程完成數據建模，完成調度創建，集群選擇，多次發佈帶來的數據版本管理。而用戶只需要關心數據來自哪裡，數據可視化如何組織。
3. 集群的核心服務是查詢，比如，接收到查詢請求後，查詢中心會結合元數據中心判定本次查詢是否命中了 Kylin 的 Cube，如果命中 Cube 則從 Kylin 集群獲取數據，否則通過 Adhoc 查詢從 Spark 或者 Presto 獲取數據。
4. 自動化運維和集群管理模塊後面會詳細介紹。

目前我們一共部署了 7 個 Kylin 集群，分國際和國內集群，服務基本上涵蓋了公司的絕大多數服務。每天構建任務 7000 左右，Cube 數量 5 千以上。

為什麼需要做集群治理呢？是因為絕大多數服務都是自助拖拽式完成的，所以主要壓力是 Kylin 集群原數據膨脹。下面講下滴滴是如何治理 Cube 元數據的。

服務治理

1. 基本架構

上文中的架構圖中的 Kylin1、Kylin2 都是一個 Kylin 集群。具體到單個集群，分三類角色節點：query、build 和 status。然而 Kylin 本身只有 job 和 query 兩種節點類型，後面會詳細講為什麼要增加 status 類型的節點。

Kylin 集群的核心是查詢能力，查詢服務是它的 SLA，要求查詢服務穩定可靠，所以 query 節點通過 VIP（Virtual IP）來實現查詢的負載均衡。

我們每天有 7 千個任務需要構建，構建節點相應會多一點，build 節點可以設置構建任務併發量。但是因為字典的構建是在 build 節點單機完成的，如果併發量設置太高，會對 build 造成一定壓力，所以要根據負載合理設置併發數。

status 節點提供 API 服務與開放平臺進行交互，實現集群元數據變更。為什麼要有 status 節點，為什麼要實現 active/standby 在下文會有詳細解釋。

2. 集群治理

集群治理從幾個方面來說明：

① 為什麼會有多集群？

1. 根據實驗後發現 Kylin 節點所佔用資源其實不大，所以將 Kylin 節點實現為一個 Docker 節點；
2. 當一個集群中 Kylin 的元數據達到一定程度，穩定性會有一些問題，各個業務對服務穩定性要求不同，要求獨立部署。

基於這兩個方面考慮，就實現了集群、節點動態伸縮功能。

② 既然有多個集群就會有幾個問題：

1. 業務和集群如何進行資源綁定；
2. 集群間負載不均衡如何做壓力轉移。

所以要實現資源的動態轉移。

③ 為什麼要實現 Status 節點的 HA？

節點的部署對象是 Docker 鏡像，裡邊包含了 Kylin、Spark、HBase、Hadoop、Hive 的 rpm 包，在Docker 啟動的時候會隨系統啟動一個 kylin-agent，agent 主要負責 Kylin 啟動、資源管理、存活監控的工作。

節點啟動時，會去配置中心讀取當前這個節點的配置信息，包括節點類型、屬性配置等，然後 agent 更新 隨 Docker 啟動的默認配置，啟動 Kylin 服務、監控等。在這個過程，可以通過配置化方式實現 Kylin 節點、集群的動態伸縮。基於服務發現的集群管理在測試中，不久將提交社區。

此圖是簡化後樣例，包含：

1. 集群名稱。
2. 集群的 servers 列表列出集群的 IP 集合。
3. 覆蓋默認的集群配置，實現集群間的差異。比如滴滴有兩個 HBase 集群：0.98 和 1.4.8，Kylin 集群使用哪個 HBase 集群可以配置在覆蓋屬性這裡。
4. build & query & status 節點的組成 IP 集。

3. 負載均衡

集群的負載主要是：查詢的壓力，構建壓力。然而查詢和構建是和 Cube 綁定的，所以只要能實現 Cube 在集群間的流轉就可以控制查詢與構建的壓力。只要實現了 Cube 的集群間流轉就實現了查詢與構建壓力的流轉，然後結合集群的負載監控以及 Cube 的流轉調度，就可以實現集群間負載的相對平衡。

實現思路：我們實現 Cube 集群間流轉，核心點就是當創建 Cube 的時候如何決定 Cube 創建到哪一個集群上，之後查詢和構建的壓力就落在該集群上。

具體實現：

1. 當有 Cube 創建需求的時候，就會把這個請求存儲到一個有序隊列。
2. 然後開放平臺會消費隊列中的 Cube 創建請求轉發到 Kylin 集群去創建 Cube。
3. 配置中心記錄 2 條核心配置：
4. 1）用戶可以在哪些集群創建 Cube；
5. 2）各個集群接收 Cube 的佔比是多少；
6. 開放平臺讀取配置中心的配置，經過簡單的計算之後就能確認該 Cube 創建請求應該發送到哪個集群。

舉例：基於用戶與集群的配置關係可以實現用戶的資源隔離。基於集群接收 Cube 的佔比，比如 A 集群 ：B 集群 = 1 ：3，那麼如果有 4 個請求的話，開放平臺就會向 A 創建 1 個 cube，向 B 創建 3 個 cube。當過一段時間之後，可以根據 A、B 集群的負載在配置中心修改 A 集群與B集群的比例，實現流量的轉移。

為什麼要設計 Active/Standby status 節點？

1. 因為 Kylin 所有的元數據都是在節點啟動的時候加載到內存，在此之後對任何元數據的變更，都是通過廣播的形式告訴其他節點發生了什麼事情。接收到廣播的節點，根據實際的需求來更新內存中的元數據，這樣在廣播失敗或者更新效率慢的時候就會造成集群間元數據不一致的問題。
2. 然後 cube-model-table 的創建會有依賴關係的，比如創建 Cube 的時候，當前節點內存中必須要 Model 的信息，如果廣播沒有完成立刻換一個節點執行 Cube 創建會報錯。

基於以上兩個原因就抽取單獨的節點 status 作為 API 和集群交互的媒介。為了防止單點故障實現了 Active/Standby。除了 table&model&cube 的 CRUD 外，集群內還有其他的元數據廣播。實驗發現 1500+ Cube 的集群使用元數據操作串行的方式比隨機廣播的方式操作失敗的比例大概減少 30%，所以我們在後來的實踐中就改成一個按請求隊列模式，實現集群狀態節點管理。