现代MRO^[1-3](maintenance, repair, overhaul)是在借鉴航空维修MRO^[4]概念的基础上, 增加了产品的状态监视及运行控制等业务内容。它的最大特点是支持产品的全生命周期管理^[5-6], 即涵盖产品的设计、生产、运行以及回收等全部阶段。因此, 与传统MRO比较, 现代MRO系统的数据管理特点是:①数据量大。产品的设计、生产、运行以及报废的整个生命周期, 每个产品都会产生大量的数据; ②数据处理任务数量快速增长。产品数量的增加使得实时处理负荷变大; ③数据类型多样化。系统中有实时数据、基础数据、业务知识数据以及用户交互数据, 这些数据的类型不一样。④共享性高。终端用户、制造商、销售商以及相关零部件的供应商都参与到产品中, 信息共享性要求大幅提高。

现代MRO系统的一个重要特点是历史数据庞大, 并且这些历史数据能够被反复利用, 进行产品运行中的预测和评估计算, 例如, 最佳维护时间的计算等, 因此, 既需要海量的存储空间亦需要好的计算能力。目前, 有关现代MRO系统的数据管理文献中, 有些专注于如何满足海量数据存储的要求^[2-3], 另外一些则只考虑计算能力问题^[6], 而综合考虑全生命周期中数据存储和数据分析计算的则较少。现有的MRO系统以采用传统的关系数据库和NoSql数据存储为主, 文献[7]利用实时数据库系统保存数据, 它只支持对动态采样数据的处理; 文献[8]针对MRO系统中数据的多源、异构、海量、动态等特点, 提出了一种综合运用云计算技术解决这一问题的思路, 它很好地解决了存储问题, 但是对于数据操纵问题却没有涉及。文献[9]针对数据模型、数据预处理与集成和数据查询等几个方面进行了分析, 提出了基于云平台的数据管理框架, 但是其核心在于数据模型方面。文献[10]针对传感器采样数据管理中所面临的数据海量性、异构性、时空敏感性、动态流式特性等问题, 提出了使用数据库集群来管理采样数据, 但是没有涉及事务数据的管理。

鉴于现存系统中的不足, 提出了一个可扩展键值存储^[11-12]系统来满足现代MRO系统的数据处理要求。通过本地化实时应用和数据缓存的特点, 在应用程序和KV存储之间增加一个中间层, 实时更新的数据被缓存到内存的不同组中; 收到读取数据请求, 直接返回内存中的数据, 避免过多的I/O操作。对于需要多个数据经过融合才能进行实时分析计算的请求, 按照应用要求对数据分组, 一起工作的键缓存在同一个计算节点中, 避免了分布式带来的风险。由于以键值存储为基础, 系统允许用户灵活地建立分组, 实现不同的计算要求, 所以满足了可扩展性^[12]。

1 现代MRO的实时数据存储模型

现代MRO系统的数据存储模型需要实现实时数据更新、实时数据分析处理以及实时数据状态显示功能。实时数据更新负责获得设备中各个部件的传感器的最新状态参数, 然后保存。实时分析根据产品的最新状态数据, 再利用历史数据, 及时准确地判断产品的状态。实时状态显示负责从数据存储中心获得产品的最新数据及状态, 向终端用户展示。

为了有效利用二级存储设备, 降低磁盘I/O次数, 将数据存储功能分为分组存储层和数据存储层。分组存储层以内存为主, 用于实时数据的计算; 数据存储层采用KV存储模型, 可以满足海量存储。当系统启动一个实时处理业务时, 将业务需要的数据从KV存储中取出, 分组存储层进行汇聚后, 再执行计算。

为了与传统的关系数据库融合, KV存储中的键由多个部分组合形成, 按照树模型组织起来, 而每个部分可以对应关系中的属性。

定义1  父子关系是指有序对集合{(p, q₁), (p, q₂), …, (p, q_l)}上, p与{q₁, q₂, …, q_l}之间是一对多的联系, 集合中的任何一个有序对称为父子关系, 其中p叫父键, q₁, q₂, …, q_l都叫子键, 个数为l。

定义2  层次模型是由一组键和键之间的父子关系构成的一棵有向树T=(V, E)。其中V和E定义为:①V是键的集合; ②如果(v₁, v₂)∈E, 当且仅当存在一个从v₁到v₂的父子关系。

现代MRO系统中, 产品、部件以及零件等之间的装配关系是树状的, 所以实时处理键组可以很好地描述产品中每个零部件的信息。例如产品是根, 产品与部件是父子关系, 部件和零件是父子关系, 零件的运行状态与时间戳是父子关系, 其键表示为/sid/cid/qid/timestamp。因此, 对于每一个具体的产品, 可以用层次模型表示。

现代MRO系统计算产品的指定状态时, 需要将涉及到的零部件信息组合在一起, 形成一个计算单元。

定义3  实时处理键组是一组层次模式的集合。

实时键组的操作主要包括:键组的建立和删除; 键组元素的增减操作。

约束规则为:①进行插入时, 如果没有相应的父键存在, 子键不能插入; ②进行删除操作时, 如果删除父键, 则子键记录必须被全部删除; ③只有一个键没有父键, 其为根键; 没有子键的键称为叶子键。除根键外, 每个键有且只有一个父键; 除叶子键外, 每个键至少存在一个子键。

例如, 当分析采摘定的状态时, 需要将转速、油压、风管参数组合在一起, 形成一个计算单元, 其包含的键形成实时处理键组。但是由于这些参数可能来自不同的物理节点, 也有可能一些键被其他计算单元使用, 因此实时处理键组是动态组合的, 因此需要进行实时键组的管理。

2 实时处理键组的管理 2.1 实时处理键组软件结构

如图 1所示, 每个物理节点包含一个协调器、一个实时应用管理器以及实时处理键组。

应用管理器主要调度该节点上的实时计算程序, 协调器执行用户实时处理键组的建立和撤销请求。当需要执行实时计算时, 协调器从各个KV存储节点获取指定的键值, 然后形成一个实时处理键组, 最后由应用管理器调度执行。一旦计算结束, 撤销对应的键组。

2.2 实时处理键组注册和撤销过程

实时处理键组的注册是由实时计算发起的, 它指定一组需要更新的成员键, 然后向实时处理键组管理器发送注册请求, 实时处理键组管理器就开始一个实时处理键组的注册过程。注册过程采用原子方式, 要么注册成功, 形成一个实时处理键组, 要么注册失败, 实时处理键组无法产生。

算法:注册过程。

输入:新收到的键K={k₁, k₂, …, k_m}

输出:新键组t

过程:

T={t₁, t₂, …, t_n}/*已经存在的键组*/

while(k∈K){

  if((k∉t_i.k)∧(∀t_i∈T)){

    if(!t)t=mg(k)

    else t.k=∪{k}

  }else

    return ϕ

  T=T∪{t}/*t与T合并*/

}

return t

实时处理键组注册时, 应用管理器向协调器发送建立命令, 协调器并发地向各个键所在的数据存储节点(参与者)发送消息(C), 参与者收到消息后, 将成员键的值发送到协调器(CA), 若有错误发生则返回错误(A)。协调器根据所有参与者的回复决定实时处理键组的建立或者中止。如果存在成员键的值无法取得, 协调器负责通知管理器建立失败。如果成功取得所有成员键的值, 协调器负责通知管理器建立成功。

当应用程序不再需要某个实时处理键组时, 首先向管理器发送解散实时处理键组的命令, 此时, 管理器向协调器发送释放消息, 实时应用存储节点上的键值即为不可用状态。若实时处理键组中某个键值的变更未被提交, 在发送解除消息之前, 协调器必须保证数据提交到各个成员节点。

2.3 实时数据分析处理的实现

图 1中的分组管理器为每一个实时处理键组设置一个对象标识, 称之为应用对象。图 2展示了系统的数据处理过程。

① 根据实时处理键组建立应用对象; ②buffer取得键值并处理; ③处理完的数据写入应用对象; ④分组管理器采用put2new策略检查③中的数据是否全部得到, 若是, 则向异步更新服务发送commit请求; ⑤异步更新服务采用put方法将数据回写到数据存储系统; ⑥异步更新服务也将其他备份进行commit更新, 分组管理器检查③提交的数据, 若发现有数据未到达, 则应用程序显示分析处理失败。

实时处理键组的数据存储在内存中, 既提高了响应速度, 又提高了故障发生时执行失效接管的速度。

2.4 可扩展性

在图 2中, 当某个节点的负荷较大时, 系统可以增加新的计算节点, 并且将部分实时处理键组转移到新的节点, 从而提高系统计算能力。另外, 由于采用分布式KV存储策略, 扩展数据存储节点非常容易, 从而满足海量数据存储的要求。

3 实现

系统组成如图 3所示, 用户的实时处理请求到达后, 实时处理服务建立实时处理键组, 从数据存储服务器中取得数据, 数据的更新写入分组对象。分析处理完的数据定期更新到键值存储系统中, 实现持久化。由于内存中数据容易丢失, 所以采用先写日志的方式(WAL)将数据写入日志中。

实时处理业务执行时, 必须保证分组中的键值是最新的, 否则不能进行处理。如果应用不需要访问分组内的全部键值, 而仅仅需要访问组内的一个键, 那么就不使用分组管理。

在实时处理键组的生命周期内, 实时键组管理器负责实时处理键组内键的访问, 它独占访问键组内键的权利。虽然实时处理键组内的键可能来自不同的数据存储节点, 但是实时处理键组服务可以缓存实时处理键组内的键值, 从而避免了代价高昂的磁盘I/O, 减少了延迟时间。

4 评价

论文实现了一个现代MRO软件中的数据管理系统。分布式键值存储采用数据存储服务, 采用Voldemort和Berkeley DB实现数据存储服务, 对Voldemort封装了一个接口, 可以连接实时处理键组服务的内存存储。

4.1 实时处理键组注册和撤销的模拟方法

假设有G个并发的实时处理键组, 每个实时处理键组中包含K个键, 则系统中至少包含n×G×K个键, 其中n是可扩展因子, 它表示没有被包含到实时处理键组中的键数量。实时处理任务发出创建实时处理键组的请求, 其中包含实时处理键组成员, 实时处理键组的成员的选择是随机的, 成员的平均个数是K, 标准偏差是σ_k。实时处理键组创建成功后, 每个实时分析处理程序获得全部的键值, 全部获得后执行分析计算, 等待数据的时间间隔为δ或者2δ, 然后继续重复以上的数据处理。

使用参数G, K, n, δ来评价系统各个方面的性能, 前3个参数来说明可扩展性, 而N用于评价实时处理键组建立和删除时的系统开销, δ则体现系统进行并发操作时的压力测试。

4.2 实时处理键组的创建时间评价

通过将实时处理键组中的其他操作设置为0, 从而使得创建过程的负载只包含创建操作, 创建成功后立即执行删除操作。评价了使用不同传输方式及实时处理键组成员选择方法时的延迟和吞吐量, 其中传输协议分为可靠传输协议和不可靠传输协议, 选择方法分为随机选择参与者键和顺序选择参与者键。

随着并发实时分析计算的请求增加, 图 4描述了实时处理键组创建请求的延迟情况。延迟时间是指客户发出创建请求与收到建立成功消息之间的时间。从图中明显可以看出, 顺序选择参与者键优于随机选择参与者键, 因为这些键存在于一个节点上, 所以使用单个创建消息即可满足; 另外, 实时处理键组中键的个数对延迟时间影响较小, 因为请求是依照批处理方式发送的, 假如有n个分布式节点, 最多只发送n个消息, 与参与者键的个数没有关系。

图 5给出了一定时间内建立实时处理键组的个数, 客户数量从50增加到10 000的过程中, 每秒钟创建实时处理键组的个数也呈线性增长, 但是随着客户数量的增大, 增长停滞, 其原因从图 4中也可以得到, 客户数量的增大, 创建组的平均延迟时间增大, 导致创建的组数量停滞。

4.3 实时处理键组的操作评价

本节评价实时处理键组操作的性能。实时处理键组建立后, 从客户端就模拟大量的操作, 在评价中, 主要比较论文中的系统与Voldemort、Berkeley DB、文献[11]中的Megastore以及文献[12]中的ForestDB系统在操作上的平均延迟时间。论文中的系统延迟时间包括实时处理键组的建立、删除时间以及附加的操作时间。对于Voldemort系统, 不需要建立组, 也不需要保证实时应用特性, 因此它被作为性能基准来评价本系统的额外开销。对于本系统, 更新操作产生后, 系统保证全部的键更新完成。在实验中, 针对不同的N值进行评价, 每个实时处理键组中键的个数K设置为15和60, δ设置为10 ms。

图 6给出了N值不同时每个操作的延迟时间。延迟时间计算方法是:

式中, t_c表示实时处理键组建立与删除时间, t_o表示操作花费时间, N_o表示操作的数量。

对于Voldemort系统, 延迟时间就是所有操作时间的平均时间。如图 6所示, 由于Megastore以及ForestDB采用本文类似的技术, 所以这3种系统与Voldemort比较, 实时处理键组带来的额外开销大约有10%~30%, 随着实时处理键组中操作数量的增加, 额外开销占用的比例进一步降低。尽管键值的更新不是直接进行持久存储, 而是通过实时处理键组服务被异步地提交到持久存储, 但是这种方式并没有影响键值的更新效率。由于Megastore以及ForestDB是针对大规模事务操作以及数据类型多样, 而本文对于实时要求相对较高, 并且数据类型单一, 所以, 相比较而言, 本文中的系统比Megastore以及ForestDB性能要好一些, 大约有10%左右。故这种采用二级缓存来形成实时应用型可扩展大数据存储系统的方式是一种有效的途径。

5 结论

随着数据密集型计算的不断增多, 数据规模的不断增大, 可扩展性作为重要的特性被提出。本文提出的实时处理键组协议很好的满足了可扩展性, 系统已经在项目中应用, 并得到评价, 既可以满足实时应用的需求, 也不降低键值存储的效率。