CN107948334A - 基于分布式存储系统的数据处理方法 - Google Patents

Abstract

本发明提供了基于分布式存储系统的数据处理方法，包括：定义至少包含压缩模式、离线压缩起始时间及离线压缩终止时间的压缩配置项；当写入待处理数据时，由客户端、服务端或者客户端与服务端先后对待处理数据执行链式压缩处理，并仅在离线压缩模式下根据离线压缩起始时间及离线压缩终止时间确定服务端介入执行链式压缩处理的时刻；当读取待处理数据时，至少由客户端执行链式解压缩处理；并在执行链式压缩处理或者链式解压缩处理后通过网络向对端设备进行响应。通过本发明，可提高带宽利用率，节省存储空间，加快数据重构速度，提高了分布式存储系统在执行写入操作或者读取操作时的数据吞吐能力。

Description

基于分布式存储系统的数据处理方法

技术领域

本发明涉及分布式存储技术领域，尤其涉及一种基于分布式存储系统的数据处理方法。

背景技术

随着虚拟化、云计算和大数据的发展、分布式存储系统成为数据存储的主要方式，在开源分布式存储领域，分布式存储系统都采用了基于副本的冗余技术或EC技术。

CEPH是开源的统一分布式存储系统，是上述目前最主流的开源存储项目之一。CEPH基于C/S(客户端/服务器)架构实现，客户端可以通过RADOS对外提供对象访问接口，也可以在RADOS之上对外提供高层应用接口，高层应用接口包括RBD、RGW和Ceph FS；服务端包括OSD、MON和MDS，分别负责数据的存储、CEPH集群状态的管理和文件系统元数据的管理；

当通过RADOS或者高层应用接口RBD、RGW和Ceph FS向CEPH集群写入数据时，RADOS以对象(RADOS将接收到的数据块称为“对象”)名的hash值、存储池PG数、PG掩码等作为输入参数、通过CRUSH计算得到对象的目标OSDs。采用基冗余技术时，会得到一个OSD列表，其中列表中的第一个OSD称为主OSD，其他的OSD称为副本OSD。然后RADOS与主OSD建立TCP/IP连接，通过网络将数据传输到主OSD端。

采用基于副本的冗余技术时，主OSD与各个副本OSD建立TCP/IP连接，通过网络并行的将数据传输到各个副本OSD，同时将数据存储到本地磁盘中；在存储系统出现OSD或者节点故障时，由于数据是副本形式存储，系统内部会根据数据的副本自动进行故障OSD或者节点上的数据进行重建恢复，以保证数据的冗余性。

数据以多副本形式存储、所需的存储空间及存储成本随着副本数的增加线性的增长，以n(n∈N+)副本为例，所需的存储空间为实际存储数据量的n倍，存储利用率为1/n；基于副本的冗余技术、存储成本高且存储利用率底。相关参考文件如中国发明专利CN105635252 A。

如果采用基于EC的冗余技术时，主OSD首先根据EC编码规则分割数据块并生成校验块，然后与各个副本OSD建立TCP/IP连接，通过网络并行的将数据块传输到各个副本OSD，同时将数据存储到本地磁盘中；在存储系统出现OSD或者节点故障时，系统内部会根据剩余的数据块自动进行故障OSD或者节点上的数据进行重建恢复，为保证数据的冗余性。

数据根据EC编码规则分块存储、所需的计算量随着EC编码规则所确定的冗余度的增加线性的增长，以K+M模式为例，写入数据需要切割为K个子数据块，同时生成M个校验块；读取数据时，需要读取K个数据块，然后合并为完整的数据，当出现数据块损坏或者丢失时，还需要通过校验块重新生成损坏或者丢失的数据块。因此，基于EC的冗余技术进行数据写入与读取时就导致副本的冗余过大。

更重要的是，单纯地提高K与M的数量无疑于增加了IO延迟，并严重影响了基于CEPH或者其他类型的分布式存储系统的IO性能，并对计算机的CPU及内存造成了非常大的计算开销，并造成磁盘存储空间的极大浪费。

发明内容

本发明的目的在于公开一种基于分布式存储系统的数据处理方法，用以提高带宽利用率，节省存储空间，加快数据重构速度，提升分布式存储系统在执行写入操作或者读取操作时的存储性能，降低分布式存储系统的设备部署成本。

为实现上述发明目的，本发明提供了一种基于分布式存储系统的数据处理方法，包括：

定义至少包含压缩模式、离线压缩起始时间及离线压缩终止时间的压缩配置项，所述压缩模式包括在线压缩模式与离线压缩模式；

当写入待处理数据时，由客户端、服务端或者客户端与服务端先后对所述待处理数据执行链式压缩处理，并仅在离线压缩模式下根据离线压缩起始时间及离线压缩终止时间确定服务端介入执行链式压缩处理的时刻；

当读取待处理数据时，至少由客户端执行链式解压缩处理；

并在执行链式压缩处理或者链式解压缩处理后通过网络向对端设备进行响应。

作为本发明的进一步改进，所述分布式存储系统包括：CEPH、Glusterfs、HDFS、Lustre。

作为本发明的进一步改进，当读取待处理数据时，由客户端执行链式压缩处理所得到的待处理数据，仅由客户端执行链式解压缩处理；

当部分读取待处理数据时，由服务端与客户端先后执行链式解压缩处理。

作为本发明的进一步改进，所述压缩配置项还包括：链式解压标签，

当读取待处理数据时，

若为由服务端执行链式压缩处理所得到的待处理数据，则根据所述链式解压标签决定由客户端或者服务端执行链式解压缩处理；

若为由客户端与服务端先后执行链式压缩处理得到的待处理数据，则根据所述链式解压标签决定仅由客户端或者客户端与服务端先后执行链式解压缩处理。

作为本发明的进一步改进，所述压缩配置项还包括：压缩开关、压缩算法、压缩块大小、压缩率临界值及压缩粒度；

其中，

所述压缩算法包括snappy压缩算法、zlib压缩算法、lzo压缩算法、lz4压缩算法或者gzip压缩算法；

所述压缩率临界值选定大于0且小于1的浮点值；

所述压缩块大小设置为服务端中2ⁿKB，n取大于或者等于1的正整数；

所述压缩粒度设置为存储池级别或者磁盘级别；

作为本发明的进一步改进，

所述压缩算法选用snappy压缩算法；

所述压缩块大小设置为64KB；

在客户端与服务端先后执行链式压缩处理时，将所述压缩粒度设置为对象级别。

作为本发明的进一步改进，所述数据处理方法还包括：

在写入待处理数据时，由RADOS和/或OSD对由待处理数据经过至少一次切割处理所形成的若干子数据块在文件系统中所形成的空洞进行至少一次合并处理；

在读取待处理数据时，由RADOS和/或OSD对由所述子数据块经过至少一次链式压缩处理所形成的压缩数据块经过链式解压缩处理后所形成的未经过链式压缩处理所对应的源数据在客户端的文件系统中分配文件系统空间。

作为本发明的进一步改进，所述OSD配置为主OSD及副本OSD；

在写入待处理数据时还包括：

首先，通过RBD将待处理数据转换为对象，当RADOS收到写入请求，对写入请求所对应的待处理数据所转换得到的上述对象，根据客户端的压缩配置项进行数据压缩；

然后，将压缩后所形成的压缩数据所形成的对象的对象名哈希值、PG数量、PGP数量、OSDMap、CrushMap作为CRUSH算法输入，计算对象在执行写入操作时所对应的位于服务端中的主OSD及副本OSD的设备列表；

将在客户端中执行数据压缩处理后的数据通过网络发送至服务端的主OSD，以通过主OSD根据压缩模式决定服务端的压缩时刻；

若为在线压缩模式，由主OSD根据服务端所设定的压缩配置项中的压缩算法执行数据压缩处理后，将压缩后的数据保存至挂载至服务端的本地磁盘中，同时将压缩后的数据通过网络发送至服务端的副本OSD；

若为离线压缩模式，主OSD直接将待处理数据存储至挂载至服务端的本地磁盘中，并将待处理数据通过网络发送至服务端的副本OSD，以仅由副本OSD根据服务端的压缩配置项在服务端中分别执行至少一次压缩后保存至挂载至服务端的本地磁盘中；

然后，由服务端的副本OSD通过网络向作为对端设备的主OSD进行响应；其中，

所述对象由对象标识oid、对象名称name、数据偏移o_offset、数据长度o_length、<offset,length>列表及数据块o_chunk共同描述。

作为本发明的进一步改进，所述OSD配置为主OSD；

在读取待处理数据时，还包括：

主OSD接收来自RADOS的读取请求后，将读取请求所对应的待处理数据反序列化为对象后，根据反序列化后所得到的对象的对象名从键-值数据库中获取对象的元数据，以通过所述元数据打开对象文件；

主OSD根据服务端的压缩配置项中的压缩算法执行解压缩处理，以生成若干解压缩数据块；

然后，将每个解压缩数据块在客户端中再次执行解压缩处理；

所述对象由对象标识oid、对象名称name、数据偏移o_offset、数据长度o_length、<offset,length>列表及数据块o_chunk共同描述。

作为本发明的进一步改进，所述网络选自Ethernet网络、Infiniband网络、RoCE网络、iWARP网络或者RDMA网络。

作为本发明的进一步改进，所述待处理数据包括：视频文件、音频文件、照片文件、文本文件或者数据库。

作为本发明的进一步改进，所述数据处理方法还包括：对在服务端和/或客户端中执行链式压缩处理后在文件系统中所形成的空洞进行合并。

作为本发明的进一步改进，所述数据处理方法还包括：对写入请求所对应的待处理数据反序列化为对象后，将对象的元数据及对象数据分别存储至服务端的键-值数据库及挂载至服务端的本地磁盘中；其中，所述键-值数据库为LevelDB或者RocksDB。

与现有技术相比，本发明的有益效果是：本发明所示出的基于分布式存储系统的数据处理方法，

首先，在写入或者读取待处理数据时，可通过在线数据压缩的手段显著地减少了数据大小，减小了压缩后或者解压缩的数据在客户端与服务端借助网络所发生的数据传输量，显著提高了网络带宽的利用率以及存储系统吞吐量，从而提高了该分布式存储系统在执行写入操作或者读取操作时的数据吞吐能力。

其次，通过离线数据压缩的手段显著地减少数据大小，显著减小了存储数据量，提高了服务端中的文件系统的存储空间利用率，降低了存储成本及设备的部署成本，具有良好的经济效益。

最后，分布式存储系统的客户端或者服务端在故障恢复时，通过采用链式压缩或者链式解压缩，从而显著地提高了恢复数据的速度，降低了数据重构过程对前端业务的影响(例如IO延迟)，显著提高了数据重构速度，从而提高了分布式存储系统在出现故障时的数据恢复速度。

附图说明

图1为描述对象文件、Object、PG及OSD之间映射关系的示意图；

图2为通过LibRBD向CEPH集群写入数据(即，执行链式压缩处理)的流程图；

图3为对象文件在客户端或者服务端执行一次压缩处理后在文件系统中所形成的文件系统逻辑图；

图4为在线压缩模式下由主OSD与副本OSD对待处理数据执行链式压缩处理后所形成的文件系统逻辑图；

图5为部分写入待处理数据后在文件系统中所形成的文件系统逻辑图；

图6为通过LibRBD向CEPH集群读取数据(即，执行链式解压缩处理)的流程图；

图7为客户端中的待处理数据通过链式解压缩处理后在文件系统中所形成的文件系统逻辑图；

图8为压缩块大小与压缩比的关系图；

图9为压缩块大小与增量内存的关系图；

图10为压缩块大小与增量CPU(单核)的关系图；

图11为压缩块大小与增量写入IOPS的关系图；

图12为压缩块大小与增量读取IOPS的关系图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

在详细阐述本发明各实施例之前，首先对说明书及实施例中所涉及的部分技术术语作简要的解释与说明。

1、EC：Erasure-code；

2、RADOS：Reliable Autonomous Distributed Object Store；

3、RBD：RADOS Block Device；

4、RGW：RADOS Gateway；

5、CephFS：Ceph Filesystem；

6、CRUSH：Controlled Replication Under Scalable Hashing；

7、PG：Placement Group；

8、OSD：Object Store Daemon；

9、MON：Monitor；

10、MDS：Metadata Server；

11、PGP:Placement Group of Placement。

本发明各实施例所示出的数据处理方法涉及对待处理数据进行压缩的处理方法及解压缩的处理方法，同时该数据处理方法运行的实例环境为分布式存储系统。该分布式存储系统包括但不限于CEPH、GlusterFS、HDFS或者Lustre。

具体而言，在基于CEPH的分布式存储系统中，每个数据片即为一个对象(Object)，在基于HDFS的分布式存储系统中，每个数据片即为一个CHUNK，再基于GlusterFS的分布式存储系统中，每个数据片即为文件(file)。

在说明书的各个实施方式中，我们以基于CEPH的分布式存储系统为范例进行示范性说明。本技术领域的普通技术人员可以合理地预测到，其他类型的分布式存储系统中，对不同的处理对象在客户端(Client)及服务端(Server)进行压缩处理及解压缩处理的过程中极具参考价值，并可通过本发明各个实施例进行合理预测并进行实施。

基于Ceph的分布式存储系统具有同时支持块(chunk)、文件(file)和对象(object)的先进架构，在稳定性、可管理性上有很强的优势，同时性能也可以满足用户需求。参图1所示，Ceph是一个Linux petabyte级分布式文件系统，其由多台PC机组成高性能、高可靠性并且可扩展的集群，并部分为四个部分。

1.客户端(Client)：提供数据并向用户提供服务，每个客户端实例向主机或者进程提供一组类似于POSIX接口(Portable Operating System Interface)或者RBD块接口或者RGW对象接口。

2.元数据服务器(MDS)：MDS，即Metadata Server。其用于缓存和同步分布式元数据，管理命名空间(Namespace)并协调安全性、一致性和耦合性。

3.对象存储集群(OSC，Object Storage Cluster)：其包含多个对象存储设备OSD_S，其中，下标“s”表示为复数个OSD，并通过OSD存储所有的数据及元数据，其中，所谓的元数据是数据的描述数据并包含描述数据属性(property)的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。同时，在基于Ceph的分布式存储系统中，OSD的角色通常被定义为主OSD(Primary OSD)与一个或者多个副本OSD(Secondary OSD)。

4.集群监视器(MONs)：维持基于Ceph的分布式存储系统中集群映射的主副本；并提供身份验证和日志记录服务。Ceph的监视器记录在监视器服务所有更改到一个单一的Paxos的实例(Instances)，并且Paxos为了一致性记录一个键-值的存储变化。Ceph的监视器在同步操作时可以查询大多数最新版本的集群映射。Ceph的监视器利用的键-值存储的快照和迭代器(使用LevelDB)，执行全局存储的同步。

在Ceph中，一个文件(file)会被分配一个来自MDS的节点号INO，文件以此为唯一标识符(UUID)。然后，文件被切分为几个对象，使用文件的节点号INO和对象号ONO(Objectnumber)，每个对象都会被分配一个对象标识符，即OID。运用基于对象标识符OID的哈希表，每个对象都会被分配到一个位置组(PG)。

然后，使用CRUSH算法，将PG映射到一系列对象存储设备OSD上。由此，在映射位置组以及副本到存储设备的过程中不需要依赖元数据，而是依据一个伪随机映射函数，从而简化了分配和查询数据的过程。因此，当用户在客户端打开一个文件时，客户端向MDS发送一个请求，并由MDS通过文件系统分层结构把文件名翻译成文件节点(iNode)，并获取INO、模式、文件大小、位置及其对应的元数据。若文件存在并可以获得相应的操作权限，则MDS同时赋予客户端对应的操作权。

在实施例中，所谓“读取数据”性质的操作与“解压缩数据”具有相同或者等同的技术含义，所谓“写入数据”性质的操作与“压缩数据”具有相同或者等同的技术含义。

总体而言，在本发明中，基于分布式存储系统的数据处理方法，包括：

定义至少包含压缩模式(c_mode)、离线压缩起始时间及离线压缩终止时间的压缩配置项，所述压缩模式(c_mode)包括在线压缩模式与离线压缩模式；

当写入待处理数据时，由客户端、服务端或者客户端与服务端先后对所述待处理数据执行链式压缩处理，并仅在离线压缩模式下根据离线压缩起始时间及离线压缩终止时间确定服务端介入执行链式压缩处理的时刻；

当读取待处理数据时，至少由客户端执行链式解压缩处理；

并在执行链式压缩处理或者链式解压缩处理后通过网络向对端设备进行响应。

在本实施方式中，所谓待处理数据包括但不限于：视频文件(video file)、音频文件(audio file)、照片文件(例如：JPG格式照片、TIF格式照片、GIF格式照片、RAW格式照片等其他一系列动态帧照片及静态照片)、文本文件(包括但不限于：txt格式的文本文件、JSON格式的文本文件等)或者数据库(包括但不限于关系型数据库或者非关系型数据库)。

需要说明的是，本申请中的技术术语“对端设备”为一个相对概念。具体而言，客户端相对于服务端而言即为对端设备；反之，服务端相对于客户端而言也为对端设备。同时，申请中的技术术语“写入数据”具有向对端设备执行数据写入、数据的部分写入或者数据压缩的技术含义；反之，技术术语“读取数据”具有自对端设备执行数据读取、数据部分读取或者数据解压缩的技术含义。

如图2至图5所示，其公开了一种基于分布式存储系统的数据处理方法，尤其是涉及一种基于CEPH的分布式存储系统中，通过客户端的libRBD向CEPH集群写入数据(即进行数据压缩的过程)的具体实现过程。本领域的普通技术人员可以合理预测到，当分布式存系统采用Glusterfs架构时，则通过客户端的libglusterfs向Glusterfs集群写入数据。当分布式存系统采用HDFS架构时，则通过客户端的libhdfs向HDFS集群写入数据。当分布式存系统采用Lustre架构时，则通过客户端的liblustre向Lustre集群写入数据。本领域的普通技术人员可以合理预测到，上述任一种分布式存储架构中的读取数据的操作与写入数据的操作在逻辑上互为逆向的操作。

具体的，在本实施方式中，基于CEPH的分布式存储系统中，通过客户端的libRBD向CEPH集群写入数据(即进行数据压缩的过程)的具体实现过程包括如下步骤：

步骤1：如图2所示，服务端在收到客户端发起的业务写入待处理数据的IO请求后，客户端的libRBD根据对象大小将IO请求所对应的待处理数据转化为对象IO。一个IO请求可能被映射到一个或多个对象。所述IO请求由<offset,length,data>标识。对象(object)是客户端中的libRBD中对数据块的一个抽象表示，包含对象标识(oid)、对象名(name)、数据偏移(o_offset)、数据长度(o_length)、子数据块(o_sub_chunk)的<offset,length>列表、数据块(o_chunk)。

步骤2：在客户端的libRBD中以对象为单位，依次向客户端中的RADOS发起写入待处理数据的IO请求(即对待处理数据进行压缩的IO请求)。

步骤3：若客户端的RADOS开启了压缩功能，则根据压缩配置项中的属性，例如压缩模式(c_mode)、压缩块大小(c_size)对齐、逻辑切割上述对象中的数据块，并更新所述对象子数据块(o_sub_chunk)<offset,length>列表信息。如图4所示，待写入数据块<o_chunk>被逻辑划分为待压缩块1(o_sub_chunk_0)和待压缩块2(o_sub_chunk_1)。

在本实施方式中，为了进一步提高基于ceph的分布式存储系统在读取或者写入数据的效率，并分担服务端的计算开销，在本实施方式中，所述压缩配置项还包括：链式解压标签(c_chain)；当读取待处理数据时，若为由服务端执行链式压缩处理所得到的待处理数据，则根据所述链式解压标签决定由客户端或者服务端执行链式解压缩处理；若为由客户端与服务端先后执行链式压缩处理得到的待处理数据，则根据所述链式解压标签决定仅由客户端或者客户端与服务端先后执行链式解压缩处理。

优选的，在本实施方式中，所述数据处理方法还包括：在写入待处理数据时，由RADOS和/或OSD对由待处理数据经过至少一次切割处理所形成的若干子数据块在文件系统中所形成的空洞进行至少一次合并处理；在读取待处理数据时，由RADOS和/或OSD对由所述子数据块经过至少一次链式压缩处理所形成的压缩数据块经过链式解压缩处理后所形成的未经过链式压缩处理所对应的源数据在客户端的文件系统中分配文件系统空间。

通过该技术方案可对待处理数据根据不同的压缩配置所最终形成的压缩块在服务端的文件系统分配合理的存储空间，或者对存储在服务端中的压缩块数据进行链式解压缩后所形成的解压缩数据在服务端的文件系统中所需要的存储空间提供合理依据，防止文件系统被过度地分配。当读取待处理数据时，由客户端执行链式压缩处理所得到的待处理数据，仅由客户端执行链式解压缩处理。

若为在线压缩模式，由主OSD根据服务端所设定的压缩配置项中的压缩算法执行数据压缩处理后，将压缩后的数据保存至挂载至服务端的本地磁盘中，同时将压缩后的数据通过网络发送至服务端的副本OSD；

若为离线压缩模式，主OSD直接将待处理数据存储至挂载至服务端的本地磁盘中，并将待处理数据通过网络发送至服务端的副本OSD，以仅由副本OSD根据服务端的压缩配置项在服务端中分别执行至少一次压缩后保存至挂载至服务端的本地磁盘中。

需要说明的是，在离线压缩模式下，既可以采取上述技术手段执行，也可以由副本OSD根据服务端的配置项在客户端中执行至少一次压缩后保存至挂载至服务端的本地磁盘中，也可以由副本OSD根据服务端的压缩配置项在服务端与客户端分别且顺序地执行至少一次压缩后保存至挂载至服务端的本地磁盘中。

当部分读取待处理数据时，由服务端与客户端先后执行链式解压缩处理。所述“先后”不仅可理解为计算机中进程层面的先后顺序关系，也可为被理解交替执行读取-写入操作。

步骤4：客户端中的RADOS根据配置的客户端压缩算法，例如snappy压缩算法，压缩上述的各个待压缩块(即待压缩块o_sub_chunk_0和待压缩块o_sub_chunk_1)，并更新所述对象中子数据块(o_sub_chunk)的<offset,length>列表信息。如图4所示，待压缩块o_sub_chunk_0和待压缩块o_sub_chunk_1分别被压缩为压缩块1(c_chunk_0)和压缩块2(c_chunk_1)并在服务端的文件系统中形成两个“节省空间”；其中，标识为“节省空间”、“客户端节省空间”及“服务端节省空间”所在的区域即表示与压缩前相比，压缩后所节省的空间。

具体的，在本实施方式中，所述压缩算法包括snappy压缩算法、zlib压缩算法、lzo压缩算法、lz4压缩算法或者gzip压缩算法。所述压缩率临界值(c_threshold)选定大于0且小于1的浮点值。压缩块大小(c_size)设置为服务端中2ⁿKB，n取大于或者等于1的正整数。压缩粒度(c_granular)设置为存储池级别或者磁盘级别。

进一步的，在本实施方式中，申请人意外地发现，当压缩算法选用snappy压缩算法并将所述压缩块大小(c_size)设置为64KB时，具有最有优异的压缩与解压缩效果，并且对节省存储空格并加快数据重构速度等其他技术指标而言，具有更为良好的技术效果。同时，在实施方式中，在客户端与服务端先后执行链式压缩处理时，将所述压缩粒度(c_granular)设置为对象级别。

压缩粒度(c_granular)限定压缩与解压缩的作用范围；当压缩粒度设置为存储池级别(pool)时表示解压缩可以作用于该存储池中所有虚拟磁盘的所有对象，当压缩粒度设置为磁盘级别时，表示解压缩只能作用于特定虚拟磁盘的对象。

步骤5：客户端中的RADOS将压缩后的各数据块收尾相接重新组装成一个完整的数据块，即执行合并操作。然后，更新所述对象的数据长度(o_length)和数据块(o_chunk)。如图4所示，压缩块1(c_chunk_0)和压缩块2(c_chunk_1)被重新合并为o_chunk，“客户端节省空间”区域即为压缩后整体缩减的空间。

步骤6：客户端中的RADOS将所述对象序列化。

步骤7：客户端中的RADOS根据配置的集群地址与监视器(Monitor)建立网络连接。所述网络连接可以是经典的Ethernet网络(基于TCP/IP协议)也可以是新型高性能网络，例如Infiniband网络、RoCE网络、iWARP网络或者RDMA网络。接着，RADOS向监视器(Monitor)发起获取集群状态请求，得到PG、PGP、OSDMap以及CrushMap信息。所述PG(Placement Group)，称为归置组，是多副本或者纠删码(EC)的逻辑管理单元，所述PGP(Placement Group ofPlacement)，称为组归置组，用来限定PG到OSD的排列组合，所述OSDMap，称为OSD映射表，用来记录CEPH集群中节点、OSD及其状态，所述CrushMap，称为Crush映射，对多CEPH集群中物理节点拓扑的抽象表示。

结合参照图1所示，在基于CEPH的分布式存储系统中，可根据Object名字的hash值(哈希值)。Object映射到不同的PG；当然，不同的Object也可能映射到相同的PG。根据OSDMap和CrushMap，PG映射到不同的OSD；当然，不同的PG也可能映射到相同的OSD。

在基于Ceph架构的分布式存储系统中，客户端是直接读或者写存放在OSD上的RADOS对象存储中的对象(data object)的，因此，Ceph需要走完(Pool,Object)→(Pool,PG)→OSD set→OSD/Disk完整的链路，才能让ceph的客户端(Client)知道目标数据object的具体位置在哪里。数据写入时，文件被切分成对象object，对象object先映射到PG，再由PG映射到OSD set。每个pool有多个PG，每个object通过计算hash值并取模得到它所对应的PG。PG再映射到一组OSD(OSD个数由pool的副本数决定)，第一个OSD是Primary，剩下的都是Replicas。Ceph分布数据的过程：首先计算数据x所在对象的Hash值并将结果和PG数目取余，以得到数据x对应的PG编号。然后，通过CRUSH算法将PG映射到一组OSD中。最后把数据x存放到PG对应的OSD中。这个过程中包含了两次映射，第一次是数据x到PG的映射。PG是抽象的存储节点，它不会随着物理节点的加入或则离开而增加或减少，因此，数据所建立映射到PG的映射关系是非常稳定的。

步骤8：客户端中的RADOS计算对象名称哈希值，将其连同PG、PGP、OSDMap、CrushMap作为CRUSH算法的输入，求得对象所应写入的OSD列表；其中OSD列表中第一个OSD称为主OSD，其他的OSD称为副本OSD。如图1所述，两副本情况下，一个PG映射到两个副本OSD。

步骤9：RADOS与主OSD建立网络连接，通过网络将上述序列化后的对象传输到主OSD。所述网络连接可以是经典的Ethernet网络(基于TCP/IP协议)，也可以是新型高性能网络Infiniband网络、RoCE网络、iWARP网络或者DRMA网络。

步骤10：主OSD接收到来自客户端的RADOS发起的写入待处理数据的IO请求后，将IO请求数据反序列化为对象。所述对象包含对象标识(oid)、对象名(name)、数据偏移(o_offset)、数据长度(o_length)、子数据块(o_sub_chunk)的<offset,length>列表、数据块(o_chunk)。

步骤11：根据请求反序列化后得到的对象名，从键-值(Key-Value)数据库中获取对象的元数据。所述键-值(Key-Value)数据库采用LevelDB或RocksDB。对象元数据包含：客户端元数据(c_metadata)、服务端元数据(s_metadata)两部分；所述客户端元数据包含数据偏移(c_offset)、数据长度(c_length)、子数据块(c_sub_chunk)<offset,length>列表，三个字段分别表示未经过服务端压缩前数据的偏移、长度和子数据块信息；所述服务端元数据包含数据偏移(s_offset)、数据长度(s_length)、子数据块压缩位图(c_bitmap)、子数据块(s_sub_chunk)<offset,length,c_length>列表，四个字段分别表示经过服务端压缩后数据的偏移、长度、压缩状态和子数据块列表。所述子数据块压缩标位图，是一个0/1位图，用来表征相应的数据块是否压缩，“0”表示未被压缩，“1”表示已被压缩。如果所述对象元数据不存在，创建一个新的元数据对象，并用接收到的信息初始化该新的对象元数据。

步骤12：根据对象名创建或者打开对象文件。所述对象文件，是一个普通的稀疏文件，由一系列设定的压缩块大小(c_size)的数据块组成。如图3所示，在磁盘介质(在本实施方式中具体为服务端的虚拟磁盘)上对象文件就是一块二进制数据。当然可能由于磁盘空间分配问题，出现离散存储的现象，在文件系统这个逻辑视图上看，可以认为对象文件由一系列有空洞的压缩块组成，也就是一个稀疏文件。

如图3所示，文件系统中可以被执行压缩处理并形成n个压缩块的数据在文件系统中呈离散状态，并可在被压缩后分别形成空洞。该空洞为某个数据块在被执行压缩处理后，在服务端的文件系统中所形成的空白存储空间。

步骤13：根据压缩配置项中的压缩模式(c_mode)决定何时执行压缩操作，如果是离线压缩或者压缩开关被置为False，跳转到步骤22，否则继续执行步骤14。

步骤14：根据压缩配置项中的压缩块大小(c_size)、逻辑切割对象中的数据块，每个子数据块由c_sub_chunk的<offset,length>标识。如图4所示，对象数据被逻辑切分为待压缩块c_sub_chunk_0和待压缩块c_sub_chunk_1。

步骤15：将上述生成的待压缩块c_sub_chunk_0和待压缩块c_sub_chunk_1所对应的<offset,length>和步骤11中对象元数据中的s_sub_chunk的<offset,length,c_length>进行比较，如果下述式(1)与式(2)的数学关系同时成立：

c_sub_chunk.offset≤s_sub_chunk.offset (1)；

c_sub_chunk.length≧s_sub_chunk.length (2)。

或者没有找到与所述待压缩块c_sub_chunk相匹配的s_sub_chunk，则表明是覆盖写，跳转到步骤18；否则是部分写，继续执行步骤16。

步骤16：如图5所示，根据对象元数据中压缩块s_sub_chunk的<offset,length,c_length>中指定的数据偏移o_offset和数据长度c_length从对象文件中读取相应的压缩块数据，如果对象元数据中子数据块压缩位图(c_bitmap)中与s_sub_chunk相对应的位为1，即：

chunk_no＝s_sub_chunk.offset/c_size

c_bitmap[1<<3][chunk_no<<3]&[chunk_no&((1<<3)-1)]＝1

则根据配置的压缩算法解压缩读取的数据。

步骤17：如图5所示，将步骤14中待写入数据c_sub_chunk的<offset,length>和上述解压缩后的数据块s_sub_chunk的<offset,lengh,c_length>进行合并；

若待写入数据的c_sub_chunk的o_offset>解压缩块s_sub_chunk的o_offset，则将解压缩块s_sub_chunk的前部区域进行合并，并称为“前合并区”，即：将待写入数据c_sub_chunk的o_offset–数据s_sub_chunk的o_offset，并添加到待写入数据c_sub_chunk的首部；

若数据s_sub_chunk的offset+数据s_sub_chunk.length>待写入数据c_sub_chunk的o_offset+数据s_sub_chunk的length，则将数据s_sub_chunk的尾部区域进行合并，并称为“后合并区”，即：将(解压缩块s_sub_chunk的offset+解压缩块s_sub_chunk的length)-(待写入数据c_sub_chunk的offset+解压缩块s_sub_chunk的length)添加到待写入数据c_sub_chunk的尾部。

然后，并更新待写入数据c_sub_chunk的<offset,length>信息。

步骤18：根据压缩配置项中的压缩算法压缩待写入数据c_sub_chunk，并更新对象元数据中s_sub_chunk的<offset,length,c_length>信息；其中，s_sub_chunk.length为待写入数据在压缩前的数据长度，s_sub_chunk.c_length为待写入数据在压缩后的数据长度。因此，在客户端中所执行的压缩，加上本次(服务端)压缩合称为链式压缩。

如图4所示，待压缩块c_sub_chunk_0和待压缩块c_sub_chunk_1在执行压缩后，分别生成待压缩块11(cc_sub_chunk_0)和待压缩块22(cc_sub_chunk_1)；其中，标识为“压缩后节省的空间”所在区域即表示与压缩前相比，压缩后各个数据块所节省的空间。

步骤19：如图2所示，根据压缩配置项中的压缩率临界值(c_threshold)与s_sub_chunk.c_length/s_sub_chunk.length的比值确定是否采纳压缩数据块，若下述等式(3)成立：

c_threshold≧(s_sub_chunk.c_length/s_sub_chunk.length) (3)；

则采纳压缩后的数据，并将对象元数据中子数据块压缩位图中与所述子数据块对应的置为1；

若上述式(3)不成立，则采纳压缩前的数据，并将对象元数据中子数据块压缩位图中与所述子数据块对应的子数据块压缩标位图中的位重置为0，同时将s_sub_chunk.c_length重置为c_sub_chunk.length。

步骤20：根据步骤14中的切割次序重新对齐、组装步骤19中的各采纳子数据块，生成新的数据块。如图4所示，采纳后的压缩块11(cc_sub_chunk_0)和压缩块22(cc_sub_chunk_1)合并为新的数据块，“服务端节省空间”区域表示服务端压缩后整体缩减空间，“服务端节省空间”和“客户端节省空间”的总和为链式压缩后整体缩减空间。通过本发明，可最终将图4中的最上方的待写入数据，先由客户端执行压缩后，再由服务端执行一次压缩，以形成所述链式压缩处理。需要说明的是，在本申请中，当客户端与服务端先后对待处理数据进行链式压缩的过程中，客户端与服务端可往复地数据压缩过程。

参图4所示，在本申请中，最终通过本发明所示出的数据处理方法可将原始状态下的写入IO请求所对应的待写入数据(o_chunk)压缩为由压缩块11与压缩块22所组成的压缩数据，从而降低了服务端中的虚拟磁盘存储空间，同时也可显著地提高了网络带宽的利用率。同时，链式压缩节省空间由服务端节省空间与客户端节省空间共同组成。

步骤21：根据上述更新后的s_sub_chunk<offset,length,c_length>列表更新对象元数据中的s_offset和s_length。如图4所述，最终的数据由压缩块11(cc_sub_chunk_0)和压缩块(cc_sub_chunk_1)合并而成，

因此，s_offset＝cc_sub_chunk_0.offset

s_length＝cc_sub_chunk_1.offset+cc_sub_chunk_1.length

步骤22：如图2所示，主OSD序列化对象。

步骤23：主OSD将上述序列化后的对象元数据及其数据分别存储到本地键-值(Key-Value)数据库和虚拟磁盘中。

步骤24：主OSD与其他副本OSD建立网络连接，然后通过网络将上述序列化后的对象及其数据传输给各副本OSD。所述网络可以是经典的Ethernet网络(基于TCP/IP协议)，也可以是新型高性能网络，例如：Infiniband网络、RoCE网络、iWARP网络或者RDMA网络。

具体的，基于Infiniband协议的新型高性能网络采用分层结构，各个层次之间相互独立，下层为上层提供服务。其中，物理层定义了在线路上如何将比特信号组成符号，然后再组成帧、数据符号以及包之间的数据填充等,详细说明了构建有效包的信令协议等；链路层定义了数据包的格式以及数据包操作的协议，如流控、路由选择、编码、解码等；网络层通过在数据包上添加一个40字节的全局的路由报头(Global Route Header，GRH)来进行路由的选择，对数据进行转发。在转发的过程中，路由器仅仅进行可变的CRC校验,这样就保证了端到端的数据传输的完整性；传输层再将数据包传送到某个指定的队列偶(QueuePair，QP)中，并指示QP如何处理该数据包以及当信息的数据净核部分大于通道的最大传输单元MTU时，对数据进行分段和重组。

基于RDMA(Remote Direct Memory Access)协议的新型高性能网络可解决网络传输中服务端对数据处理(包括压缩处理与解压缩处理或者写入数据与读取数据)的延迟。RDMA通过网络把资料直接传入计算机(即服务端或者客户端所在的计算机)的存储区，将数据从一个系统快速移动到远程系统存储器中，而不对操作系统造成任何影响，这样就不需要用到多少计算机的处理功能。它消除了外部存储器复制和上下文切换的开销，因而能解放内存带宽和CPU周期用于改进应用系统性能。

步骤25：副本OSD收到数据写入请求后，完成数据的本地存储，并发送应答给主OSD

步骤26：主OSD收到所有副本OSD的应答后，向客户端发送应答。结束。

如图6至如图7所示，其公开了一种基于分布式存储系统的数据处理方法，尤其是涉及一种基于CEPH的分布式存储系统中，通过客户端的libRBD向CEPH集群读取数据(即进行数据解压缩的过程)的具体实现过程，并包括如下步骤：

步骤1：如图6所示，当客户端接收到业务读取请求后，客户端中的libRBD根据对象大小将业务请求IO转化为对象IO，一个业务IO请求可能被映射到一个或多个对象。所述业务请求IO由<offset,length,data>标识。所述对象，是libRBD中对数据块的一个抽象表示，包含对象标识(oid)、对象名(name)、数据偏移(o_offset)、数据长度(o_length)、子数据块(o_sub_chunk)<offset,length>列表、数据块(o_chunk)。

步骤2：客户端中的RADOS将所述对象序列化。

步骤3：客户端中的RADOS根据配置的集群地址与监视器(Monitor)建立网络连接。所述网络连接可以是经典的Ethernet网络(TCP/IP)也可以是新型高性能网络Infiniband网络、RoCE网络、iWARP网络或者RDMA网络(参上文所示)。接着，RADOS向监视器(Monitor)发起获取集群状态请求，得到PG、PGP、OSDMap以及CrushMap信息。所述PG(Placement Group)，称为归置组，是多副本或者纠删码(EC)的逻辑管理单元，所述PGP(Placement Group ofPlacement)，称为组归置组，用来限定PG到OSD的排列组合，所述OSDMap，称为OSD映射表，用来记录CEPH集群中节点、OSD及其状态，所述CrushMap，称为Crush映射，对多CEPH集群中物理节点拓扑的抽象表示。

结合参照图1所示，根据对象Object名字的hash值，对象Object映射到不同的PG。当然，不同的Object也可能映射到相同的PG。根据OSDMap和CrushMap，PG映射到不同的OSD。当然，不同的PG也可能映射到相同的OSD。

步骤4：RADOS计算对象名称哈希值，将其连同PG、PGP、OSDMap、CrushMap作为CRUSH算法的输入，求得对象所应写入的OSD列表。OSD列表中第一个OSD称为主OSD，其他的OSD称为副本OSD。如图1所述，两副本情况下，一个PG映射到二个OSD。

步骤5：RADOS与主OSD建立网络连接，通过网络将上述序列化后的对象传输到主OSD。所述网络连接可以是经典的Ethernet网络(基于TCP/IP协议)也可以是新型高性能网络Infiniband网络、RoCE网络、iWARP网络或者RDMA网络。

步骤6：主OSD接收到来自RADOS的读取请求后，将请求数据反序列化为对象。所述对象包含对象标识(oid)、对象名(name)、数据偏移(o_offset)、数据长度(o_length)、子数据块(o_sub_chunk)的<offset,length>列表、数据块(o_chunk)。

步骤7：根据请求反序列化后得到的对象名，从键-值(Key-Value)数据库中获取对象的元数据。所述键-值(Key-Value)数据库可采用LevelDB或RocksDB。

对象元数据包含：客户端元数据(c_metadata)、服务端元数据(s_metadata)两部分；所述客户端元数据包含数据偏移(c_offset)、数据长度(c_length)、子数据块(c_sub_chunk)<offset,length>列表，三个字段分别表示未经过服务端压缩前数据的偏移、长度和子数据块信息；所述服务端元数据包含数据偏移(s_offset)、数据长度(s_length)、子数据块压缩位图(c_bitmap)、子数据块(s_sub_chunk)<offset,length,c_length>列表，四个字段分别表示经过服务端压缩后数据的偏移、长度、压缩状态和子数据块列表。所述子数据块压缩标位图，是一个0/1位图，用来表征相应的数据块是否压缩；其中，“0”表示未被压缩，“1”表示已压缩。

步骤8：根据对象名打开对象文件。所述对象文件，是一个普通的稀疏文件，由一系列设定的压缩块大小(c_size)的数据块组成。如图3所示，在磁盘介质(虚拟磁盘)上对象文件就是一块二进制数据。可能由于磁盘空间分配问题，出现离散存储的现象，在文件系统这个逻辑视图上看，可以认为对象文件由一系列有空洞的压缩块组成，也就是一个稀疏文件。空洞表示在文件系统中未存储数据的空白区域。

步骤9：如果开启了压缩(压缩开关置为True)，根据压缩配置项中的压缩块大小(c_size)对齐、逻辑切割对象中的数据块，生成的子数据块由c_sub_chunk的<offset,length>标识。

步骤10：将上述生成的c_sub_chunk<offset,length>和步骤7中对象元数据中的s_sub_chunk<offset,length,c_length>进行比较，如果下述等式(4)成立：

c_sub_chunk.offset/c_size＝s_sub_chunk.offset/c_size (4)；

则说明找到相匹配的s_sub_chunk；若否，则表明未找到匹配的s_sub_chunk，用0作为所述子数据块c_sub_chunk<offset,length>的填充值。

步骤11：根据上述匹配的s_sub_chunk<offset,length,c_length>中指定的offset和c_length从对象文件中读取相应的压缩块数据，如果对象元数据中子数据块压缩位图(c_bitmap)中与s_sub_chunk相对应的位为1，即：

chunk_no＝s_sub_chunk.offset/c_size

c_bitmap[1<<3][chunk_no<<3]&[chunk_no&((1<<3)-1)]＝1

并且链式解压缩标签(c_chain)为False，则根据配置的压缩算法解压缩读取的数据。如图7所示，与读取请求相匹配的压缩块有两个，分别是压缩块i和压缩块j，解压缩后生成两个解压缩数据块，分别是解压缩数据i和解压缩数据j。

步骤12：步骤9中切割生成的所有子数据块处理完后，合并、序列化各子数据块。从而将客户端中的数据i1、数据i2、数据j1及数据j2合并，并序列化并形成图7中最上方的数据，从而链式解压缩的数据处理方法。

步骤13：通过网络将应答数据发送给位于客户端的RADOS。所述网络连接可以是经典的Ethernet网络(基于TCP/IP协议)，也可以是新型高性能网络，例如：Infiniband网络、RoCE网络、iWARP网络或者RDMA网络(参上文所述)。

步骤14：客户端的RADOS收到来自主OSD的应答数据后，将应答数据反序列化。

步骤15：如果服务端压缩配置项中的链式解压缩标签(c_chain)为True，说明开启了链式解压缩(即：服务端压缩延迟到客户端解压缩，称为链式解压缩)，根据配置的服务端压缩算法解压缩数据块。如图7所示，与读取请求相匹配的压缩块有两个，分别是压缩块i和压缩块j，解压缩后生成两个解压缩数据块，分别是解压缩数据i和解压缩数据j。

步骤16：如果客户端压缩配置项中的压缩开关为True，则根据客户端压缩配置项中的算法再次解压缩数据块。如图7所示，解压缩数据i和解压缩数据j，经过客户端的再次解压缩后分别生成了数据i1、数据i2和数据j1、数据j2。由此，通过上述数据i1、数据i2和数据j1、数据j2共同组成经过链式解压缩处理所形成的客户端数据块，从完成了对待处理数据的读取操作。

步骤17：如图7所示，根据请求<offset,length>截取上述解压缩后的数据返回客户端的LibRBD。结束。

参图8至图12所示，在本实施方式中，压缩配置项的压缩块大小(c_size)设置为64KB等参数设定。在原生4M，以及不同压缩块大小(c_size)情况下，写入(读取)20G数据到CEPH集群的各项指标数据(例如：压缩比、内存占用、CPU占用、写入时间、读取时间等等)，具体参下表1及图9至如12所示。

压缩块大小	原生4M	4KB	8KB	16KB	32KB	64KB	128KB	256KB	512KB	1MB	2MB	4MB
													压缩比	0	2.99	3.57	4.13	4.55	4.86	4.86	4.87	4.87	4.87	4.78	4.26
内存占用(KB)	0	1236	1252	1276	1316	1404	1468	1860	2116	4464	7712	14192
													CPU占用(单核)	0	100％	100％	100％	100％	100％	100％	100％	100％	100％	100％	100％
写入时间(s)	130.333	45.27	38.982	34.006	32.345	29.572	29.572	29.116	29.116	29.116	28.899	32.903
													读取时间(s)	126.969	49.578	39.302	37.884	35.987	34.18	34.18	33.654	33.654	33.654	32.001	34.389
写入iops	39	113	131	150	158	173	173	175	175	175	177	155
													读取iops	40	103	130	135	142	149	149	152	152	152	159	148
大小(MB)	20480	6849	5736	4958	4501	4214	4214	4205	4205	4205	4285	4808
													有效写入块(KB)	4096	1370	1147	992	900	843	843	841	841	841	857	962
压缩时间(s)	0	22.522	20.803	20.631	19.901	21.791	20.039	19.783	19.782	20.058	20.345	21.932
													解压缩时间(s)	0	13.012	13.561	11.307	11.014	12.584	17.508	20.051	21.682	10.596	11.174	13.495
MEMCPY时间(s)	0	4.548	4.543	4.534	4.516	4.481	4.409	4.267	3.892	3.413	2.276

表1

从表1所呈现的指标数据，申请人注意到当压缩配置项中的压缩块大小(c_size)设定为64KB、128KB、256KB、512KB、1MB、2MB时，压缩比指标处于较高的阶段。

然而，结合图8-图12，申请人惊喜地注意到：过大的压缩块大小(c_size)会导致内存增量这一指标的急速增加，从而导致整个ceph集群的内存开销过大，因此，申请人将压缩块大小(c_size)设置为64KB是非常合理且科学的。该压缩配置项兼顾了在读取及写入待处理数据时压缩率及计算开销，可显著地减少数据大小，显著减小了存储数据量，提高了服务端中的文件系统的存储空间利用率，降低了存储成本及设备的部署成本，尤其是能够显著地降低服务端中的存储成本，提高存储空间的利用率，并降低了形成服务端的硬件设备的部署成本，因此具有良好的经济效益。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (13)

1.基于分布式存储系统的数据处理方法，其特征在于，包括：

定义至少包含压缩模式、离线压缩起始时间及离线压缩终止时间的压缩配置项，所述压缩模式包括在线压缩模式与离线压缩模式；

当写入待处理数据时，由客户端、服务端或者客户端与服务端先后对所述待处理数据执行链式压缩处理，并仅在离线压缩模式下根据离线压缩起始时间及离线压缩终止时间确定服务端介入执行链式压缩处理的时刻；

当读取待处理数据时，至少由客户端执行链式解压缩处理；

并在执行链式压缩处理或者链式解压缩处理后通过网络向对端设备进行响应。

2.根据权利要求1所述的数据处理方法，其特征在于，所述分布式存储系统包括：CEPH、Glusterfs、HDFS、Lustre。

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

当读取待处理数据时，由客户端执行链式压缩处理所得到的待处理数据，仅由客户端执行链式解压缩处理；

当部分读取待处理数据时，由服务端与客户端先后执行链式解压缩处理。

4.根据权利要求2所述的数据处理方法，其特征在于，所述压缩配置项还包括：链式解压标签，

当读取待处理数据时，

若为由服务端执行链式压缩处理所得到的待处理数据，则根据所述链式解压标签决定由客户端或者服务端执行链式解压缩处理；

若为由客户端与服务端先后执行链式压缩处理得到的待处理数据，则根据所述链式解压标签决定仅由客户端或者客户端与服务端先后执行链式解压缩处理。

5.根据权利要求2所述的数据处理方法，其特征在于，所述压缩配置项还包括：压缩开关、压缩算法、压缩块大小、压缩率临界值及压缩粒度；

其中，

所述压缩算法包括snappy压缩算法、zlib压缩算法、lzo压缩算法、lz4压缩算法或者gzip压缩算法；

所述压缩率临界值选定大于0且小于1的浮点值；

所述压缩块大小设置为服务端中2ⁿKB，n取大于或者等于1的正整数；

所述压缩粒度设置为存储池级别或者磁盘级别。

6.根据权利要求5所述的数据处理方法，其特征在于，

所述压缩算法选用snappy压缩算法；

所述压缩块大小设置为64KB；

在客户端与服务端先后执行链式压缩处理时，将所述压缩粒度设置为对象级别。

7.根据权利要求2至6中任一项所述的数据处理方法，其特征在于，所述数据处理方法还包括：

在写入待处理数据时，由RADOS和/或OSD对由待处理数据经过至少一次切割处理所形成的若干子数据块在文件系统中所形成的空洞进行至少一次合并处理；

在读取待处理数据时，由RADOS和/或OSD对由所述子数据块经过至少一次链式压缩处理所形成的压缩数据块经过链式解压缩处理后所形成的未经过链式压缩处理所对应的源数据在客户端的文件系统中分配文件系统空间。

8.根据权利要求7所述的数据处理方法，其特征在于，所述OSD配置为主OSD及副本OSD；

在写入待处理数据时还包括：

首先，通过RBD将待处理数据转换为对象，当RADOS收到写入请求，对写入请求所对应的待处理数据所转换得到的上述对象，根据客户端的压缩配置项进行数据压缩；

然后，将压缩后所形成的压缩数据所形成的对象的对象名哈希值、PG数量、PGP数量、OSDMap、CrushMap作为CRUSH算法输入，计算对象在执行写入操作时所对应的位于服务端中的主OSD及副本OSD的设备列表；

将在客户端中执行数据压缩处理后的数据通过网络发送至服务端的主OSD，以通过主OSD根据压缩模式决定服务端的压缩时刻；

若为在线压缩模式，由主OSD根据服务端所设定的压缩配置项中的压缩算法执行数据压缩处理后，将压缩后的数据保存至挂载至服务端的本地磁盘中，同时将压缩后的数据通过网络发送至服务端的副本OSD；

若为离线压缩模式，主OSD直接将待处理数据存储至挂载至服务端的本地磁盘中，并将待处理数据通过网络发送至服务端的副本OSD，以仅由副本OSD根据服务端的压缩配置项在服务端中分别执行至少一次压缩后保存至挂载至服务端的本地磁盘中；

然后，由服务端的副本OSD通过网络向作为对端设备的主OSD进行响应；其中，

所述对象由对象标识oid、对象名称name、数据偏移o_offset、数据长度o_length、<offset,length>列表及数据块o_chunk共同描述。

9.根据权利要求7所述的数据处理方法，其特征在于，所述OSD配置为主OSD；

在读取待处理数据时，还包括：

主OSD接收来自RADOS的读取请求后，将读取请求所对应的待处理数据反序列化为对象后，根据反序列化后所得到的对象的对象名从键-值数据库中获取对象的元数据，以通过所述元数据打开对象文件；

主OSD根据服务端的压缩配置项中的压缩算法执行解压缩处理，以生成若干解压缩数据块；

然后，将每个解压缩数据块在客户端中再次执行解压缩处理；

所述对象由对象标识oid、对象名称name、数据偏移o_offset、数据长度o_length、<offset,length>列表及数据块o_chunk共同描述。

10.根据权利要求1、8或者9或者所述的数据处理方法，其特征在于，所述网络选自Ethernet网络、Infiniband网络、RoCE网络、iWARP网络或者RDMA网络。

11.根据权利要求7、8或者9所述的数据处理方法，其特征在于，所述待处理数据包括：视频文件、音频文件、照片文件、文本文件或者数据库。

12.根据权利要求7所述的数据处理方法，其特征在于，所述数据处理方法还包括：对在服务端和/或客户端中执行链式压缩处理后在文件系统中所形成的空洞进行合并。

13.根据权利要求9所述的数据处理方法，其特征在于，所述数据处理方法还包括：对写入请求所对应的待处理数据反序列化为对象后，将对象的元数据及对象数据分别存储至服务端的键-值数据库及挂载至服务端的本地磁盘中；其中，所述键-值数据库为LevelDB或者RocksDB。