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

這個只是利用KafkaOffsetmonitor設計的一個方案，利用它對任務進行監控，接著利用爬蟲技術獲取監控的信息，再把數據導入到openfalcon里面，在openfalcon里根據策略配置告警或者自己研發告警系統，最后把信息利用企業微信或者短信發送給開發人員！

上述就是小編為大家分享的SparkStreaming與Kafka的整合是怎么樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。