图解SparkStreaming与Kafka的整合，这些细节你们要注意！

前言

老刘是一名即将找工做的研二学生，写博客一方面是复习总结大数据开发的知识点，一方面是但愿帮助更多自学的小伙伴。因为老刘是自学大数据开发，确定会存在一些不足，还但愿你们可以批评指正，让咱们一块儿进步！

 今天讲述的是SparkStreaming与Kafka的整合，这篇文章很是适合刚入门的小伙伴，也欢迎你们前来发表意见，老刘此次会用图片的形式讲述别人技术博客没有的一些细节，这些细节对刚入门的小伙伴是很是有用的！！！

正文

为何有SparkStreaming与Kafka的整合？

首先咱们要知道为何会有SparkStreaming与Kafka的整合，任何事情的出现都不是平白无故的！

咱们要知道Spark做为实时计算框架，它仅仅涉及到计算，并无涉及到数据的存储，因此咱们后期须要使用spark对接外部的数据源。SparkStreaming做为Spark的一个子模块，它有4个类型的数据源：

1. socket数据源（测试的时候使用）
2. HDFS数据源（会用到，可是用得很少）
3. 自定义数据源（不重要，没怎么见过别人会自定义数据源）
4. 扩展的数据源（好比kafka数据源，它很是重要，面试中也会问到）

下面老刘图解SparkStreaming与Kafka的整合，但只讲原理，代码就不贴了，网上太多了，老刘写一些本身理解的东西！

SparkStreaming整合Kafka-0.8

SparkStreaming与Kafka的整合要看Kafka的版本，首先要讲的是SparkStreaming整合Kafka-0.8。

在SparkStreaming整合kafka-0.8中，要想保证数据不丢失，最简单的就是靠checkpoint的机制，可是checkpoint机制有一个毛病，对代码进行升级后，checkpoint机制就失效了。因此若是想实现数据不丢失，那么就须要本身管理offset。

你们对代码升级会不会感到陌生，老刘对它好好解释一下！

咱们在平常开发中经常会遇到两个状况，代码一开始有问题，改一下，而后从新打包，从新提交；业务逻辑发生改变，咱们也须要从新修改代码！

而咱们checkpoint第一次持久化的时候会整个相关的jar给序列化成一个二进制文件，这是一个独一无二的值作目录，若是SparkStreaming想经过checkpoint恢复数据，但若是代码发生改变，哪怕一点点，就找不到以前打包的目录，就会致使数据丢失！

因此咱们须要本身管理偏移量！

用ZooKeeper集群管理偏移量，程序启动后，就会读取上一次的偏移量，读取到数据后，SparkStreaming就会根据偏移量从kafka中读取数据，读到数据后，程序会运行。运行完后，就会提交偏移量到ZooKeeper集群，但有一个小问题，程序运行挂了，但偏移量未提交，结果已经部分到HBase，再次从新读取的时候，会有数据重复，但只影响一批次，对大数据来讲，影响过小！

可是有个很是严重的问题，当有特别多消费者消费数据的时候，须要读取偏移量，但ZooKeeper做为分布式协调框架，它不适合大量的读写操做，尤为是写操做。因此高并发的请求ZooKeeper是不适合的，它只能做为轻量级的元数据存储，不能负责高并发读写做为数据存储。

根据上述内容，就引出了SparkStreaming整合Kafka-1.0。

SparkStreaming整合Kafka-1.0

直接利用kafka保存offset偏移量，能够避免利用ZooKeeper存储offset偏移量带来的风险，这里也有一个注意的地方，kafka有一个自动提交偏移量的功能，但会致使数据丢失。

由于设置自动提交就会按照必定的频率，好比每隔2秒自动提交一次偏移量。但我截获一个数据后，还没来得及处理，恰好到达2秒就把偏移量提交了，因而就致使数据丢失，因此咱们通常手动提交偏移量！

如何设计监控告警方案？

在平常开发工做中，咱们须要对实时任务设计一个监控方案，由于实时任务没有监控，程序就在裸奔，任务是否有延迟等状况没法获取，这是很是可怕的状况！

这个只是利用KafkaOffsetmonitor设计的一个方案，利用它对任务进行监控，接着利用爬虫技术获取监控的信息，再把数据导入到openfalcon里面，在openfalcon里根据策略配置告警或者本身研发告警系统，最后把信息利用企业微信或者短信发送给开发人员！

总结

好啦！本篇主要讲解了SparkStreaming和Kafka的整合过程，老刘花了不少心思讲了不少细节，对大数据感兴趣的伙伴记得给老刘点赞关注。最后，若是有疑问联系公众号：努力的老刘，进行愉快的交流！