查看kafka中未消费数据_Spark Streaming消费Kafka数据的两种方案

下午的时候翻微信看到大家在讨论Spark消费Kafka的方式，官网中就有答案，只不过是英文的，当然很多博客也都做了介绍，正好我的收藏夹中有一篇文章供大家参考。文章写的通俗易懂，搭配代码，供大家参考。

本文的作者是来自TalkingData的数据工程师张伟。

SS 是 Spark 上的一个流式处理框架，可以面向海量数据实现高吞吐量、高容错的实时计算。SS 支持多种类型数据源，包括 Kafka、Flume、twitter、zeroMQ、Kinesis 以及 TCP sockets 等。SS 实时接收数据流，并按照一定的时间间隔(下文称为“批处理时间间隔”)将连续的数据流拆分成一批批离散的数据集；然后应用诸如 map、reduce、join 和 window 等丰富的 API 进行复杂的数据处理；最后提交给 Spark 引擎进行运算，得到批量结果数据，因此其也被称为准实时处理系统。而结果也能保存在很多地方，如 HDFS，数据库等。另外 SS 也能和 MLlib(机器学习)以及 GraphX(图计算)完美融合。

Spark Streaming 支持多种类型数据源

Spark Streaming 基础概念

DStream

Discretized Stream 是 SS 的基础抽象，代表持续性的数据流和经过各种 Spark 原语操作后的结果数据流。DStream 本质上是一个以时间为键，RDD 为值的哈希表，保存了按时间顺序产生的 RDD，而每个 RDD 封装了批处理时间间隔内获取到的数据。SS 每次将新产生的 RDD 添加到哈希表中，而对于已经不再需要的 RDD 则会从这个哈希表中删除，所以 DStream 也可以简单地理解为以时间为键的 RDD 的动态序列。如下图：

窗口时间间隔

窗口时间间隔又称为窗口长度，它是一个抽象的时间概念，决定了 SS 对 RDD 序列进行处理的范围与粒度，即用户可以通过设置窗口长度来对一定时间范围内的数据进行统计和分析。假如设置批处理时间间隔为 1s，窗口时间间隔为 3s。如下图，DStream 每 1s 会产生一个 RDD，红色边框的矩形框就表示窗口时间间隔，一个窗口时间间隔内最多有 3 个 RDD，Spark Streaming 在一个窗口时间间隔内最多会对 3 个 RDD 中的数据进行统计和分析。

滑动时间间隔

滑动时间间隔决定了 SS 程序对数据进行统计和分析的频率。它指的是经过多长时间窗口滑动一次形成新的窗口，滑动时间间隔默认情况下和批处理时间间隔相同，而窗口时间间隔一般设置的要比它们两个大。在这里必须注意的一点是滑动时间间隔和窗口时间间隔的大小一定得设置为批处理时间间隔的整数倍。

如下图，批处理时间间隔是 1 个时间单位，窗口时间间隔是 3 个时间单位，滑动时间间隔是 2 个时间单位。对于初始的窗口 time 1-time 3，只有窗口时间间隔满足了才触发数据的处理。这里需要注意的一点是，初始的窗口有可能覆盖的数据没有 3 个时间单位，但是随着时间的推进，窗口最终会覆盖到 3 个时间单位的数据。当每个 2 个时间单位，窗口滑动一次后，会有新的数据流入窗口，这时窗口会移去最早的两个时间单位的数据，而与最新的两个时间单位的数据进行汇总形成新的窗口(time3-time5)。

Spark Streaming 读取 Kafka 数据

Spark Streaming 与 Kafka 集成接收数据的方式有两种：

• Receiver-based Approach

• Direct Approach (No Receivers)

Receiver-based Approach

这个方法使用了 Receivers 来接收数据。Receivers 的实现使用到 Kafka 高级消费者 API。对于所有的 Receivers，接收到的数据将会保存在 Spark executors 中，然后由 SS 启动的 Job 来处理这些数据。

然而，在默认的配置下，这种方法在失败的情况下会丢失数据，为了保证零数据丢失，你可以在 SS 中使用 WAL 日志，这是在 Spark 1.2.0 才引入的功能，这使得我们可以将接收到的数据保存到 WAL 中(WAL 日志可以存储在 HDFS 上)，所以在失败的时候，我们可以从 WAL 中恢复，而不至于丢失数据。

架构图如下：