实时计算任务的资源调优一线踩坑实录

上周帮朋友排查了一个Flink任务的倾斜问题，整整熬了两个通宵。

别上来就堆资源

我当时看着他监控面板上那个红的发紫的单task slot，CPU跑满100%，内存堆到7.9G，其他三个slot连10%的CPU都没用到，真的想把键盘塞他显示器上。

说真的，我见过至少一半的实时任务扩容申请，都是因为负责人根本没点开监控看一眼。很多人刚接触实时计算的时候，看教程里说要给taskmanager留足够的内存做状态后端，就上来就给每个taskmanager配16G内存，根本不管自己的任务状态只有几百兆，光堆内存就浪费了大半。资源配额是你能拿的上限，并行度是你实际拆分任务的粒度，这俩根本不是一回事。这也是很多人做实时计算任务的资源调优最容易踩的第一个坑：把资源上限当成了性能本身。

倾斜的代价从来不是慢一点

那个倾斜的key是什么？是业务侧留的一个测试账号，每次客户端发心跳都会打1000条重复的用户行为埋点，占了整个任务输入数据的12%，全打在同一个并行子任务上。

很多人觉得倾斜嘛，大不了延迟高一点，等一等就过去了。麻烦在于，倾斜的子任务会持续堆堆堆，内存越用越多，到最后直接OOM，触发checkpoint失败。连续三次checkpoint失败，整个任务就会被集群自动杀掉，等你收到报警的时候，已经丢了十几分钟的数据了。

不过话说回来，你也可以选择给那个倾斜的子任务单独加资源，代价是什么？你得给这个任务单独拆一个资源队列，给那个单slot配双倍内存，算下来为了这12%的测试数据，你得多花30%的集群成本。怎么算都亏。

最后我们选的方案是给这个测试账号的key加了随机前缀打散，多了一步shuffle的网络开销，大概涨了8%，换来了整个任务的负载均衡，值。

调优不是一锤子买卖

调优完别就扔那不管。实时计算任务的资源调优根本不是一劳永逸的事。

我之前见过一个实时任务，上个月618大促的时候临时把并行度从8调到16，大促结束之后没人降回来，就那么跑了一个月，光浪费的资源够多跑三个同量级的普通任务。还有的任务，业务侧新上了一个功能，数据量直接翻了三倍，原来的并行度不够，延迟从几百毫秒慢慢涨到十几秒，等用户发现数据不对的时候，已经晚了。

不用天天盯着监控，加个简单的告警就行：CPU连续半小时低于20%，说明资源给多了；连续10分钟高于80%，或者checkpoint时长突然涨了一倍，说明资源不够或者有倾斜。发个企业微信消息给负责人，就够了。

上周跟那个朋友最后把那个测试账号的key做了打散，并行度从4调到6，每个taskmanager还是原来的4核8G，延迟直接从30s降到了800ms，半毛钱额外资源都没加。

他当时拍着大腿说早知道不申请扩容了，白挨了业务侧一顿骂。

嗨，这事没那么玄。无非是别上来就堆资源，多看看监控，多算算代价而已。