专注思考的时候，时间仿佛也静下来了

自 feature freezed 以后经过近一个月的努力，Flink 社区在十一月的最后一天终于发布 Flink 1.7.0 版本。该版本处理了 420 个 issue，其中新特性或者改进主要集中在 SQL 和 State 两个模块上，另外从 1.7 开始更多的 API （包括 REST、State 还有正在讨论的 runtime）会考虑版本兼容性，以便用户更重度地依赖 Flink 做上层的开发。

数据倾斜是分布式领域最为常见及棘手的问题之一。通常来说分布式系统会以数据的 key 来对数据进行 partition (分区)，不同 key 的计算和状态都是独立，因此可以用分治的方式并行处理。当发生数据倾斜时，数据会集中到少部分的 key 上，导致这些 key 对应的 subtask 负载比其他 subtask 高得多。而在使用 event time 时间特性和 watermak 机制的实时计算系统里面，数据倾斜有了新的表现形式，即 event time 倾斜（event time skew），不同数据流的 event time 存在差异。

随着近来越来越多的业务迁移到 Flink 上，对 Flink 作业的准确性要求也随之进一步提高，其中最为关键的是如何在不同业务场景下保证 exactly-once 的投递语义。虽然不少实时系统（e.g. 实时计算/消息队列）都宣称支持 exactly-once，exactly-once 投递似乎是一个已被解决的问题，但是其实它们更多是针对内部模块之间的信息投递，比如 Kafka 生产（producer 到 Kafka broker）和消费（broker 到 consumer）的 exactly-once。而 Flink 作为实时计算引擎，在实际场景业务会涉及到很多不同组件，由于组件特性和定位的不同，Flink 并不是对所有组件都支持 exactly-once（见[1]），而且不同组件实现 exactly-once 的方法也有所差异，有些实现或许会带来副作用或者用法上的局限性，因此深入了解 Flink exactly-once 的实现机制对于设计稳定可靠的架构有十分重要的意义。

Flink 为作业的容错提供 Checkpoint 和 Savepoint 两种机制，而这两者在无论在命名还是使用上都十分相似，很容易令用户混淆，因此 Checkpoint 和 Savepoint 有何区别也是 Flink 社区常见的问题之一。除开生产环境不常见的内存 Checkpoint，External Checkpoint 和 Savepoint 都是作业状态（State）的持久化副本，也理所当然地可以用于作业恢复，甚至在提交作业时指定状态的参数都可以两者通用。那么它们究竟有什么不同呢？

由于实时场景对可用性十分敏感，实时作业通常需要避免频繁重启，因此动态加载作业配置（变量）是实时计算里十分常见的需求，比如通常复杂事件处理 (CEP) 的规则或者在线机器学习的模型。尽管常见，实现起来却并没有那么简单，其中最难点在于如何确保节点状态在变更期间的一致性。目前来说一般有两种实现方式：

• 轮询拉取方式，即作业算子定时检测在外部系统的配置是否有变更，若有则同步配置。
• 控制流方式，即作业除了用于计算的一个或多个普通数据流以外，还有提供一个用于改变作业算子状态的元数据流，也就是控制流。

Flink 作为一个基于内存的分布式计算引擎，其内存管理模块很大程度上决定了系统的效率和稳定性，尤其对于实时流式计算，JVM GC 带来的微小延迟也有可能被业务感知到。针对这个问题，Flink 实现了一套较为优雅的内存管理机制，可以在引入小量访问成本的情况下提高内存的使用效率并显著降低 GC 成本和 OOM 风险，令用户可以通过少量的简单配置即可建立一个健壮的数据处理系统。

五月底 Apache Flink 迎来了 1.x.y 版本线的第六个主要发行版 1.5.0。这个版本包含了多个重要特性，其中最为引人注目的是 FLIP-6 重写了资源调度模型（尽管未全部完成），以便与 YARN、Mesos 等集群管理器和 Dockder、Kubernetes 等容器技术更高效、更优雅地交互。

Flink 为实时计算提供了三种时间，即事件时间（event time）、摄入时间（ingestion time）和处理时间（processing time）。在进行 window 计算时，使用摄入时间或处理时间的消息都是以系统的墙上时间（wall clocks）为标准，因此事件都是按序到达的。然而如果使用更为有意义的事件时间则会需要面对乱序事件问题（out-of-order events）和迟到事件问题（late events）。针对这两个问题，Flink 主要采用了以水位线（watermark）为核心的机制来应对。

准确一次(exactly once)的送达保证是实时计算的关键特性之一，这要求作业从失败恢复后的状态以及管道中的数据流要和失败时一致，通常这是通过定期对作业状态和数据流进行快照实现的。然而这种方式主要有两点不足：首先，快照进行期间常常要暂停数据流的摄入，造成额外延迟和吞吐量下降；其次，快照会过度谨慎地将管道里正在计算的数据也随着状态保存下来，导致快照过于庞大。针对以上两个问题，Apache Flink（下简称 Flink）引入了异步屏障快照（Asynchronous Barrier Snapshot, ABS）。

The Dataflow Model 是 Google Research 于2015年发表的一篇流式处理领域的有指导性意义的论文，它对数据集特征和相应的计算方式进行了归纳总结，并针对大规模/无边界/乱序数据集，提出一种可以平衡准确性/延迟/处理成本的数据模型。这篇论文的目的不在于解决目前流计算引擎无法解决的问题，而是提供一个灵活的通用数据模型，可以无缝地切合不同的应用场景。