元資料是自動化運維的基礎，對元資料的管理和查詢貫穿整個運維的生命週期。我們從乙個元資料的使用場景開始：
雙十一搶購火熱進行中，某電商後端例項的日誌**現了502錯誤碼，運維平台監測到該異常並傳送告警給相關運維。
在這個過程中，運維元資料發揮了什麼作用？回答這個問題前，我們先回顧下元資料是什麼。
運維系統中的元資料報括服務、機器及其關聯關係。服務元資料有服務名稱、所屬節點、運維人員以及網域名稱等；機器元資料報含序列號、記憶體等資產資訊，ip、機房等網路資訊、自定義標籤資訊以及執行例項等部署資訊。這些資料由資源管理模組維護。
資源管理模組對業務以樹的形態劃分層級，形成服務樹，從上到下依次為產品線、系統和應用三類節點。
每個層級都可以關聯機器，且上層節點包含下層節點的機器。
通過新增節點的運維及研發角色，可以實現對服務和機器的許可權控制。
這種層級結構將服務與服務，服務與機器關聯起來，可以直觀的表達服務和機器的歸屬關係，便於實現許可權和配置的繼承。
智慧型監控
回到上面的問題，報警流程中，服務所在機器的監控客戶端查詢自己所屬的應用，然後從配置管理模組拉取相應監控配置，實現對日誌的監控；監控業務端收到監控資料後，查詢該機器對應的節點資訊，將報警傳送給節點的運維等人員。
此外，在devops落地實踐中，還存在多種其他應用場景
拓撲檢視
服務間關係拓撲可由遠端過程呼叫協議（rpc）間的呼叫關係鏈自動更新或者在應用上簡單維護服務間上下游關係。根據rpc呼叫關係鏈自動更新的關係拓撲圖主要用在業務運維上，可以幫助運維人員進行故障診斷，對整個業務系統執行狀態和部署架構全域性一覽，清晰便捷. 應用上手工維護服務間上下游關係，可以用於上線版本依賴控制。上線申請單中指定上線版本依賴服務的版本，上線時系統自動檢查依賴的版本是否已經完成上線，如果依賴版本未上線，終止本次操作。
批量運維
基於應用服務樹節點及許可權，規範化批量任務執行操作。日常運維過程中，運維需要對線上機器進行一些批量操作，比如公升級軟體版本、打補丁，清理日誌等。為了避免手工操作帶來的風險，只允許運維同學，選擇所屬許可權目標機器，進行操作。對於高危命令，可新增審批機制，增加流程規範。
堡壘機
當機器規模、人員規模逐漸擴大時，如何管理人、機器、許可權會變得很複雜。通過元資料的動態管理，使用者只需要在服務樹上對人員進行角色設定，即可登入堡壘機，獲得自己有許可權的列表。通過服務樹的角色同樣可以新增哪些角色擁有su許可權等訪問策略控制。
持續交付
持續整合、自動化測試、持續交付都可以基於元資料，實現資料的唯一性管理。研發側，提交**，自動觸發服務樹應用對應的編譯任務，根據編譯規範生成部署包，放到版本庫；運維側，則對資源進行分配抽象到服務樹，將版本庫裡面的**發布到服務樹例項對應的機器上；對於使用者側，通過負載均衡的接入，可以動態的進行服務樹例項流量的開關和擴縮容；部署日誌則可以按照應用日誌服務模組進行檢索，方便排查問題。
在上面的監控流程中，客戶端和業務端是機器和服務關係資料的消費方，現實的運維場景中，二者也是運維資料的主要需求方。
客戶端指安裝在機器上，用以執行特定任務的程式，其需要的資料報括當前機器相關的資訊，如機器機房、機架等裝置屬性和歸屬節點、部署服務等業務屬性。
業務端主要指運維平台中的上層系統，比如監控、部署等，當然也有跨平台的其他系統，其需求涵蓋服務、機器與許可權之間的相互查詢。
大規模運維場景中元資料查詢面臨的壓力
生產環境中，客戶端需要頻繁發起查詢請求，以保證其資料的準確性。持續增長的機器規模給系統帶來的壓力不容小覷。業務端由於複雜多樣的業務場景，其查詢條件多種多樣，查詢頻率和規模無法估量、難以控制，對系統可靠性和可用性提出了較高的要求。
傳統關係型資料庫難以承受高併發的查詢壓力，簡單的快取又難以滿足條件複雜的查詢需求。
如何面對以上壓力，提供高效高可用的查詢服務，是亟需解決的問題。
實現高可用查詢–名字服務
為了應對以上兩種場景的挑戰，devops引入了專注於提供資料查詢的名字服務，既可以實現服務的解耦，防止外部查詢影響資源管理模組的效能，又可以提供高效穩定的查詢功能。
服務和機器資料由資源管理模組維護，儲存到資料庫。名字服務定時從資源管理模組同步資料，直接面向其他業務端和客戶端提供查詢服務。為提高響應速度，減少io，元資料以map的形式儲存於記憶體中。
名字服務有三個邏輯層級，分別是同步、儲存和查詢，我們從這三個方面了解下其如何實現高可用：
保證資料的實效性和服務的可擴充套件性
同步的流程如下
服務啟動時：優先從本地存在快取檔案恢復資料，然後增量從資源管理模組同步資料，以減小資料庫壓力，並快速提供服務；如果沒有快取檔案，則從資源管理模組查詢全量資料。
服務正常執行時：實時與資源管理模組進行增量資料同步，同步的時間點以上次同步的時間戳為準；為進一步保證資料準確，需定期全量同步資料；定期更新快取檔案。
若同步資料出現異常：不更新當前資料，僅儲存異常時時間戳，以後的每次同步時間點從該時間戳開始。
由於該模組定時從資源管理模組增量/全量更新資料，在保證資料的準確性的同時對資料庫的壓力是線性且可控的，並且執行過程不依賴其他服務，因此查詢壓力增加時，可以通過水平擴容來迅速提高請求承載量。
通過快取熱點資料提高查詢效率
回顧下開始的那個場景：監控客戶端會定期查詢獲取最新的資料。假設每分鐘請求一次，那麼10萬台機器就帶來了上千的 qps，如果每個客戶端請求多個介面或者每個機器部署多種客戶端，這個數值就會翻倍。
針對這種常用的查詢場景，名字服務通過快取熱點資料來提高查詢效能。
假設客戶端需要通過 ip（也可能是uuid）查詢例項列表，而記憶體中例項是以id為key儲存的。如果依次遍歷全部例項進行ip匹配，會有一定的效能開銷。此時如果有乙份ip與例項id的關聯關係的快取，即可首先定位到對應例項的id，然後直接獲取id對應例項的詳情。
諸如此類的快取，可以是產品線與機器的歸屬關係、機房與機器的關聯關係以及應用與例項從屬關係等。
由於資料同步環節是由名字服務主動發起的，所以該索引可以在每次更新之後重新生成，來保證其準確性。
支援多維度資料查詢
上述快取不能窮舉所有查詢資訊，服務節點和機器的屬性（如機房、執行環境等）和標籤（如報警策略和其他運維自定義的標識等）都可能成為資料查詢的條件。針對此種情況，名字服務在快取資料時將屬性和標籤解析為key-value模型，使用規定的請求格式便可實現查詢。
格式定義為key1_value1.keys_value2.keyn_valuen，其中常規屬性的key以大寫字母開頭，自定義標籤的 key以小寫字母開頭。例如，當名字服務收到格式為product_trade.idc_huabei.env_pre的查詢請求時，會先根據product獲取trade產品線的機器id集合，然後與huabei機房的機器id集合取交集，再根據該id集合獲取機器集合，最後在機器集合中根據標籤匹配出pre環境的機器集合。
devops將元資料的管理與查詢業務分開維護，元資料的變更通過資源管理實現，資料查詢通過名字服務實現。資源管理通過層級結構維護了服務和機器的關係，並通過角色實現許可權的劃分。
名字服務只依賴資源管理，便於搭建，易於擴容，可以提供穩定的服務；結合業務場景，通過對熱資料快取實現了較高的查詢效率；支援多條件查詢，滿足複雜的業務需求。
元資料管理
大資料倉儲越來越重視元資料的管理，但是元資料怎麼管理，還處於探索階段。這樣帶來的弊端顯而易見，就是1 及時性達不到，2 準確性達不到，3 同步性也達不到。它只是結項的必交的文件而已。二 越來越多的角色的人使用數倉，迫切需要乙個介面展示具體指的意思，業務統計口徑等，用乙個web介面展示，但是後端還是e...
元資料管理
元資料管理的核心功能如下 在操作方式上分為自動採集和手動採集兩種 同時，提供採集日誌資訊的檢視，檢查採集是否成功。檢視採集日誌可以查詢到採集任務的如下資訊 開始時間 任務狀態 結束時間 過程日誌，採集的數量等等。元資料採集完成後，儲存在資料庫中，支撐包括元資料統計 查詢 血緣分析 影響性分析 資料資...
HDFS元資料管理
hdfs的目錄結構，包含哪些資料夾子資料夾，以及資料夾下面包含哪些檔案，以及每個檔案的block資訊 id,副本係數，block存放在那個datanode上 元資料存放在 name路徑下。在namenode的記憶體中有乙個樹形結構，存放的就是元資料資訊，對檔案的任何修改都在記憶體中有體現，但是如果機...