CN111488323A

CN111488323A - 一种数据处理方法、装置及电子设备

Info

Publication number: CN111488323A
Application number: CN202010288545.2A
Authority: CN
Inventors: 赵焕芳; 刘宇帅; 杜锐; 苏新锋; 薛飞; 牛向远
Original assignee: Agricultural Bank of China
Current assignee: Agricultural Bank of China
Priority date: 2020-04-14
Filing date: 2020-04-14
Publication date: 2020-08-04
Anticipated expiration: 2040-04-14
Also published as: CN111488323B

Abstract

本发明提供了一种数据处理方法、装置及电子设备，获取待进行数据合并处理的数据表的工作模式，依据所述工作模式确定待进行数据合并处理的目标文件，对所述目标文件进行数据合并处理。通过本发明可以对文件进行合并操作，可以减少小文件的数量，进而提高SparkSQL的检索效率和并发处理任务的能力，提升系统的整体查询效率及可用性。

Description

一种数据处理方法、装置及电子设备

技术领域

本发明涉及数据处理领域，更具体的说，涉及一种数据处理方法、装置及电子设备。

背景技术

随着信息技术IT应用系统的数据量的迅速增长，在海量数据检索应用中，分布式检索框架SparkSQL作为一种当前主流的大数据检索方法被广泛的使用，Hive是基于Hadoop之上的数据仓库处理工具，通过使用类结构化查询语言SQL的语言实现Hadoop中数据的查询，所有Hive的数据都存储在Hadoop的分布式文件系统HDFS(Hadoop DistributedFileSystem)中。SparkSQL提供了与Hive交互的数据查询接口，能够实现高效数据查询。

随着数据量的持续增长以及对文件加载延迟的要求不断提高，HDFS中过多的小文件会降低SparkSQL的检索效率和并发处理任务的能力，当小文件数量过多时，将会直接影响系统的整体查询效率及可用性。

发明内容

有鉴于此，本发明提供一种数据处理方法、装置及电子设备，以解决HDFS中过多的小文件会降低SparkSQL的检索效率和并发处理任务的能力，当小文件数量过多时，将会直接影响系统的整体查询效率及可用性的问题。

为解决上述技术问题，本发明采用了如下技术方案：

一种数据处理方法，包括：

获取待进行数据合并处理的数据表的工作模式；

依据所述工作模式确定待进行数据合并处理的目标文件；

对所述目标文件进行数据合并处理。

优选地，若所述工作模式包括全量模式，依据所述工作模式确定待进行数据合并处理的目标文件，包括：

确定所述数据表是否存在分区；

若不存在分区，将所述数据表对应的所有文件作为所述目标文件；

若存在分区，分别将所述数据表中每一分区对应的所有文件作为所述目标文件。

优选地，若所述工作模式包括增量模式，所述依据所述工作模式确定待进行数据合并处理的目标文件，包括：

将所述数据表中新增数据所在的分区对应的文件作为所述目标文件。

优选地，若所述工作模式包括镜像表模式，所述依据所述工作模式确定待进行数据合并处理的目标文件，包括：

依据预设镜像表，确定所述数据表中的新增数据对应的多个目标分区；所述目标分区为所述数据表中与所述预设镜像表的数据分区对应的已有分区；

将所述新增数据中对应每一所述目标分区的数据对应的文件，以及所述目标分区对应的原有文件作为所述目标文件。

优选地，所述对所述目标文件进行数据合并处理，包括：

获取预设合并文件数量；

依据所述预设合并文件数量，确定每一合并后的单文件的大小；

依据每一合并后的单文件的大小，对所述目标文件进行数据合并处理；

或，获取预设合并后的单文件的文件大小；

依据所述预设合并后的单文件的文件大小，确定合并后的文件的数量；

依据所述合并后的文件的数量，对所述目标文件进行数据合并处理；

或，获取当前可用资源、所述目标文件的大小以及数量；

依据所述当前可用资源、所述目标文件的大小以及数量，计算每一合并后的单文件的文件大小；

依据每一合并后的单文件的文件大小，对所述目标文件进行数据合并处理。

优选地，在所述对所述目标文件进行数据合并处理之前，还包括：

从所述目标文件中筛选出文件大小不符合预设大小的目标文件，并作为新的目标文件。

优选地，在所述对所述目标文件进行数据合并处理之后，还包括：

依据数据合并处理的结果，更新所述数据表。

一种数据处理装置，包括：

模式获取模块，用于获取待进行数据合并处理的数据表的工作模式；

文件确定模块，用于依据所述工作模式确定待进行数据合并处理的目标文件；

合并处理模块，用于对所述目标文件进行数据合并处理。

优选地，若所述工作模式包括全量模式，所述文件确定模块包括：

分区确定子模块，用于确定所述数据表是否存在分区；

文件确定子模块，用于若不存在分区，将所述数据表对应的所有文件作为所述目标文件；若存在分区，分别将所述数据表中每一分区对应的所有文件作为所述目标文件。

一种电子设备，包括：存储器和处理器；

其中，所述存储器用于存储程序；

处理器调用程序并用于：

获取待进行数据合并处理的数据表的工作模式；

依据所述工作模式确定待进行数据合并处理的目标文件；

对所述目标文件进行数据合并处理。

相较于现有技术，本发明具有以下有益效果：

附图说明

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

图1为本发明实施例提供的一种数据处理方法的方法流程图；

图2为本发明实施例提供的另一种数据处理方法的方法流程图；

图3为本发明实施例提供的再一种数据处理方法的方法流程图；

图4为本发明实施例提供的又一种数据处理方法的方法流程图；

图5为本发明实施例提供的一种数据处理装置的结构示意图。

具体实施方式

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

现在使用SparkSQL进行检索时，计算引擎Spark底层驱动会获取被检索文件的元数据并进行缓存，以此来生成Spark任务分发到集群的各个节点上执行。在工程实际应用中，为了使加载的数据能够尽快地被SparkSQL检索到，往往数据积累过程与新文件的生成同时进行，这种加载方法使得SparkSQL检索的文件容量较小、而文件数量又往往过多。这造成的问题是非常严重的：首先，在数据检索过程中，Spark要读取所有待检索的文件元数据，并将其在Spark Driver进程内存中进行缓存。此时如单个待检索文件过大就造成单个SparkSQL检索任务占用的内存过大，而服务器的物理内存是有限的，单任务内存过大，将导致Spark无法进行更多的并发检索；其次如文件较小而个数很多，会导致在进行相同规模数据量的检索中会分布式读取更多的文件，在Spark Task调度和文件获取等步骤上有较大的时间开销，造成SparkSQL的检索效率较低。在此背景下，为了解决待检索单个文件大，或文件过小过多的问题，提出了本发明实施例。具体如下：

本发明实施例提供了一种数据处理方法，参照图1，可以包括：

S11、获取待进行数据合并处理的数据表的工作模式。

具体的，在该数据表对应的文件的数量过多、一应用对数据表加工完成或者按需触发该数据表时，可以对该数据表对应的文件进行合并操作。如数据合并引擎启动HIVE元数据监测任务，实时监测元数据中各表的小文件数量情况，当文件的数量过多时，进行数据合并。

对于一数据表，该数据表的工作模式是固定的，工作模式包括全量模式、增量模式和镜像表模式。

本发明支持全量、增量及镜像数据表模式下的数据合并。对于不同的工作模式，在进行数据合并时，合并的目标文件范围是不同的。

S12、依据所述工作模式确定待进行数据合并处理的目标文件。

具体的，目标文件是需要进行合并的数据文件，现分别介绍不同工作模式下的目标文件。

1)若所述工作模式包括全量模式，步骤S12可以包括：

确定所述数据表是否存在分区；若不存在分区，将所述数据表对应的所有文件作为所述目标文件；若存在分区，分别将所述数据表中每一分区对应的所有文件作为所述目标文件。

具体的，对于全量模式的数据表，数据合并引擎首先判断数据表是否分区，对于非分区表，非分区表对应的文件即为目标文件，直接提交文件合并任务完成合并；对于分区表，则依次读取该表各分区，每一分区对应的文件分别作为目标文件，依据获取的待合并分区列表，逐分区完成数据合并过程。

2)若所述工作模式包括增量模式，步骤S12可以包括：

在增量模式下，数据合并引擎首先对新增数据所在的指定分区对应的目标文件进行合并，然后通过HIVE分区交换功能实现新增数据所在分区与指定分区的无缝切换，从而实现对增量表的分区合并功能，并做到对上层应用使用无影响。

举例来说，若数据表以月为单位作为一个分区，2019.5.6号的文件是截止昨天的5月数据文件，2019.5.7号是截止今天最新的5月数据文件，则对5.7号的文件进行合并操作，然后将5.7号文件所在的分区与原表2019.5数据所在的分区进行分区交换，确保2019.5月所在的数据的实时更新。

但是若数据表以日为单位作为一个分区，2019.5.6号的文件作为一个分区，2019.5.7号的文件作为一个新增的分区，对新增的分区进行文件合并操作后，不需要执行分区交换操作。

3)若所述工作模式包括镜像表模式，步骤S12可以包括：

依据预设镜像表，确定所述数据表中的新增数据对应的多个目标分区；所述目标分区为所述数据表中与预设镜像表所有数据分区对应的已有分区，将所述新增数据中对应每一所述目标分区的数据对应的文件，以及所述目标分区对应的原有文件作为所述目标文件。

在镜像表模式下，数据合并引擎首先从镜像表获取表分区范围，然后依次循环实现逐分区数据合并，再通过HIVE分区交换完成所有数据合并过程。

具体的，举例来说，假设原有分区分别包括2019.1-2019.6共6个分区，新增数据中分别包括2019.5月和2019.6月的数据，则将2019.5月的数据添加到2019.5月的分区中，将2019.6月的数据添加到2019.6月的分区中。并将2019.5月和2019.6月对应的分区的文件分别作为目标文件，并进行数据合并操作。

S13、对所述目标文件进行数据合并处理。

在进行数据合并处理时，可以采用不同的数据合并策略进行数据合并操作。

本实施例中，获取待进行数据合并处理的数据表的工作模式，依据所述工作模式确定待进行数据合并处理的目标文件，对所述目标文件进行数据合并处理。通过本发明可以对文件进行合并操作，可以减少小文件的数量，进而提高SparkSQL的检索效率和并发处理任务的能力，提升系统的整体查询效率及可用性。

本实施例在SparkSql正常运行的情况下，通过将小文件合并有效地提高SparkSql运行效率，使SparkSql支持对更大规模的分布式数据进行检索。本发明方法能够减少HDFS的文件数量，降低SparkSql运行时的资源压力，提高SparkSql并发处理任务的能力，有效提升SparkSql的检索效率和可用性。本发明实施例避免了SparkSql在进行大结果集检索时可能出现的内存、CPU等资源过度消耗问题，并且较大幅度的提高了检索的响应速度，减少了检索的总耗时，符合当下大数据检索实际需求，在大数据处理领域具有很强的实用性和应用范围，具有很广泛的应用前景。

可选的，在上述任一数据处理方法的实施例的基础上，步骤S13可以有多种实现方式，如可以同时支持按文件大小、按文件数量、自适应文件大小3种策略的文件合并方法。

现分别进行介绍：

1、第一种实现方式按文件数量进行数据合并；

参照图2，步骤S13可以包括：

S21、获取预设合并文件数量。

具体的，本实施例中设定了固定的预设合并文件数量，如设定为1000个，即合并后的文件数量是固定的，如合并后一共得到1000个文件。

S22、依据所述预设合并文件数量，确定每一合并后的单文件的大小。

当已知预设合并文件数量之后，目标文件的总大小已知，将总大小/预设合并文件数量，即为每一合并后的单文件的大小。

S23、依据每一合并后的单文件的大小，对所述目标文件进行数据合并处理。

每一合并后的单文件的大小，对目标文件进行合并即可，如将10个目标文件合并成一个单文件，该单文件能够满足计算得到的单文件的大小。

2、第二种实现方式按文件大小进行数据合并；

参照图3，步骤S13可以包括：

S31、获取预设合并后的单文件的文件大小。

S32、依据所述预设合并后的单文件的文件大小，确定合并后的文件的数量。

S33、依据所述合并后的文件的数量，对所述目标文件进行数据合并处理。

具体的，按照文件大小进行数据合并与按照文件数量进行数据合并的不同是：

按照文件数量是预先设定好合并后的文件数量，根据文件数量计算单文件大小，然后进行数据合并，按照文件大小是预先设定好合并后的文件大小，根据文件大小计算合并后的文件数量，然后进行数据合并。

3、第三种实现方式按自适应文件大小进行数据合并；

参照图4，步骤S13可以包括：

S41、获取当前可用资源、所述目标文件的大小以及数量。

S42、依据所述当前可用资源、所述目标文件的大小以及数量，计算每一合并后的单文件的文件大小。

S43、依据每一合并后的单文件的文件大小，对所述目标文件进行数据合并处理。

具体的，自适应文件大小策略能够根据应用当前资源情况、目标文件的大小以及数量自动设置合并文件的最佳大小，进而完成文件合并过程。

举例来说，假设有1000台机器，3000个文件，每一小文件可以是几十K大小，大文件可能有上百G，经过分析可以拆分成多个128M的文件。

以约500G大小(约1亿条记录)的数据表为例，未进行小文件合并前有约1.5万个数据文件(文件大小不均，小文件仅几十K大小，大文件可能有上百G)，基于384颗CPU，1.5T内存，每个任务可使用内存为40G的环境，测试对该表的数据加工时间超过24小时，而进行小文件合并(每个文件大小约为256M，全量合并耗时2小时左右)后，基于同样的环境同样的加工逻辑，耗时在0.5小时左右。(上述举例中具体加工耗时受数据分布、加工逻辑、资源速率等多种因素影响，同样的数据量在不同的环境及加工逻辑下处理时间可能存在一定差异)。

可选的，在本实施例的基础上，执行步骤S13之前，还可以包括：

具体的，在进行数据合并之前，待合并的单个文件的大小可能符合要求的文件大小，此时为了降低数据处理数量，这类文件可以不进行数据合并，在HDFS中遍历获取相应的文件元数据，根据文件合并策略对获取的符合文件大小的文件元数据进行剔除，将符合合并策略的小文件筛选出，并缓存至内存中。在实际应用中，对所述每一个目标文件，如目标数据表或目标分区中的数据文件大小进行分析，如该目标数据表或目标分区中数据文件大小符合要求，则跳过该目标数据表或目标分区，以减少不必要的操作，提升处理性能。

可选的，在本实施例的基础上，执行步骤S13之后，还可以包括：

依据数据合并处理的结果，更新所述数据表。

对获取到的待合并的目标文件，生成合并小文件的任务，将任务添加到并提交至Yarn上执行；小文件合并完成后，将合并的结果信息放置于待替换列表中。合并完成后重新生成一张合并后的数据表，使用rename方式替换原表，更新元数据。在文件替换后，在SparkSql中进行文件元数据缓存增量更新。具体的，待上述的目标数据表或目标分区所有处理操作均成功完成后，再依据数据合并处理的结果，更新所述数据表，避免处理中异常时对原表数据造成影响。

本实施例中，能够智能的根据文件大小、文件数量、自适应文件大小的策略合并SparkSql检索的目标文件的数量，从而降低SparkSql检索文件的资源开销，极大提升检索速度，有效整合了系统资源，提高SparkSql检索支持的任务并发数量，有效的提高了SparkSql框架的检索效率和可用性。

可选的，在上述数据处理方法的实施例的基础上，本发明的另一实施例提供了一种数据处理装置，参照图5，可以包括：

模式获取模块101，用于获取待进行数据合并处理的数据表的工作模式；

文件确定模块102，用于依据所述工作模式确定待进行数据合并处理的目标文件；

合并处理模块103，用于对所述目标文件进行数据合并处理。

可选的，在本实施例的基础上，若所述工作模式包括全量模式，所述文件确定模块可以包括：

分区确定子模块，用于确定所述数据表是否存在分区；

第一文件确定子模块，用于若不存在分区，将所述数据表对应的所有文件作为所述目标文件；若存在分区，分别将所述数据表中每一分区对应的所有文件作为所述目标文件。

可选的，在本实施例的基础上，若所述工作模式包括增量模式，所述文件确定模块可以包括：

第二文件确定子模块，用于将所述数据表中新增数据所在的分区对应的文件作为所述目标文件。

可选的，在本实施例的基础上，若所述工作模式包括镜像表模式，所述文件确定模块可以包括：

分区确定子模块，用于依据预设镜像表，确定所述数据表中的新增数据对应的多个目标分区；所述目标分区为所述数据表中与所述预设镜像表的数据分区对应的已有分区；

第三文件确定子模块，用于将所述新增数据中对应每一所述目标分区的数据对应的文件，以及所述目标分区对应的原有文件作为所述目标文件。

本实施例在SparkSql正常运行的情况下，通过将小文件合并有效地提高SparkSql运行效率，使SparkSql支持对更大规模的分布式数据进行检索。本发明方法能够减少HDFS的文件数量，降低SparkSql运行时的资源压力，提高SparkSql并发处理任务的能力，有效提升SparkSql的检索效率和可用性。本发明实施例避免了SparkSql在进行大结果集检索时可能出现的内存、CPU不足等问题，并且较大幅度的提高了检索的响应速度，减少了检索的总耗时，符合当下大数据检索实际需求，在大数据处理领域具有很强的实用性和应用范围，具有很广泛的应用前景。

需要说明的是，本实施例中的各个模块和子模块的工作过程，请参照上述实施例中的相应说明，在此不再赘述。

可选的，在上述任一数据处理装置的实施例的基础上，合并处理模块103用于对所述目标文件进行数据合并处理时，具体用于：

获取预设合并文件数量；

或，获取预设合并后的单文件的文件大小；

或，获取当前可用资源、所述目标文件的大小以及数量；

可选的，在本实施例的基础上，还包括：

文件筛选模块，用于合并处理模块103对所述目标文件进行数据合并处理之前，从所述目标文件中筛选出文件大小不符合预设大小的目标文件，并作为新的目标文件。

可选的，在本实施例的基础上，还包括：

数据表更新模块，用于在合并处理模块103对所述目标文件进行数据合并处理之后，依据数据合并处理的结果，更新所述数据表。

需要说明的是，本实施例中的各个模块的工作过程，请参照上述实施例中的相应说明，在此不再赘述。

可选的，在上述数据处理方法及装置的实施例的基础上，本发明的另一实施例提供了一种电子设备，包括：存储器和处理器；

其中，所述存储器用于存储程序；

处理器调用程序并用于：

获取待进行数据合并处理的数据表的工作模式；

依据所述工作模式确定待进行数据合并处理的目标文件；

对所述目标文件进行数据合并处理。

本实施例在SparkSql正常运行的情况下，通过将小文件合并有效地提高SparkSql运行效率，使SparkSql支持对更大规模的分布式数据进行检索。本发明方法能够减少HDFS的文件数量，降低SparkSql运行时的资源压力，提高SparkSql并发处理任务的能力，有效提升SparkSql的检索效率和可用性。本发明实施例避免了SparkSql在进行大结果集检索时可能出现的内存、CPU过度消耗等问题，并且较大幅度的提高了检索的响应速度，减少了检索的总耗时，符合当下大数据检索实际需求，在大数据处理领域具有很强的实用性和应用范围，具有很广泛的应用前景。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims

1.一种数据处理方法，其特征在于，包括：

获取待进行数据合并处理的数据表的工作模式；

依据所述工作模式确定待进行数据合并处理的目标文件；

对所述目标文件进行数据合并处理。

2.根据权利要求1所述的数据处理方法，其特征在于，若所述工作模式包括全量模式，依据所述工作模式确定待进行数据合并处理的目标文件，包括：

确定所述数据表是否存在分区；

3.根据权利要求1所述的数据处理方法，其特征在于，若所述工作模式包括增量模式，所述依据所述工作模式确定待进行数据合并处理的目标文件，包括：

4.根据权利要求1所述的数据处理方法，其特征在于，若所述工作模式包括镜像表模式，所述依据所述工作模式确定待进行数据合并处理的目标文件，包括：

5.根据权利要求1所述的数据处理方法，其特征在于，所述对所述目标文件进行数据合并处理，包括：

获取预设合并文件数量；

或，获取预设合并后的单文件的文件大小；

或，获取当前可用资源、所述目标文件的大小以及数量；

6.根据权利要求1所述的数据处理方法，其特征在于，在所述对所述目标文件进行数据合并处理之前，还包括：

7.根据权利要求1所述的数据处理方法，其特征在于，在所述对所述目标文件进行数据合并处理之后，还包括：

依据数据合并处理的结果，更新所述数据表。

8.一种数据处理装置，其特征在于，包括：

合并处理模块，用于对所述目标文件进行数据合并处理。

9.根据权利要求8所述的数据处理装置，其特征在于，若所述工作模式包括全量模式，所述文件确定模块包括：

分区确定子模块，用于确定所述数据表是否存在分区；

10.一种电子设备，其特征在于，包括：存储器和处理器；

其中，所述存储器用于存储程序；

处理器调用程序并用于：

获取待进行数据合并处理的数据表的工作模式；

依据所述工作模式确定待进行数据合并处理的目标文件；

对所述目标文件进行数据合并处理。