CN110321329A - 基于大数据的数据处理方法及装置 - Google Patents
基于大数据的数据处理方法及装置 Download PDFInfo
- Publication number
- CN110321329A CN110321329A CN201910525331.XA CN201910525331A CN110321329A CN 110321329 A CN110321329 A CN 110321329A CN 201910525331 A CN201910525331 A CN 201910525331A CN 110321329 A CN110321329 A CN 110321329A
- Authority
- CN
- China
- Prior art keywords
- file
- data
- numerical value
- preset reference
- data cleansing
- 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.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
- G06F16/119—Details of migration of file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
- G06F16/162—Delete operations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/1737—Details of further file system functions for reducing power consumption or coping with limited storage space, e.g. in mobile devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请实施例提供一种基于大数据的数据处理方法及装置，方法包括：对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件；根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，其中，每个组合中的所有第一目标文件的文件大小的和不超过第一预设基准数值且组合的个数为所有可能的个数中的最小值；将每个排列组合中的所有第一目标文件进行文件合并，得到第二目标文件，其中，所述第二目标文件对应设置有一个分布式文件***的数据块；本申请能够使海量数据的存储效率更高、资源分配更加合理以及后续计算性能更优。
Description
技术领域
本申请涉及数据处理领域，具体涉及一种基于大数据的数据处理方法及装置。
背景技术
Hadoop是一个由Apache基金会所开发的分布式***基础架构，用户可以在不了解分布式底层细节的情况下，开发分布式程序，进而能够充分利用集群的整体性进行高速运算和存储，Hadoop的框架最核心的设计就是：HDFS(Hadoop Distributed File System，分布式文件***)和MapReduce。HDFS为海量的数据提供了存储，而MapReduce则为海量的数据提供了计算。
相关技术中对数据进行文件存储时的存储效率较低，数据量较小的文件也占用了一个单独的HDFS数据块，资源分配不合理，使得整个HDFS集群具有的数据块数量过多，影响了后续数据计算的运算效率。
因此，亟需一种基于大数据的数据处理方法及装置，以解决相关技术中文件存储效率较低，资源分配不合理，影响后续数据计算的运算效率的技术问题。
发明内容
针对现有技术中的问题，本申请提供一种基于大数据的数据处理方法及装置，能够使海量数据的存储效率更高、资源分配更加合理以及后续计算性能更优。
为解决上述技术问题，本申请提供以下技术方案：
第一方面，本申请提供一种基于大数据的数据处理方法，包括：
对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件；
根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，其中，每个组合中的所有第一目标文件的文件大小的和不超过第一预设基准数值且组合的个数为所有可能的个数中的最小值；
将每个排列组合中的所有第一目标文件进行文件合并，得到第二目标文件，其中，所述第二目标文件对应设置有一个分布式文件***的数据块。
进一步地，所述对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件，包括：
根据所述原始目标文件的文件生成时间和原始目标文件进入目标目录的文件入库时间，建立与所述目标目录对应的临时目录；
对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件；
将经过数据清洗后得到的至少一个第一目标文件存储至所述临时目录中。
进一步地，所述根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，包括：
创建存储的文件大小为第一预设基准数值的存储空间；
将一所述第一目标文件存储至所述存储空间中；
获取另一个第一目标文件，将所述另一个第一目标文件存储至已有的存储空间中，若存储失败，则重新创造一个所述存储空间并将所述另一个第一目标文件存储至所述存储空间中，重复获取另一个第一目标文件直至所有第一目标文件均存储至存储空间；
将每个存储空间中的至少一个第一目标文件作为一个组合。
进一步地，所述根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，包括：
判断所述第一目标文件的文件大小是否大于第二预设基准数值，其中，第二预设基准数值小于第一预设基准数值；
若是，则将每个大于第二预设基准数值的第一目标文件分别作为一个组合；
若否，创建存储的文件大小为第一预设基准数值的存储空间；
将一小于等于第二预设基准数值的第一目标文件存储至所述存储空间中；
获取另一个小于等于第二预设基准数值的第一目标文件，将所述另一个小于等于第二预设基准数值的第一目标文件存储至已有的存储空间中，若存储失败，则重新创造一个所述存储空间并将所述另一个小于等于第二预设基准数值的第一目标文件存储至所述存储空间中，重复获取另一个小于等于第二预设基准数值的第一目标文件直至所有小于等于第二预设基准数值的第一目标文件均存储至存储空间；
将每个存储空间中的至少一个第一目标文件作为一个组合。
进一步地，所述对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件，包括：
对所述目标目录下的原始目标文件进行数据清洗，根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比，得到至少一个所述第一目标文件。
进一步地，所述根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比，得到至少一个所述第一目标文件，包括：
根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比得到所述第一目标文件的压缩个数；
将经过数据清洗后的所述原始目标文件的文件格式转换为列式存储格式，得到至少一个所述第一目标文件，其中，所述第一目标文件的个数小于等于所述压缩个数。
进一步地，还包括：
所述第一目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间和第一目标文件对应的原始目标文件的文件生成时间对应的时间标识；
根据所述文件入库时间和所述时间标识，得到所述原始目标文件的数据录入延迟信息。
进一步地，在所述对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件之后，包括：
所述第二目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间；
判断存储所述数据块的正式目录中是否存在名称中包含所述文件入库时间的数据块；
若是，则删除所述数据块中的所有第二目标文件，并将对应的所述临时目录中经过数据清洗后形成的所述第二目标文件迁移至所述正式目录对应的数据块中。
进一步地，所述对目标目录下的原始目标文件进行数据清洗，包括：
创建数据清洗任务，并将所述数据清洗任务提交到集群的动态资源队列中；
从所述动态资源队列中获取所述数据清洗任务并根据所述数据清洗任务对目标目录下的原始目标文件进行数据清洗。
第二方面，本申请提供一种基于大数据的数据处理装置，包括：
数据清洗模块，用于对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件；
文件组合模块，用于根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，其中，每个组合中的所有第一目标文件的文件大小的和不超过第一预设基准数值且组合的个数为所有可能的个数中的最小值；
文件合并模块，用于将每个排列组合中的所有第一目标文件进行文件合并，得到第二目标文件，其中，所述第二目标文件对应设置有一个分布式文件***的数据块。
进一步地，所述数据清洗模块包括：
临时目录建立单元，用于根据所述原始目标文件的文件生成时间和原始目标文件进入目标目录的文件入库时间，建立与所述目标目录对应的临时目录；
数据清洗单元，用于对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件；
临时目录存储单元，用于将经过数据清洗后得到的至少一个第一目标文件存储至所述临时目录中。
进一步地，所述文件组合模块包括：
基准空间创建单元，用于创建存储的文件大小为第一预设基准数值的存储空间；
第一目标文件存储单元，用于将一所述第一目标文件存储至所述存储空间中；
第二目标文件存储单元，用于获取另一个第一目标文件，将所述另一个第一目标文件存储至已有的存储空间中，若存储失败，则重新创造一个所述存储空间并将所述另一个第一目标文件存储至所述存储空间中，重复获取另一个第一目标文件直至所有第一目标文件均存储至存储空间；
目标文件组合单元，用于将每个存储空间中的至少一个第一目标文件作为一个组合。
进一步地，所述文件组合模块包括：
文件大小判断单元，用于判断所述第一目标文件的文件大小是否大于第二预设基准数值，其中，第二预设基准数值小于第一预设基准数值；
文件排列组合单元，用于当判定所述第一目标文件的文件大小大于第二预设基准数值时，将每个大于第二预设基准数值的第一目标文件分别作为一个组合，若否，则根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合。
进一步地，所述数据清洗单元包括：
数据清洗子单元，用于对所述目标目录下的原始目标文件进行数据清洗，根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比，得到至少一个所述第一目标文件。
进一步地，所述数据清洗子单元包括：
压缩个数确定子单元，用于根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比得到所述第一目标文件的压缩个数；
数据格式转换子单元，用于将经过数据清洗后的所述原始目标文件的文件格式转换为列式存储格式，得到至少一个所述第一目标文件，其中，所述第一目标文件的个数小于等于所述压缩个数。
进一步地，还包括：
第一文件命名模块，用于所述第一目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间和第一目标文件对应的原始目标文件的文件生成时间对应的时间标识；
延迟监控模块，用于根据所述文件入库时间和所述时间标识，得到所述原始目标文件的数据录入延迟信息。
进一步地，所述数据清洗单元包括：
第二文件命名子单元，用于所述第二目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间；
查重判断子单元，用于判断存储所述数据块的正式目录中是否存在名称中包含所述文件入库时间的数据块；
查重处理子单元，用于当判断存储所述数据块的正式目录中存在名称中包含所述文件入库时间的数据块时，删除所述数据块中的所有第二目标文件，并将对应的所述临时目录中经过数据清洗后形成的所述第二目标文件迁移至所述正式目录对应的数据块中。
进一步地，所述数据清洗模块包括：
清洗任务提交单元，用于创建数据清洗任务，并将所述数据清洗任务提交到集群的动态资源队列中；
清洗任务执行单元，用于从所述动态资源队列中获取所述数据清洗任务并根据所述数据清洗任务对目标目录下的原始目标文件进行数据清洗。
第三方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的基于大数据的数据处理方法的步骤。
第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的基于大数据的数据处理方法的步骤。
由上述技术方案可知，本申请提供一种基于大数据的数据处理方法及装置，通过对HDFS文件***中目标目录下的原始目标文件先进行数据清洗，得到第一目标文件，其中，经过数据清洗后的所述第一目标文件的文件大小不大于第一预设基准数值，但是可能存在文件大小比较小的情况，会额外占用存储资源，然后进一步根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，以使每个组合中的所有第一目标文件的文件大小的和尽可能接近第一预设基准数值，即HDFS中每个数据块的最大容量，再然后，将每个组合中的所有第一目标文件进行合并，得到一个第二目标文件，并为其对应设置有一个HDFS的数据块，以使用于存储原始目标文件的HDFS的数据块的数量最少，达到较佳的存储效率，资源分配更合理，进而提高后续数据计算的运算效率。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例中的基于大数据的数据处理方法的流程示意图之一；
图2为本申请实施例中的基于大数据的数据处理方法的流程示意图之二；
图3为本申请实施例中的基于大数据的数据处理方法的流程示意图之三；
图4为本申请实施例中的基于大数据的数据处理方法的流程示意图之四；
图5为本申请实施例中的基于大数据的数据处理方法的流程示意图之五；
图6为本申请实施例中的基于大数据的数据处理方法的流程示意图之六；
图7为本申请实施例中的基于大数据的数据处理方法的流程示意图之七；
图8为本申请实施例中的基于大数据的数据处理方法的流程示意图之八；
图9为本申请实施例中的基于大数据的数据处理装置的模块示意图之一；
图10为本申请实施例中的基于大数据的数据处理装置的模块示意图之二；
图11为本申请实施例中的基于大数据的数据处理装置的模块示意图之三；
图12为本申请实施例中的基于大数据的数据处理装置的模块示意图之四；
图13为本申请实施例中的基于大数据的数据处理装置的模块示意图之五；
图14为本申请实施例中的基于大数据的数据处理装置的模块示意图之六；
图15为本申请实施例中的基于大数据的数据处理装置的模块示意图之七；
图16为本申请实施例中的基于大数据的数据处理装置的模块示意图之八；
图17为本申请实施例中的基于大数据的数据处理装置的模块示意图之九；
图18为本申请实施例中的电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
考虑到相关技术中对数据进行文件存储时的存储效率较低，数据量较小的文件也占用了一个单独的HDFS数据块，资源分配不合理，使得整个HDFS集群具有的数据块数量过多，影响了后续数据计算的运算效率的问题，本申请提供一种基于大数据的数据处理方法及装置，通过对HDFS文件***中目标目录下的原始目标文件先进行数据清洗，得到第一目标文件，其中，经过数据清洗后的所述第一目标文件的文件大小不大于第一预设基准数值，但是可能存在文件大小比较小的情况，会额外占用存储资源，然后进一步根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，以使每个组合中的所有第一目标文件的文件大小的和尽可能接近第一预设基准数值，即HDFS中每个数据块的最大容量，再然后，将每个组合中的所有第一目标文件进行合并，得到一个第二目标文件，并为其对应设置有一个HDFS的数据块，以使用于存储原始目标文件的HDFS的数据块的数量最少，达到较佳的存储效率，资源分配更合理，进而提高后续数据计算的运算效率。
为了能够使海量数据的存储效率更高、资源分配更加合理以及后续计算性能更优，本申请提供一种基于大数据的数据处理方法的实施例，参见图1，所述基于大数据的数据处理方法具体包含有如下内容：
步骤S101：对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件。
可以理解的是，数据采集来后首先会存储至HDFS中，HDFS建立目标目录用于存储所述原始目标文件，优选地，所述HDFS每隔一分钟建立一个目标目录，用于存储该一分钟内入库的原始目标文件。
作为一种优选的实施方式，所述目标目录的目录结构可以包含建立该目录时的时间和对应的机房编号，例如目录结构为“/hadoop/accesslog/${1分钟目录}/${机房id}”，对应的具体示例为“/hadoop/accesslog/201806280955/1034”。
可以理解的是，可以通过现有的大数据计算引擎来执行对目标目录中的原始目标文件的数据清洗工作，例如使用Spark引擎，在向所述Spark引擎输入要执行的数据清洗任务时，还可以同时输入能够控制清洗输出结果的关键参数，例如收敛参数，以此确定清洗后的第一目标文件的大致的文件大小和文件数量。
具体地，确定收敛参数的目的是为了初步解决数据清洗后生成的小文件问题，收敛参数的计算过程为：
(1)确定原始目标文件经过数据清洗后期望的文件大小A，优选的，该期望的文件大小的取值可以为第一预设基准数值，获取目标目录下所有待清洗的原始目标文件的文件大小的和B；
(2)确定数据清洗时文件格式发生转换所对应的数据压缩比C，并根据收敛参数计算公式确定收敛参数，所述收敛参数计算公式可以为：B/(A/C)，例如，确定原始目标文件经过数据清洗后期望的文件大小为120M(接近一个HDFS的数据块的容量上限)，目标目录下所有待清洗的原始目标文件的文件大小的和为2400M，数据清洗时文件格式由TXT格式转换为了ORC格式，且TXT格式与ORC格式之间的数据压缩比已知，为0.25，则由收敛参数计算公式可知对应的收敛参数为：2400/(120/0.25)＝5，此时原始目标文件经过数据清洗后大致能够生成5个第一目标文件，且每个第一目标文件的文件大小不超过120M。
步骤S102：根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，其中，每个组合中的所有第一目标文件的文件大小的和不超过第一预设基准数值且组合的个数为所有可能的个数中的最小值。
可以理解的是，为了进一步解决第一目标文件的小文件的问题，可以使用装箱算法对小文件进行合并，所述小文件的判断依据可以为小于第二预设基准数值，例如，HDFS中每个数据块的容量上限为128M，第二预设基准数值可取80M。由于在HDFS中每个数据块的容量上限为128M，即低于128M的文件会占用1个数据块，而高于128M的文件理论上占用的数据块的数量为：(文件大小/128)+1，但是实际上由于第一目标文件的不可分割特性，会存在一些数据块中的存储空间具有较大空闲的情况，第一目标文件的存储不合理，则HDFS集群的数据块就会较多，HDFS集群的数据块数量越多，对资源的消耗越大，对后续计算时的运算性能影响也越大，此时就需要对小文件进行有效合并，尽量减少数据块的数量。
可以理解的是，所述装箱算法的实现过程可以为：
(1)初始化：假设一个箱子(存储空间)的容量(存储空间的大小)为120M(接近Block块大小128M，合并后的文件占用空间会略微变大，存储空间的大小可根据Block块的大小灵活选取)。
(2)取文件排序：取出满足条件的第一目标文件A(20M)、B(60M)、C(65M)和D(90M)，按照文件大小降序排序，得到D(90M)、C(65M)、B(30M)和A(20M)。
(3)遍历文件，分配箱子：
a、取出第一个文件D(90M)，申请一个容量为128M的箱子E，将文件装箱，此时箱子中的文件大小为90M。
b、取出第二个文件C(65M)，尝试将文件放入第一个箱子E，如果箱子E容量不足，则申请一个新箱子F，此时新箱子F中的文件大小为65M；此处尝试将C(65M)放入第一个箱子E中时，会使箱子E中的文件大小增加到90M+65M＝155M，超出了箱子自身的128M容量，所以不可行。
c、取出第三个文件B(30M)，按照箱子申请的顺序，尝试将文件B(30M)放入第一个箱子E，如果将文件B放入箱子E后，箱子E中的文件大小为90M+30M＝120M，没有超过箱子自身的容量128M，因此可行；如果不可行，则尝试将文件B(30M)放入下一个箱子F中；如果最终也没有合适的箱子，则申请一个新箱子G，将文件B(30M)放入新箱子G中。
d、依次遍历其他所有文件，按照箱子的申请的顺序装箱，没有合适的箱子则申请新箱子，直到所有的文件都装箱。
e、过滤只有一个文件的箱子，这种无需合并。
步骤S103：将每个排列组合中的所有第一目标文件进行文件合并，得到第二目标文件，其中，所述第二目标文件对应设置有一个分布式文件***的数据块。
可以理解的是，可以使用Spark计算引擎自带的文件合并调用接口实现对多个第一目标文件的文件合并，具体地，
(1)将待合并的文件移动到合并的中间目录，目录结构为：“/中间目录/合并批次号/tmp/箱子id/文件”。
(2)使用Spark的数据源API加载箱子，每个箱子使用一个DataFrame，收敛大小(coalesce)为1。将数据保存到中间目录，目录结构：“/中间目录/合并批次号/data/文件”。
(3)将合并后的数据移动到原目录。
(4)删除合并的中间目录。
在本申请的其他实施例中，也可以采用其他第三方计算引擎来实现文件合并的功能，本申请对进行文件合并时所使用的具体方法和采用的具体第三方计算引擎不作具体限定，能够将将每个排列组合中的所有第一目标文件进行文件合并即可。
从上述描述可知，本申请实施例提供的基于大数据的数据处理方法，能够对HDFS文件***中目标目录下的原始目标文件先进行数据清洗，得到第一目标文件，其中，经过数据清洗后的所述第一目标文件的文件大小更大，文件数量更少，然后根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，以使每个组合中的所有第一目标文件的文件大小的和尽可能接近第一预设基准数值，即HDFS中每个数据块的最大容量，再然后，将每个组合中的所有第一目标文件进行合并，得到一个第二目标文件，并为其对应设置有一个HDFS的数据块，以使用于存储原始目标文件的HDFS的数据块的数量最少，达到较佳的存储效率，资源分配更合理，进而提高后续数据计算的运算效率。
为了能够有效减少目标文件的数量、提高目标文件的文件大小以及去除不相干的干扰数据，在本申请的基于大数据的数据处理方法的一实施例中，还可以具体包含有创建与目标目录对应的临时目录来进行数据清洗的步骤，参见图2，该步骤具体包含有如下内容：
步骤S201：根据所述原始目标文件的文件生成时间和原始目标文件进入目标目录的文件入库时间，建立与所述目标目录对应的临时目录。
可以理解的是，所述原始目标文件中自带有其文件生成时间，当将所述原始目标文件录入到HDFS中时，也可获知其录入的文件入库时间，例如一个原始目标文件的生成时间为2018年11月07号14点03分，其录入到HDFS中的时间为2018年11月07号14点29分，则可确定对应的目标目录可以为“src/201811071429”，其对应的临时目录可以为“accesslog/temp/201811071429/d＝181107/h＝14/m5＝05”，具体地所述临时目录中的“accesslog/temp/201811071429”与所述目标目录相对应，所述临时目录中的“d＝181107”表征文件生成时间为“2018年11月07号”，所述“h＝14”表征文件生成时间为“14点”，所述“m5＝05”表征文件生成时间为“00分至05分的5分钟时间段”。
步骤S202：对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件。
步骤S203：将经过数据清洗后得到的至少一个第一目标文件存储至所述临时目录中。
可以理解的是，所述原始目标文件经过数据清洗后生成至少一个第一目标文件，所述第一目标文件存储与所述临时目录中，具体的，例如一个原始目标文件的生成时间为2018年11月07号14点03分，其录入到HDFS中的时间为2018年11月07号14点29分，其经过数据清洗后生成有3个第一目标文件，其分别的临时目录为“accesslog/temp/201811071429/d＝181107/h＝14/m5＝05/201811071429-0.orc”、“accesslog/temp/201811071429/d＝181107/h＝14/m5＝05/201811071429-1.orc”和“accesslog/temp/201811071429/d＝181107/h＝14/m5＝05/201811071429-3.orc”。
为了能够有效减少目标文件的数量和提高目标文件的文件大小，对数据量较小的小文件进行合理的合并，以使最终占用的HDFS的数据块数量最少，后续计算效率更高，在本申请的基于大数据的数据处理方法的一实施例中，还可以具体包含有对小文件进行合并的步骤，参见图3，该步骤具体包含有如下内容：
步骤S301：创建存储的文件大小为第一预设基准数值的存储空间。
步骤S302：将一所述第一目标文件存储至所述存储空间中。
步骤S303：获取另一个第一目标文件，将所述另一个第一目标文件存储至已有的存储空间中，若存储失败，则重新创造一个所述存储空间并将所述另一个第一目标文件存储至所述存储空间中，重复获取另一个第一目标文件直至所有第一目标文件均存储至存储空间。
步骤S304：将每个存储空间中的至少一个第一目标文件作为一个组合。
可以理解的是，为了进一步解决小文件的问题，可以使用装箱算法对小文件进行合并，所述小文件的判断依据可以为小于80M的文件，由于在HDFS中每个数据块的容量上限为128M，即低于128M的文件会占用1个数据块，而高于128M的文件占用的数据块的数量为：(文件大小/128)+1，HDFS集群的数据块数量越多，对资源的消耗越大，对后续计算时的运算性能影响也越大，此时就需要对小文件进行有效合并，尽量减少数据块的数量。
可以理解的是，所述装箱算法的实现过程可以为：
(1)初始化：假设一个箱子的容量为120M(接近Block块大小128M，合并后的文件占用空间会略微变大)，即所述第一预设基准数值为120M，且设置待合并单个文件大小最大为80M。
(2)取文件排序：取出满足条件的第一目标文件A(20M)、B(60M)、C(65M)和D(90M)，按照文件大小降序排序，得到D(90M)、C(65M)、B(30M)和A(20M)。
(3)遍历文件，分配箱子：
a、取出第一个文件D(90M)，申请一个容量为128M的箱子E，将文件装箱，此时箱子中的文件大小为90M。
b、取出第二个文件C(65M)，尝试将文件放入第一个箱子E，如果箱子E容量不足，则申请一个新箱子F，此时新箱子F中的文件大小为65M；此处尝试将C(65M)放入第一个箱子E中时，会使箱子E中的文件大小增加到90M+65M＝155M，超出了箱子自身的128M容量，所以不可行。
c、取出第三个文件B(30M)，按照箱子申请的顺序，尝试将文件B(30M)放入第一个箱子E，如果将文件B放入箱子E后，箱子E中的文件大小为90M+30M＝120M，没有超过箱子自身的容量128M，因此可行；如果不可行，则尝试将文件B(30M)放入下一个箱子F中；如果最终也没有合适的箱子，则申请一个新箱子G，将文件B(30M)放入新箱子G中。
d、依次遍历其他所有文件，按照箱子的申请的顺序装箱，没有合适的箱子则申请新箱子，直到所有的文件都装箱。
e、过滤只有一个文件的箱子，这种无需合并。
在本申请的其他实施例中，所述装箱算法的实现过程也可以为：
读取目录下的小文件，将小文件移动到临时目录，设置分区数为：临时目录下文件大小之和/128M，使用coalesce传入分区数，然后使用Spark的外部数据源api将小文件合并成大文件。
在一种举例中，有4个第一目标文件的文件大小分别为：30M、60M、65M和90M；
文件总大小：30+60+65+90＝245M
则分区数＝245/128＝2
使用coalesce，合并后的文件为：
文件1＝(60M+90M)＝150M，占用2个block；
文件2＝(30M+65M)＝95M,，占用1个block。
为了能够在进行小文件合并时有针对性的进行合并，即本身数据量已经较大的文件不进行合并，或者合并后的文件大小尽可能接近但不超过HDFS一个数据块的容量上限，以使最终占用的HDFS的数据块数量最少，后续计算效率更高，在本申请的基于大数据的数据处理方法的一实施例中，还可以具体包含有对小文件进行合并时对先进行文件大小判断的步骤，参见图4，该步骤具体包含有如下内容：
步骤S401：判断所述第一目标文件的文件大小是否大于第二预设基准数值，其中，第二预设基准数值小于第一预设基准数值。
步骤S402：若是，则将每个大于第二预设基准数值的第一目标文件分别作为一个组合。
步骤S403：若否，创建存储的文件大小为第一预设基准数值的存储空间；
步骤S404：将一小于等于第二预设基准数值的第一目标文件存储至所述存储空间中。
步骤S405：获取另一个小于等于第二预设基准数值的第一目标文件，将所述另一个小于等于第二预设基准数值的第一目标文件存储至已有的存储空间中，若存储失败，则重新创造一个所述存储空间并将所述另一个小于等于第二预设基准数值的第一目标文件存储至所述存储空间中，重复获取另一个小于等于第二预设基准数值的第一目标文件直至所有小于等于第二预设基准数值的第一目标文件均存储至存储空间。
步骤S406：将每个存储空间中的至少一个第一目标文件作为一个组合。
可以理解的是，所述第二预设基准数值为小文件的文件大小判定标准，可以为80M，文件大小小于80M的第一目标文件定义为小文件，需要进行小文件合并处理，而文件大小超过80M的第一目标文件，由于自身文件大小已经足够大，与其他第一目标文件组合之后的文件大小之和往往都超过了所述第一预设基准数值，因此可以不再进行排列组合，直接将其作为一个单独的组合，在本申请的其他一些实施例中，所述第二预设基准数值(即小文件的文件大小判定标准)也可以为其他数值，本申请对所述第二预设基准数值的具体数值大小不作具体限定。
为了能够在经过数据清洗后得到的第一目标文件的文件大小和文件数量能够利于后续小文件合并时的排列组合效率，在本申请的基于大数据的数据处理方法的一实施例中，还可以具体包含有在数据清洗时输入特定参数控制输出结果的步骤，该步骤具体包含有如下内容：对所述目标目录下的原始目标文件进行数据清洗，根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比，得到至少一个所述第一目标文件。
为了能够在进行数据清洗时将原始目标文件的文件格式转换为体量更小的特定文件格式，以使后续计算效率更高，在本申请的基于大数据的数据处理方法的一实施例中，还可以具体包含有对原始目标文件进行文件格式转换的步骤，参见图5，该步骤具体包含有如下内容：
步骤S501：根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比得到所述第一目标文件的压缩个数。
步骤S502：将经过数据清洗后的所述原始目标文件的文件格式转换为列式存储格式，得到至少一个所述第一目标文件，其中，所述第一目标文件的个数小于等于所述压缩个数。
可以理解的是，确定收敛参数的目的是为了初步解决数据清洗后生成的小文件问题，收敛参数的计算过程为：
(1)确定原始目标文件经过数据清洗后期望的文件大小A，获取目标目录下所有待清洗的原始目标文件的文件大小的和B；
(2)确定数据清洗时文件格式发生转换所对应的数据压缩比C，并根据收敛参数计算公式确定收敛参数，所述收敛参数计算公式可以为：B/(A/C)，例如，确定原始目标文件经过数据清洗后期望的文件大小为120M(接近一个HDFS的数据块的容量上限)，目标目录下所有待清洗的原始目标文件的文件大小的和为2400M，数据清洗时文件格式由TXT格式转换为了ORC格式，且TXT格式与ORC格式之间的数据压缩比已知，为0.25，则由收敛参数计算公式可知对应的收敛参数为：2400/(120/0.25)＝5，此时原始目标文件经过数据清洗后大致能够生成5个第一目标文件，且每个第一目标文件的文件大小不超过120M。
具体地，ORC的全称是(Optimized Row Columnar)，ORC文件格式是一种Hadoop生态圈中的列式存储格式，它的产生早在2013年初，最初产生自Apache Hive，用于降低Hadoop数据存储空间和加速Hive查询速度。和Parquet类似，它并不是一个单纯的列式存储格式，仍然是首先根据行组分割整个表，在每一个行组内进行按列存储。ORC文件是自描述的，它的元数据使用Protocol Buffers序列化，并且文件中的数据尽可能的压缩以降低存储空间的消耗，目前也被Spark SQL、Presto等查询引擎支持，但是Impala对于ORC目前没有支持，仍然使用Parquet作为主要的列式存储格式。2015年ORC项目被Apache项目基金会提升为Apache顶级项目。ORC具有以下一些优势：
1、ORC是列式存储，有多种文件压缩方式，并且有着很高的压缩比。
2、文件是可切分(Split)的。因此，在Hive中使用ORC作为表的文件存储格式，不仅节省HDFS存储资源，查询任务的输入数据量减少，使用的MapTask也就减少了。
3、提供了多种索引，row group index、bloom filter index。
4、ORC可以支持复杂的数据结构(比如Map等)。
为了能够直观的对文件的入库时间、生成时间以及对应的入库延迟情况进行监控，在本申请的基于大数据的数据处理方法的一实施例中，还可以具体包含有根据第一目标文件的文件入库时间和文件生成时间对数据录入延迟情况进行监控的步骤，参见图6，该步骤具体包含有如下内容：
步骤S601：所述第一目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间和第一目标文件对应的原始目标文件的文件生成时间对应的时间标识。
步骤S602：根据所述文件入库时间和所述时间标识，得到所述原始目标文件的数据录入延迟信息。
可以理解的是，所述原始目标文件中自带有其文件生成时间，当将所述原始目标文件录入到HDFS中时，也可获知其录入的文件入库时间，例如一个原始目标文件的生成时间为2018年11月07号14点03分，其录入到HDFS中的时间为2018年11月07号14点29分，则可确定对应的目标目录可以为“src/201811071429”，其对应的临时目录可以为“accesslog/temp/201811071429/d＝181107/h＝14/m5＝05”，由此可知，所述原始目标文件的生成时间为“2018年11月07号14点03分”，而其数据录入的时间为“2018年11月07号14点29分”，其中产生了26分钟的录入延迟，据此本申请可以对每个原始目标文件的录入延迟情况进行监控。
为了能够在临时目录中的经过数据清洗后的文件迁移至目标目录时，预先进行文件查重，在本申请的基于大数据的数据处理方法的一实施例中，还可以具体包含有根据目标目录中的文件名称进行文件查重的步骤，参见图7，该步骤具体包含有如下内容：
步骤S701：所述第二目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间。
步骤S702：判断存储所述数据块的正式目录中是否存在名称中包含所述文件入库时间的数据块。
步骤S703：若是，则删除所述数据块中的所有第二目标文件，并将对应的所述临时目录中经过数据清洗后形成的所述第二目标文件迁移至所述正式目录。
可以理解的是，将所述临时目录的文件移动到正式的目标目录之前，即在移动文件数据之前，需要预先判断正式目录中的文件名是否以此次清洗的时间戳开头，如果存在(此处存在的原因是：第一次清洗任务失败，可能只清洗了部分数据后异常终止，本次为重新调度)，则删除正式数据目录下文件名以此次清洗的时间戳开头的文件，然后将临时目录的文件移动到正式的数据目录。这样可以保证即使重新调度，数据不会重复。
为了能够提高清洗任务的处理效率，在本申请的基于大数据的数据处理方法的一实施例中，还可以具体包含有将数据清洗任务提交集群动态资源队列进程处理的步骤，参见图8，该步骤具体包含有如下内容：
步骤S801：创建数据清洗任务，并将所述数据清洗任务提交到集群的动态资源队列中。
步骤S802：从所述动态资源队列中获取所述数据清洗任务并根据所述数据清洗任务对目标目录下的原始目标文件进行数据清洗。
可以理解的是，可以使用集群的动态资源对队列提交本次数据清洗任务，具体地，给队列分配内存和CPU资源，提供任务时指定队列名，由此可知本申请还可以实现如下技术效果：使用资源队列时，保证这个任务所需要的CPU、内存是独占的；不抢占其他任务的资源；根据队列规划集群所需要的总资源。
为了能够使海量数据的存储效率更高、资源分配更加合理以及后续计算性能更优，本申请提供一种用于实现所述基于大数据的数据处理方法的全部或部分内容的基于大数据的数据处理装置的实施例，参见图9，所述基于大数据的数据处理装置具体包含有如下内容：
数据清洗模块10，用于对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件；
文件组合模块20，用于根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，其中，每个组合中的所有第一目标文件的文件大小的和不超过第一预设基准数值且组合的个数为所有可能的个数中的最小值。
文件合并模块30，用于将每个排列组合中的所有第一目标文件进行文件合并，得到第二目标文件，其中，所述第二目标文件对应设置有一个分布式文件***的数据块。
从上述描述可知，本申请实施例提供的基于大数据的数据处理装置，能够对HDFS文件***中目标目录下的原始目标文件先进行数据清洗，得到第一目标文件，其中，经过数据清洗后的所述第一目标文件的文件大小更大，文件数量更少，然后根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，以使每个组合中的所有第一目标文件的文件大小的和尽可能接近第一预设基准数值，即HDFS中每个数据块的最大容量，再然后，将每个组合中的所有第一目标文件进行合并，得到一个第二目标文件，并为其对应设置有一个HDFS的数据块，以使用于存储原始目标文件的HDFS的数据块的数量最少，达到较佳的存储效率，资源分配更合理，进而提高后续数据计算的运算效率。
为了能够有效减少目标文件的数量、提高目标文件的文件大小以及去除不相干的干扰数据，在本申请的基于大数据的数据处理装置的一实施例中，参见图10，所述数据清洗模块10包括：
临时目录建立单元11，用于根据所述原始目标文件的文件生成时间和原始目标文件进入目标目录的文件入库时间，建立与所述目标目录对应的临时目录。
数据清洗单元12，用于对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件。
临时目录存储单元13，用于将经过数据清洗后得到的至少一个第一目标文件存储至所述临时目录中。
为了能够有效减少目标文件的数量和提高目标文件的文件大小，对数据量较小的小文件进行合理的合并，以使最终占用的HDFS的数据块数量最少，后续计算效率更高，在本申请的基于大数据的数据处理装置的一实施例中，参见图11，所述文件组合模块20包括：
基准空间创建单元21，用于创建存储的文件大小为第一预设基准数值的存储空间。
第一目标文件存储单元22，用于将一所述第一目标文件存储至所述存储空间中。
第二目标文件存储单元23，用于获取另一个第一目标文件，将所述另一个第一目标文件存储至已有的存储空间中，若存储失败，则重新创造一个所述存储空间并将所述另一个第一目标文件存储至所述存储空间中，重复获取另一个第一目标文件直至所有第一目标文件均存储至存储空间。
目标文件组合单元24，用于将每个存储空间中的至少一个第一目标文件作为一个组合。
为了能够在进行小文件合并时有针对性的进行合并，即本身数据量已经较大的文件不进行合并，或者合并后的文件大小尽可能接近但不超过HDFS一个数据块的容量上限，以使最终占用的HDFS的数据块数量最少，后续计算效率更高，在本申请的基于大数据的数据处理装置的一实施例中，参见图12，所述文件组合模块20包括：
文件大小判断单元25，用于判断所述第一目标文件的文件大小是否大于第二预设基准数值，其中，第二预设基准数值小于第一预设基准数值。
文件排列组合单元26，用于当判定所述第一目标文件的文件大小大于第二预设基准数值时，将每个大于第二预设基准数值的第一目标文件分别作为一个组合，若否，则根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合。
为了能够在经过数据清洗后得到的第一目标文件的文件大小和文件数量能够利于后续小文件合并时的排列组合效率，在本申请的基于大数据的数据处理装置的一实施例中，参见图13，所述数据清洗单元12包括：
数据清洗子单元121，用于对所述目标目录下的原始目标文件进行数据清洗，根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比，得到至少一个所述第一目标文件。
为了能够在进行数据清洗时将原始目标文件的文件格式转换为体量更小的特定文件格式，以使后续计算效率更高，在本申请的基于大数据的数据处理装置的一实施例中，参见图14，所述数据清洗子单元121包括：
压缩个数确定子单元1211，用于根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比得到所述第一目标文件的压缩个数。
数据格式转换子单元1212，用于将经过数据清洗后的所述原始目标文件的文件格式转换为列式存储格式，得到至少一个所述第一目标文件，其中，所述第一目标文件的个数小于等于所述压缩个数。
为了能够直观的对文件的入库时间、生成时间以及对应的入库延迟情况进行监控，在本申请的基于大数据的数据处理装置的一实施例中，参见图15，还包括：
第一文件命名模块40，用于所述第一目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间和第一目标文件对应的原始目标文件的文件生成时间对应的时间标识。
延迟监控模块50，用于根据所述文件入库时间和所述时间标识，得到所述原始目标文件的数据录入延迟信息。
为了能够在临时目录中的经过数据清洗后的文件迁移至目标目录时，预先进行文件查重，在本申请的基于大数据的数据处理装置的一实施例中，参见图16，所述数据清洗单元12包括：
第二文件命名子单元122，用于所述第二目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间。
查重判断子单元123，用于判断存储所述数据块的正式目录中是否存在名称中包含所述文件入库时间的数据块。
查重处理子单元124，用于当判断存储所述数据块的正式目录中存在名称中包含所述文件入库时间的数据块时，删除所述数据块中的所有第二目标文件，并将对应的所述临时目录中经过数据清洗后形成的所述第二目标文件迁移至所述正式目录。
为了能够提高清洗任务的处理效率，在本申请的基于大数据的数据处理装置的一实施例中，参见图17，所述数据清洗模块10包括：
清洗任务提交单元14，用于创建数据清洗任务，并将所述数据清洗任务提交到集群的动态资源队列中。
清洗任务执行单元15，用于从所述动态资源队列中获取所述数据清洗任务并根据所述数据清洗任务对目标目录下的原始目标文件进行数据清洗。
为了更进一步说明本方案，本申请还提供一种应用上述基于大数据的数据处理装置实现基于大数据的数据处理方法的具体应用实例，具体包含有如下内容：
随着政府和公众对网络信息安全要求的不断提高，对互联网提供方厂家对访问日志留存和访问日志查询也提出了更高的要求。根据相关的网络安全规定：网络运营者应采取检测、记录网络运行状态、网络安全事件的技术措施，并按照规定留存相关的网络日志不少于六个月，在需要对互联网网络日志留存6个月的基础诉求下，亟需一套存储效率更高，资源分配更加合理，计算性能更优的解决方案。
1、数据采集入HDFS：
根据***时间戳建HDFS目录，1分钟一个目录，后续的清洗任务是按照1分钟调度一次，来读取这个1分钟的目录，按照每分钟新建目录，可保证数据在1分钟后即可被清洗，如果按照5分钟新建目录，那至少要等待5分钟后才被处理。如果按照1小于1分钟的时间新建目录，增加了复杂度，具体地，目录结构可以为“/hadoop/accesslog/${1分钟目录}/${机房id},如：/hadoop/accesslog/201806280955/1034”。
2、数据清洗：
(1)读取HDFS的数据目录，src/分钟字符串,如src/201811071429目录，201811071429是按照数据入HDFS，根据当前的***时间戳建立的目录，***时间戳精确到分钟。
(2)清洗数据，在临时目录生成ORC格式文件，确定收敛(coalesce)参数，初步解决小文件问题。小文件目标为控制清洗后的文件大小在120M左右。具体地，收敛(coalesce)参数处理过程：
a、获取当前批次所有文件(清洗前)的总大小。
b、根据压缩比，确定收敛参数。收敛参数计算公式：总的文件大小/(120M/0.25)。例如，清洗前有1000个小文件，总的文件大小为2400M，则收敛参数为：2400/(120/0.25)＝5。清洗后的文件平均大小为：2400M/5＝120M。由于原始文件的时间可能会跨越多个时间分区(如按照5分钟分区)，如落入某个时间分区只有几条日志，那在这个分区会产生只有几条日志的小文件，特别是数据的延迟跨越很多时间分区，将会造成较多的小文件。
(3)对临时目录生成的每个文件，加上时间戳，即清洗前目录的分钟时间戳。
(4)将临时目录的文件移动到正式的数据目录，在移动数据之前，判断正式的数据目录的文件名是否以此次清洗的时间戳开头，如果存在(此处存在的原因是：第一次任务清洗失败，可能只清洗了部分数据后异常终止了，此次为重新调度)，则删除正式数据目录下文件名以此次清洗的时间戳开头的文件，然后将临时目录的文件移动到正式的数据目录。这样可以保证即使重新调度，数据不会重复。
3、合并小文件：
(1)清洗后转换为ORC格式，存储空间降低75％左右。
(2)根据每个机房不同数据源的大小，控制收敛参数(coalesce)，初步解决小文件问题。此处为清洗过程解决小文件问题，可参见前面的清洗过程。
(3)清洗后，使用装箱算法合并小文件，基于装箱算法的小文件合并，根据文件合并规则计算最优的合并方案，消耗最少的集群资源实现小文件的精准合并。
小文件的判断依据：小于80M的文件，定义为小文件，需要使用装箱算法合并。HDFS的block块大小为128M，低于128M的文件会占用1个block，高于128M占用的block块为：文件大小/128M+1。集群的block数越多，对资源的消耗越大，影响性能。小文件合并的目的就是尽量减少集群的block块数量。
小文件合并的方案有如下几种：
方案一：将目录下的所有文件进行合并
读取目录下的所有文件，分区数＝目录下文件大小之和/128M,使用coalesce或者repartition传入分区数，spark的外部数据源api将小文件合并成大文件。
存在的问题：
a、合并目录下的所有文件，数据量大，文件数多，需要非常多的资源。
b、如果使用coalesce，没有shuffle，性能要好，但是会导致合并后的数据分布不均衡，合并后的文件可能包含10M、129M的文件，占用3个block块。理想的合并结果可能是11M、128M，占2个block块。
c、如果使用repartiton，数据分布均匀，但是占用大量的网络IO、磁盘IO和CPU的资源。
方案二：使用coalesce,只合并目录下的小文件
读取目录下的小文件，将小文件移动到临时目录，分区数＝临时目录下文件大小之和/128M,使用coalesce传入分区数，spark的外部数据源api将小文件合并成大文件。
存在问题：文件大小不合理。
例如4个文件：30M 60M 65M 90M，文件总大小：30+60+65+90＝245M，分区数＝245/128＝2，使用coalesce，合并后的文件可能是这样：
文件1＝(60M+90M)＝150M,占用2个block
文件2＝(30M+65M)＝95M,占用1个block
但是观察下，发现最优化的合并方案是：
文件1＝(30M+90M)＝120M,占用1个block
文件2＝(60M+65M)＝125M,占用1个block
方案三：在方案二的基础上，使用装箱算法
实现过程如下：
a、初始化：设置箱子容量为120M(接近Block块大小128M，合并后的文件占用空间会略微变大)，设置待合并单个文件大小最大为80M。
b、取文件排序：取出满足条件的文件，按照文件大小降序排序。
c、遍历文件，分配箱子。
取出第一个文件，申请一个容量为128M的箱子，将文件装箱。
取出第二个文件，尝试将文件放入第一个箱子，如果箱子容量不足，则申请一个新箱子。
取出第三个文件，按照箱子申请的顺序，尝试将文件放入箱子，找到合适的箱子后，即返回。如果没有合适的箱子，则申请一个新箱子。
依次遍历其他所有文件，按照箱子的申请的顺序装箱，没有合适的箱子则申请新箱子，直到所有的文件都装箱。
过滤只有一个文件的箱子，这种无需合并。
d、将待合并的文件移动到合并的中间目录，目录结构为：/中间目录/合并批次号/tmp/箱子id/文件。
e、使用Spark的数据源API加载箱子，每个箱子使用一个DataFrame，收敛大小(coalesce)为1。将数据保存到中间目录，目录结构：/中间目录/合并批次号/data/文件。
f、将合并后的数据移动到原目录。
g、删除合并的中间目录。
4、使用资源对队列提交任务
主要是给队列分配内存和CPU资源，提供任务时指定队列名
(1)不使用资源队列时，任务间资源相互影响；消耗资源多的任务会抢占其他任务的资源，导致其他任务执行非常慢或者申请不到资源。
(2)使用资源队列时，保证这个任务所需要的CPU、内存是独占的；不抢占其他任务的资源；根据队列规划集群所需要的总资源。
5、数据延迟监控
文件名带上了数据入库(HDFS)时的***时间戳，可以对数据的延迟情况进行监控。
本申请的实施例还提供能够实现上述实施例中的基于大数据的数据处理方法中全部步骤的一种电子设备的具体实施方式，参见图18，所述电子设备具体包括如下内容：
处理器(processor)601、存储器(memory)602、通信接口(CommunicationsInterface)603和总线604；
其中，所述处理器601、存储器602、通信接口603通过所述总线604完成相互间的通信；所述通信接口603用于实现基于大数据的数据处理装置、在线业务***、客户端设备以及其他参与机构之间的信息传输；
所述处理器601用于调用所述存储器602中的计算机程序，所述处理器执行所述计算机程序时实现上述实施例中的基于大数据的数据处理方法中的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：
步骤S101：对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件。
步骤S102：根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，其中，每个组合中的所有第一目标文件的文件大小的和不超过第一预设基准数值且组合的个数为所有可能的个数中的最小值。
步骤S103：将每个排列组合中的所有第一目标文件进行文件合并，得到第二目标文件，其中，所述第二目标文件对应设置有一个分布式文件***的数据块。
从上述描述可知，本申请实施例提供的电子设备，能够对HDFS文件***中目标目录下的原始目标文件先进行数据清洗，得到第一目标文件，其中，经过数据清洗后的所述第一目标文件的文件大小更大，文件数量更少，然后根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，以使每个组合中的所有第一目标文件的文件大小的和尽可能接近第一预设基准数值，即HDFS中每个数据块的最大容量，再然后，将每个组合中的所有第一目标文件进行合并，得到一个第二目标文件，并为其对应设置有一个HDFS的数据块，以使用于存储原始目标文件的HDFS的数据块的数量最少，达到较佳的存储效率，资源分配更合理，进而提高后续数据计算的运算效率。
本申请的实施例还提供能够实现上述实施例中的基于大数据的数据处理方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的基于大数据的数据处理方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：
步骤S101：对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件。
步骤S102：根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，其中，每个组合中的所有第一目标文件的文件大小的和不超过第一预设基准数值且组合的个数为所有可能的个数中的最小值。
步骤S103：将每个排列组合中的所有第一目标文件进行文件合并，得到第二目标文件，其中，所述第二目标文件对应设置有一个分布式文件***的数据块。
从上述描述可知，本申请实施例提供的计算机可读存储介质，能够对HDFS文件***中目标目录下的原始目标文件先进行数据清洗，得到第一目标文件，其中，经过数据清洗后的所述第一目标文件的文件大小更大，文件数量更少，然后根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，以使每个组合中的所有第一目标文件的文件大小的和尽可能接近第一预设基准数值，即HDFS中每个数据块的最大容量，再然后，将每个组合中的所有第一目标文件进行合并，得到一个第二目标文件，并为其对应设置有一个HDFS的数据块，以使用于存储原始目标文件的HDFS的数据块的数量最少，达到较佳的存储效率，资源分配更合理，进而提高后续数据计算的运算效率。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。
上述实施例阐明的***、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
本领域技术人员应明白，本说明书的实施例可提供为方法、***或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。
本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
以上所述仅为本说明书的实施例而已，并不用于限制本说明书实施例。对于本领域技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的权利要求范围之内。
Claims (20)
1.一种基于大数据的数据处理方法，其特征在于，包括：
对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件；
根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，其中，每个组合中的所有第一目标文件的文件大小的和不超过第一预设基准数值且组合的个数为所有可能的个数中的最小值；
将每个排列组合中的所有第一目标文件进行文件合并，得到第二目标文件，其中，所述第二目标文件对应设置有一个分布式文件***的数据块。
2.根据权利要求1所述的数据处理方法，其特征在于，所述对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件，包括：
根据所述原始目标文件的文件生成时间和原始目标文件进入目标目录的文件入库时间，建立与所述目标目录对应的临时目录；
对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件；
将经过数据清洗后得到的至少一个第一目标文件存储至所述临时目录中。
3.根据权利要求1所述的数据处理方法，其特征在于，所述根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，包括：
创建存储的文件大小为第一预设基准数值的存储空间；
将一所述第一目标文件存储至所述存储空间中；
获取另一个第一目标文件，将所述另一个第一目标文件存储至已有的存储空间中，若存储失败，则重新创造一个所述存储空间并将所述另一个第一目标文件存储至所述存储空间中，重复获取另一个第一目标文件直至所有第一目标文件均存储至存储空间；
将每个存储空间中的至少一个第一目标文件作为一个组合。
4.根据权利要求1所述的数据处理方法，其特征在于，所述根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，包括：
判断所述第一目标文件的文件大小是否大于第二预设基准数值，其中，第二预设基准数值小于第一预设基准数值；
若是，则将每个大于第二预设基准数值的第一目标文件分别作为一个组合；
若否，创建存储的文件大小为第一预设基准数值的存储空间；
将一小于等于第二预设基准数值的第一目标文件存储至所述存储空间中；
获取另一个小于等于第二预设基准数值的第一目标文件，将所述另一个小于等于第二预设基准数值的第一目标文件存储至已有的存储空间中，若存储失败，则重新创造一个所述存储空间并将所述另一个小于等于第二预设基准数值的第一目标文件存储至所述存储空间中，重复获取另一个小于等于第二预设基准数值的第一目标文件直至所有小于等于第二预设基准数值的第一目标文件均存储至存储空间；
将每个存储空间中的至少一个第一目标文件作为一个组合。
5.根据权利要求2所述的数据处理方法，其特征在于，所述对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件，包括：
对所述目标目录下的原始目标文件进行数据清洗，根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比，得到至少一个所述第一目标文件。
6.根据权利要求5所述的数据处理方法，其特征在于，所述根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比，得到至少一个所述第一目标文件，包括：
根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比得到所述第一目标文件的压缩个数；
将经过数据清洗后的所述原始目标文件的文件格式转换为列式存储格式，得到至少一个所述第一目标文件，其中，所述第一目标文件的个数小于等于所述压缩个数。
7.根据权利要求1所述的数据处理方法，其特征在于，还包括：
所述第一目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间和第一目标文件对应的原始目标文件的文件生成时间对应的时间标识；
根据所述文件入库时间和所述时间标识，得到所述原始目标文件的数据录入延迟信息。
8.根据权利要求2所述的数据处理方法，其特征在于，在所述对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件之后，包括：
所述第二目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间；
判断存储所述数据块的正式目录中是否存在名称中包含所述文件入库时间的数据块；
若是，则删除所述数据块中的所有第二目标文件，并将对应的所述临时目录中经过数据清洗后形成的所述第二目标文件迁移至所述正式目录对应的数据块中。
9.根据权利要求1所述的数据处理方法，其特征在于，所述对目标目录下的原始目标文件进行数据清洗，包括：
创建数据清洗任务，并将所述数据清洗任务提交到集群的动态资源队列中；
从所述动态资源队列中获取所述数据清洗任务并根据所述数据清洗任务对目标目录下的原始目标文件进行数据清洗。
10.一种基于大数据的数据处理装置，其特征在于，包括：
数据清洗模块，用于对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件；
文件组合模块，用于根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合，其中，每个组合中的所有第一目标文件的文件大小的和不超过第一预设基准数值且组合的个数为所有可能的个数中的最小值；
文件合并模块，用于将每个排列组合中的所有第一目标文件进行文件合并，得到第二目标文件，其中，所述第二目标文件对应设置有一个分布式文件***的数据块。
11.根据权利要求10所述的数据处理装置，其特征在于，所述数据清洗模块包括：
临时目录建立单元，用于根据所述原始目标文件的文件生成时间和原始目标文件进入目标目录的文件入库时间，建立与所述目标目录对应的临时目录；
数据清洗单元，用于对目标目录下的原始目标文件进行数据清洗，得到至少一个第一目标文件；
临时目录存储单元，用于将经过数据清洗后得到的至少一个第一目标文件存储至所述临时目录中。
12.根据权利要求10所述的数据处理装置，其特征在于，所述文件组合模块包括：
基准空间创建单元，用于创建存储的文件大小为第一预设基准数值的存储空间；
第一目标文件存储单元，用于将一所述第一目标文件存储至所述存储空间中；
第二目标文件存储单元，用于获取另一个第一目标文件，将所述另一个第一目标文件存储至已有的存储空间中，若存储失败，则重新创造一个所述存储空间并将所述另一个第一目标文件存储至所述存储空间中，重复获取另一个第一目标文件直至所有第一目标文件均存储至存储空间；
目标文件组合单元，用于将每个存储空间中的至少一个第一目标文件作为一个组合。
13.根据权利要求10所述的数据处理装置，其特征在于，所述文件组合模块包括：
文件大小判断单元，用于判断所述第一目标文件的文件大小是否大于第二预设基准数值，其中，第二预设基准数值小于第一预设基准数值；
文件排列组合单元，用于当判定所述第一目标文件的文件大小大于第二预设基准数值时，将每个大于第二预设基准数值的第一目标文件分别作为一个组合，若否，则根据每个所述第一目标文件的文件大小，将所有所述第一目标文件分为多个组合。
14.根据权利要求11所述的数据处理装置，其特征在于，所述数据清洗单元包括：
数据清洗子单元，用于对所述目标目录下的原始目标文件进行数据清洗，根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比，得到至少一个所述第一目标文件。
15.根据权利要求14所述的数据处理装置，其特征在于，所述数据清洗子单元包括：
压缩个数确定子单元，用于根据所述原始目标文件的文件大小、第一预设基准数值以及数据清洗过程中文件格式转换的数据压缩比得到所述第一目标文件的压缩个数；
数据格式转换子单元，用于将经过数据清洗后的所述原始目标文件的文件格式转换为列式存储格式，得到至少一个所述第一目标文件，其中，所述第一目标文件的个数小于等于所述压缩个数。
16.根据权利要求10所述的数据处理装置，其特征在于，还包括：
第一文件命名模块，用于所述第一目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间和第一目标文件对应的原始目标文件的文件生成时间对应的时间标识；
延迟监控模块，用于根据所述文件入库时间和所述时间标识，得到所述原始目标文件的数据录入延迟信息。
17.根据权利要求11所述的数据处理装置，其特征在于，所述数据清洗单元包括：
第二文件命名子单元，用于所述第二目标文件的文件名称中包含所述原始目标文件存储至目标目录时对应的文件入库时间；
查重判断子单元，用于判断存储所述数据块的正式目录中是否存在名称中包含所述文件入库时间的数据块；
查重处理子单元，用于当判断存储所述数据块的正式目录中存在名称中包含所述文件入库时间的数据块时，删除所述数据块中的所有第二目标文件，并将对应的所述临时目录中经过数据清洗后形成的所述第二目标文件迁移至所述正式目录对应的数据块中。
18.根据权利要求10所述的数据处理装置，其特征在于，所述数据清洗模块包括：
清洗任务提交单元，用于创建数据清洗任务，并将所述数据清洗任务提交到集群的动态资源队列中；
清洗任务执行单元，用于从所述动态资源队列中获取所述数据清洗任务并根据所述数据清洗任务对目标目录下的原始目标文件进行数据清洗。
19.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至9任一项所述的基于大数据的数据处理方法的步骤。
20.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至9任一项所述的基于大数据的数据处理方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910525331.XA CN110321329A (zh) | 2019-06-18 | 2019-06-18 | 基于大数据的数据处理方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910525331.XA CN110321329A (zh) | 2019-06-18 | 2019-06-18 | 基于大数据的数据处理方法及装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110321329A true CN110321329A (zh) | 2019-10-11 |
Family
ID=68119686
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910525331.XA Pending CN110321329A (zh) | 2019-06-18 | 2019-06-18 | 基于大数据的数据处理方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110321329A (zh) |
Cited By (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110737683A (zh) * | 2019-10-18 | 2020-01-31 | 成都四方伟业软件股份有限公司 | 一种基于抽取的商业智能分析平台自动分区方法及装置 |
| CN111338780A (zh) * | 2020-02-28 | 2020-06-26 | 中国工商银行股份有限公司 | 并发文件的传输方法及装置 |
| CN111488323A (zh) * | 2020-04-14 | 2020-08-04 | 中国农业银行股份有限公司 | 一种数据处理方法、装置及电子设备 |
| CN111897493A (zh) * | 2020-07-15 | 2020-11-06 | 杭州海康威视***技术有限公司 | 存储空间管理方法、装置及电子设备、存储介质 |
| CN112035057A (zh) * | 2020-07-24 | 2020-12-04 | 武汉达梦数据库有限公司 | 一种hive文件合并的方法和装置 |
| CN112181920A (zh) * | 2020-09-24 | 2021-01-05 | 陕西天行健车联网信息技术有限公司 | 一种车联网大数据高性能压缩存储方法及*** |
| CN112231293A (zh) * | 2020-09-14 | 2021-01-15 | 杭州数梦工场科技有限公司 | 文件读取方法、装置、电子设备和存储介质 |
| CN112395252A (zh) * | 2020-10-10 | 2021-02-23 | 广州三七互娱科技有限公司 | 文件合并方法、装置及电子设备 |
| CN112948330A (zh) * | 2021-02-26 | 2021-06-11 | 拉卡拉支付股份有限公司 | 数据合并方法、装置、电子设备、存储介质及程序产品 |
| CN112965939A (zh) * | 2021-02-07 | 2021-06-15 | 中国工商银行股份有限公司 | 一种文件合并方法、装置和设备 |
| CN113111038A (zh) * | 2021-03-31 | 2021-07-13 | 北京达佳互联信息技术有限公司 | 文件存储方法、装置、服务器及存储介质 |
| CN113568877A (zh) * | 2020-04-28 | 2021-10-29 | 杭州海康威视数字技术股份有限公司 | 一种文件合并方法、装置、电子设备及存储介质 |
| CN113704811A (zh) * | 2021-07-16 | 2021-11-26 | 杭州医康慧联科技股份有限公司 | 数据价值管理方法 |
| CN113946289A (zh) * | 2021-09-23 | 2022-01-18 | 南京医基云医疗数据研究院有限公司 | 基于Spark计算引擎的文件合并方法及装置、存储介质、设备 |
| CN114706861A (zh) * | 2022-06-08 | 2022-07-05 | 天津南大通用数据技术股份有限公司 | 一种在列存储引擎中按列动态分组存储的方法 |
| CN115361374A (zh) * | 2022-07-26 | 2022-11-18 | 中电金信软件有限公司 | 文件传输方法、装置和电子设备 |
| CN115632877A (zh) * | 2022-12-01 | 2023-01-20 | 成都九洲电子信息***股份有限公司 | 一种大规模pcap数据正确性验证方法、***及存储介质 |
| CN116069741A (zh) * | 2023-02-20 | 2023-05-05 | 北京集度科技有限公司 | 文件处理方法、装置和计算机程序产品 |
| CN113568877B (zh) * | 2020-04-28 | 2024-08-02 | 杭州海康威视数字技术股份有限公司 | 一种文件合并方法、装置、电子设备及存储介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120284317A1 (en) * | 2011-04-26 | 2012-11-08 | Dalton Michael W | Scalable Distributed Metadata File System using Key-Value Stores |
| CN103500089A (zh) * | 2013-09-18 | 2014-01-08 | 北京航空航天大学 | 一种适应于Mapreduce计算模型的小文件存储*** |
| CN104133882A (zh) * | 2014-07-28 | 2014-11-05 | 四川大学 | 一种基于hdfs的小文件处理方法 |
| CN105677842A (zh) * | 2016-01-05 | 2016-06-15 | 北京汇商融通信息技术有限公司 | 基于Hadoop大数据处理技术的日志分析*** |
| CN109446165A (zh) * | 2018-10-11 | 2019-03-08 | 中盈优创资讯科技有限公司 | 大数据平台的文件合并方法及装置 |
-
2019
- 2019-06-18 CN CN201910525331.XA patent/CN110321329A/zh active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120284317A1 (en) * | 2011-04-26 | 2012-11-08 | Dalton Michael W | Scalable Distributed Metadata File System using Key-Value Stores |
| CN103500089A (zh) * | 2013-09-18 | 2014-01-08 | 北京航空航天大学 | 一种适应于Mapreduce计算模型的小文件存储*** |
| CN104133882A (zh) * | 2014-07-28 | 2014-11-05 | 四川大学 | 一种基于hdfs的小文件处理方法 |
| CN105677842A (zh) * | 2016-01-05 | 2016-06-15 | 北京汇商融通信息技术有限公司 | 基于Hadoop大数据处理技术的日志分析*** |
| CN109446165A (zh) * | 2018-10-11 | 2019-03-08 | 中盈优创资讯科技有限公司 | 大数据平台的文件合并方法及装置 |
Cited By (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110737683A (zh) * | 2019-10-18 | 2020-01-31 | 成都四方伟业软件股份有限公司 | 一种基于抽取的商业智能分析平台自动分区方法及装置 |
| CN111338780A (zh) * | 2020-02-28 | 2020-06-26 | 中国工商银行股份有限公司 | 并发文件的传输方法及装置 |
| CN111338780B (zh) * | 2020-02-28 | 2023-03-31 | 中国工商银行股份有限公司 | 并发文件的传输方法及装置 |
| CN111488323A (zh) * | 2020-04-14 | 2020-08-04 | 中国农业银行股份有限公司 | 一种数据处理方法、装置及电子设备 |
| CN111488323B (zh) * | 2020-04-14 | 2023-06-13 | 中国农业银行股份有限公司 | 一种数据处理方法、装置及电子设备 |
| CN113568877A (zh) * | 2020-04-28 | 2021-10-29 | 杭州海康威视数字技术股份有限公司 | 一种文件合并方法、装置、电子设备及存储介质 |
| CN113568877B (zh) * | 2020-04-28 | 2024-08-02 | 杭州海康威视数字技术股份有限公司 | 一种文件合并方法、装置、电子设备及存储介质 |
| CN111897493A (zh) * | 2020-07-15 | 2020-11-06 | 杭州海康威视***技术有限公司 | 存储空间管理方法、装置及电子设备、存储介质 |
| CN111897493B (zh) * | 2020-07-15 | 2023-03-10 | 杭州海康威视***技术有限公司 | 存储空间管理方法、装置及电子设备、存储介质 |
| CN112035057A (zh) * | 2020-07-24 | 2020-12-04 | 武汉达梦数据库有限公司 | 一种hive文件合并的方法和装置 |
| CN112035057B (zh) * | 2020-07-24 | 2022-06-21 | 武汉达梦数据库股份有限公司 | 一种hive文件合并的方法和装置 |
| CN112231293A (zh) * | 2020-09-14 | 2021-01-15 | 杭州数梦工场科技有限公司 | 文件读取方法、装置、电子设备和存储介质 |
| CN112181920A (zh) * | 2020-09-24 | 2021-01-05 | 陕西天行健车联网信息技术有限公司 | 一种车联网大数据高性能压缩存储方法及*** |
| CN112395252A (zh) * | 2020-10-10 | 2021-02-23 | 广州三七互娱科技有限公司 | 文件合并方法、装置及电子设备 |
| CN112965939A (zh) * | 2021-02-07 | 2021-06-15 | 中国工商银行股份有限公司 | 一种文件合并方法、装置和设备 |
| CN112948330A (zh) * | 2021-02-26 | 2021-06-11 | 拉卡拉支付股份有限公司 | 数据合并方法、装置、电子设备、存储介质及程序产品 |
| CN113111038A (zh) * | 2021-03-31 | 2021-07-13 | 北京达佳互联信息技术有限公司 | 文件存储方法、装置、服务器及存储介质 |
| CN113111038B (zh) * | 2021-03-31 | 2024-01-19 | 北京达佳互联信息技术有限公司 | 文件存储方法、装置、服务器及存储介质 |
| CN113704811A (zh) * | 2021-07-16 | 2021-11-26 | 杭州医康慧联科技股份有限公司 | 数据价值管理方法 |
| CN113946289A (zh) * | 2021-09-23 | 2022-01-18 | 南京医基云医疗数据研究院有限公司 | 基于Spark计算引擎的文件合并方法及装置、存储介质、设备 |
| CN114706861B (zh) * | 2022-06-08 | 2022-09-16 | 天津南大通用数据技术股份有限公司 | 一种在列存储引擎中按列动态分组存储的方法 |
| CN114706861A (zh) * | 2022-06-08 | 2022-07-05 | 天津南大通用数据技术股份有限公司 | 一种在列存储引擎中按列动态分组存储的方法 |
| CN115361374A (zh) * | 2022-07-26 | 2022-11-18 | 中电金信软件有限公司 | 文件传输方法、装置和电子设备 |
| CN115632877A (zh) * | 2022-12-01 | 2023-01-20 | 成都九洲电子信息***股份有限公司 | 一种大规模pcap数据正确性验证方法、***及存储介质 |
| CN115632877B (zh) * | 2022-12-01 | 2023-04-07 | 成都九洲电子信息***股份有限公司 | 一种大规模pcap数据正确性验证方法、***及存储介质 |
| CN116069741A (zh) * | 2023-02-20 | 2023-05-05 | 北京集度科技有限公司 | 文件处理方法、装置和计算机程序产品 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110321329A (zh) | 基于大数据的数据处理方法及装置 | |
| US20160299919A1 (en) | Management of Intermediate Data Spills during the Shuffle Phase of a Map-Reduce Job | |
| US8677366B2 (en) | Systems and methods for processing hierarchical data in a map-reduce framework | |
| Tao et al. | Dynamic resource allocation algorithm for container-based service computing | |
| CN102231121B (zh) | 基于内存映射的大数据文件快速并行提取方法 | |
| Ju et al. | iGraph: an incremental data processing system for dynamic graph | |
| Verma et al. | Big Data representation for grade analysis through Hadoop framework | |
| CN109144699A (zh) | 分布式任务调度方法、装置及*** | |
| CN106406987A (zh) | 一种集群中的任务执行方法及装置 | |
| Halim et al. | A MapReduce-based maximum-flow algorithm for large small-world network graphs | |
| Arnaiz-González et al. | MR-DIS: democratic instance selection for big data by MapReduce | |
| Vo et al. | A multi-core approach to efficiently mining high-utility itemsets in dynamic profit databases | |
| CN106202092A (zh) | 数据处理的方法及*** | |
| Jiang et al. | Parallel K-Medoids clustering algorithm based on Hadoop | |
| CN108415912A (zh) | 基于MapReduce模型的数据处理方法和设备 | |
| Bala et al. | P-ETL: Parallel-ETL based on the MapReduce paradigm | |
| Lee et al. | Performance improvement of mapreduce process by promoting deep data locality | |
| Li et al. | MapReduce task scheduling in heterogeneous geo-distributed data centers | |
| JP2019106031A (ja) | データ処理システム及びデータ分析処理方法 | |
| CN103324577A (zh) | 基于最小化io访问冲突和文件分条的大规模分条文件分配*** | |
| Vasiliu et al. | A hybrid scheduler for many task computing in big data systems | |
| CN109582476A (zh) | 数据处理方法、装置及*** | |
| CN103064862A (zh) | 一种多指标排序数据处理方法及设备 | |
| Rana | Integration of big data analytics and the cloud environment in harnessing valuable business insights | |
| CN104252486B (zh) | 一种数据处理的方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20191011 |