又一个巨头决定彻底放弃Spark，全面转型 Flink！
马上618了，做大数据的同学又要忙起来了。
去年天猫618活动中Flink完美承载高达了50亿的峰值流量检验。数据量也达到了惊人的7TB每秒，相当于一秒钟需要读完500万本《新华字典》！Flink的强悍之处，阿里已屡试不爽！
阿里为何坚定不移地选择Flink？
大数据起源于批处理，在批处理上，Spark有很深的积累。为了应对全球大量业务的实时需求，Spark也推出了流计算解决方案——SparkStreaming。但Spark毕竟不是一款纯流式计算引擎，所以在时效性等问题上，始终无法提供极致的流批一体体验。[1]
而后起新秀Flink的基本数据模型则是数据流，以及事件(Event)的序列。数据流作为数据的基本模型，可以是无边界的无限“流”，即一般意义上的流处理；也可以是有边界的有限“流”，也就同时兼顾了批处理。
在AI前线的采访中：先在很多人提到实时流计算引擎，都会拿 Spark 和 Flink 来做对比，您怎么看待下一代实时流计算引擎之争？未来实时流计算引擎最重要的发展方向是什么？[2]
阿里搜索事业部资深搜索专家蒋晓伟回答到：
蒋晓伟：Spark 和 Flink 一开始 share 了同一个梦想，他们都希望能够用同一个技术把流处理和批处理统一起来，但他们走了完全不一样的两条路，前者是用以批处理的技术为根本，并尝试在批处理之上支持流计算；后者则认为流计算技术是最基本的，在流计算的基础之上支持批处理。正因为这种架构上的不同，今后二者在能做的事情上会有一些细微的区别。比如在低延迟场景，Spark 基于微批处理的方式需要同步会有额外开销，因此无法在延迟上做到极致。在大数据处理的低延迟场景，Flink 已经有非常大的优势。经过我们的探索，Flink 在批处理上也有了比较大的突破，这些突破都会反馈回社区。当然，对于用户来说，多一个选择永远是好的，不同的技术可能带来不同的优势，用户可以根据自己业务场景的需求进行选择。
未来，在大数据方向，机器学习正在逐渐从批处理、离线学习向实时处理、在线学习发展，而图计算领域同样的事情也在发生，比如实时反欺诈通常用图计算来做，而这些欺诈事件都是实时地、持续不断地发生，图计算也在变得实时化。
但是 Flink 除了大数据领域以外，在应用和微服务的场景也有其独特的优势。应用和微服务场景对延迟的要求非常苛刻，会达到百毫秒甚至十毫秒级别，这样的延迟只有 Flink 的架构才能做到。我认为应用和微服务其实是非常大的领域，甚至可能比大数据更大，这是非常激动人心的机会。上面这些都是我们希望能够拓宽的应用领域。
同时，Flink相比于Spark而言还有诸多明显优势：
支持高效容错的状态管理，保证在任何时间都能计算出正确的结果； 同时支持高吞吐、低延迟、高性能的分布式流式数据处理框架； 支持事件时间（Event Time）概念，事件即使无序到达甚至延迟到达，数据流都能够计算出精确的结果； 轻量级分布式快照（Snapshot）实现的容错，能将计算过程分布到单台并行节点上进行处理。
阿里早在几年前就开始探索 Flink 的实战应用，随着双 11 阿里基于Flink实时计算场景的屡战屡胜，毋庸置疑，Flink 将会加速成为大厂主流的数据处理框架，最终化身下一代大数据处理标准。
最近正好我收到了一本清华大学出版社赠送的新书《Flink大数据分析实战》，由资深大数据专家精心编写，循序渐进地介绍了Flink生态系统主流的大数据开发技术。
全书共7章，第1章讲解Flink的基础知识，包括Flink应用场景、主要组件、编程模型等，后通过一个单词计数示例带领读者快速体验Flink应用程序的编写；第2、3章讲解Flink的多种运行时架构、任务调度原理、数据分区以及Flink集群的安装部署，同时包括Flink命令行操作、应用程序提交、常用Shell命令等；
第4～7章讲解了Flink流式计算DataStream API、关系型计算Table&SQL API以及图计算框架Gelly等的基础知识、架构原理，同时包括常用Shell命令、API操作、内核源码剖析，并通过多个实际案例讲解各个框架的具体应用以及与Hadoop生态系统框架Hive、Kafka的整合操作。
如果大家对大数据分析感兴趣，不妨了解一下Flink。
参考资料
基于 Flink 构建全场景多维度实时计算数仓: https://blog.csdn.net/wypblog/article/details/121368992
[2]阿里重磅开源Blink：为什么我们等了这么久？: https://www.dandelioncloud.cn/article/details/1498973498038099970
推荐阅读
点击这里，阅读更多数据文章！