CN114661668A - 文件管理方法及相关装置 - Google Patents

Abstract

本申请实施例公开了一种文件管理方法及相关装置，方法包括：通过驱动端启动主线程遍历由执行端产生的临时文件夹，获取任务目录；启动第一子Job发遍历任务目录，得到第一文件集合；对第一文件集合执行过滤操作，得到第二文件集合；启动第二子Job对第二文件集合并发执行合并操作，得到第三文件集合后，删除第二文件集合，并在移动完成目标文件后创建_SUCCESS标记文件。如此，通过本申请实施例的方案，可以实现自适应地减少存储***中的文件数量，便于数据生命周期管理；同时还能降低驱动端出现OOM的概率，提升Spark任务稳定性和执行效率。

Description

文件管理方法及相关装置

技术领域

本申请涉及电子技术领域，具体涉及一种文件管理方法及相关装置。

背景技术

现有的文件管理的方案中，一般需要借助定时执行工具或者***，配置周期性的定时任 务进行合并任务，实现对数据文件的管理。

但是上述方式需要借助额外的工具或***，并且需要结合人为操作，这种方式下***的 稳定性和执行效率较低。同时，文件合并删除过程与用户进行文件调用的状态是相互隔离的， 会存在数据不同步的问题，影响用户的体验感。因此，亟需一种文件管理方法来改进上述问 题。

发明内容

本申请实施例提供了一种文件管理方法及相关装置，通过对数据文件集合的筛选确定需 要进行合并的小数据文件，并对其按照分区信息进行分组合并，如此能够保证小数据文件在 存储***中占据连续的存储空间，进而实现自适应地减少存储***中的文件数量，便于数据 生命周期管理；同时合并后的数据文件能提高驱动端内存空间的利用率，减少驱动端出现 OOM的概率，提升Spark任务稳定性和执行效率。

第一方面，本申请实施例提供一种文件管理方法，应用于文件管理***的驱动端，所述 方法包括：

启动主线程遍历Job临时文件夹，获取任务目录，其中，所述任务目录由所述执行端执 行任务提交操作产生；

启动第一子Job并发遍历所述任务目录，得到第一文件集合，所述第一文件集合包括待 写入数据文件；

对所述第一文件集合执行过滤操作，得到第二文件集合，所述第二文件集合包括目标待 合并文件；

启动第二子Job对所述第二文件集合并发执行合并操作，得到第三文件集合；

将所述第三文件集合依次移动到目标目录后，删除所述第二文件集合。

第二方面，本申请实施例提供一种文件管理方法，应用于文件管理***的执行端，所述 方法包括：

对临时文件夹执行任务提交操作，生成任务目录。

第三方面，本申请实施例提供一种文件管理方法，应用于文件管理***的驱动端，所述 方法包括：

启动主线程遍历用户目录下小文件合并工作目录，获取克隆目录，其中，所述克隆目录 由执行端通过拷贝任务目录产生，所述任务目录由所述执行端执行任务提交操作产生；

启动第三子Job并发遍历所述克隆目录，得到第四文件集合，所述第四文件集合包括待 写入数据文件的克隆文件；

解析所述第四文件集合，得到第五文件集合，所述第五文件集合包括目标待合并数据文 件的真实文件；

启动第四子Job对所述第五文件集合并发执行合并操作，得到第六文件集合；

将所述第六文件集合依次移动到目标目录后，删除所述第五文件集合。

第四方面，本申请实施例提供一种文件管理方法，应用于文件管理***的执行端，所述 方法包括：

执行数据文件的写入操作，产生临时文件夹；

对所述临时文件夹执行任务提交操作，产生任务目录；

通过拷贝所述任务目录，得到克隆目录。

第五方面，本申请实施例提供一种文件管理装置，应用于文件管理***的驱动端，所述 装置包括：

获取单元，用于所述驱动端启动主线程遍历Job临时目录，获取执行端执行任务提交操 作产生的任务目录；

所述获取单元，还用于所述主线程启动第一子Job遍历所述任务目录，获取第一文件集 合；

遍历单元，用于遍历所述第一文件集合，得到第二文件集合，所述第二文件集合包括一 个或多个待合并文件；

合并单元，用于所述主线程启动第二子Job对所述一个或多个待合并文件执行合并操作， 得到第三文件集合；

处理单元，用于将所述第三文件集合移动到目标目录后，删除所述第二文件集合。

第六方面，本申请实施例提供一种文件管理装置，应用于文件管理***的执行端，所述 装置包括：

提交单元，用于对临时文件夹执行任务提交操作，生成任务目录。

第七方面，本申请实施例提供一种文件管理装置，应用于文件管理***的驱动端，所述 装置包括：

启动单元，用于启动主线程遍历用户目录下小文件合并工作，获取克隆目录，其中，所 述克隆目录由执行端通过拷贝任务目录产生，所述任务目录由所述执行端执行任务提交操作 产生；

所述启动单元，还用于启动第三子Job并发遍历所述克隆目录，得到第四文件集合，所 述第四文件集合包括待写入数据文件的克隆文件；

所述启动单元，还用于启动第四子Job对所述第五文件集合并发执行合并操作，得到第 六文件集合；

解析单元，用于解析所述第四文件集合，得到第五文件集合，所述第五文件集合包括目 标待合并数据文件的真实文件；

处理单元，用于将所述第六文件集合依次移动到目标目录后，删除所述第五文件集合。

第八方面，本申请实施例提供一种文件管理装置，应用于文件管理***的执行端，所述 装置包括：

写入单元，用于执行数据文件的写入操作，产生临时文件夹；

提交单元，用于对所述临时文件夹执行任务提交操作，产生任务目录；

复制单元，通过拷贝任务目录，得到克隆目录。

第九方面，本申请实施例提供一种电子设备，包括处理器、存储器、通信接口以及一个 或多个可执行程序代码，其中，上述一个或多个程序被存储在上述存储器中，并且被配置由 上述处理器执行，上述可执行程序代码包括用于执行本申请实施例第一方面或第二方面中任 一步骤的指令。

第十方面，本申请实施例提供一种电子设备，包括处理器、存储器、通信接口以及一个 或多个可执行程序代码，其中，上述一个或多个可执行程序代码被存储在上述存储器中，并 且被配置由上述处理器执行，上述程序包括用于执行本申请实施例第三方面或第四方面中任 一步骤的指令。

第十一方面，本申请实施例提供了一种计算机可读存储介质，其中，上述计算机可读存 储介质存储用于电子数据交换的计算机程序，其中，上述计算机程序使得计算机执行如本申 请实施例第一方面或第二方面中所描述的部分或全部步骤。

第十二方面，本申请实施例提供了一种计算机可读存储介质，其中，上述计算机可读存 储介质存储用于电子数据交换的计算机程序，其中，上述计算机程序使得计算机执行如本申 请实施例第三方面或第四方面中所描述的部分或全部步骤。

第十三方面，本申请实施例提供了一种计算机程序产品，其中，上述计算机程序产品包 括存储了计算机程序的非瞬时性计算机可读存储介质，上述计算机程序可操作来使计算机执 行如本申请实施例第一方面或第二方面任一方法中所描述的部分或全部步骤。该计算机程序 产品可以为一个软件安装包。

第十四方面，本申请实施例提供了一种计算机程序产品，其中，上述计算机程序产品包 括存储了计算机程序的非瞬时性计算机可读存储介质，上述计算机程序可操作来使计算机执 行如本申请实施例第三方面或第四方面任一方法中所描述的部分或全部步骤。该计算机程序 产品可以为一个软件安装包。

可以看出，本申请实施例公开了一种文件管理方法及相关装置，可通过驱动端启动主线 程遍历由执行端产生的临时文件夹，并获取任务目录；启动第一子Job并发遍历任务目录， 得到第一文件集合；对第一文件集合执行过滤操作，得到第二文件集合；启动第二子Job对 第二文件集合并发执行合并操作，得到第三文件集合后，删除第二文件集合，并对移动完成 的文件创建标记文件。如此，通过本申请实施例的方案，可以实现自适应地减少存储***中 的文件数量，便于数据生命周期管理；同时还能降低驱动端出现OOM的概率，提升Spark 任务稳定性和执行效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需 要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例， 对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其 他的附图。

图1A是本申请实施例提供了一种常用的文件合并的流程示意图；

图1B是本申请实施例提供了一种hadoop的文件合并方法的流程示意图；

图2是本申请实施例提供的一种文件管理方法的流程示意图；

图3是本申请实施例提供的一种文件管理方法的交互流程示意图；

图4是本申请实施例提供的另一种文件处理方法的流程示意图；

图5是本申请实施例提供的一种文件管理装置的功能单元组成框图；

图6是本申请实施例提供的另一种文件管理装置的功能单元组成框图；

图7是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图， 对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请 一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有 作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对 象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆 盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、***、产品或设备没有限定 于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这 些过程、方法、产品或设备固有的其他步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本 申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例， 也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的 是，本文所描述的实施例可以与其它实施例相结合。

1)电子设备可以是还包含其它功能诸如个人数字助理和/或音乐播放器功能的便携式电 子设备，诸如手机、平板电脑、具备无线通讯功能的可穿戴电子设备(如智能手表)等。便 携式电子设备的示例性实施例包括但不限于搭载IOS***、Android***、Microsoft***或者 其它操作***的便携式电子设备。上述便携式电子设备也可以是其它便携式电子设备，诸如 膝上型计算机(Laptop)等。还应当理解的是，在其他一些实施例中，上述电子设备也可以 不是便携式电子设备，而是台式计算机。

2)分布式文件***(Distributed File System，DFS)是指文件***管理的物理存储资源 不一定直接连接在本地节点上，而是通过计算机网络与节点(可简单的理解为一台计算机) 相连；或是若干不同的逻辑磁盘分区或卷标组合在一起而形成的完整的有层次的文件***。 DFS为分布在网络上任意位置的资源提供一个逻辑上的树形文件***结构，从而使用户访问 分布在网络上的共享文件更加简便。单独的DFS共享文件夹的作用是相对于通过网络上的其 他共享文件夹的访问点。

3)内存溢出(Out of memory，OOM)内存溢出(Out Of Memory，简称OOM)是指应用系 统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的 最大内存。此时程序就运行不了，***会提示内存溢出，有时候会自动关闭软件，重启电脑 或者软件后释放掉一部分内存又可以正常运行该软件，而由***配置、数据流、用户代码等 原因而导致的内存溢出错误，即使用户重新执行任务依然无法避免。

4)Apache Spark是专为大规模数据处理而设计的快速通用的计算引擎。Spark是UC Berkeley AMP lab(加州大学伯克利分校的AMP实验室)所开源的类Hadoop MapReduce的通用 并行框架。Spark是大数据领域一个非常流行的计算引擎，其文件数量主要取决于RDD中 partition分区的数量和表分区的数量，需要注意的是，这里提到的两个分区是不一样的概念， RDD的partition分区与Spark任务执行的并发度相关，而表分区则是Hive中的概念。Spark程序 产生的文件数目一般是RDD分区数和Hive表分区数的乘积，当Spark任务并行度过高或表分区 数目过大时，就容易导致出现小文件过多的问题，进而引发一系列其他问题。Spark，拥有 Hadoop MapReduce所具有的优点；但不同于MapReduce的是——Job中间输出结果可以保存在 内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭 代的MapReduce的算法。

其中，Spark框架主要的构成包括以下几个部分：

Application：用户编写的Spark应用程序。

驱动端Driver：Spark中的Driver即运行上述Application的main函数并创建SparkContext， 创建Spark Context的目的是为了准备Spark应用程序的运行环境，在Spark中有SparkContext负 责与Cluster Manager通信，进行资源申请、任务的分配和监控等，当Executor部分运行完毕后， Driver同时负责将SparkContext关闭。

执行端Executor：是运行在工作节点(WorkerNode)的一个进程，负责运行Task。

RDD：弹性分布式数据集，是分布式内存的一个抽象概念，提供了一种高度受限的共享 内存模型。

DAG：有向无环图，反映RDD之间的依赖关系。

Task：运行在Executor上的工作单元。

Job：一个Job包含多个RDD及作用于相应RDD上的各种操作。

Stage：是Job的基本调度单位，一个Job会分为多组Task，每组Task被称为Stage，或者也 被称为TaskSet，代表一组关联的，相互之间没有Shuffle依赖关系的任务组成的任务集。

Cluter Manager：指的是在集群上获取资源的外部服务。目前有以下三种类型：

1)Standalon:spark原生的资源管理，由Master负责资源的分配；

2)Apache Mesos:与hadoop MR兼容性良好的一种资源调度框架；

3)Hadoop Yarn:主要是指Yarn中的ResourceManager。

目前，常规的领域对于小文件合并的使用的方法是通过离线Spark任务实现对指定目录 下小数据文件的合并，其主要实现思路是请参照图1A所示的一种常用的文件合并的流程示意 图，具体过程包括：

使用定时执行工具或***，配置周期性的定时任务，在原始数据文件完成写入并持久化 落盘后，在指定时间起一个Spark任务对指定目录进行遍历和过滤，得到待合并的小数据文 件，然后进行合并操作，在中间目录生成大数据文件，如果小文件合并执行成功，再将合并 生成的大数据文件转移到目标目录下并删除原来的小数据文件；如果在合并过程中出现异常 导致Spark任务执行失败，则需要人工清理掉合并过程中生成的临时数据目录和文件，然后 再重新调度执行Spark任务来进行小数据文件的合并。为更好地理解本申请的技术方案，下 面结合具体实施例，对本申请进行详细说明。

上述方案中，需要借助额外的工具或***，同时文件合并删除过程与用户进行文件调用 的状态是相互隔离的，会存在数据不同步的问题。因此，本申请方案在常规的文件合并方案 的基础上，基于spark框架实现文件的合并操作。

Spark在进行计算处理的过程中，一般都是采用Hadoop的FileOutputCommitterV1文件 提交算法，简单来说就是，通过两次rename操作将数据写入到最终的目标目录，具体地请参 照图1B所示，图1B是一种hadoop的文件合并方法的流程示意图，具体包括以下步骤。

每个task任务将数据写入到如下路径：(数据并行写入临时目录)

tableDir/_temporary/appAttemptDir/_temporary/taskAttemptDir/dataFile。

各个task任务完成数据的读取和写入后，会执行commitTask方法做第一次rename操作， 将数据文件从task任务的临时目录转移到如下路径：(task目标目录)

tableDir/_temporary/appAttemptDir/taskDir/dataFile。

当所有task任务都执行完commitTask方法提交数据文件后，driver端会执行commitJob 方法做第二次rename操作，按照顺序将数据文件从Spark Job的临时目录转移到如下目标路 径，并生成_SUCCESS标志文件：(最终目标目录)

tableDir/datafile。

tableDir/_SUCCESS。

基于Hadoop FileOutputCommitter V1文件提交算法的Spark作业执行原理，简单概括如下图2所对应的具体过程。

为了更好地理解本申请方案的内容，下面将结合具体的示例进行方案的描述。

请参阅图2，图2是本申请实施例提供了一种文件管理方法的流程示意图，应用于文件管理***的驱动端，如图2所示，本申请中文件管理方法具体包括以下操作步骤。

S201、启动主线程遍历作业临时文件夹，获取任务临时目录。

其中，所述任务目录由所述执行端执行任务提交操作产生。

具体地，本申请方案主要是利用spark架构去实现本方案的内容。通过本申请方案提出 来的方法，可以适用于所有适配了Hadoop的文件提交协议的分布式文件***。

具体地，在执行端executor将数据写入到文件***时，会产生一个存储数据文件的临时 文件夹，其中，临时文件夹下面存在着一个或多个子文件夹，有各自对应的目录路径。

进一步地，executor在完成数据读取操作后，会执行数据提交操作，实现将数据存入执 行端的临时目录中。在此过程中，执行端进行任务提交操作采用的是并行操作，可以同时提 交若干个数据文件。在进行并行操作的时候，执行端会产生任务目录，所述任务目录里用于 表征提交事件。

S202、启动第一子Job并发遍历所述任务目录，得到第一文件集合。

具体地，所述第一文件集合包括待写入数据文件。

具体地，目录是文件***中另一个重要的概念。一个“目录”或“文件夹”就是一个虚 拟容器，它里面保存着一组文件和其他一些目录。一个典型的文件***可能会包含成千上万 的目录，多个文件通过存储在一个目录中，可以达到有组织地存储文件的目的。同时，在一 个目录中可以保持另外的目录(称为子目录)，这些目录和文件构成了一个层次结构(即目 录树)。

具体地，驱动端通过启动一个主线程去遍历该任务目录，进而获得各个任务的数据提交 目录。所述数据提交目录包括：数据文件信息和数据文件路径。其中，所述数据文件信息包 括数据文件的大小、名称等等。

具体地，第一文件集合中的待写入数据文件包括但不限于：可直接存入文件***的大数 据文件、需要执行合并操作的小数据文件等等。

S203、对所述第一文件集合执行过滤操作，得到第二文件集合。

具体地，所述第二文件集合包括目标待合并文件。

具体地，本申请方案中，主要是针对小数据文件执行合并操作，以实现减少碎片文件造 成磁盘空间的不连续存储带来的资源浪费等问题。因此，在将待写入数据文件执行落盘操作 时，需要先对数据文件进行筛选过滤。进而，筛选出需要进行合并的目标待合并文件，构成 第二文件集合。

S204、启动第二子Job对所述第二文件集合并发执行合并操作，得到第三文件集合。

具体地，在步骤S203操作选出待合并的数据文件后，驱动端启动一个合并子Job，对上 述筛选结果执行合并操作。得到合并后的第三文件集合，其中，所述文件集合至少包括一个 合并后的数据文件。

S205、将所述第三文件集合依次移动到目标目录后，删除所述第二文件集合。

具体地，在步骤S204操作结束后，将合并后的第三文件集合移动到目标目录中。

进一步地，将第二文件集合执行删除操作，释放其占用的内存资源。同时，对移动后的 第三文件集合创建标记文件，所述标记文件用于表征当前数据文件已经成功存入目标目录中。

可以看出，本申请实施例公开了一种文件管理方法，可通过驱动端启动主线程遍历由执 行端产生的Job临时文件夹，获取任务目录；启动第一子Job并发遍历任务目录，得到第一 文件集合；对第一文件集合执行过滤操作，得到第二文件集合；启动第二子Job对第二文件 集合并发执行合并操作，得到第三文件集合后，删除第二文件集合，并对移动完成的文件创 建标记文件。如此，通过本申请实施例的方案，通过获取执行端产生的任务目录确定需要写 入存储***的数据文件集合，通过对数据文件集合的筛选确定需要进行合并的小数据文件， 并对其按照分区信息进行分组合并，如此能够保证小数据文件在存储***中占据连续的存储 空间，进而实现自适应地减少存储***中的文件数量，便于数据生命周期管理；同时合并后 的数据文件能够提高Spark驱动端内存空间的利用率，减少驱动端出现OOM的概率，提升 Spark任务稳定性和执行效率。

在一个可能的示例中，所述任务目录包括至少一个子目录；所述启动第一子Job并发遍 历所述任务目录，得到第一文件集合，可以包括如下步骤：所述驱动端启动所述第一子Job； 所述第一子Job根据数据文件的命名规则，对所述至少一个子目录下数据文件进行并发遍历， 得到所述待写入数据文件；根据所述待写入数据文件，构建所述第一文件集合。

具体地，使用目录树组织文件***时，需要通过某种方法指明文件名。路径名描述了怎 样在一个文件***中确认一个文件的位置，它是一个分量名序列，各分量名之间用分隔符(通 常分隔符是斜杠符)隔开。分量名是一个字符序列，它指明一个被唯一地包含在前缀(父目 录)分处中的名字。一个完整的路径名由一个分隔符(为了方便讨论，后面采用斜杠符“/” 作为分隔符)开始，并且指明一个文件，这个文件可以从文件***的根(没有祖先的目录) 开始，沿着该路径名的后继分量名所在的那个分支游历文件树而找到。

具体地，驱动端启动第一子Job根据上述命名规则，对步骤S201中执行端进行任务提交 操作时得到的任务目录进行遍历和过滤，即对任务目录中的父目录和子目录进行并发遍历， 得到全部的待写入数据文件。通过遍历和过滤操作得到的待写入数据文件构建第一文件集合。

可以看出，本申请实施例中，通过第一子Job根据目录的命名规则对任务目录进行并发 遍历，能够在较短时间内获取全部待写入数据文件，并进行下一步任务操作。

在一个可能的示例中，所述得到所述待写入数据文件之后，还能包括如下步骤：根据表 分区目录结构解析所述待写入数据文件的存储路径，得到映射信息表，所述映射信息表包括 所述待写入数据文件名及其对应的表分区信息。

具体地，数据文件在写入数据表中时，数据表会分配对应的存储空间，表分区是一种数 据组织方案，在本申请方案中，表数据根据一个或多个表列中的值划分到多个称为数据分区 的存储对象中。每个数据分区都是单独存储的。这些存储对象可以在不同的表空间中，也可 以在相同表空间中。查询处理同样可以利用分离的数据来避免扫描不相关数据，从而使许多 数据仓库样式查询具有更好地查询性能。

示例性地，在获取到待写入数据文件后，根据表分区目录结构对上述数据文件的存储路 径进行解析，得到每一个数据文件所对应的存储路径，即映射信息表。

可以看出，本申请实施例中，可以通过待写入数据文件的解析，能够获取到每一个数据 文件对应的分区信息，进而可以根据分区信息进行后续的文件合并操作。

在一个可能的示例中，所述得到所述待写入数据文件之后，还能包括如下步骤：根据合 并规则对所述待写入数据文件执行过滤操作，得到所述目标待合并文件，所述合并规则用于 筛选不符合文件大小阈值的所述数据文件；根据所述目标待合并文件，构建所述第二文件集 合。

具体地，待写入数据文件中，较大数据文件占据的存储空间是连续且较大的，因此可以 直接存入到目标目录中。对于较小的数据文件，通常是占据较小的空间，且都是碎片式分散 占据存储空间，为了更好地保证存储***的磁盘资源充分利用，可以针对这类文件执行合并 操作，以使若干个小的数据文件合并为较大的数据文件进行存储。

具体地，在获取到所有的待写入数据文件即第一文件集合后，对所有的待写入数据文件 进行并发式遍历和过滤。

实际应用中，可以通过设置合并规则进行上述操作。所述合并规则包括：数据文件的大 小、数据文件的类型等等。需要说明的是，合并规则既可以根据***原本的规则进行，也可 以通过人为设置，在此不做具体限制。本申请方案中，以数据文件的大小作为合并规则为例 进行描述。

具体地，若将数据文件大小阈值设置为1024KB，则驱动端在进行并发遍历过滤时，当检 测到数据文件大小小于1024KB时，将其作为目标待合并文件，添加到第二文件集合中。若 当前数据文件大小大于1024KB，则可以直接进入下一步数据存入操作。

另一种可能的方法还包括根据预设的文件类型进行数据文件遍历和过滤，得到第二文件 集合。其中，具体可以根据文件类型设置优先级，根据优先级对数据文件进行过滤。

可见，本申请实施例中，通过对待写入数据文件按照合并规则进行遍历和过滤，如此能 够将所有待写入数据文件分为可以直接进行存储的数据文件和需要进行合并操作的目标合并 文件。同时，提供简单的配置规则供用户使用，针对不同规模的业务，适应性强、应用范围 广。

在一个可能的示例中，所述方法还包括以下操作步骤：根据所述映射信息表对所述第二 文件集合执行分组操作，得到分组结果，其中，所述分组结果包括至少一个分组，每一个所 述分组包括相同表分区对应的所述目标待合并文件；启动所述第二子Job，对所述分组结果执 行合并操作，得到所述第三文件集合，所述合并操作用于对每一个所述分组中的所述目标待 合并文件进行合并。

具体地，根据上述步骤获取的映射信息表对第二文件集合中的目标待合并文件进行分组， 得到分组结果。其中，分组结果中包括至少一个分组，分组依据是每一个目标待合并文件对 应的表分区信息。故，每一个分组中包含的是同一分区中的目标待合并文件。

可以看出，本申请实施例中，根据映射信息进行分组操作，得到每一个目标待合并文件 对应的分组。进一步地，可以根据分组结果执行合并操作。根据分组结果进一步执行合并操 作，能够保证同一分区下的数据文件合并为同一个数据文件，如此在进行移动到目标目录下 面的作业执行效率。

在一个可能的示例中，所述将所述第三文件集合依次移动到目标目录之后，所述方法还 包括如下步骤：根据所述第三文件集合，生成标记信息文件，所述标记信息文件用于指示所 述第三文件集合移动完成。

具体地，驱动端在将合并后的数据文件移动到最终的目标目录后，将第二文件集合中的 目标待合并文件进行删除。释放当前第二文件集合中的数据文件所占据的磁盘空间。

实际应用中，如果有执行端并发提交大规模的待写入数据文件，即使所有提交任务都执 行完成了，仍需等待较长一段时间Spark作业才执行结束，这些时间主要耗费在Spark driver 端做第二次rename操作。

本方案中，在Spark作业执行过程中，如果部分任务提交操作已执行成功，而此时Spark Job执行失败，则可能会有一部分数据对外可见，此时需要数据消费者根据是否新生成了 _SUCCESS标记文件来判断数据的完整性。因此，在本申请方案中，在驱动端将合并后的数 据文件移动到最终的目标目录中后，会对移动后的数据文件创建空标记文件_SUCCESS。

可见，本申请实施例中，在完成移动操作后，数据文件存入到目标目录中，重新生成 _SUCCESS标记文件以表示Spark作业执行成功。

在一个可能的示例中，所述方法还应用于文件管理***的执行端；所述方法包括：对临 时文件夹执行任务提交操作，生成任务目录。

具体地，执行端在将待写入数据文件写入临时文件夹后，将待写入数据文件从临时文件 夹提交到执行端的目标目录。

可见，本申请实施例中，执行端通过将临时文件移动到执行端的目标目录中，从而提交 过程产生的任务目录作为驱动端遍历的依据。

在一个可能的示例中，所述对所述临时文件夹执行任务提交操作之前，所述方法还包括 如下步骤：在用户目录下，对数据文件及所属分区目录执行克隆操作，生成临时目录和文件； 在任务数据文件及所属目录全部完成克隆后，执行所述任务提交操作。

可见，本申请实施例中，通过执行端将待写入数据文件写入到临时文件夹中，进一步将 临时文件夹中数据文件移动到执行端的目标目录中，产生任务目录。如此，驱动端可根据任 务目录来获取待存入的数据文件。

下面将结合图3来具体描述文件处理方法实施例中记载的任何一种文件管理方法的部分 或全部步骤。如图所示，图3是本申请实施例提供的一种文件管理方法的交互流程示意图。

其中，步骤S301～步骤S302以及步骤S308～步骤S311执行图2所述步骤中的部分或全 部内容。步骤S303～步骤S307执行上述执行端所述步骤中的部分或全部内容，在此不做过多 赘述。

可以看出，本申请实施例中，通过在executor端(执行端)各个任务执行完commitTask 方法提交操作后，在driver端(驱动端)执行将待写入数据文件移至目标目录，即执行 commitJob操作之前，***文件合并动作，通过遍历待写入数据文件，自适应的进行数据文 件的合并和合并后的删除操作，如此能够在保证数据文件正常写入目标目录的同时，减少存 储***中的文件数量，便于数据生命周期管理；同时，在driver端直接进行commitJob操作 之前执行合并操作，能够降低driver端出现OOM的概率，提升Spark任务稳定性，并且提高 用户Spark作业的执行效率。

请参阅图4，图4是本申请实施例提供了另一种文件处理方法的流程示意图，应用于文 件管理***的驱动端，如图4所示，本申请中文件管理方法包括以下操作步骤：

S401、启动主线程遍历用户目录下小文件合并工作目录，获取克隆目录。

其中，所述克隆目录由执行端通过拷贝任务目录产生，所述任务目录由所述执行端执行 任务提交操作产生。

具体地，executor端的所有任务每完成一个临时数据文件的写入，即采集对应的表分区 目录结构、文件名等基本信息，待所有的任务执行结束并提交完待写入数据文件后，在当前 用户目录下小文件合并工作目录中克隆本次提交任务的任务目录、表分区目录及对应的空数 据文件。

进一步地，驱动端并发遍历上述目录下的小文件合并工作目录的子目录，获取提交任务 所产生的任务目录的克隆目录；

S402、启动第三子Job并发遍历所述克隆目录，得到第四文件集合。

其中，所述第四文件集合包括待写入数据文件的克隆文件；

S403、解析所述第四文件集合，得到第五文件集合。

其中，所述第五文件集合包括目标待合并数据文件的真实文件。

S404、启动第四子Job对所述第五文件集合并发执行合并操作，得到第六文件集合。

S405、将所述第六文件集合依次移动到目标目录后，删除所述第五文件集合。

具体地，上述步骤S402-S405的执行步骤，与图2所描述的步骤S202-S205及其相关描 述基本类似，在此不做赘述。

通过上述全过程后，对于Spark作业来说，如果数据源分布着大量小文件，则Spark作 业在从数据源获取数据时，也会产生大量的任务，在这种情况下，每个executor会依次执行 多个任务。如果数据源是文件大小分布均衡的大数据文件，则Spark作业在从数据源获取数 据时，产生的任务数量相对会大幅减少，在这种情况下，每个executor可能只需要依次执行 少量几个任务，避免在多个task任务之间进行切换，提高数据读取效率，进而提高Spark作 业的执行效率。

如下表1所示，本申请方案在S3实际生产环境测试中，Spark作业数据读取效率的提升 情况。

表1

如表1所示内容，将本申请提出来的文件合并方法和常规未引入文件合并方法的数据文 件存储，在平均数据量和任务执行的并行度保持一致的情况下，即数量为1737216599行、并 行度为80个的情况下，分别进行数据文件写入操作。文件平均数目那一栏表明：未引入本申 请方案和使用本申请方案之后，文件平均数目减少99.2％；Spark作业总内存平均消耗减少 61.5％；Spark作业数据读取平均耗时减少62.8％。

从上述统计结果可以发现，通过引入基于Spark的动态自适应小文件合并方法来减少小 文件数量，能大幅减少Spark作业产生的小文件数量和消耗的内存及CPU资源，同时有效提 高Spark作业的数据读取效率，进而提高整个Spark作业的执行效率。

可见，本申请实施例中，基于Spark的动态自适应小文件合并方法，将小数据文件合并 的过程，深度融合到Spark作业的执行过程中，既保证了操作的原子性，还保证了数据的一 致性。同时，该小文件合并方法在使用上简单方便，适应性强，适用范围广。通过扩展Spark 原生接口，以插件方式运用到Spark作业中，使用起来简单方便。同时，能够提供简单的配 置规则供用户使用，针对不同规模的业务，适应性强、应用范围广。创新性地使用分布式文 件***中执行端保存待写入数据文件的临时文件夹来暂存小文件合并临时数据，既能避免依 赖第三方组件，也能保证良好的执行效率。

在一个可能的示例中，所述克隆目录包括至少一个子目录；所述启动第三子Job并发遍 历所述克隆目录，得到第四文件集合，包括以下步骤：所述驱动端启动所述第三子Job；所述 第三子Job并发遍历所述克隆目录，所述第三子Job通过对数据文件的路径执行过滤操作， 得到所述待写入数据文件的克隆文件；根据所述待写入数据文件的克隆文件，构建所述第四 文件集合。

具体地，driver端执行的小文件合并程序启动一个第三子Job，用于并发遍历所有克隆目 录，通过对文件路径的过滤匹配，获取所有待写入数据文件的克隆文件。其中，所述克隆文 件包括但不限于：较大的数据文件、较小的需要执行合并操作的数据文件。

可见，本申请实施例中，执行端driver对克隆目录进行并发遍历，能够在较短时间内获 取全部待写入数据文件的克隆文件，并进行下一步任务操作。

在一个可能的示例中，所述得到所述待写入数据文件的克隆文件之后，所述方法还包括 以下步骤：根据表分区目录结构对所述第四文件集合执行解析操作，得到所述待写入数据文 件的真实文件；获取所述待写入数据文件的真实文件的相关信息，其中，所述相关信息包括： 文件大小、路径以及所述待写入数据文件的真实文件对应的表分区信息。

具体地，对于得到的所有克隆文件，按照表分区目录结构对文件路径进行解析重构，获 取所有真实数据文件对应的表分区，进而得到真实数据文件的路径、文件大小及对应所属表 分区等基本信息。

可见，本申请实施例中，可以通过根据克隆文件的相关信息对其进行解析，进而能够获 取到每一个真实的数据文件对应的分区信息，进而可以根据分区信息进行后续的文件合并操 作。

在一个可能的示例中，所述得到所述待写入数据文件的真实文件之后，所述方法还包括 以下步骤：根据所述相关信息，对所述待写入数据文件的真实文件执行过滤操作，得到所述 目标待合并数据文件的真实文件；根据所述目标待合并数据文件的真实文件，构建所述第五 文件集合；根据所述表分区信息对所述第五文件集合执行分组操作，得到分组结果，其中， 所述分组结果包括至少一个分组，每一个所述分组包括相同表分区对应的所述目标待合并数 据文件的真实文件。

可见，本申请实施例中，根据映射信息进行分组操作，得到每一个目标待合并文件对应 的分组。进一步地，可以根据分组结果执行合并操作。根据分组结果进一步执行合并操作， 能够保证同一分区下的数据文件合并为同一个数据文件，提高将数据文件移动到目标目录的 执行效率。

在一个可能的示例中，所述方法还包括以下步骤：启动所述第四子Job，对所述分组结果 执行合并操作，得到所述第六文件集合，所述合并操作用于对每一个所述分组中的所述目标 待合并文件进行合并。

实际应用中，对于Spark作业，数据源分布的小文件数量越多，在从数据源获取数据时， 产生的任务数量也会更多，而数据分片信息以及对应产生的任务元信息都保存在driver端的 内存中，这就会给driver带来很大的压力，甚至引发OOM异常导致作业执行失败。

具体地，驱动端对于得到的真实数据文件的基本信息，根据配置的小文件合并规则，过 滤掉不符合文件大小阈值的数据文件，再根据表分区信息对过滤后的数据文件进行分组，将 待写入同一个表分区的数据文件进行归类聚合。

可见，本申请实施例中，根据分组结果进一步执行合并操作，能够保证同一分区下的数 据文件合并为同一个数据文件，提高将数据文件移动到目标目录的执行效率。同时，还能降 低driver出现OOM的概率，提升Spark任务稳定性。

在一个可能的示例中，所述将所述第六文件集合依次移动到目标目录之后，所述方法还 包括以下步骤：根据所述第六文件集合，生成标记文件，所述标记文件用于指示所述第六文 件集合移动完成。

可见，本申请实施例中，通过对移动完成的数据文件创建移动成功的标记文件，如此数 据消费者可以根据是否新生成了_SUCCESS标记文件来判断数据的完整性。

在一个可能的示例中，所述方法还用于文件管理***的执行端，所述方法包括以下步骤： 执行数据文件的写入操作，产生临时文件夹；对所述临时文件夹执行任务提交操作，产生任 务目录；通过拷贝所述任务目录，得到克隆目录。

具体地，执行端executor的所有任务每完成一个临时数据文件的写入，就会采集对应的 表分区目录结构、文件名等基本信息，待task任务执行结束并提交数据文件后，在当前用户 目录下小文件合并工作目录中克隆task任务目录、表分区目录及对应的空数据文件。

可见，本申请实施例中，通过执行端将待写入数据文件写入到临时文件夹中，进一步将 临时文件夹中移动到执行端的目标目录中，产生任务目录并对任务目录进行拷贝得到克隆目 录。如此，能够保证写入数据的一致性，以及驱动端可根据克隆目录来获取待存入的数据文 件。

上述主要从方法侧执行过程的角度对本申请实施例的方案进行了介绍。可以理解的是， 电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域 技术人员应该很容易意识到，结合本文中所提供的实施例描述的各示例的单元及算法步骤， 本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机 软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可 以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请 的范围。

本申请实施例可以根据上述方法示例应用于文件管理***，所述文件管理***包括驱动 端和执行端：

所述驱动端用于启动主线程遍历Job临时文件夹，获取任务目录，其中，所述任务目录 由所述执行端执行任务提交操作产生；启动第一子Job并发遍历所述任务目录，得到第一文 件集合，所述第一文件集合包括待写入数据文件；对所述第一文件集合执行过滤操作，得到 第二文件集合，所述第二文件集合包括目标待合并文件；启动第二子Job对所述第二文件集 合并发执行合并操作，得到第三文件集合；将所述第三文件集合依次移动到目标目录后，删 除所述第二文件集合；

所述执行端用于对临时文件夹执行任务提交操作，生成任务目录。

本申请实施例可以根据上述方法示例应用于另一种文件管理***，所述文件管理***包 括驱动端和执行端：

所述驱动端用于启动主线程遍历用户目录下小文件合并文件夹，获取克隆目录，其中， 所述克隆目录由执行端通过拷贝任务目录产生，所述任务目录由所述执行端执行任务提交操 作产生；启动第三子Job并发遍历所述克隆目录，得到第四文件集合，所述第四文件集合包 括待写入数据文件的克隆文件；解析所述第四文件集合，得到第五文件集合，所述第五文件 集合包括目标待合并数据文件的真实文件；启动第四子Job对所述第五文件集合并发执行合 并操作，得到第六文件集合；将所述第六文件集合依次移动到目标目录后，删除所述第五文 件集合；

所述执行端用于执行数据文件的写入操作，产生临时文件夹；对所述临时文件夹执行任 务提交操作，产生任务目录；通过拷贝任务目录，得到克隆目录。

本申请实施例可以根据上述方法示例对电子设备进行功能单元的划分，例如，可以对应 各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。上述 集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。需要说明的 是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以 有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，与图2的实施例一致，图5示出了本 申请实施例提供的一种文件管理装置的功能单元组成框图，如图5所示，该文件管理装置500， 文件管理装置500可以包括：驱动端510和执行端520，其中驱动端510包括：获取单元501、 遍历单元502、合并单元503和处理单元504，执行端520包括提交单元505。其中，

其中，获取单元501可以用于支持电子设备执行上述步骤S201和步骤S202，和/或用于 本文所描述的技术的其他过程。

遍历单元502可以用于支持电子设备执行上述步骤S203，和/或用于本文所描述的技术的 其他过程。

合并单元503可以用于支持电子设备执行上述步骤S204，和/或用于本文所描述的技术的 其他过程。

处理单元504可以用于支持电子设备执行上述步骤S205，和/或用于本文所描述的技术的 其他过程。

提交单元505可以用于支持电子设备执行对临时文件夹执行任务提交操作，生成任务目 录。

可见，在本申请实施例提供的文件管理装置，通过驱动端的获取单元启动主线程遍历由 执行端的提交单元所产生的临时文件夹，并获取任务目录；通过遍历单元启动第一子Job并 发遍历任务目录，得到第一文件集合；通过对第一文件集合执行过滤操作，得到第二文件集 合；通过合并单元对第二文件集合并发执行合并操作，得到第三文件集合后，通过处理单元 删除第二文件集合，并对移动完成的文件创建标记文件。如此，通过本申请实施例的装置， 可以实现自适应地减少存储***中的小文件数量，便于数据生命周期管理；同时还能降低驱 动端出现OOM的概率，提升Spark任务稳定性和执行效率。

与图4的实施例一致，图6示出了本申请实施例提供的另一种文件管理装置的功能单元 组成框图，如图6所示，该文件管理装置600，文件管理装置600可以包括：驱动端610和执行端620，其中驱动端610包括：启动单元601、解析单元602和处理单元603，执行端620 包括写入单元604、提交单元605和复制单元606。其中，

其中，启动单元601可以用于支持电子设备执行上述步骤S401～步骤S403，和/或用于本 文所描述的技术的其他过程。

解析单元602可以用于支持电子设备执行上述步骤S404，和/或用于本文所描述的技术的 其他过程。

处理单元603可以用于支持电子设备执行上述步骤S405，和/或用于本文所描述的技术的 其他过程。

写入单元604可以用于支持电子设备执行数据文件的写入操作，产生临时文件夹。

提交单元605可以用于支持电子设备对所述临时文件夹执行任务提交操作，产生任务目 录。

复制单元606可以用于支持电子设备拷贝任务目录，得到克隆目录。

可见，在本申请实施例提供的文件管理装置，通过驱动端的启动单元启动主线程遍历由 执行端的提交单元产生的临时文件夹，并获取克隆目录；然后，启动第三子Job并发遍历克 隆目录，得到第四文件集合；启动第四子Job对第五文件集合并发执行合并操作，得到第六 文件集合；由解析单元解析第四文件集合，得到目标待合并数据文件的真实文件；由处理单 元将第六文件集合依次移动到目标目录后，删除第五文件集合。如此，通过本申请实施例的 装置，可以实现自适应地减少存储***中的文件数量，便于数据生命周期管理；同时还能降 低驱动端出现OOM的概率，提升Spark任务稳定性和执行效率。

需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模 块的功能描述，在此不再赘述。

本实施例提供的电子设备如图2或图5所示，用于执行上述文件管理方法，因此可以达 到与上述实现方法相同的效果。

在采用集成的单元的情况下，电子设备可以包括处理模块、存储模块和通信模块。其中， 处理模块可以用于对电子设备的动作进行控制管理，例如，可以用于支持电子设备执行上述 获取单元501、遍历单元502、合并单元503和处理单元504，以及提交单元505执行的步骤。 存储模块可以用于支持电子设备执行存储程序代码和数据等。通信模块，可以用于支持电子 设备与其他设备的通信。

本实施例提供的电子设备如图4或图6所示，用于执行上述文件管理方法，因此可以达 到与上述实现方法相同的效果。

在采用集成单元的情况下，电子设备可以包括处理模块、存储模块和通信模块。其中， 处理模块可以用于对电子设备的动作进行控制管理，例如，可以用于支持电子设备执行上述 启动单元601、解析单元602和处理单元603，以及写入单元604、提交单元605和复制单元 606执行的步骤。存储模块可以用于支持电子设备执行存储程序代码和数据等。通信模块， 可以用于支持电子设备与其他设备的通信。

其中，处理模块可以是处理器或控制器。其可以实现或执行结合本申请公开内容所描述 的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一 个或多个微处理器组合，数字信号处理(digital signal processing，DSP)和微处理器的组合等 等。存储模块可以是存储器。通信模块具体可以为射频电路、蓝牙芯片、Wi-Fi芯片等与其他 电子设备交互的设备。

与上述图2所示的实施例一致的，请参阅图7，图7是本申请实施例提供的一种电子设 备的结构示意图，如图7所示，如图所示，该电子设备包括处理器、存储器、通信接口以及一个或多个可执行程序代码，其中，上述一个或多个可执行程序代码被存储在上述存储器中， 并且被配置由上述处理器执行。

在一个可能的示例中，上述程序包括用于执行以下步骤的指令：

启动主线程遍历Job临时文件夹，获取任务目录，其中，所述任务目录由所述执行端执 行任务提交操作产生；

启动第一子Job并发遍历所述任务目录，得到第一文件集合，所述第一文件集合包括待 写入数据文件；

对所述第一文件集合执行过滤操作，得到第二文件集合，所述第二文件集合包括目标待 合并文件；

启动第二子Job对所述第二文件集合并发执行合并操作，得到第三文件集合；

将所述第三文件集合依次移动到目标目录后，删除所述第二文件集合。

可以看出，本申请实施例中所描述的电子设备，通过驱动端启动主线程遍历由执行端产 生的临时文件夹，获取任务目录；启动第一子Job并发遍历任务目录，得到第一文件集合； 对第一文件集合执行过滤操作，得到第二文件集合；启动第二子Job对第二文件集合并发执 行合并操作，得到第三文件集合后，删除第二文件集合，并对移动完成的文件创建标记文件。 如此，通过本申请实施例的方案，可以实现自适应地减少存储***中的文件数量，便于数据 生命周期管理；同时还能降低驱动端出现OOM的概率，提升Spark任务稳定性和执行效率。

本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质中存储有用于电子 数据交换的计算机程序，计算机程序包括执行指令，执行指令用于执行如上述文件管理方法 实施例中记载的任何一种文件管理方法的部分或全部步骤，上述计算机包括电子终端设备。

本申请实施例提供了一种计算机程序产品，其中，计算机程序产品包括计算机程序，计 算机程序可操作来使计算机如上述方法实施例中记载的任何一种文件管理方法的部分或全部 步骤，该计算机程序产品可以是一个软件安装包。

需要说明的是，对于前述的任一种文件管理方法的实施例，为了简单描述，故将其都表 述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的 限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员 也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请 所必须的。

以上对本申请实施例进行了详细介绍，本文中应用了具体个例对本申请一种文件管理方 法及相关装置的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的 方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请一种文件管理方法及相 关装置的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不 应理解为对本申请的限制。

本申请是参照本申请实施例的方法、硬件产品和计算机程序产品的流程图和/或方框图 来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及 流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专 用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计 算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个 流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工 作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制 造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定 的功能。存储器可以包括：闪存盘、只读存储器(英文：Read-OnlyMemory，简称：ROM)、 随机存取器(英文：Random Access Memory，简称：RAM)、磁盘或光盘等。

尽管在此结合各实施例对本申请进行了描述，然而，在实施所要求保护的本申请过程中， 本领域技术人员通过查看附图、公开内容、以及所附权利要求书，可理解并实现所公开实施 例的其他变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一” 或“一个”不排除多个的情况。相互不同的从属权利要求中记载了某些措施，但这并不表示 这些措施不能组合起来产生良好的效果。

本领域普通技术人员可以理解上述任一种文件管理方法实施例的各种方法中的全部或部 分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于计算机可读存储器中， 存储器可以包括：闪存盘、只读存储器、随机存取器、磁盘或光盘等。

可以理解的是，凡是被控制或者被配置以用于执行本申请一种文件管理方法实施例所描 述的流程图的处理方法的产品，如上述流程图的装置以及计算机程序产品，均属于本申请所 描述的相关产品的范畴。

显然，本领域的技术人员可以对本申请提供的一种文件管理方法及装置进行各种改动和 变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要 求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (25)

1.一种文件管理方法，其特征在于，应用于文件管理***的驱动端；所述方法包括：

启动主线程遍历作业临时文件夹，获取任务临时目录，其中，所述任务目录由所述执行端执行任务提交操作产生；

启动第一子Job并发遍历所述任务目录，得到第一文件集合，所述第一文件集合包括待写入数据文件；

对所述第一文件集合执行过滤操作，得到第二文件集合，所述第二文件集合包括目标待合并文件；

启动第二子Job对所述第二文件集合并发执行合并操作，得到第三文件集合；

将所述第三文件集合依次移动到目标目录后，删除所述第二文件集合。

2.根据权利要求1所述的方法，其特征在于，所述任务目录包括至少一个子目录；

所述启动第一子Job并发遍历所述任务目录，得到第一文件集合，包括：

所述驱动端启动所述第一子Job；

所述第一子Job根据数据文件的命名规则，对所述至少一个子目录下数据文件进行并发遍历，得到所述待写入数据文件；

根据所述待写入数据文件，构建所述第一文件集合。

3.根据权利要求2所述的方法，其特征在于，在所述得到所述待写入数据文件之后，所述方法还包括：

根据表分区目录结构解析所述待写入数据文件的存储路径，得到映射信息表，所述映射信息表包括所述待写入数据文件名及其对应的表分区信息。

4.根据权利要求2或3所述的方法，其特征在于，所述得到所述待写入数据文件之后，所述方法还包括：

根据合并规则对所述待写入数据文件执行过滤操作，得到所述目标待合并文件，所述合并规则用于筛选不符合文件大小阈值的所述数据文件；

根据所述目标待合并文件，构建所述第二文件集合。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

根据所述映射信息表对所述第二文件集合执行分组操作，得到分组结果，其中，所述分组结果包括至少一个分组，每一个所述分组包括相同表分区对应的所述目标待合并文件；

启动所述第二子Job，对所述分组结果执行合并操作，得到所述第三文件集合，所述合并操作用于对每一个所述分组中的所述目标待合并文件进行合并。

6.根据权利要求1所述的方法，其特征在于，所述将所述第三文件集合依次移动到目标目录之后，所述方法还包括：

根据所述第三文件集合，生成标志信息文件，所述标志信息文件用于指示所述第三文件集合移动完成。

7.一种文件管理方法，其特征在于，应用于文件管理***的执行端；所述方法包括：

对临时文件夹执行任务提交操作，生成任务目录。

8.根据权利要求7所述的方法，其特征在于，所述对所述临时文件夹执行任务提交操作之前，所述方法还包括：

在用户目录下，对数据文件及所属分区目录执行克隆操作，生成临时目录和文件；

在任务数据文件及所属目录全部完成克隆后，执行所述任务提交操作。

9.一种文件管理方法，其特征在于，应用于文件管理***的驱动端；所述方法包括：

启动主线程遍历用户目录下小文件合并工作目录，获取克隆目录，其中，所述克隆目录由执行端通过拷贝任务目录产生，所述任务目录由所述执行端执行任务提交操作产生；

启动第三子Job并发遍历所述克隆目录，得到第四文件集合，所述第四文件集合包括待写入数据文件的克隆文件；

解析所述第四文件集合，得到第五文件集合，所述第五文件集合包括目标待合并数据文件的真实文件；

启动第四子Job对所述第五文件集合并发执行合并操作，得到第六文件集合；

将所述第六文件集合依次移动到目标目录后，删除所述第五文件集合。

10.根据权利要求9所述的方法，其特征在于，所述克隆目录包括至少一个子目录；

所述启动第三子Job并发遍历所述克隆目录，得到第四文件集合，包括：

所述驱动端启动所述第三子Job；

所述第三子Job并发遍历所述克隆目录，

所述第三子Job通过对数据文件的路径执行过滤操作，得到所述待写入数据文件的克隆文件；

根据所述待写入数据文件的克隆文件，构建所述第四文件集合。

11.根据权利要求10所述的方法，其特征在于，所述得到所述待写入数据文件的克隆文件之后，所述方法还包括：

根据表分区目录结构对所述第四文件集合执行解析操作，得到所述待写入数据文件的真实文件；

获取所述待写入数据文件的真实文件的相关信息，其中，所述相关信息包括：文件大小、路径以及所述待写入数据文件的真实文件对应的表分区信息。

12.根据权利要求11所述的方法，其特征在于，所述得到所述待写入数据文件的真实文件之后，所述方法还包括：

根据所述相关信息，对所述待写入数据文件的真实文件执行过滤操作，得到所述目标待合并数据文件的真实文件；

根据所述目标待合并数据文件的真实文件，构建所述第五文件集合；

根据所述表分区信息对所述第五文件集合执行分组操作，得到分组结果，其中，所述分组结果包括至少一个分组，每一个所述分组包括相同表分区对应的所述目标待合并数据文件的真实文件。

13.根据权利要求12所述的方法，其特征在于，所述方法还包括：

启动所述第四子Job，对所述分组结果执行合并操作，得到所述第六文件集合，所述合并操作用于对每一个所述分组中的所述目标待合并文件进行合并。

14.根据权利要求9所述的方法，其特征在于，所述将所述第六文件集合依次移动到目标目录之后，所述方法还包括：

根据所述第六文件集合，生成标志信息，所述标志信息用于指示所述第六文件集合移动完成。

15.一种文件管理方法，其特征在于，应用于文件管理***的执行端；所述方法包括：

执行数据文件的写入操作，产生临时文件夹；

对所述临时文件夹执行任务提交操作，产生任务目录；

通过拷贝所述任务目录，得到克隆目录。

16.一种文件管理***，其特征在于，所述文件管理***包括驱动端和执行端：

所述驱动端用于启动主线程遍历Job临时文件夹，获取任务目录，其中，所述任务目录由所述执行端执行任务提交操作产生；启动第一子Job并发遍历所述任务目录，得到第一文件集合，所述第一文件集合包括待写入数据文件；对所述第一文件集合执行过滤操作，得到第二文件集合，所述第二文件集合包括目标待合并文件；启动第二子Job对所述第二文件集合并发执行合并操作，得到第三文件集合；将所述第三文件集合依次移动到目标目录后，删除所述第二文件集合；

所述执行端用于对临时文件夹执行任务提交操作，生成任务目录。

17.一种文件管理***，其特征在于，所述文件管理***包括驱动端和执行端：

所述驱动端用于启动主线程遍历用户目录下小文件合并文件夹，获取克隆目录，其中，所述克隆目录由执行端通过拷贝任务目录产生，所述任务目录由所述执行端执行任务提交操作产生；启动第三子Job并发遍历所述克隆目录，得到第四文件集合，所述第四文件集合包括待写入数据文件的克隆文件；解析所述第四文件集合，得到第五文件集合，所述第五文件集合包括目标待合并数据文件的真实文件；启动第四子Job对所述第五文件集合并发执行合并操作，得到第六文件集合；将所述第六文件集合依次移动到目标目录后，删除所述第五文件集合；

所述执行端用于执行数据文件的写入操作，产生临时文件夹；对所述临时文件夹执行任务提交操作，产生任务目录；通过拷贝任务目录，得到克隆目录。

18.一种文件管理装置，其特征在于，应用于文件管理***的驱动端，所述装置包括：

获取单元，用于所述驱动端启动主线程遍历临时目录，获取执行端执行任务提交操作产生的任务目录；

所述获取单元，还用于所述主线程启动第一子Job遍历所述任务目录，获取第一文件集合；

遍历单元，用于遍历所述第一文件集合，得到第二文件集合，所述第二文件集合包括一个或多个待合并文件；

合并单元，用于所述主线程启动第二子Job对所述一个或多个待合并文件执行合并操作，得到第三文件集合；

处理单元，用于将所述第三文件集合移动到目标目录后，删除所述第二文件集合。

19.一种文件管理装置，其特征在于，应用于文件管理***的执行端，所述装置包括：

提交单元，用于对临时文件夹执行任务提交操作，生成任务目录。

20.一种文件管理装置，其特征在于，应用于文件管理***的驱动端，所述装置包括：

启动单元，用于启动主线程遍历用户目录下小文件合并工作目录，获取克隆目录，其中，所述克隆目录由执行端通过拷贝任务目录产生，所述任务目录由所述执行端执行任务提交操作产生；

所述启动单元，还用于启动第三子Job并发遍历所述克隆目录，得到第四文件集合，所述第四文件集合包括待写入数据文件的克隆文件；

所述启动单元，还用于启动第四子Job对所述第五文件集合并发执行合并操作，得到第六文件集合；

解析单元，用于解析所述第四文件集合，得到第五文件集合，所述第五文件集合包括目标待合并数据文件的真实文件；

处理单元，用于将所述第六文件集合依次移动到目标目录后，删除所述第五文件集合。

21.一种文件管理装置，其特征在于，应用于文件管理***的执行端，所述装置包括：

写入单元，用于执行数据文件的写入操作，产生临时文件夹；

提交单元，用于对所述临时文件夹执行任务提交操作，产生任务目录；

复制单元，通过拷贝任务目录，得到克隆目录。

22.一种电子设备，其特征在于，包括处理器、存储器、通信接口，以及一个或多个程序，所述一个或多个可执行程序代码被存储在所述存储器中，并且被配置由所述处理器执行，所述程序包括用于执行如权利要求1-6或7-8任一项所述的方法中的步骤的指令。

23.一种电子设备，其特征在于，包括处理器、存储器、通信接口，以及一个或多个程序，所述一个或多个可执行程序代码被存储在所述存储器中，并且被配置由所述处理器执行，所述程序包括用于执行如权利要求9-14或15任一项所述的方法中的步骤的指令。

24.一种计算机可读存储介质，其特征在于，存储用于电子数据交换的计算机程序，其中，所述计算机程序使得计算机执行如权利要求1-6或7-8任一项所述的方法。

25.一种计算机可读存储介质，其特征在于，存储用于电子数据交换的计算机程序，其中，所述计算机程序使得计算机执行如权利要求9-14或15任一项所述的方法。

Images