【導語】在上期的圖數據庫介紹中，我們對什麼是圖數據庫，以及圖數據庫所擅長的領域做了一個初步的介紹，也收到了衆多的反饋和諮詢，特別要求我們對圖數據庫在一些具體行業的應用能做一些深入介紹。爲此，從本期文檔開始，筆者將用一系列文章對圖數據庫在一些專門領域的部署和應用做專題介紹。第一期，將講述圖數據庫在CMDB領域的建模和應用場景。
傳統CMDB的弊端
CMDB，英文名Configuration Management Database，即配置管理數據庫，常常被認爲是構建其他ITIL流程的基礎而優先考慮，ITIL項目的成敗與是否成功建立CMDB有非常大的關係。
從2000年開始，CMDB開始在國內企業慢慢推廣開來，分別經過了最初的資產信息電子化階段、開始與ITSM流程協同配合階段，一直到配置自動化發現引入階段，目前隨着雲計算技術的發展，CMDB的場景已經從傳統的資產臺賬管理逐步演化到流程協同管理、影響分析、配置比對、雲化資源管理等方面，但在CMDB的技術架構上，無論是開源產品還是商業化產品都沒有明顯改進，發展比較緩慢。這在一定程度上也影響了CMDB場景的拓展。
接下來我們將分析當前CMDB建設遇到的一些常見問題。
缺乏合理化、整體化的規劃
需求不清晰，定義了不合理的配置廣度和深度。
大而全還是小而深——選擇猶豫不決
這種決策機制在項目初期往往耗費了大量時間，但隨着新技術的不斷涌現，這種方式已經無法適應越來越敏捷的IT環境，這種相對靜態的CMDB模型已經不能滿足納管新IT組件的要求。
採用了不正確的管控策略
按照經典ITIL的管控和項目實施機制，配置管理規劃，尤其是CMDB模型的規劃往往由項目組承擔，一旦規劃完成後整個模型也就變得很難再進行擴展，應該說這裏採用的是一種集中管控的策略。
但在實際IT運維工作中，我們發現對於CMDB使用最多的是各個二線團隊，不同團隊之間對於CMDB深度和廣度的要求，以及管控方式都有較大差別。
配置管理人員職責定義不清晰
配置經理、配置管理員、配置Owner之間職責不清晰
ITIL或ISO20000中對於這三類角色的定義往往過於寬泛，沒有進一步考慮實際運維人員的運維場景，以及使用的運維工具，導致職責定義和實際做事方式脫節。
角色職責和崗位的對應不明晰
在沒有ITIL以前，在企業IT部門或數據中心往往找不到一個現成崗位對於IT配置信息進行集中管理，而是每個人各管一攤。
實施ITIL後，究竟由哪個部門的哪個崗位承擔配置經理這一職責往往是最讓人傷腦筋的，最後往往是趕鴨子上架。這種角色定義方式最終導致體系無法運轉。
配置管理成了IT運維的負擔
這其實是CMDB在企業落地所面臨的最大挑戰，無法充分調動運維人員的積極性，主要體現在：
初始數據收集工作量大
存量的配置數據往往基數很大，一般配置的量級在5000以上，考慮到雲化環境的海量運維場景，這個基數還會更大。
隨着分佈式應用架構以及微服務架構的興起，未來一套新應用系統上線引入新的配置項數量也無法簡單通過手工輸入的方式來完成。
單一的自動化配置發現工具只是一種幻想
如前所說，約從2007年開始，業內引入了自動發現工具用以解決配置數據的初始化問題，但由於這類工具往往由某個廠商提供，導致了配置發現的侷限性，企業往往也要付出較大成本。
投產後由於變更頻繁，數據無法保證及時準確
以往企業一般採用變更操作驅動配置修改（人工修改或自動化發現修改）的方式以確保配置數據的準確性，這種方式往往會出現配置信息的不一致。
如何讓人人“樂於”參與
這裏的參與主要體現在兩個方面：
- 需要使用與自己相關的配置數據時，CMDB可以立即提供；
- 遇到CMDB無法提供的數據時，IT部門可自行在一定標準和約束下擴展滿足本部門運維CMDB模型，支撐部門級的運維場景。
配置數據的價值無法呈現
缺乏清晰的場景定義，包括流程價值、監控價值、BSM價值、雲價值等
單一流程驅動CMDB的場景，無法讓CMDB中的數據流動起來，隨着時間的推移CMDB中的數據就逐漸腐敗——不及時也不準確。
同時，CMDB在技術上作爲一個“數據庫”，要讓其中的數據能夠流動起來，必須明確與之匹配的運維場景。
場景是用來描述與CMDB中某些配置項交互的一組活動，滿足IT部門某一方面的運維管理目標，這一目標可以被度量、跟蹤、改進、可視化，與此同時，CMDB的價值也隨之呈現。
缺乏有效、明確的配置數據集成策略
如前所述，CMDB是一個邏輯上的數據庫，其中的數據需要和企業現有IT環境中的多類數據源進行整合，一套行之有效的數據集成策略和ETL（數據抽取、轉換、轉載）工具也必不可少。
通過以上分析，我們回顧了CMDB的歷史發展過程，以及建設過程中遇到的挑戰。下面來看雲化環境下CMDB又將面臨什麼新問題。
圖數據庫和CMDB
在我們上一篇關於圖數據庫的文章《圖數據庫——大數據時代的高鐵》中，我們已經對圖數據庫有了一個初步的認識，那麼最擅長做風控的圖數據庫爲什麼也能在CMDB領域大展拳腳呢？這就與圖數據庫天生的技術特性密不可分。
CMDB領域中最基本的單位是CI，也就是配置項，CMDB最基礎的功能就是記錄配置項，以及它們的重要屬性和之間的關係。簡單而言，CMDB是用以記錄IT系統中所有類別及其具體屬性，以及其間關聯關係的。如果你只有那麼幾臺設備，手指就能數得過來；如果有幾十臺設備，幾張表也夠了；而如果是成百上千臺，甚至種類就多達幾十種呢？這就必須要有個資產管理系統，否則你怎麼知道這臺設備的前世今生，以及它出了問題應該找誰（哪家供應商）。
而資產管理系統就夠了嗎？設備要用起來，就不能是孤立的，多種設備，以及設備上的系統、軟件必須是連接起來纔有意義，但資產系統顯然管不了這種關聯關係。
而如果使用傳統的關係數據庫，很簡單的想法是一張表對應一種設備類型，表的列就是這種設備的屬性。那問題來了，我加了一種設備怎麼辦？我需要在數據庫裏新建一張表，這個我還能做，因爲我是個系統管理員嘛，這麼簡單的DBA入門工作還是能做的，但程序怎麼辦？它能認出新加的這張表嗎？我可不懂Java、JavaScript……於是只好付錢給我的軟件供應商，讓他再幫我加這一類設備。而作爲軟件提供商，就會面臨各種各樣稀奇古怪的設備類型，那軟件開發人員能把這些類型都內置在裏面嗎？顯然不可能。再一種情況，以前我的資產管理系統對於PC服務器，只需要記錄它的型號、配置即可，突然老闆跟我說今年要作固定資產登記，每臺機器加個標籤，上面是固定資產編號。我又得叫軟件提供商提供新版本了……
簡而言之，傳統的資產管理系統，設備類別不可增，設備屬性也不能增。或者，都可增，但開發代價太大了，不是小公司的開發團隊能鎮得住的，其性能及可維護性也不好。用關係數據庫（RDBMS)來做CMDB是死路一條。而圖數據庫爲CMDB的未來發展指出了一條陽關大道。
圖數據庫屬於NoSQL的一種，其表徵數據的核心稱之爲節點，節點採用Key-Value的方式保存數據，這一點創造性解決了設備類別（CMDB裏叫CI類）的擴展性，可以隨意加一種CI類，也可以隨意在CI類里加一個屬性，而且它不會影響原有數據，也無所謂空與非空。另外，圖數據庫原來主要用於社交網絡，就是小明認識小紅，而小紅是她媽媽的女兒，她媽媽是她爸爸的妻子，同時也是老闆的下屬，那小紅與老闆有什麼社交關係就可以查出來了（如圖1所示）。
人與人之間的關係太複雜，而設備與設備之間的關係（CI項與CI項之間的關係）也類似，應用系統依賴於數據庫節點和中間件節點，而數據庫節點和中間件節點都依賴於操作系統，操作系統運行在虛擬機上，虛擬機又依賴於物理服務器，物理服務器又與存儲相連……那麼，應用系統與存儲其實也是有關聯的。這樣的連接關係，如果用關係數據庫來表示，應該怎麼設計？實際上是無法表達出來的。
在圖2中，我們可以根據CI之間的關係定義不同的關係，例如CI和CI之間是依賴關係、包含關係、運行於關係、安裝在關係，以及連接關係等。而且關係的屬性種類可以根據實際的需求無限制擴展。
CMDB領域中的圖數據模型
圖數據庫一般都有自己獨特的對數據進行描述的方式，即以圖節點和圖邊爲特徵的數據表徵形式。在不同領域的數據結構中圖模型的表現是完全不一樣的。我們將通過一個實際案例來詳細瞭解一下，在CMDB領域的圖模型是如何建模的。
傳統CMDB原始數據分析
傳統CMDB都是把數據存儲在關係型數據庫中，並且分多張表存儲。接下來我們就把數據從關係型數據庫中導出爲.csv格式的表格，用Excel打開。如圖3所示，這是一個包含了UPS、STS、配電櫃、機櫃、物理主機、VM、應用系統等超過20種數據類型的原始數據表格。
圖4是原始數據表中配電櫃子表的數據演示，出於數據隱私的需要，我們隱藏了部分字段的真實信息。其他CI的數據我們就不一一示例，基本上都大同小異。
原始數據關聯關係分析
關於什麼是圖數據庫的“節點”和“邊”我們不再詳述，大家可以參考我們上一篇介紹圖數據庫的文章，到這一步，我們就直接分析如何根據原始數據建立節點和邊的關係數據模型。
第一步是要根據業務需求，確認不同CI之間的關係分類，如我們在表1中所描述的那樣，一般情況下，CI之間的關係就只有表中呈現的那麼多。
第二步，我們把所有的CI和關係的種類都列出來，當然，只需要和業務部門充分溝通。圖5是一個示例。
根據分析結果整理出節點類型和邊類型
根據步驟一和步驟二的整理結果，列出所有的節點類型，如圖6、圖7所示。
根據節點類型和邊類型畫出CMDB系統的圖模型
根據已經整理好的節點類型和邊類型，我們就可以很輕鬆地把基於圖數據庫框架的數據模型畫出來，將來原始關係型數據庫中的結構化數據也會以這種數據模型的架構轉換成圖數據庫中的節點和邊的數據類型，從此不再和關係型數據庫有任何關係。
在圖8中我們可以看到所有CI之間的關係圖譜。圖數據庫的一個最大優點就是數據建模非常方便直觀。傳統關係型數據庫的DBA可以無需做任何修改就把原始的E-R圖直接轉換成圖數據庫的圖數據模型，這一點對業務部門的使用者而言非常方便。
我們在上文談及傳統CMDB的弊端時，曾經說過傳統CMDB的建模非常難以把握CI深度的這個度的關係，而在圖數據庫中這都不會存在問題。管理員可以根據業務需求，隨時修改圖8的圖模型，例如在不同的CI之間建立起邊的聯繫，或者新增加一種節點類型（CI類型），而這一切甚至不需要停機，在線狀態就可以直接修改生效。
CMDB查詢展示
數據模型建好之後，接下去只需要把數據導入圖數據庫即可，對於ITIL管理人員來說，還是要看一下圖數據庫是如何解決傳統CMDB系統弊端的。
查某一個／多個CI向上支撐／向下影響的其他CI，並支持結果按類別篩選
我們首先來看看在CMDB中遇到的最常見問題：查找任意一個CI的影響關係，即如果該CI出現問題，無論是出現故障還是需要做變更，看看這個CI的影響範圍，以及可能的影響職能部門，甚至指定的個人。
在圖9中，我們查找從指定UPS出發，在“結果類型”中填0，表示查詢所有受影響或支撐的CI，在“查詢深度”輸入框中指定步數，輸入10，則表示查詢10步及10步以內受影響或支持的CI。如，UPS到開關是一步影響關係，UPS到開關再到配電櫃就是2步影響關係，以此類推。
在上面的圖展示中，可以對圖進行放大縮小，或者對某一塊區域的圖節點進行放大查看，甚至可以對某一個節點進行查看。
查詢關聯路徑：選擇2個CI，看其間的影響／關聯路徑
查找兩個CI之間的關聯關係也是我們在CMDB系統中經常遇到的問題，傳統的關係型數據庫需要做不同表之間的Join操作，數據量一大就會出現計算時間呈指數級別上升，往往查詢時間會讓管理人員無法忍受。而圖數據庫的查詢時間基本上是在幾毫秒到十幾毫秒之間，較之傳統的關係型數據庫查找時間，可以減少幾個數量級。
我們在“源節點ID”輸入框中輸入第一個CI的ID，如UPSG；在“源節點類型”輸入框中輸入第一個CI的類型，如ups；在“宿節點ID”輸入框中輸入第二個CI的ID，如rs-06D51ER；在“宿節點類型”輸入框中輸入第二個CI的類型，如ps。則表示需要查詢ups爲 UPSG和物理主機rs-06D51ER之間的關聯路徑；在“查詢深度”輸入框中輸入步數，如10，表示查詢到的路徑最長不超過10步。查詢結果見圖10。
查詢某個人管理着哪些CI
查詢某個人管理着哪些CI，在圖數據庫上就是查找和這個人有關聯關係的節點和邊的類型的計算。
我們在CMDB系統中，在“節點ID”輸入框中輸入某個人的姓名，在“節點類型”輸入框中輸入類型，如person，表示查找某個管理員管理着哪些CI；在“最多查出多少個節點”中指定一個數，如100，表示最多查出100個（見圖11）。
類似的查詢場景還有查詢某個機房有哪些CI，如圖12所示。
查詢某個IP被哪個CI使用了
查詢某個IP被哪個CI使用了這是最爲頻繁使用的查詢，傳統關係型數據庫的查詢速度應該也不會慢太多，但是關鍵是我要從查詢到的結果出發去進一步查找該CI的信息，此時圖數據庫就可以展現出更直觀的方式。在圖數據庫上只需要點擊查詢到的CI，就可以從該CI出發，進一步展現和該CI有關係的其他CI，這種查詢可以無限制地做下去，直到找到管理員需要的信息（如圖13所示）。
查詢結果可以以多種直觀的方式展現
圖數據庫對查詢結果的輸出可以非常靈活，可以導出爲.csv格式的表格性數據，但更擅長的還是圖形化界面的展示。
圖形化界面的展示可以是多種形式，例如通過力學排列、樹形排列、層疊排列、環形排列等不同形式展現，方便查看（例圖見圖14、圖15）。
存在的問題
CMDB已經是IT領域一個並不算新穎的話題，甚至有點老生常談，但是通過圖數據庫來重新構建CMDB系統，卻給這個似乎已經步入中年的IT技術重新帶來了青春。在問題管理、資產管理，以及變更管理上，都大大提高了既有的工作效率。
雖然如此，通過圖數據庫來重新構建CMDB系統也存在一些待決的問題，需要各個CMDB的軟件廠商和項目落地的合作伙伴共同去面對和解決。
首先，使用圖數據庫並沒有解決原始數據自動化配置發現的問題。圖數據庫的出現，大大拓展了CI的範圍廣度和深度，將之前運維體系所不能，甚至不敢涉足到的CI數據也納入到管理系統中來，同時查詢性能反而得到了提高，這是一個優點，但是原始數據的自動化配置也是圖數據庫無法繞開的步驟。巧婦難爲無米之炊，如果沒有數據，再強大的平臺也無能爲力，所以圖數據庫還需要配合數據自動化配置發現才能實現最佳效果；
第二，目前市面上基於圖數據庫的CMDB系統基本上都是在既有的ITSM系統上再次改造而來，並沒有廠商開發出原生的基於圖數據庫的CMDB系統。主要原因是圖數據庫技術還比較新，傳統CMDB廠商對其瞭解還不夠深入，所以現在更多的實踐還是在現有CMDB基礎之上的改進和補充。目前已經有一些CMDB的開發廠商正在研究如何把圖數據庫整合到ITSM平臺中，甚至完全替換掉傳統的CMDB技術，讓我們拭目以待。
關於系統選型和配置建議
從2014年開始到現在，圖數據庫已經在目前所有數據庫模型的發展趨勢中名列第一，如圖16所示。目前業界基於圖數據庫開發出來的開源軟件和閉源軟件都不少，其中開源界最有名的是Neo4j，而在閉源的商業軟件則有GraphSQL——一個來自美國硅谷的品牌。
無論是Neo4j還是GraphSQL，他們都是基於原生圖存儲和圖引擎計算的數據庫產品，在原理上完全一致。在產品知名度、軟件易用性上，Neo4j經過多年發展已經更加深入人心，但是在大型企業部署上，例如高可用、高併發、可擴展性等企業級管理功能上卻是GraphSQL明顯勝出。
CMDB領域本身的數據量並不大，關鍵是複雜關係的關聯分析和管理。一個1000人大型企業的CI項目總計在一起一般不會超過50萬個，轉換成圖數據庫中的節點和邊的數據類型後一般在100萬個節點左右甚至以下，邊的數量在1000萬左右。這個數據量對圖數據庫而言都是小兒科，一臺普通的X86服務器就可以滿足要求。如果出於企業級管理的需要，例如高可用、熱備等，就要考慮部署3臺左右的主機，甚至異地數據中心的雙集羣架構。
最後，關於本文中提到的技術框架問題、數據模型，以及如何做到數據同步、如何實現自動化數據配置發現等問題，因篇幅所限無法一一展現，歡迎有興趣的朋友和我們聯繫。
本文所採用的技術平臺由GraphSQL提供支持，在此表示感謝。
作者：董小珊，20年IT從業經驗，曾供職於HP、F5、Citrix。熟知行業應用，對企業級用戶的諮詢、管理、挖掘，有着豐富的經驗。2016年作爲聯合創始人創辦深圳安聯信息技術有限公司，專注於圖數據庫的諮詢與市場。
姚臻，大數據分析專家，尤其是專注於圖數據庫領域，對GraphSQL、Neo4J、InfiniteGraph等不同的開源技術和閉源產品都有比較深入的研究。
譚通，大數據工程架構師，多年C/C++開發經驗，現致力於圖數據庫領域，對圖建模、業務場景算法有豐富的實踐經驗。
責編：仲培藝，關注數據庫領域，尋求報道或者投稿請致郵[email protected]。
本文爲《程序員》原創文章，未經允許不得轉載，更多精彩文章請訂閱2017年《程序員》