spark 读写 cassandra

前面应该还有个数据生产者，比如flume. flume负责生产数据，发送至kafka。 spark streaming作为消费者，实时的从kafka中获取数据进行计算。 计算结果保存至redis，供实时推荐使用。 flume+kafka+spark+redis是实时数据收集与计算的一套经典架构...

---

　　1、kafkautils.createdstream
构造函数为kafkautils.createdstream(ssc, [zk], [consumer group id], [per-topic,partitions] )
使用了receivers来接收数据，利用的是kafka高层次的消费者api，对于所有的receivers接收到的数据将会保存在spark executors中，然后通过spark streaming启动job来处理这些数据，默认会丢失，可启用wal日志，该日志存储在hdfs上
a、创建一个receiver来对kafka进行定时拉取数据，ssc的rdd分区和kafka的topic分区不是一个概念，故如果增加特定主体分区数仅仅是增加一个receiver中消费topic的线程数，并不增加spark的并行处理数据数量
b、对于不同的group和topic可以使用多个receivers创建不同的dstream
c、如果启用了wal，需要设置存储级别，即kafkautils.createstream(….,storagelevel.memory_and_disk_ser)
2.kafkautils.createdirectstream
区别receiver接收数据，这种方式定期地从kafka的topic+partition中查询最新的偏移量，再根据偏移量范围在每个batch里面处理数据，使用的是kafka的简单消费者api
优点:
a、 简化并行，不需要多个kafka输入流，该方法将会创建和kafka分区一样的rdd个数，而且会从kafka并行读取。
b、高效，这种方式并不需要wal，wal模式需要对数据复制两次，第一次是被kafka复制，另一次是写到wal中
c、恰好一次语义(exactly-once-semantics)，传统的读取kafka数据是通过kafka高层次api把偏移量写入zookeeper中，存在数据丢失的可能性是zookeeper中和ssc的偏移量不一致。eos通过实现kafka低层次api，偏移量仅仅被ssc保存在checkpoint中，消除了zk和ssc偏移量不一致的问题。缺点是无法使用基于zookeeper的kafka监控工具