一种提升Flink写入HDFS性能的方法及装置

技术领域

本发明属于大数据实时计算领域，涉及一种提升实时数据仓库数据写入性能的方法及装置，尤其是一种提升Flink写入HDFS性能的方法及装置。

背景技术

在实时数据计算中，一般常见的应用平台数据集成是采用管道化的方式，即“一个Flink任务写多条流”的模式。数据集成过程中会出现几百个流存在于同一个Kafka Topic中的现象，并且由同一个Flink任务分流写到多个Hive表中。此时就需要给任务设置很大的并行度，从而会同时打开超大数量的HDFS文件，这使得集群稳定性问题更加严重。当Flink任务做Checkpoint(检查点)时，HDFS Sink会去做flush数据和close文件等操作。因此Flink在写入HDFS时会遇到个别HDFS文件写入慢的问题，从而导致HDFS集群存在不稳定性的场景，造成整个数据仓库的吞吐性能下降。

发明内容

针对Flink写入HDFS集群稳定性的问题，本发明提供一种提升Flink写入HDFS性能的方法及装置，能够大幅提升Flink任务对HDFS文件的写入能力，提高数据写入和读取的效率，从而保证实时数据仓库的稳定性。

为实现上述目的，本发明采用下述技术方案：

在本发明一实施例中，提出了一种提升Flink写入HDFS性能的方法，该方法包括：

在checkpoint快照阶段，通过文件续写的方式，将Flink任务进程内存数据续写到HDFS中，同时记录写出文件的offset；

在checkpoint恢复阶段，对文件进行截断，并将文件截断到offset位置，再继续写入；

在checkpoint快照阶段，将需要关闭的处于正在写入状态的文件放到异步队列中，同时将异步关闭文件操作放入状态缓存中管理；

在checkpoint快照阶段，通过多线程进行处理；

在checkpoint快照阶段，利用Checkpoint ID严格单调递增的特性，优化Checkpoint ID。

进一步地，优化Checkpoint ID，包括：

Sink端临时目录为{dump_path}/{next_cp_id}，其中next_cp_id的定义是当前最新的cp_id+1；

在Checkpoint快照阶段，Sink端保存当前最新cp_id到状态缓存，同时更新next_cp_id为cp_id+1；

在Checkpoint完成阶段，将Sink端临时目录中所有小于等于当前最新cp_id的数据移动到正式目录下；

在Checkpoint恢复阶段，Sink端恢复当前最新cp_id，并将Sink端临时目录中所有小于等于当前最新cp_id的数据移动到正式目录下。

进一步地，当Flink任务做Checkpoint时，通过滚动策略定义了当处于正在写入状态的文件关闭后，正在写入状态将变为正在追加写入状态，在成功的Checkpoint后，正在追加写入状态将变为完成写入状态。

进一步地，通过设置Checkpoint间隔时间，控制部分文件供下游系统可用的速度、大小和数量。

在本发明一实施例中，还提出了一种提升Flink写入HDFS性能的装置，该装置包括：

文件关闭减频模块，用于在checkpoint快照阶段，通过文件续写的方式，将Flink任务进程内存数据续写到HDFS中，同时记录写出文件的offset；在checkpoint恢复阶段，对文件进行截断，并将文件截断到offset位置，再继续写入；

文件关闭异步化模块，用于在checkpoint快照阶段，将需要关闭的处于正在写入状态的文件放到异步队列中，同时将异步关闭文件操作放入状态缓存中管理；

流并行化处理模块，用于在checkpoint快照阶段，通过多线程进行处理；

Checkpoint ID优化模块，用于在checkpoint快照阶段，利用Checkpoint ID严格单调递增的特性，优化Checkpoint ID。

进一步地，优化Checkpoint ID，包括：

Sink端临时目录为{dump_path}/{next_cp_id}，其中next_cp_id的定义是当前最新的cp_id+1；

在Checkpoint快照阶段，Sink端保存当前最新cp_id到状态缓存，同时更新next_cp_id为cp_id+1；

在Checkpoint完成阶段，将Sink端临时目录中所有小于等于当前最新cp_id的数据移动到正式目录下；

在Checkpoint恢复阶段，Sink端恢复当前最新cp_id，并将Sink端临时目录中所有小于等于当前最新cp_id的数据移动到正式目录下。

进一步地，当Flink任务做Checkpoint时，通过滚动策略定义了当处于正在写入状态的文件关闭后，正在写入状态将变为正在追加写入状态，在成功的Checkpoint后，正在追加写入状态将变为完成写入状态。

进一步地，通过设置Checkpoint间隔时间，控制部分文件供下游系统可用的速度、大小和数量。

在本发明一实施例中，还提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现前述提升Flink写入HDFS性能的。

在本发明一实施例中，还提出了一种计算机可读存储介质，计算机可读存储介质存储有执行提升Flink写入HDFS性能的的计算机程序。

有益效果：

1、本发明可以减少HDFS文件关闭的频率，同时大大减少小文件的生成。

2、本发明采用HDFS文件关闭的异步化改进，即使故障恢复时，也能继续对文件进行关闭。

3、本发明针对实时流做了并行化的处理，增加处理速度。

4、在高并发场景下，由于个别Task Snapshot超时或者失败，导致整个Checkpoint失败的问题会比较明显；而采用本发明，针对Checkpoint失败，可提高系统的容错性以及稳定性。

附图说明

图1是本发明提升Flink写入HDFS性能的方法流程示意图；

图2是本发明RollingPolicy滚动策略的示意图；

图3是本发明异步队列状态存储的示意图；

图4是本发明Checkpoint恢复阶段的关闭操作示意图；

图5是本发明提升Flink写入HDFS性能的装置结构示意图；

图6是本发明计算机设备结构示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神，应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种装置、装置、节点、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

本发明的实施方式，提出了一种提升Flink写入HDFS性能的方法及装置，能够大幅提升Flink任务对HDFS文件的写入能力，提高数据写入和读取的效率，从而保证实时数据仓库的稳定性。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。

图1是本发明提升Flink写入HDFS性能的方法流程示意图。如图1所示，该方法包括：

S1、减少文件的close(关闭)频率

RollingPolicy(滚动策略)定义了当指定的处于正在写入状态的文件关闭后，正在写入状态将变为Pending状态(标识一种正在追加写入的状态)，在成功的Checkpoint后，正在追加写入状态将变为Finished状态(标识一种完成写入的状态)。处于Pending状态的文件会在下一次Checkpoint时变为Finished状态，通过设置Checkpoint间隔时间，可以控制部分文件(part file)对下游系统可用的速度、大小和数量。在Checkpoint Snapshot(快照)阶段，不会去close处于正在写入状态的文件，而更多的是通过文件续写的方式，仅将Flink任务进程内存数据续写到HDFS中，并记录写出文件的offset(偏移量)。同时在checkpoint恢复阶段，就需要对处于正在写入状态的文件做truncate(截断)，将处于正在写入状态的文件截断到offset位置，再继续写入，相当于去掉多余的数据。这样可以减少文件close的频率，同时大大减少小文件的生成。

如图2所示，将处于正在写入状态的文件关闭操作和关闭超时操作异步处理。图2中，InProgressPart：正在写入的部分(文件)；CloseingPartsForCurrentCheckpoint：当前检查点的关闭部分(文件)；PendingFileRecoverablesForCurrentCheckpoint：当前检查点的可恢复性挂起文件。

S2、文件close的异步化改进

将需要close的处于正在写入状态的文件放到异步队列中，从而保证close的动作不会堵塞整个主链路的处理，提升HDFS稳定性情况下的吞吐。将异步close文件操作放入state(状态缓存)中管理。即使在checkpoint恢复阶段，也能继续对文件进行关闭。

这里的异步是将close文件操作交由其他线程(队列)处理，当前线程(队列)继续下一步操作，无需处理close文件操作。

如图3所示，将checkpoint Snapshot(快照)阶段的异步close文件操作放入state(状态缓存)中管理。在异步线程(队列)中从状态缓存中获取并close文件。图3中，InProgressPart：正在写入的部分(文件)；CloseingPartsForCurrentCheckpoint：当前检查点的关闭部分(文件)；PendingFileRecoverablesForCurrentCheckpoint：当前检查点的可恢复性挂起文件；PendingFileRecoverablesPreCheckpoint：挂起文件到可恢复预检查点。

如图4所示，将当前写入部分(文件)的关闭操作和关闭超时操作异步处理。在Checkpoint恢复阶段，从state(状态缓存)中获取需要异步close的文件进行关闭操作。图4中CloseingPartsForCurrentCheckpoint：当前检查点的关闭部分(文件)；PendingFileRecoverablesForCurrentCheckpoint：当前检查点的可恢复性挂起文件。

S3、流并行化的处理

针对多条流，在Checkpoint Snapshot(快照)阶段进行并行化的处理，多条流并行化的处理其实就是打开多个bucket(桶)，Flink框架原生是通过循环的方式来进行串行的处理，而并行化改造后通过多线程来处理，就可以增加处理速度，减少Checkpoint超时的发生。

S4、优化Checkpoint ID

充分利用Checkpoint ID(检查点ID)严格单调递增的特性，每一次做Checkpoint时，当前Checkpoint ID一定比之前大，因此在Checkpoint Complete(完成)阶段，可以提交小于等于当前Checkpoint ID的临时数据。具体优化策略如下：

Sink(数据流输出机制)端临时目录为：

{dump_path}/{next_cp_id}，这里{dump_path}：变量，转储路径，{next_cp_id}：变量，当前最新的Checkpoint ID为cp_id+1。

在Checkpoint Snapshot(快照)阶段，Sink端保存当前最新cp_id到State(状态缓存)，同时更新next_cp_id为cp_id+1。

在Checkpoint Complete(完成)阶段，Sink端将临时目录中所有小于等于当前最新cp_id的数据移动到正式目录(指外部调用者传入的路径参数)下。

在Checkpoint Recover(恢复)阶段，Sink端恢复最新一次的cp_id，并将临时目录中所有小于等于当前最新cp_id的数据移动到正式目录下。

需要说明的是，尽管在上述实施例及附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

为了对上述提升Flink写入HDFS性能的方法进行更为清楚的解释，下面结合一个具体的实施例来进行说明，然而值得注意的是该实施例仅是为了更好地说明本发明，并不构成对本发明不当的限定。

实施例：

1、在Flink的checkpoint Snapshot(快照)阶段代码中，去除close文件操作，添加记录写出文件的offset功能方法来记录写入文件的偏移量，当需要close文件时，则在state中记录该文件。假设Flink写入100万条数据到HDFS，需要关闭文件1000次，每次关闭耗时20ms,则本发明能够节省20秒，并且不再发生等待关闭文件造成的线程阻塞。

2、当集群发生故障，需要从checkpoint做故障恢复(checkpoint恢复阶段)时，由于已经记录写入文件的offset偏移量，此时只需要从offset位置继续写入，相当于去掉多余的数据，从而减少重新写入所耗费的资源和时间。当10G文件写入到8G的时候，网络中断，则从checkpoint做故障恢复时，获取存储的offset，从offset地方继续写入，此时只需要写入剩余的2G文件。

3、在第1步中，将需要close的文件放到异步队列中，close文件操作将在并行的线程中进行，异步close文件操作将不会再影响主线程处理数据流的速度，降低了文件写入的并发度，提高写入速度，降低等待时间。同时需要加入到state中管理。即使故障恢复时，也能继续对文件进行关闭，经过这种优化方式，100万数据写入时长提高20s，数据流写入性能提升50％。

4、改造在checkpoint Snapshot(快照)阶段代码，加入实现做并行化处理的方法，根据文件块个数去并行写入HDFS，比如1G文件，文件块设置为128M，则并行写入线程数量可为8，性能最大可提升8倍。并行化改造后通过多线程来处理，就可以增加处理速度，减少Checkpoint超时的发生。

5、利用Checkpoint ID严格单调递增的特性，实现在Checkpoint Complete(完成)阶段，提交小于等于当前Checkpoint ID的临时数据的功能。这样的改造解决了HDFS写入延迟容易有毛刺的问题，原本Flink由于个别Task Snapshot超时或者失败，导致整个Checkpoint失败的问题会比较明显。本发明解决了Checkpoint失败问题，有效提高系统的容错性以及稳定性。

基于同一发明构思，本发明还提出一种提升Flink写入HDFS性能的装置。该装置的实施可以参见上述方法的实施，重复之处不再赘述。以下所使用的术语“模块”，可以是实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图5是本发明提升Flink写入HDFS性能的装置结构示意图。如图5所示，该装置包括：

文件关闭减频模块101，用于在checkpoint快照阶段，通过文件续写的方式，将Flink任务进程内存数据续写到HDFS中，同时记录写出文件的offset；在checkpoint恢复阶段，对文件进行截断，并将文件截断到offset位置，再继续写入。

当Flink任务做Checkpoint时，通过滚动策略定义了当处于正在写入状态的文件关闭后，正在写入状态将变为正在追加写入状态，在成功的Checkpoint后，正在追加写入状态将变为完成写入状态。

通过设置Checkpoint间隔时间，控制部分文件供下游系统可用的速度、大小和数量。

文件关闭异步化模块102，用于在checkpoint快照阶段，将需要关闭的处于正在写入状态的文件放到异步队列中，同时将异步关闭文件操作放入状态缓存中管理。

流并行化处理模块103，用于在checkpoint快照阶段，通过多线程进行处理。

Checkpoint ID优化模块104，用于在checkpoint快照阶段，利用Checkpoint ID严格单调递增的特性，优化Checkpoint ID。

优化Checkpoint ID，包括：

Sink端临时目录为{dump_path}/{next_cp_id}，其中next_cp_id的定义是当前最新的cp_id+1；

在Checkpoint快照阶段，Sink端保存当前最新cp_id到状态缓存，同时更新next_cp_id为cp_id+1；

在Checkpoint完成阶段，将Sink端临时目录中所有小于等于当前最新cp_id的数据移动到正式目录下；

在Checkpoint恢复阶段，Sink端恢复当前最新cp_id，并将Sink端临时目录中所有小于等于当前最新cp_id的数据移动到正式目录下。

应当注意，尽管在上文详细描述中提及了提升Flink写入HDFS性能的装置的若干模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。

基于前述发明构思，如图6所示，本发明还提出一种计算机设备200，包括存储器210、处理器220及存储在存储器210上并可在处理器220上运行的计算机程序230，处理器220执行计算机程序230时实现前述提升Flink写入HDFS性能的方法。

基于前述发明构思，本发明还提出一种计算机可读存储介质，计算机可读存储介质存储有执行前述提升Flink写入HDFS性能的的计算机程序。

本发明提出的提升Flink写入HDFS性能的方法及装置，HDFS写入效率是原来的10倍以上；解决了高并发场景下，HDFS文件close阻塞问题；能够有效降低HDFS小文件数量，高频次的写入比原来降低10倍以上；利用checkpoint可大大提高系统的容错性以及稳定性。

本发明中涉及到的专业术语说明如下：

全程Apache Flink，是一个开源的流处理框架，应用于分布式、高性能和高可用的数据流应用程序，可以处理有限数据流和无限数据，即能够处理有边界和无边界的数据流。

Hadoop Distributed File System，简称HDFS，是一个分布式文件系统。HDFS有着高容错性的特点，并且设计用来部署在低廉的硬件上，而且它提供高吞吐量来访问应用程序的数据，适合那些有着超大数据集的应用程序。

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。

hive是基于Hadoop的一个数据仓库工具，用来进行数据提取、转化和加载，这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。

HDFS Sink是用于将数据流最终的输出到HDFS的机制。

Flush：内存数据写入磁盘。

虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包含的各种修改和等同布置。

对本发明保护范围的限制，所属领域技术人员应该明白，在本发明的技术方案的基础上，本领域技术人员不需要付出创造性劳动即可做出的各种修改或变形仍在本发明的保护范围以内。