Flink方案设计中的4大误区

本文主要介绍Flink 方案设计中的一些常见误区，这些大多数是因为开发者没有充分思考需求导致， 分别如下:

1. 未考虑数据一致性跟交付保证
2. 未考虑业务后续升级以及应用改进
3. 未考虑业务规模问题
4. 未深入考虑业务实际需求

提到一致性与交付保障，其实可以通过如下几个问题针对具体的业务场景来选择具体方案。

首先要考虑是否在乎数据的丢失是否对业务产生影响，如果不在乎的话，可以不添加Checkpoint。

其次要考虑是否在乎结果的正确性。在很多场景中，结果的正确性对业务来说非常重要，比如交易相关业务； 但是在另外一些场景，比如监控等我们仅需要一个概要的数据统计，少量的数据异常并不会影响最后的统计分布。 如果不在乎结果的正确性，可以考虑采用at-least-once语义并使用可重放(replayable sources) 的数据源。

如果下游要求数据不能出现重复，尽管数据正确也只能发送一次，这时要使用 exactly-once 语义并使用可回放的数据源，另外sink需要支持事务。

我们进行上述的分析后，最终的目的其实是针对于具体的业务以及在后续的业务进行调整时来进行方案的调整。 我们调整的核心因素就是”延迟“，既要考虑数据准确性，也要根据业务的延迟来进行权衡选择。

另外，由于一个业务不是一成不变的，所以在设计完成之后还要考虑后续可能涉及到的升级。针对于这点，我们有如下几个问题需要考虑:

1. 在一些复杂场景下，由于业务需求的变更，可能需要调整任务拓扑结构，比如增加或删减某个算子。 在这种情况下，一定要注意保证任务重启后是否可以恢复到原来的状态。

如果我们新的拓扑删减了某个算子导致任务重启时Flink发现之前的某个节点不存在了，对应 的状态就无法成功恢复，系统会抛出异常导致重启失败。 （可以通过参数 --allowNonRestoreState 来忽略该类问题 ）

如果新作业中包含新建的节点，这个节点就用空状态去初始化即可。
另外需要注意，为了保证作业成重启且状态的恢复不受影响，我们应该为各个算子设置 StreamAPI 中的 uid 。如果状态的结构发生了变化，Avro Types 和 POJO 的类型都是可以直接支持的，Kryo 是不支持的。

最后建议所有 key 的类型尽量不要修改，因为这会涉及 shuffle 和状态的正确性。

2. Flink 作业一般都有状态读取，做升级时需要有 savepoint 机制来保障，将状态存储保留在远端，再恢复到新的作业上去。很多场景下都会有升级的需求，这简单列了几点：

a 升级集群版本 b 业务 bug 的修复 c 业务逻辑（拓扑）的变更

资源的使用情况也是必须要考虑的因素之一，下面是一个评估内存和网络 IO 使用的思路。这里我们假设使用的是 Fs State，所有运行时状态都在内存中。不恰当的资源配置可能会造成 OOM 等严重的问题。