全部产品
存储与CDN 数据库 安全 应用服务 数加·人工智能 数加·大数据基础服务 互联网中间件 视频服务 开发者工具 解决方案 物联网 钉钉智能硬件
流计算

性能调优

更新时间:2018-01-10 15:49:37

性能调优

Stream SQL任务开发完成后,需要点『资源配置』,通过『获取自动生成JSON配置』来生成一份默认的配置文件。用户可以对资源配置进行修改,从而对性能调优。资源文件基本概念

异常分析

由图所示:

  1. 3号的TASK节点的输入队列已达到100%造成数据堆积反压到它的上游1号的TASK节点,现在1号的TASK节点接着反压到0号的TASK的输出队列造成数据堆积。

    111

  2. 单击3号的TASK节点,找到队列已达到100%的TaskExecutor .

    112

  3. 查看TaskExecutor的CPU和内存的使用量,根据使用量来调大相应的CPU和MEM。

    113

    性能调优

    进入调优窗口

    114

    打开可视化编辑115

116

批量修改

117

单节点修改

118

点击用配置好的参数,重新上线启动。

资源如何设置

可调参数:

● parallelism:

  • source

    1. 资源根据上游Partition数来。例如SOURCE的个数是16,那么source的并发可以配置为16,8,4等,不要超过16
  • 中间的处理节点

    1. 根据预估的QPS计算。对于小任务来说,和source一样的并发度就够了。QPS高的任务,可以配大点,例如 64128 或者 256
  • sink节点

    1. 并发度和下游存储的Partition数相关,一般是下游Partition个数的2~3倍。如果配置太大会导致写超时或失败。例如下游SINK的个数是16,那么sink的并发最大可以配置48

● vcore: CPU,默认 0.1,根据实际CPU使用配置(但最好能被1整除),一般建议0.25

● heap_memory: 堆内存,默认 256MB,根据实际内存使用配置点击GROUP就可以编辑以上参数。

● 如果有GROUP BY 的TASK节点可以配置以下参数:

state_size: state大小,默认0。如果operator有用state,需要把state_size配成1,表示该operator会用state,job在申请资源的时候会额外为该operator申请内存,供state访问使用;如果不配成1,job可能被yarn kill。(state_size需要配成1的operator有:group by, join, over, window) 虽然有这么多配置项,对普通用户来说,只需要关心:vcore,parallelism和heap_memory。整个job 建议core:mem=1:4,即一个核对应4G内存。

性能调优相关

miniBatch设置: 该设置只能优化group by。Stream SQL纯流模式下,每来一条数据都会去操作state,io消耗较大,设置miniBatch后,同一个key的一批数据只访问一次state,且只输出最新的一条数据,即减少了state访问也减少了向下游的数据更新。miniBatch设置如下:

  1. 表示整个job允许的延迟

  2. blink.miniBatch.allowLatencyMs=5000

  3. 单个batch的size

  4. blink.miniBatch.size=1000

    119

上下游的参数配置

名称 参数 详情 设置参数值
DATAHUB源表 batchReadSize 单次读取条数 可选,默认为10
DATAHUB结果表 batchSize 单次写入条数 可选,默认为300
日志服务(SLS)源表 batchGetSize 单次读取logGroup条数 可选,默认为10
分析型数据库(AnalyticDB)结果表 batchSize 每次写的批次大小 可选,默认为1000
云数据库(RDS)结果表 batchSize 每次写的批次大小 可选,默认为50

示例:

22

概念介绍

global

● isChainingEnabled : 表示是否启用chain策略,默认为 true,『不需要改』.

nodes

● id : 节点id号,自动生成,唯一,『不需要改』.

● uid: 节点uid号,用于计算operator id,如果不设置,会使用id.

● pact:节点类型,例如Data Source,Operator,Data Sink等等,『不需要改』.

● name:节点名字,用户可以自定义.

● slotSharingGroup: “default”,『不需要改』.

● chainingStrategy: chain的策略,有 HEAD, ALWAYS, NEVER,『不需要改』.

● parallelism: 并发度,默认为1,可以根据实际数据量改大点.

● vcore: CPU,默认 0.1,根据实际CPU使用配置(但最好能被1整除),一般建议0.25 .

● heap_memory: 堆内存,默认 256MB,根据实际内存使用配置.

● direct_memory: jvm堆外内存,默认0, 建议不要改.

● native_memory: jvm堆外内存,jni使用,默认 0,建议用10MB.

● source: 源节点.

● target: 目标节点.

● ship_strategy: 分发策略,例如”FORWARD”.

● side: “second”.

Chain

Stream SQL 任务是一个DAG图,会有很多个节点(Operator),有些上下游的节点在运行时是可以合成一个点的,这称之为『chain』。对于chain之后的点,CPU取最大的最大值,内存取总和。例如Node1{256MB,0.2core},Node2{128MB,0.5core},Node2{128MB,0.25core},那么这三个点chain后的CPU是 0.5core,内存是 512MB。chain的规则简单来说就是:并发度需要一样。但是,有些节点之间是不能合在一起的,比如groupBy。一般来说,尽可能的让节点都chain在一起,减少网络传输。

本文导读目录