CN112100148B - 一种打包日志的增量处理方法 - Google Patents

Abstract

本发明公开了一种打包日志的增量处理方法，包括通过预先配置的实时采集工具将应用服务器在应用服务系统运行过程中产生的日志发送到异步队列kafka集群中；采用预设方法从kafka集群中读取日志记录，并打包生成原始日志文件和中间临时日志文件；采用预设规则扫描中间临时日志文件中的gzip文件列表；在某个时间窗口节点读取gzip文件中的内容，并重新排序后打包输出成分片日志文件；利用代理技术实现大时间粒度下对分片日志文件的查看和下载。有益效果：本发明能够大幅度提升的日志处理的效率；能够大幅度减少了需要追溯或回滚数据的处理量，提升了系统的可维护性；能够为整个日志处理系统提供长期的弹性扩容能力。

Description

一种打包日志的增量处理方法

技术领域

本发明涉及信息技术大数据处理领域，具体来说，涉及一种打包日志的增量处理方法。主要是为了满足在给CDN客户提供服务的过程中，要对所有的记录访问日志，按照客户定制的格式化需求以小时为粒度（或者其他任意时间粒度）进行排序、压缩、打包，供客户进行下载，以便进行后续的核对和分析的诉求。

背景技术

随着信息技术的飞速发展，硬件处理能力、存储能力、网络接入带宽大幅提升，云平台和物联网技术平台经过这些年的发展，也不断壮大成熟，越来越多的数据被生产和制造出来，这些数据当中很多以日志的形式存在，需要经过格式化、排序、压缩、打包处理，以便供后续进行进一步的加工和分析处理。

因此，对于日常系统运行过程中产生的大量日志，如何利用现有的技术对大数据量的日志进行高效地格式化打包处理；如何能够在出现问题的时候进行细粒度的定位和回滚；以及如何在未来长期的运行过程中，让整个处理系统具备很强的弹性扩容能力，是摆在我们面前亟需解决的一个技术问题。

针对相关技术中的问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术中的问题，本发明提出一种打包日志的增量处理方法，以克服现有相关技术所存在的上述技术问题。

为此，本发明采用的具体技术方案如下：

该打包日志的增量处理方法，包括以下步骤：

S1、通过预先配置的实时采集工具将应用服务器在应用服务系统运行过程中产生的日志发送到异步队列kafka集群中；

S2、采用预设方法从kafka集群中读取日志记录，并打包生成原始日志文件和中间临时日志文件；

S3、采用预设规则扫描中间临时日志文件中的gzip文件列表；

S4、在某个时间窗口节点读取gzip文件中的内容，并重新排序后打包输出成分片日志文件；

S5、利用代理技术实现大时间粒度下对分片日志文件的查看和下载。

进一步的，所述采用预设方法从kafka集群中读取日志记录的步骤还包括：

S211、利用HDFS+SPARK集群开启SPARK的streaming，以1分钟为时间窗口，对kafka集群中多个分区进行异步日志的并行拉取，生成原始Spark DStream；

S212、对原始Spark DStream进行序列化处理，并保存成原始日志记录；

S213、根据业务需求规定的格式对原始日志记录进行格式化。

进一步的，所述打包生成原始日志文件和中间临时日志文件的步骤还包括：

S221、对格式化后的Spark DStream利用SPARK分布式运算进行重分区；

S222、对重新分区后的Spark DStream进行序列化处理，压缩打包成中间临时日志gzip文件，并输出到HDFS的指定目录中。

进一步的，对格式化后的Spark DStream利用SPARK分布式运算进行重分区的步骤还包括：

预先对日志记录中分钟对齐的时间戳用SPARK的distinct运算子进行去重，计算得到一共包含有N个时间戳，然后对N个时间戳进行排序后依次映射到0到N-1的分区ID空间中；

Spark DStream进行运算的时候，需要通过SPARK的重分区运算子对SparkDStream中的日志记录进行分区，分区的hash key以分钟对齐的时间戳为准，分钟对齐的时间戳为每条日志记录的时间戳除以60并取整得到对应的值得到分钟对齐的时间戳，同时在分区的过程中按照日志记录的时间戳进行排序。

进一步的，对重新分区后的Spark DStream进行序列化处理，压缩打包成中间临时日志gzip文件，并输出到HDFS的指定目录中的步骤还包括：

在输出中间临时日志文件的时候在文件名中附加一个uuid。

进一步的，采用预设规则扫描中间临时日志文件中的gzip文件列表的步骤还包括：

S31、定时启动SPARK离线任务计算程序；

S32、从数据库中读取SPARK离线任务计算程序最后一次处理的时间窗口，并往后移动一个时间窗口；

S33、若新的时间窗口的时间上限小于当前系统时间的时间窗口大小，则开始递归扫描上述S2中创建的中间临时日志文件；

S34、若中间临时日志文件的文件路径名中的该中间临时日志文件的处理时间在规定的时间窗口内，则将其加入到待处理列表中，否则过滤掉。

进一步的，在某个时间窗口节点读取gzip文件中的内容，并重新排序后打包输出成分片日志文件的步骤还包括：

S41、SPARK离线任务计算程序对读取到的待处理列表，并按照中间临时日志文件名中的分钟对齐的日志记录时间戳以分钟粒度进行分类拆分；

S42、对每一个分钟粒度时间戳进行循环处理，直到处理完当前时间窗口中的所有任务；

S43、更新当前已经处理好的时间窗口到数据库中。

进一步的，所述更新当前已经处理好的时间窗口到数据库中的步骤还包括：

将已在本循环中处理掉的中间临时日志文件移动到指定的备份目录中，然后跳转到S3，查看是否需要进行下一个时间窗口的处理。

进一步的，对每一个分钟粒度时间戳进行循环处理，直到处理完当前时间窗口中的所有任务的步骤还包括：

S421、将当前分钟粒度时间戳对应的中间临时日志文件读取到SPARK离线分析RDD中；

S422、将RDD按日志记录的时间戳执行排序操作；

S423、对排序后的RDD进行序列化，打包压缩成目标分片日志gzip文件，并输出到HDFS的指定目录中。

进一步的，利用代理技术实现大时间粒度下对分片日志文件的查看和下载的步骤还包括：

S51、日志下载网关接收用户请求；

S52、日志下载网关查找HDFS中的文件目录，并判断是否存在要查询的日志目录；

S53、日志下载网关将查询到的日志文件路径名放入内存的列表中并按照文件名进行排序；

S54、日志下载网关依次打开每个日志文件，并将日志文件的内容发送给用户端；

S55、所有日志文件的内容发送结束后，则结束整个下载处理流程。

本发明的有益效果为：

（1）本发明充分利用HDFS+SPARK大数据系统的分布式处理能力，让本发明的整个系统尽可能地连续进行工作，并用来处理实时上传上来的大量应用服务日志，而不至于因为业务规定的打包粒度的要求而等到一个相对较大的时间粒度的开始才能对日志进行处理，从而大幅度提升的日志处理的效率。

（2）本发明因为采用了比业务需求规定的更精细的粒度对日志文件进行处理，一旦发现某个时间点的日志处理有问题，可以以1分钟级精确定位到那个时间点的文件，进行细粒度的追溯和回滚处理，避免在大粒度上面进行处理，大幅度减少了需要追溯或回滚数据的处理量，提升了系统的可维护性。

（3）利用HDFS+SPARK大数据系统处理平台的弹性架构，能够为整个日志处理系统提供长期的弹性扩容能力，满足未来长期运行的需求。

（4）通过为中间临时日志文件设置时间窗口，从而避免了记录乱序的问题。

附图说明

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

图1是根据本发明实施例的一种打包日志的增量处理方法的流程图；

图2是根据本发明实施例的一种打包日志的增量处理方法的部署架构图

图3是根据本发明实施例的一种打包日志的增量处理方法的HDFS的指定目录示意图；

图4是根据本发明实施例的一种打包日志的增量处理方法的业务需求确定目标文件路径示意图；

图5是根据本发明实施例的一种打包日志的增量处理方法的目标文件路径中的时间信息的示意图。

具体实施方式

为进一步说明各实施例，本发明提供有附图，这些附图为本发明揭露内容的一部分，其主要用以说明实施例，并可配合说明书的相关描述来解释实施例的运作原理，配合参考这些内容，本领域普通技术人员应能理解其他可能的实施方式以及本发明的优点，图中的组件并未按比例绘制，而类似的组件符号通常用来表示类似的组件。

根据本发明的实施例，提供了一种打包日志的增量处理方法。

现结合附图和具体实施方式对本发明进一步说明，如图1所示，根据本发明实施例的打包日志的增量处理方法，包括以下步骤：

S1、通过预先配置的实时采集工具将应用服务器在应用服务系统运行过程中产生的日志发送到异步队列kafka集群中；

S2、采用预设方法从kafka集群中读取日志记录，并打包生成原始日志文件和中间临时日志文件；

S3、采用预设规则扫描中间临时日志文件中的gzip文件列表；

S4、在某个时间窗口节点读取gzip文件中的内容，并重新排序后打包输出成分片日志文件；

S5、利用代理技术实现大时间粒度下对分片日志文件的查看和下载。

在一个实施例中，所述采用预设方法从kafka集群中读取日志记录的步骤还包括：

S211、利用HDFS+SPARK集群开启SPARK的streaming，以1分钟为时间窗口，对kafka集群中多个分区进行异步日志的并行拉取，生成原始Spark DStream；因为拉取的异步日志在1分钟的时间窗口之内，数据量是可控的，完全可以存储在HDFS+SPARK集群服务器的内存中，即存储在位于Spark的DStream中，而这个DStream分布在HDFS+SPARK集群节点服务器的内存的中；

S212、对原始Spark DStream进行序列化处理，并保存成原始日志记录；原始日志记录用来满足未来的追溯和回滚的需求；

如图3所示，为了能够满足未来的追溯和回滚的需求，将原始日志记录不做任何处理，全部序列化出来用gzip压缩存储到HDFS的指定目录中，这里的文件目录名字中的时间以实际处理的时间来设置；

S213、根据业务需求规定的格式对原始日志记录进行格式化。这一步骤利用DStream本身的分区特性，在每个分区各自所在的SPARK集群节点服务器上并行地进行格式化处理，甚至可以根据业务需要对不符合规范的原始日志记录进行过滤操作。

在一个实施例中，所述打包生成原始日志文件和中间临时日志文件的步骤还包括：

S221、对格式化后的Spark DStream利用SPARK分布式运算进行重分区；重新分区后每个分区按原始日志记录的时间戳对齐到1分钟粒度；

S222、对重新分区后的Spark DStream进行序列化处理，压缩打包成中间临时日志gzip文件，并输出到HDFS的指定目录中；生成的中间临时日志gzip文件按照原始日志记录的时间戳对齐到1分钟粒度，但是可能会因为应用服务器日志上传乱序的问题导致可能有多个，需要S3进行再次排序合并处理。

如图4所示，这个步骤比较简单，由于S221已经使每个分区都仅包含一个分钟对齐的时间戳了，因此只要将分钟对齐的时间戳按照业务需求确定目标文件路径即可。

在一个实施例中，对格式化后的Spark DStream利用SPARK分布式运算进行重分区的步骤还包括：

预先对日志记录中分钟对齐的时间戳用SPARK的distinct运算子进行去重，计算得到一共包含有N个时间戳，然后对N个时间戳进行排序后依次映射到0到N-1的分区ID空间中；

Spark DStream进行运算的时候，需要通过SPARK的重分区运算子对SparkDStream中的日志记录进行分区，分区的hash key以分钟对齐的时间戳为准，分钟对齐的时间戳为每条日志记录的时间戳除以60并取整得到对应的值得到分钟对齐的时间戳，同时在分区的过程中按照日志记录的时间戳进行排序。

在一个实施例中，对重新分区后的Spark DStream进行序列化处理，压缩打包成中间临时日志gzip文件，并输出到HDFS的指定目录中的步骤还包括：

在输出中间临时日志文件的时候在文件名中附加一个uuid。

在连续处理的过程中可能对于一个分钟对齐的时间戳，会对应生成若干个中间临时日志文件，需要交给S3来进一步进行最后的处理。

在一个实施例中，采用预设规则扫描中间临时日志文件中的gzip文件列表的步骤还包括：

S31、定时启动SPARK离线任务计算程序；

S32、从数据库中读取SPARK离线任务计算程序最后一次处理的时间窗口，并往后移动一个时间窗口；

S33、若新的时间窗口的时间上限小于当前系统时间的时间窗口大小，则开始递归扫描上述S2中创建的中间临时日志文件；

S34、若中间临时日志文件的文件路径名中的该中间临时日志文件的处理时间在规定的时间窗口内，则将其加入到待处理列表中，否则过滤掉。

其中，中间临时日志文件的处理时间窗口按照业务允许的范围来设定，譬如窗口宽度定义为5分钟，如果当前开始处理的时间为10:21分，则当前系统时间对应的时间窗口区间为[10:10,10:15]。对中间临时日志文件设置时间窗口主要是为了解决某个分钟对齐的时间戳日志处理完成了，一段时间以后又有属于这个时间戳范围的日志进来，因为之前属于这个时间戳范围的日志已经进行了打包，即使新的日志可以追加进去，也会因为待处理的日志记录的时间戳要比已经打包进去的日志时间戳要早，而产生记录乱序的问题。当然，如果不考虑日志乱序的问题，则可以将时间窗口放开。

在一个实施例中，在某个时间窗口节点读取gzip文件中的内容，并重新排序后打包输出成分片日志文件的步骤还包括：

S41、SPARK离线任务计算程序对读取到的待处理列表，并按照中间临时日志文件名中的分钟对齐的日志记录时间戳以分钟粒度进行分类拆分；如表格1所示拆分：

表格 1 以1分钟为粒度对日志文件列表进行拆分

S42、对每一个分钟粒度时间戳进行循环处理，直到处理完当前时间窗口中的所有任务；

S43、更新当前已经处理好的时间窗口到数据库中。

在一个实施例中，所述更新当前已经处理好的时间窗口到数据库中的步骤还包括：

将已在本循环中处理掉的中间临时日志文件移动到指定的备份目录中，然后跳转到S3，查看是否需要进行下一个时间窗口的处理。

在一个实施例中，对每一个分钟粒度时间戳进行循环处理，直到处理完当前时间窗口中的所有任务的步骤还包括：

S421、将当前分钟粒度时间戳对应的中间临时日志文件读取到SPARK离线分析RDD中；

S422、将RDD按日志记录的时间戳执行排序操作；

S423、对排序后的RDD进行序列化，打包压缩成目标分片日志gzip文件，并输出到HDFS的指定目录中。

如图5所示，生成的目标文件路径中的时间信息以当前处理的日志文件包含的分钟粒度时间戳来设置。这样子，如果在给用户输出打包日志的时候，规定需要以1小时为粒度，那么最终对于2019年12月2日10点的打包日志，将实际包括60个分片文件（每分钟1个），而且每个1分钟粒度的分片日志文件内部是已经排好序的。如表格2所示：

表格 2 打包日志分片文件的存储路径格式

由于最终生成的打包日志文件是按1分钟为粒度分片进行保存的，如表格2所显示的那样，而业务要求是以更大的粒度（1小时或者1天的粒度）给用户打包输出，因此必须对这些分片文件重新进行整合，然后输出为业务规定的粒度。本发明利用gzip压缩文件可以对压缩后的分片文件直接进行拼接，拼接后可以无缝把所有内容解压出来，无需先解压分片文件，再拼接解压后的分片文件，最后再重新压缩的方式来处理的特性，利用日志下载代理服务器在下载请求到来的时候实时拼接的方式，大大降低了后续的处理难度。本发明基于gzip的这个特性，不进行分片文件的物理合并处理，而是通过日志下载网关提供虚拟打包合并的方式来实现。从而，在满足业务需求的情况下，又提供了相当的灵活性。最终输出的大时间粒度的日志文件，因为采用的是在最后输出给用户的时候实时对分片文件合并方法，所以在任何时候对最终需要输出的日志文件可以以分片为单位被增加、修改、删除的。因此，可以实现至少以下两个方面的特性：1. 假如要求的是1小时粒度的打包日志输出，那么不必等到这个小时完全结束才对这个小时的全量数据进行打包，中间就可以看到输出的日志文件；2. 如果中间发现有部分的分片日志文件处理有问题，完全可以对这部分的分片日志文件进行精确定位并回滚，然后利用备份下来的原始日志文件重新进行计算、打包，最后替换有问题的分片日志文件，这样子大大缩小的回滚处理的粒度，提高了处理的效率。

在一个实施例中，利用代理技术实现大时间粒度下对分片日志文件的查看和下载的步骤还包括：

S51、日志下载网关接收用户请求；比如：要求获取2019年12月2日10点钟这1小时粒度的打包日志。

S52、日志下载网关查找HDFS中的文件目录，并判断是否存在要查询的日志目录；如表格2，查找/outputlog/20191202/目录下面，是否有10开头的gzip文件，如果没有，就提示需要下载的日志文件不存在。

S53、日志下载网关将查询到的日志文件路径名放入内存的列表中并按照文件名进行排序；比如/outputlog/20191202/下面以10开头的日志文件；

S54、日志下载网关依次打开每个日志文件，并将日志文件的内容发送给用户端；

S55、所有日志文件的内容发送结束后，则结束整个下载处理流程。

如图2所示，为整个日志打包系统的部署架构：

图的左侧，多个应用服务器在应用服务系统运行的过程中，在不断的产生各种日志，通过一些实时采集工具将应用服务器的日志发送到异步队列kafka中。图的中间，HDFS+SPARK集群进行分布式运算，来进行日志文件的格式化、排序、压缩、打包操作，最终生成打包好的分片（譬如以1分钟为粒度）日志文件存储到HDFS的指定目录中。图的右侧，日志下载网关为查看和下载日志的用户提供虚拟视图，按照业务所要求的更大的时间粒度（譬如1小时或者1天粒度）提供日志的查看和下载。

综上所述，本发明充分利用HDFS+SPARK大数据系统的分布式处理能力，让本发明的整个系统尽可能地连续进行工作，并用来处理实时上传上来的大量应用服务日志，而不至于因为业务规定的打包粒度的要求而等到一个相对较大的时间粒度的开始才能对日志进行处理，从而大幅度提升的日志处理的效率。本发明因为采用了比业务需求规定的更精细的粒度对日志文件进行处理，一旦发现某个时间点的日志处理有问题，可以以1分钟级精确定位到那个时间点的文件，进行细粒度的追溯和回滚处理，避免在大粒度上面进行处理，大幅度减少了需要追溯或回滚数据的处理量，提升了系统的可维护性。利用HDFS+SPARK大数据系统处理平台的弹性架构，能够为整个日志处理系统提供长期的弹性扩容能力，满足未来长期运行的需求。通过为中间临时日志文件设置时间窗口，从而避免了记录乱序的问题。

在本发明中，除非另有明确的规定和限定，术语“安装”、“设置”、“连接”、“固定”、“旋接”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系，除非另有明确的限定，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种打包日志的增量处理方法，其特征在于，该方法包括以下步骤：

S1、通过预先配置的实时采集工具将应用服务器在应用服务系统运行过程中产生的日志发送到异步队列kafka集群中；

S2、采用预设方法从kafka集群中读取日志记录，并打包生成原始日志文件和中间临时日志文件；

S3、采用预设规则扫描中间临时日志文件中的gzip文件列表；

S4、在某个时间窗口节点读取gzip文件中的内容，并重新排序后打包输出成分片日志文件；

S5、利用代理技术实现大时间粒度下对分片日志文件的查看和下载;

采用预设规则扫描中间临时日志文件中的gzip文件列表的步骤还包括：

S31、定时启动SPARK离线任务计算程序；

S32、从数据库中读取SPARK离线任务计算程序最后一次处理的时间窗口，并往后移动一个时间窗口；

S33、若新的时间窗口的时间上限小于当前系统时间的时间窗口大小，则开始递归扫描上述S2中创建的中间临时日志文件；

S34、若中间临时日志文件的文件路径名中的该中间临时日志文件的处理时间在规定的时间窗口内，则将其加入到待处理列表中，否则过滤掉。

2.根据权利要求1所述的一种打包日志的增量处理方法，其特征在于，所述采用预设方法从kafka集群中读取日志记录的步骤还包括：

S211、利用HDFS+SPARK集群开启SPARK的streaming，以1分钟为时间窗口，对kafka集群中多个分区进行异步日志的并行拉取，生成原始Spark DStream；

S212、对原始Spark DStream进行序列化处理，并保存成原始日志记录；

S213、根据业务需求规定的格式对原始日志记录进行格式化。

3.根据权利要求2所述的一种打包日志的增量处理方法，其特征在于，所述打包生成原始日志文件和中间临时日志文件的步骤还包括：

S221、对格式化后的Spark DStream利用SPARK分布式运算进行重分区；

S222、对重新分区后的Spark DStream进行序列化处理，压缩打包成中间临时日志gzip文件，并输出到HDFS的指定目录中。

4. 根据权利要求3所述的一种打包日志的增量处理方法，其特征在于，对格式化后的Spark DStream利用SPARK分布式运算进行重分区的步骤还包括：

预先对日志记录中分钟对齐的时间戳用SPARK的distinct运算子进行去重，计算得到一共包含有N个时间戳，然后对N个时间戳进行排序后依次映射到0到N-1的分区ID空间中；

Spark DStream进行运算的时候，需要通过SPARK的重分区运算子对Spark DStream中的日志记录进行分区，分区的hash key以分钟对齐的时间戳为准，分钟对齐的时间戳为每条日志记录的时间戳除以60并取整得到对应的值得到分钟对齐的时间戳，同时在分区的过程中按照日志记录的时间戳进行排序。

5. 根据权利要求3所述的一种打包日志的增量处理方法，其特征在于，对重新分区后的Spark DStream进行序列化处理，压缩打包成中间临时日志gzip文件，并输出到HDFS的指定目录中的步骤还包括：

在输出中间临时日志文件的时候在文件名中附加一个uuid。

6.根据权利要求1所述的一种打包日志的增量处理方法，其特征在于，在某个时间窗口节点读取gzip文件中的内容，并重新排序后打包输出成分片日志文件的步骤还包括：

S41、SPARK离线任务计算程序对读取到的待处理列表，并按照中间临时日志文件名中的分钟对齐的日志记录时间戳以分钟粒度进行分类拆分；

S42、对每一个分钟粒度时间戳进行循环处理，直到处理完当前时间窗口中的所有任务；

S43、更新当前已经处理好的时间窗口到数据库中。

7.根据权利要求6所述的一种打包日志的增量处理方法，其特征在于，所述更新当前已经处理好的时间窗口到数据库中的步骤还包括：

将已在本循环中处理掉的中间临时日志文件移动到指定的备份目录中，然后跳转到S3，查看是否需要进行下一个时间窗口的处理。

8.根据权利要求6所述的一种打包日志的增量处理方法，其特征在于，对每一个分钟粒度时间戳进行循环处理，直到处理完当前时间窗口中的所有任务的步骤还包括：

S421、将当前分钟粒度时间戳对应的中间临时日志文件读取到SPARK离线分析RDD中；

S422、将RDD按日志记录的时间戳执行排序操作；

S423、对排序后的RDD进行序列化，打包压缩成目标分片日志gzip文件，并输出到HDFS的指定目录中。

9.根据权利要求1所述的一种打包日志的增量处理方法，其特征在于，利用代理技术实现大时间粒度下对分片日志文件的查看和下载的步骤还包括：

S51、日志下载网关接收用户请求；

S52、日志下载网关查找HDFS中的文件目录，并判断是否存在要查询的日志目录；

S53、日志下载网关将查询到的日志文件路径名放入内存的列表中并按照文件名进行排序；

S54、日志下载网关依次打开每个日志文件，并将日志文件的内容发送给用户端；

S55、所有日志文件的内容发送结束后，则结束整个下载处理流程。

Images