大数据流式计算

目录

流式计算简介

流式计算

常⻅的离线和流式计算框架

Storm V.S. SparkStreaming V.S. Flink

 如何选择⼀款合适的流式处理框架

---

流式计算简介

流式计算

        如何去理解流式计算，最形象的例⼦，就是⼩明的往⽔池中放( ⼊ ) ⽔⼜放 ( 出 ) ⽔的案例。流式计算就像⽔流⼀样，数据连绵不断的产⽣，并被快速处理，所以流式计算拥有如下⼀些特点：

• 数据是⽆界的(unbounded)
• 数据是动态的
• 计算速度是⾮常快的
• 计算不⽌⼀次
• 计算不能终⽌

反过来看看⼀下离线计算有哪些特点：

• 数据是有界的(Bounded)
• 数据静态的
• 计算速度通常较慢
• 计算只执⾏⼀次
• 计算终会终⽌

        在⼤数据计算领域中，通常所说的流式计算分为了实时计算和 准实时计算 。所谓事实计算就是来⼀条记录 ( ⼀个事件Event)启动⼀次计算；⽽准实时计算则是介于实时计算和离线计算之间的⼀个计算，所以每次处理的是⼀个微⼩的批次。

常⻅的离线和流式计算框架

• 常⻅的离线计算框架

1.  mapreduce
2.  spark-core
3.  flink-dataset

• 常⻅的流式计算框架

1.  storm(jstorm)
       第⼀代的流式处理框架，每⽣成⼀条记录，提交⼀次作业。实时流处理，延迟低。
2.  spark-streaming
    ​​​​​​   第⼆代的流式处理框架，短时间内⽣成mirco-batch，提交⼀次作业。准实时，延迟略⾼，秒级或者亚秒级延迟。
3.  flink-datastream(blink)
       第三代的流式处理框架，每⽣成⼀条记录，提交⼀次作业。实时，延迟低。

Storm V.S. SparkStreaming V.S. Flink

 如何选择⼀款合适的流式处理框架

•  对于Storm来说：

1.       建议在需要纯实时，不能忍受1秒以上延迟的场景下使⽤，⽐如实时计算系统，要求纯实时进⾏交易和分 析时。
2.         在实时计算的功能中，要求可靠的事务机制和可靠性机制，即数据的处理完全精准，⼀条也不能多，⼀条也不能少，也可以考虑使⽤Storm，但是Spark Streaming也可以保证数据的不丢失。
3.         如果我们需要考虑针对⾼峰低峰时间段，动态调整实时计算程序的并⾏度，以最⼤限度利⽤集群资源（通常是在⼩型公司，集群资源紧张的情况），我们也可以考虑⽤Storm

• 对于Spark Streaming来说：

1.         不满⾜上述3点要求的话，我们可以考虑使⽤Spark Streaming来进⾏实时计算。
2.         考虑使⽤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 、排序等昂贵操作，中间结果有必要进⾏缓存