共计 2350 个字符，预计需要花费 6 分钟才能阅读完成。
这篇文章主要介绍“如何解密 Spark Streaming”，在日常操作中，相信很多人在如何解密 Spark Streaming 问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”如何解密 Spark Streaming”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
1，解密 Spark Streaming Job 架构和运行机制
先通过运行在线单词统计这个例子，观察 Spark Streaming 在控制台上输出的日志信息。
以下代码为在 9999 端口监听客户端连接请求，然后不断向客户端发送单词。
先启动 SocketServer，然后在启动 SparkStreaming 在线统计单词的程序，代码如下
运行过程总结如下
1，StreamingContext 启动后会 ReceiverTracker，根据创建时指定的 batchDuration 时间，启动 RecurringTimer 定时器，间隔 Interval 发送 JobGenerator 消息，会启动 JobGenerator 和 JobScheduler 和 BlockGenerator。
2，ReceiverTracker 接收到 Receiver(Stream 0) 的注册消息，然后 RecevierSupervisorImpl 启动 Receiver 来接收数据。
3，SocketServer 连接到 localhost:9999 开始接收数据，将接收到的数据通过 BlockGenerator 存放到 BlockManager 中。
4，JobScheduler 接收到定期发送的 JobGenerator 消息后，提交一个 Job，DStreamGraph 从 ReceiverTracker 中获取数据生成 RDD，DAGScheduler 调度 Job 的执行，让 TaskSchedulerImpl 向 Executor 发送 TaskSet，让 Executor 执行。
5，Task 运行完后将结果发送给 Driver，DAGScheduler 和 JbScheduler 打印 Job 完成和耗时信息，最后在控制台输出单词统计结果。
可以看到随着时间的流逝会有不断的 Job 生成并且运行，那么，Spark Streaming 中 Job 是如何生成的？
在 StreamingContext 调用 start 方法的内部其实是会启动 JobScheduler 的 start 方法，进行消息循环，在 JobScheduler 的 start 内部会构造 JobGenerator 和 ReceiverTracker，并且调用 JobGenerator 和 ReceiverTracker 的 start 方法
1，JobGenerator 启动后不断的根据 batchDuration 生成一个个的 Job
2，ReceiverTracker 启动后首先在 Spark 集群中启动 Receiver(其实在 Executor 中先启动 ReceiverSupervisor) 在 Receiver 接收到数据后会通过 ReceiverSupervisor 将数据存储到 Executor 的 BlockManager 中，并且把数据的 Metadata 信息发送给 Driver 的 ReceiverTracker，在 ReceiverTracker 内部通过 ReceivedBlockTracker 来管理接收到的元数据信息
每个 BatchInterval 会产生一个具体的 Job，其实这里的 Job 不是 SparkCore 中的 Job，它只是基于 DStreamGraph 而生成的 RDD 的 DAG 而已，从 Java 角度讲，相等于 Runnable 接口实例，此时要向运行 Job 需要提交给 JobScheduler，在 JobScheduler 中通过线程池中单独的线程
来提交 Job 到集群运行 (其实是在线程中基于 RDD 的 Action 触发真正的作业的运行)
为什么使用线程池？
1，作业不断生成，所以为了提升效率，我们需要线程池。这和 Executor 中通过线程池执行 Task 有异曲同工之妙
2，有可能设置了 Job 的 FAIR 公平调度的方式，这个时候也需要多线程的支持
2，解密 Spark Streaming 容错架构和运行机制
容错分为 Driver 级别的容错和 Executor 级别的容错。
在 Executor 级别的容错具体为接收数据的安全性和任务执行的安全性。在接收数据安全性方面，一种方式是 Spark Streaming 接收到数据默认为 MEMORY_AND_DISK_2 的方式，在两台机器的内存中，如果一台机器上的 Executor 挂了，立即切换到另一台机器上的 Executor，这种方式一般情况下非常可靠且没有切换时间。另外一种方式是 WAL（Write Ahead Log），在数据到来时先通过 WAL 机制将数据进行日志记录，如果有问题则从日志记录中恢复，然后再把数据存到 Executor 中，再进行其他副本的复制，这种方式对性能有影响。在生产环境中一般使用 Kafka 存储，Spark Streaming 接收到数据丢失时可以从 Kafka 中回放。在任务执行的安全性方面，靠 RDD 的容错。
在 Driver 级别的容错具体为 DAG 生成的模板，即 DStreamGraph，RecevierTracker 中存储的元数据信息和 JobScheduler 中存储的 Job 进行的进度情况等信息，只要通过 checkpoint 就可以了，每个 Job 生成之前进行 checkpoint，在 Job 生成之后再进行 checkpoint，如果出错的话就从 checkpoint 中恢复。
到此，关于“如何解密 Spark Streaming”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
