CN111597157A

CN111597157A - 一种改进日志处理系统架构的方法

Info

Publication number: CN111597157A
Application number: CN202010267270.4A
Authority: CN
Inventors: 何熊熊; 李欢
Original assignee: Zhejiang University of Technology ZJUT
Current assignee: Zhejiang University of Technology ZJUT
Priority date: 2020-04-08
Filing date: 2020-04-08
Publication date: 2020-08-28

Abstract

一种改进日志处理系统架构的方法，架构从下往上依次为数据集成层、文件存储层、统计分析层和数据可视化模块。基于Kafka提供的Connector接口实现了一个HDFSConnector可以做到将收集到的日志消息实时地存储到HDFS分布式文件系统中，为后续的离线统计、分析、挖掘、预测提供数据支持，同时提出了一种新的日志处理架构，它与传统的架构不同，它可以同时支持离线计算和实时计算，并且它更具有拓展性，也具有较高的吞吐量，此外还简化了系统组件中的数量，可维护性也更好。

Description

一种改进日志处理系统架构的方法

技术领域

本发明涉及网络技术领域，具体涉及一种改进日志处理系统架构的方法。

背景技术

随着科技的发展，我们的生活也越来越信息化，大数据已与我们的工作生活密不可分，它的存在给商业、医疗、航空、农业等其他领域的发展起到了积极的作用。从商业价值上看，大数据技术在统计分析用户行为，挖掘潜在商业价值上已有非常广泛的应用。而要做后续的统计分析工作则需要将数据传送到统计分析的平台中。数据源，在用户行为分析中主要是指移动端日志和web日志。如今收集日志的方式多种多样，数据源已经存在了。那么，将收集到的日志接入到统计分析平台，并且保证数据接入系统的稳定性、高效性都是至关重要的，因为这些都将直接影响着后续数据分析、挖掘的质量。

在Hadoop生态系统传统的计算模型中，日志的收集工作主要是由Flume开源系统完成。首先是通过在主机.上部署Agent，由Agent来负责按照一定的收集频率将源源不断产生的日志消息传输到Channel,最后再由Flume提供的Sink完成数据到下一个系统的需求。这里的Sink组件，若要是想对数据进行离线分析则可以使用HDFS Sink完成存储到HDFS分布式文件系统的功能，然后经由后面的Hive的分析将数据进行统计分析。若是需要对数据进行实时计算则会存在一个Flume收集到的数据无法按时按需的传送到实时计算框架中的问题，因此这种框架为了想要支持实时计算必须解决这个问题。现如今比较主流的处理方式是接入一个Kafka，通过Kafka这种消息中间件负责做一个缓冲可以将Flume收集到的信息做一个实时消费，接入到实时计算框架。

发明内容

为了克服传统日志架构组件复杂并且效率缓慢的问题，本发明利用Spark平台提供的Spark Streaming组件；将指定的时间片段将流数据积累为RDD，继而对每个RDD进行微批次式处理，经过这种处理方式来处理大规模的流式数据，与Kafka集群以及HDFS结合，实现对产生的日志数据进行处理，从其中比较改进的日志处理系统结构与业界流行的日志处理系统架构得出改进的日志处理系统架构具有更好的简单性，更加灵活的处理方式，并且比传统的方式更节省系统资源。

本发明解决其技术问题所采用的技术方案是：

一种改进日志处理系统架构的方法，架构从下往上依次为数据集成层、文件存储层、统计分析层和数据可视化模块，所述数据集成层是用来将数据源导入文件存储层，或是将数据源导入计算模型，这里的数据源是用户对Nginx服务器一次请求的记录；所述文件存储层是将数据源持久化到分布式文件系统供离线分析使用，这里的文件分布式系统采用HDFS；所述计算模型层主要分成两个部分，其中第一部分用来将存储到分布式文件系统中的数据信息导入到分布式计算模型Spark中进行离线分析，这里的离线批处理模型采用Spark on Yarn；另一部分用来将来源自数据集成层的信息导入实时计算模型进行实时计算，选择Spark作为离线分析的计算模型，选用Spark Streaming进行实时分析只需要维护并监控Spark集群。

进一步，首先当一个请求打向nginx后，使用lua脚本完成日志整理：例如统一处理的日志格式，去除无效的请求等；然后根据不同的nginx日志，划分不同的topic；进一步使用lua脚本实现producer异步发送到kafka集群，再进一步根据业务逻辑的需要分业务的对日志数据进行消费。

本发明的有益效果主要表现在：

(1)与传统的日志处理系统架构相比，本发明可以同时支持离线计算和实时计算，并且它具有良好的扩展性，较高的吞吐量，也具有高时效性。

(2)本发明与传统日志处理系统架构相比简化了系统中的组件数量，可维护性也更好，从而更加节省系统资源。

附图说明

图1是本发明的整个系统架构图；

图2是Kafka-Data-Pipeline的抽象架构图；

图3是High Available的HDFS架构图；

图4是Spark内部运行逻辑图。

具体实施方式

下面结合附图对本发明作进一步描述。

参照图1～图4，一种改进日志处理系统架构的方法，此日志处理平台分为四层，架构从下往上依次为数据集成层，文件存储层，统计分析层和数据可视化模块。所述数据集成层是用来将数据源导入文件存储层，或是将数据源导入计算模型，这里的数据源主要市用户对Nginx服务器一次请求的记录；所述文件存储层主要是将数据源持久化到分布式文件系统供离线分析使用，这里的文件分布式系统采用HDFS；所述计算模型层主要分成两个部分，其中第一部分用来将存储到分布式文件系统中的数据信息导入到分布式计算模型Spark中进行离线分析，这里的离线批处理模型采用Spark on Yarn，另一部分用来将来源自数据集成层的信息导入实时计算模型进行实时计算，在这里采用Spark Streaming，这里是出于两点考虑，首先因为是选择Spark作为离线分析的计算模型，那么选用SparkStreaming进行实时分析这样只需要维护并监控Spark集群。

参照图2，本发明提出了一种新型的日志收集，聚合以及传输到下一个系统的方式，该方式不同于传统的架构模式，这里我们称其为Kafka-Data-Pipeline，简称KDP。KDP需要满足高时效性，高吞吐量，高可扩展性三个要求。

从抽象的角度看，一条信息流入KDP，然后通过KDP的两种消费者组进行消费。数据的消费分为两种途径，第一条路径通过Kafka Connector链接到离线处理框架进行离线计算，另一条路径是传入到Kafka中的数据直接写入到实时计算框架进行实时计算。核心部件功能说明如表1所示。

表1

各个组件协调工作，完成数据的流式处理，具体工作流程如下：

1.当一个用户在浏览器的地址栏输入一个url进行访问时，就会有一条对应的日志记录用户的访问时间，IP地址等消息。用户的一次性的Request将产生对应的消息

2.当用户收到请求的时候，通过lua脚本将发送到Nginx中的消息做一个预处理，并通过lua-resty-kafka组件将数据发向kafka

3.经过1，2两个步骤后，用户的访问消息就存放到Kafka集群上以下根据业务的需求数据将分流成两个方向。

4.由于做离线分析时需要将数据拷贝到HDFS中，需要一个组件可以完成这个功能，这个组件是自行开发的HDFS Sink Connector

5.做实时分析的时候需要将数据接入到Spark，通过SparkStreaming-kafka组件完成

参照图3，这一层主要是负责将每一条日志信息存入分布式文件系统中以便于下一步的利用。起到存储作用的分布式文件系统主要选择HDFS。

在Hadoop2.0之前，NameNode(NN)在HDFS集群中存在单点故障。单点故障问题是指集群中仅仅存在一个NN结点，加入这个NN结点所在的服务器出现了宕机，会使整个集群都宕机。为了解决这个问题，通过分析可知有两方面的原因是影响HDFS的可用性的因素。首先在无法预知的情况下，如果NN结点在的服务器出现了宕机，直到结点NN被重启，整个集群都是无法正常使用的，其次在可预测的情形下，比如NN结点所在的服务器的软硬件升级，将导致集群暂停使用。

为了解决上述问题，Hadoop官方文档提供的两种方案来解决HDFS的高可用性问题。核心思想是在一个集群里运行active namenode和stand by namenode这两个结点来解决问题。在常见的高可用集群中，有两个不同的服务器当作NameNode结点。不论何时何刻，仅仅有一台服务器是active状态的，而另一台服务器是stand by状态的。Active NameNode结点负责用户的操作，stand by name node则是用来维持完备的状态，必要时提供故障恢复。

为了使两个NameNode结点所存储的数据不出现不一致冲突，需要一个JournalNodes守护进程，这两个NameNode分别与这个守护进程通信。假如Active NameNode进行了修改操作，它需要与JournalNodes进行实时通信，并且Stand by Name Node检测着edits log的变化，发现变化时更新其内部的命名空间。当故障出现时候Stand By NameNode会从守护进程读取Edits信息，并且将自己转换为Active状态，为了比较迅速的恢复故障，Stand by Name Node中存放着文件块的位置信息。为了实现高可用，集群中的所有DataNode结点都配置好了Active Name Node和Stand By NameNode的位置信息，并向结点发送Heartbeat以及文件的位置信息。

参照图4，本发明的计算模型层采用Spark计算模型。由于Apache Spark支持批量数据的处理和数据的流式处理。而其他的系统比如Storm只专注于数据流式处理，Mapreduce只支持批处理。Spark具有统一的编程模型可同时支持批处理和流式处理，所以本发明在文本中采用Spark作为执行引擎，特别体现在以下几个方面。

1.能在故障报错与straggler的情况下迅速恢复状态；

2.更好的负载均衡与资源使用；

3.静态数据集与流式数据是可整合的并且支持交互查询；

4.内置了许多高级的算法库。

本说明书的实施例所述的内容仅仅是对发明构思的实现形式的列举，仅作说明用途。本发明的保护范围不应当被视为仅限于本实施例所陈述的具体形式，本发明的保护范围也及于本领域的普通技术人员根据本发明构思所能想到的等同技术手段。

Claims

1.一种改进日志处理系统架构的方法，其特征在于，架构从下往上依次为数据集成层、文件存储层、统计分析层和数据可视化模块，所述数据集成层是用来将数据源导入文件存储层，或是将数据源导入计算模型，这里的数据源是用户对Nginx服务器一次请求的记录；所述文件存储层是将数据源持久化到分布式文件系统供离线分析使用，这里的文件分布式系统采用HDFS；所述计算模型层分成两个部分，其中第一部分用来将存储到分布式文件系统中的数据信息导入到分布式计算模型Spark中进行离线分析，这里的离线批处理模型采用Spark on Yarn，另一部分用来将来源自数据集成层的信息导入实时计算模型进行实时计算，选择Spark作为离线分析的计算模型，选用Spark Streaming进行实时分析只需要维护并监控Spark集群。

2.如权利要求1所述的一种改进日志处理系统架构的方法，其特征在于，首先当一个请求打向nginx后，使用lua完成日志整理：例如统一处理的日志格式，去除无效的请求等；然后根据不同的nginx日志，划分不同的topic；进一步使用lua脚本实现producer异步发送到kafka集群，再进一步根据业务逻辑的需要分业务的对日志数据进行消费。