一、Spark Stream、Kafka Stream、Storm等存在的问题

在设计一个低延迟、exactly once、流和批统一的，能够支撑足够大体量的复杂计算的引擎时，Spark Stream等的劣势就显现出来。Spark Streaming的本质还是一个基于microbatch计算的引擎。这种引擎一个天生的缺点就是每个microbatch的调度开销比较大，当我们要求的延迟越低，额外的开销就越大。这就导致了Spark Streaming实际上不是特别适合于做秒级甚至亚秒级的计算。

Kafka Streaming是从一个日志系统做起来的，它的设计目标是足够轻量，足够简洁易用。这一点很难满足我们对大体量的复杂计算的需求。

Storm是一个没有批处理能力的数据流处理器，除此之外Storm只提供了非常底层的API，用户需要自己实现很多复杂的逻辑。

二、Flink的优势

（1）不同于Spark，Flink是一个真正意义上的流计算引擎，和Storm类似，Flink是通过流水线数据传输实现低延迟的流处理；

（2）Flink使用了经典的Chandy-Lamport算法，能够在满足低延迟和低failover开销的基础之上，完美地解决exactly once的目标；

（3）如果用一套引擎来统一流处理和批处理，那就必须以流处理引擎为基础。Flink还提供了SQL/tableAPI这两个API，为批和流在query层的统一又铺平 了道路。因此，Flink是最合适的批和流统一的引擎；

（4）Flink在设计之初就非常在意性能相关的任务状态state和流控等相关技术的设计，这些都使得用Flink执行复杂的大规模任务能时性能更胜一筹。

三、Flink和Blink的主要区别

简单地说，Blink就是阿里巴巴开发的基于开源Flink的企业版计算引擎。如前面所说，虽然Flink在理论模型和架构方面有很多创新，但是在工程实现上还有不少问题。

2015年到2016年，阿里巴巴团队主要专注于解决Blink的runtime稳定性和scalability的问题：

（1）优化了集羣调度策略使得Blink能够更好更合理地利用集羣资源；

（2）优化了checkpoint机制，使得Blink能够很高效地处理拥有很大状态的job；

（3）优化了failover的策略，使得job在异常的时候能够更快恢复，从而对业务延迟造成更少的影响；

（4）设计了异步算子，使得Blink能够在即使被读取外部数据阻塞的同时还能继续处理其他event，从而获得整体非常高的吞吐率。

在拥有了稳定的runtime之后，开始专注于增强Blink的易用性 。所以在2016年底到现在，阿里巴巴团队大力开发Blink实时计算SQL，通过SQL作为统一API服务于各种复杂业务。从规范Streaming SQL的语义和标准，到实现UDX、join、aggregation、window等一系列SQL最重要的算子，几乎一手打造了完整的Streaming SQL，并且将这些工作推回了FLink社区，得到Flink社区的认可。截止目前，Blink团推先后拥有了5位Flink贡献者。

四、流数据的SQL查询存在的难点，以及Blink的解决方案

流计算SQL设计中最大的难点就是Stream SQL的语义和标准。这个事情在Flink和Calcite两个社区一直都在讨论研究中，后来达成共识—世界上不存在Stream SQL。流和 批的计算可以自然而然地在传统SQL这一层统一。

流计算所特有的unbounded特性其实本质只是何时观测抽样计算结果，这种属性可以作为一个job的configure来设置而无需去改变用户的业务查询逻辑。为了能够使用传统SQL在流计算上执行，阿里巴巴和Flink社区一起引入了动态表的概。除了动态表之外，阿里巴巴还提出并解决了流计算撤回等其他重要的流计算场景拥有的概念。有了这些语义和功能，使用传统批处理SQL就能写出Blink流式计算的任务，这样就使得使用Blink SQL作为一个支持流处理和批处理的统一的API成为可能。

基于Blink SQL，阿里巴巴打造了新一代阿里巴巴流计算平台streamCompute。现在整个阿里集团包括搜索、推荐、广告等大部分核心流计算业务都是通过streamCompute平台来提供服务。