SparkStreaming的实战案例

废话不多说，直接上干货！！！
相关依赖：编程架构：

在某个节点上中启动nc -lk 9999，然后用作数据源。编写程序实现网络的wordcount。
代码实现：使用nc -lk 9999在相应的节点上发出消息（每隔一个批处理时间发送一次），查看控制台打印：
batch2

batch3

结果发现：由于现在的操作时无状态的，所以每隔2s处理一次，但是每次的单词数不会统计，也就是说，只会统计当前批处理的单词，之前输入的则不会统计。同样是wordCounte，这次要实现的效果是：到现在为止，统计过去时间段内的所有单词的个数。
代码：使用 nc -kl 9999：

观察控制台：
batch2

batch3

发现：两次批处理的结果，进行了聚合，也就是所谓的有状态的计算。
注意：
ssc.checkpoint("C:z_datacheckPointcheckPoint_1")
上面这句代码一定要加，他会将上一次的批处理计算的结果保存起来，如果不加：
错误：requirement failed: The checkpoint directory has not been set. Please set it by StreamingContext.checkpoint().   在上述的updateStateByKey代码中如果当前程序运行异常时，会丢失数据（重启之后，找不回原来计算的数据），因为编程入口StreamingContext在代码重新运行的时候，是重新生成的，为了使程序在异常退出的时候，在下次启动的时候，依然可以获得上一次的StreamingContext对象，保证计算数据不丢失，此时就需要将StreamingContext对象存储在持久化的系统中。也就是说需要制作StreamingContext对象的HA。
代码：测试：
   – 先正常运行一段时间，计算出结果
   – 停止程序
   – 再次启动
   – 验证再次启动的程序，是否能够拿回停止前计算得到的结果
原理：
  如果是第一次执行，那么在在这个checkpointDriectory目录中是不存在streamingContext对象的，所以要创建，第二次运行的时候，就不会在创建，则是从checkpointDriectory目录中读取进行恢复。
注意：
  正常情况下，使用这种方式的HA，只能持久状态数据到持久化的文件中，默认情况是不会持久化StreamingContext对象到CheckPointDriectory中的。  从故障中恢复checkpoint中有两种类型
   - Metadata checkpointing：driver节点中的元数据信息
     - Configuration：用于创建流式应用程序的配置
     - DStream：定义streaming程序的DStream操作
     - Incomplete batches：批量的job排队但尚未完成。（程序上次运行到的位置）
   - Data checkpointing：将生成的RDD保存到可靠的存储
     - 计算之后生成的RDD
     - 在receiver接收到数据，转化的RDD   – 从运行应用程序的driver的故障中恢复-元数据，（driver的HA）
   – 使用有状态计算的时候启动checkPoint：updateStateByKey或者reduceByKeyAndWindow…   – 有状态计算的时候：
    ssc.checkpoint("C:z_datacheckpoint")
   – driver的HA的时候：  在使用transf 香港云主机orm操作的时候介绍两个重要的概念：
  黑名单：如果允许的操作比不允许的操作多，那么将不允许的操作加入黑名单
  白名单：如果允许的操作比不允许的操作少，那么将允许的操作加入白名单
代码：黑名单中的数据会被过滤：

注意：
在做window操作时：
  - 窗口覆盖的数据流的时间长度，必须是批处理时间间隔的倍数
  - 前一个窗口到后一个窗口所经过的时间长度，必须是批处理时间间隔的倍数。
伪代码：概念：

相关推荐: Win10商店打不开怎么解决

今天小编给大家分享一下Win10商店打不开怎么解决的相关知识点，内容详细，逻辑清晰，相信大部分人都还太了解这方面的知识，所以分享这篇文章给大家参考一下，希望大家阅读完这篇文章后有所收获，下面我们一起来了解一下吧。具体步骤：1.在桌面左下角的搜索栏中 香港云主机…