Spark Streaming怎樣使用Kafka保證數(shù)據(jù)零丟失，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

創(chuàng)新互聯(lián)公司是一家專業(yè)提供南江企業(yè)網(wǎng)站建設,專注與成都網(wǎng)站制作、成都做網(wǎng)站、html5、小程序制作等業(yè)務。10年已為南江眾多企業(yè)、政府機構等服務。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設計公司優(yōu)惠進行中。

spark_streaming使用kafka保證數(shù)據(jù)零丟失

spark streaming從1.2開始提供了數(shù)據(jù)的零丟失，想享受這個特性，需要滿足如下條件：

1.數(shù)據(jù)輸入需要可靠的sources和可靠的receivers

2.應用metadata必須通過應用driver checkpoint

3.WAL（write ahead log）

##可靠的sources和receivers

spark streaming可以通過多種方式作為數(shù)據(jù)sources（包括kafka），輸入數(shù)據(jù)通過receivers接收，通過replication存儲于spark中（為了faultolerance，默認復制到兩個spark executors），如果數(shù)據(jù)復制完成，receivers可以知道（例如kafka中更新offsets到zookeeper中）。這樣當receivers在接收數(shù)據(jù)過程中crash掉，不會有數(shù)據(jù)丟失，receivers沒有復制的數(shù)據(jù)，當receiver恢復后重新接收。

##metadata checkpoint

可靠的sources和receivers，可以使數(shù)據(jù)在receivers失敗后恢復，然而在driver失敗后恢復是比較復雜的，一種方法是通過checkpoint metadata到HDFS或者S3。metadata包括：

• configuration

• code

• 一些排隊等待處理但沒有完成的RDD（僅僅是metadata，而不是data）

這樣當driver失敗時，可以通過metadata checkpoint，重構應用程序并知道執(zhí)行到那個地方。

##數(shù)據(jù)可能丟失的場景

可靠的sources和receivers，以及metadata checkpoint也不可以保證數(shù)據(jù)的不丟失，例如：

• 兩個executor得到計算數(shù)據(jù)，并保存在他們的內存中

• receivers知道數(shù)據(jù)已經(jīng)輸入

• executors開始計算數(shù)據(jù)

• driver突然失敗

• driver失敗，那么executors都會被kill掉

• 因為executor被kill掉，那么他們內存中得數(shù)據(jù)都會丟失，但是這些數(shù)據(jù)不再被處理

• executor中的數(shù)據(jù)不可恢復

##WAL

為了避免上面情景的出現(xiàn)，spark streaming 1.2引入了WAL。所有接收的數(shù)據(jù)通過receivers寫入HDFS或者S3中checkpoint目錄，這樣當driver失敗后，executor中數(shù)據(jù)丟失后，可以通過checkpoint恢復。

##At-Least-Once 盡管WAL可以保證數(shù)據(jù)零丟失，但是不能保證exactly-once，例如下面場景：

• Receivers接收完數(shù)據(jù)并保存到HDFS或S3

• 在更新offset前，receivers失敗了

• Spark Streaming以為數(shù)據(jù)接收成功，但是Kafka以為數(shù)據(jù)沒有接收成功，因為offset沒有更新到zookeeper

• 隨后receiver恢復了

• 從WAL可以讀取的數(shù)據(jù)重新消費一次，因為使用的kafka High-Level消費API，從zookeeper中保存的offsets開始消費

##WAL的缺點 通過上面描述，WAL有兩個缺點：

• 降低了receivers的性能，因為數(shù)據(jù)還要存儲到HDFS等分布式文件系統(tǒng)

• 對于一些resources，可能存在重復的數(shù)據(jù)，比如Kafka，在Kafka中存在一份數(shù)據(jù)，在Spark Streaming也存在一份（以WAL的形式存儲在hadoop API兼容的文件系統(tǒng)中）

##Kafka direct API 為了WAL的性能損失和exactly-once，spark streaming1.3中使用Kafka direct API。非常巧妙，Spark driver計算下個batch的offsets，指導executor消費對應的topics和partitions。消費Kafka消息，就像消費文件系統(tǒng)文件一樣。

1.不再需要kafka receivers，executor直接通過Kafka API消費數(shù)據(jù)

2.WAL不再需要，如果從失敗恢復，可以重新消費

3.exactly-once得到了保證，不會再從WAL中重復讀取數(shù)據(jù)

主要說的是spark streaming通過各種方式來保證數(shù)據(jù)不丟失，并保證exactly-once，每個版本都是spark streaming越來越穩(wěn)定，越來越向生產(chǎn)環(huán)境使用發(fā)展。

關于Spark Streaming怎樣使用Kafka保證數(shù)據(jù)零丟失問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關知識。