杂谈：我为什么推荐 Apache Flink

在过去的一年多时间里，我一直在队伍里推广 Apache Flink。很多朋友大概都知道，一年多以前，我负责的项目还在推 Spark，但如今我却极力推荐大家尝试使用 Flink。公司内外许多朋友开始问我：为什么一年里我的态度转变如此之大，特别是当我司加大对 Spark 的支持力度的时候。所以我想，也许我可以把自己的一些经验做一些总结。

我们部门用 Flink 的时间不长，应用领域限制在实时计算，所以我的经验也只能围绕一些我们实际用到的工程特性展开。至于其它一些特性比如机器学习支持之类，我也不甚了了。考虑到网上也有很多各种评测和讨论，诸君不妨在 Google 上搜索相关的文章。

新上手的惊喜：小功能的大作用

刚上手 Flink 时，我惊喜地发现 Flink 添加了两个很小但实用的功能，都恰到好处地解决了我们之前在用 Spark 时的一些工程上的痛点。这在一开始时给了我巨大的好感。

个好用的功能是项目模版。Flink 提供了 flink-quickstart-java 和 flink-quickstart-scala 插件，允许使用 Maven 的开发者创建统一的项目模版。熟悉 Maven 的朋友可能都了解，Maven 的 pom.xml 可以借助各种插件完成极其灵活的功能，但需要程序员对插件有足够多的了解才能驾驭。比如uber-jar 打包时去除不必要的依赖，在运行环境相对复杂的大型项目中十分必要，但很容易就因为配置不当混入额外的依赖包。在使用 Spark 的时候我们经常图省事把需要的 Spark 运行时包组成 uber-jar，产生的 jar 包动辄上百 MB，集成测试时上传更新非常不便。而 Flink 的模版则直接集成了一个良好的 uber-jar 配置，大部分 Flink 运行时包都被有效地排除了出去，终产生的 jar 包经常只有数百 KB 到几个 MB，上传下载都节约了不少时间，大大提高了集成测试的效率。

另一个我迅速喜欢上的功能是 RichFunction 接口。Flink 的开发始于 Java 7 时期，因此其大部分操作符都是从某个接口继承下来并扩展，直到 Java 8 开始才引入 lambda 作为操作符。作为习惯了 Spark 的开发者，我一开始也很自然地嫌弃麻烦的接口而尽量用 lambda，但很快地我就发现 Flink 的好处：它的 RichFunction 接口允许我实现一个 open() 函数，这恰恰是我用 lambda 时一直想要的功能。代码示例如下：

public class MyFilter extennds RichFilterFunctttttion<String> {
     public void open(Configuration parameters) {
         // Call loadLibrary()
     }
     public boolean filter(String value) {
         // Call native functions via JNI
     }
 }