最近这段时间，大家可以看出来，我把大部分工作外时间的都花在了对Flink 使用上，目的就在于对比Spark和Flink基于同一个应用场景下的解决方案孰优孰劣。

虽然没有专门去做那种大规模、多场景的专业对比，但是也能多少说明一些问题。

选择对比的分别是Spark3.2.0 以及Flink 1.15.3，都是当前官方提供的稳定的、次新版本。

在对两者对比使用的过程中，全程参考双方的官方文档，每一行代码，每一项配置也都是根据功能需要进行添加，有兴趣的小伙伴可以参考我之前的3篇文章。

因为是第一次正儿八经使用Flink(之前生产一直用的Spark)，虽然花的时间不长，但是通过这些天的硬肝，基本上把Flink的功能了解了个80%左右，核心文档，各种API的玩法和应用场景，也都摸了个七七八八。

用最短的时间，去熟悉一个技术80%的功能，最高效最实用的方式就是：把它给跑起来。

通过这些天跟Flink的“亲密接触”，以及跟Spark的各种细节比对，再结合这些年对这么多开源组件的使用经验，对于这两者的选择问题，我的感悟和总结如下：

1. 官方文档很重要

关于这一点，我之前在视频中说过，对于任何一门新技术，尤其是这种顶级开源技术，最好的学习渠道，一定是去看官方文档。

你对这个技术的第一印象，它能提供的功能和能解决的问题，我相信，除了官方文档外，没有谁能够解释和定义的更加详细和精准了。

很多人会觉得官方文档看不懂，太难了，其实你难，对于其他人也一样难，只不过有的人不会因为暂时的难而放弃，你只要硬着头皮，坚持一个一段时间，我相信就能克服这种英文阅读的障碍。

而且，随着你读的次数越多，你会感觉越来越顺，甚至到达某个时间节点后，你会开始享受这种阅读感，不信，你坚持1个月试试。

在这次使用Flink的过程中，因为使用的版本比较新，我还专门留意了下对应版本的中文资料，有用的真是凤毛麟角，偶然有为数不多的看上去可以参考的资料，结果你一验证，完全驴唇不对马嘴。

这个时候就体现出官方文档的重要性，因为对于Flink来说，每个子版本的改动，其API的写法都有比较大的变化，你想顺利把新版本的代码给运行起来，也只能去参考官方文档。

很多人不喜欢看官方文档还有一个原因在于：它无法直接给你提供问题的解决方案。

因为它过于简洁，比如它在描述其API用法的时候，都是一个部分一个部分给拆的很碎去介绍的，但是很多人就受不了，他们喜欢文档能直接提供一套完整的解决方案代码，直接copy过来稍微改改就能用。

而看官方文档，想实现你的一个完整需求，比如从kafka读取数据源，然后通过watermark和windows API把数据处理结果写到Elasticsearch。

你如果想通过官方文档直接找到模板代码，那不好意思，一定没有，但是你却可以找到如何读取kafka的代码，以及如何使用 watermark 和windows功能的代码，最后找到数据如何写Elasticsearch的代码。

你只有在文档上分别找到上述的3种示例代码，然后经过逻辑思考给串联起来，才能形成你的解决方案，这个过程虽然比较曲折，但是在找答案的过程，也就是你在熟悉和学习这门技术的过程。

而这样的历经确是值得的，因为任何一门技术，如果你没有经历一番折腾，你是不可能对它影响深刻的。

2. 别看广告，看疗效

群里有很多小伙伴在谈及Flink的时候，总是喜欢以一种非常肯定的语气，说什么流式计算的王者、流批一体才是未来等等。

我想说：大哥，你才用它做过几个项目啊，自信成这样，你说这话的时候有考虑过Spark的感受吗。

知道什么叫广告吗？

我还清晰的记得几年前，一些类似的Apache开源项目也是打着碾压谁谁谁，性能超过谁谁谁多少倍的广告大肆宣传，各种原理剖析、性能测试文章铺天盖地。

结果呢？大部分直到现在还不是要死不活的。

这就好比市面上要推出一款新的商品，一开始别人都不认识你，你要想把它卖的好，手段之一就是拼命的打广告、宣传，多刷存在感，让别人知道你，然后才会有人购买，对不对。

但是如果是一款已经被市场验证过的，特别成熟的商品，你觉得它还会去花大精力打广告吗，不需要了嘛，因为没有必要啊。

这就好比现在那些天天打广告的那些车企，基本上都是些造车新势力，你看那些百年老店，真正的成熟品牌，反而不怎么打广告。

一个道理！

当一项技术在大肆宣传的时候，那就说明这项技术一定不成熟，或者不够成熟，它这么做的原因特别简单，就是让大家都去广泛使用，来给它试错，然后不断反映问题，提bug，给它提供优化、改进、升级的空间和动力。

所有开源社区不都是这么玩的吗？当年Spark的宣传攻势，我还历历在目。

但是作为技术使用者，作为企业，你要知道，你最关心的是什么？

是一味的追求技术的新潮，还是踏踏实实拿技术为实际业务服务，解决实际问题？

前者，有专门的、不差钱的公司和团队在做。

但是作为大部分的普通公司，用技术解决实际项目中数据问题的普通程序员，你觉得你的重心是什么？

难道不是在能够满足实际业务需要的情况下，追求更稳定、更实用、更高效的技术吗？

我相信这一点，对那些历经过多个项目，被各种因为脑子一热上新技术带来的坑，轮番毒打的老牌程序员来说，深以为然。

这里没有否定任何对新技术的追求，只是你要知道用新的东西会带来哪些可能的隐患和为之要付出的代价。

在项目的技术选型初期，一定要做好各种预判、调研，否则项目执行到一半，执行不下去了，最后只能推倒重来，坑了自己是小事，关键你把整个团队都给坑了，非常的不负责任。

3. Spark和Flink，选谁？

选谁都行，只要你能勇于为你的选择承担后续的责任。

通过我对Spark 6年的使用经验，以及最近3周对 Flink 还算是较为深度的体验，个人会认为，无论是在文档的友好程度，还是api的易用性上，Spark会更胜一筹。

毕竟，你大哥还是你大哥，Spark经过这么多年的升级和迭代，这两方面都已经非常成熟，也非常的贴合用户的使用习惯。

其次，在跟其他软件的兼容性上，虽然Flink独立了一个模块叫Flink CDC，但是Spark在这方面可丝毫都不弱，各种对主流技术组件的兼容早就炉火纯青。

再者，对于数据计算提供的各种算子API，SQL API，我在使用中没有感受到其功能的明显区别，但是在提交计算任务到集群运行时，明显感觉Spark跟Hadoop的兼容性会更好，Flink会出现些不大不小的bug，而Spark则没有。

最后，对于一些功能，Flink的代码明明根据官方文档来写的，但是却怎么着都运行不起来，出现一些莫名其妙的报错，当然，可能是我水平问题，但是我想如果我都不能把他们顺利的给跑起来，那一定有很多人也够呛。

而这一点，在Spark身上则没有出现过。

至于说实时性，我相信一定会有很多人拿这个说事，我希望那些说Spark实时性不如Flink的人，麻烦你们多看几眼官方文档，或者自己亲自做几个实验，别人家说什么你就信什么，相信自己实践出来的结论不香吗。

最后浅谈一下稳定性，在基于目前我测试的watermark和windows功能，流量在1w条数据/秒，跑了4天(截止到此刻为止)，除了中途Flink因为内存不足导致进程挂死1次(但是报错并没有显示OOM)，Spark和Flink都很稳定。

现阶段，如果是我，在生产上会依然会坚持用Spark，但是我会一直在测试环境关注Flink的动态，直到哪天我觉得它足够好了，才考虑把它派到“前线”。

最后

这篇文章没有否定任何新技术，更没有否定Flink，相反，我一直是个积极拥抱新技术的人。

我只是认为，作为技术人，在面对各种宣传和推广的时候，不要盲目跟风，要做到头脑清醒，有自己的思考和判断能力。

而这，也是我们面试选拔人才，最看重的能力之一。

以上，是我的一点思考，希望对你有用。

你也可以添加我的私人微信，拉你入技术讨论群，跟一群热爱技术的小伙伴一起成长...

Spark还是Flink？