随着企业信息系统的快速发展，日趋复杂的业务对系统不断提出新的需求。为应对频繁变更的需求以及快速增长的系统规模，构造业务模型库以支持服务开发是实现云服务系统快速开发及运营维护的重要途径。而在模型驱动服务开发过程中，需要一个业务模型管理平台对服务的全生命周期，包括业务建模、服务转换、服务配置、服务部署、服务监控等各个阶段进行支持。为达到这些目标，业务模型库需要实现对海量的结构化数据及非结构化业务模型进行高效的存储和访问。

由于关系数据库无法在海量数据环境下提供足够性能，因此很难直接采用关系数据库实现。NoSQL数据库^[1]具有易于水平扩展集群规模，高效利用分布式索引和内存等特点。因此Olivier等^[2]开发了一个框架允许开发者使用SQL接口来对关系数据库和NoSQL数据库进行操作。Paolo等^[3]开发了一个SOS API用于提供多种NoSQL数据库的统一操作接口。但相比关系数据库，NoSQL数据库缺乏对数据访问的ACID(atomicity，consistency，isolation，durability)约束，且不支持关系模型中一些复杂的查询操作，往往无法支持多列查询或执行效率低下，因而并不能完全地取代关系数据库。吴广君等^[4]在存储结构的NoSQL数据库上结合B+树索引和局部索引以提高检索效率，并实现了海量数据的多列查询。

Hadoop等能够在分布式环境下高效地处理海量数据，支持通过MapReduce对海量数据进行高效处理^[5]。而Hive是建立在Hadoop上的数据仓库基础构架^[6]，作为Apache开源项目的优化，Hive在云平台优化方案不少^[7]。Xu等^[8]设计了一个整合Hadoop与并行数据库的架构，使得二者能够统一地进行操作和管理，并提供了一系列的数据处理工具，可以用来进行数据的提取转化。

支持云服务开发的模型库实现，需要结合关系数据库与NoSQL数据库的优势并构造其海量处理机制。同时面向云服务应用，还需要构造数据的服务调用方式^[9]和多租户机制^[10]。因此，本文提出了分布式环境下的业务模型数据存储访问框架。基于多种数据库进行整合与扩展，构建基于Hadoop的文件库，对非结构化模型数据进行版本管理，解决模型存储问题；在开发阶段和运行维护阶段提供数据存储访问支持；面向服务应用要求，实现RESTful服务生成机制，支持业务模型到服务的转换和应用。

云平台下的业务模型库涉及到多种数据，如模型数据、模型文件、租户信息数据、日志数据、权限控制数据等。这些数据无论是在数据结构、数据量、访问方式上都不尽相同，采用单一的存储方案难以高效地满足所有数据的存储访问需求。因此，本文提出一个业务模型数据存储访问框架(简称数据框架)。该框架结合多种数据库以及Hadoop，能够满足海量模型数据的多种存储、访问需求。框架架构如图 1所示，包含模块如下：

图 1 业务模型数据存储访问框架架构

图选项

1) 文件库。文件库在Hadoop的基础上，添加额外的组件，实现对结构化和非结构化的数据进行管理。利用HDFS(high density fixed services)作为基础文件系统，进行扩展实现模型数据版本管理及多租户数据隔离。文件处理器使用Hadoop自带的Hadoop Archieve工具来提升Hadoop对于小文件的处理能力。

2) 数据库模块。数据库模块基于混合数据库，对结构化数据进行管理。该模块实现多种数据库的结合，利用NoSQL数据库实现对海量数据的存储和处理，同时利用关系数据库实现复杂的连接查询以及ACID约束。数据控制器通过统一的编程接口以及对象关系映射，屏蔽具体数据库接口和数据模型之间的差异，提供统一的数据视图，简化了信息系统数据访问层的开发以及数据库迁移过程。

3) RESTful服务模块。RESTful服务模块基于数据库模块，抽取业务模型中的信息资源元数据，建立信息资源，并生成相应RESTful服务供外部应用调用。

为实现数据框架的各种功能，本文提出了数据库管理模型、文件库管理模型和RESTful服务生成机制，分别用于实现数据框架的各个主要功能模块。

数据管理模型核心在于实现多种数据库的统一访问，其中主要方法包括多种数据库的对象实体映射以及查询适配。此外，还引入多租户管理机制来支持云平台下的多租户服务。

为实现多种数据库的对象实体映射，需要抽象出数据集合的结构，即建立对象到不同数据库中存储的数据实体的映射。

主流NoSQL数据库根据存储模型大体可分为4类：键值对存储型、文档存储型、列存储型、图存储型。这4类NoSQL数据库的存储模型有很大区别，但都可从中抽象出包含任意个属性的数据记录的结构，因而每个数据记录结构可映射为一个对象。而一组属性相同的数据记录则可映射为一个数据实体类，如键值对存储型数据库中，一组键值对可视为一个数据记录的全部属性。通过映射可将多种不同NoSQL数据库中的数据映射为内存中的对象。除此之外，还需要维护实体间关系。由于外键约束会带来许多系统开销，本文的外键存储方式借鉴了Pedro的方法^[10]，并进行了改进。在每个数据实体中，每个外键都以单独属性来存储。在实体关系为“一对多”或“多对多”的情况下，不使用额外的数据集合来存储外键关联，而是将外键的所有值以集合的方式存储在一个属性中。基于这种集合存储方式，再提供一组针对集合进行的操作支持，包括：“contains”用于判断集合中是否存在指定值；“add”用于添加指定值到集合中，如果值已经存在于集合中则不进行操作；“remove”用于删除集合中指定值。

通过统一访问接口发出的查询无法被数据库直接执行，需要一组适配器来将统一查询翻译为具体数据库能接受的原生查询。针对关系数据库，适配过程是将统一查询翻译为SQL(structured query language)语句的过程。众多NoSQL都有各自独特的查询接口及数据模型，因此每种NoSQL数据库都需要一个专用的适配器来进行查询翻译。

NoSQL数据库提供各种常用的针对单个数据集合的查询操作，但不支持分组(group)操作和连接(join)操作。分组操作可通过对记录集进行额外的处理实现，但连接操作的实现则相对复杂。NoSQL数据库不提供原生支持的连接操作，但在许多应用场景中，实体之间不可避免地需要进行连接查询。此外，为了实现多种数据库的紧密结合，也需要一种跨数据库的连接操作。尽管这种操作效率低于关系数据库，但在非高并发执行的场景下能发挥很大作用，因此本文提出一个跨数据库的连接操作实现方法。

定义1 约束(restriction，R)：在查询中通过对目标实体中某个属性的取值范围进行约束、进行归约计算操作、或设置排列顺序。一个约束可以使用如下元组定义：

〈R〉：：=〈Entity，Property，Restriction_Type，Restriction_Parameter〉，(Entity∈Entity_Set，Property∈Property_Set(Entity)，Restriction_Type∈RestrictionType_Set).

其中：Entity是约束R所针对的实体；Entity_Set是系统中所有数据实体的集合；Property是约束所针对的属性；Property_Set(Entity)是实体Entity所包含的属性集合；Restriction_Type指约束的类型；RestrictionType_Set是所有约束类型的集合，其中包括如“小于”“以指定字符串开头”“进行求和计算(sum)”等；Restriction_Parameter是约束参数，表示约束时需要的参数，可能是一个数值、一个集合或另一个属性。

定义2 连接约束(join restriction，JR)：约束的一种特例，指约束类型需要连接操作的约束。连接约束可定义为如下元组：

〈JR〉：：=〈Entity，Property，JoinRestriction_Type，Join_Entity，Join_Property〉，(Entity∈Entity_Set，Property∈Property_Set(Entity)，JoinRestriction_Type∈JoinRestrictionType_Set，JoinRestrictionType_Set⊆RestrictonType_Set，Join_Entity ∈Entity_Set，Join_Entity ≠ Entity，Join_Property∈Property_Set(JoinEntity)).

其中JoinRestriction_Type是连接约束类型的集合。

定义3 非连接约束(non-join restriction，NJR)：约束类型无需连接操作的约束。非连接约束可定义为以下元组：

〈NJR〉：：=〈Entity，Property，Restriction_Type，Restriction_Parameter〉，(Entity∈Entity_Set，Property∈Property_Set(Entity)，Restriction_Type∈(RestrictionType_Set -JoinRestrctionType_Set).

定义4 连接查询(join query，JQ)：需要进行连接操作的查询。连接查询的约束集合中至少存在一个连接约束。查询包括增删改查4类，4类操作的元素定义有一些区别，此处以4类操作所需元素的并集来定义：

〈JQ〉：：=〈Record，Target_Entity，Join_Restrictions，NonJoin_Restrictions〉，(Target_Entity∈Entity_Set).

其中：连接约束集合表示此查询使用的所有连接约束构成的集合，非连接约束则是此查询中所有非连接约束构成的集合。对于增删改查4类查询，每类查询的定义元组可通过连接查询定义元组(〈JQ〉)的部分元素设为空来构成。

定义5 非连接查询(non-join query，NJQ)：无需进行连接操作的查询。此处同样以增删改查4类操作元素的并集来定义元组：

〈NJQ〉：：=〈 Record，Target_Entity，NonJoin_Restrictions〉，(Target_Entity∈Entity_Set).

定义6 记录集(record set，RS)：一个数据记录的集合。此处记录集代表一个抽象的概念，既可指一个数据集合中的全部记录构成的集合，也可以指查询过程中产生的结果或中间结果构成的记录集合。记录集(〈RS〉)可被定义为一个二元组：

〈RS〉：：=〈Entity，Records〉，(Entity∈Entity_Set).

其中Entity表示记录集中所有记录所对应的实体(记录集中所有记录必须对应一个相同的实体)。

基于以上定义，本文给出处理连接查询的算法伪代码，其中包括一个递归函数及主执行过程，见图 2。

图 2 连接查询算法伪代码

图选项

业务模型库提供面向多租户的服务，在数据层面，多租户服务的需求主要在于数据的隔离和共享。每个租户享有自己独立的私有数据，用户所有的操作都只针对自己的私有数据进行，而不会对其他租户的私有数据构成影响。

为了尽可能达到性能与数据隔离性的平衡，数据库管理模型采用共享数据库，独立数据集合的方式实现数据隔离，即不同租户数据存储在相同数据库中的不同数据集合中。该方案允许以数据实体为粒度，控制不同数据共享或私有。每一个租户针对私有数据集合的操作将被重定位到属于该租户的私有数据集合进行，因而不会影响其他租户的私有数据。

在数据框架中，文件库以文件的形式存储和处理非结构化的模型数据。文件库基于Hadoop的HDFS构建对其功能进行了扩展，并封装其接口。

在文件库中，为实现版本管理，文件夹中的所有文件以及随后被放置在这个文件夹下的所有文件都将被添加一个额外的版本属性，而文件夹则被添加一个最新版本号属性。在业务服务库中，每组模型文件被存放在单独的版本化文件夹中。业务服务库在访问模型文件时，可按版本号获取模型，也可默认访问最新版本模型。

文件库为支持多租户管理，实现了文件粒度的数据隔离与共享机制。基本方法为：在文件库中为每个租户划分租户空间。每个租户空间本质上为文件库中根目录下的一个文件夹，使用租户ID命名。同时也有一个用于存储共享文件的共享空间。文件库对每个租户发出的针对私有文件操作进行拦截，并重定位。文件操作默认针对私有空间进行操作，因此当操作没有显式声明是私有空间还是共享空间时，操作目标路径都将被修改为指向属于该租户的租户空间中对应的位置进行操作。

RESTful服务借助HTTP协议提供操作接口，具有轻量级以及无状态的特性^[11]，可提供跨平台的通用资源访问，因此在数据基础上构造RESTful服务的自动生成机制，是实现数据对外服务接口的关键。RESTful服务生成分为以下阶段：

1) 抽取资源元数据。在多视图的业务模型中，通过服务转换功能，可实现由业务模型数据到Web服务描述文件(Web application description language, WADL)的转换。WADL文件中，包含了资源所对应的一系列元数据的XML(extensible markup language)格式的描述。

2) 建立资源。利用获得的资源元数据可在数据库中建立相应的资源，即创建数据库中的数据集合。资源元数据描述资源的方式与数据库中数据结构并不一致，因此需要在资源元数据与数据实体之间建立映射，从而将其转换为数据集合。在WADL中资源的数据结构以嵌套的方式描述，一个复杂类型(complex type)可能多级嵌套其他复杂类型，在建立资源元数据到数据实体时，需要将复杂类型逐级展开，映射为一个数据实体，并存储到数据集合中。

3) 生成相应服务接口。当资源建立完成后，需要生成相应的RESTful服务供资源使用者调用。由于资源已经被映射为一系列的数据实体，还需实现通过HTTP对这些资源进行操作的接口。构建一组统一的RESTful服务，基于数据库模块访问实体资源；该服务提供增删改查等各种基本查询接口，从访问的URL及参数中获取操作的具体资源以及查询条件，从而实现对所有资源的RESTful服务访问接口。

本文通过业务模型库提出的数据存储访问模型进行验证。该业务模型库是为某物流服务平台的支持模块，其核心是在模型驱动开发中实现对服务的全生命周期支持。业务模型库需要存储和管理多种结构化、半结构化数据。为了尽可能提高数据存储和访问效率，根据这些数据本身以及访问的不同特点，通过配置将其分别存储在了MySQL数据库、MongoDB数据库和文件库中，如图 3所示。

图 3 业务服务库的数据持久化的存储分布

图选项

业务模型库允许租户或领域专家(一种特殊的租户)上传业务模型。每次上传以模型压缩包的方式上传一套模型。在服务端，模型压缩包首先被解压和解析，其中的模型基本信息和模型数据被提取并存储在数据库中。同时系统还在数据库中记录一组日志数据，模型源文件则被存储到文件库中。模型上传过程中数据库模型根据预先配置的信息以及租户信息确定数据的具体数据库以及数据集合存储位置。在浏览模型时，由于多租户管理机制的限制，租户只能看到自己上传的模型以及系统共享的模型，并对其进行操作。图 4为浏览模型的流程。

图 4 浏览模型流程

图选项

不同租户看到的是不同的模型组列表。租户在上传模型之后，还可进行服务转换，生成RESTful服务，供外部系统调用。

业务模型数据存储访问框架整合并扩展了多种数据库以及Hadoop，用于在业务模型库系统开发和运行维护阶段对业务模型的存储和访问提供支持。在分布式环境下集成多种数据库来实现海量模型存储的方法有Curé O等^[2]提出的数据集成系统、Yan等^[12]提出的业务模型库等，实现了业务模型存储、管理、查询功能。如表 1所示，本文从功能方面与这2种方案进行了比较。本文方案提供了一个更加完整的数据存储访问平台，不仅更加紧密地结合关系数据库与多种NoSQL数据库，而且提供灵活的配置；此外，为了支持云平台下业务模型库的服务应用，也集成了多租户数据隔离机制以及模型文件的版本管理机制，并提供RESTful服务自动生成功能。本文方案可在云平台下，实现业务模型库对海量业务模型数据的高效存储访问，并降低开发及维护成本。

针对云平台下的海量数据的存储访问需求，本文提出了业务模型数据存储访问框架。针对结构化数据，提出了数据库管理模型整合并扩展多种数据库以提供高效的数据存储访问，同时提供统一访问接口降低开发、维护成本；针对非结构化数据，框架封装扩展HDFS，提出了模型数据的版本管理模型，管理设计中和使用中的多版本的模型数据。本文整合了多种数据库，既支持不同类型数据的灵活存储，又提供了统一的查询访问接口，在不增加开发、维护成本的前提下结合了多种数据库的优势。