A Year of Blink at Alibaba: Apache Flink in Large Scale Production--翻译

这是一篇转载，来自阿里搜索事业部的蒋晓伟，原文链接：A Year of Blink at Alibaba: Apache Flink in Large Scale Production。

看过文章之后，很受启发，令人备受鼓舞。

现在仔细想来，我使用Flink也已经1年了，虽然都是业务层面的流计算开发，但是对内部的原理和Flink的思想与历史，也或多或少的有了了解。

下面将文中主要内容进行翻译，希望大家也能从中有所收获！

阿里对Flink的改造并投入生产已经1年的时间。

搜索业务以前有2个job，一个是每天一次的批处理job，用Map/Reduce开发，产生每天的搜索文档；另一个job是自己开发的流处理程序，用于处理增量的更新。这种方式的问题主要是在高吞吐量和高扩展环境下，不能确保精准一次的处理。

为了解决这个问题，我们意识到需要一个为批处理和流处理统一的计算引擎，目的是在上千台集群下提供精准一次的处理。这就有2种方式可以选择：

1、批处理优先，将流切分成微批
2、流处理优先，批处理是流的特例。

第一种解决方案，即微批的处理的问题是：在高吞吐下很难提供非常低的延时。
而Flink采用了第二种方案，在没有牺牲低延时和高吞吐的情况下，统一了批和流处理。

但是在研究Flink之后发现，Flink本身也存在一些问题，使得我们决定对Flink进行改造：

1、Yarn的支持，Flink不能做到对资源的动态扩展。在改造之后，我们可以动态的请求或释放资源，并且解决了JobManager的单点瓶颈问题。

2、增量检查点。Flink的检查点是全量的，每次状态都是只增不减，这对于特别巨大的状态数据而言，检查点的效率不高。而增量检查点减少了每次巨大的状态大小，也提高了恢复的速度。

3、job的并行度不能在job运行期间改变，例如每个operator的并行度，在job运行之后就无法改变了。我们通过over-sharding解决了这一问题，使得并行度动态调整后，状态没有丢失。

4、恢复。在失败时，我们也提高了恢复的速度。

5、Table & SQL API。虽然Flink统一了批和流，但是其API还是各自的DataSet与DataStream。我们就想通过SQL统一批和流的Runtime。而且SQL本身是非常成功的声明式语言，所以SQL就成了改造Flink的另一个方面。流上的SQL就像是个动态表，我们在SQL上做了双流join，UDF, UDTF, UDAGG, windowing, retraction等工作。

在我们改造并应用到生产后不久发现，我们做的工作和Flink社区的工作发生了重叠。在讨论之后，我们决定将这些修改贡献给社区，让Flink社区和阿里都可以从中受益。从第一个分支开始到现在已经1年了，我们真的相信社区的力量而且要为社区做些贡献。

回首过往，毫无疑问，过去的一年对于Flink社区和阿里都是伟大的一年。我们承诺将继续与社区一起，推动Flink向前发展。