CN109977161A - presto集群的监控系统 - Google Patents

Abstract

本申请提供一种presto集群的监控系统。本申请提供的presto集群的监控系统包括：数据库和至少一个节点；节点包括：主节点和至少一个从节点；主节点，用于采集用户的查询任务，并向从节点下发查询任务；从节点，用于接收查询任务，采集查询任务查询的信息和执行状态，并向数据库发送；数据库接收并保存查询任务查询的信息和执行状态；主节点和从节点，分别通过心跳机制监控对方是否宕机；主节点还用于当发现从节点宕机时，重启从节点；从节点还用于当发现主节点宕机时，通过选举机制选出新的主节点。

Description

presto集群的监控系统

技术领域

本申请涉及presto集群相关技术领域，具体涉及一种presto集群的监控系统。

背景技术

Presto是一种应用于大数据方面的分布式SQL查询引擎，所有数据处理和传输都是基于内存和网络，计算过程一气呵成，不分阶段，没有中间temp阶段，避免了不必要的I/O和延迟开销，因此总体查询效率比Hive高出近10倍。

Presto集群在计算过程中，需要把所有参与计算的元数据拆分并加载到各个计算节点的内存中完成计算，例如：查询、排序、存放中间结果集等。Presto支持多个作业并行执行。当某一个节点宕机时，该节点无法正常工作，影响整个系统的工作状态。

发明内容

本申请提供一种presto集群的监控系统，以解决在Presto集群的运行过程中，某一个节点宕机时，该节点无法正常工作，影响整个系统的工作状态的问题。

本申请提供一种presto集群的监控系统，包括：数据库和多个负责采集监控presto集群的节点；

所述节点包括：主节点和至少一个从节点；

所述主节点，用于采集用户的查询任务，并向所述从节点下发所述查询任务；

所述从节点，用于接收所述查询任务，采集所述查询任务查询的信息和执行状态，并向所述数据库发送；

所述数据库接收并保存所述查询任务查询的信息和执行状态；

所述主节点和所述从节点，分别通过心跳机制监控对方是否宕机；

所述主节点还用于当发现所述从节点宕机时，尝试重启所述从节点；

所述从节点还用于当发现所述主节点宕机时，通过选举机制选举新的主节点。

可选的，所述新的主节点，用于重启所述宕机的主节点，并将所述宕机的主节点转化为从节点。

可选的，所述从节点，通过选举机制，选举新的主节点具体包括：

最先发现所述主节点宕机的从节点，通过选举算法，被选举为新的主节点。

可选的，所述新的主节点，用于重启所述宕机的主节点并失败预设次数后，告警。

可选的，所述从节点，还用于向主节点反馈所述查询任务的执行状态；

所述主节点，还用于接收所述查询任务的执行状态，判断任务执行是否成功，得到是或否的第一判断结果，若所述第一判断结果为是，移除所述查询任务，若所述第一判断结果为否，再次向所述从节点下发所述查询任务。

可选的，所述主节点，对于同一查询任务下发并失败第二预设次数后，标记所述查询任务为失败，告警，并停止下发所述查询任务。

可选的，所述主节点，还用重启所述从节点并失败预设次数后，告警。

可选的，所述主节点，还用于通过预设接口接收待添加节点发送的信息，并在检测所述待添加节点的信息后，将所述待添加节点添加为从节点。

可选的，所述主节点向所述从节点下发所述查询任务时采用公平调度算法。

可选的，所述主节点向所述从节点下发所述查询任务，包括：

所述主节点向所述从节点发送所述查询任务的标识；其中，标识与查询任务一一对应。

所述从节点接收所述查询任务，包括：

所述从节点接收所述标识，并依据所述标识获取所述查询任务。

本申请的提供的presto集群的监控系统中，主节点，用于采集用户的查询任务，并向从节点下发查询任务；从节点，用于接收采集任务，采集查询任务的查询的信息和执行状态，并存入数据库；完成查询任务。在presto集群中，主节点和从节点，分别通过心跳机制监控对方是否宕机；主节点还用于当发现从节点宕机时，重启从节点；所述从节点还用于当发现所述主节点宕机时，通过选举机制选举新的主节点。如此设置，从节点发生宕机时，主节点对其进行重启，维持系统稳定性，主节点宕机时，会有从节点转化为新的从节点，新的主节点会对没有处理完成或没有下发的任务继续下发，保证任务不丢。使得整个系统中的节点可以稳定运行。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请提供的一种presto集群的监控系统的结构示意图；

图2是本申请提供的presto集群的监控系统的流程图。

附图标记：

1-数据库；2-主节点；3-从节点。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

Presto是一种应用于大数据方面的分布式SQL查询引擎，所有数据处理和传输都是基于内存和网络，计算过程一气呵成，不分阶段，没有中间temp阶段，避免了不必要的I/O和延迟开销，因此总体查询效率比Hive高出近10倍。

Presto集群在计算过程中，需要把所有参与计算的元数据拆分并加载到各个计算节点的内存中完成计算，例如：查询、排序、存放中间结果集等。Presto支持多个作业并行执行。当某一个节点宕机时，该节点无法正常工作，影响整个系统的工作状态。

图1为本申请提供的一种presto集群的监控系统的结构示意图；参照图1，presto集群的监控系统采用master/slave架构，包括：数据库1和多个负责采集监控presto集群的节点；

节点包括：主节点2和至少一个从节点3；

其中，对于同一个节点可以是主节点的同时也是从节点，同时执行主节点和从节点的任务。

主节点2，用于采集用户的查询任务，并向从节点3下发查询任务；

从节点3，用于接收采集任务，采集查询任务的查询的信息和执行状态，并存入数据库1；

主节点2和从节点3，分别通过心跳机制监控对方是否宕机；

主节点2还用于当发现从节点3宕机时，重启从节点3；

从节点3还用于当发现主节点1宕机时，通过选举机制选举新的主节点。

其中，心跳机制是定时发送一个自定义的结构体(心跳包)，让对方知道自己还活着，以确保连接的有效性的机制。所谓的心跳包就是客户端定时发送简单的信息给服务端告诉它我还在而已。代码就是每隔几秒钟发送一个固定信息给服务端，服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。其中两个节点通过心跳机制判断连接的有效性时，各个节点既可以是服务端也可以是客户端。

网络中的接收和发送数据都是使用系统中的SOCKET(套接字)进行实现。但是如果此套接字已经断开，那发送数据和接收数据的时候就一定会有问题。可是如何判断这个套接字是否还可以使用呢？这个就需要在系统中创建心跳机制。其实，TCP(TransmissionControl Protocol传输控制协议)中已经为我们实现了一个叫做心跳的机制。如果你设置了心跳，那TCP就会在一定的时间(比如你设置的是3秒钟)内发送你设置的次数的心跳(比如说2次)，并且此信息不会影响你自己定义的协议。所谓“心跳”就是定时发送一个自定义的结构体(心跳包或心跳帧)，让对方知道自己“在线”，以确保链接的有效性。

本申请的提供的presto集群的监控系统中，主节点，用于采集用户的查询任务，并向从节点下发查询任务；从节点，用于接收采集任务，采集查询任务的查询的信息和执行状态，并存入数据库；完成查询任务。在presto集群中，主节点和从节点，分别通过心跳机制监控对方是否宕机；主节点还用于当发现从节点宕机时，重启从节点；所述从节点还用于当发现所述主节点宕机时，通过选举机制选举新的主节点。如此设置，从节点发生宕机时，主节点对其进行重启，维持系统稳定性，主节点宕机时，会有从节点转化为新的从节点，新的主节点会对没有处理完成或没有下发的任务继续下发，保证任务不丢。使得整个系统中的节点可以稳定运行。

进一步的，无论是主节点还是从节点都将自身的任务执行情况，自身状态实时的存储在数据库中。如此设置，数据库中存储查询任务查询的信息和执行状态以及各个节点的状态，相关人员可以通过数据库监控查询任务的进行状态，随时监控任务的执行状态。

当然，实际应用中，由主节点重启从节点的过程中，重启也可能会失败，从节点可能长时间无法重启，面对这种情况发明人提出了如下方案：

主节点，还用重启从节点并失败预设次数后，将从节点标记为宕机并告警。

如此设置，可以有效的避免无限次的重启从节点，而影响主节点的效率，进而影响整个系统的运行效率。

进一步的，在主节点宕机时，从节点3通过选举机制选举新的主节点。具体的，确定主节点宕机，及选举过程如下：

当主节点宕机后，从节点在心跳时，发现主节点一直没响应。每次失败的心跳都会记录到一张表中。当报告心跳失败达到一定次数，并且超过半数的从节点都报告心跳失败时，认为主节点宕机，从节点会选举新的主节点。而选举的方式就是看心跳记录表中最早报告心跳失败的从节点作为新的主节点，然后新的主节点通知所有节点，切换主节点ip，改向新的主节点汇报。新的主节点会同步数据库中宕机的主节点未下发和未处理完成的任务，重新下发，保证任务不丢。与此同时，会尝试一定次数重启刚刚宕掉的主节点，重启失败新的主节点告警，重启成功宕机的主节点身份变为从节点，向新的主节点心跳汇报，接收任务下发。

需要了解的是，为了保证presto集群可以正常运行，有时候需要向presto集群内部添加新的节点，为了使得节点的添加更为方便，发明人提供了如下方案：

主节点，还用于通过预设接口接收待添加节点发送的信息，并在检测待添加节点的信息后，将待添加节点添加为从节点。

如此设置，将待添加节点变成为了presto集群的一部分，扩展presto集群，提高presto集群的运行效率。

具体的，新的待添加节点是一个jar包，里面配置了集群相关信息，包括当前的主节点的ip和端口号。启动这个待添加节点后，待添加节点会查询数据库，获取主节点信息，然后调用主节点的心跳接口，这样就加入了presto集群监控系统。

上文中介绍了本申请提供的presto集群的监控系统中，主节点与从节点之间的互相唤醒，互相监控和添加新的从节点的方式。接下来将详细介绍本申请提供的方案中如何具体执行查询任务并监控查询任务的执行状态。

本申请提供的方案中：主节点，用于采集用户的查询任务，并向从节点下发查询任务。其中，主节点向数据库发送自身的工作状态以及采集和下发查询任务的进程。

从节点，用于接收采集任务，采集查询任务查询的信息和执行状态，并向数据库发送。

如此设置数据库中存储查询任务查询的信息和执行状态，相关人员可以监控查询任务的进行状态，随时监控任务执行状态。

其中，本申请提供的方案中，主节点向从节点下发查询任务时采用公平调度算法。

需要了解的是，调度算法是根据系统的资源分配策略所规定的资源分配算法。对于不同的系统和系统目标，通常采用不同的调度算法，例如，在批处理系统中，为了照顾为数众多的段作业，应采用短作业优先的调度算法；又如在分时系统中，为了保证系统具有合理的响应时间，应当采用轮转法进行调度。目前存在的多种调度算法中，有的算法适用于作业调度，有的算法适用于进程调度；但也有些调度算法既可以用于作业调度，也可以用于进程调度。

本申请中采用的公平调度算法，将查询任务按照各个从节点处理查询任务的能力相对平均的分派给从节点。从而避免发生数据倾斜。即：避免出现部分从节点堆积多个查询任务，而另一部分从节点空闲的状况。

数据倾斜是进行大数据计算时最经常遇到的问题之一。当我们在执行HiveQL或者运行MapReduce作业时候，如果遇到一直卡在map100％,reduce99％一般就是遇到了数据倾斜的问题。数据倾斜其实是进行分布式计算的时候，某些节点的计算能力比较强或者需要计算的数据比较少，早早执行完了，某些节点计算的能力较差或者由于此节点需要计算的数据比较多，导致出现其他节点的reduce阶段任务执行完成，但是这种节点的数据处理任务还没有执行完成。

本申请中各个从节点还会将向主节点反馈自身的运行状态，并且向数据库发送自身的运行状态。如此主节点可以根据各个从节点的运行状态判断是否发生了数据倾斜，以便于及时作出调整，例如尽量向空闲的从节点发送查询任务。进一步的相关人员还可以根据数据库内存储的数据来判断发生数据倾斜的原因，进一步的优化系统。

进一步的，主节点向从节点下发任务时，具体为向从节点发送查询任务的标识；其中，标识与查询任务一一对应。

从节点接收查询任务，具体为：

从节点接收标识，并依据标识获取查询任务。

如此设置，在主节点下发任务的过程中，下发的数据为查询任务的标识，从节点依据标识获取查询任务，简化了主节点和从节点之间的数据交互提高了系统的性能。

为了使得确保查询任务被执行，发明人提出了如下方案：本申请提供的presto集群的监控系统中，主节点，还用于接收查询任务的执行状态，判断任务执行是否成功，得到是或否的第一判断结果，若第一判断结果为是，移除查询任务，若第一判断结果为否，再次向从节点下发查询任务。

如此设置，将已完成的查询任务将会被移除，未完成的查询任务将会被再次下发。当一个查询任务被对此下发且均为被完成时，便可以认为该查询任务无法成功执行，标记该任务失败，并告警。如此可以通过告警通知相关人员对标记为失败的任务进行进一步的处理。

为了更清楚的表述本申请提供的方案，现对本申请中的告警行为进行汇总。告警行为主要包括：

主节点宕机时，选举产生的新的主节点对宕机的主节点进行重启失败后，新的主节点告警。

从节点宕机时，主节点重启从节点并失败后，主节点告警。

任务执行失败，主节点接收到从节点的反馈后需告警。其中，此处任务执行失败有两种情况，一种是从节点无法通过主节点发送的标识获取查询任务，另一种是查询任务执行过程中发生错误。

图2是本申请提供的presto集群的监控系统的流程图；参照图2，本申请提供的presto集群的监控系统执行的流程包括：

主节点和从节点通过心跳机制监控对方是否宕机。

主节点检测到从节点宕机，向从节点发送重启命令并告警。

从节点检测到主节点宕机，选举最先发现主机点宕机的从节点为新的主节点。

新的主节点重启宕机的主节点，失败则报警，成功则将宕机的主节点转化为从节点。

主节点向从节点下发查询任务。

从节点采集查询任务查询的信息和自身运行状态。

从节点向存储器发送查询任务查询的信息、执行状态和自身运行状态。

从节点向主节点反馈查询任务的执行情况和自身运行状态。

查询任务执行状态为失败时，主节点重新下发此任务。

对于同一查询任务下发并失败第二预设次数后，标记查询任务为失败，并告警。

待添加的节点查询主节点信息。

数据库发送主节点信息。

待添加的节点调用主节点的心跳接口，加入监控系统，成为从节点。

由于在上文的介绍中已经详细的介绍了各个步骤的具体执行过程，再次就不一一赘述了。

本申请的提供的presto集群的监控系统中，主节点，用于采集用户的查询任务，并向从节点下发查询任务；从节点，用于接收采集任务，采集查询任务的查询的信息和执行状态，并存入数据库；完成查询任务。在presto集群中，主节点和从节点，分别通过心跳机制监控对方是否宕机；主节点还用于当发现从节点宕机时，重启从节点；所述从节点还用于当发现所述主节点宕机时，通过选举机制选举新的主节点。如此设置，从节点发生宕机时，主节点对其进行重启，维持系统稳定性，主节点宕机时，会有从节点转化为新的从节点，新的主节点会对没有处理完成或没有下发的任务继续下发，保证任务不丢。使得整个系统中的节点可以稳定运行。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少一个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种presto集群的监控系统，其特征在于，包括：数据库和至少两个个节点；

所述数据库和所述节点连接；

所述节点包括：主节点和至少一个从节点；

各个节点分别互相连接；

所述主节点，用于采集用户的查询任务，并向所述从节点下发所述查询任务；

所述从节点，用于接收所述查询任务，采集所述查询任务查询的信息和执行状态，并向所述数据库发送；

所述数据库接收并保存所述查询任务查询的信息和执行状态；

所述主节点和所述从节点，分别通过心跳机制监控对方是否宕机；

所述主节点还用于当发现所述从节点宕机时，尝试重启所述从节点；

所述从节点还用于当发现所述主节点宕机时，通过选举机制选举新的主节点。

2.根据权利要求1所述的presto集群的监控系统，其特征在于，所述新的主节点，用于重启宕机的主节点，并将所述宕机的主节点转化为从节点。

3.根据权利要求1所述的presto集群的监控系统，其特征在于，所述从节点，通过选举机制，选举新的主节点具体包括：

最先发现所述主节点宕机的从节点，通过选举算法，被选举为新的主节点。

4.根据权利要求2所述的presto集群的监控系统，其特征在于，所述新的主节点，用于重启所述宕机的主节点并失败预设次数后，告警。

5.根据权利要求1所述的presto集群的监控系统，其特征在于，所述从节点，还用于向主节点反馈所述查询任务的执行状态；

所述主节点，还用于接收所述查询任务的执行状态，判断任务执行是否成功，得到是或否的第一判断结果，若所述第一判断结果为是，移除所述查询任务，若所述第一判断结果为否，再次向从节点下发所述查询任务。

6.根据权利要求5所述的presto集群的监控系统，其特征在于，所述主节点，对于同一查询任务下发并失败第二预设次数后，标记所述查询任务为失败，告警，并停止下发所述查询任务。

7.根据权利要求1所述的presto集群的监控系统，其特征在于，所述主节点，还用重启所述从节点并失败预设次数后，告警。

8.根据权利要求1所述的presto集群的监控系统，其特征在于，所述主节点，还用于通过预设接口接收待添加节点发送的信息，并在检测所述待添加节点的信息后，将所述待添加节点添加为从节点。

9.根据权利要求1所述的presto集群的监控系统，其特征在于，所述主节点向所述从节点下发所述查询任务时采用公平调度算法。

10.根据权利要求1所述的presto集群的监控系统，其特征在于，所述主节点向所述从节点下发所述查询任务，包括：

所述主节点向所述从节点发送所述查询任务的标识；其中，标识与查询任务一一对应。

所述从节点接收所述查询任务，包括：

所述从节点接收所述标识，并依据所述标识获取所述查询任务。