当前位置:   article > 正文

大数据之Spark(九):Spark Streaming 概述

spark streaming

一、流式计算简介

1.1 流式计算

        理解流式计算,最形象的例子,就是小明的往水池中放(入)水又放(出)水的案例。流式计算就像水流⼀样, 数据连绵不断的产生,并被快速处理,所以流式计算拥有如下⼀些特点:

  • 数据是无界的(unbounded)
  • 数据是动态的
  • 计算速度是非常快的
  • 计算不止一次
  • 计算不能终⽌
  • 反过来看看⼀下离线计算有哪些特点:
  • 数据是有界的(Bounded)
  • 数据静态的
  • 计算速度通常较慢
  • 计算只执行一次
  • 计算终会终止

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

1.2 常见的离线和流式计算框架

常见的离线计算框架

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

常见的流式计算框架

1. storm(jstorm)

第⼀代的流式处理框架,每⽣成⼀条记录,提交⼀次作业。实时流处理,延迟低。

2. spark-streaming

第⼆代的流式处理框架,短时间内⽣成mirco-batch,提交⼀次作业。准实时,延迟略⾼,秒级或者亚秒级延迟。

3. flink-datastream(blink)

第三代的流式处理框架,每⽣成⼀条记录,提交⼀次作业。实时,延迟低。

1.3 SparkStreaming简介

SparkStreaming,和SparkSQL⼀样,也是Spark生态栈中非常重要的一个模块,主要是用来进行流式计算的框架。流式计算框架,从计算的延迟上面,又可以分为纯实时流式计算和准实时流式计算,SparkStreaming属于准实时计算框架

所谓纯实时的计算,指的是来⼀条记录(event事件),启动⼀次计算的作业;离线计算,指的是每次计算⼀个非常大的⼀批(比如几百G,好几个T)数据;准实时计算,介于纯实时和离线计算之间的⼀种计算⽅式。显然不是每⼀条记录就计算⼀次,显然比起离线计算数据量小的多,使用Micro-batch(微小的批次)来表示。

SparkStreaming是SparkCore的api的⼀种扩展,使用DStream(discretized stream or DStream)作为数据模型, 基于内存处理连续的数据流,本质上还是RDD的基于内存的计算。

DStream,本质上是RDD的序列。SparkStreaming的处理流程可以归纳为下图:

 1.4 SparkStreaming基本工作原理

接收实时输入数据流,然后将数据拆分成多个batch,⽐如每收集1秒的数据封装为⼀个batch,然后将每个batch交给Spark的计算引擎进⾏处理,最后会⽣产出⼀个结果数据流,其中的数据,也是由⼀个⼀个的batch所组成的。

Spark Streaming提供了⼀种⾼级的抽象,叫做DStream,英⽂全称为Discretized Stream,中⽂翻译为“离散 流”,它代表了⼀个持续不断的数据流。DStream可以通过输⼊数据源来创建,⽐如Kafka、Flume、ZMQ和 Kinesis;也可以通过对其他DStream应⽤⾼阶函数来创建,⽐如map、reduce、join、window。

DStream的内部,其实⼀系列持续不断产⽣的RDD。RDD是Spark Core的核心抽象,即分布式弹性数据集。DStream中的每个RDD都包含了⼀个时间段内的数据。

对DStream应⽤的算⼦,⽐如map,其实在底层会被翻译为对DStream中每个RDD的操作。⽐如对⼀个 DStream执⾏⼀个map操作,会产⽣⼀个新的DStream。但是,在底层,其实其原理为,对输⼊DStream中每个 时间段的RDD,都应⽤⼀遍map操作,然后⽣成的新的RDD,即作为新的DStream中的那个时间段的⼀个RDD。 底层的RDD的transformation操作。

还是由Spark Core的计算引擎来实现的。Spark Streaming对Spark Core进⾏了⼀层封装,隐藏了细节,然后对 开发⼈员提供了⽅便易⽤的⾼层次的API。

 1.5 Storm V.S. SparkStreaming V.S. Flink

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

  • 对于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、排序等昂贵操作,中间结果有必要进⾏缓存

 二、SparkStreaming实时处理入门

 2.1 工程创建

 导入Maven依赖

  1. <dependency>
  2. <groupId>org.apache.spark</groupId>
  3. <artifactId>spark-streaming_2.11</artifactId>
  4. <version>2.2.2</version>
  5. </dependency>
  6. <dependency>
  7. <groupId>org.apache.spark</groupId>
  8. <artifactId>spark-streaming-kafka-0-10_2.11</artifactId>
  9. <
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/一键难忘520/article/detail/1007073
推荐阅读
相关标签
  

闽ICP备14008679号