自动配置调优

实时计算 Flink新增自动调优功能autoconf。能够在流作业以及上下游性能达到稳定的前提下，根据您作业的历史运行状况，重新分配各算子资源和并发数，达到优化作业的目的。更多详细说明请您参阅自动配置调优。

首次智能调优

1. 创建一个作业。如何创建作业请参看快速入门。

2. 上线作业。选择智能推荐配置，指定使用CU数为系统默认，不填即可。点击下一步。

3. 数据检查，预估消耗CU数。

4. 在运维界面启动作业，根据实际业务需要指定读取数据时间。

   说明:实时计算作业启动时候需要您指定启动时间。实际上就是从源头数据存储的指定时间点开始读取数据。指定读取数据时间需要在作业启动之前。例如，设置启动时间为1小时之前。

5. 待作业稳定运行10分钟后，且以下状态符合要求，即可开始下一次性能调优。

   • 运行信息拓扑图中IN_Q不为100%。
   • 数据输入RPS符合预期。

非首次性能调优

1. 停止>下线作业。

2. 重新上线作业。选择智能推荐配置，指定使用CU数为系统默认，不填即可。点击下一步。

3. 数据检查，再次预估消耗CU数。

4. 在运维界面启动作业，待作业稳定运行十分钟后，即可再一次性能调优。

说明：

• 自动配置调优一般需要3到5次才能达到理想的调优效果。请完成首次性能调优后，重复非首次性能调优过程多次。
• 每次调优前，请确保足够的作业运行时长，建议10分钟以上。
• 指定CU数（参考值） = 实际消耗CU数*目标RPS/当前RPS。
  • 实际消耗CU数：上一次作业运行时实际消耗CU
  • 目标RPS：输入流数据的实际RPS（或QPS）
  • 当前RPS：上一次作业运行时实际的输入RPS

手动配置调优

手动配置调优可以分以下三个类型。

• 资源调优
• 作业参数调优
• 上下游参数调优

资源调优

资源调优即是对作业中的Operator的并发数（parallelism）、CPU（core）、堆内存（heap_memory）等参数进行调优。

分析定位资源调优节点

定位性能瓶颈节点

性能瓶颈节点为Vertex拓扑图最下游中参数IN_Q值为100%的一个或者多个节点。如下图，7号节点为性能瓶颈节点。

分析性能瓶颈因素

性能瓶颈的可分为三类。

• 并发（parallelism）不足
• CPU（core）不足
• MEM（heap_memory）不足

如下图，7号节点的性能瓶颈是资源（CPU和/或MEM）配置不足所导致。

说明：判断性能瓶颈因素方法

• 瓶颈节点的资源健康分为100，则认为资源已经合理分配，性能瓶颈是并发数不足所导致。
• 瓶颈节点的资源健康分低于100，则认为性能瓶颈是单个并发的资源（CPU和/或MEM）配置不足所导致。
• 无持续反压，但资源健康分低于100，仅表明单个并发的资源使用率较高，但暂不影响作业性能，可暂不做调优。

通过作业运维页面中Metrics Graph功能，进一步判断性能瓶颈是CPU不足还是MEM不足。步骤如下。

1. 运维界面中，点击TaskExecutor，找到性能瓶颈节点ID，点击查看详情。

2. 选择Metrics Graph，根据曲线图判断CPU或者MEM是否配置不足（很多情况下两者同时不足）。

调整资源配置

完成了性能瓶颈因素判断后，点击开发>基本属性>跳转到新窗口配置，开始调整资源配置。

批量修改Operator

1. 点击GROUP框，进入批量修改Operator数据窗口。

   说明：

   1. GROUP内所有的operator具有相同的并发数。
   2. GROUP的core为所有operator的最大值。
   3. GROUP的_memory为所有operator之和。
   4. 建议单个Job维度的CPU:MEM=1:4，即1个核对应4G内存。

2. 配置修改完成后点击应用当前配置并关闭窗口。

单个修改Operator

1. 点击Operator框，进入修改Operator数据窗口。

2. 配置修改完成后点击应用当前配置并关闭窗口。

参数调整说明

您只需调整parallelism、core和heap_memory三个参数，即能满足大部分的资源调优需求。

• Parallelism
  • source节点
    资源根据上游Partition数来。例如source的个数是16，那么source的并发可以配置为16、8、4等。不能超过16。
  • 中间节点
    根据预估的QPS计算。对于数据量较小的任务，设置和source相同的并发度。QPS高的任务，可以配置更大的并发数，例如64、128、或者256。
  • sink节点
    并发度和下游存储的Partition数相关，一般是下游Partition个数的2~3倍。如果配置太大会导致数据写入超时或失败。例如，下游sink的个数是16，那么sink的并发最大可以配置48。
• Core
  即CPU，根据实际CPU使用比例配置，建议配置值为0.25，可大于1。
• Heap_memory
  堆内存。根据实际内存使用状况进行配置。
• 其他参数
  • state_size：默认为0，group by、join、over、window等operator需设置为1。
  • direct_memory：JVM堆外内存，默认值为0, 建议不要修改。
  • native_memory：JVM堆外内存，默认值为0，建议修改为10MB。
  • chainingStrategy：chain策略，根据实际需要修改。

作业参数调优

1. 在开发页面的右侧选择作业参数。

2. 输入调优语句。

优化	解决问题	调优语句
MiniBatch	提升吞吐，降低对下游压力仅对Group by有效。	blink.miniBatch.allowLatencyMs=5000 blink.miniBatch.size=1000
LocalGlobal	优化数据倾斜问题	blink.localAgg.enable=true
TTL	设置State状态时间	1.x：state.backend.rocksdb.ttl.ms=129600000 2.x：state.backend.niagara.ttl.ms=129600000 其中，1.x 表示需显式开启，2.x 表示默认开启。

注意：添加或删除MiniBatch或LocalGlobal参数，job状态会丢失，修改值大小状态不会丢失。

上下游参数调优

实时计算 Flink可以在with参数内设置相应的参数，达到调优上下游存储性能的目的。

调优步骤：

1. 进入作业的开发界面。
2. 确定需要调优的上下游引用表的语句。
3. 在with参数中配置相应的调优参数。如下图。

batchsize参数调优

实时计算 Flink的每条数据均会触发上下游存储的读写，会对上下游存储形成性能压力。可以通过设置batchsize，批量的读写上下游存储数据来降低对上下游存储的压力。

名字	参数	详情	设置参数值
Datahub源表	batchReadSize	单次读取条数	可选，默认为10
Datahub结果表	batchSize	单次写入条数	可选，默认为300
日志服务源表	batchGetSize	单次读取logGroup条数	可选，默认为10
ADB结果表	batchSize	每次写入的批次大小	可选，默认为1000
RDS结果表	batchSize	每次写入的批次大小	可选，默认为50

注意： 添加、修改或者删除以上参数后，作业必须停止-启动后，调优才能生效。

cache参数调优

名字	参数	详情	设置参数值
RDS维表	Cache	缓存策略	默认值为None,可选LRU、ALL。
RDS维表	cacheSize	缓存大小	默认值为None,可选LRU、ALL。
RDS维表	cacheTTLMs	缓存超时时间	默认值为None,可选LRU、ALL。
OTS维表	Cache	缓存策略	默认值为None, 可选LRU,不支持ALL。
OTS维表	cacheSize	缓存大小	默认值为None, 可选LRU,不支持ALL。
OTS维表	cacheTTLMs	缓存超时时间	默认值为None, 可选LRU,不支持ALL。

注意： 添加、修改或者删除以上参数后，作业必须停止-启动后，调优才能生效。

手动配置调优流程

1. 资源调优、作业参数调优、上下游参数调优
2. 开发上线作业
3. 资源配置方式：使用上次资源配置
4. 数据检查
5. 上线

说明：完成资源、作业参数、上下游参数调优后，手动配置调优后续的步骤与自动配置调优基本一致。区别在于资源配置环节需要选择使用上次资源配置。

FAQ

Q：性能调优后作业为什么运行不起来？

A:可能性1：首次自动配置时指定了CU数，但指定的CU数太小（比如小于自动配置默认算法的建议值，多见于作业比较复杂的情况），建议首次自动配置时不指定CU数。
可能性2：默认算法建议的CU数或指定的CU数超过了项目当前可用的CU数，建议扩容。

Q：Vertex拓扑中看不到持续反压，但延迟却非常大，为什么？

A：可能性1：若延时直线上升，需考虑是否上游source中部分partition中没有新的数据，因为目前delay统计的是所有partition的延时最大值。
可能性2：Vertex拓扑中看不到持续反压，那么性能瓶颈点可能出现在source节点。因为source节点没有输入缓存队列，即使有性能问题，IN_Q也永远为0（同样，sink节点的OUT_Q也永远为0）。
解决方案：通过手动配置调优，将source节点（GROUP）中的operator中chainingStrategy修改为HEAD，将其从GROUP中拆解出来。然后上线运行后再看具体是哪个节点是性能瓶颈节点，若依然看不到性能瓶颈节点，则可能是因为上游source吞吐不够，需考虑增加source的batchsize或增加上游source的shard数。

Q:如何判断持续反压，反压时如何判断性能瓶颈点？

A:Vertex拓扑中某些节点的IN_Q持续为100%则存在持续反压情况，最后一个(或多个)IN_Q为100%的节点为性能瓶颈点。如下示例：

上图存在反压,瓶颈在6号节点。

上图存在反压，瓶颈在2号节点。

上图存在反压，瓶颈在8号节点。

上图可能存在节点，瓶颈在0号节点。

Q: 如何判断数据倾斜？

A：(1)表象上看，某些节点不论增加多大的并发仍存在性能瓶颈，则可能存在数据倾斜。
(2)在Vertex拓扑中点击疑似存在数据倾斜的节点（一般为性能瓶颈节点），进入SubTask List界面，重点观察RecvCnt和InQueue，若各ID对应的RecvCnt值差异较大（一般超过1个数量级）则认为存在数据倾斜，若个别ID的InQueue长期为100%，则认为可能存在数据倾斜。
解决方案：请您参看GROUP BY 数据出现热点、数据倾斜。

Q: 上线时指定15CU，但是上线后实际消耗仅为10CU，什么原因？

A：这种问题一般发生在Vertex只有一个节点的情况，此时由于source上游的物理表的shard数为1，Flink要求source的并发不能超过上游shard数，导致无法增加并发，因此亦无法增加到指定的CU数。
解决方案：

1. 增加上游物理表的shard数。
2. 将ID0的节点中的operator拆开，将source节点（GROUP）中的operator chainingStrategy修改为HEAD，将其从GROUP中拆解出来，然后手动配置调优。

Q: 上线时出现如左上图的告警，或出现诸如“Cannot set chaining strategy on Union Transformation”错误，如何处理？

A：这是由于作业的SQL有改动，导致DAG改变。
解决方案：通过重新获取配置解决，开发-基本属性-跳转到新窗口配置-重新获取配置信息。

 

原文链接
本文为云栖社区原创内容，未经允许不得转载。