![大数据流式计算](https://100zi.50zi.cn/uploadfile/img/15/562/9c2934c2184433af95cd97513e0323fc.jpg)
目录
流式计算简介
流式计算
常⻅的离线和流式计算框架
Storm V.S. SparkStreaming V.S. Flink
如何选择⼀款合适的流式处理框架
流式计算简介
流式计算
如何去理解流式计算,最形象的例⼦,就是⼩明的往⽔池中放(⼊)⽔⼜放(出)⽔的案例。流式计算就像⽔流⼀样,数据连绵不断的产⽣,并被快速处理,所以流式计算拥有如下⼀些特点: 数据是⽆界的(unbounded) 数据是动态的 计算速度是⾮常快的 计算不⽌⼀次 计算不能终⽌反过来看看⼀下离线计算有哪些特点: 数据是有界的(Bounded) 数据静态的 计算速度通常较慢 计算只执⾏⼀次 计算终会终⽌在⼤数据计算领域中,通常所说的流式计算分为了实时计算和准实时计算。所谓事实计算就是来⼀条记录(⼀个事件Event)启动⼀次计算;⽽准实时计算则是介于实时计算和离线计算之间的⼀个计算,所以每次处理的是⼀个微⼩的批次。
常⻅的离线和流式计算框架
常⻅的离线计算框架mapreduce spark-core flink-dataset常⻅的流式计算框架storm(jstorm)
第⼀代的流式处理框架,每⽣成⼀条记录,提交⼀次作业。实时流处理,延迟低。spark-streaming
第⼆代的流式处理框架,短时间内⽣成mirco-batch,提交⼀次作业。准实时,延迟略⾼,秒级或者亚秒级延迟。flink-datastream(blink)
第三代的流式处理框架,每⽣成⼀条记录,提交⼀次作业。实时,延迟低。
Storm V.S. SparkStreaming V.S. Flink
如何选择⼀款合适的流式处理框架
对于Storm来说:建议在需要纯实时,不能忍受1秒以上延迟的场景下使⽤,⽐如实时计算系统,要求纯实时进⾏交易和分 析时。 在实时计算的功能中,要求可靠的事务机制和可靠性机制,即数据的处理完全精准,⼀条也不能多,⼀条也不能少,也可以考虑使⽤Storm,但是Spark Streaming也可以保证数据的不丢失。 如果我们需要考虑针对⾼峰低峰时间段,动态调整实时计算程序的并⾏度,以最⼤限度利⽤集群资源(通常是在⼩型公司,集群资源紧张的情况),我们也可以考虑⽤Storm对于Spark Streaming来说:不满⾜上述3点要求的话,我们可以考虑使⽤Spark Streaming来进⾏实时计算。考虑使⽤Spark Streaming最主要的⼀个因素,应该是针对整个项⽬进⾏宏观的考虑,即,如果⼀个项⽬除了实时计算之外,还包括了离线批处理、交互式查询、图计算和MLIB机器学习等业务功能,⽽且实时计算中,可能还会牵扯到⾼延迟批处理、交互式查询等功能,那么就应该⾸选Spark⽣态,⽤Spark Core开发离线批处理,⽤Spark SQL开发交互式查询,⽤Spark Streaming开发实时计算,三者可以⽆缝整合,给系统提供⾮常⾼的可扩展性。对于Flink来说:⽀持⾼吞吐、低延迟、⾼性能的流处理 ⽀持带有事件时间的窗⼝(Window)操作 ⽀持有状态计算的Exactly-once语义 ⽀持⾼度灵活的窗⼝(Window)操作,⽀持基于time、count、session,以及data-driven的窗⼝操作 ⽀持具有Backpressure功能的持续流模型 ⽀持基于轻量级分布式快照(Snapshot)实现的容错 ⼀个运⾏时同时⽀持Batch on Streaming处理和Streaming处理 Flink在JVM内部实现了⾃⼰的内存管理 ⽀持迭代计算 ⽀持程序⾃动优化:避免特定情况下Shuffle、排序等昂贵操作,中间结果有必要进⾏缓存