SOA管理大数据

SOA的三个数据中心模型分别是数据即服务(DaaS)模型、物理层次结构模型和架构组件模型。DaaS数据存取的模型描述了数据是如何提供给SOA组件的。物理模型描述了数据是如何存储的以及存储的层次图是如何传送到SOA数据存储器上的。最后，架构模型描述了数据、数据管理服务和SOA组件之间的关系。
SOA和数据企业的例子
也许以极限情况为开始是理解SOA数据问题的最好方式：一个企业的数据需求完全可以由关系数据库管理系统(RDBMS)中的条款来表示。这样一个企业可能会直接采用数据库设备或者将专用的数据库服务器和现有的查询服务连接到SOA组件（查询即服务，或QaaS）上。这种设计理念五年前或者更早之前已经被人们所接受。该设计之所以成功是因为它平衡了上述三个模型之间的关系。QaaS服务模型不是机械地连接到存储器上；而是通过一个单一的架构—— RDBMS（关系型数据库管理系统）。数据去重和完整性便于管理单一的架构。
通过大数据的例子可以更好地理解为什么这个简单的方法却不能在更大的范围内处理数据。多数的大数据是非关系型的、非交易型的、非结构化的甚至是未更新的数据。由于缺乏数据结构因此将其抽象成一个查询服务并非易事，由于数据有多个来源和形式因此很少按序存储，并且定义基础数据的完整性和去重过程是有一些规则的。当作为大数据引入到SOA的应用程序中时，关键是要定义三种模型中的最后一种模型，SOA数据关系中的架构模型。有两种选择：水平方向和垂直方向。

SOA和各类数据模型

在水平集成数据模型中，数据收集隐蔽于一套抽象的数据服务器，该服务器有一个或多个接口连接到应用程序上，也提供所有的完整性和数据管理功能。组件虽不能直接访问数据，但作为一种即服务形式，就像他们在简单情况下的企业，其数据的要求是纯粹的RDBMS模型。应用程序组件基本上脱离了RDBMS与大数据之间数据管理的差异。尽管由于上述原因这种方法不能创建简单的RDBMS查询模型，但是它至少复制了我们上面提到的简单的RDBMS模型。

垂直集成的数据模型以更多应用程序特定的方式连接到数据服务上，该方式使得客户关系管理、企业资源规划或动态数据认证的应用程序数据很大程度在服务水平上相互分离，这种分离直接涉及到数据基础设施。在某些情况下，这些应用程序或许有可以直接访问存储/数据服务的SOA组件。为了提供更多统一的数据完整性和管理，管理服务器可以作为SOA组件来操作各种数据库系统，以数据库特定的方式执行常见的任务，如去重和完整性检查。这种方法更容易适应于遗留应用和数据结构, 但它在问数据何访方式上会破坏SOA即服务原则，也可能产生数据管理的一致性问题。

SOA和水平数据模型

毫无疑问水平模型更符合SOA原则，因为它更彻底地从SOA组件中抽象出了数据服务。不过，为了使其有效，有必要对非关系型数据库进行抽象定义和处理低效率与抽象有关的流程——SOA架构师知道除非小心的避免此类事情否则这将会成为不可逾越的障碍。

水平的SOA数据策略已经开始应用于适用大数据的抽象数据。解决这个问题最常见的方法是MapReduce，可以应用于Hadoop形式的云构架。Hadoop以及类似的方法可以分发、管理和访问数据，然后集中查询这一分布式信息的相关结果。实际上，SOA组件应将MapReduce和类似数据分析功能作为一种查询功能应用。

处理水平数据库的效率问题

效率问题较为复杂。因为水平数据库模型可能是通过类似大多数SOA流程的信息服务总线来完成的，一个重要的步骤是要确保与该编排相关的开销额度保持在最低程度。这可以帮助减少与SOA相关的数据访问开销，但它不能克服存储系统本身的问题。因为这些存储系统已经通过水平模型脱离了SOA组件，很容易被忽略与延迟和数据传输量相关的问题，特别地，如果数据库是云分布的，那么使用他们就会产生可变的网络延迟。

上述问题的一个解决方案是现代分层存储模式。数据库不是磁盘，而是一组相互连接的高速缓存点，其存储于本地内存中，也可能转向固态硬盘，然后到本地磁盘，最后到云存储。缓存算法处理这些缓存点之间的活动，从而来平衡存储成本（同时也是平衡同步地更新成本）和性能。

对于大数据，它也是经常可以创建适用于大多数分析的汇总数据。例如一个计算不同地点车辆数量的交通遥测应用。这中方法可以产生大量的数据，但是如果汇总数据最后一分钟还存储在内存中，最后一小时存储在闪存中，最后一天存在磁盘上，那么控制应用程序所需的实际时间可以通过快速访问资源得到满足,然而假设分析时我们可以使用一些更便宜、更慢的应用程序是会怎样。

SOA都是抽象的，但当抽象隐藏了底层影响性能和响应时间的复杂性时，这种抽象的危险程度会提高。数据访问也是这样的，因此,SOA架构师需要认真地考虑抽象与性能之间的平衡关系，并为其特定的业务需求优化它。