圖解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的整合過程，老劉花了不少心思講了不少細節，對大數據感興趣的夥伴記得給老劉點贊關注。最後，若是有疑問聯繫公衆號：努力的老劉，進行愉快的交流！