Flink集的任务资源调整方法、装置及电子设备与流程

flink集的任务资源调整方法、装置及电子设备
技术领域
1.本技术涉及计算机信息处理领域，具体而言，涉及一种flink集的任务资源调整方法、装置、电子设备及计算机可读介质。

背景技术：

2.apache flink是由apache软件基金会开发的开源流处理框架，其核心是用java和scala编写的分布式流数据流引擎。flink以数据并行和流水线方式执行任意流数据程序，flink的流水线运行时系统可以执行批处理和流处理程序。此外，flink的运行时本身也支持迭代算法的执行。flink相对简单的编程模型、sql的支持，加上其高吞吐、低延迟、高性能以及支持exactly-once语义和eventtime的特性，使得开发人员可以快速的开发出满足业务需求的实时处理任务。
3.但是，flink中任务的资源是静态配置的，任务启动后使用的资源量就不会变了，即使业务流量发生变化，flink也无法自动调整资源进行应对。如果预先预留过多的任务资源，则在日常处理情况下回造成资源极大的浪费，如果按照日常业务流量配置任务资源的话，则会在突发业务流量的情况下产生任务延迟或者任务处理异常等等问题。
4.因此，需要一种新的flink集的任务资源调整方法、装置、电子设备及计算机可读介质。
5.在所述背景技术部分公开的上述信息仅用于加强对本技术的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

6.有鉴于此，本技术提供一种flink集的任务资源调整方法、装置、电子设备及计算机可读介质，能够在业务流量发生变化的情况下，自动调整flink任务资源，既能够避免预留大量任务资源造成的浪费，又能够避免由于缺少任务资源导致的任务延迟。
7.本技术的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本技术的实践而习得。
8.根据本技术的一方面，提出一种flink集的任务资源调整方法，该方法包括：通过metrics系统获取flink集中的任务对应的多个指标；根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略；根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；在所述任务的状态存在异常时，生成资源调整指令；基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源。
9.可选地，还包括：根据任务对应的taskmanager中cpu利用率生成资源调整策略；和/或根据任务对应的时延数值生成资源调整策略；和/或根据任务对应的taskmanager中内存利用率和gc指标生成资源调整策略；和/或根据任务对应的内存溢出异常生成资源调整策略；为多个任务类别分别确定其对应的资源调整策略。
10.可选地，通过metrics系统获取flink集中的任务对应的多个指标，包括：在
flink集中的任务启动时，在zookeeper注册为临时节点；prometheus监控系统通过zookeeper中的临时节点对flink集中的任务进行监控；prometheus监控系统通过flink集中metrics系统获取任务对应的所述多个指标。
11.可选地，prometheus监控系统通过flink集中metrics系统获取任务对应的所述多个指标，包括：prometheus监控系统基于第一定时周期通过flink集中metrics系统获取任务对应的延迟指标；prometheus监控系统基于第二定时周期通过flink集中metrics系统获取任务对应的所述多个指标。
12.可选地，根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略，包括：在sql数据库中获取所述多个资源调整策略；根据任务类别由多个资源调整策略目标资源调整策略。
13.可选地，根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常，包括：将所述多个指标代入所述目标资源调整策略对应的规则表达式中，生成计算结果；根据结果阶段确定所述任务的状态是否存在异常。
14.可选地，基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源，包括：将所述资源调整指令发送到flink集的任务调度接口；重启所述任务对应的taskmanager以更新所述任务对应的任务资源。
15.根据本技术的一方面，提出一种flink集的任务资源调整装置，该装置包括：指标模块，用于通过metrics系统获取flink集中的任务对应的多个指标；策略模块，用于根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略；判断模块，用于根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；指令模块，用于在所述任务的状态存在异常时，生成资源调整指令；调整模块，用于基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源。
16.根据本技术的一方面，提出一种电子设备，该电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序；当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如上文的方法。
17.根据本技术的一方面，提出一种计算机可读介质，其上存储有计算机程序，该程序被处理器执行时实现如上文中的方法。
18.根据本技术的flink集的任务资源调整方法、装置、电子设备及计算机可读介质，通过通过metrics系统获取flink集中的任务对应的多个指标；根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略；根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；在所述任务的状态存在异常时，生成资源调整指令；基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源的方式，能够在业务流量发生变化的情况下，自动调整flink任务资源，既能够避免预留大量任务资源造成的浪费，又能够避免由于缺少任务资源导致的任务延迟。
19.应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本技术。
附图说明
20.通过参照附图详细描述其示例实施例，本技术的上述和其它目标、特征及优点将
变得更加显而易见。下面描述的附图仅仅是本技术的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
21.图1是现有技术中flink集的系统框架。
22.图2是根据一示例性实施例示出的一种flink集的任务资源调整方法的系统框图。
23.图3是根据一示例性实施例示出的一种flink集的任务资源调整方法的流程图。
24.图4是根据另一示例性实施例示出的一种flink集的任务资源调整方法的示意图。
25.图5是根据另一示例性实施例示出的一种flink集的任务资源调整方法的示意图。
26.图6是根据另一示例性实施例示出的一种flink集的任务资源调整方法的流程图。
27.图7是根据一示例性实施例示出的一种flink集的任务资源调整装置的框图。
28.图8是根据一示例性实施例示出的一种电子设备的框图。
29.图9是根据一示例性实施例示出的一种计算机可读介质的框图。
具体实施方式
30.现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本技术将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。
31.此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本技术的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本技术的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本技术的各方面。
32.附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
33.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
34.应理解，虽然本文中可能使用术语第一、第二、第三等来描述各种组件，但这些组件不应受这些术语限制。这些术语乃用以区分一组件与另一组件。因此，下文论述的第一组件可称为第二组件而不偏离本技术概念的教示。如本文中所使用，术语“及/或”包括相关联的列出项目中的任一个及一或多者的所有组合。
35.本领域技术人员可以理解，附图只是示例实施例的示意图，附图中的模块或流程并不一定是实施本技术所必须的，因此不能用于限制本技术的保护范围。
36.为了使得本技术的技术更加容易被理解和执行，现对flink集(flinkcluste)的
系统框架进行简要描述。如图1所示，一个flinkcluster是由一个jobmanager和多个taskmanager组成的,jobmanager和taskmanager是进程级组件，其他的组件都是进程内的组件。
37.一个jobmanager中有一个resourcemanager和多个jobmaster，jobmanager中每一个jobmaster单独管理一个具体的job，jobmanager中的scheduler组件负责调度执行该job的dag中所有task，发出资源请求，即整个资源调度的起点；jobmaster中的slot pool组件持有分配到该job的所有资源。另外，jobmanager中唯一的resource manager负责整个flink cluster的资源调度以及与外部调度系统对接，这里的外部调度系统指的是kubernetes、mesos、yarn等资源管理系统。
38.taskmanager负责task的执行，其中的slot是taskmanager资源的一个子集，也是flink集资源管理的基本单位，slot的概念贯穿资源调度过程的始终。
39.flink集的资源调度是一个经典的两层模型，其中从cluster到job的分配过程是由slot manager来完成，job内部分配给task资源的过程则是由scheduler来完成。在有资源需求时，scheduler向slot pool发出slot request(资源请求)，slot pool如果不能满足该资源需求则会进一步请求resource manager，具体来满足该请求的组件是slot manager。
40.flink集目前的资源分配机制为静态分配机制，flink中的任务(job)在初始化完成之后，在整个运行期间资源不会变化，除非修改对应的资源配置，然后重启整个job。这样的设置会导致：当业务流量陡增的时候，job需要大量的资源处理需求时，flink却无法增加资源，导致任务发生延迟，这种问题对于核心业务的实时处理场景会造成极大的失败任务。
41.为了应对这种情况，开发人员往往会预分配大量的资源，应对高峰期的流量。这样就造成了，资源的大量浪费。再有就是，有些开发人员针对flink的内核原理并不是很清楚，在配置任务的时候，分配的资源不合理，也会导致任务的异常，比如任务中使用的state大小大于分配的taskmanager内存，这样往往会出现一些oom(内存溢出)的问题等。
42.因此，从保证任务稳定性、时效性和降低资源成本的角度出发，需要有能够针对flink实时任务资源自动进行调优的功能。但是，本技术的发明人发现，目前开源flink本身不支持动态的资源调整，业界不同公司采用的方案都不太相同。
43.有鉴于现有技术中存在的问题，本技术提出一种新的flink集的任务资源调整方法，能够在节约开发成本以及后续的升级维护成本的前提下，优化现有任务资源过分配的问题；在集任务任务发生延迟时，能够快速调整资源并恢复；还能够针对不同业务方定制不同的调优规则，并可快速部署上线；本案提出的方法具有高可用性、扩展性。下面借助于具体的实施例来对本技术的内容进行详细说明。
44.图2是根据一示例性实施例示出的一种flink集的任务资源调整方法及装置的系统框图。
45.如图2所示，系统架构20可以包括flink集201，网络202和服务器203。网络202用以在flink集201和服务器203之间提供通信链路的介质。网络202可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
46.flink集201可以是进行各种任务处理的服务器集，例如为用户所浏览的互联
网服务类网站提供支持的后台管理服务集。flink集201可以对接收到的用户任务进行分析等处理，并将生成处理结果。
47.服务器203可例如通过metrics系统获取flink集201中的任务对应的多个指标；服务器203可例如根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略；服务器203可例如根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；服务器203可例如在所述任务的状态存在异常时，生成资源调整指令；服务器203可例如基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源。
48.服务器203还可例如根据任务对应的taskmanager中cpu利用率生成资源调整策略；服务器203还可例如根据任务对应的时延数值生成资源调整策略；服务器203还可例如根据任务对应的taskmanager中内存利用率和gc(garbage collection，垃圾回收)指标生成资源调整策略；服务器203还可例如根据任务对应的内存溢出异常生成资源调整策略；服务器203还可例如为多个任务类别分别确定其对应的资源调整策略。
49.为了保证最大程度的优化flink任务，在调优规则上面，可采取多种策略组合的方式。更具体的，可有如下几种策略：
50.cpu-based策略：主要基于taskmanager的cpu实际利用率来动态调整并发度，这是一个典型的弹性计算伸缩策略。当cpu利用率高的时候，说明作业比较繁忙，这时候autopilot就会扩大作业的并发度，来减少单个taskmanager的负载。当cpu利用率低的时候，说明taskmanager比较空闲，这时候就可以反过来减少作业的并发度，来释放多余的资源；
51.source-delay-based策略：主要根据source的delay metrics(时延度量)来判断是否需要进行并发度调整。这个策略目前支持kafka和holosource。当检测到延迟的情况下，可将任务迅速调整为n天内最大的资源使用量，来快速消费数据，消除任务延迟。
52.memory-utilization-based策略：主要基于taskmanager实际内存的利用率以及gc metrics信息来判断是否需要调整taskmanager内存大小。当taskmanager整体内存利用率低，而且没有gc严重的时候，可以调整内存的大小；当taskmanager内存利用率已经偏高，或者说gc严重的时候，可以调大单个taskmanager的内存，来保证上面跑的task处于比较健康的状态；
53.job-exception-based策略：主要是自动识别因为资源异常所产生的作业的异常。可监测是oom(内存溢出)等异常日志，当有对应日志的时候，系统会调大taskmanager的内存。
54.服务器203可以是一个实体的服务器，还可例如为多个服务器组成，需要说明的是，本技术实施例所提供的flink集的任务资源调整方法可以由服务器203执行，相应地，flink集的任务资源调整装置可以设置于服务器203中。
55.图3是根据一示例性实施例示出的一种flink集的任务资源调整方法的流程图。flink集的任务资源调整方法30至少包括步骤s302至s310。
56.如图3所示，在s302中，通过metrics系统获取flink集中的任务对应的多个指标。可例如，在flink集中的任务启动时，在zookeeper注册为临时节点；prometheus监控系统通过zookeeper中的临时节点对flink集中的任务进行监控；prometheus监控系统通
过flink集中metrics系统获取任务对应的所述多个指标。
57.其中，prometheus是一个开源监控解决方案，用于收集和聚合指标作为时间序列数据。更简单地说，prometheus商店中的每个项目都是一个指标事件，并带有它发生的时间戳。prometheus通过使用基于拉取的数据获取机制来确定指标的当前值。它会定期轮询支持每个指标的数据源，然后将结果作为新事件存储在时间序列数据库中。
58.图4是根据另一示例性实施例示出的一种flink集的任务资源调整方法的示意图。如图4所示，flink任务在启动的时候，会将自身的地址信息作为临时节点注册在zookeeper中，这样prometheus便可实时发现对应的节点，并从flink的jobmanager/taskmanager中拉取指标。当flink任务退出时，promethues检测到对应的节点消失，便不再从对应的节点拉取指标。
59.在一个实施例中，prometheus监控系统基于第一定时周期通过flink集中metrics系统获取任务对应的延迟指标；prometheus监控系统基于第二定时周期通过flink集中metrics系统获取任务对应的所述多个指标。
60.在一个实施例中，指标可包括如下一种或多种：jobmanager/taskmanager的堆内存(heap)使用率；full gc(full garbage collection，针对jvm整个堆进行垃圾回收)的次数；jobmanager/taskmanager的cpu使用率；任务的反压(backpressure，任务下游蒜子处理过慢，导致任务上游算子阻塞的现象)；source消费lag(flink任务数据源算子消费延迟)；输入输出qps(每秒数据条数)；exceptions/errors(任务的异常或者错误日志)。
61.在s304中，根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略。可例如，在mysql数据库中获取所述多个资源调整策略；根据任务类别由多个资源调整策略目标资源调整策略。
62.可在数据库中提取预先设置的多个资源调整策略，如上文所述的cpu-based策略、source-delay-based策略、memory-utilization-based策略、job-exception-based策略等等。按照预先分配的策略和任务类别的对应关系，确定当前任务对应的具体策略种类。
63.在s306中，根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常。可例如，将所述多个指标代入所述目标资源调整策略对应的规则表达式中，生成计算结果；根据结果阶段确定所述任务的状态是否存在异常。
64.将获取到的指标代入到上文所述的策略中，计算出实时的cpu数值或者实际内存利用率等指标，进而判断当前任务是否存在异常。
65.在一个实施例中，当前任务对应的策略可为：cpu-based策略，在：cpu-based策略中，基于taskmanager的cpu实际利用率来动态调整并发度。此时，可根据获取当前cpu的利用率，当cpu的利用率高于第一阈值时，此时可增加作业的并发度，增加的数量可根据cpu的利用率和预先指定的对应关系实时确定。当cpu的利用率小于第二阈值时，此时可减小作业的并发度，减小的数量可根据cpu的利用率和预先指定的对应关系实时确定。
66.其他策略和任务指标可做类似的处理，本技术在此不再赘述。
67.在s308中，在所述任务的状态存在异常时，生成资源调整指令。接续上文内容，在cpu的利用率高于第一阈值时，或者低于第二阈值时，对应生成资源增加或减小指令。具体的指令参数可根据预先对应关系实时生成。
68.在s310中，基于所述资源调整指令重启所述任务对应的taskmanager以更新所述
任务对应的任务资源。可例如，将所述资源调整指令发送到flink集的任务调度接口；重启所述任务对应的taskmanager以更新所述任务对应的任务资源。
69.根据本技术的flink集的任务资源调整方法，通过通过metrics系统获取flink集中的任务对应的多个指标；根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略；根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；在所述任务的状态存在异常时，生成资源调整指令；基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源的方式，能够在业务流量发生变化的情况下，自动调整flink任务资源，既能够避免预留大量任务资源造成的浪费，又能够避免由于缺少任务资源导致的任务延迟。
70.应清楚地理解，本技术描述了如何形成和使用特定示例，但本技术的原理不限于这些示例的任何细节。相反，基于本技术公开的内容的教导，这些原理能够应用于许多其它实施例。
71.图5是根据另一示例性实施例示出的一种flink集的任务资源调整方法的示意图。如图5所示，本技术的flink集的任务资源调整方法对应的整体架构为无中心的分布式架构，为了保证系统的高性能，可采用的akka技术框架，mysql作为任务配置、调优规则以及调优历史等信息的存储。系统内部主要分为如下几块：
72.taskmanager可用于调优任务的发现、移除与负载均衡。针对每个调优的实时任务都会创建一个actor，来具体负责改任务的调优检测工作。
73.tuneactor：可包含三个功能模块：
74.metricsreader可用于根据配置好的指标，从外部系统(prometheus,elasticsearch)中获取计算好的指标；
75.ruleevaluator可用于从数据库中加载对应的调优规则，根据metricsreader获取的任务指标，判断任务当前状态是否正常，是否需要增减资源，然后生成对应的action指令；
76.actionmerger可用于合并ruleevaluator生成的action指令，生成最终的action指令。
77.jobcontroller可用于根据生成的action指令，调用任务调度服务相关接口，更新并重启任务。
78.对于线上生产环境中的flink实时任务而言，任务的时效性至关重要，因此能够快速的检测到任务延迟，并迅速恢复，是flink资源自动优化任务方案的关键点之一。另外，线上不同业务方，flink任务的类型、负载是多种多样的，这样对于基于规则的调优方案来说，调优规则的灵活性与多变性就非常重要，能够灵活、快速高效的新增修改调优规则，是本技术中flink集的任务资源调整方法的优点。
79.本技术中flink集的任务资源调整方法，采用akka作为技术框架，promethues作为flink任务的metrics指标计算的来源，来检测flink任务的异常，能够保证任务的时效性。
80.本技术中flink集的任务资源调整方法，将调优规则存储在数据库中，利用google aviator来灵活解析规则表达式。这样，在针对不同的业务方或者任务优化调优规则时，只需要修改数据库中对应的规则即可，无需重新编写代码，打包部署上线。使得本申
请中的flink任务的调优方法具有灵活性、易用性。
81.为了保证任务能够高效的检测到任务延迟并迅速扩容，同时对prometheus不会产生太大的压力。本技术中定义了两个定时器：第一定时器可为actor自定义定时器，actor自定义定时器监测周期较短，主要用于检测任务是否延迟、是否需要扩容；第二定时器可为crontab定时器，crontab定时器监测周期相对较长，主要用于检测任务是否需要缩容。具体的流程如图6所示。
82.在s602中，通过第一定时器获取延迟指标。
83.在s604中，判断系统当前是否有延迟的任务。
84.在s606中，通过第二定时器获取全部指标。
85.在s608中，获取任务对应的目标资源调整策略。
86.在s610中，计算确定是否需要进行资源调整。
87.在s612中，生成资源调整指令。
88.在s614中，更新重启任务作业。
89.本技术的flink集的任务资源调整方法，直接存储metrics对应的promethuesql语句，利用prometheus高效的查询分析能力，直接获取对应的flink指标，这种方法不同于现有技术中的硬编码的方式，本技术的方式能够保证调优规则的快速部署生效。
90.在本技术的flink集的任务资源调整方法中，为了定义了不同的调优规则模版，这样，不同业务方，不同flink任务类型，可以使用对应的调优规则模版，同时在升级规则更新的时候，也可以快速批量应用。
91.在本技术的flink集的任务资源调整方法中，利用google avator来解析存储的规则表达式，灵活高效。当我们需要调整调优规则的时候，只需要修改数据库中存储的对应的规则表达式即可，实时生效，且无需重启程序，用户侧无感知。
92.本领域技术人员可以理解实现上述实施例的全部或部分步骤被实现为由cpu执行的计算机程序。在该计算机程序被cpu执行时，执行本技术提供的上述方法所限定的上述功能。所述的程序可以存储于一种计算机可读存储介质中，该存储介质可以是只读存储器，磁盘或光盘等。
93.此外，需要注意的是，上述附图仅是根据本技术示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。
94.下述为本技术装置实施例，可以用于执行本技术方法实施例。对于本技术装置实施例中未披露的细节，请参照本技术方法实施例。
95.图7是根据一示例性实施例示出的一种flink集的任务资源调整装置的框图。如图7所示，flink集的任务资源调整装置70包括：指标模块702，策略模块704，判断模块706，指令模块708，调整模块710。
96.指标模块702用于通过metrics系统获取flink集中的任务对应的多个指标；指标模块702还用于在flink集中的任务启动时，在zookeeper注册为临时节点；prometheus监控系统通过zookeeper中的临时节点对flink集中的任务进行监控；prometheus监控系统通过flink集中metrics系统获取任务对应的所述多个指标。
97.策略模块704用于根据任务类别在多个资源调整策略中为所述任务确定目标资源
调整策略；策略模块704还用于在mysql数据库中获取所述多个资源调整策略；根据任务类别由多个资源调整策略目标资源调整策略。
98.判断模块706用于根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；判断模块706还用于将所述多个指标代入所述目标资源调整策略对应的规则表达式中，生成计算结果；根据结果阶段确定所述任务的状态是否存在异常。
99.指令模块708用于在所述任务的状态存在异常时，生成资源调整指令；
100.调整模块710用于基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源。调整模块710还用于将所述资源调整指令发送到flink集的任务调度接口；重启所述任务对应的taskmanager以更新所述任务对应的任务资源。
101.根据本技术的flink集的任务资源调整装置，通过通过metrics系统获取flink集中的任务对应的多个指标；根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略；根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；在所述任务的状态存在异常时，生成资源调整指令；基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源的方式，能够在业务流量发生变化的情况下，自动调整flink任务资源，既能够避免预留大量任务资源造成的浪费，又能够避免由于缺少任务资源导致的任务延迟。
102.图8是根据一示例性实施例示出的一种电子设备的框图。
103.下面参照图8来描述根据本技术的这种实施方式的电子设备800。图8显示的电子设备800仅仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制。
104.如图8所示，电子设备800以通用计算设备的形式表现。电子设备800的组件可以包括但不限于：至少一个处理单元810、至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830、显示单元840等。
105.其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书中的根据本技术各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图3，图6中所示的步骤。
106.所述存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(rom)8203。
107.所述存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
108.总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
109.电子设备800也可以与一个或多个外部设备800’(例如键盘、指向设备、蓝牙设备等)通信，使得用户能与该电子设备800交互的设备通信，和/或该电子设备800能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口850进行。并且，电子设备800还可以通过网络适配器860与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。网络适配器860可以通过总线830与电子设备800的其它模块通信。应当明白，尽管图中未示出，可
以结合电子设备800使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
110.通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，如图9所示，根据本技术实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、或者网络设备等)执行根据本技术实施方式的上述方法。
111.所述软件产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
112.所述计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。
113.可以以一种或多种程序设计语言的任意组合来编写用于执行本技术操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
114.上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该计算机可读介质实现如下功能：通过metrics系统获取flink集中的任务对应的多个指标；根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略；根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；在所述任务的状态存在异常时，生成资源调整指令；基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源。该计算机可读介质还可实现如下功能：根据任务对应的taskmanager中cpu利用率生成资源调整策略；和/或根据任务对应的时延数值生成资源调整策略；和/或根据任务对应的taskmanager中内存利用率和gc指标生成资源调整策略；和/或根据任务对应的内存溢出异常生成资源调整策略；为多个任务类别分别确定其对应的资源调整策略。
115.本领域技术人员可以理解上述各模块可以按照实施例的描述分布于装置中，也可
以进行相应变化唯一不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
116.通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本技术实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本技术实施例的方法。
117.以上具体地示出和描述了本技术的示例性实施例。应可理解的是，本技术不限于这里描述的详细结构、设置方式或实现方法；相反，本技术意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

技术特征：

1.一种flink集的任务资源调整方法，其特征在于，包括：通过metrics系统获取flink集中的任务对应的多个指标；根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略；根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；在所述任务的状态存在异常时，生成资源调整指令；基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源。2.如权利要求1所述的方法，其特征在于，还包括：根据任务对应的taskmanager中cpu利用率生成资源调整策略；和/或根据任务对应的时延数值生成资源调整策略；和/或根据任务对应的taskmanager中内存利用率和gc指标生成资源调整策略；和/或根据任务对应的内存溢出异常生成资源调整策略；为多个任务类别分别确定其对应的资源调整策略。3.如权利要求1所述的方法，其特征在于，通过metrics系统获取flink集中的任务对应的多个指标，包括：在flink集中的任务启动时，在zookeeper注册为临时节点；prometheus监控系统通过zookeeper中的临时节点对flink集中的任务进行监控；prometheus监控系统通过flink集中metrics系统获取任务对应的所述多个指标。4.如权利要求3所述的方法，其特征在于，prometheus监控系统通过flink集中metrics系统获取任务对应的所述多个指标，包括：prometheus监控系统基于第一定时周期通过flink集中metrics系统获取任务对应的延迟指标；prometheus监控系统基于第二定时周期通过flink集中metrics系统获取任务对应的所述多个指标。5.如权利要求1所述的方法，其特征在于，根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略，包括：在mysql数据库中获取所述多个资源调整策略；根据任务类别由多个资源调整策略目标资源调整策略。6.如权利要求1所述的方法，其特征在于，根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常，包括：将所述多个指标代入所述目标资源调整策略对应的规则表达式中，生成计算结果；根据结果阶段确定所述任务的状态是否存在异常。7.如权利要求1所述的方法，其特征在于，基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源，包括：将所述资源调整指令发送到flink集的任务调度接口；重启所述任务对应的taskmanager以更新所述任务对应的任务资源。8.一种flink集的任务资源调整装置，其特征在于，包括：指标模块，用于通过metrics系统获取flink集中的任务对应的多个指标；策略模块，用于根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策
略；判断模块，用于根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；指令模块，用于在所述任务的状态存在异常时，生成资源调整指令；调整模块，用于基于所述资源调整指令重启所述任务对应的taskmanager以更新所述任务对应的任务资源。9.一种电子设备，其特征在于，包括：一个或多个处理器；存储装置，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-7中任一所述的方法。10.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-7中任一所述的方法。

技术总结

本申请涉及一种Flink集的任务资源调整方法、装置、电子设备及计算机可读介质。该方法包括：通过Metrics系统获取Flink集中的任务对应的多个指标；根据任务类别在多个资源调整策略中为所述任务确定目标资源调整策略；根据所述多个指标和所述目标资源调整策略判断所述任务的状态是否存在异常；在所述任务的状态存在异常时，生成资源调整指令；基于所述资源调整指令重启所述任务对应的TaskManager以更新所述任务对应的任务资源。本申请涉及的任务资源调整方法，能够在业务流量发生变化的情况下，自动调整Flink任务资源，既能够避免预留大量任务资源造成的浪费，又能够避免由于缺少任务资源导致的任务延迟。务资源导致的任务延迟。务资源导致的任务延迟。