CN103559247B - 一种数据业务处理方法及装置 - Google Patents

Abstract

本发明公开了一种数据业务处理方法及装置，所述方法包括：根据接收到的数据业务处理请求，从存储原数据的第一存储系统中读取待处理数据；根据所述待处理数据和数据业务处理请求的属性，选择第二存储系统；将所述待处理数据存储到第二存储系统中，并根据数据业务处理请求对待处理数据进行计算处理，且将产生的处理结果存储到第三存储系统中；从第三存储系统中获取处理结果，作为所述数据业务处理请求的响应结果；从所述第二存储系统中删除所述待处理数据，根据需要决定是否删除所述第三存储系统中的处理结果。本发明对各个存储系统的操作抽象化，封装成统一的接口，实现用户对系统的控制更加简单、方便，不同业务采用统一的架构不同的存储系统，灵活应用、可靠性高。

Description

一种数据业务处理方法及装置

技术领域

本发明涉及云计算领域，具体涉及数据业务处理领域，尤其涉及一种数据业务处理方法及装置。

背景技术

随着互联网技术的突飞猛进及网络信息技术的快速发展，数据的传播速度日益加快，数据的飞涨也增加了数据信息处理的难度。从企业角度来看，日益增长的信息已经很难存储在标准关系数据库甚至数据仓库中，例如，如何查询一个十亿行的表，怎样跨越数据中心所有服务器上的日志进行一个数据查询，如果有的数据是非结构化或者半结构化的数据，就更难进行数据查询了。

Hadoop实现了一个分布式文件系统(Hadoop Distributed File System)，简称HDFS。HDFS可以分布式地操作大量数据，在海量数据上处有很大的优势。它主要有以下几个优势：

1、高可靠性。Hadoop按位存储和处理数据的能力值得人们信赖。

2、高扩展性。Hadoop是在可用的计算机集簇间分配数据并完成计算任务的，这些集簇可以方便地扩展到数以千计的节点中。

3、高效性。Hadoop能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快。

4、高容错性。Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配。

然而，HDFS是由中央文件系统维护元数据，无法避免单点故障。此外对小文件的处理存在先天不足和只支持WORM(一次写多次读)，对于希望在大数据环境中实现更可靠，更高程度的灵活性、更好可扩展性的企业，仅仅依靠HDFS的性能无法满足企业的需求。

发明内容

有鉴于此，本发明实施例提供一种数据业务处理方法及装置，以提高存储系统的灵活性和可靠性。

第一方面，本发明实施例提供了一种数据业务处理方法，所述方法包括：

根据接收到的数据业务处理请求，从第一存储系统中存储的原数据中读取待处理数据；

根据所述待处理数据和数据业务处理请求的属性，选择第二存储系统；

将所述待处理数据存储到第二存储系统中，并根据数据业务处理请求对待处理数据进行计算处理，且将产生的处理结果存储到第三存储系统中；

从第三存储系统中获取处理结果，作为所述数据业务处理请求的响应结果；

从所述第二存储系统中删除所述待处理数据，所述第三存储系统中的所述处理结果根据需要决定是否删除。

进一步地，所述第一存储系统、第二存储系统及第三存储系统的类型相同或不同，为下述存储系统中的任意一个：分布式对象存储系统、分布式块存储系统和分布式文件系统。

进一步地，根据接收到的数据业务处理请求，从第一存储系统中存储的原数据中读取待处理数据包括：根据接收到的数据业务处理请求中的目标数据地址，基于类Map/Reduce计算框架计算目标数据在第一存储系统和第二存储系统的映射关系，根据所述映射关系从原数据中读取待处理数据。

进一步地，所述方法还包括：通过统一应用程序编程接口接收用户的统一数据存储请求；根据所述统一数据存储请求获取待存储数据所对应的至少一个存储系统；根据获取的至少一个存储系统，基于设定转换规则，将所述统一数据存储请求转换为各所述存储系统对应的至少一个系统数据存储请求；根据所述系统数据存储请求将待存储数据存储到对应的各存储系统中。

进一步地，根据所述统一数据存储请求获取待存储数据所对应的至少一个存储系统包括：从所述统一数据存储请求中解析获取系统标识，根据系统标识获取待存储数据所对应的至少一个存储系统；从所述统一数据存储请求中识别待存储数据的属性，根据所述待存储数据的属性选择对应的至少一个存储系统。

第二方面，本发明实施例还提供了一种数据业务处理装置，所述装置包括：

数据读取模块，用于根据接收到的数据业务处理请求，从第一存储系统中存储的原数据中读取待处理数据；

第一选择模块，用于根据所述待处理数据和数据业务处理请求的属性，选择第二存储系统；

数据处理模块，用于将所述待处理数据存储到第二存储系统中，并根据数据业务处理请求对待处理数据进行计算处理，且将产生的处理结果存储到第三存储系统中；

响应结果获取模块，用于从第三存储系统中获取处理结果，作为所述数据业务处理请求的响应结果；

数据删除模块，用于从所述第二存储系统中删除所述待处理数据，所述第三存储系统中的所述处理结果根据需要决定是否删除。

进一步地，所述第一存储系统、第二存储系统及第三存储系统的类型相同或不同，为下述存储系统中的任意一个：分布式对象存储系统、分布式块存储系统和分布式文件系统。

进一步地，数据读取模块包括：目标数据地址获取单元，用于获取接收到的数据业务处理请求中的目标数据地址；映射关系获取单元，用于获取类Map/Reduce计算框架计算目标数据在第一存储系统中的映射关系；数据读取单元，用于根据所述目标数据地址，基于所述映射关系从原数据中读取待处理数据。

进一步地，所述装置还包括：数据请求接收模块，用于通过统一应用程序编程接口接收用户的统一数据存储请求；第二选择模块，用于根据所述统一数据存储请求获取待存储数据所对应的至少一个存储系统；数据存储请求转换模块，用于根据获取的至少一个存储系统，基于设定转换规则，将所述统一数据存储请求转换为各所述存储系统对应的至少一个系统数据存储请求；第三选择模块，用于根据所述统一数据存储请求获取待存储数据所对应的至少一个存储系统；数据存储模块，用于根据所述系统数据存储请求将待存储数据存储到对应的各存储系统中。

进一步地，第二选择模块、第三选择模块都包括：第一选择单元，用于从所述统一数据存储请求中解析获取系统标识，根据系统标识获取待存储数据所对应的至少一个存储系统；第二选择单元，用于从所述统一数据存储请求中识别待存储数据的属性，根据所述待存储数据的属性选择对应的至少一个存储系统。

本发明通过将数据处理请求涉及的数据转存至适合的存储系统进行处理，充分利用了各种存储系统的特点，灵活应用、且速度快、可靠性高。

附图说明

图1是本发明第一实施例中的数据业务处理方法的流程图。

图2是本发明第二实施例中的数据业务处理方法的流程图。

图3A是本发明第三实施例中的数据业务处理方法的流程图。

图3B是本发明第三实施例所适用的系统架构示意图。

图4是本发明第四实施例中的数据业务处理装置的结构图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

在图1中示出了本发明的第一实施例。本发明实施例适用于一种存储架构，该存储架构包括多种存储系统，该存储系统设置有统一的存储接口，处理数据业务。该每种存储系统中可存储一些原数据，对原数据的数据业务处理可以在多个存储系统的配合下完成。

图1是本发明第一实施例中的数据业务处理方法的流程图，该实现流程100可以由数据业务处理装置来执行，该装置可以由软件和/或硬件来实现，配置在存储架构中，控制各存储系统的数据业务处理过程。该方法详述如下：

在步骤101中，根据接收到的数据业务处理请求，从第一存储系统中存储的原数据中读取待处理数据。

在本实施例中，存储系统可以为多种，由于存储系统的不同，所以可以有多种方式来实现根据数据业务处理请求来确定待处理数据，以及寻址的方式。例如，直接寻址或者间接寻址方式。

其中，数据业务处理请求可包括数据分析、统计、预测等，具体包括对数据的增加(Create)、查询(Retrieve)、更新(Update)和删除(Delete)等操作，可以指明目标数据地址，或通过查询确定待处理数据的目标数据地址。本步骤中，可以根据数据业务处理请求中确定与该处理请求相关的所有数据，作为待处理数据。待处理数据可能只是原数据的部分数据。

在步骤102中，根据所述待处理数据和数据业务处理请求的属性，选择第二存储系统。

在本实施例中，可以选择用来存储待处理数据的存储系统作为第二存储系统。选择的依据是所述待处理数据和数据业务处理请求的属性，例如待处理数据的数据量大小，处理请求是读写操作还是查询操作中。由于存储系统各自的特点，所以其分别适用于不同的数据业务处理，例如，部分存储系统会更适用于对小文件的处理。第二存储系统与第一存储系统可以为同一类型的存储系统，也可以为不同类型的存储系统。

在步骤103中，将所述待处理数据存储到第二存储系统中，并根据数据业务处理请求对待处理数据进行计算处理，且将产生的处理结果存储到第三存储系统中。

在本实施例中，将所述待处理数据存储到第二存储系统中，并根据数据业务处理请求对待处理数据进行计算处理，比如对待处理数据进行统计、分析、预测等等，处理后的结果存储在第三存储系统中。

在步骤104中，从第三存储系统中获取处理结果，作为所述数据业务处理请求的响应结果。

在本实施例中，将步骤103中计算处理得到的处理结果从第三存储系统中读取出来，作为所述数据业务处理请求的响应结果反馈给用户。

在步骤105中，从所述第二存储系统中删除所述待处理数据，所述第三存储系统中的所述处理结果根据需要决定是否删除。

在本实施例中，删除存储在第二存储系统中的所述待处理数据和第三存储系统中的所述处理结果。我们对数据进行的处理都是对存储在第二存储系统中的待处理数据进行的操作处理，而第一存储系统中的原数据并未进行变化。将处理结果响应给用户，可以包括将读取结果、查询结果返回给用户，也包括将处理结果写入原数据，以保持原数据的正确性。所述存储在第二系统中的待处理数据仅作为过渡数据使用，所以可以将其删除，保留更多的存储空间用来存储其他数据，所以在得到数据业务处理请求的响应结果后，将这些数据从第二存储系统中删除。所述存储在第三存储系统中的处理结果根据需要来决定是否删除。

本发明第一实施例将数据处理请求涉及的数据转存至适合的存储系统进行处理，充分利用了各种存储系统的特点，灵活应用、且速度快、可靠性高。

在上述技术方案的基础上，步骤101和步骤105中的第一存储系统、第二存储系统及第三存储系统的类型可以相同也可以不同，为下述存储系统中的任意一个：分布式对象存储系统、分布式块存储系统和分布式文件系统。比如swift属于分布式对象存储；sheepdog、ceph、cinder属于分布式块存储；hdfs、GlusterFS、Lustre属于分布式文件系统等。

在图2中示出了本发明的第二实施例。

图2是本发明第二实施例中的数据业务处理方法的流程图，本实施例在上述各实施例的基础上，优选是将根据接收到的数据业务处理请求，从第一存储系统中存储的原数据中读取待处理数据进一步优化为根据接收到的数据业务处理请求中的目标数据地址，基于类Map/Reduce计算框架计算目标数据在第一存储系统和第二存储系统之间的(中的)映射关系，根据所述映射关系从原数据中读取待处理数据。

该实现流程200详述如下：

在步骤201中，接收数据业务处理请求。

在本实施例中，接收数据业务处理请求，该数据业务处理请求包括目标数据地址以及对数据的统计、分析、预测，也包括对数据的增加(Create)、查询(Retrieve)、更新(Update)和删除(Delete)等操作。

在步骤202中，基于类Map/Reduce计算框架计算目标数据在第一存储系统和第二存储系统之间的映射关系。

在本实施例中，由于数据处理模块采用类Map/Reduce计算框架，我们基于类Map/Reduce计算框架计算出目标数据在第一存储系统和第二存储系统之间(中)的映射关系。所述第一存储系统可以为以下任意存储系统：分布式块存储系统、分布式对象存储系统以及分布式文件系统。

类Map/Reduce计算框架是一种原理与Map/Reduce相同或类似的方法。Map/Reduce是一种编程模型，用于大规模数据集(大于1TB)的并行运算。概念"Map(映射)"和"Reduce(化简)"，和他们的主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。当前的软件实现是指定一个Map(映射)函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce(化简)函数，用来保证所有映射的键值对中的每一个共享相同的键组。

Map/Reduce通过把对数据集的大规模操作分发给网络上的每个节点实现可靠性；每个节点会周期性的把完成的工作和状态的更新报告回来。如果一个节点保持沉默超过一个预设的时间间隔，主节点(类同Google File System中的主服务器)记录下这个节点状态为死亡，并把分配给这个节点的数据发到别的节点。每个操作使用命名文件的原子操作以确保不会发生并行线程间的冲突；当文件被改名的时候，系统可能会把他们复制到任务名以外的另一个名字上去。

在步骤203中，根据接收到的数据业务处理请求中的目标数据地址和所述映射关系从原数据中读取待处理数据。

在步骤204中，根据所述待处理数据和数据业务处理请求的属性，选择第二存储系统。

在步骤205中，根据所述数据存储请求，将所述待处理数据存储到第二存储系统中，并根据数据业务处理请求对待处理数据进行计算处理，且将产生的处理结果存储到第三存储系统中。

在步骤206中，从第三存储系统中获取处理结果，作为所述数据业务处理请求的响应结果。

在步骤207中，从所述第二存储系统中删除所述待处理数据，所述第三存储系统中的所述处理结果根据需要决定是否删除。

本发明第二实施例通过采用类Map/Reduce计算框架将数据处理请求涉及的数据转存至适合的存储系统进行处理，充分利用了各种存储系统的特点和类Map/Reduce的并行计算，灵活应用、且速度快、可靠性高。相比于第一实施例，本发明第二实施例利用了类Map/Reduce并行计算的特点，提高了数据处理速度。

在图3中示出了本发明的第三实施例。

图3A是本发明第三实施例中的数据业务处理方法的流程图。图3B是本发明第三实施例所适用的系统架构示意图。该系统中包括多种存储系统，例如分布式块存储系统、分布式对象存储系统和/或分布式文件系统，还包括统一API接口和基于类Map/Reduce计算框架的控制器，可用于执行本发明实施例的技术方案。

在上述实施例的基础上，本实施例还包括了以下步骤：

在步骤301中，通过统一应用程序编程接口接收用户的统一数据存储请求。

在本实施例中，对于不同的存储系统，我们将用来接收数据存储请求的不同接口封装成统一的应用程序编程接口，接收用户的统一数据存储请求。

API(Application Programming Interface,应用程序编程接口)是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件的以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。API(Application ProgrammingInterface，应用编程接口)其实就是操作系统留给应用程序的一个调用接口，应用程序通过调用操作系统的API而使操作系统去执行应用程序的命令或动作。我们通过统一的应用程序编程接口API接收用户的数据存储请求。API接口支持RESTful、FUSE以及java、C、python等语言。

在步骤302中，根据所述统一数据存储请求获取待存储数据所对应的至少一个存储系统。

在本实施例中，根据所述统一数据存储请求的属性，通过多种方式选取与待存储数据所对应的至少一个存储系统。例如我们可以通过以下方式获取至少一个存储系统：

从所述统一数据存储请求中解析获取系统标识，根据系统标识获取待存储数据所对应的至少一个存储系统；或

从所述统一数据存储请求中识别待存储数据的属性，根据所述待存储数据的属性选择对应的至少一个存储系统。

例如，我们可以选择分布式对象存储系统、分布式块存储系统或者分布式文件系统中的其中一个，也可以选择其中两个等。

在步骤303中，根据获取的至少一个存储系统，基于设定转换规则，将所述统一数据存储请求转换为各所述存储系统对应的至少一个系统数据存储请求。

在本实施例中，根据获取的存储系统，基于设定的转换规则，将所述统一数据存储请求转换为各所属存储系统的至少一个系统数据存储请求。其中，设定的转换规则有分布式块存储系统、分布式对象存储系统和分布式文件存储系统之间互相转换的规则。例如，将统一数据存储到分布式文件系统的请求转换成分布式块存储系统的存储请求或者分布式对象存储系统的存储请求。

在步骤304中，根据所述系统数据存储请求将待存储数据存储到对应的各存储系统中。

在本实施例中，根据分布式块存储系统的系统数据存储请求将待存储数据存储到分布式块存储系统中，或者根据分布式对象存储系统的系统数据存储请求将待存储数据存储到分布式对象存储系统中。

本发明第三实施例与上述实施例中的步骤无必须的时序性限定。与上述实施例相比，本发明第三实施例为用户提供了多种存储系统的统一接口，用户无需了解不同存储系统的特点，由系统自动完成存储系统的选择和存储操作。并且还增加了各存储系统之间的转换，使各个系统之间也可以进行数据的平滑迁移。例如，可以将数据从原存储系统中读出再进行存储，即完成了将数据进行系统间转换的操作。

在图4中示出了本发明的第四实施例。

图4是本发明第四实施例中的数据业务处理装置的结构图。本实施例的装置均适用于上述实施例。如图4所示，该装置包括数据读取模块401、第一选择模块402、数据处理模块403、响应结果获取模块404和数据删除模块409。

其中，数据读取模块401，用于根据接收到的数据业务处理请求，从第一存储系统中存储的原数据中读取待处理数据。

第一选择模块402，用于根据所述待处理数据和数据业务处理请求的属性，选择第二存储系统。

数据处理模块403，用于将所述待处理数据存储到第二存储系统中，并根据数据业务处理请求对待处理数据进行计算处理，且将产生的处理结果存储到第三存储系统中。

响应结果获取模块404，用于从第三存储系统中获取处理结果，作为所述数据业务处理请求的响应结果。

数据删除模块409，用于从所述第二存储系统中删除所述待处理数据和所述处理结果。

本发明第四实施例将数据处理请求涉及的数据转存至适合的存储系统进行处理，充分利用了各种存储系统的特点，灵活应用、且速度快、可靠性高实现各存储系统之间的转换，使同一业务也可以采用多种存储系统，各个系统之间也可以进行数据的平滑迁移。

在上述方案中，所述第一存储系统和第二存储系统可以相同或不同，为下述存储系统中的任意一个：分布式对象存储系统、分布式块存储系统和分布式文件系统。

优选是，数据读取模块401包括：目标数据地址获取单元4011、映射关系获取单元4012和数据读取单元4013。其中，目标数据地址获取单元4011，用于获取接收到的数据业务处理请求中的目标数据地址；映射关系获取单元4012，用于获取类Map/Reduce计算目标数据在第一存储系统中的映射关系；数据读取单元4013，用于根据所述目标数据地址，基于所述映射关系从原数据中读取待处理数据。

在上述方案基础上，该装置还可以进一步包括：数据请求接收模块405、第二、三选择模块406、数据存储请求转换模块407和数据存储模块408。其中，数据请求接收模块405，用于通过统一应用程序编程接口接收用户的统一数据存储请求。第二、三选择模块406，用于根据所述统一数据存储请求获取待存储数据所对应的至少一个存储系统。数据存储请求转换模块407，用于根据获取的至少一个存储系统，基于设定转换规则，将所述统一数据存储请求转换为各所述存储系统的至少一个系统数据存储请求。数据存储模块408，用于根据所述系统数据存储请求将待存储数据存储到对应的各存储系统中。

上述技术方案，能够为用户提供多存储系统的统一接口，自动完成适当存储系统的选择和操作。

在本实施例中，第二、三选择模块406进一步可包括第一选择单元4061和/或第二选择单元4062，其中第一选择单元4061，用于从所述统一数据存储请求中解析获取系统标识，根据系统标识获取待存储数据所对应的至少一个存储系统；第二选择单元4062，用于从所述统一数据存储请求中识别待存储数据的属性，根据所述待存储数据的属性选择对应的至少一个存储系统。我们可以选择分布式对象存储系统、分布式块存储系统或者分布式文件系统中的其中一个，也可以选择其中两个等。所述待存储数据为所述数据业务处理请求的响应结果。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (10)

1.一种数据业务处理方法，其特征在于，所述方法包括：

根据接收到的数据业务处理请求，从第一存储系统中存储的原数据中读取待处理数据；

根据所述待处理数据和数据业务处理请求的属性，选择第二存储系统，其中，选择用来存储待处理数据的存储系统作为所述第二存储系统；

将所述待处理数据存储到第二存储系统中，并根据数据业务处理请求对待处理数据进行计算处理，且将产生的处理结果存储到第三存储系统中；

从第三存储系统中获取处理结果，作为所述数据业务处理请求的响应结果；

从所述第二存储系统中删除所述待处理数据，所述第三存储系统中的所述处理结果根据需要决定是否删除。

2.根据权利要求1所述的数据业务处理方法，其特征在于：

所述第一存储系统、第二存储系统及第三存储系统的类型相同或不同，为下述存储系统中的任意一个：分布式对象存储系统、分布式块存储系统和分布式文件系统。

3.根据权利要求1或2所述的数据业务处理方法，其特征在于，根据接收到的数据业务处理请求，从第一存储系统中存储的原数据中读取待处理数据包括：

根据接收到的数据业务处理请求中的目标数据地址，基于类Map/Reduce计算框架计算目标数据第一存储系统和第二存储系统的映射关系，根据所述映射关系从原数据中读取待处理数据到第二存储系统。

4.根据权利要求1所述的数据业务处理方法，其特征在于，还包括：

通过统一应用程序编程接口接收用户的统一数据存储请求；

根据所述统一数据存储请求获取待存储数据所对应的至少一个存储系统；

根据获取的至少一个存储系统，基于设定转换规则，将所述统一数据存储请求转换为各所述存储系统对应的至少一个系统数据存储请求；

根据所述系统数据存储请求将待存储数据存储到对应的各存储系统中。

5.根据权利要求4所述的数据业务处理方法，其特征在于，根据所述统一数据存储请求获取待存储数据所对应的至少一个存储系统包括：

从所述统一数据存储请求中解析获取系统标识，根据系统标识获取待存储数据所对应的至少一个存储系统；或

从所述统一数据存储请求中识别待存储数据的属性，根据所述待存储数据的属性选择对应的至少一个存储系统。

6.一种数据业务处理装置，其特征在于，所述装置包括：

数据读取模块，用于根据接收到的数据业务处理请求，从第一存储系统中存储的原数据中读取待处理数据；

第一选择模块，用于根据所述待处理数据和数据业务处理请求的属性，选择第二存储系统，其中，选择用来存储待处理数据的存储系统作为所述第二存储系统；

数据处理模块，用于将所述待处理数据存储到第二存储系统中，并根据数据业务处理请求对待处理数据进行计算处理，且将产生的处理结果存储到第三存储系统中；

响应结果获取模块，用于从第三存储系统中获取处理结果，作为所述数据业务处理请求的响应结果；

数据删除模块，用于从所述第二存储系统中删除所述待处理数据，所述第三存储系统中的所述处理结果根据需要决定是否删除。

7.根据权利要求6所述的数据业务处理装置，其特征在于：

所述第一存储系统、第二存储系统及第三存储系统的类型相同或不同，为下述存储系统中的任意一个：分布式对象存储系统、分布式块存储系统和分布式文件系统。

8.根据权利要求6或7所述的数据业务处理装置，其特征在于，数据读取模块包括：

目标数据地址获取单元，用于获取接收到的数据业务处理请求中的目标数据地址；

映射关系获取单元，用于获取类Map/Reduce计算框架计算目标数据在第一存储系统和第二存储系统之间的映射关系；

数据读取单元，用于根据所述目标数据地址，基于所述映射关系从原数据中读取待处理数据到第二存储系统。

9.根据权利要求6所述的数据业务处理装置，其特征在于，还包括：

数据请求接收模块，用于通过统一应用程序编程接口接收用户的统一数据存储请求；

第二选择模块，用于根据所述统一数据存储请求获取待存储数据所对应的至少一个存储系统；

数据存储请求转换模块，用于根据获取的至少一个存储系统，基于设定转换规则，将所述统一数据存储请求转换为各所述存储系统对应的至少一个系统数据存储请求；

第三选择模块，用于根据所述系统数据存储请求获取待存储数据所对应的至少一个存储系统；

数据存储模块，用于根据所述系统数据存储请求将待存储数据存储到对应的各存储系统中。

10.根据权利要求9所述的数据业务处理装置，其特征在于，第二选择模块、第三选择模块都包括：

第一选择单元，用于从所述统一数据存储请求中解析获取系统标识，根据系统标识获取待存储数据所对应的至少一个存储系统；

第二选择单元，用于从所述统一数据存储请求中识别待存储数据的属性，根据所述待存储数据的属性选择对应的至少一个存储系统。