CN106170968B - 一种数据压缩存储方法、装置，及分布式文件系统 - Google Patents
一种数据压缩存储方法、装置，及分布式文件系统 Download PDFInfo
- Publication number
- CN106170968B CN106170968B CN201480037404.6A CN201480037404A CN106170968B CN 106170968 B CN106170968 B CN 106170968B CN 201480037404 A CN201480037404 A CN 201480037404A CN 106170968 B CN106170968 B CN 106170968B
- Authority
- CN
- China
- Prior art keywords
- node
- data
- file
- data compression
- data block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000013144 data compression Methods 0.000 title claims abstract description 456
- 238000000034 method Methods 0.000 title claims abstract description 82
- 238000003860 storage Methods 0.000 title claims abstract description 48
- 238000007906 compression Methods 0.000 claims abstract description 102
- 230000006835 compression Effects 0.000 claims abstract description 102
- 230000005540 biological transmission Effects 0.000 claims abstract description 50
- 230000008569 process Effects 0.000 claims abstract description 30
- 238000013500 data storage Methods 0.000 claims abstract description 13
- 238000006062 fragmentation reaction Methods 0.000 claims description 176
- 238000013467 fragmentation Methods 0.000 claims description 167
- 238000012545 processing Methods 0.000 claims description 39
- 239000012634 fragment Substances 0.000 claims description 21
- 238000011084 recovery Methods 0.000 claims description 17
- 239000012141 concentrate Substances 0.000 claims description 7
- 230000008878 coupling Effects 0.000 claims description 6
- 238000010168 coupling process Methods 0.000 claims description 6
- 238000005859 coupling reaction Methods 0.000 claims description 6
- 230000006870 function Effects 0.000 description 21
- 239000011232 storage material Substances 0.000 description 13
- 238000010586 diagram Methods 0.000 description 11
- 238000007726 management method Methods 0.000 description 11
- 238000004422 calculation algorithm Methods 0.000 description 7
- 238000005520 cutting process Methods 0.000 description 6
- 230000011218 segmentation Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 238000009826 distribution Methods 0.000 description 3
- 238000002360 preparation method Methods 0.000 description 3
- 238000012163 sequencing technique Methods 0.000 description 3
- 241000208340 Araliaceae Species 0.000 description 1
- 241001269238 Data Species 0.000 description 1
- 235000005035 Panax pseudoginseng ssp. pseudoginseng Nutrition 0.000 description 1
- 235000003140 Panax quinquefolius Nutrition 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008602 contraction Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000004744 fabric Substances 0.000 description 1
- 235000008434 ginseng Nutrition 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Abstract
一种数据压缩存储方法、装置，及分布式文件系统，所述分布式文件系统包括客户端节点、名称节点以及数据节点，所述方法的实现包括：名称节点在接收到客户端节点发送的文件创建请求后，确定数据压缩节点集，所述数据压缩节点集包含至少两个数据压缩节点，所述数据压缩节点为具有数据压缩处理资源的数据节点；所述名称节点将所述数据压缩节点集发送给客户端节点；所述名称节点在接收到所述数据压缩节点集中的数据压缩节点发送的节点获取请求后，确定数据存储节点，所述数据存储节点为具有数据存储资源的数据节点；所述名称节点将确定的所述数据存储节点的信息发送给所述节点获取请求对应的数据压缩节点。用于提高数据压缩存储效率和速度。
Description
技术领域
本发明涉及存储技术领域，具体涉及一种数据压缩存储方法、装置，及分布式文件系统。
背景技术
在分布式文件系统(Distributed File System)中，文件系统管理的物理存储资源有的在本地节点上，有的在远程节点上。Hadoop分布式文件系统(Hadoop DistributedFile System，HDFS)是一种常用分布式文件系统，具备高度容错性，适合部署在廉价的机器上。另外，HDFS能实现高吞吐量的数据访问，因此较适合大规模数据的应用环境。
在HDFS中，至少包含如下三类功能节点：数据节点(DataNode，DN)、名称节点(NameNode，NN)，以及HDFS客户端节点(HDFS client)。以上三类功能节点可以任意组合以后部署在物理实体设备中。
其中，数据节点在HDFS文件系统中用于存储文件的具体内容。在HDFS系统中，一个待存储文件会被切分为多个数据块(通常默每块大小为64M或128M)，同一个数据块有需要有多个副本存储在不同的DN中，以提高数据存储的可靠性。
名称节点，被认为是HDFS文件系统的核心，用于存储分布式文件系统中所有文件的目录树结构及文件数据在在数据节点中的准确位置。名称节点并不保存具体的文件内容数据。
HDFS客户端节点是负责将待存储文件切分为多个数据块并按照名称节点的要求进行对数据块进行存储的设备。
在HDFS中，数据压缩存储的实现过程如下：
HDFS客户端节点，获取待存储文件，然后将待存储文件压缩得到压缩文件；HDFS客户端节点向名称节点发送文件创建请求，告知有文件需要存储；
上述名称节点接收到文件创建请求后，将如何分割压缩文件的参数信息发送给HDFS客户端节点；
HDFS客户端节点按照上述参数信息的指示，将上述待存储文件压缩并分割为若干个数据块(Block)，然后从名称节点获取各数据块的副本将要存放的数据节点；最后将分割得到的Block存储到数据节点。
若采用以上数据压缩存储方案，一方面，HDFS客户端节点对待存储文件进行压缩，压缩速度较慢。另一方面，保存过程在一个数据块及其副本保存成功后才能保存下一个数据块，文件保存速度较慢。
发明内容
本发明实施例提供一种数据压缩存储方法、装置，及分布式文件系统，用于提高分布式系统的数据压缩存储效率，提高分布式系统的速度。
本发明实施例一方面提供了一种数据压缩存储方法，应用于分布式文件系统，所述分布式文件系统包括客户端节点、名称节点以及数据节点，包括：
名称节点在接收到客户端节点发送的文件创建请求后，确定数据压缩节点集，所述数据压缩节点集包含至少两个数据压缩节点，所述数据压缩节点为具有数据压缩处理资源的数据节点；
所述名称节点将所述数据压缩节点集发送给客户端节点；
所述名称节点在接收到所述数据压缩节点集中的数据压缩节点发送的节点获取请求后，确定数据存储节点，所述数据存储节点为具有数据存储资源的数据节点；
所述名称节点将确定的所述数据存储节点的信息发送给所述节点获取请求对应的数据压缩节点。
结合一方面的实现方式，在第一种可能的实现方式中，所述确定数据压缩节点集包括：
选取当前可用的压缩处理资源达到预定标准的至少两个数据压缩节点；将选取的所述至少两个数据压缩节点的集合作为所述数据压缩节点集。
结合一方面或者一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述名称节点在接收到所述数据压缩节点发送的节点获取请求后，确定数据存储节点，包括：
所述名称节点接收到所述节点获取请求后，确定所述数据压缩节点是否属于所述数据压缩节点集，若是，则确定数据存储节点。
结合一方面的第二种实现方式，在第三种可能的实现方式中，在确定数据压缩节点集之后，所述方法还包括：所述名称节点记录所述数据压缩节点集和对应于所述数据压缩节点集的待存储文件的信息；
所述节点获取请求中携带所述数据块所属待存储文件的信息，以及所述数据压缩节点的标识；
所述确定所述数据压缩节点是否属于所述数据压缩节点集包括：
所述名称节点依据所述数据块所属待存储文件的信息确定对应的数据压缩节点集，并判断发送所述节点获取请求的数据压缩节点是否属于确定的所述数据压缩节点集。
结合一方面的实现方式，在第四种可能的实现方式中，在接收到客户端节点发送的文件创建请求后，所述方法还包括：记录所述文件创建请求指定需要保存的待存储文件的文件名；
在确定数据存储节点之后，所述方法还包括：
记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号。
结合一方面的第四种可能的实现方式，在第五种可能的实现方式中，在记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识之后，所述方法还包括：
在恢复所述待存储文件过程中，依据所述数据块号确定所述数据块所属的待存储文件，依据所述数据块号中所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号确定所述数据块在所述待存储文件中的顺序。
结合一方面的实现方式，在第六种可能的实现方式中，在接收到客户端节点发送的文件创建请求后，所述方法还包括：记录所述文件创建请求指定需要保存的待存储文件的文件名；
在确定数据存储节点之后，所述方法还包括：
若所述待存储文件的文件分片的个数与所述数据压缩节点集中的数据压缩节个数相同，并且文件分片被按照数据压缩节点的序号的顺序分发给数据压缩节点，则记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号。
结合一方面的第六种可能的实现方式，在第七种可能的实现方式中，在记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识之后，所述方法还包括：
在恢复所述待存储文件过程中，依据所述数据块号确定所述数据块所属的待存储文件，依据所述数据块号中的所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号确定所述数据块在所述待存储文件中的顺序。
本发明实施例二方面提供了一种分布式文件系统，包括：客户端节点、名称节点以及数据节点，其特征在于，
客户端节点获取待存储文件，向名称节点发送文件创建请求；
名称节点在接收到所述客户端节点发送的文件创建请求后，确定数据压缩节点集，所述数据压缩节点集包含至少两个数据压缩节点，所述数据压缩节点为具有数据压缩处理资源的数据节点；所述名称节点将所述数据压缩节点集发送给所述客户端节点；
所述客户端节点接收所述名称节点根据所述文件创建请求返回的数据压缩节点集，分割所述待存储文件得到至少两个文件分片，然后将各文件分片发送给所述数据压缩节点集中的数据压缩节点；
数据压缩节点在接收到所述客户端节点发送的文件分片后，压缩接收到的所述文件分片，并分割得到数据块；所述数据压缩节点向所述名称节点发送节点获取请求；
所述名称节点在接收到所述数据压缩节点集中的数据压缩节点发送的节点获取请求后，确定数据存储节点，所述数据存储节点为具有数据存储资源的数据节点；所述名称节点将确定的所述数据存储节点的信息发送给所述节点获取请求对应的数据压缩节点；
所述数据压缩节点接收所述名称节点发送的数据存储节点的信息；所述数据压缩节点将所述数据块发送给所述数据存储节点存储。
结合二方面的实现方式，在第一种可能的实现方式中，所述确定数据压缩节点集包括：
所述名称节点选取当前可用的压缩处理资源达到预定标准的至少两个数据压缩节点；将选取的所述至少两个数据压缩节点的集合作为所述数据压缩节点集。
结合一方面的实现方式，在第二种可能的实现方式中，所述名称节点在接收到所述数据压缩节点发送的节点获取请求后，确定数据存储节点，包括：
所述名称节点接收到所述节点获取请求后，确定所述数据压缩节点是否属于所述数据压缩节点集，若是，则确定数据存储节点。
结合二方面的第二种可能的实现方式，在第三种可能的实现方式中，在所述名称节点确定数据压缩节点集之后，所述系统还包括：
所述名称节点记录所述数据压缩节点集和对应于所述数据压缩节点集的待存储文件的信息；
所述名称节点获取请求中携带所述数据块所属待存储文件的信息，以及所述数据压缩节点的标识；所述确定所述数据压缩节点是否属于所述数据压缩节点集包括：
所述名称节点依据所述数据块所属待存储文件的信息确定对应的数据压缩节点集，并判断发送所述节点获取请求的数据压缩节点是否属于确定的所述数据压缩节点集。
结合一方面的实现方式，在第四种可能的实现方式中，所述系统还包括：
所述名称节点在接收到客户端节点发送的文件创建请求后，记录所述文件创建请求指定需要保存的待存储文件的文件名；
所述名称节点在确定数据存储节点之后，记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号。
结合一方面的第四种可能的实现方式，在第五种可能的实现方式中，所述系统还包括：
所述名称节点在恢复所述待存储文件过程中，依据所述数据块号确定所述数据块所属的待存储文件，依据所述数据块号中所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号确定所述数据块在所述待存储文件中的顺序。
结合一方面的实现方式，在第六种可能的实现方式中，所述系统还包括：
所述名称节点在接收到客户端节点发送的文件创建请求后，记录所述文件创建请求指定需要保存的待存储文件的文件名；
所述客户端节点分割所述待存储文件得到的文件分片个数与所述数据压缩节点集中的数据压缩节个数相同，所述客户端节点将得到的文件分片被按照数据压缩节点的序号的顺序分发给数据压缩节点；
所述名称节点在确定数据存储节点之后，记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号。
结合一方面的第六种可能的实现方式，在第七种可能的实现方式中，所述系统还包括：
所述名称节点在恢复所述待存储文件过程中，依据所述数据块号确定所述数据块所属的待存储文件，依据所述数据块号中的所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号确定所述数据块在所述待存储文件中的顺序。
结合一方面的实现方式，在第八种可能的实现方式中，所述客户端节点分割所述待存储文件得到至少两个文件分片包括：将所述待存储文件分割为与各数据压缩节点当前可用的压缩处理资源的多少对应大小的文件分片；所述文件分片的个数等于所述数据压缩节点集中数据压缩节点的个数；
所述客户端节点将各文件分片发送给所述数据压缩节点集中的数据压缩节点包括：将较大的文件分片发送给所述数据压缩节点集中当前可用的压缩处理资源较多的数据压缩节点，将较小的文件分片发送给所述数据压缩节点集中当前可用的压缩处理资源较少的数据压缩节点。
结合一方面的第八种实现方式，在第九种可能的实现方式中，所述文件分片的数量大于或等于所述数据压缩节点集中的数据压缩节点的个数；
所述客户端节点将各文件分片发送给所述数据压缩节点集中的数据压缩节点包括：所述客户端节点将文件分片逐个发送给当前具有空闲的数据压缩处理资源的数据压缩节点。
结合一方面的实现方式，在第十种可能的实现方式中，所述系统还包括：
所述数据压缩节在压缩所述文件分片之前与其他数据压缩节点协商数据压缩规则；
所述数据压缩节将所述文件分片压缩为压缩文件包括：所述数据压缩节按照协商得到的所述数据压缩规则压缩所述文件分片。
结合一方面、一方面的第一种、第二种、第三种、第四种、第五种、第六种、第七种、第八种、第九种或者第十种可能的实现方式，在第十一种可能的实现方式中，所述系统还包括：
所述数据压缩节点在将所述数据块发送给所述数据存储节点存储之前，生成文件压缩头，在所述文件压缩头中携带所述数据压缩规则的指示信息，依据当前使用的数据压缩规则确定是否将所述文件压缩头并入所述数据块，若是则将所述文件压缩头并入所述数据块。
本发明实施例三方面还提供了一种名称节点，应用于分布式文件系统，所述分布式文件系统包括客户端节点、所述名称节点以及数据节点，所述名称节点包括：
第一接收单元，用于接收客户端节点发送的文件创建请求；
第一确定单元，用于在所述第一接收单元接收到客户端节点发送的文件创建请求后，确定数据压缩节点集，所述数据压缩节点集包含至少两个数据压缩节点，所述数据压缩节点为具有数据压缩处理资源的数据节点；
第一发送单元，用于将所述第一确定单元确定的所述数据压缩节点集发送给客户端节点；
第二接收单元，用于接收到所述数据压缩节点集中的数据压缩节点发送的节点获取请求；
第二确定单元，用于在所述第二接收单元接收到所述数据压缩节点集中的数据压缩节点发送的节点获取请求后，确定数据存储节点，所述数据存储节点为具有数据存储资源的数据节点；
第二发送单元，用于将所述第二确定单元确定的所述数据存储节点的信息发送给所述节点获取请求对应的数据压缩节点。
结合三方面的实现方式，在第一种可能的实现方式中，所述第一确定单元，用于选取当前可用的压缩处理资源达到预定标准的至少两个数据压缩节点；将选取的所述至少两个数据压缩节点的集合作为所述数据压缩节点集。
结合三方面或者一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述第二确定单元，具体用于在所述第一接收单元接收到所述节点获取请求后，确定所述数据压缩节点是否属于所述数据压缩节点集，若是，则确定数据存储节点。
结合三方面的第二种实现方式，在第三种可能的实现方式中，所述名称节点还包括：
第一记录单元，用于在所述第一确定单元确定数据压缩节点集之后，记录所述数据压缩节点集和对应于所述数据压缩节点集的待存储文件的信息；
所述节点获取请求中携带所述数据块所属待存储文件的信息，以及所述数据压缩节点的标识；
所述第二确定单元，具体用于依据所述数据块所属待存储文件的信息确定对应的数据压缩节点集，并判断发送所述节点获取请求的数据压缩节点是否属于确定的所述数据压缩节点集。
结合三方面的实现方式，在第四种可能的实现方式中，所述名称节点还包括：
第二记录单元，用于在所述第一确定单元接收到客户端节点发送的文件创建请求后，记录所述文件创建请求指定需要保存的待存储文件的文件名；
所述第二记录单元，还用于在所述第二确定单元确定数据存储节点之后，记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号。
结合三方面的第四种可能的实现方式，在第五种可能的实现方式中，所述名称节点还包括：
第一恢复单元，用于在恢复所述待存储文件过程中，依据所述第二记录单元记录的数据块号确定所述数据块所属的待存储文件，依据所述数据块号中所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号确定所述数据块在所述待存储文件中的顺序。
结合三方面的实现方式，在第六种可能的实现方式中，所述名称节点还包括：
第三记录单元，用于在所述第一确定单元接收到客户端节点发送的文件创建请求后，记录所述文件创建请求指定需要保存的待存储文件的文件名；
所述第三记录单元，还用于在确定数据存储节点之后，若所述待存储文件的文件分片的个数与所述数据压缩节点集中的数据压缩节个数相同，并且文件分片被按照数据压缩节点的序号的顺序分发给数据压缩节点，则记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号。
结合三方面的第六种可能的实现方式，在第七种可能的实现方式中，所述名称节点还包括：
第二恢复单元，用于在恢复所述待存储文件过程中，依据所述第三记录单元记录的数据块号确定所述数据块所属的待存储文件，依据所述数据块号中的所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号确定所述数据块在所述待存储文件中的顺序。
在本发明实施例中，名称节点确定的数据压缩节点集中包含了至少两个数据压缩节点，数据压缩节点集中的数据压缩节点参与了待存储文件的压缩。由于数据压缩节点是数据节点，名称节点管理节点的功能修改较小；更重要的是，各个数据压缩节点的数据压缩和存储过程是并行的。因此，采用本发明实施例待存储文件的压缩和存储不再仅限于客户端节点的处理能力，因此可以提高分布式系统的数据压缩存储效率，提高分布式系统的速度。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施方法流程示意图；
图2是本发明实施例结合系统的方法流程示意图；
图3为本发明实施例结合系统的方法流程示意图；
图4为本发明实施例名称节点结构示意图；
图5为本发明实施例名称节点结构示意图；
图6为本发明实施例名称节点结构示意图；
图7为本发明实施例名称节点结构示意图；
图8为本发明实施例名称节点结构示意图；
图9为本发明实施例名称节点结构示意图；
图10为本发明实施例名称节点结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例提供一种数据压缩存储方法，应用于分布式文件系统，上述分布式文件系统包括客户端节点、名称节点以及数据节点，如图1所示，包括：
在本实施例中，分布式文件系统可以是任意的分布式文件系统，特别地可以应用于HDFS。
101：名称节点在接收到客户端节点发送的文件创建请求后，确定数据压缩节点集，上述数据压缩节点集包含至少两个数据压缩节点，上述数据压缩节点为具有数据压缩处理资源的数据节点；
名称节点具有管理数据压缩节点以及数据存储节点的功能，名称节点需要确定可以作为某次数据压缩存储过程中的数据压缩节点，本实施例还提供了如何确定数据压缩节点的策略，具体如下：上述确定数据压缩节点集包括：选取当前可用的压缩处理资源达到预定标准的至少两个数据压缩节点；将选取的上述至少两个数据压缩节点的集合作为上述数据压缩节点集。
在本实施例中，采用所有数据压缩节点当前可用的压缩处理资源为标准进行选择；可用的压缩处理资源可以包含数据压缩的最直接资源，如：空闲的压缩计算资源，还可以包括配合压缩处理的必要资源，如：传输压缩数据的资源。因此压缩处理资源应当理解为较为广泛的压缩处理资源，不应简单理解为只能包含计算资源。
102：上述名称节点将上述数据压缩节点集发送给客户端节点；
103：上述名称节点在接收到上述数据压缩节点集中的数据压缩节点发送的节点获取请求后，确定数据存储节点，上述数据存储节点为具有数据存储资源的数据节点；
在本实施例中，名称节点管理数据压缩存储的过程，因此还可以加入鉴权的方案来保证客户端节点能够按照名称节点确定的压缩节点集分配文件分片，具体如下：上述名称节点在接收到上述数据压缩节点发送的节点获取请求后，确定数据存储节点，包括：
上述名称节点接收到上述节点获取请求后，确定上述数据压缩节点是否属于上述数据压缩节点集，若是，则确定数据存储节点。
基于本实施例中的名称节点在确定数据压缩节点集之后，上述方法还包括：上述名称节点记录上述数据压缩节点集和对应于上述数据压缩节点集的待存储文件的信息；
上述节点获取请求中携带上述数据块所属待存储文件的信息，以及上述数据压缩节点的标识；上述确定上述数据压缩节点是否属于上述数据压缩节点集包括：上述名称节点依据上述数据块所属待存储文件的信息确定对应的数据压缩节点集，并判断发送上述节点获取请求的数据压缩节点是否属于确定的上述数据压缩节点集。
104：上述名称节点将确定的上述数据存储节点的信息发送给上述节点获取请求对应的数据压缩节点。
在本实施例中，名称节点确定的数据压缩节点集中包含了至少两个数据压缩节点，数据压缩节点集中的数据压缩节点参与了待存储文件的压缩。由于数据压缩节点是数据节点，名称节点管理节点的功能修改较小；更重要的是，各个数据压缩节点的数据压缩和存储过程是并行的。因此，采用本发明实施例待存储文件的压缩和存储不再仅限于客户端节点的处理能力，因此可以提高分布式系统的数据压缩存储效率，提高分布式系统的速度。
本实施例可以实现数据压错存储，基于数据压缩存储的流程，本实施例还提供了用户在后续有数据恢复需求的情况下如何进行数据恢复的数据准备，在名称节点一侧需要记录一些数据，具体如下：在接收到客户端节点发送的文件创建请求后，上述方法还包括：记录上述文件创建请求指定需要保存的待存储文件的文件名；
在确定数据存储节点之后，上述方法还包括：记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识，上述数据块号包含上述数据块在其所在的文件分片中的序号以及上述数据块所属的文件分片的序号。
在本实施例中，文件分片的序号是待存储文件被切分为文件分片后，按照文件分片在待存储文件中的顺序依次编号的序号；数据块由于是文件分片压缩得到的，因此数据块与文件分片有所属关系，文件分片压缩会得到很多数据块，数据块在其所在的文件分片中的序号也是顺序编号得到的序号。
基于本实施例记录的数据，本实施例还提供了进行数据恢复的方案，如下：在记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识之后，上述方法还包括：
在恢复上述待存储文件过程中，依据上述数据块号确定上述数据块所属的待存储文件，依据上述数据块号中上述数据块在其所在的文件分片中的序号以及上述数据块所属的文件分片的序号确定上述数据块在上述待存储文件中的顺序。
以上实施例通过记录数据块在所在的文件分片中的序号以及数据块所属的文件分片的序号，该记录方案可以应用在所有场景下。对于特定的场景，可以改变记录的数据的具体内容，本实施例还提供了如下方案：在接收到客户端节点发送的文件创建请求后，上述方法还包括：记录上述文件创建请求指定需要保存的待存储文件的文件名；
在确定数据存储节点之后，上述方法还包括：若上述待存储文件的文件分片的个数与上述数据压缩节点集中的数据压缩节个数相同，并且文件分片被按照数据压缩节点的序号的顺序分发给数据压缩节点，则记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识，上述数据块号包含上述数据块在其所在的文件分片中的序号以及上述数据压缩节点的序号。
基于以上实施例记录的具体数据内容(数据块号包含上述数据块在其所在的文件分片中的序号以及上述数据压缩节点的序号)，本发明实施例还提供了数据恢复过程中的处理方案，具体如下：在记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识之后，上述方法还包括：
在恢复上述待存储文件过程中，依据上述数据块号确定上述数据块所属的待存储文件，依据上述数据块号中的上述数据块在其所在的文件分片中的序号以及上述数据压缩节点的序号确定上述数据块在上述待存储文件中的顺序。
基于以上实施例对于客户端节点、名称节点以及数据压缩的分别介绍，本实施例还提供了综合的实施实例进行详细说明如下，请参阅图2所示，包括如下步骤：
201：客户端节点在获取到待存储文件后，向名称节点发送文件创建请求；
在本步骤中，待存储文件是需要存储的数据，数据量通常较大，因此需要压缩存储。待存储文件可以是客户端本地的文件，也可以是来源于其他设备的文件，本实施例对此不作限制。
202：名称节点在接收到客户端节点发送的上述文件创建请求后，确定数据压缩节点集，上述数据压缩节点集包含至少两个数据压缩节点，上述数据压缩节点为具有数据压缩处理资源的数据节点；上述名称节点将上述数据压缩节点集发送给上述客户端节点；
在名称节点确定数据压缩节点集以后，可以记录数据压缩节点集。记录时可以采用数据压缩节点表的形式记录，并采用数据压缩节点标识作为表项，例如，表1所示：
表1
| 数据压缩节点序号 | 数据压缩节点序号标识 |
| 1 | DN1 |
| 2 | DN5 |
| ... | ... |
| N | DNn |
在本实施例中，数据压缩节点和数据存储节点均是采用功能划分的节点，处于对名称节点的管理需要来看，将数据压缩节点和数据存储节点的功能放在数据节点实现较为合适。
另需说明的是名称节点确定数据压缩节点集所采用的策略，可以按照实际需要进行设定，以下给出了具体举例：
在确定上述数据压缩节点集之前，上述名称节点获取上述名称节点管理的各数据压缩节点当前可用的压缩处理资源；选取当前可用的压缩处理资源达到预定标准的至少两个数据压缩节点；选取的上述至少两个数据压缩节点作为上述数据压缩节点集的元素。
在本实施例中，可用的压缩处理资源的信息可以按需要设定，因此预定标准也可以对应设定标准，以下给出了几个举例：
假定1：当前具有的空闲压缩计算能力，那么预定标准可以是空闲压缩计算能力超过预定阈值；
假定2：综合当前空闲压缩计算能力以及当前数据传输能力(考虑即使压缩计算能力空闲较多，数据传输能力较弱，那么综合的存储能力仍然会较低)，那么预定标准可以是：空闲压缩计算能力超过预定阈值并且数据传输能力也超过另一预定阈值。
以上假定仅作为举例不应理解为对本实施例穷举，以上采用压缩处理资源的标准可以确定哪些是符合作为数据压缩处理节点要求的节点，本实施例还给出了如何确定数据压缩节点数量，以及在数量确定后如何选取符合要求的数据压缩节点作为最终执行数据压缩的节点的方案，如下：
节点集中的数据压缩节点的数量可以由多种确定方法。如：根据原始数据量及数据分块预设大小确定，假定有10G原始数据作为待存储文件，预设的数据分片大小为2G，则需要有10/2＝5个数据压缩节点。
数据压缩节点选取也有多种实现方法。如：优先选取和客户端节点在同一个机架上的数据压缩节点，同一个机架的数据压缩节点数目不足，则选择相邻机架的数据压缩节点，如果仍然不足，可以选择其他机架上同一个数据中心的数据压缩节点，直到选择到所需的节点数目。
可选的数据压缩节点较多时，可以依据负载均衡的需求来指导如何选择数据压缩节点，以上举例不应理解为本发明实施例可选方案的穷举。
203：上述客户端节点分割上述待存储文件得到至少两个文件分片，然后将各文件分片发送给上述数据压缩节点集中的数据压缩节点；
客户端节点分割待存储文件的策略可以按照需求进行设定，本实施例给出了如下几种作为举例：
1、按照数据压缩节点集的元素数量，将待存储文件等分为和上述元素数量相等的数量的文件分片。
采用等分的方式控制过程最为简便。
2、按照各数据压缩节点的资源多少来确定文件分片的数据量大小，具体如下：
在分割上述待存储文件之前，获取上述数据压缩节点集中的数据压缩节点当前可用的压缩处理资源。在本实施例中，各数据压缩节点当前可用的压缩处理资源可以是客户端节点自己统计的，也可以是由名称节点统计后告知的。
然后执行分割：将上述待存储文件分割为与上述各数据压缩节点当前可用的压缩处理资源的多少对应大小的文件分片；上述文件分片的个数等于上述数据压缩节点集中数据压缩节点的个数。
最后执行与分割策略对应的发送策略：将较大的文件分片发送给上述数据压缩节点集中当前可用的压缩处理资源较多的数据压缩节点，将较小的文件分片发送给上述数据压缩节点集中当前可用的压缩处理资源较少的数据压缩节点。
采用按照资源多少来确定文件分片的数据量大小，可以实现按需分片发挥各数据压缩节点的数据压缩性能。
3、等分待存储文件，分割得到的文件分片的数量大于数据压缩节点集的元素数量，那么对应的发送策略可以如下：将文件分片逐个发送给当前具有空闲的数据压缩处理资源的节点。
采用本方案，分割策略控制较为简便，仍然可以发挥各数据压缩节点的数据压缩性能。
204：数据压缩节点在接收到客户端节点发送的文件分片后，压缩上述文件分片，并分割得到数据块；上述数据压缩节点使用的数据压缩规则与上述其他数据压缩节点使用的数据压缩规则相同；数据压缩节点向名称节点发送节点获取请求；
由于数据压缩节点集中有至少两个数据压缩节点，因此上述文件分片为分割待存储文件得到的文件的分片之一，上述文件分片之外的其他文件分片被发送给了其它数据压缩节点。
本实施例中，数据块是存储节点存储数据的单元，通常来说可以是固定大小的数据块。上述数据存储节点为具有数据存储资源的节点。
在本实施例中，各数据压缩节点使用的压缩规则是相同的，压缩规则是如何保持相同的方式可以按需确定，例如：采用固定的压缩规则就可以，本实施例还提供了更为灵活的压缩规则确定方式，如下：
在压缩上述文件分片之前，上述方法还包括：上述数据压缩节点与上述其他数据压缩节点协商数据压缩规则；
上述将上述文件分片压缩为压缩文件包括：按照协商得到的上述数据压缩规则压缩上述文件分片。
具体协商得到何种数据压缩规则，可以参考各种数据压缩算法本实施例对此不作限制。
由于数据压缩节点之间需要协商数据压缩规则，因此相互之间有通信需求，通信过程可以由客户端节点或者名称节点协助完成，本实施例还提供了较为优选的实现方式如下：
上述数据压缩节点与上述其他数据压缩节点，通过采用远程直接存储器存取(Remote Direct Memory Access，RDMA)建立的连接协商数据压缩规则，或者，通过采用用户数据报协议(User Datagram Protocol，UDP)建立的通信连接协商数据压缩规则。
另外，由于参与数据压缩的数据压缩节点至少有两个，那么为了保持数据块保存以后能够和使用一个节点进行压缩时一致，减少对整个系统架构的修改，本发明实施例可以在数据块被存储之前进行如下操作：
上述数据压缩节点生成文件压缩头，在上述文件压缩头中携带上述数据压缩规则的指示信息，依据当前使用的数据压缩规则确定是否将上述文件压缩头并入上述数据块，若是则将上述文件压缩头并入上述数据块。
文件压缩头携带的信息、文件压缩头的具体位置以及文件压缩头的数量需求等都是和采用的具体数据压缩算法相关的，本实施例对文件压缩头的具体形式不作限制。
另外，在本实施例中，数据压缩节点压缩数据可以采用软压缩的方式进行，也可以使用硬压缩的方式进行。为了提高压缩数据的效率，减少对集成数据压缩节点的影响，可以优选采用如下方案：采用数据存储节点的硬件的压缩卡压缩上述文件分片。
205：名称节点在接收到上述数据压缩节点发送的节点获取请求后，确定数据存储节点；
在本实施例中，如果在确定数据压缩节点以后记录了数据压缩节点集，那么在确定数据存储节点之前，还可以对节点获取请求的发送者进行认证，具体如下：
上述名称节点接收到上述数据压缩节点发送的请求存储数据块的节点获取请求后，确定上述数据压缩节点是否属于上述数据压缩节点集，若是确定数据存储节点。
由于原始的待存储文件被分割成了至少两个文件分片，另外节点获取请求的用途是确定数据块存储的节点，因此数据压缩节点会传递改数据块的信息，例如：该数据块的其压缩的在文件分片中的序号。名称节点虽然在确定数据存储节点时可以不考虑文件分片造成的影响，不过为了后续管理数据块的需要，本发明实施例还提供了如何记录文件数据的准确位置的具体实现方案：
在接收到客户端节点发送的文件创建请求后，上述方法还包括：记录上述文件创建请求指定需要保存的待存储文件的文件名；
在确定数据存储节点之后，上述方法还包括：记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识，上述数据块号包含上述数据块在其所在的文件分片中的序号以及上述数据块所属的文件分片的序号。
作为一个举例：假定原始的待存储文件为1G，被分成10个文件分片，文件分片的序号是1～10，数据压缩节点对每个文件分片进行压缩的过程中会独立按序编号；NN节点记录的是：第一个文件分片的第一个数据块可以是：1-001，第二个文件分片的第三个数据块可以是：2-003，第三个文件分片的第一个数据块为3-001，以此类推。可以通过上述数据块号确定数据块在原始的待存储文件中的顺序。
本实施例还提供了待存储文件的恢复方案如下：在恢复上述待存储文件过程中，依据上述数据块号确定上述数据块所属的待存储文件，依据上述数据块号中上述数据块在其所在的文件分片中的序号以及上述数据块所属的文件分片的序号确定上述数据块在上述待存储文件中的顺序。
本实施例给给出了一个特定的应用场景的记录文件数据准确位置的方案，该特定应用场景如下：上述待存储文件的文件分片的个数与上述数据压缩节点集中的数据压缩节个数相同，并且文件分片被按照数据压缩节点的序号的顺序分发给数据压缩节点。那么可以如下：
在接收到客户端节点发送的文件创建请求后，上述方法还包括：记录上述文件创建请求指定需要保存的待存储文件的文件名；
在确定数据存储节点之后，上述方法还包括：记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识，上述数据块号包含上述数据块在其所在的文件分片中的序号以及上述数据压缩节点的序号。
以下给出了一种上述特定应用场景下的记录方案，假定：名称节点记录有参与压缩的数据压缩节点列表，假设为DN1，DN2...DNn，第一个文件分片由DN1处理，第二个文件分片由DN2处理，第三个文件分片由DN3处理。那么，数据压缩节点在得到数据块，分配编号时，可以在数据块的序号前添加前缀，如DN1提交的第一块数据，编号为1-001，第二块数据为1-002，DN2提交的第一块数据编号为2-001，以此类推。这样可以通过前缀以及可以确定各数据压缩节点得到的数据块的先后顺序，例如：2-001一定在1-100之后。客户端读取原始文件时，服务端可以根据名称节点保存的数据块号的先后顺序依次返回数据块即可，数据块号是否连续并不重要，只要能通过数据块号区分出先后顺序即可。为了确定数据块号对应的数据块的存储的位置，因此可以记录存储数据块的数据存储节点的标识。这样就可以找到数据块了。
本实施例还提供了以上特定应用场景下待存储文件的恢复方案如下：
在恢复上述待存储文件过程中，依据上述数据块号确定上述数据块所属的待存储文件，依据上述数据块号中的上述数据块在其所在的文件分片中的序号以及上述数据压缩节点的序号确定上述数据块在上述待存储文件中的顺序。
206：上述数据压缩节点接收上述名称节点发送的数据存储节点；上述数据压缩节点将上述数据块发送给上述数据存储节点存储。
本发明实施例还提供了另一实施例的举例，本实施例将结合名称节点、客户端、数据存储节点以及数据压缩节点的系统结构，将数据压缩节点的功能集成在数据存储节点，压缩数据的功能采用集成在数据节点上的压缩卡实现，作为本发明实施例的一个优选实施例进行举例说明。在本实施例中，数据压缩节点和数据存储节点的功能均位于数据节点(Date Node，ND)。
另需说明的是，本实施例使用高速压缩模块的高速压缩能力实现多个数据节点的并行压缩和并行存储机制，从而提供HDFS系统中文件高速压缩和存储的能力。上述高速压缩模块可以是硬件压缩卡等硬件设备，也可以是软件模块。硬件压缩卡是使用硬件逻辑实现某种压缩算法，对数据进行压缩并输出压缩数据的硬件设备，硬件压缩卡的运行不需要消耗主机的CPU资源。软件压缩模块可以利用自研软件或者普通软件的数据压缩能力实现。
请参阅图5所示，在图5中，参与数据压缩的节点为DN1和DN2，DN3～DN5是用于保存数据块副本的DN。在客户端节点(Cllent Node，CN)运行有HDFS客户端(HDFS cllent)，椭圆形区域是库函数的示意不属于硬件架构。图3所示箭头方向为数据或消息的流向，具体如下：
301：Client Node调用DistributedFileSystem向NN发送文件创建请求消息，用于告知NN有待存储文件需要存储，并请求NN返回可以压缩待存储文件的DN的信息。
上述DistributedFileSystem是HDFS系统开发类库中的功能函数，用于请求NN创建文件。另外，DistributedFileSystem会返回一个FSDataOutputStream对象，这个对象负责NN和DN之间的通信。FSDataOutputStream对象是库函数，如果DN和CN均具有包含该库函数的函数库，那么至少有如下两种方式实现DN与NN之间的通信：1、CN通过FSDataOutputStream告知DN的FSDataOutputStream运行FSDataOutputStream所使用的参数；2、DN自身调用FSDataOutputStream，与NN进行通信获得运行FSDataOutputStream所使用的参数。另一种是，DN没有包含以上库函数的函数库，那么CN可以先将上述函数库发送给DN，之后的实现再参考以上两种方式。其中DN和CN具有上述库函数，由CN告知DN运行FSDataOutputStream所使用的参数的方式可以作为一个优选实现方式。
文件创建请求的上述两个功能的信息可以分开发送，也可以单独发送。在文件创建请求中，可以携带用于NN确定DN的各种信息，还可以携带其他信息，例如：
可用的硬件压缩卡(或者DN)，HDFS存储时机架感知位置脚本的路径等配置信息。机架感知位置脚本用于确定DN的硬件压缩卡的在机架的分布信息，CPU和内存占用率等。
另外，本实施例还可以兼容集中压缩的方式，HDFS客户端可以在文件创建请求中指定压缩方式，具体方案如下：在文件创建请求消息中携带压缩标识：0-采用集中压缩，1-采用并行压缩。如果压缩标识为0那么HDFS独立完成数据压缩存储，NN不用返回DN的信息。
302：NN收到文件创建请求消息后，创建待存储文件的信息，选择DN并返回给Client Node。
在本步骤中，创建的待存储文件的信息包括：待存储文件的保存路径，文件创建时间戳。还可以保存返的所有DN的信息。
保存路径如：hdfs：//namenode：9000/user/hadoop/study/helloworld.dat；用于表示上述待存储文件的信息保存的位置。
在本步骤中，创建的待存储文件的信息后可以保存其文件名，以及对应该文件名的DN。
在本步骤中NN需要根据DN状态综合评估，选择合适的DN返回给Client Node。返回给Client Node的消息中需要携带能够让Client Node找到DN的必要信息，例如：DN的主机名、互联网协议(Internet Protocol，IP)地址或者端口号等。
NN选择DN方案可以如下：NN中维护所有DN的状态信息，在选择DN时，可以根据预定的选择规则灵活实现，例如：首先查询已经配置有硬件压缩卡的DN，然后查找距离HDFS客户端最近的DN(如在同一个机架上，同一个子网段中等)，然后根据DN的负载信息，选择负载较轻的DN(如CPU，内存占用量较小)。另外，还可以将待存储文件的大小作为考虑因素来确定需要的DN数量。图5中，假定选择的DN为DN1和DN2。
303：HDFS客户端接收到NN返回的DN后，从客户端节点读出待存储文件，将上述待存储文件切分得到文件分片。
在本步骤中，文件分片的数量与DN数目相同，在发送文件分片时每个DN一个文件分片，这样可以避免多次分配文件分片。
HDFS客户端切分待存储文件的策略可以如下：
策略一：根据NN返回的DN的数目均分。如：NN返回2个DN信息，Client Node则将原始的待存储文件均分成2等份。
策略二：查询NN返回的各DN的计算能力和负载，再根据计算能力和负载确定相应的大小的文件分片，然后根据确定大小的文件分片进行切分，然后发送给对应的DN。文件切分后的文件分片的数量仍旧与NN返回的DN的数目相等。
切分策略还可以有其他方式，本发明实施例不作唯一性限制。
304：HDFS客户端将文件分片发送给NN返回的DN。
由于本发明实施例采用DN之间协商压缩规则的方案，因此HDFS客户端还需要告知DN，参与压缩上述待存储文件的DN的信息，可以携带DN的IP地址、主机名等信息。
本步骤中文件分片可以是HDFS客户端主动发送的，也可以是告知DN以后由DN获取的，后一种方式：HDFS客户端需要告知DN文件分片的信息，例如：文件分片对应的的待存储文件保存的路径信息，由DN根据上述路径信息获取文件分片。Client Node在发送完文件分片以后，可以记录发送完毕的状态信息。
在以上步骤504执行完毕后，客户端节点在本流程中的功能就可以结束，后续流程由DN和NN完成。以下对应图5进行说明，DN1和DN2执行内容是相同的，以下实施例DN2进行详细说明，DN1可参考DN2的说明本实施例不再一一赘述。
305：DN2的压缩存储代理模块(Compress storage agent)会首先将文件分片接收并保存在DN2本地。
在本实施例中压缩代理模块负责和客户端节点通信，因此会收到参与压缩上述待存储文件的DN的信息。
306：DN2上的压缩存储代理模块通知硬件压缩卡，可以开始压缩。
在本步骤中，参与压缩上述待存储文件的DN的信息需要告知给硬件压缩卡。
307：DN2上的硬件压缩卡和DN1上的硬件压缩卡协商得到数据压缩规则。
数据压缩规则通常以压缩算法的形式体现，不同的压缩算法会有不同的文件压缩头和分布特点。因此本步骤可以确定文件压缩头以及文件压缩头的位置。以字典压缩为例，各个DN收到数据分片后，各自扫描各自的文件分片，按照一定的策略(如霍夫曼编码等)计算数据分片对应的字典。各个DN产生各自的字典后DN间互相通信，广播自己的负载和资源状况(如CPU负载，内存使用率，带宽占用率等)，选择负载最轻的DN作为汇总节点，各个DN将自己计算出的字典发送到汇总节点，汇总节点综合各个字典，整理出一个统一的字典，广播到各个DN，之后各个DN开始各自的压缩流程。
308：硬件压缩卡按照协商获得的压缩规则对本地的文件分片进行数据压缩并分割，得到数据块。
文件压缩头的位置是根据所用的压缩算法确定的，以字典压缩为例，文件压缩头位于原始的待存储文件压缩得到的第一个数据块中，因此在本实施例中，应该对应的第一块文件分片压缩产生的第一块数据块中。文件压缩头和第一块文件分片压缩产生的第一块数据块合并，置于第一个数据块前边。
另外，如果文件压缩头位于压缩文件尾部，则文件压缩头和最后一块文件分片压缩产生的最后一块数据块合并，置于最后一个数据块后边。其他合并方式按照不同的压缩算法确定，本实施例再一一说明。使用相同的字典压缩数据块保证了压缩后的压缩快的结构和单节点压缩相同。
HDFS系统通常会规定数据块(Block)的大小，即：数据压缩和存储的粒度，因此在本步骤中，硬件压缩卡得到的数据块的大小都是固定大小的。
309：DN2的压缩存储代理模块每检测到产生了一个新的Block大小的数据块，就通过调用FSDataOutputStream向NN发送请求保存该数据块的DN信息。NN向压缩存储代理模块返回用于存储上述数据块的DN列表。
在本步骤中，DN2可以向NN发送DN2的标识，以及新的Block所属的文件名；那么NN可以在收到请求以后，通过文件名确定用于鉴权的DN即：DN1和DN2，然后确定DN2的标识是DN2，属于用于鉴权的DN，因此可以确定鉴权通过，在鉴权通过后，NN可以向DN2返回DN列表。
压缩存储代理模块发送给NN的请求中携带上述保存路径，如：
hdfs：//namenode：9000/user/hadoop/study/helloworld.dat；用于将数据块对应到NN创建的待存储文件的信息。
本步骤也可以不由压缩存储代理模块执行，例如：由硬件压缩卡执行是可以的，也可以新设置一个模块来实现。
在DN列表中包含的DN的个数与数据块备份的副本个数相同。在DN列表中，需要携带能够确定DN的必要信息，例如：DN的主机名、IP地址，或者端口号等。在图5中，DN列表中的DN个数为3，分别为DN3～DN5。
本步骤中，由于数据块被存储到DN节点以后，还需要在用户发出恢复原始的待存储文件的指令后对上述待存储文件进行恢复操作。基于此，本发明实施例还提供了在NN侧记录数据块相关信息的方案，具体如下：DN2需要向NN发送数据块的数据块号，用于确定这个数据块在整个待存储文件中的顺序。
数据块号的编号方式可以依具体的应用场景不同而不同，其中可以通用的方案如下：数据块号的编号方式可以采用如下方式进行：分片号+数据块序号。其中分片号是文件分片在待存储文件的所有分片中的序号，数据块序号是该数据块在其所在的文件分片中的序号。例如1-001就必定在2-001之前，因此仍然可以确定各数据块的顺序。
如果基于如下的特定应用场景，如：文件分片的个数和数据压缩节点的个数相同，并且文件分片是按照DN的序号的先后次序依次发送给数据压缩节点的，那么，数据块号的编号方式，可以采用如下方式进行：DN号+数据块序号。例如：DN1得到的第一个数据块号为：1-001，DN2得到的第二个数据块号为2-002。
在NN接收到需要恢复原始的待存储文件的指令后，可以首先找到待存储文件对应的数据块号及其所在的DN，从DN节点中读取出这些数据块，并依据记录的数据块号确定数据块在原始的待存储文件中的顺序，从而恢复出原始的待存储文件。
310：DN2的压缩存储代理模块调用FSDataOutputStream，将数据块依次存入DN3～DN5。
依次存入的过程是：压缩存储代理模块将数据块发送给DN列表中的第一个DN(DN3)。消息中携带数据块，DN3保存完数据块，则向DN列表中的下一个DN(DN4)发送数据块，直至列表中的最后一个DN(DN5)保存完数据块。
311：DN5～DN3依次返回写确认到达压缩存储代理模块调用的FSDataOutputStream，用于确认数据块存储完毕。压缩存储代理模块调用FSDataOutputStream在接收到写确认以后，可以进行下一个数据块的存储操作，执行过程与前一数据块相同。待全部数据块存储完毕后通知客户端节点和NN存储完毕，并关闭与NN以及客户端节点的连接。
写确认的消息的返回路径如下：DN列表中的最后一个DN(DN5)保存完数据块后发送写确认给DN列表的倒数第二个DN(DN4)，DN4将写确认转发给前一个DN，直到DN列表的第一个DN(DN3)，DN3再将写确认转发给压缩存储代理模块调用的FSDataOutputStream。最终由压缩存储代理模块确定一个数据块存储完成。
客户端节点如果维护了文件分片的状态信息，那么还可以将与返回存储完毕信息的DN对应的文件分片的状态设定为完成(Finished)，客户端节点在确定全部的文件分片的状态为Finished以后，可以确定待存储文件已经存储完毕，这时可以向NN返回存储完成消息，还可以记录本次分布式压缩存储流程完成。
在本实施例中，多个DN上的硬件压缩卡进行数据压缩，提高了压缩的并行度，可以缩短文件压缩时间。在硬件压缩卡上，可以将文件分片直接压缩为HDFS Block大小，每产生一个数据块，DN就可以向HDFS存储一个数据块块，多个DN存储操作时并行的，无需等待所有数据压缩完毕后再由数据所在节点切分后保存。采用硬件压缩卡执行压缩，不必占用DN或者客户端节点的CPU资源，能够节省了CPU资源。
本发明实施例提供了一种名称节点，应用于分布式文件系统，上述分布式文件系统包括客户端节点、上述名称节点以及数据节点，如图4所示，上述名称节点包括：
第一接收单元401，用于接收客户端节点发送的文件创建请求；
第一确定单元402，用于在上述第一接收单元401接收到客户端节点发送的文件创建请求后，确定数据压缩节点集，上述数据压缩节点集包含至少两个数据压缩节点，上述数据压缩节点为具有数据压缩处理资源的数据节点；
第一发送单元403，用于将上述第一确定单元402确定的上述数据压缩节点集发送给客户端节点；
第二接收单元404，用于接收到上述数据压缩节点集中的数据压缩节点发送的节点获取请求；
第二确定单元405，用于在上述第二接收单元404接收到上述数据压缩节点集中的数据压缩节点发送的节点获取请求后，确定数据存储节点，上述数据存储节点为具有数据存储资源的数据节点；
第二发送单元406，用于将上述第二确定单元405确定的上述数据存储节点的信息发送给上述节点获取请求对应的数据压缩节点。
可选地，上述第一确定单元402，用于选取当前可用的压缩处理资源达到预定标准的至少两个数据压缩节点；将选取的上述至少两个数据压缩节点的集合作为上述数据压缩节点集。
可选地，上述第二确定单元405，具体用于在上述第一接收单元401接收到上述节点获取请求后，确定上述数据压缩节点是否属于上述数据压缩节点集，若是，则确定数据存储节点。
进一步地，如图5所示，上述名称节点还包括：
第一记录单元501，用于在上述第一确定单元402确定数据压缩节点集之后，记录上述数据压缩节点集和对应于上述数据压缩节点集的待存储文件的信息；
上述节点获取请求中携带上述数据块所属待存储文件的信息，以及上述数据压缩节点的标识；
上述第二确定单元405，具体用于依据上述数据块所属待存储文件的信息确定对应的数据压缩节点集，并判断发送上述节点获取请求的数据压缩节点是否属于确定的上述数据压缩节点集。
进一步地，如图6所示，上述名称节点还包括：
第二记录单元601，用于在上述第一确定单元402接收到客户端节点发送的文件创建请求后，记录上述文件创建请求指定需要保存的待存储文件的文件名；
上述第二记录单元601，还用于在上述第二确定单元405确定数据存储节点之后，记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识，上述数据块号包含上述数据块在其所在的文件分片中的序号以及上述数据块所属的文件分片的序号。
进一步地，如图7所示，上述名称节点还包括：
第一恢复单元701，用于在恢复上述待存储文件过程中，依据上述第二记录单元601记录的数据块号确定上述数据块所属的待存储文件，依据上述数据块号中上述数据块在其所在的文件分片中的序号以及上述数据块所属的文件分片的序号确定上述数据块在上述待存储文件中的顺序。
进一步地，如图8所示，上述名称节点还包括：
第三记录单元801，用于在上述第一确定单元402接收到客户端节点发送的文件创建请求后，记录上述文件创建请求指定需要保存的待存储文件的文件名；
上述第三记录单元801，还用于在确定数据存储节点之后，若上述待存储文件的文件分片的个数与上述数据压缩节点集中的数据压缩节个数相同，并且文件分片被按照数据压缩节点的序号的顺序分发给数据压缩节点，则记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识，上述数据块号包含上述数据块在其所在的文件分片中的序号以及上述数据压缩节点的序号。
进一步地，如图9所示，上述名称节点还包括：
第二恢复单元901，用于在恢复上述待存储文件过程中，依据上述第三记录单元801记录的数据块号确定上述数据块所属的待存储文件，依据上述数据块号中的上述数据块在其所在的文件分片中的序号以及上述数据压缩节点的序号确定上述数据块在上述待存储文件中的顺序。
本发明实施例还提供另一种名称节点，如图10所示，包括：接收器1001、发射器1002、处理器1003以及存储器1004；其中存储器1004可以应用于处理器1003在数据处理过程中的数据缓存等应用，也可以应用于数据的存储。
上述名称节点应用于分布式文件系统，上述分布式文件系统包括客户端节点、上述名称节点以及数据节点；在本实施例中，分布式文件系统可以是任意的分布式文件系统，特别地可以应用于HDFS。
上述接收器1001，用于接收客户端节点发送的文件创建请求；
上述处理器1003，用于在接收到客户端节点发送的文件创建请求后，确定数据压缩节点集，上述数据压缩节点集包含至少两个数据压缩节点，上述数据压缩节点为具有数据压缩处理资源的数据节点；
上述发射器1002，用于将上述数据压缩节点集发送给客户端节点；
上述接收器1001，还用于接收上述数据压缩节点集中的数据压缩节点发送的节点获取请求；
上述处理器1003，用于在接收到上述数据压缩节点集中的数据压缩节点发送的节点获取请求后，确定数据存储节点，上述数据存储节点为具有数据存储资源的数据节点；
上述发射器1002，用于将确定的上述数据存储节点的信息发送给上述节点获取请求对应的数据压缩节点。
在本实施例中，名称节点确定的数据压缩节点集中包含了至少两个数据压缩节点，数据压缩节点集中的数据压缩节点参与了待存储文件的压缩。由于数据压缩节点是数据节点，名称节点管理节点的功能修改较小；更重要的是，各个数据压缩节点的数据压缩和存储过程是并行的。因此，采用本发明实施例待存储文件的压缩和存储不再仅限于客户端节点的处理能力，因此可以提高分布式系统的数据压缩存储效率，提高分布式系统的速度。
名称节点具有管理数据压缩节点以及数据存储节点的功能，名称节点需要确定可以作为某次数据压缩存储过程中的数据压缩节点，本实施例还提供了如何确定数据压缩节点的策略，具体如下：上述处理器1003，用于确定数据压缩节点集包括：选取当前可用的压缩处理资源达到预定标准的至少两个数据压缩节点；将选取的上述至少两个数据压缩节点的集合作为上述数据压缩节点集。
在本实施例中，采用所有数据压缩节点当前可用的压缩处理资源为标准进行选择；可用的压缩处理资源可以包含数据压缩的最直接资源，如：空闲的压缩计算资源，还可以包括配合压缩处理的必要资源，如：传输压缩数据的资源。因此压缩处理资源应当理解为较为广泛的压缩处理资源，不应简单理解为只能包含计算资源。
在本实施例中，名称节点管理数据压缩存储的过程，因此还可以加入鉴权的方案来保证客户端节点能够按照名称节点确定的压缩节点集分配文件分片，具体如下：上述处理器1003，用于在接收到上述数据压缩节点发送的节点获取请求后，确定数据存储节点，包括：在接收到上述节点获取请求后，确定上述数据压缩节点是否属于上述数据压缩节点集，若是，则确定数据存储节点。
基于本实施例中的名称节点在确定数据压缩节点集之后，上述处理器1003，还用于记录上述数据压缩节点集和对应于上述数据压缩节点集的待存储文件的信息；上述节点获取请求中携带上述数据块所属待存储文件的信息，以及上述数据压缩节点的标识；上述处理器1003，用于确定上述数据压缩节点是否属于上述数据压缩节点集包括：依据上述数据块所属待存储文件的信息确定对应的数据压缩节点集，并判断发送上述节点获取请求的数据压缩节点是否属于确定的上述数据压缩节点集。
本实施例可以实现数据压错存储，基于数据压缩存储的流程，本实施例还提供了用户在后续有数据恢复需求的情况下如何进行数据恢复的数据准备，在名称节点一侧需要记录一些数据，具体如下：上述处理器1003，还用于在接收到客户端节点发送的文件创建请求后，记录上述文件创建请求指定需要保存的待存储文件的文件名；
在确定数据存储节点之后，记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识，上述数据块号包含上述数据块在其所在的文件分片中的序号以及上述数据块所属的文件分片的序号。
在本实施例中，文件分片的序号是待存储文件被切分为文件分片后，按照文件分片在待存储文件中的顺序依次编号的序号；数据块由于是文件分片压缩得到的，因此数据块与文件分片有所属关系，文件分片压缩会得到很多数据块，数据块在其所在的文件分片中的序号也是顺序编号得到的序号。
基于本实施例记录的数据，本实施例还提供了进行数据恢复的方案，如下：上述处理器1003，还用于在记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识之后，在恢复上述待存储文件过程中，依据上述数据块号确定上述数据块所属的待存储文件，依据上述数据块号中上述数据块在其所在的文件分片中的序号以及上述数据块所属的文件分片的序号确定上述数据块在上述待存储文件中的顺序。
以上实施例通过记录数据块在所在的文件分片中的序号以及数据块所属的文件分片的序号，该记录方案可以应用在所有场景下。对于特定的场景，可以改变记录的数据的具体内容，本实施例还提供了如下方案：上述处理器1003，还用于在接收到客户端节点发送的文件创建请求后，记录上述文件创建请求指定需要保存的待存储文件的文件名；
在确定数据存储节点之后，若上述待存储文件的文件分片的个数与上述数据压缩节点集中的数据压缩节个数相同，并且文件分片被按照数据压缩节点的序号的顺序分发给数据压缩节点，则记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识，上述数据块号包含上述数据块在其所在的文件分片中的序号以及上述数据压缩节点的序号。
基于以上实施例记录的具体数据内容(数据块号包含上述数据块在其所在的文件分片中的序号以及上述数据压缩节点的序号)，本发明实施例还提供了数据恢复过程中的处理方案，具体如下：上述处理器1003，还用于在记录上述数据块的数据块号和存储上述数据块的数据存储节点的标识之后，在恢复上述待存储文件过程中，依据上述数据块号确定上述数据块所属的待存储文件，依据上述数据块号中的上述数据块在其所在的文件分片中的序号以及上述数据压缩节点的序号确定上述数据块在上述待存储文件中的顺序。
值得注意的是，上述名称节点只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。
另外，本领域普通技术人员可以理解实现上述各方法实施例中的全部或部分步骤是可以通过程序来指令相关的硬件完成，相应的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明实施例揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。
Claims (22)
1.一种数据压缩存储方法，应用于分布式文件系统，所述分布式文件系统包括客户端节点、名称节点以及数据节点，其特征在于，包括：
名称节点在接收到客户端节点发送的文件创建请求后，确定数据压缩节点集，所述数据压缩节点集包含至少两个数据压缩节点，所述数据压缩节点为具有数据压缩处理资源的数据节点；
所述名称节点将所述数据压缩节点集发送给客户端节点；
所述名称节点在接收到所述数据压缩节点集中的数据压缩节点发送的节点获取请求后，确定数据存储节点，所述数据存储节点为具有数据存储资源的数据节点；
所述名称节点将确定的所述数据存储节点的信息发送给所述节点获取请求对应的数据压缩节点；
所述名称节点在接收到所述数据压缩节点发送的节点获取请求后，确定数据存储节点，包括：
所述名称节点接收到所述节点获取请求后，确定所述数据压缩节点是否属于所述数据压缩节点集，若是，则确定数据存储节点；
在确定数据压缩节点集之后，所述方法还包括：所述名称节点记录所述数据压缩节点集和对应于所述数据压缩节点集的待存储文件的信息；
所述节点获取请求中携带数据块所属待存储文件的信息，以及所述数据压缩节点的标识；
所述确定所述数据压缩节点是否属于所述数据压缩节点集包括：
所述名称节点依据所述数据块所属待存储文件的信息确定对应的数据压缩节点集，并判断发送所述节点获取请求的数据压缩节点是否属于确定的所述数据压缩节点集。
2.根据权利要求1所述方法，其特征在于，所述确定数据压缩节点集包括：
选取当前可用的压缩处理资源达到预定标准的至少两个数据压缩节点；将选取的所述至少两个数据压缩节点的集合作为所述数据压缩节点集。
3.根据权利要求1所述方法，其特征在于，
在接收到客户端节点发送的文件创建请求后，所述方法还包括：记录所述文件创建请求指定需要保存的待存储文件的文件名；
在确定数据存储节点之后，所述方法还包括：
记录数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号。
4.根据权利要求3所述方法，其特征在于，在记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识之后，所述方法还包括：
在恢复所述待存储文件过程中，依据所述数据块号确定所述数据块所属的待存储文件，依据所述数据块号中所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号确定所述数据块在所述待存储文件中的顺序。
5.根据权利要求1所述方法，其特征在于，
在接收到客户端节点发送的文件创建请求后，所述方法还包括：记录所述文件创建请求指定需要保存的待存储文件的文件名；
在确定数据存储节点之后，所述方法还包括：
若所述待存储文件的文件分片的个数与所述数据压缩节点集中的数据压缩节个数相同，并且文件分片被按照数据压缩节点的序号的顺序分发给数据压缩节点，则记录数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号。
6.根据权利要求5所述方法，其特征在于，在记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识之后，所述方法还包括：
在恢复所述待存储文件过程中，依据所述数据块号确定所述数据块所属的待存储文件，依据所述数据块号中的所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号确定所述数据块在所述待存储文件中的顺序。
7.一种分布式文件系统，包括：客户端节点、名称节点以及数据节点，其特征在于，
客户端节点获取待存储文件，向名称节点发送文件创建请求；
名称节点在接收到所述客户端节点发送的文件创建请求后，确定数据压缩节点集，所述数据压缩节点集包含至少两个数据压缩节点，所述数据压缩节点为具有数据压缩处理资源的数据节点；所述名称节点将所述数据压缩节点集发送给所述客户端节点；
所述客户端节点接收所述名称节点根据所述文件创建请求返回的数据压缩节点集，分割所述待存储文件得到至少两个文件分片，然后将各文件分片发送给所述数据压缩节点集中的数据压缩节点；
数据压缩节点在接收到所述客户端节点发送的文件分片后，压缩接收到的所述文件分片，并分割得到数据块；所述数据压缩节点向所述名称节点发送节点获取请求；
所述名称节点在接收到所述数据压缩节点集中的数据压缩节点发送的节点获取请求后，确定数据存储节点，所述数据存储节点为具有数据存储资源的数据节点；所述名称节点将确定的所述数据存储节点的信息发送给所述节点获取请求对应的数据压缩节点；
所述数据压缩节点接收所述名称节点发送的数据存储节点的信息；所述数据压缩节点将所述数据块发送给所述数据存储节点存储；
所述名称节点在接收到所述数据压缩节点发送的节点获取请求后，确定数据存储节点，包括：
所述名称节点接收到所述节点获取请求后，确定所述数据压缩节点是否属于所述数据压缩节点集，若是，则确定数据存储节点；
在所述名称节点确定数据压缩节点集之后，所述系统还包括：
所述名称节点记录所述数据压缩节点集和对应于所述数据压缩节点集的待存储文件的信息；
所述名称节点获取请求中携带所述数据块所属待存储文件的信息，以及所述数据压缩节点的标识；所述确定所述数据压缩节点是否属于所述数据压缩节点集包括：
所述名称节点依据所述数据块所属待存储文件的信息确定对应的数据压缩节点集，并判断发送所述节点获取请求的数据压缩节点是否属于确定的所述数据压缩节点集。
8.根据权利要求7所述系统，其特征在于，所述确定数据压缩节点集包括：
所述名称节点选取当前可用的压缩处理资源达到预定标准的至少两个数据压缩节点；将选取的所述至少两个数据压缩节点的集合作为所述数据压缩节点集。
9.根据权利要求7所述系统，其特征在于，所述系统还包括：
所述名称节点在接收到客户端节点发送的文件创建请求后，记录所述文件创建请求指定需要保存的待存储文件的文件名；
所述名称节点在确定数据存储节点之后，记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号。
10.根据权利要求9所述系统，其特征在于，所述系统还包括：
所述名称节点在恢复所述待存储文件过程中，依据所述数据块号确定所述数据块所属的待存储文件，依据所述数据块号中所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号确定所述数据块在所述待存储文件中的顺序。
11.根据权利要求7所述系统，其特征在于，所述系统还包括：
所述名称节点在接收到客户端节点发送的文件创建请求后，记录所述文件创建请求指定需要保存的待存储文件的文件名；
所述客户端节点分割所述待存储文件得到的文件分片个数与所述数据压缩节点集中的数据压缩节个数相同，所述客户端节点将得到的文件分片被按照数据压缩节点的序号的顺序分发给数据压缩节点；
所述名称节点在确定数据存储节点之后，记录所述数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号。
12.根据权利要求11所述系统，其特征在于，所述系统还包括：
所述名称节点在恢复所述待存储文件过程中，依据所述数据块号确定所述数据块所属的待存储文件，依据所述数据块号中的所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号确定所述数据块在所述待存储文件中的顺序。
13.根据权利要求7所述系统，其特征在于，
所述客户端节点分割所述待存储文件得到至少两个文件分片包括：将所述待存储文件分割为与各数据压缩节点当前可用的压缩处理资源的多少对应大小的文件分片；所述文件分片的个数等于所述数据压缩节点集中数据压缩节点的个数；
所述客户端节点将各文件分片发送给所述数据压缩节点集中的数据压缩节点包括：将较大的文件分片发送给所述数据压缩节点集中当前可用的压缩处理资源较多的数据压缩节点，将较小的文件分片发送给所述数据压缩节点集中当前可用的压缩处理资源较少的数据压缩节点。
14.根据权利要求13所述系统，其特征在于，所述文件分片的数量大于或等于所述数据压缩节点集中的数据压缩节点的个数；
所述客户端节点将各文件分片发送给所述数据压缩节点集中的数据压缩节点包括：所述客户端节点将文件分片逐个发送给当前具有空闲的数据压缩处理资源的数据压缩节点。
15.根据权利要求7所述系统，其特征在于，所述系统还包括：
所述数据压缩节在压缩所述文件分片之前与其他数据压缩节点协商数据压缩规则；
所述数据压缩节将所述文件分片压缩为压缩文件包括：所述数据压缩节按照协商得到的所述数据压缩规则压缩所述文件分片。
16.根据权利要求7至15任意一项所述系统，其特征在于，所述系统还包括：
所述数据压缩节点在将所述数据块发送给所述数据存储节点存储之前，生成文件压缩头，在所述文件压缩头中携带所述数据压缩规则的指示信息，依据当前使用的数据压缩规则确定是否将所述文件压缩头并入所述数据块，若是则将所述文件压缩头并入所述数据块。
17.一种名称节点，应用于分布式文件系统，所述分布式文件系统包括客户端节点、所述名称节点以及数据节点，其特征在于，所述名称节点包括：
第一接收单元，用于接收客户端节点发送的文件创建请求；
第一确定单元，用于在所述第一接收单元接收到客户端节点发送的文件创建请求后，确定数据压缩节点集，所述数据压缩节点集包含至少两个数据压缩节点，所述数据压缩节点为具有数据压缩处理资源的数据节点；
第一发送单元，用于将所述第一确定单元确定的所述数据压缩节点集发送给客户端节点；
第二接收单元，用于接收到所述数据压缩节点集中的数据压缩节点发送的节点获取请求；
第二确定单元，用于在所述第二接收单元接收到所述数据压缩节点集中的数据压缩节点发送的节点获取请求后，确定数据存储节点，所述数据存储节点为具有数据存储资源的数据节点；
第二发送单元，用于将所述第二确定单元确定的所述数据存储节点的信息发送给所述节点获取请求对应的数据压缩节点；
所述第二确定单元，具体用于在所述第一接收单元接收到所述节点获取请求后，确定所述数据压缩节点是否属于所述数据压缩节点集，若是，则确定数据存储节点；
所述名称节点还包括：
第一记录单元，用于在所述第一确定单元确定数据压缩节点集之后，记录所述数据压缩节点集和对应于所述数据压缩节点集的待存储文件的信息；
所述节点获取请求中携带数据块所属待存储文件的信息，以及所述数据压缩节点的标识；
所述第二确定单元，具体用于依据所述数据块所属待存储文件的信息确定对应的数据压缩节点集，并判断发送所述节点获取请求的数据压缩节点是否属于确定的所述数据压缩节点集。
18.根据权利要求17所述名称节点，其特征在于，
所述第一确定单元，用于选取当前可用的压缩处理资源达到预定标准的至少两个数据压缩节点；将选取的所述至少两个数据压缩节点的集合作为所述数据压缩节点集。
19.根据权利要求17所述名称节点，其特征在于，所述名称节点还包括：
第二记录单元，用于在所述第一确定单元接收到客户端节点发送的文件创建请求后，记录所述文件创建请求指定需要保存的待存储文件的文件名；
所述第二记录单元，还用于在所述第二确定单元确定数据存储节点之后，记录数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号。
20.根据权利要求19所述名称节点，其特征在于，所述名称节点还包括：
第一恢复单元，用于在恢复所述待存储文件过程中，依据所述第二记录单元记录的数据块号确定所述数据块所属的待存储文件，依据所述数据块号中所述数据块在其所在的文件分片中的序号以及所述数据块所属的文件分片的序号确定所述数据块在所述待存储文件中的顺序。
21.根据权利要求17所述名称节点，其特征在于，所述名称节点还包括：
第三记录单元，用于在所述第一确定单元接收到客户端节点发送的文件创建请求后，记录所述文件创建请求指定需要保存的待存储文件的文件名；
所述第三记录单元，还用于在确定数据存储节点之后，若所述待存储文件的文件分片的个数与所述数据压缩节点集中的数据压缩节个数相同，并且文件分片被按照数据压缩节点的序号的顺序分发给数据压缩节点，则记录数据块的数据块号和存储所述数据块的数据存储节点的标识，所述数据块号包含所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号。
22.根据权利要求21所述名称节点，其特征在于，所述名称节点还包括：
第二恢复单元，用于在恢复所述待存储文件过程中，依据所述第三记录单元记录的数据块号确定所述数据块所属的待存储文件，依据所述数据块号中的所述数据块在其所在的文件分片中的序号以及所述数据压缩节点的序号确定所述数据块在所述待存储文件中的顺序。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2014/094179 WO2016095149A1 (zh) | 2014-12-18 | 2014-12-18 | 一种数据压缩存储方法、装置，及分布式文件系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106170968A CN106170968A (zh) | 2016-11-30 |
| CN106170968B true CN106170968B (zh) | 2019-09-20 |
Family
ID=56125612
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201480037404.6A Active CN106170968B (zh) | 2014-12-18 | 2014-12-18 | 一种数据压缩存储方法、装置，及分布式文件系统 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN106170968B (zh) |
| WO (1) | WO2016095149A1 (zh) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106156359B (zh) * | 2016-07-28 | 2019-05-21 | 广东奥飞数据科技股份有限公司 | 一种云计算平台下的数据同步更新方法 |
| CN108242931B (zh) * | 2016-12-23 | 2023-04-28 | 中科星图股份有限公司 | 一种数据压缩提供方法 |
| CN106682227A (zh) * | 2017-01-06 | 2017-05-17 | 郑州云海信息技术有限公司 | 基于分布式文件系统的日志数据存储系统及读写方法 |
| CN107977442B (zh) * | 2017-12-08 | 2020-08-07 | 北京希嘉创智教育科技有限公司 | 日志文件压缩及解压缩方法、电子设备和可读存储介质 |
| CN109302449B (zh) * | 2018-08-31 | 2022-03-15 | 创新先进技术有限公司 | 数据写入方法、数据读取方法、装置和服务器 |
| CN109766319B (zh) * | 2018-12-27 | 2021-05-11 | 网易（杭州）网络有限公司 | 压缩任务处理方法、装置、存储介质及电子设备 |
| CN109831540B (zh) * | 2019-04-12 | 2022-02-11 | 成都四方伟业软件股份有限公司 | 分布式存储方法、装置、电子设备及存储介质 |
| CN114040027B (zh) * | 2021-10-29 | 2023-11-24 | 深圳智慧林网络科技有限公司 | 一种基于双模式的数据压缩方法、装置和数据解压方法 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101193301A (zh) * | 2006-11-30 | 2008-06-04 | 三星电子株式会社 | 在视觉上压缩图像数据的方法、介质和系统 |
| CN101605148A (zh) * | 2009-05-21 | 2009-12-16 | 何吴迪 | 云存储的并行系统的架构方法 |
| CN103020205A (zh) * | 2012-12-05 | 2013-04-03 | 北京普泽天玑数据技术有限公司 | 一种分布式文件系统上基于硬件加速卡的压缩解压缩方法 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8266182B2 (en) * | 2006-06-30 | 2012-09-11 | Harmonic Inc. | Transcoding for a distributed file system |
| US8510267B2 (en) * | 2011-03-08 | 2013-08-13 | Rackspace Us, Inc. | Synchronization of structured information repositories |
| TW201445989A (zh) * | 2013-05-30 | 2014-12-01 | Hon Hai Prec Ind Co Ltd | 分散式編解碼系統及方法 |
-
2014
- 2014-12-18 CN CN201480037404.6A patent/CN106170968B/zh active Active
- 2014-12-18 WO PCT/CN2014/094179 patent/WO2016095149A1/zh active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101193301A (zh) * | 2006-11-30 | 2008-06-04 | 三星电子株式会社 | 在视觉上压缩图像数据的方法、介质和系统 |
| CN101605148A (zh) * | 2009-05-21 | 2009-12-16 | 何吴迪 | 云存储的并行系统的架构方法 |
| CN103020205A (zh) * | 2012-12-05 | 2013-04-03 | 北京普泽天玑数据技术有限公司 | 一种分布式文件系统上基于硬件加速卡的压缩解压缩方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2016095149A1 (zh) | 2016-06-23 |
| CN106170968A (zh) | 2016-11-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106170968B (zh) | 一种数据压缩存储方法、装置，及分布式文件系统 | |
| CN109547524B (zh) | 基于物联网的用户行为存储方法、装置、设备及存储介质 | |
| CN109714330B (zh) | 一种跨网络的断点续传方法和系统 | |
| US20220014434A1 (en) | Slice Resource Deployment Method and Apparatus, and Slice Manager and Computer Storage Medium | |
| US20170031948A1 (en) | File synchronization method, server, and terminal | |
| US11102322B2 (en) | Data processing method and apparatus, server, and controller | |
| CN110233881A (zh) | 业务请求处理方法、装置、设备及存储介质 | |
| EP4221233A1 (en) | Data download method and apparatus, computer device and storage medium | |
| US10020916B2 (en) | Method and apparatus for data communication of vehicle | |
| CN110083307A (zh) | 数据存储方法、存储器和服务器 | |
| CN106559241A (zh) | 应用日志的收集、发送方法、装置、系统及日志服务器 | |
| CN111953520B (zh) | 通过群组虚拟设备实现群体控制的方法、装置、设备及介质 | |
| CN110719526B (zh) | 视频播放方法及装置 | |
| CN111651498A (zh) | 一种区块链数据的高效检索方法及装置 | |
| CN111200479B (zh) | 传输数据的校验方法、存储介质 | |
| CN110109865A (zh) | 一种数据存储方法、装置、设备及可读存储介质 | |
| CN112398754B (zh) | 数据传输方法、装置、介质、电子设备及网络接入设备 | |
| CN106453663B (zh) | 改进的基于云服务的存储扩容方法及装置 | |
| CN115348333B (zh) | 基于udp双端通信交互的数据传输方法、系统及设备 | |
| US20120102086A1 (en) | Processing node selection system, information processing node, processing execution method and program | |
| CN111405313B (zh) | 存储流媒体数据的方法和系统 | |
| CN110401723A (zh) | Ova文件上传服务器的方法、系统、设备及存储介质 | |
| CN107707590A (zh) | 数据传输的系统、方法及装置 | |
| CN110519355A (zh) | 下发ova文件信息的方法、系统、设备及存储介质 | |
| CN113014533B (zh) | 校验文件的处理方法、装置及系统、存储介质、电子装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20220211 Address after: 550025 Huawei cloud data center, jiaoxinggong Road, Qianzhong Avenue, Gui'an New District, Guiyang City, Guizhou Province Patentee after: Huawei Cloud Computing Technologies Co.,Ltd. Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd. |