由于我们的实时数仓开始尝试基于StarRocks，但是当我们尝试把上百数据表通过Flink-conector 往Starrocks 写的时候，一开始都还好，但是到我们偶尔业务 膨胀 及 Starrocks 无资源隔离，导致写入性能受到影响的时候，Flink 任务会报checkpoint超时。
我们的排查思路：首先我们没有用状态后端，纯ETL，另外我们使用的是 At-least-once ，通过Starrocks来做幂等。exactly once 我们看了会保存到 operator state 中。 所以我们优先就是排查 starrock sink，通过对源码的分析，发现当 Starrocks 写入压力很大时，stream load 会阻塞，导致checkpoint超时，因为内部用了一个 容量为1 的阻塞队列来控制。 checkpoint 必须要把当前所有的数据都 sink 完成后才会成功
建议：可以又Starrocks 来维护一个参数，写入多久算 失败，然后直接抛出 用户直观的 异常，让用户明显知道 是 starrocks 的压力问题，而不是体现出来的 checkpoint超时