Flink及Storm、Spark主流流框架比较-实时框架比较

实时计算框架对比 - flink，storm，spark 三者的区别

我相信有不少的工程师都有着这样的处境，在学flink之前很好奇flink，storm，spark的区别是什么，为什么现在很多企业都在往flink方向转它的优势是什么，为什么不适用storm，为什么不适用spark，在下面的内容中我会为大家解答。希望可以帮助大家，也希望大家看了之后可以提出自己宝贵建议。

有限数据集和无限数据集

1.有限数据集：数据大小有限（固定大小，比如固定的文件），用于批处理，这一类数据主要用于mr，hive，pig，spark等批计算引擎。

2.无限数据集：数据持续增长（属于无限大小，比如kafka中的日志数据，总是有新数据进入，并且不知道什么时候结束或者是永远不结束），用于流式处理，这一类数据主要用于storm，spark streaming，flink等一些流式计算引擎。

apache计算引擎的发展关系

在apche中的三篇论文鉴定大数据的基础其中mr收到其中一篇论文的启发创造了mapreduce，同时随着时代的发展也出现了其他的技术技术。

1.第一代计算引擎 mapreduce

mapreduce 作为第一个计算引擎，用于批处理，是计算引擎的先驱，内部支持机器学习但是现在机器学习库不在更新，并且mapreduce 编写十分的耗时，开发效率低，开发时间成本太大，所以很少有企业写mapreduce 来跑程序。

2.第二代计算引擎 pig/hive

作为第二代引擎pig/hive 对hadoop（如果不知道hadoop的话，建议不要看了。。。。。）进行了嵌套，其存储基于hdfs，计算基于mr，hive/pig在处理任务时首先会把本身的代码解析为一个个m/r任务，这样就大大的降低了mr的编写编写成本。

pig 有自己的脚本语言属于，比hive更加的灵活

hive 属于类sql语法，虽然没有pig灵活，但是对于现在程序员都会sql的世界来说大家更喜欢使用hive

pig/hive 只支持批处理，且支持机器学习（hivemall）

3.第三代计算引擎 spark/storm

随着时代的发展，企业对数据实时处理的需求愈来愈大，所以就出现了storm/spark

这两者有着自己的计算模式

storm属于真正的流式处理，低延迟（ms级延迟），高吞吐，且每条数据都会触发计算。

spark属于批处理转化为流处理即将流式数据根据时间切分成小批次进行计算，对比与storm而言延迟会高于0.5s（s级延迟），但是性能上的消耗低于storm。“流式计算是批次计算的特例（流式计算是拆分计算的结果）”

4.第四代计算引擎 flink

flink2015年出现在apache，后来又被阿里巴巴技术团队进行优化（这里我身为国人为之自豪）为blink，flink支持流式计算也支持的批次处理。

flink为流式计算而生属于每一条数据触发计算，在性能的消耗低于storm，吞吐量高于storm，延时低于storm，并且比storm更加易于编写。因为storm如果要实现窗口需要自己编写逻辑，但是flink中有窗口方法。

flink内部支持多种函数，其中包括窗口函数和各种算子（这一点和spark很像，但是在性能和实时上spark是没有办法比较的）

flink支持仅一次语义保证数据不丢失

flink支持通过envent time来控制窗口时间，支持乱序时间和时间处理（这点我觉得很厉害）

对于批次处理flink的批处理可以理解为 “批次处理是流式处理的特例”（批次计算是流式计算的合并结果）

区别对比（总结）

这里用一张图来做第一点的简介

这里用一张图来做第一点的对比

相比于storm ，spark和flink两个都支持窗口和算子，减少了不少的编程时间

flink相比于storm和spark，flink支持乱序和延迟时间（在实际场景中，这个功能很牛逼），个人觉得就这个功能就可以锤爆spark

对于spark而言他的优势就是机器学习，如果我们的场景中对实时要求不高可以考虑spark，但是如果是要求很高就考虑使用flink，比如对用户异常消费进行监控，如果这个场景使用spark的话那么等到系统发现开始预警的时候（0.5s），罪犯已经完成了交易，可想而知在某些场景下flink的实时有多重要。