智慧運維基礎：運維知識庫之 ETL
作者簡介
乾貨概覽H++
百度雲高階研發工程師
負責百度雲Noah智慧運維產品元資料建設、時序資料儲存相關研發工作，在分散式系統架構、高效能資料服務、資料清洗等方向有著較為廣泛的實踐經驗。
在百度智慧化運維的持續演進過程中，我們在逐步建設以智慧運維機器人為核心的運維能力，將其應用於故障自愈、根因定位、智慧變更等運維場景中。而建設以智慧運維機器人為核心的運維能力，最基礎的工作是要先建立運維的世界觀（環境模型），以機器人的視角來理解運維世界、感知系統狀態、獲取環境變化等。
在傳統運維模式中，運維資料分散在不同的系統中，這些運維資料存在幾個問題：訪問方式不一致；資料術語、概念、模型不一致；系統間沒有資料關聯。
這些問題使得我們日常的運維工作，經常需要理解、處理各種不同的資料，導致運維成本高，效率難以提升。因此希望建立運維知識庫統一運維工作中的語言，對運維工作中的物件進行統一建模，收集並轉錄日常運維工作的資源與操作，為日常運維工作提供一種『書同文，車同軌，行同倫』的基礎。（PS：借鑑自秦始皇）
本文主要介紹百度雲Noah智慧運維產品，在構建運維知識庫過程中的思考。
運維知識庫中的資料
運維知識庫中包含了元資料（Meta）、狀態資料（Status）、事件資料（Event）：
- 運維元資料（Meta）對運維實體世界進行建模，包括運維實體的屬性、組成以及關聯關係等；
- 狀態資料（Status）反應系統的狀態，表徵服務的存活性、資源消耗或能力等；
- 事件資料（Event）描述對系統做的變更、服務狀態的異常等事件。
ETL系統架構
運維元資料、狀態資料、事件資料分佈在幾十個不同的系統中，隨著業務的增長和相關係統的不斷增加暴露出了以下幾個問題：
- 資料分散，訪問方式不一致：同一型別的資料分散在多個不同的系統，各系統提供不同的訪問入口；
- 資料術語、概念、模型不一致：各系統使用的術語、概念、模型各不相同，例如“應用”這個概念，每個系統或工具對於Application的理解都不盡相同；
- 系統間資料沒有建立關聯：例如部署、監控和路由服務等核心場景在運維資料上沒有打通，表現為部署平臺、路由服務、監控系統所使用的服務管理機制各不相同，三個系統間的資料難以關聯，且無聯動性。
因此，依託『書同文』的理念建立運維知識庫，提供一個統一的運維資料管理系統，來管理運維工作中的公共基礎資料，打通系統間的資料關聯，使這些資料能夠遵循統一的模型被共享和使用。
為了使這些資料能夠遵循統一模型，我們制定了各類資料的模型（Schema），採用ETL機制從各系統獲取（Extract）資料、轉換（Transform）成統一的模型、並存儲（Load）在知識庫中，其架構如圖所示。
這些運維資料在建設時根據業務對資料時效性要求的不同，分為以下三種：
離線資料建設，例如用於運維變更效率指標統計等相關的資料；
- 近線資料建設，例如故障診斷過程中依賴的資料；
- 實時資料建設，例如智慧故障自愈、智慧流量排程相關的路由資料等。
對於上述不同的資料我們採用不同的ETL方式，分別是：
- 拉 （Pull ETL），週期性從資料來源拉取資料，適用於離線資料的建設；
- 推 （Push ETL），資料來源主動推送變更的資料，適用於時效性較高的近線資料建設；
- Federation （Lazy ETL），在查詢時從資料來源獲取資料、按照Schema轉換後並返回，適用於實時資料建設。
Pull ETL
Pull ETL提供了兩種資料接入方式：自適應ETL、基於SDK的自定義ETL。
自適應ETL，是我們針對適用範圍較廣的資料來源（如百度名字服務BNS、Noah監控平臺、Noah部署平臺等）開發的，使用者僅需配置好ETL規則，自適應排程器會自動解析規則，並將資料按規則接入運維知識庫。
基於SDK的自定義ETL，是我們為其他資料來源提供的ETL方式，使用者基於我們提供的SDK可以開發各種資料來源的ETL指令碼，配置好排程策略，通用排程器根據排程策略執行ETL指令碼，即可將資料接入運維知識庫。
Push ETL
Push ETL採用訊息佇列（MQ），來支援時效性高的資料建設。資料來源發生變更時，需要將變更訊息推送至MQ，運維知識庫訂閱、消費這些訊息，並轉換、儲存資料。
如下圖所示，使用者基於SDK開發Push ETL指令碼，排程器執行指令碼並保證其一直處於執行狀態。資料來源推送變更訊息至MQ，Push ETL指令碼訂閱MQ中的變更訊息，將變更的資料轉換成統一的模型並存儲在知識庫中。
Lazy ETL
Lazy ETL是為實時資料查詢而提供的ETL模式。在運維領域我們需要看到系統的某些元資料/狀態的實時變化，比如實時路由資料、監控系統的時序資料等。Pull ETL由於是週期性的執行，因此在時效性上無法滿足需求；Push ETL需要資料來源進行改造，有一定的成本，且變更訊息傳輸存在一定的延遲，無法實時查詢到最新資料。
因此，如下圖所示，我們採用另一種經典方法Federation（Lazy ETL）來實現資料整合：即運維知識庫處理使用者查詢時，直接呼叫介面去訪問原始資料來源，按schema轉換後，返回給使用者。
總結
本文主要介紹了百度雲Noah智慧運維產品中的運維知識庫之ETL。針對不同業務場景使用的資料，提供不同的ETL方式。針對離線資料建設，採用Pull ETL週期性從資料來源獲取資料，此外綜合考慮資料接入收益和成本，提供了自適應ETL以及基於SDK的自定義ETL；針對時效性高的資料建設，採用Push ETL，資料來源主動推送變更到運維知識庫中；針對實時資料建設，採用Lazy ETL，在查詢時回源獲取資料並進行轉換。有對運維知識庫和ETL感興趣的同學，歡迎留言探討。
本文轉載於公眾號 AIOps 智慧運維
2018 年即將遠去
2019 年即將到來~
新的一年
運維行業怎麼能不搞事情呢？
GOPS 2019 · 深圳站
早鳥票限時搶購