这是我参与「第四届青训营 」笔记创作活动的第1天
首先是使用Flink的必要性，从某种意义上来说实时流处理可以算作是极致的定时任务，并且做了时间上的优化，从而尽快得到时间线上的相关数据。
正因为这个角度的观点，另外两种计算：批处理和交互式查询可以和他算作相同的任务。批处理好处在于确定性，知道自己要处理什么，也不太需要时间约束，只是这也并非强制要求，待处理数据集的不确定性并不重要；交互式查询注重操作的实时性，不过一旦做了查询的操作，时间要求其实操作人员心里应该有底，清楚一番操作到底是接近批处理，还是流处理；于是三者存在由同一种工具或者说框架完成的可能。
目前来看，担当这个重任的就是 Flink。 其他的无论是Hadoop捆绑的Map Reduce 计算框架，抑或是大名鼎鼎的 Spark 框架，都没有Flink 这样被广泛的认可。尽管 Spark 推出了 spark structed streaming 这个更强的计算框架，但是由于 Flink 毕竟更早在这几个领域获得了广泛的认可，在马太效应的加持之下， structed streaming 到底是没什么起色。
Flink 能够取得这样的成果，最重要的一点莫过于它实现了所谓的“流批一体”，让流计算和批处理有一样的操作方式，或者说实现了无界数据流和有界数据流的统一, 这给编写、调试、学习等等各方面提供的极大的便利性，减轻了相关人员的各种心智负担。还有一点则是提供了SQL接口，虽然说现在这是大部分计算框架都会提供的，但是它仍然很值得一提，因为首先它给不熟悉编程语言的人员提供了SQL这种经过了广泛验证的数据操作描述语言，降低了技术门槛；其次由于 SQL 广泛的使用，业界研究有相当多的优化措施，这又是锦上添花之举。
