近年来，流处理变得越来越流行。实时数据分析有更大的价值所在，而现在许多系统都是连续的事件流，除了互联网领域，车联网，电力系统，穿戴设备等等的数据都是以事件流的方式收集并处理的。但目前为止大多数公司并没有用流处理的方式解决实时大数据分析的问题，原因可能是有限数据的存储更容易，而sql等分析方式也更简单。但只有用流的方式处理这种数据才是更符合实际的，当然这个困难很大，涉及数据一致性与时间的问题，其实已经属于物理学范畴。
图 google dataflow
但是幸好我们有Flink，相对于Storm与Spark Streaming，Flink更符合Google Dataflow（见文章实时计算大数据处理的基石-Google Dataflow https://mp.weixin.qq.com/s/a30H5GztIzqFyv84IOqLJg）的理念，不同于Spark Streaming的微批，flink还是采用流处理的方式，而离线批处理flink也可以去做，因为在flink中批处理是流处理的一个子集，有限数据处理其实本来就是无线数据处理的一部分。作为高度创新的开源流处理器，Flink 拥 有诸多优势，包括容错性、高吞吐、低延迟。优秀的流处理框架应该不仅能做到低延迟高吞吐，还要可以做到消息正好传递一次，并有优秀的容错机制。
Twitter开源的Storm框架风靡一时，在Hadoop诞生初期，Storm弥补了Hadoop不能做实时数据处理缺陷，被广泛使用，现在的很多公司依然在使用，Storm延迟是毫秒级的，但是它很难实现高吞吐，不能保证消息恰好一次的传递。我们可以通过ack机制保证，但开销极大，现在很多使用Storm的公司都出现了消息积压的问题，这其实是很难避免的。
图Storm
这种将离线与实时分开的架构（Lambda 架构）选用批处理的技术处理全量数据，采用流式计算处理实时增量数据。
而同时支持流处理和批处理的计算引擎，有两种选择：一个是Apache Spark，一个是Apache Flink。
从技术，生态等各方面的综合考虑，首先，Spark的技术理念是基于批来模拟流的计算。而Flink则完全相反，它采用的是基于流计算来模拟批计算。
图spark
从技术发展方向看，用批来模拟流有一定的技术局限性，并且这个局限性可能很难突破。而Flink基于流来模拟批，在技术上有更好的扩展性。
Flink诞生于欧洲的一个大数据研究项目StratoSphere。该项目是柏林工业大学的一个研究性项目。早期，Flink是做Batch计算的，但是在2014年，StratoSphere里面的核心成员孵化出Flink，同年将Flink捐赠Apache，并在后来成为Apache的顶级大数据项目，同时Flink计算的主流方向被定位为Streaming，即用流式计算来做所有大数据的计算，这就是Flink技术诞生的背景。
2015开始阿里开始介入flink 负责对资源调度和流式sql的优化，成立了阿里内部版本blink在最近更新的1.9版本中,blink开始合并入flink,
未来flink也将支持java,scala,python等更多语言，并在机器学习领域施展拳脚。
