sparkstreaming优化总结
一方面关于数据丢失和重复消费问题
1.数据丢失问题
receiver模式:
(该部分比较简单,可以跳过)
丢失原因:
首先,receiver task 接收 kafka 中的数据,并备份到其他 executor 中的blockmanager里,然后将偏移量提交给 zookeeper ,接着 存在备份的 executor 将数据的地址封装并发送到 driver 中的 receiver tracker,然后由 driver 发送 task ,以及监测任务执行和回收结果。
在这个过程中,如果数据已经提交到了 zookeeper ,此时,driver 挂了,executor 也会被 kill 掉,当 driver 重启时,内存中就没有数据的地址信息了,而且kafka 会从新的偏移量处发送数据,即发生数据丢失。
解决方案:
开启 WAL 机制,在数据备份的时候,同时将数据拷贝一份到 hdfs ,等数据备份完成之后,再提交偏移量。同时,driver启动时,如果 hdfs 上存在未消费的数据,则先消费该数据。
这样,即使zookeeper 提交偏移量之后 driver 挂了,当driver重启之后,依旧能从hdfs 上消费数据。
存在问题:
开启WAL机制可能导致数据重复消费等问题。
direct模式:
sparkstreaming 2.2 direct 模式采用的是kafka的 simple consumer api,该情况下,偏移量可以手动管理,只要保证数据都消费之后再提交偏移量,就不存在数据丢失问题。
2.数据重复消费问题:
receiver模式:
原因:
开启 WAL 机制后,如果数据成功备份到 hdfs 之后,driver 挂了,此时偏移量还未提交给 zookeeper,重启时,
driver会先消费 hdfs 中的数据,由于偏移量未提交,该数据会再次接收并消费。
解决方案:
以Receiver基于ZooKeeper的方式,当读取数据时去访问Kafka的元数据信息,在处理代码中例如foreachRDD或
transform时,将信息写入到内存数据库中(memoryS