一臊诊、Spark Streaming 數(shù)據(jù)安全性的考慮：
Spark Streaming不斷的接收數(shù)據(jù)，并且不斷的產(chǎn)生Job斜脂，不斷的提交Job給集群運(yùn)行抓艳。所以這就涉及到一個(gè)非常重要的問題數(shù)據(jù)安全性。
Spark Streaming是基于Spark Core之上的帚戳，如果能夠確保數(shù)據(jù)安全可好的話玷或，在Spark Streaming生成Job的時(shí)候里面是基于RDD，即使運(yùn)行的時(shí)候出現(xiàn)問題片任，那么Spark Streaming也可以借助Spark Core的容錯(cuò)機(jī)制自動(dòng)容錯(cuò)偏友。
對(duì)Executor容錯(cuò)主要是對(duì)數(shù)據(jù)的安全容錯(cuò)
為啥這里不考慮對(duì)數(shù)據(jù)計(jì)算的容錯(cuò)：計(jì)算的時(shí)候Spark Streaming是借助于Spark Core之上的容錯(cuò)的，所以天然就是安全可靠的对供。
Executor容錯(cuò)方式：
1. 最簡(jiǎn)單的容錯(cuò)是副本方式位他，基于底層BlockManager副本容錯(cuò)，也是默認(rèn)的容錯(cuò)方式产场。
2.WAL日志方式
3. 接收到數(shù)據(jù)之后不做副本鹅髓，支持?jǐn)?shù)據(jù)重放，所謂重放就是支持反復(fù)讀取數(shù)據(jù)京景。
BlockManager備份：
默認(rèn)在內(nèi)存中兩份副本窿冯，也就是Spark Streaming的Receiver接收到數(shù)據(jù)之后存儲(chǔ)的時(shí)候指定StorageLevel為MEMORY_AND_DISK_SER_2，底層存儲(chǔ)是交給BlockManager确徙，BlockManager的語義確保了如果指定了兩份副本醒串，一般都在內(nèi)存中执桌。所以至少兩個(gè)Executor中都會(huì)有數(shù)據(jù)。
Receiver將數(shù)據(jù)交給BlockManger是由ReceiveredBlockHandler來處理的厦凤，有兩種ReceiveredBlockHandler的實(shí)現(xiàn)：
1.WriteAheadLogBasedBlockHandler
2.BlockManagerBasedBlockHandler
這里的storageLevel是構(gòu)建InputDStream時(shí)傳入的鼻吮，socketTextStream的默認(rèn)存儲(chǔ)級(jí)別是StorageLevel.MEMORY_AND_DISK_SER_2
如果使用WriteAheadLogBasedBlockHandler需要開啟WAL，默認(rèn)并沒有開啟：
WAL日志方式：
這種方式會(huì)現(xiàn)將數(shù)據(jù)寫入日志文件较鼓，就是checkpoint目錄椎木，出現(xiàn)異常是，從checkpoint目錄重新讀取數(shù)據(jù)博烂，進(jìn)行恢復(fù)香椎。啟動(dòng)WAL時(shí)候，沒必要將副本數(shù)設(shè)置成大于1禽篱，也不需要序列化畜伐。
WAL會(huì)將數(shù)據(jù)同時(shí)寫入BlockManager和write ahead log，而且是并行的寫block躺率，當(dāng)然兩處的block存儲(chǔ)完成玛界，才會(huì)返回。
將Block 存入BlockManager：
將Block 存入WAL日志：
WAL寫數(shù)據(jù)的時(shí)候是順序?qū)懙恐ǎ瑪?shù)據(jù)不可修改慎框，所以讀的時(shí)候只需要按照指針(也就是要讀的record在那，長(zhǎng)度是多少)讀即可后添。所以WAL的速度非潮靠荩快。
瀏覽一下WriteAheadLog遇西，他是一個(gè)抽象類：
看一下WriteAheadLog的一個(gè)實(shí)現(xiàn)類FileBasedWriteAheadLog的write方法：
根據(jù)不同時(shí)間獲取不同Writer將序列化結(jié)果寫入文件,返回一個(gè)FileBasedWriteAheadLogSegment類型的對(duì)象fileSegment馅精。
讀數(shù)據(jù)：
其中創(chuàng)建了一個(gè)FileBaseWriteAheadLogRandomReader對(duì)象，然后調(diào)用了該對(duì)象的read方法:
支持?jǐn)?shù)據(jù)重放粱檀。
在實(shí)際的開發(fā)中直接使用Kafka洲敢，因?yàn)椴恍枰蒎e(cuò)，也不需要副本茄蚯。
Kafka有Receiver方式和Direct方式
Receiver方式：是交給Zookeeper去管理數(shù)據(jù)的沦疾，也就是偏移量offSet.如果失效后，Kafka會(huì)基于offSet重新讀取第队，因?yàn)樘幚頂?shù)據(jù)的時(shí)候中途崩潰，不會(huì)給Zookeeper發(fā)送ACK刨秆，此時(shí)Zookeeper認(rèn)為你并沒有消息這個(gè)數(shù)據(jù)凳谦。但是在實(shí)際中越來用的越多的是Direct的方式直接操作offSet.而且還是自己管理offSet.
DirectKafkaInputDStream會(huì)去查看最新的offSet,并且把offSet放到Batch中。
在Batch每次生成的時(shí)候都會(huì)調(diào)用latestLeaderOffsets查看最近的offSet,此時(shí)的offSet就會(huì)與上一個(gè)offSet相減獲得這個(gè)Batch的范圍衡未。這樣就可以知道讀那些數(shù)據(jù)尸执。
轉(zhuǎn)載請(qǐng)注明出去：http://www.reibang.com/users/4435a13863fb/latest_articles
