共计 1798 个字符，预计需要花费 5 分钟才能阅读完成。
这篇文章主要讲解了“Spark Streaming 的案例分析”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“Spark Streaming 的案例分析”吧！
为什么从 SparkStreaming 入手？
因为 SparkStreaming 是 Spark Core 上的一个子框架，如果我们能够完全精通了一个子框架，我们就能够更好的驾驭 Spark。SparkStreaming 和 Spark SQL 是目前最流行的框架，从研究角度而言，Spark SQL 有太多涉及到 SQL 优化的问题，不太适应用来深入研究。而 SparkStreaming 和其他的框架不同，它更像是 SparkCore 的一个应用程序。如果我们能深入的了解 SparkStreaming，那我们就可以写出非常复杂的应用程序。
SparkStreaming 的优势是可以结合 SparkSQL、图计算、机器学习，功能更加强大。这个时代，单纯的流计算已经无法满足客户的需求啦。在 Spark 中 SparkStreaming 也是最容易出现问题的，因为它是不断的运行，内部比较复杂。
本课内容：
1，SparkStreaming 另类在线实验
这个另类在线实验体现在 batchInterval 设置的很大，5 分钟甚至更大，为了更清晰的看清楚 Streaming 运行的各个环境。
实验内容是使用 SparkStreaming 在线统计单词个数，SparkStreaming 连接一个端口中接收发送过来的单词数据，将统计信息输出到控制台中，其中使用 netcat 创建一个简单的 server，来开启并监听一个端口，接收用户键盘输入的单词数据。
2，瞬间理解 SparkStreaming 的本质
结合这个实验并通过观察 Web UI 上的 Job，Stage，Task 等信息，再结合 SparkStreaming 的源码，对 SparkStreaming 进行分析。
实验环境说明：
实验由 3 台 Ubuntu14.04 虚拟机上运行，其中一台作为 Spark 的 Master，另外两台作为 Spark 的 Worker。使用的 Spark 版本为目前最先版 1.6.1，Spark checkpoint 的存储在 HDFS 上 (hadoop 的版本为 2.6.0)。为了记录 SparkStreaming 运行的过程信息，需要启动 Spark 的 HistoryServer，以下是启厅 Spark，HDFS，HistoryServer 服务的脚本。
实验代码如下
提交到 Spark 集群的脚本如下
首先在 Master 节点使用 nc -lk 9999，创建一个简单的 Server，然后在运行脚本提交 Spark Application。
从网上找来一篇英文文章，如下
单词统计结果如下
在 Spark UI 上观察发现有 4 个 Job
首先查看 Job 0 发现 SparkStreaming 在刚启动时会提交一个 Job
StreamingContext 的 start 方法中调用了 JobScheduler 的 start 方法
继续看 JobScheduler 类的 start 方法
从注释中说明该方法是为了确保每个 Slave 都注册上，避免所有的 Receiver 在同一个节点，为了后面计算负载均衡。
Job1 一直在运行是因为它不断接收数据流中的数据，运行在 Worker1 上并且运行 1 个 Task 来接收数据，数据本地性为 PROCESS_LOCAL，receiver 接收到数据会保存到内存中。
Job2 的信息如下
其中 Stage3 信息如下
其中 Stage4 信息如下
Job3 的信息如下，Job3 的 DAG 图和 Job2 的 DAG 图是一样的，但是 Stage5 跳过了。
后面的 Job 都是在对单词切分统计。
回顾这 4 个 Job，其中 2 个 Job 是框架运行的，Job0 确保所有 slave 都注册上，避免所有的 Receiver 在同一个节点，为了后面计算负载均衡。Job1 为启动一个数据接收器，运行在一个 Executor 上的一个 Task 上，不断接收数据量数据，然后保存到内存中。Job2 和 Job3 在运行单词切分统计。
感谢各位的阅读，以上就是“Spark Streaming 的案例分析”的内容了，经过本文的学习后，相信大家对 Spark Streaming 的案例分析这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！
