[发明专利]基于对象存储Hadoop提交器的实现方法及装置

说明书

本发明公开了一种基于对象存储Hadoop提交器的实现方法及装置。该发明包括：读取一个或多个文件，其中，文件的自定义元数据用于表征文件的描述信息；使用文件秒合功能将一个或多个文件进行合并，生成新文件；将新文件存储到目标目录下，其中，新文件作为软连接用于指向对应的源数据文件。通过本发明，解决了相关技术中在文件存储时采用的提交协议导致文件存储效率低下的技术问题。

技术领域

本发明涉及文件存储领域，具体而言，涉及一种基于对象存储Hadoop提交器的实现方法及装置。

背景技术

相关技术中，Hadoop中MapReduce将用户提交的job拆分成多个单个操作task(分别是map task和reduce task)并在多个节点上执行这些task，task在执行完成后，将执行结果的输出通过output commit协议存储于最终的结果目录。任何job端提交工作都将跨集群中的节点执行，并且可能发生在job执行的关键部分之外。然而，除非output commit协议要求所有task等待job driver的信号，否则task的提交不能在最终目录中实例化它们的输出，可用于将成功task的输出提升到可以提交job的状态，解决投机性执行和失败问题。

因此output commit需要能够处理当job driver出现故障并且重新启动时，重新启动的job driver仅重新运行未完成的task；当重新启动的job完成时，将恢复已完成task的输出以供提交。

其中，常用的output committer包括：FileOutputCommitter，Staging Committer和Magic Committer。

其中，FileOutputCommitter：标准的提交算法(及其v1和v2算法)依赖于目录重命名这个O(1)原子操作：调用者将其工作输出到目标文件系统中的临时目录，然后将这些目录重命名为最终目标，作为提交工作的方式。基于使用一致的list清单来操作commit，并且其中FileSystem.rename()命令是O(1)原子操作，用rename允许单个task在临时目录中工作，使用rename as原子操作可以显式地commit task并最终提交整个Job。因为重命名的成本很低，所以可以在task和job commit期间以最小的延迟执行rename。注意，HDFS将在rename操作期间锁定namenode元数据，因此所有rename()调用都将被序列化。但是，由于它们只更新两个目录条目的元数据，所以锁的持续时间很短。而对于对象存储而言，rename由O(1)的操作变为了两段式的提交模式，并非原子操作，在对象存储的rename操作的copy阶段，需要对数据进行copy操作，效率很低。

Staging Committer：该committer在是用过程中需要先将数据写入本地，再提交到S3对象存储中，效率低下。而且需要引入第三方的强一致性存储系统(如HDFS)，所以会带来架构的复杂性，提高运维难度。

Magic Committer：该committer使用分段上传来提交task的输出文件，但是并不会区分文件大小，一般情况下建议在对大文件(如100M以上)使用分段上传来提高上传效率，而Magic Committer无论多小的文件都使用分段上传，造成IO效率低下。在task commit和job commit阶段需要不停的读、写、合并.pendingset文件，影响IO效率。该Committer是在Hadoop3版本中发布的，并不支持当前市场主流的Hadoop2版本。

同时需要说明的是，S3协议兼容的对象存储在一致性的表现上，大致分为最终一致性(弱一致性)和强一致性两种。Staging Committer和Magic Committer都是偏重于对弱一致性的存储系统的支持。而对于强一致性的S3协议兼容的对象存储，是不需要引入一致性组件的。

针对相关技术中存在的上述问题，目前尚未提出有效的解决方案。

发明内容