一、流式计算对比
exactly once（精确一次的理解）->effectively once(有效一次)：https://ververica.cn/developers/exactly-once-2/
Flink和Spark的对比(廷珏给的链接)
https://ververica.cn/developers/big-data-computing-engine-battle/
https://ververica.cn/developers/competition-ecology-and-future/
流处理即未来
https://ververica.cn/developers/stream-processing-is-the-future/
二、github上社区活跃度对比
社区活跃度的对比不是为了追大流，只是因为咱们用的就是开源技术，如果采用技术群体的基数和活跃度不够大，那资料的查询和问题的解决会是一个头疼的问题，从技术普适性的角度来思考，也不是个好事情。
- Spark2.4.3以后的版本中的structured streaming可以达到毫秒级别延时的实时计算。
- Spark是以批处理起家，发展流处理，所以微批处理吞吐优先，可以选用。
- 实时处理后数据准备放在哪里?如果放在mysql，数十万tps实时插mysql，mysql也受不了
- spark streaming已然极其稳定了，flink的bug比较多。这个从github的提交删除也能看出来
三、对于实时计算，从延时和吞吐量方面来思考
备注：摘自宋博士给的论文，论文有点早，没有加入Spark Structured Streaming的考虑
延时对比：
吞吐量对比：
四、从统一解决方案的角度来考虑
Spark
Spark提供了统一的解决方案。Spark可以用于批处理、交互式查询（Spark SQL）、实时流处理（Spark Streaming）、机器学习（Spark MLlib）和图计算（GraphX）。
这些不同类型的处理都可以在同一个应用中无缝使用。这对于企业应用来说，就可使用一个平台来进行不同的工程实现，减少了人力开发和平台部署成本
引用自：https://zhuanlan.zhihu.com/p/70424613
Flink
在Flink 中，如果输入数据流是有边界的，就自然达到了批处理的效果。这样流和批的区别完全是逻辑上的，和处理实现独立，用户需要实现的逻辑也完全一样，应该是更干净的一种抽象。后续会在深入对比流计算方面的时候做更深入的讨论。
Flink 也提供了库来支持机器学习，图计算等场景。从这方面来说和 Spark 没有太大区别。
Spark 和 Flink 都瞄准了在一个执行引擎上同时支持大多数数据处理场景，也应该都能做到这一点。主要区别就在于因为架构本身的局限在一些场景会受到限制。比较突出的地方就是 Spark Streaming 的 micro batch 执行模式。Spark 社区应该也意识到了这一点，最近在持续执行模式（continuous processing）方面开始发力。
五、从结合业务的角度来考虑
咱们目前可以想到的后边可能会用到的大数据处理框架的地方：
- MRP/LRP计算
- 日志，异常信息，业务信息的实时处理
- 针对于单个租户、工厂的数据分析，订单量预测，针对于多个租户、工厂的分析，单量预测。
- 如果后期做MES，公有云MES上对接机器的数量，机器产生的实时数据，这个绝对是巨量数据，实时分析。
咱们应该是既有bounded data，也同时有unbounded data需要处理，统一的处理框架很有必要
六、资料语言友好度方面
这个flink是完胜其他框架，毕竟是阿里推的框架，中文肯定是少不了的（不是完全中文）。
七、语言角度来考虑
Spark是用scala实现的，对于java程序员来说，如果需要深入了解底层的东西，scala肯定要学，就算不想深入了解，对于“喜欢用源码治病（源码治百病）”的同学来说也是一种痛苦。
Flink本身就是用java实现的，如果想要研究，对java程序员来说，无疑是非常方便的。
Spark和Storm的使用国内国外都有，Flink的使用主要集中在国内，不过，阿里的一顿猛推，Flink肯定在国内会有越来越多的受众。
八、从公司角度来思考
最好选用和公司未来一样的框架，这样会少不少麻烦事儿，但目前不清楚未来公司会用哪个。
打听了下，这哥们儿在招大数据工程师，招的方向是spark，但是感觉这个并没有代表性（不是集团管理或者架构部的），但也说不准。（公司如果别人都没用过，只有我们处理过，那大概率听我们的）
九、结合业务的一些“个人”思考
个人理解，其实大数据框架的出现，以及各种周围组件和中间件的出现，是为了解决以前没有办法处理的和解决的问题。比如，在大数据框架以及相关组件出现前，我要做大数据处理，但我的内存根本处理不了那么大的对象，处理完我也不好存放，存放完我也不好分析等等。
而对于我们的MRP/LRP运算来说，目前来看应该是放得下的，这可能也是为什么和大神聊天的时候，大神非常坚决的说“你们的业务不适合使用spark或者其他大数据框架来处理的原因”（个人推断）。这样说其实也是有道理的，毕竟，如果能通过单机上并行计算来解决，分布式计算的各种任务调度和分布式组件的管理，数据的shuffle等等，都是需要耗时的。单机的效率可能会更高。
但是，这个在没经过设计，以及实际论证的情况下真的不好说。
未知的世界总是充满否定和怀疑，踩过的路子总是充满匆匆的身影，仿佛那条路从一开始都是存在的。
