CN114528127A - 数据处理方法、装置、存储介质及电子设备 - Google Patents

Abstract

本申请实施例公开了一种数据处理方法、装置、存储介质及电子设备，其中，方法包括：通过获取数据源中的目标数据流，将目标数据流写入数据湖并同步对所述数据湖中的小数据文件进行文件合并处理。采用本申请实施例，可以提高数据处理效率。

Description

数据处理方法、装置、存储介质及电子设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据处理方法、装置、存储介质及电子设备。

背景技术

数据湖是指使用大型二进制对象或者文件格式来存储数据的系统，被用于统一存储数据，既包括原系统中的原始副本，也包括转换后的数据，如报表、可视化的数据等等。

在大数据场景下，因业务场景、数据规模的不同，存在各类大数据引擎用于处理某一领域的需求，常见的可以基于消息中间件存储诸如日志、订单、票据等数据，然后使用数据引擎消费数据并结合数据湖实现数据管理。

发明内容

本申请实施例提供了一种数据处理方法、装置、存储介质及电子设备，所述技术方案如下：

第一方面，本申请实施例提供了一种数据处理方法，所述方法包括：

获取数据源中的目标数据流；

将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，所述小数据文件为文件内存小于内存阈值的数据文件。

第二方面，本申请实施例提供了一种数据处理装置，所述装置包括：

数据获取模块，用于获取数据源中的目标数据流；

写入合并模块，用于将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，所述小数据文件为文件内存小于内存阈值的数据文件。

第三方面，本申请实施例提供一种计算机存储介质，所述计算机存储介质存储有多条指令，所述指令适于由处理器加载并执行上述的方法步骤。

第四方面，本申请实施例提供一种电子设备，可包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行上述的方法步骤。

本申请一些实施例提供的技术方案带来的有益效果至少包括：

在本申请一个或多个实施例中，通过获取数据源中的目标数据流，将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，通过采用并行执行方式将数据流写入数据湖和文件合并同步进行，可以避免数据合并量堆积，也降低了检查点阶段的数据处理压力，优化了数据流处理写入流程，大幅提高了数据处理效率。

附图说明

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

图1是本申请实施例提供的一种数据处理方法的流程示意图；

图2是本申请实施例提供的一种数据写入的场景示意图；

图3是本申请实施例提供的另一种数据处理方法的流程示意图；

图4是本申请实施例提供的一种文件合并的场景示意图；

图5是本申请实施例提供的一种数据湖性能的比对分析图；

图6是本申请实施例提供的另一种数据处理方法的流程示意图；

图7a是本申请实施例提供的一种涉及布隆过滤的性能示意图；

图7b是本申请实施例提供的一种涉及哈希过滤的性能示意图；

图7c是本申请实施例提供的一种涉及采用开源默认过滤方式的性能示意图；

图8是本申请实施例提供的另一种数据处理装置的结构示意图；

图9是本申请实施例提供的一种写入合并模块的结构示意图；

图10是本申请实施例提供的另一种数据处理装置的结构示意图；

图11是本申请实施例提供的一种写入合并模块的结构示意图；

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

具体实施方式

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

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。在本申请的描述中，需要说明的是，除非另有明确的规定和限定，“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

在相关技术中，常见的可以基于消息中间件存储诸如日志、订单、票据等数据，然后使用数据引擎消费数据并结合数据湖实现数据管理，其通常支持近实时的写入和更新，支持各种写入查询引擎如hive引擎，spark引擎，flink引擎的一种基于数据湖的数据存储架构。

目前，数据湖主要有hudi数据湖和iceberg数据湖；

1)基于Hudi数据湖的数据引擎写入方案：在消息处理阶段会对当前待写入的数据先进行缓存，在checkpoint(检查点)阶段再将数据写入到文件中。同时在数据写入处理时使用：copyOnWrite(写入时复制)的方式即直接对文件进行合并重写生成完整的新的列式存储文件，这个过程同时也完成小文件合并的功能。然后，基于Hudi数据湖的方案，首先，在处理消息时只是缓存数据，在checkpoint(检查点)期间进行写入，这样并没有最大化写入性能；其次，checkpoint(检查点)阶段同时完成数据写入和小文件合并，大量文件需要更新读写，checkpoint(检查点)阶段任务量较大，数据处理效率不高。

2)基于iceberg数据湖的数据引擎写入方案：采用流式的增量数据写入方式，在消息处理阶段直接实时的将增量数据写入到对应的列式存储文件，在checkpoint阶段只是将写入的数据进行提交修改对应的元数据文件。数据湖的数据写入处理时使用的是一种mergeOnRead的方式，也即先写入增量文件，之后再进行文件合并操作，需要多个数据处理阶段才能够完成；采用这种方式，如果长期不进行文件合并，增量文件也会较多，会有读取时间较长以及内存溢出的情况，从而造成数据处理任务量较大，数据处理效率不高。

下面结合具体的实施例对本申请进行详细说明。

在一个实施例中，如图1所示，特提出了一种数据处理方法，该方法可依赖于计算机程序实现，可运行于基于冯诺依曼体系的数据处理装置上。该计算机程序可集成在应用中，也可作为独立的工具类应用运行。所述数据处理装置可以是一种服务平台。所述服务平台可以是单独的服务器设备，例如：机架式、刀片、塔式、或者机柜式的服务器设备，或采用工作站、大型计算机等具备较强计算能力硬件设备；也可以是采用多个服务器组成的服务器集群，所述服务集群中的各服务器可以是以对称方式组成的，其中每台服务器在事务链路中功能等价、地位等价，各服务器均可单独对外提供服务，所述单独提供服务可以理解为无需另外的服务器的辅助。

具体的，该数据处理方法包括：

S101：获取数据源中的目标数据流；

可以理解的，数据源可以为业务库、埋点日志、应用平台或其他数据源。数据源中的数据可采用基于实际应用场景下的数据抽取机制来抽取，例如每天定时抽取一次。在一些实施例中，可以采用消息中间件监听数据源的Binlog，实时接入数据源的数据至消息中间件即可。埋点日志一般以文件的形式保存，可以使用Flume定时抽取，也可以用SparkStreaming或者Storm来实时接入。其它数据源具有多样性，与具体业务相关，不再赘述。

在本说明书一个或多个实施例中，服务平台从数据源中获取数据的方式通常是以数据流的形式，也即服务平台可以基于实际应用场景下的数据抽取机制来获取数据源中的目标数据流，在一些实施场景中可以基于目标数据流实现海量数据实时入数据湖，通过数据湖可以实现存储海量的不同格式的数据。

在一种可行的实施方式中，服务平台可以将客户端接收的流事务(业务)数据写入消息中间件，例如，通过HTTP接收机从客户端接收流数据。其中，客户端具体可以为个人计算机或移动端设备等电子设备上的应用或网页，流事务(业务)数据具体可以为埋点数据和用户浏览数据。然后，通过HTTP接收机可以将流事务(业务)数据写入Kafka消息中间件，例如可以通过消息中间件存储实时数据文件，其中包括日志、订单、车票等数据文件。通过流式计算引擎(如Flink、Spark)通过消息中间件消费数据以获得数据源中的流事务(业务)数据并写入数据湖中进行存储管理，也即目标数据流，目标数据通常包含若干数据文件，并通常以一组有序、有起点和终点的字节数据序列存在。

S102：将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，所述小数据文件为文件内存小于内存阈值的数据文件。

所述数据湖支持多种用于写入查询等功能的流式计算引擎引擎，流式计算引擎可以是Flink引擎、Spark引擎等等，所述数据湖可以Hudi数据湖、Iceberg数据湖等。所述数据湖主要基于Hdfs(分布式文件系统)的存储架构，支持近实时的写入和更新，所述数据湖主要使用列式存储格式：如parquet、orc格式等，数据湖具有压缩比大，存储空间小，可快速读取，适合olap分析等优点。

在本说明书一个或多个实施例中，可以实现“目标数据流写入数据湖”与“数据湖中的小数据文件进行文件合并处理”并行执行，而不必在目标数据流中若干数据文件写入数据湖之后才能够进行文件合并处理。通过本说明书的数据处理方法，可以实现诸如流式计算引擎增量写入文件数据和文件合并功能的并行执行，大幅提高数据处理效率。

在一种可行的实施方式中，可以在对目标数据流中的数据文件进行数据处理时，创建针对所述目标数据流的并行处理任务，控制流式计算引擎响应于并行处理任务，将目标数据流中的若干数据文件一边写入数据湖的表中，一边同步对数据湖中的小数据文件进行文件合并处理。这样，可以避免针对数据湖的数据增量写入和文件合并需要部署两个数据处理任务，同时如果文件合并耗时太长，以及在涉及对数据文件的检查点阶段会大概率跨越多个写入检查点提交也会导致数据错误，本说明书涉及的数据处理方法可以针对流式计算引擎部署一个数据处理任务(如针对Flink流式计算引擎部署一个用于并行处理的Flink任务)即可完成增量数据写入和文件合并，同时能不影响数据湖的读取性能。

在一种具体的实施场景中，服务平台获取目标数据流，实时将目标数据流中的数据文件逐个写入数据湖，在写入数据湖的过程中，若存在至少一个数据文件为完成写入状态，也即完成目标数据流中至少一个数据文件完成写入数据湖，针对数据湖而言相当于已经写入了增量数据，服务平台可以在已完成至少一个数据文件完成入湖(也即完成写入数据湖)时，服务平台同步对数据湖中的小数据文件进行文件合并处理。

其中，小数据文件为文件内存小于内存阈值的数据文件；

在日常应用中，诸如从个人应用中产生的日常文件到web应用中都会产生许多小文件，特别是在实际事务场景中，诸如blog、wiki、spaces的兴起导致了互联网提供内容的方式发生改变，其基于互联网的数据具有海量、多样、动态变化等等特征，这也随之会产生海量的小数据文件，如用户头像、相册微缩图等文件，日志文件，介绍信息等等，通常小数据文件可以理解为小于一定内存阈值的数据文件，内存阈值可以基于实际应用环境设置，如内存阈值可以是1M、10M等，服务平台可以通过对数据湖中的数据文件进行文件扫描可以随之确定小于内存阈值的小数据文件。

可以理解的，服务平台完成对目标数据流中至少一个数据文件的写入数据湖之后，这些“至少一个数据文件”也即为完成写入状态，在本说明书一个或多个实施例中，可以设置文件数量阈值，在已写入的数据文件达到文件数量阈值时，同步开启对数据湖中小数据文件的扫描，已确定至少一个小数据文件。

可选的，开启对数据湖中小数据文件的扫描，文件扫描对象可以是数据湖中的全部或部分数据文件；在一个或多个实施例中，对数据湖中小数据文件的扫描可以是增量扫描的方式，也即仅对目标数据流中为完成写入状态的数据文件进行小数据文件扫描。

可以理解的，同步对所述数据湖中的小数据文件进行文件合并处理可以是：通过对数据湖中相应文件进行扫描，至少确定所有需要合并的数据文件(也即小文件)，来生成文件合并任务；

在一种具体的实施场景中，数据湖存储数据文件可以视作将一批数据湖中的文件封装成至少一个有业务或事务意义的table，也即数据湖存储数据文件会对应若干数据湖表，每完成对目标数据流中至少一个数据文件的写入数据湖的分区，会对应更新数据湖表以完成对增量数据写入的记录。数据湖完成写入至少一个数据文件会提交数据湖表table。通常对数据湖中相应文件进行扫描可以通过对数据湖表进行扫描，通过同步扫描数据湖表对应的文件，以筛选出该数据湖表中所对应的需要合并的小数据文件，从而来确定文件合并任务，文件合并任务至少包括需合并的小数据文件，可以理解的，基于文件合并任务同步对所述数据湖中的小数据文件进行文件合并处理，生成至少一个新的目标合并文件。在一些实施场景中，在完成文件合并处理生成目标合并文件之后，由于已对多个小数据文件进行合并，则还包括对数据湖中过期文件(可理解为以完成合并的小数据文件)进行过滤以完成数据湖的数据文件更新。

在一种具体的实施场景中，以数据湖为Iceberg数据湖为例进一步对数据湖数据更新进行释义，数据湖每次数据更新(如增量更新)后更新相应数据湖表进行commit，commit都会生成一个快照(Snapshot)，该快照至少包含唯一的snapshotId、时间戳timestamp及对应的manifest文件。最新snapshot拥有该表(数据湖表)的全局视图，每个snapshot包含多个manifest元数据文件，每个manifest文件中记录本次事务中记录写入文件与分区的对应关系，且包含一些文件记录的统计信息，如lower_bound、upper_bound、added_rows_count、deleted_rows_count用来快速筛选文件。在一些实施场景中，可以把manifest文件可理解为索引文件。

可以理解的，数据湖基于Snapshot的特性，可以通过snapshot来访问iceberg中的数据，如果数据写入数据湖但没有commit成功，就不会生成新的snapshot，也因此不会访问到这部分不完整数据。文件在数据湖上布局，至少包括两个部分：database数据库部分和table表部分。每张表包含两个目录，第一个目录metadata保存snapshot、manifest文件；第二个目录data保存数据文件，按照分区进行划分。

示意性的，针对向数据湖写入目标数据流所包含的至少一个数据文件，可以通过至少一个用于数据写入数据湖的算子来实现。如图2所示，图2是本申请涉及的一种数据写入的场景示意图，在图2中，用于数据写入数据湖的算子至少可以包括：StreamWriter：流写入类算子、FilesCommitter：文件提交类算子。前述各算子的数量可以是多个；

示意性的，从数据源根据当前table(也即数据湖表)进行keyby操作进入StreamWriter算子；其中，keyby操作(用于流计算)不会改变数据的每个元素的数据结构，仅仅时根据key对输入数据流(也即目标数据流)涉及的若干数据文件重新划分子任务用于处理数据写入，通过若干子任务可以实现对若干数据文件的并行数据写入。

StreamWriter算子是通过table实例化的，然后构造一个taskWriterFactory，在启动写入数据的时候再实例化一个writer(可以理解为一个对象)来进行写入操作也即写入所分配的数据文件中的数据，主要用来写入记录到对应的avro、parquet、orc文件。writer启动写入源数据中的数据到数据湖，同时记录本次针对数据文件的写入操作，然后将写入结果WriteResult发送给FilesCommitter算子；写入结果WriteResult可以理解为StreamWriter算子的输出通过将目标数据流的数据文件进行变换生成该过程产生的数据(湖)文件，主要包括数据文件文件进行insert(插入数据)操作时的数据文件和进行delete删除操作时的DeleteFile。可以理解的，此时实际写入数据文件已经在数据湖中，这里写入结果WriteResult只是记录文件的元信息，例如位置、文件名等。

FilesCommitter算子接收相应的数据WriteResult，然后在checkpoint(检查点)到来时把所有的DataFile数据文件收集起来，并提交Transaction(事务)到数据湖，完成本次checkpoint的数据写入，在一些实施场景中，提交Transaction(事务)会将写入更新后的数据湖表table进行提交。示意性的，FilesCommitter从StreamWriter发送的多个WriteResult中回放数据文件，按照数据类型的不同(DAtaFile、DeleteFile)创建或更新对应类型的ManifestFile(文件列表table)用以进行提交，并将ManifestList作为快照保存在序号递增的metadata.json文件(可以理解为元数据文件)中。

示意性的，FilesCommitter算子为每个checkpointId(检查点)维护了一个DataFile文件列表，每个checkpointId(检查点)对应一个checkpointIdid(检查点标识)，这样即使中间有某个checkpoint的transaction(事务)提交或处理失败了，它的原DataFile文件仍然维护在State(数据湖的状态)中，依然可以通过后续的checkpoint回退来提交。

在一种可行的实施方式中，数据湖可以是基于Iceberg数据湖，数据处理引擎可以是Flink流式计算引擎。

可以理解的，上述过程在写入目标数据流至数据湖中是持续进行的，也即经上述流程持续不断的将目标数据流中的每个数据文件写入到数据湖中，在写入数据湖的过程中，若存在至少一个数据文件为完成写入状态，也即完成目标数据流中至少一个数据文件完成写入数据湖，针对数据湖而言相当于已经写入了增量数据但未写入完成全部的目标数据流，服务平台可以在已完成至少一个数据文件完成入湖(也即完成写入数据湖)时，基于至少一个算子同步对数据湖中的小数据文件进行文件合并处理；

在一些实施例中，将写入更新后的数据湖表table进行提交，可以生成一个(反馈)消息，消息可以至少可以包含表名信息(如数据湖表中的表名信息)和checkpointIdid(检查点标识)，该消息可以用于至少反馈在同步对数据湖文件中小数据文件扫描阶段可以基于该表名信息可以对其对应table中记录的文件进行扫描。

在本申请实施例中，通过获取数据源中的目标数据流，将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，通过采用并行执行方式将数据流写入数据湖和文件合并同步进行，可以避免数据合并量堆积，也降低了检查点阶段的数据处理压力，优化了数据流处理写入流程，大幅提高了数据处理效率。

请参见图3，图3是本申请提出的一种数据处理方法的另一种实施例的流程示意图。具体的：

S201：获取数据源中的目标数据流；

具体可参见本申请说明书其他实施例的步骤，此处不再赘述。

S202：将所述目标数据流中所有数据文件分别写入数据湖；

具体可参见本申请说明书其他实施例的步骤，此处不再赘述。

S203：若存在至少一个所述数据文件为完成写入状态，则确定至少一个数据处理算子，通过所述数据处理算子确定文件合并任务；

所述至少一个数据处理算子用于同步对数据湖中的小数据文件进行文件合并处理，数据处理算子的数量可以是多个；各数据处理算子的类型可以不同，以用户完成不同的计算处理指令。

例如，算子可以预先参照任务分配工作或处理类别可以包括各种类型的算子，如scan(扫描)算子、filter(过滤)算子、hash(哈希)算子(用于hash join和聚合)、sort(分类)算子、input(输入)算子、output(输出)算子、join(加入)算子、agg(聚合)算子。当然，上述只是算子类型的几个示例，还可以有其它类型的算子，对此不做限制。

在一种可行的实施方式中，通过所述数据处理算子确定文件合并任务可以至少包括第一处理算子、第二处理算子以及第三处理算子。第一处理算子可以是用于文件扫描、任务生成，例如第一处理算子可以是FileScanTasks，第一处理算子为文件扫描/任务生成类算子；第二处理算子用于文件合并，读取数据写入新合并的文件，例如第二处理算子可以是RowDataRewriter，用于行数据改写或，数据文件合并；第三处理算子用于小文件合并的文件替换和提交，还可以用于过期文件删除，第三处理算子可以是ReplaceDataFiles，ReplaceDataFiles算子用于数据文件替换。

示意性的，可以通过第一处理算子对所述数据湖进行文件扫描处理，生成文件扫描结果，并基于所述文件扫描结果生成至少一个文件合并任务。

可选的，可以针对第一处理算子配置启动条件，启动条件可以是接收完成写入数据文件至数据湖的已完成写入数量、可以是在完成写入数据文件至数据湖后接收到(反馈)消息的数量，启动条件设置为满足预设条件时开启一次小文件合并的扫描；在本说明书一个或多个实施例中，满足启动条件，则第一处理算子开始对相应table表记录的文件进行扫描以至少筛选小数据文件，基于扫描结果生成文件合并任务；

在一些实施例中，还可以扫描delete文件信息用于进行小文件合并后的过期文件删除以更新数据湖的文件数据。可以理解为，文件合并任务可以包括所有需要合并的小数据文件、表名信息、本次任务的合并数量，在一些实施例中，文件合并任务还可以包括delete文件信息和/或checkpointId。

可选的，第一处理算子还可以进一步配置，以提升数据处理时的稳定性；

在一种可行的实施方式中，可以检测所述文件合并任务对应数据表的数据处理状态；

所述数据处理状态包括空闲状态和工作状态，空闲状态也即table表中的文件不存在未结束的文件合并任务；工作状态也即table表中的文件存在文件合并任务未结束；

可选的，若所述数据处理状态为空闲状态，则基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理，并记录所述文件合并任务对应数据表的合并触发时间；

可选的，若所述数据处理状态为工作状态，则取消本次文件合并任务，取消文件合并任务可以是将该任务删除，可以是监测上一次文件合并任务是否完成，若完成则执行启动文件合并任务。

示意性的，第一处理算子可配置为检测当前至少一个table表中的文件是否存在文件合并任务未结束，也即是否为工作状态，若存在文件合并任务未结束时则取消文件合并任务，若不存在文件合并任务未结束也即空闲状态，则继续文件合并任务；例如，如果启动开始文件合并则会将开始的启动时间记录下来，每次启动开始合并时都会先获取(当前table表对应的)最新的文件合并提交的合并提交时间，也即检测当前至少一个table表中的文件是否存在文件合并任务未结束，若合并提交时间小于或等于启动时间，则说明当前table表上一次文件合并还未完成，会取消这一次文件合并，保证每个table表同一时刻只有一个文件合并任务在执行，提升稳定性。

在一种具体的实施场景中，通过第一处理算子获取各所述数据文件对应的写入消息；写入消息也即数据文件在完成写入数据湖后所生成的消息，如写入消息为本说明书一个或多个实施例中的反馈消息。写入消息可以至少可以包含表名信息(如数据湖表中的表名信息)和checkpointIdid(检查点标识)，该消息可以用于至少反馈在同步对数据湖文件中小数据文件扫描阶段可以基于该表名信息对table中记录的文件进行扫描。

通过第一处理算子基于写入消息中的表名信息对所述数据湖进行文件扫描处理，生成文件扫描结果，并基于所述文件扫描结果生成至少一个文件合并任务；文件扫描结果至少包括针对小数据文件的扫描结果，如小数据文件数量、小数据文件名称等等。在一些实施例中，文件扫描结果还可以包括delete文件信息(记录的写入过程中delete操作所记录对应的文件信息)和/或checkpointId。

示意性的，通常对数据湖中相应文件进行扫描可以通过对数据湖表进行扫描，通过基于写入消息中的表名信息确定需要扫描的数据湖表以及数据湖表中所记录的数据湖文件，然后基于表名信息来同步扫描前述指示的数据表中对应的数据湖文件，以筛选出该数据湖表中所对应的需要合并的小数据文件，从而来确定文件合并任务。文件合并任务至少包括需合并的小数据文件，可以理解的，基于文件合并任务同步对所述数据湖中的小数据文件进行文件合并处理，生成至少一个新的目标合并文件。在一些实施场景中，在完成文件合并处理生成目标合并文件之后，由于已对多个小数据文件进行合并，则还包括对数据湖中过期文件(可理解为以完成合并的小数据文件)进行过滤以完成数据湖的数据文件更新。

S204：基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理。

在一种具体的实施方式中，针对同步对所述数据湖中的小数据文件进行文件合并处理，可以通过至少一个用于文件合并的数据处理算子来实现。前述第一处理算子用于确定至少一个文件合并任务，后续执行文件合并可以是由其他数据处理算子完成；

示意性的，如图4所示，图4是本申请涉及的一种文件合并的场景示意图，通过所述数据处理算子确定文件合并任务可以至少包括第一处理算子、第二处理算子以及第三处理算子。第一处理算子可以是用于文件扫描、任务生成，例如第一处理算子可以是FileScanTasks，第一处理算子为文件扫描/任务生成类算子；第二处理算子用于文件合并，读取数据写入新合并的文件，例如第二处理算子可以是RowDataRewriter，用于行数据改写或，数据文件合并；第三处理算子用于小文件合并的文件替换和提交，还可以用于过期文件删除，第三处理算子可以是ReplaceDataFiles，ReplaceDataFiles算子用于数据文件替换。

示意性的，通过第一处理算子FileScanTasks对所述数据湖进行文件扫描处理，生成文件扫描结果，并基于所述文件扫描结果生成至少一个文件合并任务。

示意性的，可以通过第一处理算子向至少一个第二处理算子RowDataRewriter分发至少一个文件合并任务；示意性的，第二处理算子接收到的文件合并任务可以是一个也可以是多个，具体可基于实际情况进行配置。通过多个第二处理算子可以并行处理若干文件合并任务，基于文件合并任务实现对任务指示的小文件进行合并。

在实际应用中，在数据湖涉及的增量更新场景下，流式计算引擎如flink引擎基于移动的时间间隔不停的下底层文件文件系统输出数据，以写入至数据湖中，流式计算引擎的每增量更新一份文件，会随之产生相应的小数据文件，小数据文件可以是新写入的数据文件、元数据文件、快照文件等等。这些大量的小数据文件需要进行文件合并，在相关应用场景下可以设置小文件合并方式用于指示处理算子如何对若干小数据文件进行合并，例如小文件合并方式可以是文件压缩；可以是将多个小文件按照固定合并结果进行组合，如将已经写入数据湖表的小文件(非缓存区中的小文件)合并为结构“key+value”的键值集合形式的Mapfile，key为小文件的文件名，小文件的文件内容作为value值，按照“key+value”进行拼接，将多个小文件合并到键值集合中生成新的文件作为一个目标合并文件。可以理解的，在本申请中小文件合并方式可以基于实际应用环境进行配置，此处不作具体限定。

示意性的，可以在第二处理算子为多个时，可以通过各所述第二处理算子分别并行执行文件合并任务以同步对数据湖中的小数据文件进行文件合并处理，得到至少一个目标合并文件；

示意性的，第二处理算子：RowDataRewriter负责执行文件合并，读取数据写入新合并的文件，RowDataRewriter可多任务并行执行，文件合并任务会分发到各个RowDataRewriter中执行，每个RowDataRewriter基于文件合并任务对指示的所有需要合并的小数据文件进行合并，生成一个目标合并文件。

可选的，第二处理算子RowDataRewriter中可开启一个线程池执行文件合并的任务，每收到一个文件合并的任务，就会放到线程池的线程任务队列中顺序执行，也即执行将所述文件合并任务写入线程任务队列，基于线程任务队列对所述数据湖中的小数据文件进行文件合并处理的步骤，文件合并任务执行完成后会返回一个结果(包含新生成的目标合并文件，合并前的文件等信息)，然后发到下游ReplaceDataFiles算子中。

示意性的，第二处理算子通过将文件合并任务写入线程任务队列，可以实现多线程并行执行“checkpoint检查点处理”以及“基于线程任务队列对所述数据湖中的小数据文件进行文件合并处理”，以避免一些场景下任务执行时间过长算子无法处理checkpoint消息导致checkpoint失败；

其中，checkpoint检查点处理可以理解为检查点操作(checkpoint操作)，又称检查点机制，通过该检查点机制可以保证数据湖以及写入模块(例如，流式计算处理引擎，Flink集群)在某个算子因为某些原因出现故障时，能够将整个事务流图的状态恢复到故障之前的某一状态，保证事务流图状态的一致性。可以理解为，检查点机制是在数据湖涉及增量写入场景下保证数据或事务一致性的重要容灾机制。

具体而言，通过该检查点操作可以将正在运行的任务的状态保存下来，这个状态包括任务中每个算子的state(状态)，数据源中的消息的offset(偏移量)等。需要说明的是，检查点操作是数据湖涉及的增量数据场景中实现容错机制最核心的功能，它能够根据配置周期性地基于Stream中各个Operator/task的状态来生成SnapShot(快照)，从而将这些状态数据定期持久化存储下来，当程序一旦意外崩溃时，重新运行程序时可以有选择地从这些快照进行恢复，从而修正因为故障带来的程序数据异常。快照的核心概念之一是barrier。这些barrier被注入数据流并与数据流中的数据(或者称为记录)一起作为数据流的一部分向下流动。barriers永远不会超过记录，数据流严格有序，barrier将数据流中的记录隔离成一系列的记录集合，并将一些集合中的数据加入到当前的快照中，而另一些数据加入到下一个快照中。每个barrier都带有快照的ID，并且barrier之前的记录都进入了该快照。基于此，在本说明书中，为了避免写入数据湖并同步小文件合并这个过程中：由于任务执行时间过长算子无法处理checkpoint消息导致checkpoint失败，因此基于线程任务队列来辅助第二处理算子并行执行小文件合并以及checkpoint处理。也就是说在接收到诸如流式计算引擎或其他算子发送的检查点消息时，可以基于线程任务队列来实现多线程并行处理该检查点消息以对其进行检查点处理。

进一步的，通过第三处理算子基于所述至少一个目标合并文件对所述数据湖进行文件过滤处理。

示意性的，第三处理算子可以是ReplaceDataFiles算子，至少用于文件替换、文件提交、过期文件删除等。ReplaceDataFiles算子会在确定生成目标合并文件之后，对原需要合并的小数据文件进行替换删除操作，ReplaceDataFiles算子可以根据表名信息、checkpointId、需要完成的任务数记录接收到的已完成文件合并任务；

可选的，可以设置文件合并完成后的提交条件，可以是当文件合并任务的任务数等于任务数阈值时，对本次文件合并进行提交更新数据湖表中文件存储路径。提交后会执行过期文件删除，删除掉已经合并的小数据文件以及已过期的snapshot快照文件，以完成文件过滤处理。

可参考图5，图5是一种数据湖性能的比对分析图，在图5中，使用开源数据湖hudi数据湖作为比对对象，使用本说明书一个或多个实施例的数据处理方法对数据湖增量写入流程进行优化后可参考图5所示出的“本方案”对应的虚线线条示出的性能，图5所示出纵坐标为写入性能，单位为record/s,横坐标为已写入数据湖的数据量，基于本说明书优化后的方案入库性能稳定在12000record/s以上，而开源hudi数据湖则在5000record/s以下，采用本说明书所示出的方式，在数据写入量超过千万之后，insert(插入数据)和upsert(更新数据)性能可以保持稳定，且数据作业稳定性较好，写入性能和文件合并性能均可兼顾，基本不受数据增长影响，写入吞吐量和并行度呈正相关。其数据湖写入性能大幅改善，兼顾数据写入并同时执行小文件合并，极大的提升了数据处理效率，本方案数据处理的写入合并并行度大幅提升。

在本申请实施例中，通过获取数据源中的目标数据流，将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，通过采用并行执行方式将数据流写入数据湖和文件合并同步进行，可以避免数据合并量堆积，也降低了检查点阶段的数据处理压力，大幅提高了数据处理效率；以及，通过新增多个处理算子实现数据流写入时文件合并同步进行，而不必在数据流全部完成写入之后在其他非数据写入阶段进行小文件合并，优化了数据流处理写入流程；可以在数据湖应用层场景中，诸如Flink等计算引擎仅需部署一个任务计算处理任务即可同事完成数据写入和文件合并的功能，同时能不影响读取性能。

请参见图6，图6是本申请提出的一种数据处理方法的另一种实施例的流程示意图。具体的：

S301：获取数据源中的目标数据流；

S302：将所述目标数据流写入数据湖；

S303：若存在至少一个所述数据文件为完成写入状态，则对所述数据湖中的小数据文件进行文件合并处理，得到至少一个目标合并文件。

具体可参见本申请说明书其他实施例的步骤，此处不再赘述。

S304：获取目标合并文件对应的合并触发时间；

所述合并触发时间可以理解为执行文件合并的起始时间，或，开始文件合并的触发时间。

在本说明书一个或多个实施例中，通常可以确定文件合并任务，基于所述文件合并任务同步对所述数据湖中的小数据文件进行文件合并处理，可以将文件合并任务的任务生成时间作为合并触发时间。

S305：基于所述合并触发时间设置所述目标合并文件的文件序列号，基于所述文件序列号对所述数据湖进行文件过滤处理。

可以理解的，数据湖中每次增量写入数据或小文件合并之后文件提交都会生成一个文件序列号来标记新的文件(如目标合并文件)，文件序列号可表示为seqNum，文件的文件信息中通常包含该文件序列号。

在本说明书一个或多个实施例中，数据处理阶段是将目标数据流中数据文件写入数据湖和小数据文件合并同时并行执行，而针对数据湖而言，在完成小数据文件合并生成目标合并文件之后，会读取data文件过滤掉大于当前文件序列号的数据删除数据，数据删除数据可以是对已过期文件、合并后的小数据文件执行删除操作时生成的equility-delete数据，而文件合并和增量写入提交的顺序不一定在同一个时间点，此时若生成目标合并文件，并以目标合并文件对应的文件生成时间来生成文件序列号seqNum，就会导致部分应该过滤的数据不会被过滤掉，导致数据冗余乃至数据数据数据记录错误。

例如，通常小文件合并的触发会进行配置，如配置为在指定数量的数据文件写入数据湖提交之后开始checkpoint，那么有可能在一个checkpoint阶段完成并提交，也有可能会跨越多个checkpoint阶段才执行完成文件提交，如果跨越了若干checkpoint阶段同时生成了目标合并文件使用基于文件生成时间生成seqNum，则通常会导致这些已经完成数据合并之后的小数据文件data不会在文件合并期间记录到delete文件中，就会导致后续部分应该过滤的数据不会被过滤掉，导致数据冗余乃至数据数据数据记录错误。

在一些实施例中，生成新的文件(如增量写入新的文件、合并小数据文件生成目标合并文件)对应的文件提交过程在检查点处理之后完成，通过检查点处理这一操作验证数据一致性。

在本说明书一个或多个实施例中，通过在每生成目标合并文件时获取目标合并文件对应的合并触发时间，将合并触发时间而非文件生成时间设置为所述目标合并文件的文件序列号，这样后续在进行过滤处理时，会对其至少进行equility-delete过滤，equility-delete过滤会将所有大于当前文件序列号的数据删除数据(equility-delete)进行过滤。读取data文件可以正确基于文件序列号对所述数据湖进行文件过滤处理。可以过滤掉所有之后checkpoint处理的equility-delete记录文件，可以保障数据处理的稳定性。

S306：获取所述目标合并文件对应的参考检查点标识，记录所述参考检查点标识。

可以理解的，如flink等流式计算引擎增量写入数据文件提交时，会先写入记录本次数据文件的avro文件(一种二进制序列化文件格式)，avro文件可以是清单文件，然后将avro文件记录到流式计算引擎的状态后端，同时记录下本次增量写入数据文件对应的checkpointId(检查点标识)，然后完成当前算子的checkpoint提交，然后再所有算子、完成后在执行commitUpToCheckpoint中的逻辑进检查点操作，将之前写入的avro文件读取出来，重新写入manifest.avro清单文件，snapshot.avro快照文件和metadata.json元数据文件，然后完成提交，同时完成提交之后会把之前的avro文件删除。同时在写入的metadata.json元数据文件中会记下已提交的checkpointId。

checkpoint用于确保数据一致性，在检查点阶段失败是会涉及到数据恢复流程，当流式计算引擎执行数据恢复流程时会从元数据文件中读取最近时间点提交的checkpointId，然后只提交大于该checkpointId的检查点。但在文件合并产生新的文件以及后续合并后删除部分文件，这一过程是没有写入checkpointId，若执行数据恢复流程时如果上一次checkpoint提交是属于文件合并场景下的checkpoint，则由于没有读取到已提交的checkpointId，会将已提交过的checkpoint再次提交一遍，而该checkpointId会对应记录有已删除文件，此时就会由于找不到已经删除的文件导致恢复失败。这里在文件合并时生成目标合并文件之后同时写入提交的checkpointId，保证能正常恢复，也即生成目标合并文件之后获取所述目标合并文件对应的参考检查点标识，也即此时的检查点标识，将该参考检查点标识进行记录，如将参考检查点标识写入至元数据文件。

S307：获取数据插入文件的第一数据量和数据删除文件的第二数据量，基于所述第一数据量和所述第二数据量，对所述数据湖进行文件过滤处理。

在数据湖增量写入数据过程中，会实时写入三种文件：data文件，equility-delete文件和pos-delete文件，在进行insert(插入数据)操作时会写入data文件(也即新写入数据湖的数据文件)；进行delete操作时会写入equility-delete文件和pos-delete文件，equility-delete文件中会记录需要删除的记录的整条记录值，而pos-delete文件中会记录需要删除的记录所在的文件和行号，每个checkpoint阶段内进行insert操作时会在一个map中记录下当前checkpoint周期内写入的key和对应的文件行号。

所述数据插入文件也即进行insert(插入数据)操作时写入数据湖的data文件，通常可理解为增量文件，数据插入文件可以是合并处理后生成的目标合并文件。

所述数据删除文件也即前述进行delete操作时写入的equility-delete文件，equility-delete文件中会记录需要删除的记录的整条记录值。

所述第一数据量可以理解为数据插入文件的文件数量或者总数据容量。

所述第一数据量可以理解为数据删除文件的文件数量或者总数据容量。

在一种具体的实施场景中，在数据湖涉及的文件合并或读取场景下，会涉及到对数据湖进行文件过滤处理，通常可以是基于哈希过滤方式，也即读取文件合并阶段对应的equility-delete文件(可理解为文件合并之后的过期文件)时全部放入hashest进行过滤；在一些实施场景中，全部放入hashest进行过滤也会导致内存溢出。

示意性的，哈希过滤方式对应的基于HashSet的实现文件过滤，HashSet具有不允许有重复元素的特性，通过将equility-delete文件的所有元素都添加到HashSet对象中，利用HashSET对象的无重复元素特性实现自动剔除重复的元素。

在一种可行的实施方式中，可以在一定场景下仅读取数据插入文件也即进行insert(插入数据)操作时写入数据湖的data文件进行过滤，可减少内存占用。

示意性的，可以设定一个阈值，例如可以在equility-delete的数据量在data文件的n倍(如n为2)以上的情况下使用data文件的key过滤代替直接读取equility-delete文件。因为这时内存使用量在最差的情况下是data文件中所有的key都在delete文件中，这时使用data文件进行过滤与前述方式内存使用量相等，而如果equility-delete的数据量继续增多，即使在最差的情况下也是使用data文件过滤后内存使用量更少，对于文件IOequility-delete的数据量是data文件的两倍或更大的情况，读取data文件IO的影响也会逐渐变小，也即解决了内存溢出的问题。

可选的，在达到设定阈值时，可以切换过滤方式，使用布隆过滤器代替哈希过滤方式进行内存优化，使用data文件中的key(通常key可以是文件名)构建bloomfilter(布隆过滤器)，如果一个key在data文件中，则通过bloomfilter(布隆过滤器)判断也一定返回正确，因此可使用bloomfilter(布隆过滤器)代替使用hashset对应的哈希过滤方式。

例如，如果data文件的key占用100m空间，delete文件的key占用200m空间，且data文件中的key和delete文件是完全重合的，则采用原哈希过滤方式直接读取delete文件较多的内存，通常会占用200m内存，使用bloomfilter(布隆过滤器)读取data文件的key则大幅减小内存占用，一般其误判率极小，如误判类别仅为0.001，则读取时delete文件可能消耗100.1m内存，而bloomfilter(布隆过滤器)占用的内存一般是hashset对应哈希过滤方式的1/50-1/100，因此可以切换过滤方式。

在一种具体的实施场景中，若所述第一数据量与所述第二数据量的比值大于目标数值，则基于所述数据插入文件采用布隆过滤方式对所述数据湖进行文件过滤处理；若所述第一数据量与所述第二数据量的比值小于或等于目标数值，则基于所述数据删除文件采用哈希过滤方式对所述数据湖进行文件过滤处理。

可选的，所述目标数据基于实际应用场景设置，如目标数值可以设置为2，也即第一数据量与所述第二数据量的比值超过目标数值2时，使用布隆过滤方式。

可参见图7a-图7c，图7a为一种涉及布隆过滤的性能示意图，图7b为一种涉及哈希过滤的性能示意图，图7c为一种涉及数据湖采用开源默认过滤方式的性能示意图；结合图7a和图7b可直观反馈使用前述方式基于第一数据量和第二数据量使用不同数据过滤方式内存占用的情况，在其他条件相同的情况下，可以看到bloomfilter(布隆过滤器)方式内存使用峰值稳定在2G左右，hashset方式内存使用峰值基本在2-3G之间，而原始版本内存使用内存峰值基本在3-4G之间，也即采用本说明书所对应的数据处理方法可以节省数据处理阶段的内存占用，节省数据处理资源消耗。

在本申请实施例中，通过获取数据源中的目标数据流，将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，通过采用并行执行方式将数据流写入数据湖和文件合并同步进行，可以避免数据合并量堆积，也降低了检查点阶段的数据处理压力，优化了数据流处理写入流程，大幅提高了数据处理效率；以及，在兼顾数据处理效率的同时可以保障文件过滤过程正常，避免文件过滤出错，提升数据处理的容灾性能。

下面将结合图8，对本申请实施例提供的数据处理装置进行详细介绍。需要说明的是，图8所示的数据处理装置，用于执行本申请所示实施例的方法步骤，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请的其他实施例。

请参见图8，其示出本申请实施例的数据处理装置的结构示意图。该数据处理装置1可以通过软件、硬件或者两者的结合实现成为用户终端的全部或一部分。根据一些实施例，该数据处理装置1包括数据获取模块11和写入合并模块12，具体用于：

数据获取模块11，用于获取数据源中的目标数据流；

写入合并模块12，用于将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，所述小数据文件为文件内存小于内存阈值的数据文件。

可选的，如图9所示，所述写入合并模块12，包括：

数据写入单元121，用于将所述目标数据流中所有数据文件分别写入数据湖；

文件合并单元122，用于若存在至少一个所述数据文件为完成写入状态，则同步对所述数据湖中的小数据文件进行文件合并处理。

可选的，所述文件合并单元122，具体用于：

确定文件合并任务，基于所述文件合并任务同步对所述数据湖中的小数据文件进行文件合并处理。

可选的，所述文件合并单元122，具体用于：

确定至少一个数据处理算子，通过所述数据处理算子确定文件合并任务，基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理。

可选的，所述文件合并单元122，具体用于：

通过第一处理算子对所述数据湖进行文件扫描处理，生成文件扫描结果，并基于所述文件扫描结果生成至少一个文件合并任务。

可选的，所述文件合并单元122，具体用于：

通过第一处理算子获取各所述数据文件对应的写入消息；

通过第一处理算子基于所述写入消息中的表名信息对所述数据湖进行文件扫描处理，生成文件扫描结果。

可选的，所述文件合并单元122，具体用于：

通过第一处理算子向至少一个第二处理算子分发所述至少一个文件合并任务；

通过各所述第二处理算子分别并行执行所述文件合并任务以同步对所述数据湖中的小数据文件进行文件合并处理，得到至少一个目标合并文件；

通过第三处理算子基于所述至少一个目标合并文件对所述数据湖进行文件过滤处理。

可选的，所述文件合并单元122，具体用于：

检测所述文件合并任务对应数据表的数据处理状态；

若所述数据处理状态为空闲状态，则基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理，并记录所述文件合并任务对应数据表的合并触发时间；

若所述数据处理状态为工作状态，则取消所述文件合并任务。

可选的，所述写入合并模块12，具体用于：

将所述文件合并任务写入线程任务队列；

基于线程任务队列对所述数据湖中的小数据文件进行文件合并处理。

可选的，所述写入合并模块12，具体用于：

接收检查点消息；

采用并行执行方式对所述检查点消息进行检查点处理以及基于线程任务队列对所述数据湖中的小数据文件进行文件合并处理。

可选的，所述写入合并模块12，具体用于：

对所述数据湖中的小数据文件进行文件合并处理，得到至少一个目标合并文件；

获取目标合并文件对应的合并触发时间；

基于所述合并触发时间设置所述目标合并文件的文件序列号，基于所述文件序列号对所述数据湖进行文件过滤处理。

可选的，如图10所示，所述装置1，还包括：

文件过滤模块13，用于获取数据插入文件的第一数据量和数据删除文件的第二数据量；

所述文件过滤模块13，还用于基于所述第一数据量和所述第二数据量，对所述数据湖进行文件过滤处理。

可选的，如图11所示，所述文件过滤模块13，包括：

布隆过滤单元131，用于若所述第一数据量与所述第二数据量的比值大于目标数值，则基于所述数据插入文件采用布隆过滤方式对所述数据湖进行文件过滤处理；

哈希过滤单元132，用于若所述第一数据量与所述第二数据量的比值小于或等于目标数值，则基于所述数据删除文件采用哈希过滤方式对所述数据湖进行文件过滤处理。

需要说明的是，上述实施例提供的数据处理装置在执行数据处理方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的数据处理装置与数据处理方法实施例属于同一构思，其体现实现过程详见方法实施例，这里不再赘述。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请实施例中，在本申请实施例中，通过获取数据源中的目标数据流，将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，通过采用并行执行方式将数据流写入数据湖和文件合并同步进行，可以避免数据合并量堆积，也降低了检查点阶段的数据处理压力，优化了数据流处理写入流程，大幅提高了数据处理效率；以及，在兼顾数据处理效率的同时可以保障文件过滤过程正常，避免文件过滤出错，提升数据处理的容灾性能。

本申请实施例还提供了一种计算机存储介质，所述计算机存储介质可以存储有多条指令，所述指令适于由处理器加载并执行如上述图1～图7c所示实施例的所述数据处理方法，具体执行过程可以参见图1～图7c所示实施例的具体说明，在此不进行赘述。

本申请还提供了一种计算机程序产品，该计算机程序产品存储有至少一条指令，所述至少一条指令由所述处理器加载并执行如上述图1～图7c所示实施例的所述数据处理方法，具体执行过程可以参见图1～图7c所示实施例的具体说明，在此不进行赘述。

请参见图12，为本说明书一个或多个实施例提供了一种电子设备的结构示意图。如图12所示，所述电子设备1000可以包括：至少一个处理器1001，至少一个网络接口1004，用户接口1003，存储器1005，至少一个通信总线1002。

其中，通信总线1002用于实现这些组件之间的连接通信。

其中，用户接口1003可以包括显示屏(Display)、摄像头(Camera)，可选用户接口1003还可以包括标准的有线接口、无线接口。

其中，网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。

其中，处理器1001可以包括一个或者多个处理核心。处理器1001利用各种借口和线路连接整个服务器1000内的各个部分，通过运行或执行存储在存储器1005内的指令、程序、代码集或指令集，以及调用存储在存储器1005内的数据，执行服务器1000的各种功能和处理数据。可选的，处理器1001可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable Logic Array，PLA)中的至少一种硬件形式来实现。处理器1001可集成中心处理器(Central Processing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器1001中，单独通过一块芯片进行实现。

其中，存储器1005可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory)。可选的，该存储器1005包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器1005可用于存储指令、程序、代码、代码集或指令集。存储器1005可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现上述各个方法实施例的指令等；存储数据区可存储上面各个方法实施例中涉及到的数据等。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图12所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及应用程序。

在图10所示的电子设备1000中，用户接口1003主要用于为用户提供输入的接口，获取用户输入的数据；而处理器1001可以用于调用存储器1005中存储的应用程序，并具体执行以下操作：

获取数据源中的目标数据流；

将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，所述小数据文件为文件内存小于内存阈值的数据文件。

在一个实施例中，所述处理器1001在执行所述将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理时，具体执行以下操作：

将所述目标数据流中所有数据文件分别写入数据湖；

若存在至少一个所述数据文件为完成写入状态，则同步对所述数据湖中的小数据文件进行文件合并处理。

在一个实施例中，所述处理器1001在执行所述同步对所述数据湖中的小数据文件进行文件合并处理，包括：

确定文件合并任务，基于所述文件合并任务同步对所述数据湖中的小数据文件进行文件合并处理。

在一个实施例中，所述处理器1001在执行所述确定文件合并任务，基于所述文件合并任务同步对所述数据湖中的小数据文件进行文件合并处理，包括：

确定至少一个数据处理算子，通过所述数据处理算子确定文件合并任务，基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理。

在一个实施例中，所述处理器1001在执行所述确定文件合并任务时，具体执行以下步骤：

通过第一处理算子对所述数据湖进行文件扫描处理，生成文件扫描结果，并基于所述文件扫描结果生成至少一个文件合并任务。

在一个实施例中，所述处理器1001在执行所述通过第一处理算子对所述数据湖进行文件扫描处理，生成文件扫描结果时，具体执行以下步骤：

通过第一处理算子获取各所述数据文件对应的写入消息；

通过第一处理算子基于所述写入消息中的表名信息对所述数据湖进行文件扫描处理，生成文件扫描结果。

在一个实施例中，所述处理器1001在执行所述基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理时，具体执行以下步骤：

通过第一处理算子向至少一个第二处理算子分发所述至少一个文件合并任务；

通过各所述第二处理算子分别并行执行所述文件合并任务以同步对所述数据湖中的小数据文件进行文件合并处理，得到至少一个目标合并文件；

通过第三处理算子基于所述至少一个目标合并文件对所述数据湖进行文件过滤处理。

在一个实施例中，所述处理器1001在执行所述基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理时，具体执行以下步骤：

检测所述文件合并任务对应数据表的数据处理状态；

若所述数据处理状态为空闲状态，则基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理，并记录所述文件合并任务对应数据表的合并触发时间；

若所述数据处理状态为工作状态，则取消所述文件合并任务。

在一个实施例中，所述处理器1001在执行所述基于所述文件合并任务同步对所述数据湖中的小数据文件进行文件合并处理时，具体执行以下步骤：

将所述文件合并任务写入线程任务队列；

基于线程任务队列对所述数据湖中的小数据文件进行文件合并处理。

在一个实施例中，所述处理器1001在执行所述将各所述文件合并任务写入线程任务队列之后，还执行以下步骤：

接收检查点消息；

所述基于线程任务队列对所述数据湖中的小数据文件进行文件合并处理，包括：

采用并行执行方式对所述检查点消息进行检查点处理以及基于线程任务队列对所述数据湖中的小数据文件进行文件合并处理。

在一个实施例中，所述处理器1001在执行所述对所述数据湖中的小数据文件进行文件合并处理时，具体执行以下步骤：

对所述数据湖中的小数据文件进行文件合并处理，得到至少一个目标合并文件；

获取目标合并文件对应的合并触发时间；

基于所述合并触发时间设置所述目标合并文件的文件序列号，基于所述文件序列号对所述数据湖进行文件过滤处理。

在一个实施例中，所述处理器1001在执行所述数据处理方法时，还执行以下步骤：

获取数据插入文件的第一数据量和数据删除文件的第二数据量；

基于所述第一数据量和所述第二数据量，对所述数据湖进行文件过滤处理。

在一个实施例中，所述处理器1001在执行所述基于所述第一数据量和所述第二数据量，采用布隆过滤方式对所述数据湖进行文件过滤处理时，具体执行以下步骤：

若所述第一数据量与所述第二数据量的比值大于目标数值，则基于所述数据插入文件采用布隆过滤方式对所述数据湖进行文件过滤处理；

若所述第一数据量与所述第二数据量的比值小于或等于目标数值，则基于所述数据删除文件采用哈希过滤方式对所述数据湖进行文件过滤处理。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体或随机存储记忆体等。

在本申请实施例中，通过获取数据源中的目标数据流，将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，通过采用并行执行方式将数据流写入数据湖和文件合并同步进行，可以避免数据合并量堆积，也降低了检查点阶段的数据处理压力，优化了数据流处理写入流程，大幅提高了数据处理效率；以及，在兼顾数据处理效率的同时可以保障文件过滤过程正常，避免文件过滤出错，提升数据处理的容灾性能。

以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (16)

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

获取数据源中的目标数据流；

将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，所述小数据文件为文件内存小于内存阈值的数据文件。

2.根据权利要求1所述的方法，其特征在于，所述将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，包括：

将所述目标数据流中所有数据文件分别写入数据湖；

若存在至少一个所述数据文件为完成写入状态，则同步对所述数据湖中的小数据文件进行文件合并处理。

3.根据权利要求2所述的方法，其特征在于，所述同步对所述数据湖中的小数据文件进行文件合并处理，包括：

确定文件合并任务，基于所述文件合并任务同步对所述数据湖中的小数据文件进行文件合并处理。

4.根据权利要求3所述的方法，其特征在于，所述确定文件合并任务，基于所述文件合并任务同步对所述数据湖中的小数据文件进行文件合并处理，包括：

确定至少一个数据处理算子，通过所述数据处理算子确定文件合并任务，基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理。

5.根据权利要求4所述的方法，其特征在于，所述确定文件合并任务，包括：

通过第一处理算子对所述数据湖进行文件扫描处理，生成文件扫描结果，并基于所述文件扫描结果生成至少一个文件合并任务。

6.根据权利要求5所述的方法，其特征在于，所述通过第一处理算子对所述数据湖进行文件扫描处理，生成文件扫描结果，包括：

通过第一处理算子获取各所述数据文件对应的写入消息；

通过第一处理算子基于所述写入消息中的表名信息对所述数据湖进行文件扫描处理，生成文件扫描结果。

7.根据权利要求5所述的方法，其特征在于，所述基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理，包括：

通过第一处理算子向至少一个第二处理算子分发所述至少一个文件合并任务；

通过各所述第二处理算子分别并行执行所述文件合并任务以同步对所述数据湖中的小数据文件进行文件合并处理，得到至少一个目标合并文件；

通过第三处理算子基于所述至少一个目标合并文件对所述数据湖进行文件过滤处理。

8.根据权利要求4所述的方法，其特征在于，所述基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理，包括：

检测所述文件合并任务对应数据表的数据处理状态；

若所述数据处理状态为空闲状态，则基于所述文件合并任务采用所述数据处理算子同步对所述数据湖中的小数据文件进行文件合并处理，并记录所述文件合并任务对应数据表的合并触发时间；

若所述数据处理状态为工作状态，则取消所述文件合并任务。

9.根据权利要求3所述的方法，其特征在于，所述基于所述文件合并任务同步对所述数据湖中的小数据文件进行文件合并处理，包括：

将所述文件合并任务写入线程任务队列；

基于线程任务队列对所述数据湖中的小数据文件进行文件合并处理。

10.根据权利要求9所述的方法，其特征在于，所述将各所述文件合并任务写入线程任务队列之后，还包括：

接收检查点消息；

所述基于线程任务队列对所述数据湖中的小数据文件进行文件合并处理，包括：

采用并行执行方式对所述检查点消息进行检查点处理以及基于线程任务队列对所述数据湖中的小数据文件进行文件合并处理。

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

对所述数据湖中的小数据文件进行文件合并处理，得到至少一个目标合并文件；

获取目标合并文件对应的合并触发时间；

基于所述合并触发时间设置所述目标合并文件的文件序列号，基于所述文件序列号对所述数据湖进行文件过滤处理。

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

获取数据插入文件的第一数据量和数据删除文件的第二数据量；

基于所述第一数据量和所述第二数据量，对所述数据湖进行文件过滤处理。

13.根据权利要求12所述的方法，其特征在于，所述基于所述第一数据量和所述第二数据量，采用布隆过滤方式对所述数据湖进行文件过滤处理，包括：

若所述第一数据量与所述第二数据量的比值大于目标数值，则基于所述数据插入文件采用布隆过滤方式对所述数据湖进行文件过滤处理；

若所述第一数据量与所述第二数据量的比值小于或等于目标数值，则基于所述数据删除文件采用哈希过滤方式对所述数据湖进行文件过滤处理。

14.一种数据处理装置，其特征在于，所述方法包括：

数据获取模块，用于获取数据源中的目标数据流；

写入合并模块，用于将所述目标数据流写入数据湖，并同步对所述数据湖中的小数据文件进行文件合并处理，所述小数据文件为文件内存小于内存阈值的数据文件。

15.一种计算机存储介质，其特征在于，所述计算机存储介质存储有多条指令，所述指令适于由处理器加载并执行如权利要求1～13任意一项的方法步骤。

16.一种电子设备，其特征在于，包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行如权利要求1～13任意一项的方法步骤。

Images