大数据框架对比

一、流式计算对比

image.png

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/

流处理即未来

image.png

https://ververica.cn/developers/stream-processing-is-the-future/

二、github上社区活跃度对比

社区活跃度的对比不是为了追大流，只是因为咱们用的就是开源技术，如果采用技术群体的基数和活跃度不够大，那资料的查询和问题的解决会是一个头疼的问题，从技术普适性的角度来思考，也不是个好事情。

image

image.png

image.png

• Spark2.4.3以后的版本中的structured streaming可以达到毫秒级别延时的实时计算。
• Spark是以批处理起家，发展流处理，所以微批处理吞吐优先，可以选用。
• 实时处理后数据准备放在哪里?如果放在mysql，数十万tps实时插mysql，mysql也受不了
• spark streaming已然极其稳定了，flink的bug比较多。这个从github的提交删除也能看出来

三、对于实时计算，从延时和吞吐量方面来思考

备注：摘自宋博士给的论文，论文有点早，没有加入Spark Structured Streaming的考虑

延时对比：

image.png

吞吐量对比：

image.png

四、从统一解决方案的角度来考虑

Spark

Spark提供了统一的解决方案。Spark可以用于批处理、交互式查询（Spark SQL）、实时流处理（Spark Streaming）、机器学习（Spark MLlib）和图计算（GraphX）。

这些不同类型的处理都可以在同一个应用中无缝使用。这对于企业应用来说，就可使用一个平台来进行不同的工程实现，减少了人力开发和平台部署成本

image.png

引用自：https://zhuanlan.zhihu.com/p/70424613

Flink

image.png

在Flink 中，如果输入数据流是有边界的，就自然达到了批处理的效果。这样流和批的区别完全是逻辑上的，和处理实现独立，用户需要实现的逻辑也完全一样，应该是更干净的一种抽象。后续会在深入对比流计算方面的时候做更深入的讨论。

Flink 也提供了库来支持机器学习，图计算等场景。从这方面来说和 Spark 没有太大区别。

Spark 和 Flink 都瞄准了在一个执行引擎上同时支持大多数数据处理场景，也应该都能做到这一点。主要区别就在于因为架构本身的局限在一些场景会受到限制。比较突出的地方就是 Spark Streaming 的 micro batch 执行模式。Spark 社区应该也意识到了这一点，最近在持续执行模式（continuous processing）方面开始发力。

五、从结合业务的角度来考虑

咱们目前可以想到的后边可能会用到的大数据处理框架的地方：

• MRP/LRP计算
• 日志，异常信息，业务信息的实时处理
• 针对于单个租户、工厂的数据分析，订单量预测，针对于多个租户、工厂的分析，单量预测。
• 如果后期做MES，公有云MES上对接机器的数量，机器产生的实时数据，这个绝对是巨量数据，实时分析。
  咱们应该是既有bounded data，也同时有unbounded data需要处理，统一的处理框架很有必要

六、资料语言友好度方面

image.png

这个flink是完胜其他框架，毕竟是阿里推的框架，中文肯定是少不了的（不是完全中文）。

七、语言角度来考虑

Spark是用scala实现的，对于java程序员来说，如果需要深入了解底层的东西，scala肯定要学，就算不想深入了解，对于“喜欢用源码治病（源码治百病）”的同学来说也是一种痛苦。
Flink本身就是用java实现的，如果想要研究，对java程序员来说，无疑是非常方便的。
Spark和Storm的使用国内国外都有，Flink的使用主要集中在国内，不过，阿里的一顿猛推，Flink肯定在国内会有越来越多的受众。

image.png

image.png

image.png

image.png

八、从公司角度来思考

最好选用和公司未来一样的框架，这样会少不少麻烦事儿，但目前不清楚未来公司会用哪个。

image.png

打听了下，这哥们儿在招大数据工程师，招的方向是spark，但是感觉这个并没有代表性（不是集团管理或者架构部的），但也说不准。（公司如果别人都没用过，只有我们处理过，那大概率听我们的）

九、结合业务的一些“个人”思考

个人理解，其实大数据框架的出现，以及各种周围组件和中间件的出现，是为了解决以前没有办法处理的和解决的问题。比如，在大数据框架以及相关组件出现前，我要做大数据处理，但我的内存根本处理不了那么大的对象，处理完我也不好存放，存放完我也不好分析等等。
而对于我们的MRP/LRP运算来说，目前来看应该是放得下的，这可能也是为什么和大神聊天的时候，大神非常坚决的说“你们的业务不适合使用spark或者其他大数据框架来处理的原因”（个人推断）。这样说其实也是有道理的，毕竟，如果能通过单机上并行计算来解决，分布式计算的各种任务调度和分布式组件的管理，数据的shuffle等等，都是需要耗时的。单机的效率可能会更高。
但是，这个在没经过设计，以及实际论证的情况下真的不好说。

未知的世界总是充满否定和怀疑，踩过的路子总是充满匆匆的身影，仿佛那条路从一开始都是存在的。

image.png

image.png