站酷 | 插畫
搭建流程略，主要講一下如何更好的結合使用，看圖說話。
Kafka 結合 Spark Streaming 實現在線的準實時流分析，除了保證數據源和數據接收的可靠性，還要保證元數據的 checkpoint 。
以上的方案，不能防止數據的丟失。
Executor 收到數據後開始執行任務了。但是這時候 Driver 掛掉了，相應的 Executor 進程也會被 kill 掉，數據就會丟失。
為了防止上面這種數據丟失，Spark Streaming 1.2開始引入了WAL機制 。
啟用了WAL機制，已經接收的數據被接收器寫入到容錯存儲中，比如HDFS或者S3。由於採用了WAl機制，Driver可以從失敗的點重新讀取數據，即使Exectuor中內存的數據已經丟失了。在這個簡單的方法下，Spark Streaming提供了一種即使是Driver掛掉也可以避免數據丟失的機制。
At-least-once語義
接收器接收到輸入數據，並把它存儲到WAL中；接收器在更新Zookeeper中Kafka的偏移量之前突然掛掉了；這是就會出現數據被處理 2 次的情況。
終極解決方案 Kafka Direct API
為了解決由WAL引入的性能損失，並且保證 exactly-once 語義，Spark Streaming 1.3中引入了名為Kafka direct API
好處：
不再需要接收器，Executor 直接從 Kafka 中採用 Sample Consumer API 消費數據。
不再需要WAL機制，我們仍然可以從失敗恢復之後從Kafka中重新消費數據。
exactly-once語義得以保存，我們不再從WAL中讀取重複的數據。
綜合以上，direct 模式比receive模式的優點：
1、簡化並行讀取：如果要讀取多個partition，不需要創建多個輸入DStream，然後對它們進行union操作。Spark會創建跟Kafka partition一樣多的RDD partition，並且會並行從Kafka中讀取數據。所以在Kafka partition和RDD partition之間，有一個一對一的映射關係。
2、高性能：如果要保證零數據丟失，在基於receiver的方式中，需要開啟WAL機制。這種方式其實效率低下，因為數據實際上被複制了兩份，Kafka自己本身就有高可靠的機制會對數據複製一份，而這裡又會複製一份到WAL中。而基於direct的方式，不依賴Receiver，不需要開啟WAL機制，只要Kafka中作了數據的複製，那麼就可以通過Kafka的副本進行恢復。
3、一次且僅一次的事務機制：基於receiver的方式，是使用Kafka的高階API來在ZooKeeper中保存消費過的offset的。這是消費Kafka數據的傳統方式。這種方式配合著WAL機制可以保證數據零丟失的高可靠性，但是卻無法保證數據被處理一次且僅一次，可能會處理兩次。因為Spark和ZooKeeper之間可能是不同步的。基於direct的方式，使用kafka的簡單api，Spark Streaming自己就負責追蹤消費的offset，並保存在checkpoint中。Spark自己一定是同步的，因此可以保證數據是消費一次且僅消費一次。由於數據消費偏移量是保存在checkpoint中，因此，如果後續想使用kafka高級API消費數據，需要手動的更新zookeeper中的偏移量。
kafka 上新
Zookeeper 的恢復模式，廣播模式，選舉流程
Hadoop HA 深度解剖
HBase 數據模型，體系架構，組件功能說明等總結
PageRank 算法，搜索引擎的關鍵技術
如果對您有幫助，歡迎點贊、關注、轉發。
閱讀更多 大數據進擊之路 的文章
