针对资产数据的数据处理系统的制作方法
【专利摘要】本发明公开了一种针对资产数据的数据处理系统，所述数据处理系统包括逻辑层、缓存层和数据存储层，其中，所述数据存储层用于以分别存储的方式存储配置项、配置项之间的关系以及配置项的属性；所述缓存层用于以缓存的形式存储所述数据存储层中的数据；所述逻辑层包括查询优化模块，用于根据查询条件查询所述缓存层，并根据查询结果确定从缓存层中查询目标数据还是从所述数据存储层中查询目标数据。采用本发明提供的数据处理系统，能够提高对资产数据的维护效率和查询效率。
【专利说明】针对资产数据的数据处理系统
【技术领域】
[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日
【发明者】张晴晴, 季永锋, 邢召林 申请人:北京百度网讯科技有限公司