針對資產數據的數據處理系統的制作方法
【專利摘要】本發明公開了一種針對資產數據的數據處理系統，所述數據處理系統包括邏輯層、緩存層和數據存儲層，其中，所述數據存儲層用于以分別存儲的方式存儲配置項、配置項之間的關系以及配置項的屬性；所述緩存層用于以緩存的形式存儲所述數據存儲層中的數據；所述邏輯層包括查詢優化模塊，用于根據查詢條件查詢所述緩存層，并根據查詢結果確定從緩存層中查詢目標數據還是從所述數據存儲層中查詢目標數據。采用本發明提供的數據處理系統，能夠提高對資產數據的維護效率和查詢效率。
【專利說明】針對資產數據的數據處理系統
【技術領域】
[0001] 本發明涉及數據處理領域，更為具體而言，涉及一種針對資產數據的數據處理系 統。
【背景技術】
[0002] IT資產（實體資產和虛擬資產）是自動化運維的基礎，目前大多數運維系統隨著 業務規模不斷增長都會因為設計問題導致資產數據難以維護、產生錯誤數據等問題，從而 降低自動化運維的效率，嚴重時甚至出現線上故障。
[0003] 目前資產管理多是采用關系型數據庫（例如，MySQL、SQL Server、Oracle等），即 不同類別的資產數據分表存儲在不同表中，資產之間的關系通過表外鍵來關聯。
[0004] 現有的直接通過關系型數據庫（不同類別的資產分表存儲于不同表中）的方式 會帶來如下問題：1.每增加一類資產時需要新建一張表，同時需要增加該類資產的操作、 維護、流程及頁面；2.為資產添加某類屬性時，會給整張表加鎖，導致其它請求阻塞甚至超 時，效率過低；3.資產間關系不明確，從而導致涉及影響范圍之類的問題無法高效給出結 論；4.信息分散，不易統計分析；5.直接通過數據庫聯表，效率低下。
【發明內容】
[0005] 為了解決現有技術所存在的缺陷，本發明實施方式提供一種針對資產數據的數據 處理系統，能以合理的方式存儲資產數據，提高資產數據的查詢和維護效率。
[0006] 本發明實施方式提供了一種針對資產數據的數據處理系統，包括邏輯層、緩存層 和數據存儲層，其中，
[0007] 所述數據存儲層用于以分別存儲的方式存儲配置項、配置項之間的關系以及配置 項的屬性；
[0008] 所述緩存層用于以緩存的形式存儲所述數據存儲層中的數據；
[0009] 所述邏輯層包括查詢優化模塊，用于根據查詢條件查詢所述緩存層，并根據查詢 結果確定從緩存層中查詢目標數據還是從所述數據存儲層中查詢目標數據。
[0010] 可選地，在本發明實施例的一種實現方式中，所述配置項包括資產分類和資產實 例，所述資產實例的第一屬性值存儲在第一表中，所述資產實例的第二屬性值存儲在表結 構不同于所述第一表的第二表中。
[0011] 可選地，在本發明實施例的另一種實現方式中，所述配置項包括資產分類和資產 實例；所述數據存儲層包括：用于存儲屬性信息的第一存儲區，用于存儲資產分類信息的 第二存儲區，用于存儲資產分類與屬性的對應關系的第三存儲區，用于存儲資產分類之間 的關系的第四存儲區，用于存儲資產實例信息的第五存儲區，用于存儲資產實例的屬性值 的第六存儲區；用于存儲資產實例之間的關系的第七存儲區，其中，在第六存儲區中，以橫 表的形式存儲所述資產實例的第一屬性值，以縱表的形式存儲所述資產實例的第二屬性 值。
[0012] 可選地，在本發明實施例的再一種實現方式中，所述配置項包括資產分類和資產 實例；在所述緩存層中，以第一數據結構緩存資產分類信息、屬性信息以及資產分類與屬性 的對應關系，以第二數據結構緩存所有資產實例的屬性值，以第三數據結構緩存資產分類 之間的關系、資產實例之間的關系、熱點屬性信息和索引信息。
[0013] 可選地，在本發明實施例的又一種實現方式中，所述緩存層還用于采用MemcacheQ 對所述底層數據存儲區進行數據庫操作。
[0014] 可選地，在本發明實施例的更一種實現方式中，所述查詢優化模塊具體用于：根據 查詢條件中的屬性查詢所述緩存層中的索引信息以確定查詢條件中的屬性是否為熱點屬 性；如果不是熱點屬性，則從所述數據存儲層中查詢目標信息；如果是熱點屬性，則從所述 緩存層中查詢目標信息。其中，優選地，在根據關系型查詢條件從所述緩存層中查詢目標信 息時，根據關聯資產實例的量進行判斷，如果關聯資產實例的量超過閾值，則從所述數據存 儲層中查詢目標信息；如果未超過閾值，則從所述緩存層中查詢目標信息。
[0015] 可選地，在本方面實施例的其它實現方式中，一方面，所述邏輯層還包括事務支 持模塊，所述事務支持模塊用于識別事務類請求；所述緩存層還通過REDis(-種鍵值 (Key-Value)數據庫）的multi/exec實現所述緩存層的事務特性。另一方面，所述系統可 包括：數據抓取層，用于抓取線上資產數據；一致性校驗和同步模塊，用于根據抓取的資產 數據對所述數據存儲層中的數據和所述緩存層中的數據進行一致性校驗，以及用于將抓取 到的資產數據中同步到所述數據存儲層和所述緩存層中。再一方面，所述系統可包括對外 接口，用于接收用戶的操作請求以對所述數據存儲層中的數據進行查詢或維護等處理。 [0016] 采用本發明的各種實施例具有以下有益效果：
[0017] 1)通過將資產實例的屬性值存儲于不同表結構的表中，例如，將經常用作查詢條 件的屬性所對應的屬性值存儲于橫表，將描述信息存儲于縱表，能夠達到以下有益效果：一 方面，相對于采用縱表存儲所有屬性值而言，能夠降低數據量以及查詢結果返回后的結果 集拼裝難度，提高維護效率；另一方面，相對于采用橫表存儲所有屬性值而言，能夠降低數 據查詢過程中需要遍歷的數據量，有效提高查詢效率。
[0018] 2)通過將配置項、配置項之間的關系以及配置項的屬性分別存儲，能夠靈活地對 各部分數據進行增、刪、改、查等處理，提高了數據維護的便利性。
[0019] 3)在查詢過程中，根據查詢優化模塊查詢緩存層的查詢結果確定適合的后續查詢 邏輯，能夠充分利用緩沖層和數據存儲層具有不同數據結構的特點提高查詢效率。
【專利附圖】
【附圖說明】
[0020] 圖1是根據本發明實施例的一種針對資產數據的數據處理系統的方塊示意圖；
[0021] 圖2是根據本發明實施例的一種實現方式的數據存儲層的方塊示意圖；
[0022] 圖3是根據本發明實施例的一種實現方式的查詢優化方法的流程示意圖；
[0023] 圖4是根據本發明實施例的一種針對資產數據的數據處理系統的方塊示意圖。
【具體實施方式】
[0024] 以下結合附圖和【具體實施方式】對本發明的各個方面進行詳細闡述。其中，眾所周 知的模塊、單元及其相互之間的連接、鏈接、通信或操作沒有示出或未作詳細說明。并且，所 描述的特征、架構或功能可在一個或一個以上實施方式中以任何方式組合。本領域技術人 員應當理解，下述的各種實施方式只用于舉例說明，而非用于限制本發明的保護范圍。還可 以容易理解，本文所述和附圖所示的各實施方式中的模塊或單元或步驟可以按各種不同配 置進行組合和設計。
[0025] 首先，對本發明涉及的術語進行解釋：
[0026] CMDB (Configuration Management Database):配置管理數據庫，用于存儲與管理 企業IT架構中設備的各種配置信息。本發明各個實施例可以理解為對現有CMDB的改進， 也可以理解為基于現有CMDB提出的新的技術方案。
[0027] 圖1是根據本發明實施例的一種針對資產數據的數據處理系統的方塊示意圖，參 照圖1，數據處理系統包括數據存儲層11、緩存層12和邏輯層13。下面分別進行說明。
[0028] 數據存儲層11用于以分別存儲的方式存儲配置項（Cl)、配置項之間的關系以及 配置項的屬性。
[0029] 其中，配置項包括資產分類和資產實例。"資產分類"是指按照分類策略對所有資 產進行劃分得到的多個類別，例如"服務器"、"VIP"等均指資產中的類別；"資產實例"是指 某個資產分類下的具體個體或單位，例如，服務器這一資產分類下可以包括服務器A、服務 器B等資廣實例。
[0030] 可選地，在本實施例的一種具體實現方式中，資產實例的第一屬性值存儲在第一 表中，第二屬性值存儲在表結構不同于所述第一表的第二表中。例如，第一表為橫表，其中 存儲的第一屬性值是資產實例的屬性中用作或經常用作查詢條件的屬性所對應的屬性值； 第二表為縱表，其中存儲的第二屬性值是資產實例的描述信息，該類信息一般不會用作查 詢條件，但卻是查詢結果的一部分。本領域技術人員可以根據需要靈活地確定將哪些屬性 用作查詢條件，本發明對此不做具體限制。
[0031] 采用如上所述的存儲方式，一方面，相對于采用縱表存儲所有屬性值而言，能夠降 低數據量以及查詢結果返回后的結果集拼裝難度，有效提高維護效率；另一方面，相對于采 用橫表存儲所有屬性值而言，能夠降低數據查詢過程中需要遍歷的數據量，有效提高查詢 效率。此外，由于將配置項、配置項之間的關系以及配置項的屬性分別存儲，從而能夠靈活 地對各部分數據進行增、刪、改、查等處理，提高了數據維護的便利性。
[0032] 可選地，在本實施例的一種實現方式中，關于數據存儲層11的具體說明，請參見 下文結合圖2進行的說明。
[0033] 緩存層12用于以緩存的形式存儲所述數據存儲層中的數據。并且，優選地，緩存 層12采用不同的數據結構（例如，集合（set)、串（string)、哈希（hash)數據結構等）緩 存所述數據存儲層中的數據。
[0034] 在本實施例中，通過緩存層12緩存數據存儲層11中的數據，避免了將所有的查詢 操作都落在數據存儲層11，有效降低了數據存儲層11在查詢過程中的壓力。
[0035] 可選地，在本實施例的一種具體實現方式中，關于緩存層12的具體說明，請參見 下文結合表（一）進行的說明。
[0036] 邏輯層13包括查詢優化模塊131，用于根據查詢條件查詢所述緩存層，并根據查 詢結果確定從緩存層中查詢目標數據還是從所述數據存儲層中查詢目標數據。
[0037] 在本實施例中，通過查詢優化模塊131確定查詢邏輯，一方面，避免了將所有的查 詢都落在數據存儲層，降低了數據儲層的壓力；另一方面，對于某些查詢（例如，下文提及 的熱點屬性查詢），通過查詢緩存層能夠明顯提高查詢效率。
[0038] 可選地，在本實施例的一種具體實現方式中，關于查詢優化模塊131的具體說明， 請參見下文結合圖3進行的說明。
[0039] 圖2是根據本發明實施例的一種實現方式的數據存儲層的方塊示意圖，參照圖 2,數據存儲層包括第一存儲區201至第七存儲區304,其中，PK (Primary Key)表示主鍵， FK(Foreign Key)表示外鍵。下面對第一存儲區201至第七存儲區304分別進行說明。
[0040] 第一存儲區201 (或者稱作屬性池表），用于存儲屬性信息。換言之，在第一存儲區 201中存儲整個數據處理系統中涉及到的所有屬性。其中，單個屬性可以包括以下信息：屬 性名稱、限制類型（如整型、非定長字符串等）、默認值、是否可以為空等等。
[0041] 第二存儲區203 (或者稱作CI分類表），用于存儲資產分類信息。例如，存儲各資 產分類的名稱等。
[0042] 第三存儲區202 (或者稱作CI分類與屬性關聯表），用于定義各資產分類具有哪些 屬性。其中的"屬性信息所在表表名"和"對應字段"用于定位資產分類的部分屬性的屬性 值在數據存儲層中的位置（例如，"資產分類1"的"屬性2"的屬性值存儲在"CI實例屬性 橫表"的"字段1"中）。其中的"實例屬性id"是指201中所有屬性id中屬于某資產實例 的屬性id。
[0043] 第四存儲區204(或者稱作Cl分類關系表），用于存儲資產分類之間的關系，包括： 彼此之間存在關系的資產分類的id(例如，關系一方分類id和關系另一方分類id，當然，還 可包括關系更多的分類id)以及資產分類之間的關系類型。
[0044] 其中，資產分類之間可以包括很多種關系類型，例如，1:1 (即，一個資產分類下的 一個資產實例只能與另一資產分類下的一個資產實例對應）、l:m(即，一個資產分類下的 一個資產實例可以與另一資產分類下的多個資產實例對應）、m: 1 (即，一個資產分類下的 多個資產實例可以與另一資產分類下的一個資產實例對應）等類型，但同一類型的關系可 以具有不同的含義，如"固定于"、"歸屬于"等。例如，資產分類A與資產分類B為1:1關系， 含義可以是"資產分類A的一個實例Al綁定了資產分類B的一個實例B1"，資產分類C與 資產分類D也是1:1的類型，但其含義可以是"資產分類C的一個實例Cl存放于資產分類 D的一個實例Dl上"。資產分類之間的關系是單向的（S卩，不同資產分類之間的關系在數據 庫中只存一份），本領域技術人員應當理解，通過對資產分類之間的關系的約束，進而約束 了資產實例之間的關系。
[0045] 在第四存儲區204中，"約束方法"是可選地，其用于定義某些可計算功能，例如，在 用戶插入IP但未提供網段的操作處理中，根據約束方法確定，在指向上述操作處理之前， 需要根據IP計算網段信息并校驗網段信息是否符合預設要求。
[0046] 第五存儲區303 (或者稱作CI實例表），用于存儲資產實例信息。例如，用于存儲 各資產實例的唯一標識（例如，id)、資產實例所屬的資產分類id等。此外，還可以記錄實 例狀態，例如，當刪除某個實例時，采用軟刪除（即不直接刪除，而是變更狀態）的方式，以 便更好的追蹤該實例的歷史。
[0047] 第六存儲區301和302,用于存儲資產實例的屬性值。其中，302 (或者稱作CI實 例屬性橫表）以橫表的形式存儲資產實例的常用作查詢條件的屬性所對應的屬性值。在橫 表中，可以建立索引以存儲熱點屬性。301(或者稱作Cl實例屬性縱表）以縱表的形式存儲 資產實例的其它信息（例如，一般不用作查詢條件的描述信息）。
[0048] 第七存儲區304 (或者稱作CI實例關系表），用于存儲不同資產分類的資產實例 之間的關系，例如對于存在關系的兩個資廣實例，存儲關系一方實例id和關系另一方實例 id。其中，關系狀態與前文所述的實例狀態類似，此處不贅述。關系id對應第四存儲區204 的id，在查詢204確定兩種資產分類之間的關系之后，根據已知的一方實例id和用于標識 上述兩種資廣分類之間的關系的關系id查詢304,可以確定與一方實例存在關系的另一方 實例的id。
[0049] 除了上述存儲區之外，如圖2所示，數據存儲層還可以包括Cl分類主鍵表101和 CI快照401。其中，分類主鍵表101用于定義例如某類資產的唯一性約束等，CI快照401用 于存儲資產實例的快照信息，例如，存儲每一次操作（例如，修改、增加、刪除等操作）某資 產實例（以資產實例id標識）相關數據的操作時間、所執行的具體操作、變更后的新值等。
[0050] 為便于理解，同時本領域技術人員也應當理解，201-204可以看作類（抽象定義）， 301-304則可看作相應的對象（具體數據）。此外，可以采用MySQL建立數據存儲層。
[0051] 以上對根據本發明實施例的一種實現方式的數據存儲層進行了說明，接下來對根 據本發明實施例的一種實現方式的緩存層進行說明。
[0052] 緩存層可以采用第一數據結構（例如，hash數據結構）緩存屬性、資產分類信息 以及資產分類與屬性的對應關系；采用第二數據結構（例如，string數據結構）緩存資產 實例的屬性值；采用第三數據結構（例如，set數據結構）緩存資產分類之間的關系、資產 實例之間的關系、熱點屬性信息和索引信息。
[0053] 通常來講，如果緩存層緩存的數據較多，則查詢方便但更新工作量較大，如果緩存 的數據較少，則降低了更新的工作量，但查詢不便，導致很多查詢會落到數據存儲層，給數 據存儲層造成很大的壓力。根據發明人的研究發現，針對資產數據的數據處理系統都包含 如下的幾個特點：多數查詢都集中在少數幾類資產中、多數查詢都集中在少數幾類查詢中 (即查詢模式相對集中）、大部分查詢都是簡單精確查詢。結合以上特點，在本實施例的一 種具體實現方式中，緩存層可以按照表（一）所示的數據存儲結構存儲相關數據。
[0054]
【權利要求】
1. 一種針對資產數據的數據處理系統，其特征在于，所述數據處理系統包括邏輯層、緩 存層和數據存儲層，其中， 所述數據存儲層用于以分別存儲的方式存儲配置項、配置項之間的關系以及配置項的 屬性； 所述緩存層用于以緩存的形式存儲所述數據存儲層中的數據； 所述邏輯層包括查詢優化模塊，用于根據查詢條件查詢所述緩存層，并根據查詢結果 確定從緩存層中查詢目標數據還是從所述數據存儲層中查詢目標數據。
2. 如權利要求1所述的系統，其特征在于，所述配置項包括資產分類和資產實例，所述 資產實例的第一屬性值存儲在第一表中，所述資產實例的第二屬性值存儲在表結構不同于 所述第一表的第二表中。
3. 如權利要求1所述的系統，其特征在于， 所述配置項包括資產分類和資產實例； 所述數據存儲層包括： 用于存儲屬性信息的第一存儲區， 用于存儲資產分類信息的第二存儲區， 用于存儲資產分類與屬性的對應關系的第三存儲區， 用于存儲資產分類之間的關系的第四存儲區， 用于存儲資產實例信息的第五存儲區， 用于存儲資產實例的屬性值的第六存儲區； 用于存儲資產實例之間的關系的第七存儲區， 其中，在第六存儲區中，以橫表的形式存儲所述資產實例的第一屬性值，以縱表的形式 存儲所述資產實例的第二屬性值。
4. 如權利要求1-3中任一項所述的系統，其特征在于， 所述配置項包括資產分類和資產實例； 在所述緩存層中，以第一數據結構緩存資產分類信息、屬性信息以及資產分類與屬性 的對應關系，以第二數據結構緩存所有資產實例的屬性值，以第三數據結構緩存資產分類 之間的關系、資產實例之間的關系、熱點屬性信息和索引信息。
5. 如權利要求1-3中任一項所述的系統，其特征在于，所述緩存層還用于，采用 MemcacheQ對所述底層數據存儲區進行數據庫操作。
6. 如權利要求4所述的系統，其特征在于，所述查詢優化模塊具體用于： 根據查詢條件中的屬性查詢所述緩存層中的索引信息以確定查詢條件中的屬性是否 為熱點屬性； 如果不是熱點屬性，則從所述數據存儲層中查詢目標信息； 如果是熱點屬性，則從所述緩存層中查詢目標信息。
7. 如權利要求6所述的系統，其特征在于，所述查詢優化模塊具體用于： 在根據關系型查詢條件從所述緩存層中查詢目標信息時，根據關聯資產實例的量進行 判斷，如果關聯資產實例的量超過閾值，則從所述數據存儲層中查詢目標信息；如果未超過 閾值，則從所述緩存層中查詢目標信息。
8. 如權利要求1-3中任一項所述的系統，其特征在于， 所述邏輯層還包括事務支持模塊，所述事務支持模塊用于識別事務類請求； 所述緩存層還通過REDIS的multi/exec實現所述緩存層的事務特性。
9. 如權利要求1-3中任一項所述的系統，其特征在于，所述系統還包括： 數據抓取層，用于抓取線上資產數據； 一致性校驗和同步模塊，用于根據抓取的資產數據對所述數據存儲層中的數據和所述 緩存層中的數據進行一致性校驗，以及用于將抓取到的資產數據中同步到所述數據存儲層 和所述緩存層中。
10. 如權利要求1-3中任一項所述的系統，其特征在于，所述系統還包括對外接口，用 于接收用戶的操作請求以對所述數據存儲層中的數據進行查詢或維護。
【文檔編號】G06F17/30GK104391992SQ201410775769
【公開日】2015年3月4日 申請日期:2014年12月15日 優先權日:2014年12月15日
【發明者】張晴晴, 季永鋒, 邢召林 申請人:北京百度網訊科技有限公司