Flink大数据计算的机遇与挑战

本文来自于王绍翾在2018年08月11日Flink China Meetup。 王绍翾，花名“大沙”，加州大学圣迭戈分校计算机工程的博士，Apache Flink Commiter。目前在阿里负责Flink平台以及生态的一些工作。

本文内容如下：

流计算核心技术

  Flink是德国data Artisans创造的，早期Flink主要是做偏批计算的，但是Spark在批处理上已经有一定优势，正面竞争没什么意义，于是改变方向，基于chandy-lamport算法开始做流计算，完成后完美的解决了低延迟问题和状态管理。

低延迟，快速容错

  低延迟是Flink源生的，当然保证了快速容错。大数据计算中job总是会失败，所以需要能够快速的恢复。如果平时延迟很低，但是job一失败，恢复几分钟，肯定是无法接受的。

通用的API，易用性

  Flink有了基础的能力后，开始考虑通用的API，最开始的时候有了一些Java和Scala的一些API。但是发展到一定程度之后，因为API不只是开放于开发，而是所有用户。怎么样更容易的满足用户的需求和支持用户，这是流计算的很核心的一点。

弹性，高性能

  弹性，高性能是大数据不变的主题。怎么样确保引擎在上千台机器不出问题的运行，scalability很重要，包括Spark早期到一定规模遇到很多问题，当然Blink已经完美的解决了所有问题。在性能上，Flink不仅是在流计算还是批处理上已经有了绝对的优势。

流和批的统一

  Flink的早期interface是非常弱的，包括Spark早期也是，于是流计算的社区开始讨论流计算的SQL到底是什么样子的，于是形成了两派风格，一派是认为Streaming SQL是一种different SQL跟Batch Sql，另一派推的SQL跟Batch SQL是完全一致的。

  为什么会说完全一致？流计算跟批计算一个基本的区别是，都是计算，但是流计算需要提前看到结果，这需要将结果提前发出，但是后面过来的数据会对前面的结果进行修正，所以流计算跟批计算比较大的区别就是数据提前发出和数据修正，最终保证数据正确。

怎么来处理这个问题:

• 首先要告诉用户API，怎么样去计算完全是用户的语义
• 另外两点就是什么时候发出去，什么时候修正，这些跟SQL本身描述是没什么关系的
• 所以传统的A