Apache Flink 1.0.0 版本发布

Apache Flink 1.0.0 版近日发布了。Flink 是分布式流和数据批处理的平台。1.0.0 发布版本保证了与以后的1.x.x 版本的后向兼容性。由64 个贡献者提交的450 个JIRA 问题，都在这个版本中被修复了。除了修复故障，这个版本还有许多面向用户的新特性。

InfoQ 与 Stephan Ewen（项目提交者）取得了联系并就 1.0.0 发行版进行了探讨，包括它的新特性和早先InfoQ 刊登的新闻之后该项目的动态。

InfoQ：在 0.9 发布之前我们曾经和你讨论过它。跟我们讲一下之后的历程，尤其是在 1.0.0 中新的面向用户的特性。

Stephan Ewen:我们上次谈论之后，Flink 又有了相当的发展。过去的发行版本注重构建流处理能力。我们从 0.9 版开始重写了数据流的 API。我个人赞同数据流处理 (data streaming) 可以囊括许多现在的批处理程序的愿景。Flink 已经增加了许多功能让这个愿景变得可能。

现在，数据量 API 合并了许多先进的功能，比如支持 Event Time，支持无序的流（一种非常灵活并且可定制的窗口机制）以及容错的分布式状态。Flink 的运行时可以提供高吞吐量的同时保持较低的处理延迟，还能对状态和窗口提供精确的一次性（exactly-once）处理语义。我们还增加了许多运行方面的功能，例如高可用性（没有单点故障）和更好的监控（测量和网络仪表面板），甚至还为 Apache Storm 提供了兼容层用以重用那些为 Storm 拓扑编写的代码。

1.0 发行版面向用户的最突出的特性可能是“保存点（savepoints）”、“复杂事件处理”（CEP）库、支持 Kafka 0.9 版本、核外状态以及更好的监控能力（例如对于检查点和背压（backpressure））。CEP 库允许用户定义事件队列和数据流中搜索的条件。保存点主要保存了某个特定时间点上流处理器的完整状态的快照，你可以从这个状态重新运行程序（或其他程序）。这个机制非常强大，它可以用于回滚或重新运行流计算，或者没有失败和中间状态的情况下升级程序。

当然，Flink 的其他部分也在逐渐进步，包括数据集（批处理）API 和图像处理库“Gelly”。

InfoQ：1.0.0 是不是第一个保证后向兼容性的发行版？你们打算如何做到这一点？从 Apache Flink 的早期版本迁移到 1.0.0 难不难？

Stephen Ewen：向后兼容指的是公开稳定的 API 中的类和方法，那些类都使用特殊的 Java 声明“Public”来标记。这些稳定的 API 包括大多数的数据流和数据集 API 构造。在未来的 1.x 版本中，这部分会保持稳定。

还有许多部分被标记成“Public Evolving”。对这些特性，细节部分可能在未来版本中根据社区的反馈随时进行调整。

从 0.10 向 1.0 版本迁移数据流程序应该讲非常简单，因为数据流 API 的最大的破坏性更改发生在 0.9 和 0.10 版本之间。事实上现在数据集 API 已经稳定了好几个版本了。

InfoQ：我们在之前的会谈中已经讨论过和 Apache Spark 之间的相似性。流处理平台看起来是一个充满竞争的领域，看起来似乎也不乏相关项目。开发者为什么要使用 Apache Flink 呢？与其他竞品相比有什么贴心的东西吗？

Stephan Ewen：在我看来，Flink 的能力在于它对 API 的整合、操作功能和性能。你可以使用它构建流解决方案，这对于其他的框架来说是不可能的，或者说现在不可能显著地比它（Flink）更简单。

数据流 API 简洁而灵活，支持一些对先进应用非常重要的特性，比如事件时间（event time），定制窗口或状态。Flink 运行在合适的流模型之上，这就赋予了它良好的延迟和反压力方面的表现，强大的语义容错性能（exactly once）以及与 Kafka 和 YARN 很好地集成。

最终，Flink 有着十分复杂的状态管理的支持，包括之前提过的“保存点（savepoints）”。这些保存点可以用于重算和程序不同版本的分支扩展（想一下 A/B 测试）。

InfoQ: 性能往往是这个领域的区分器。你能否描述下相对于这个领域的其他项目，Apache Flink 的性能表现如何？

Sephan Ewen:经过自身的测试，Flink 的运行时已经具有非常有竞争力的性能，无论是吞吐量还是延迟。在许多真实的应用程序中，流处理器自身却并不是性能瓶颈。性能往往受到与其他服务的交互的限制，比如跟外部数据库。

就因为这样，我觉得更重要的事实是 Flink 对于状态和一致性的强大支持使得用户可以使用和以前不一样的方式构建应用程序来绕过那些瓶颈。例如最近有篇文章提到一个实例，绕过对于使用键 / 值存储的需求，同时使用流处理器的来存储和暴露实时统计数据。性能的巨大提升同时伴随着对于资源需求的显著减小。

InfoQ：比方说，Apache Flink 和 Apache Kafka 比起来怎么样？Kafka 连接器起什么作用？

Stephan Ewen：Flink 和 Kafka 解决的是完全不同的问题，且相互之间有良好的补充。Kafka 提供流信息的持久化存储，Flink 在流的基础上进行计算和分析。Flink 的 Kafka 连接器从 Kafka 代理中接受事件流，并追踪元数据以确保失败后可恢复，仅处理一次（exactly-once）的语义也会被保留。

InfoQ：你能否谈一下 Apache Flink 环境中的状态？它如何使用 RocksDB 来存储状态？为什么选择 RocksDB？

Stephan Ewen：流程序中的状态是所有其他更复杂的应用的基础。计时或计数窗口都有状态，比如说 CEP
库在一个序列模式中追踪当前事件。早期的流处理器，比如 Apache Storm，必须依赖外部的键 / 值存储保存状态。Flink 在流处理器内部维护状态（在工作进程中），而且定时检查状态用于容错。

Flink 拥有多种所谓的“状态后端”供用户选择，它们描述了 Flink 保存状态的数据结构。其中一个状态后端的选择是 RocksDB，我们选择它因为它是固定并可扩展基于磁盘（或者闪存）的键 / 值索引。要是程序保存非常多的状态信息甚至超过工作机器的内存的话，它是非常好的选择。另一方面，对于具有状态的程序而言，要是状态完全的适合主内存，也可以使用纯内存的状态后端。

InfoQ：能不能谈一下在 1.0.0 中还未完成的工作，接下来的发行版的路线图是怎样的？沿着这条路，这个项目在接下来一两年的时间准备有什么发展？

Stephan Ewen:在路线图中有许多非常有趣的功能正在开发着。在不久的将来，API 方面最大的补充可能是流式 SQL。

在业务功能方面，我们正在开发动态并行运算，意思是说流式程序可以在运行的时候向内和向外扩展。此外，与 Mesos 资源管理框架的整合也在进行中，还有为非常大的状态的设置检查点的性能提升。为其他系统增加或提升连接器性能和改善监控的工作也在持续进行中。

最终，Flink 社区的人们在 Apache Beam（孵化）项目中也很活跃。给 Beam 管道的 Flink 运行器也是目前功能最完善的开源 Beam 运行时。我们正在和 Beam 社区合作进一步演化 Flink 运行器和 Beam 程序模型。

基于不同的 Hadoop 版本的 Apache Flink 下载以及其他的入门材料可以在这篇文档中获得。

查看英文原文： Apache Flink 1.0.0 is Released