問題排查

看反壓：背壓高的下游oprator就是瓶頸
關(guān)注checkpoint時長
checkpoint時長一定程度影響系統(tǒng)吞吐
看核心指標(biāo)
延遲指標(biāo)秦忿、吞吐等
資源使用率

常見問題

json序列化反序列化
通常在source和sink的task上,在指標(biāo)上沒有體現(xiàn),容易被忽略(取消operator chain,查看反壓)
數(shù)據(jù)傾斜
數(shù)據(jù)傾斜影響系統(tǒng)吞吐
頻繁GC
內(nèi)存比例分配不合理導(dǎo)致頻繁gc弄贿，影響吞吐甚至tm失聯(lián)
MAP和SET的hash沖突
有hashmap和hashset 隨著負(fù)載因子的增高孝冒，引起插入和查詢性能下降
和低速的系統(tǒng)交互
和低速的外部系統(tǒng)交互,mysql侵贵、hbase (增加應(yīng)用緩存、積攢批次處理避免單條查詢)
大窗口
1）窗口size大笆制、數(shù)據(jù)量大
2）滑動窗口size和step步長比例較大 eg size=5min,step=1s 同一條數(shù)據(jù)查法很多窗口的計算

數(shù)據(jù)傾斜影響

數(shù)據(jù)熱點：數(shù)據(jù)集中在某些task中,數(shù)據(jù)不平衡
GC頻繁：過多的數(shù)據(jù)在jvm,導(dǎo)致內(nèi)存資源短缺,觸發(fā)頻繁gc
吞吐下降,數(shù)據(jù)延遲增大
系統(tǒng)崩潰過長的gc會導(dǎo)致tm和jm失聯(lián),系統(tǒng)崩潰

數(shù)據(jù)傾斜

1.源頭
數(shù)據(jù)源消費不均勻,調(diào)整并行度(eg kakfa 分區(qū) 3個kafka分區(qū) 兩個并行度導(dǎo)致其中一個task處理2個kafka分區(qū) 另一個處理一個分區(qū))
解決辦法：通常source的并法度是kafka分區(qū)的整數(shù)倍

2.聚合場景

image.png

解決辦法：兩段聚合的方式（局部聚合+全局聚合）
方案適用場景：對RDD執(zhí)行reduceByKey等聚合類shuffle算子或者在Spark SQL中使用group by語句進(jìn)行分組聚合時氮墨，比較適用這種方案。

方案實現(xiàn)思路：這個方案的核心實現(xiàn)思路就是進(jìn)行兩階段聚合栗弟。第一次是局部聚合污筷，先給每個key都打上一個隨機(jī)數(shù)(注意：隨機(jī)數(shù)范為選擇為下游并發(fā)度)，比如10以內(nèi)的隨機(jī)數(shù)乍赫，此時原先一樣的key就變成不一樣的了瓣蛀，比如(hello, 1) (hello, 1) (hello, 1) (hello, 1)，就會變成(1_hello, 1) (1_hello, 1) (2_hello, 1) (2_hello, 1)雷厂。接著對打上隨機(jī)數(shù)后的數(shù)據(jù)惋增，執(zhí)行reduceByKey等聚合操作，進(jìn)行局部聚合改鲫，那么局部聚合結(jié)果诈皿，就會變成了(1_hello, 2) (2_hello, 2)。然后將各個key的前綴給去掉像棘，就會變成(hello,2)(hello,2)稽亏，再次進(jìn)行全局聚合操作，就可以得到最終結(jié)果了缕题，比如(hello, 4)截歉。

內(nèi)存調(diào)優(yōu)

image.png

Flink中的總內(nèi)存由JVM堆、manager memory和network buffers構(gòu)成
對于容器化部署烟零，總內(nèi)存還可以包括一個容器預(yù)留內(nèi)存

所有其他內(nèi)存組件都是在啟動Flink進(jìn)程之前從total memory中計算出來的瘪松。啟動后咸作，manager memory和network buffers在某些情況下根據(jù)進(jìn)程內(nèi)可用的JVM內(nèi)存進(jìn)行調(diào)整
total memory 由taskmanager.heap.size指定
在Yarn or Mesos部署時,是請求容器大小

Container cut-off

引入截斷是為了適應(yīng)其他類型的內(nèi)存消耗，而這些消耗在這個內(nèi)存模型中沒有考慮宵睦，例如RocksDB本機(jī)內(nèi)存性宏、JVM開銷等。它也是一個安全余量状飞，以防止容器超出其內(nèi)存限制并被容器管理器殺死毫胜。
containerized.heap-cutoff-ratio ：默認(rèn)為0.25(占總內(nèi)存的)

堆外內(nèi)存調(diào)優(yōu)

NetworkBuffer
taskmanager.network.memory.fraction：默認(rèn)是0.1
taskmanager.network.memory.min:默認(rèn)是64M
taskmanager.network.memory.max: 默認(rèn)是1G
一般taskmanager.network.memory.fraction是0.1或小于0.1 根據(jù)使用情況調(diào)整
ManagerBuffer :
taskmanager.memory.off-heap:true（默認(rèn)是false不開啟）
taskmanager.memory.fraction(默認(rèn)是0.7)
考慮到流計算過程中ManagerBuffer沒有使用,可以taskmanager.memory.fraction調(diào)整小于0.3

堆內(nèi)內(nèi)存調(diào)優(yōu)
flink運行在jvm上，F(xiàn)link使用的 Parallel Scavenge垃圾回收器可以改為G1

env.java.opts= -server -XX:+UseG1GC - XX:MaxGCPauseMillis=300 -XX:+PrintGCDetails

內(nèi)存模型的例子

TM總內(nèi)存8G, cutoff:容器的預(yù)留內(nèi)存(k8s诬辈、yarn)為8G * 0.25

taskmanager.memory.fraction設(shè)置,例如
0.8的值意味著TM為內(nèi)部數(shù)據(jù)緩沖區(qū)保留了80%的內(nèi)存(堆內(nèi)或堆外酵使，取決于taskmanager.memory.off . heap)，將20%的空閑內(nèi)存留給TM的堆焙糟，供用戶定義的函數(shù)創(chuàng)建的對象使用口渔。此參數(shù)僅在taskmanager.memory未設(shè)置是生效。
managed = (total - network) x fraction
heap = total - managed (if off-heap) - network
network = Min(max, Max(min, fraction x total)