Hadoop集群异常节点实时检测与诊断算法

潘伟博， 汪海涛， 姜 瑛， 陈 星， 田 帅

(昆明理工大学 信息工程与自动化学院， 云南 昆明 650500)

Hadoop[1]是一种分布式系统平台，可以有效地划分大规模数据，以并行方式均匀地映射和分发任务，目前已经被广泛应用于大数据与云计算等领域[2]。但随着Hadoop集群节点数量的增加，集群以及节点在管理和维护方面的困难也不断增加。当Hadoop集群中某些节点发生异常时，会导致集群整体作业性能降低，但用户很难检测和识别导致节点异常的原因。首先，Hadoop日志数据难以读取且不规则，并且没有直接的方法来判断节点是否发生异常；其次，发生异常时日志数据中关于节点错误的信息很少。因此，及时发现异常节点并诊断原因是至关重要的。

在早期的研究中，通常使用离线检测技术分析历史数据来诊断Hadoop集群中的异常节点[3-4]。Pan等[5]提出了一种基于体系结构层性能指标分析的方法，通过Ganesha工具检测Hadoop集群中的异常节点。Guo等[6]提出了一种针对Hadoop集群日志数据进行自动化分析方法，通过提取分布式系统执行控制流和数据流的状态进行初步节点异常检测。Tang等[7]提出了一种Hadoop集群异常检测视图工具，从时间、空间与性能度量三个性能指标分析Hadoop集群中可能出现的问题。随着集群节点数量的不断增加，实时检测异常节点变得越来越重要。Manjunatha等[8]基于Spark框架提出了一种混合分层算法，通过学习每个备份端点的特征，自动地选择一组异常值进行检测。Fathnia等[9]提出了一种轻量级异常检测工具，结合日志信息分析和系统指标检测异常节点。Habeeb等[10]提出了一种适用于大规模在线数据流的异常检测策略，进行异常节点检测。但此类方法需要在实时监控之前训练数据，训练过程不仅耗时，而且训练得到的阈值会随着Hadoop集群规模的增大或者减小而失效。

针对上述问题，本文提出了一种Hadoop集群异常节点实时检测与诊断算法，检测Hadoop集群中的异常节点，并诊断导致节点发生异常的根本原因。

1 原理及方法

1.1 算法概述

本文提出的算法分为异常节点检测与诊断节点异常根本原因两个阶段，整体架构如图1所示。首先基于正常状态下各节点性能相似性原理[11]，使用Logstash工具收集Hadoop集群节点运行日志中的任务状态信息，同时将reduce任务个数换为map任务个数，使用异常节点检测算法捕获异常节点。发现异常节点后，利用Perf性能分析工具收集体系结构性能信息，再通过异常节点诊断算法诊断导致该节点异常的原因。

图1 Hadoop集群异常节点实时 检测与诊断算法整体框架

1.2 数据获取

YARN是Hadoop集群资源管理器，将资源管理与任务调度监控拆分为单独的守护进程，并且YARN拥有一个全局资源管理器和每个应用程序管理器。容器是YARN对资源的抽象，并且封装了节点上的大量资源。在Hadoop 2.0之后，基于YARN的应用程序管理器作为一个编号为000001的任务在容器中运行，可以将其视为具有所有者日志的特殊任务，该任务类似于map任务和reduce任务。容器中的syslog文件实时记录着Hadoop任务的运行状态，分别记录分配map任务的类别、时间、任务编号与运行节点等信息。通过分析收集到的日志数据，就可以获得当前Hadoop集群的运行状态，并利用正常状态下节点之间的行为相似性来检测异常。为了分析导致节点发生异常的原因，本文定义了3种基于体系结构层的性能指标，分别是CPU使用率、内存使用率与I/O负载。通过定期从集群节点收集3种性能指标数据，并分析该时刻系统结构层性能指标状态来确定导致节点异常的原因。系统结构性能指标信息如表1所示。

表1 体系结构性能指标

1.3 异常节点实时检测与诊断

1.3.1 异常节点检测算法

Hadoop集群节点通常具有类似的软件和硬件条件，因此当有新任务提交给集群时，分配给每个节点的逻辑计算数量和数据处理大小应大致相同，且Hadoop集群中所有节点的执行能力都遵循高斯分布。若某个节点发生异常，则该节点的执行能力将下降。为了减少map任务和reduce任务之间的耦合性对Hadoop集群异常节点检测的影响，本文将集群中每个节点的reduce任务转换为map任务。因为Hadoop集群执行任务时map阶段和reduce阶段并未完全分开执行，map任务完成一部分后就会占用任务槽，然后立刻执行reduce任务，并且reduce任务周期普遍较长，甚至会执行到该作业结束。所以通过将reduce任务转换为map任务可以同时考虑map任务和reduce任务，统计出执行reduce任务时的耗时能够执行的map任务数量。例如，reduce任务已运行1 min，与此同时，在同一节点上的map任务的平均运行时间为20 s，则可以将reduce任务转换为等效的3个map任务。

此外，为了避免节点异常而导致测量时间不准确，本文定义最近一次完成map任务的时间为转换时的评估标准。因为最近一次的map任务执行时间可以反映出节点当前的性能。本文定义集群中每个节点的任务逻辑完成数量为同一时间段内reduce任务完成数量转化为map任务的数量与map任务完成数量之和，并且该任务逻辑完成数量服从高斯分布。此外，考虑到本文搭建小规模集群(节点数量小于20)，因此使用t检验确定阈值，其中阈值可以根据给定的置信度和自由度来确定。同时，Hadoop集群中高于阈值的节点，若该节点的逻辑完成数量大于所有节点的逻辑完成数量平均值，该节点是误报的正常节点；反之，则其为异常节点。异常节点实时检测算法描述见算法1。

算法1 异常节点实时检测算法

输入：Hadoop集群节点nodei(i=1，2，…，n)。

输出：异常节点abnomal_nodej(j=1，2，…，m)。

步骤1：将集群节点nodei执行reduce任务数量转换为map任务数量，即逻辑转换数量Numreduce→map；

步骤2：将节点nodei同一时间段内map任务数量与逻辑转换数量Numreduce→map相加，得到节点nodei的任务逻辑完成数量nodeiNum；

步骤3：计算该时间段内Hadoop集群中节点的任务逻辑完成数量的平均值nodeNumavg和方差nodeNumvar；

步骤4：通过设定的置信度和自由度得到t检验的阈值Tth；

步骤5：通过节点nodei任务逻辑完成数量nodeiNum、任务逻辑完成数量的平均值nodeNumavg和方差nodeNumvar以及自由度freedom，计算出节点nodei的t检验分数tscore；

步骤6：将节点nodei的t检验分数tscore和阈值Tth比较，任务逻辑完成数量nodeiNum和平均值nodeNumavg比较，得出该节点是否发生异常。

算法1中的nodei表示Hadoop集群中的第i个节点，abnomal_nodej为第j个异常节点，tscore是t检验分数。当tscore大于阈值Tth，并且任务的逻辑完成数量nodeiNum小于平均值nodeNumavg时，表示该节点为离群节点，即此时检测到该节点发生异常。

1.3.2 异常节点诊断算法

Hadoop集群节点发生异常通常是由多种因素综合导致，本文主要讨论CPU使用率、内存使用率与I/O负载3种性能指标导致的异常。当检测到某个节点发生异常时，使用Pref性能分析工具周期性的收集并输出该节点此时刻的体系结构层指标信息，然后结合上文提出的异常节点实时检测算法诊断出导致节点异常的根本原因。CPU使用率、内存使用率与I/O负载率的计算公式如下：

(1)

(2)

(3)

其中CPUusage、Memeryusage、IOutil分别表示Hadoop集群节点的CPU使用率、内存使用率、I/O负载率。

本文基于Hadoop集群节点的相似性诊断导致节点异常的原因。Hadoop集群中的节点在负载或者闲置的时候，各个节点的性能指标大致相同，当某个节点异常时，该节点的性能就会发生变化，并且可以表现在系统性能指标的使用率上。本文结合异常节点实时检测算法和Hadoop集群节点的相似性诊断导致节点异常的原因。异常节点诊断算法见算法2。

算法2 异常节点诊断算法

输入：异常节点abnomal_nodej(j=1，2，…，m)。

步骤1：计算异常节点abnomal_nodej的CPU使用率CPUusage、内存使用率Memoryusage、I/O负载率IOutil；

步骤2：将计算得到的CPUusage、Memoryusage和IOutil三种系统结构指标按照升序分别排序；

步骤3：将CPUusage、Memoryusage和IOutil使用率低于20%和高于80%的标记为异常指标abnomal_indexi。

2 实验

2.1 实验设置

本文实验部署6个服务器节点，包括1个主节点和5个从节点，详细的Hadoop集群节点配置信息如表2所示。本文使用WordCount和TeraSort基准测试程序用于评估本文提出算法的有效性，其中WordCount程序用于计算给定输入集中每个单词的出现次数，TeraSort程序是对TeraGen程序生成的测试数据进行排序，然后通过TeraValidate程序校验排序的准确性。本文实验搭建集群规模小于20个节点，符合小样本高斯分布，因此设置t检验的置信度freedom为0.05(符合高斯分布)。通过计算得到阈值Tth为1.94，同时设置Spark Streaming的批处理周期为5 s。

表2 服务器配置信息

在实验中，本文模拟注入3种常见异常进行实验。利用stress工具对CPU和内存以及I/O生成负载。具体地，在作业运行之前和正在运行时向集群中的节点注入异常，然后评估异常对节点的性能影响，具体的异常注入信息如表3所示。

表3 异常注入详细信息

实验分为两个阶段，第一阶段在Hadoop集群运行之前向节点注入异常，再执行基准测试程序。然后利用节点相似性原理检测异常节点，最后再分析体系结构性能指标诊断节点异常的根本原因。第二阶段，在Hadoop集群运行期间向节点注入异常，然后在集群上运行基准测试程序。为了评估本文提出算法的有效性，本实验分别使用精确率(Precision)、召回率(Recall)以及F1-score三个评价指标进行评估，其中三个评价指标的值越高，表示模型的性能越好。

2.2 实验结果分析

本文在WordCount和TeraSort两个基准测试程序上进行了实验。通过对比不同状态下的节点行为和集群中节点的各种资源利用率，来检测和诊断集群中的异常节点。实验结果表明本文提出的算法可以有效地实时检测和诊断Hadoop集群中的异常节点。具体的实验结果如图2—图9所示。

图2 正常状态节点行为 图3 正常状态节点资源使用率

由图2和图3可知，在Hadoop集群节点没有发生异常的情况下，各个节点的行为基本一致，并且各个节点tscore分数都小于阈值Tth，该时刻Hadoop集群中各个节点的各种资源使用率也大致相同。从图4和图5可知，节点node5的任务逻辑完成数量nodeiNum远远小于其他节点，tscore分数也大于阈值Tth，说明该节点发生异常。并且该时刻该异常节点的CPU使用率大于80%，该节点异常的根本原因是CPU异常导致。通过观察图6和图7可以发现，节点node5的行为同其他节点差异较大，同时tscore分数也大于阈值Tth，通过算法1可以检测到该节点发生异常，然后通过对该节点各种资源使用率的分析可知，node5节点的内存使用率大于80%，则内存异常定义为导致该节点异常的原因。通过图8和图9可知节点node5的tscore分数也大于阈值Tth，说明节点node5被检测到异常，再通过分析各种资源使用率可发现该节点的I/O负载小于20%，说明I/O负载异常是导致该节点异常的根本原因。

图4 CPU异常节点行为 图5 CPU异常节点资源使用率

图6 内存异常节点行为 图7 内存异常节点资源使用率

图8 I/O异常节点行为 图9 I/O异常节点资源使用率

为了进一步验证本文提出算法的准确性和有效性，将本文提出的算法和传统算法以及同类型先进的实时异常检测算法进行比较。表4所示为在Hadoop集群中进行WordCount和TeraSort基准测试的实验结果。从表中的实验结果可知，融合了Hadoop日志信息和体系结构层信息的异常节点检测算法相比于传统的算法性能有所提升。Pan等[5]、Guo等[6]、Fathnia等[9]与Habeeb等[10]的实验结果表明，将Hadoop日志信息和体系结构指标结合可以有效提高异常节点检测和诊断的性能。从整体来看，本文提出的算法在Hadoop集群异常节点检测评价指标准确率和召回率以及F1-score上优于其他所有的方法。相较于传统算法，基于Hadoop日志信息和体系结构层指标信息的异常阶段节点检测有了明显的改善。此外，相较于现有的实时异常检测算法，本文算法将reduce任务和map任务相互转化，减少了耦合性的影响，从而提升了算法的有效性。

表4 不同算法基准测试实验结果

此外，为了评估本文提出算法的泛化能力，在Hadoop集群节点运行时注入异常。具体地，在集群节点map任务完成20%、50%和80%时注入不同的异常，然后运行20次WordCount和TeraSort基准测试程序实验。实验结果表明本文提出的算法在Hadoop集群阶段运行时依然可以检测出异常节点，并诊断出导致异常的原因。详细的实验结果如表5、表6和表7所示。

表5 基准测试实验结果(map任务完成20%)

表6 基准测试实验结果(map任务完成50%)

表7 基准测试实验结果(map任务完成80%)

从表中可知，在map任务完成度为20%和50%时注入异常，实验结果和在Hadoop集群节点运行前注入异常基本一致，而当map任务完成度80%时注入异常，各项评价指标值有所降低。其原因是reduce阶段和map阶段任务并不是完全独立执行，在map任务完成部分后reduce任务就开始执行，而且reduce任务的执行时间普遍较长。本文提出算法主要依赖map任务，但是当map任务执行完后，reduce任务还未执行完毕，这将会导致节点发生异常而不能及时发现。

2.3 运行时间开销分析

在实时检测与诊断算法中，运行时间开销是重要的影响因素，而且在Spark Streaming批处理机制中，需要在固定的周期内完成计算并返回结果。如果实时检测算法的时间复杂度太高，则会增加批处理的时间，进而影响Hadoop集群整体性能。

本文使用BigdataBench中提及的WordCount、TeraSort和Grep三种基准测试程序评估提出算法的运行时间开销。将作业在没有数据收集工具运行的情况下运行的时间定义为基线时间，然后将收集Hadoop日志数据和体系结构层指标数据的间隔设置为1 s，并测量作业在有数据收集工具运行时的完成时间作为对比。实验结果如图10所示，可以明显得出本文提出算法引起的额外开销很低。

图10 运行时间开销

3 总结

本文基于Hadoop集群节点行为性能相似性，设计并实现了Hadoop集群异常节点的实时检测和诊断算法。该算法不但考虑了map任务和reduce任务之间的耦合性，而且本文提出的算法比传统的Hadoop异常节点检测与诊断算法精确率更高。通过在WordCount和TeraSort两个基准测试程序验证了本文提出算法的有效性。在未来的工作中，将进一步优化异常检测和诊断算法，使其适应更复杂情况，泛化能力更强。此外，针对异常误报情况对集群异常节点检测的影响，将提供其指标来区分集群是否真的发生异常。