大数据学习系列----基于Spark Streaming流式计算

个性化的需求

随着互联网知识信息指数级膨胀，个性化的需求对于用户来讲愈来愈重要，经过推荐算法和用户点击行为的流式计算能够很简单的作出一个商用的推荐系统。

流程

1. java
2. spark streaming
3. kafka
4. redis
5. mysql

spark streaming从kafka读取用户行为数据，过滤数据后从redis中拉取物品类似度矩阵，从db或缓存中获取用户历史行为，经过协同过滤进行兴趣/ctr候选集计算，将结果缓存到redis，异步持久化到db，经过接口进行数据展现。

开发包使用KafkaUtils类

设置消费者offset

数据从kafka拉取时，可能由于程序异常，形成数据丢失或不一致，能够经过kafka把数据从新拉取，能够指定offset读取。

从kafka拉取数据，转换为spark streaming中的数据结构DStream。 接收数据有两种：

1. 利用receiver接收数据；
2. 直接从kafka读取数据；

receiver方式

基本的使用kafka高阶api，接收的全部数据存储在spark的executor中，以后spark streaming提交的job会处理这些数据。

reveiver方式，spark中partiton和kafka的partition并非相关的，若是加大每一个topic的partition数量，仅仅增长线程来处理由单一receiver消费的主题，但并无增长spark在处理数据上的并行度。

对于不一样的group和topic，可使用多个receiver建立不一样的DStream来提高并行度，以后利用union来统一成一个DStream。

直接读取方式

Direct方式，没有receiver这一层，会周期性的获取kafka中每一个topic的每一个partition中新的offset，以后根据设定的maxRatePerPartition来处理每一个batch。

相较于receiver方式的优点是：

1. 简化的并行：direct方式中，kafka的partiton与rdd的partition是一一对应的，并行读取kafka数据，这种映射关系利于优化和理解。
2. 高效：receiver方式中，为了达到0数据丢失，将数据存入Write ahead log中，这样kafka和日志中就保存了两份数据，浪费；direct方式不存在这个问题。
3. 精确：receiver方式，使用的是kafka的高阶api从zk中获取offset值，也是传统的同kafka中读取的方式，但spark streaming消费数据和zk中记录的offset不一样步，偶尔形成数据重复消费；direct方式直接使用低阶kafka api，offset利用spark streaming的checkpoints记录，消除不一致。

receiver方式，是从zk获取offset值，zk保存了当前消费的offset值，若是从新启动开始消费会接着上次offset继续消费。 direct方式中，直接从kafka来读取数据，offset要本身记录，能够经过checkpoint，数据库，文件记录，或者写回到zk。

调优

若是批处理时间设置短，产生的job并不能在这期间完成，就会形成数据不断累积，致使spark streaming阻塞。

spark streaming中的DStream若是被反复利用，最好使用cache()，将数据流缓存起来，防止过分调度形成网络开销。

设置合理的GC，并行垃圾回收。