Flink的TTL是否会对数据一致性造成影响？

Question

Time-To-Live 是否会对 Flink 的 数据一致性 造成影响吗？
比如：程序因为某个原因 回放 到上个 checkpoint 的状态了，然后它的执行结果与没有 回放 的执行结果不一样了。因为如果没有 回放 的话，某些 State 应该因 过时 而清除，但 回放 操作变相 延长 了这部分 State 的 过期时间 。

有办法优化这种情况吗？

Answer 1

Flink是一个可以处理有边界和无边界数据流的有状态计算框架。Flink为普通用户案例在不同抽象级别和专业库上提供了多种应用接口。

这里，我们呈现一下Flink的简单使用及令人印象深刻的接口和库。

为了流式应用绑定数据块

那些能构建和执行成流失框架处理的的各类应用常常被定义为在控制流、状态及时间上的如何运行良好。接下来，我们描述一下这些流式应用构建块及解释Flink的方式是如何去处理它们的。

流

很显然，流是一种面向基础的流式处理。然而，流可以有不同的特点去影响一个可以和应该怎么被处理。Flink是一个全方位的处理框架可以处理任何流。

有边界和无边界的流：流可以是有边界或者无边界的。举例：固定大小数据集。Flink有高级特性去处理无边界的流，也有专用的操作去有效的处理有边界的流。

实时和离线流：所有数据都会被当成流来生成。有两种方式可以来处理数据。即时生成的数据实时处理，或者持久化流到存储系统。

例如：文件系统或对象存储，我们都会稍后处理它。Flink应用可以同时处理离线或实时流。

 

状态

每一个不平凡的流式应用都是有状态的。例如：应用程序只需个别事件的转换才不需要状态。任何应用程序只要运行基本的业务逻辑都需要去记住事件和即时结果，比如当接收到下一个事件或者过了一段特殊的时间间隔之后。

 

应用程序状态是Flink中的第一等公民。你可以查看flink在状态处理中提供的所有特性。

提供多种方式的状态原始值获取： Flink提供了各种数据结构的状态原始值，例如原子类型值、列表或者键值对形式。开发者们可以自行选择最有效率的方式。

可插拔式的状态管理支持：应用程序状态用一个可插拔的状态后端来管理和记录检查点。Flink将不同的状态保存到内存或RocksDB数据库，一种有效率的嵌入式磁盘存储。自定义的状态保存后端也可以即时插拔。

恰好一次的数据一致性保证：Flink的检查点和恢复算法能保证在失败的情况下应用程序状态的一致性。同时，失败会被透明处理并且不会影响应用程序的正确执行。

大数据量的状态管理： Flink可以管理几个Tb的应用程序状态数据，归功于它的异步和增量式检查点算法。

应用的可扩展性：Flink通过分发状态到更多或者更少的工作节点上来支持有状态应用程序的扩展。

 

时间

时间是流式应用的另一个重要成分。因为每一个时间的生成都是在一个很特殊的时间点，所以大部分事件流都有一个固定的时间语意。

不仅如此，很多一般式的流计算都是基于时间的，例如窗口聚合、会话式的操作、模式识别以及基于时间序列的连接操作。流式处理一个很重要的方面就是如何让应用程序区分时间。例如：事件时间和处理时间的区别

Flink提供了一系列与时间有关的特性。

基于事件时间的模式：事件时间语意下的流式处理应用程序的计算结果是基于事件时间戳的。因此，基于事件时间的处理能提供准确一致的结果而不管记录是被实时还是离线事件处理的。

水印的支持：Flink用水印来推断事件时间的应用程序的时间。水印同时也是一种灵活的机制来处理延时和结果的竞争。

迟到的数据处理：当处理流是使用水印的事件时间模式的时候，它会发生一种情况就是，计算会在所有关联的事件到来之前完成。这些事件被称为迟到的事件。Flink提供了多种方式处理这些迟到的事件，例如将他们改道并更新已完成的结果。

基于处理时间的模式：基于事件时间模式之外，Flink也支持基于处理时间的语意，它会使计算基于处理机器的时钟时间来触发计算。这种模式可以适用于那些对低延迟有很严格要求但是可以容忍相似结果的应用。

分级别的APIs

Flink提供了三种级别的APIs。每种API提供不同的代价的简洁性及可表达性的区别，并且服务于不同的案例。