第一章

信息科技需要處理的三大核心問(wèn)題

信息存儲(chǔ)、信息傳輸、信息處理

數(shù)據(jù)產(chǎn)生方式的變革

運(yùn)營(yíng)式系統(tǒng)階段

數(shù)據(jù)庫(kù)的出現(xiàn)使數(shù)據(jù)管理的復(fù)雜度大大降低，數(shù)據(jù)往往伴隨著一定的運(yùn)營(yíng)活動(dòng)而產(chǎn)生并記錄在數(shù)據(jù)庫(kù)中，數(shù)據(jù)的產(chǎn)生方式是被動(dòng)的

用戶原創(chuàng)內(nèi)容階段

數(shù)據(jù)爆發(fā)產(chǎn)生于Web2.0時(shí)代，而Web2.0的最重要的標(biāo)志就是用戶原創(chuàng)內(nèi)容
智能手機(jī)等移動(dòng)設(shè)備加速內(nèi)容產(chǎn)生
數(shù)據(jù)產(chǎn)生方式是主動(dòng)的

感知式系統(tǒng)階段

感知式系統(tǒng)的廣泛使用
人類社會(huì)數(shù)據(jù)量第三次大的飛躍最終導(dǎo)致的大數(shù)據(jù)的產(chǎn)生

大數(shù)據(jù)4V概念（能簡(jiǎn)要概括）

數(shù)據(jù)量大、數(shù)據(jù)類型繁多、處理速度快、價(jià)值密度低

大數(shù)據(jù)對(duì)思維方式的影響

全樣而非抽樣、效率而非準(zhǔn)確、相關(guān)而非因果

大數(shù)據(jù)技術(shù)的不同層面及其功能

技術(shù)層面	功能
數(shù)據(jù)采集與預(yù)處理	采用ELT工具將分布的、異構(gòu)數(shù)據(jù)源中的數(shù)據(jù)，如關(guān)系數(shù)據(jù)、平面數(shù)據(jù)文件等，抽取到臨時(shí)中間層后進(jìn)行清洗、轉(zhuǎn)換、集成，最后加載到數(shù)據(jù)倉(cāng)庫(kù)或數(shù)據(jù)集市中，成為聯(lián)機(jī)分析處理、數(shù)據(jù)挖掘的基礎(chǔ)；也可以利用日志采集工具（如Flume、Kafka等）把實(shí)時(shí)采集的數(shù)據(jù)作為流計(jì)算系統(tǒng)的輸入，進(jìn)行實(shí)時(shí)處理分析
數(shù)據(jù)存儲(chǔ)和管理	利用分布式文件系統(tǒng)、數(shù)據(jù)倉(cāng)庫(kù)、關(guān)系數(shù)據(jù)庫(kù)、NoSQL數(shù)據(jù)庫(kù)、云數(shù)據(jù)庫(kù)等，實(shí)現(xiàn)對(duì)結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化海量數(shù)據(jù)的存儲(chǔ)和管理
數(shù)據(jù)處理和分析	利用分布式并行編程模型和計(jì)算機(jī)框架，結(jié)合機(jī)器學(xué)習(xí)和數(shù)據(jù)挖掘算法，實(shí)現(xiàn)對(duì)海量數(shù)據(jù)的處理和分析；對(duì)分析結(jié)果進(jìn)行可視化呈現(xiàn)，幫助人們更好地理解數(shù)據(jù)、分析數(shù)據(jù)
數(shù)據(jù)安全和隱私保護(hù)	在從大數(shù)據(jù)中挖掘潛在的巨大商業(yè)價(jià)值和學(xué)術(shù)價(jià)值的同時(shí)，構(gòu)建隱私數(shù)據(jù)保護(hù)體系和數(shù)據(jù)安全體系，有效保護(hù)個(gè)人隱私和數(shù)據(jù)安全

大數(shù)據(jù)計(jì)算模式

大數(shù)據(jù)計(jì)算模式	解決問(wèn)題	代表產(chǎn)品
批處理計(jì)算	針對(duì)大規(guī)模數(shù)據(jù)的批量處理	MapReduce、Spark等
流計(jì)算	針對(duì)流數(shù)據(jù)的實(shí)時(shí)計(jì)算	Storm、S4、Flume、Streams、Puma、DStream、SuperMario、銀河數(shù)據(jù)處理平臺(tái)等
圖計(jì)算	針對(duì)大規(guī)模圖結(jié)構(gòu)數(shù)據(jù)的處理	Pregel、GraphX、Giraph、PowerGraph、Hama、GoldenOrb等
查詢分析計(jì)算	大規(guī)模數(shù)據(jù)的存儲(chǔ)管理和查詢分析系	Dremel、Hive、Cassandra、Impala等

云計(jì)算關(guān)鍵技術(shù)

虛擬化、分布式存儲(chǔ)、分布式計(jì)算、多租戶等

物聯(lián)網(wǎng)關(guān)鍵技術(shù)

識(shí)別和感知技術(shù)
網(wǎng)絡(luò)與通信技術(shù)
數(shù)據(jù)挖掘與融合技術(shù)

第二-三章

分布式文件系統(tǒng)概念

分布式文件系統(tǒng)是一種通過(guò)網(wǎng)絡(luò)實(shí)現(xiàn)文件在多臺(tái)主機(jī)上進(jìn)行分布式存儲(chǔ)的文件系統(tǒng)

HDFS文件塊

HDFS默認(rèn)一個(gè)塊64MB，一個(gè)文件被分成多個(gè)塊，以塊作為存儲(chǔ)單位 塊的大小遠(yuǎn)遠(yuǎn)大于普通文件系統(tǒng)，可以最小化尋址開(kāi)銷 。

HDFS采用抽象的塊概念可以帶來(lái)以下幾個(gè)明顯的好處：

支持大規(guī)模文件存儲(chǔ)
簡(jiǎn)化系統(tǒng)設(shè)計(jì)
適合數(shù)據(jù)備份

名稱節(jié)點(diǎn)、數(shù)據(jù)節(jié)點(diǎn)的功能與工作原理（能簡(jiǎn)要概括）

名稱節(jié)點(diǎn)功能：

在HDFS中，名稱節(jié)點(diǎn)（NameNode）負(fù)責(zé)管理分布式文件系統(tǒng)的命名空間，保存了兩個(gè)核心的數(shù)據(jù)結(jié)構(gòu)，即FsImage和EditLog

名稱節(jié)點(diǎn)工作原理：

在名稱節(jié)點(diǎn)啟動(dòng)的時(shí)候，它會(huì)將FsImage文件中的內(nèi)容加載到內(nèi)存中，之后再 執(zhí)行EditLog文件中的各項(xiàng)操作，使得內(nèi)存中的元數(shù)據(jù)和實(shí)際的同步，存在內(nèi)存 中的元數(shù)據(jù)支持客戶端的讀操作。
一旦在內(nèi)存中成功建立文件系統(tǒng)元數(shù)據(jù)的映射，則創(chuàng)建一個(gè)新的FsImage文件 和一個(gè)空的EditLog文件
名稱節(jié)點(diǎn)起來(lái)之后，HDFS中的更新操作會(huì)重新寫(xiě)到EditLog文件中，因?yàn)?FsImage文件一般都很大（GB級(jí)別的很常見(jiàn)），如果所有的更新操作都往 FsImage文件中添加，這樣會(huì)導(dǎo)致系統(tǒng)運(yùn)行的十分緩慢，但是，如果往EditLog 文件里面寫(xiě)就不會(huì)這樣，因?yàn)镋ditLog 要小很多。每次執(zhí)行寫(xiě)操作之后，且在 向客戶端發(fā)送成功代碼之前，edits文件都需要同步更新

數(shù)據(jù)節(jié)點(diǎn)：

? 數(shù)據(jù)節(jié)點(diǎn)是分布式文件系統(tǒng)HDFS的工作節(jié)點(diǎn)，負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和讀取，會(huì)根據(jù)客戶端或者是名稱節(jié)點(diǎn)的調(diào) 度來(lái)進(jìn)行數(shù)據(jù)的存儲(chǔ)和檢 索，并且向名稱節(jié)點(diǎn)定期發(fā)送自己所存儲(chǔ)的塊的列表

? 每個(gè)數(shù)據(jù)節(jié)點(diǎn)中的數(shù)據(jù)會(huì)被保存在各自節(jié)點(diǎn)的本地Linux文件系統(tǒng)中

第二名稱節(jié)點(diǎn)的意義與功能（理解工作原理，能用自己語(yǔ)言說(shuō)明）

第二名稱節(jié)點(diǎn)是HDFS架構(gòu)中的一個(gè)組成部分，它是用來(lái)保存名稱節(jié)點(diǎn)中對(duì)HDFS 元數(shù)據(jù)信息的備份，并減少名稱節(jié)點(diǎn)重啟的時(shí)間。SecondaryNameNode一般是 單獨(dú)運(yùn)行在一臺(tái)機(jī)器上

SecondaryNameNode的工作情況：

（1）SecondaryNameNode會(huì)定期和 NameNode通信，請(qǐng)求其停止使用EditLog 文件，暫時(shí)將新的寫(xiě)操作寫(xiě)到一個(gè)新的文件 edit.new上來(lái)，這個(gè)操作是瞬間完成，上層 寫(xiě)日志的函數(shù)完全感覺(jué)不到差別；

（2）SecondaryNameNode通過(guò)HTTP GET方式從NameNode上獲取到FsImage和 EditLog文件，并下載到本地的相應(yīng)目錄下 ；

（3）SecondaryNameNode將下載下 來(lái)的FsImage載入到內(nèi)存，然后一條一條地 執(zhí)行EditLog文件中的各項(xiàng)更新操作，使得 內(nèi)存中的FsImage保持最新；這個(gè)過(guò)程就是 EditLog和FsImage文件合并；

（4）SecondaryNameNode執(zhí)行完（3 ）操作之后，會(huì)通過(guò)post方式將新的 FsImage文件發(fā)送到NameNode節(jié)點(diǎn)上

（5）NameNode將從 SecondaryNameNode接收到的新的 FsImage替換舊的FsImage文件，同時(shí)將 edit.new替換EditLog文件，通過(guò)這個(gè)過(guò)程 EditLog就變小了

HDFS冗余存儲(chǔ)的定義與意義

定義：

? 作為一個(gè)分布式文件系統(tǒng)，為了保證系統(tǒng)的容錯(cuò)性和可用性，HDFS采用 了多副本方式對(duì)數(shù)據(jù)進(jìn)行冗余存儲(chǔ)，通常一個(gè)數(shù)據(jù)塊的多個(gè)副本會(huì)被分布到不 同的數(shù)據(jù)節(jié)點(diǎn)上

意義：

? （1）加快數(shù)據(jù)傳輸速度

? （2）容易檢查數(shù)據(jù)錯(cuò)誤

? （3）保證數(shù)據(jù)可靠性

HDFS數(shù)據(jù)存放策略，讀取策略P52 （理解工作原理，用自己的話說(shuō)明）

數(shù)據(jù)存放：

第一個(gè)副本：放置在上傳文件的數(shù)據(jù)節(jié)點(diǎn)；如果是集群外提交，則隨機(jī)挑 選一臺(tái)磁盤(pán)不太滿、CPU不太忙的節(jié)點(diǎn)

第二個(gè)副本：放置在與第一個(gè)副本不同的機(jī)架的節(jié)點(diǎn)上

第三個(gè)副本：與第一個(gè)副本相同機(jī)架的其他節(jié)點(diǎn)上

更多副本：隨機(jī)節(jié)點(diǎn)

數(shù)據(jù)讀取：

? HDFS提供了一個(gè)API可以確定一個(gè)數(shù)據(jù)節(jié)點(diǎn)所屬的機(jī)架ID，客戶端也 可以調(diào)用API獲取自己所屬的機(jī)架ID。當(dāng)客戶端讀取數(shù)據(jù)時(shí)，從名稱節(jié)點(diǎn)獲得數(shù)據(jù)塊不同副本的存放位置列表， 列表中包含了副本所在的數(shù)據(jù)節(jié)點(diǎn)，可以調(diào)用API來(lái)確定客戶端和這些 數(shù)據(jù)節(jié)點(diǎn)所屬的機(jī)架ID，當(dāng)發(fā)現(xiàn)某個(gè)數(shù)據(jù)塊副本對(duì)應(yīng)的機(jī)架ID和客戶端 對(duì)應(yīng)的機(jī)架ID相同時(shí)，就優(yōu)先選擇該副本讀取數(shù)據(jù)，如果沒(méi)有發(fā)現(xiàn)，就隨機(jī)選擇一個(gè)副本讀取數(shù)據(jù)

HDFS三種數(shù)據(jù)錯(cuò)誤及其恢復(fù)方法（理解工作原理，用自己的話說(shuō)明）

名稱節(jié)點(diǎn)出錯(cuò)

恢復(fù)方法：HDFS設(shè)置了備份機(jī)制，把這些核心文件 同步復(fù)制到備份服務(wù)器SecondaryNameNode上。當(dāng)名稱節(jié)點(diǎn)出錯(cuò)時(shí)， 就可以根據(jù)備份服務(wù)器SecondaryNameNode中的FsImage和Editlog 數(shù)據(jù)進(jìn)行恢復(fù)。

數(shù)據(jù)節(jié)點(diǎn)出錯(cuò)

恢復(fù)方法：每個(gè)數(shù)據(jù)節(jié)點(diǎn)會(huì)定期向名稱節(jié)點(diǎn)發(fā)送“心跳”信息，向名稱節(jié)點(diǎn)報(bào)告自 己的狀態(tài)。當(dāng)數(shù)據(jù)節(jié)點(diǎn)發(fā)生故障，或者網(wǎng)絡(luò)發(fā)生斷網(wǎng)時(shí)，名稱節(jié)點(diǎn)就無(wú)法收到來(lái)自 一些數(shù)據(jù)節(jié)點(diǎn)的心跳信息，這時(shí)，這些數(shù)據(jù)節(jié)點(diǎn)就會(huì)被標(biāo)記為“宕機(jī)”， 節(jié)點(diǎn)上面的所有數(shù)據(jù)都會(huì)被標(biāo)記為“不可讀”，名稱節(jié)點(diǎn)不會(huì)再給它們 發(fā)送任何I/O請(qǐng)求。這時(shí)，有可能出現(xiàn)一種情形，即由于一些數(shù)據(jù)節(jié)點(diǎn)的不可用，會(huì)導(dǎo)致一 些數(shù)據(jù)塊的副本數(shù)量小于冗余因子。名稱節(jié)點(diǎn)會(huì)定期檢查這種情況，一旦發(fā)現(xiàn)某個(gè)數(shù)據(jù)塊的副本數(shù)量小于冗 余因子，就會(huì)啟動(dòng)數(shù)據(jù)冗余復(fù)制，為它生成新的副本

數(shù)據(jù)出錯(cuò)

恢復(fù)方法：當(dāng)客戶端讀取文件的時(shí)候，會(huì)先讀取該信息文件，然后，利用該信息文件對(duì) 每個(gè)讀取的數(shù)據(jù)塊進(jìn)行校驗(yàn)，如果校驗(yàn)出錯(cuò)，客戶端就會(huì)請(qǐng)求到另外一個(gè)數(shù) 據(jù)節(jié)點(diǎn)讀取該文件塊，并且向名稱節(jié)點(diǎn)報(bào)告這個(gè)文件塊有錯(cuò)誤，名稱節(jié)點(diǎn)會(huì) 定期檢查并且重新復(fù)制這個(gè)塊

第四章

HBASE生態(tài)系統(tǒng)

HBASE的數(shù)據(jù)模型相關(guān)概念，理解掌握其中各個(gè)概念

表：HBase采用表來(lái)組織數(shù)據(jù)，表由行和列組成，列劃分為若干個(gè)列族
行：每個(gè)HBase表都由若干行組成，每個(gè)行由行鍵（row key）來(lái)標(biāo)識(shí)。
列族：一個(gè)HBase表被分組成許多“列族”（Column Family）的集合，它是基本的訪問(wèn)控制單元
列限定符：列族里的數(shù)據(jù)通過(guò)列限定符（或列）來(lái)定位
單元格：在HBase表中，通過(guò)行、列族和列限定符確定一個(gè)“單元格”（cell），單元格中存儲(chǔ)的數(shù)據(jù)沒(méi)有數(shù)據(jù)類型，總被視為字節(jié)數(shù)組byte[]
時(shí)間戳：每個(gè)單元格都保存著同一份數(shù)據(jù)的多個(gè)版本，這些版本采用時(shí)間戳進(jìn)行索引

數(shù)據(jù)坐標(biāo)的含義

HBase中需要根據(jù)行鍵、列族、列限定符和時(shí)間戳來(lái)確定一個(gè)單元格，因此，可以視為一個(gè)“四維坐標(biāo)”，即[行鍵, 列族, 列限定符, 時(shí)間戳]

概念視圖與物理視圖的實(shí)際含義

概念視圖：在Hbase的概念視圖中，一個(gè)表可以視為一個(gè)稀疏、多維的映射關(guān)系

物理視圖：在概念視圖層面，HBase中的每個(gè)表是由許多行組成的，但是在物理存儲(chǔ)層面，它是采用了基于列的存儲(chǔ)方式

HBASE三層結(jié)構(gòu)

層次	名稱	作用
第一層	Zookeeper文件	記錄了-ROOT-表的位置信息
第二層	-ROOT-表	記錄了.META.表的Region位置信息 -ROOT-表只能有一個(gè)Region。通過(guò)-ROOT表，就可以訪問(wèn).META.表中的數(shù)據(jù)
第三層	.META.表	記錄了用戶數(shù)據(jù)表的Region位置信息， .META.表可以有多個(gè)Region，保存了HBase 中所有用戶數(shù)據(jù)表的Region位置信息

第五章

NoSQL數(shù)據(jù)庫(kù)的含義與特點(diǎn)

含義：

? NoSQL是一種不同于關(guān)系數(shù)據(jù)庫(kù)的數(shù)據(jù)庫(kù)管理系統(tǒng)設(shè)計(jì)方式，是對(duì)非關(guān)系型數(shù)據(jù)庫(kù)的統(tǒng)稱，它所采用的數(shù)據(jù)模型并非傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的關(guān)系模型，而是類似鍵/值、列族、文檔等菲關(guān)系模型。

特點(diǎn)：

? （1）靈活的可擴(kuò)展性

? （2）靈活的數(shù)據(jù)模型

? （3）與云計(jì)算緊密融合

關(guān)系數(shù)據(jù)庫(kù)在WEB 2.0時(shí)代的局限 與WEB 2.0不適用關(guān)系型數(shù)據(jù)庫(kù)的原因

（1）無(wú)法滿足海量數(shù)據(jù)的管理需求

（2）無(wú)法滿足數(shù)據(jù)高并發(fā)的需求

（3）無(wú)法滿足高可擴(kuò)展性和高可用性的需求

四大類型NoSQL數(shù)據(jù)庫(kù)的定義,特點(diǎn),代表性產(chǎn)品（理解并能用自己語(yǔ)言說(shuō)明）

1.key-value

Redis
鍵值對(duì)存儲(chǔ)，特點(diǎn)：查詢數(shù)據(jù)塊
內(nèi)容緩存，主要用于處理大量數(shù)據(jù)的高訪問(wèn)負(fù)載，也用于一些日志系統(tǒng)等等。

鍵值數(shù)據(jù)庫(kù)適用于那些頻繁讀寫(xiě)，擁有簡(jiǎn)單數(shù)據(jù)模型的應(yīng)用。鍵值數(shù)據(jù)庫(kù)中存儲(chǔ)的值可以是簡(jiǎn)單的標(biāo)量值，如整數(shù)或布爾值，也可以是結(jié)構(gòu)化數(shù)據(jù)類型，比如列表和JSON結(jié)構(gòu)。

2.Colunmn列式存儲(chǔ)
HBase
將同一列的數(shù)據(jù)放在一起，查詢非?？?/p>

列族數(shù)據(jù)庫(kù)被設(shè)計(jì)應(yīng)用于大量數(shù)據(jù)的情況，它保證了讀取和寫(xiě)入的性能和高可用性。谷歌推出Bigtable來(lái)應(yīng)對(duì)其服務(wù)需求。Facebook開(kāi)發(fā)Cassandra 來(lái)支持其收件箱搜索服務(wù)。

3.document文檔存儲(chǔ)

MongoDB
經(jīng)典用于web項(xiàng)目中，與KeyValue類似，比如MongoDB主要應(yīng)用在爬蟲(chóng)

文檔型數(shù)據(jù)庫(kù)按照靈活性的標(biāo)準(zhǔn)設(shè)計(jì)。如果一個(gè)應(yīng)用程序需要存儲(chǔ)不同的屬性以及大量的數(shù)據(jù)，那么文檔數(shù)據(jù)庫(kù)將會(huì)是一個(gè)很好的選擇。例如，要在關(guān)系數(shù)據(jù)庫(kù)中表示產(chǎn)品，建模者可以使用通用的屬性和額外的表來(lái)為每個(gè)產(chǎn)品子類型存儲(chǔ)屬性。文檔數(shù)據(jù)庫(kù)卻可以更為簡(jiǎn)單的處理這種情況。

4.Graph圖結(jié)構(gòu)存儲(chǔ)

neo4j
用于社交網(wǎng)絡(luò)

圖形數(shù)據(jù)庫(kù)非常適合表示網(wǎng)絡(luò)實(shí)體連接等問(wèn)題。評(píng)估圖形數(shù)據(jù)庫(kù)有效性的一種方法是確定實(shí)例和實(shí)例間是否存在關(guān)系。

分類	相關(guān)產(chǎn)品	數(shù)據(jù)模型	典型應(yīng)用	優(yōu)點(diǎn)	缺點(diǎn)
鍵值數(shù)據(jù)庫(kù)（Key-Value Database)	Redis、Riak、SimplDB、Chordless、Scalaris、Memcached	鍵/值對(duì)	內(nèi)容緩存，如會(huì)話、配置文件、參數(shù)、購(gòu)物車等	擴(kuò)展性好、靈活性好、大量寫(xiě)操作時(shí)性能高	無(wú)法存儲(chǔ)結(jié)構(gòu)化信息、條件查詢效率較低
列族數(shù)據(jù)庫(kù)	BigTable、Hbase、Cassandra、HadoopDB、GreenPlum、PNUTS	列族	分布式數(shù)據(jù)存儲(chǔ)與管理	查找速度快、可擴(kuò)展性強(qiáng)、容易進(jìn)行分布式擴(kuò)展、復(fù)雜性低	功能較少，大都不支持強(qiáng)事物一致性
文檔數(shù)據(jù)庫(kù)	CouchDB、MongoDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit	版本化的文檔	存儲(chǔ)、索引并管理面向文檔的數(shù)據(jù)或者類似的半結(jié)構(gòu)化數(shù)據(jù)	性能好、靈活性高、復(fù)雜性低、數(shù)據(jù)結(jié)構(gòu)靈活	缺乏統(tǒng)一的查詢語(yǔ)法
圖數(shù)據(jù)庫(kù)	Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB	圖結(jié)構(gòu)	應(yīng)用于大量復(fù)雜、互連接、低結(jié)構(gòu)化的圖結(jié)構(gòu)場(chǎng)合，如社交網(wǎng)絡(luò)、推薦系統(tǒng)等	靈活性高、支持復(fù)雜的圖算法、可用于構(gòu)建復(fù)雜的關(guān)系圖譜	復(fù)雜性高、只能支持一定的數(shù)據(jù)規(guī)模

NOSQL的三大基石, 理解三大要點(diǎn)的準(zhǔn)確意義和內(nèi)容，要求全部掌握，并能用自己語(yǔ)言說(shuō)明

CAP

所謂的CAP指的是：

C（Consistency）：一致性，是指任何一個(gè)讀操作總是能夠讀到之前完成的寫(xiě)操作的結(jié)果，也就是在分布式環(huán)境中，多點(diǎn)的數(shù)據(jù)是一致的， 或者說(shuō)，所有節(jié)點(diǎn)在同一時(shí)間具有相同的數(shù)據(jù)

A:（Availability）：可用性，是指快速獲取數(shù)據(jù)，可以在確定的時(shí)間 內(nèi)返回操作結(jié)果，保證每個(gè)請(qǐng)求不管成功或者失敗都有響應(yīng)；

P（Tolerance of Network Partition）：分區(qū)容忍性，是指當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況時(shí)（即系統(tǒng)中的一部分節(jié)點(diǎn)無(wú)法和其他節(jié)點(diǎn)進(jìn)行通信），分離的系統(tǒng)也能夠正常運(yùn)行，也就是說(shuō)，系統(tǒng)中任意信息的丟失或失敗不會(huì)影響系統(tǒng)的繼續(xù)運(yùn)作。

CAP理論告訴我們，一個(gè)分布式系統(tǒng)不可能同時(shí)滿足一致性、可用性和分區(qū)容忍性這三個(gè)需求，最多只能同時(shí)滿足其中兩個(gè)，正所謂“魚(yú)和熊 掌不可兼得”

當(dāng)處理CAP的問(wèn)題時(shí)，可以有幾個(gè)明顯的選擇：

CA：也就是強(qiáng)調(diào)一致性（C）和可用性（A），放棄分區(qū)容忍性（P），最簡(jiǎn)單的做法是把所有與事務(wù)相關(guān)的內(nèi)容都放到同一臺(tái)機(jī)器上。很顯然，這種 做法會(huì)嚴(yán)重影響系統(tǒng)的可擴(kuò)展性。傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)（MySQL、SQL Server 和PostgreSQL），都采用了這種設(shè)計(jì)原則，因此，擴(kuò)展性都比較差
CP：也就是強(qiáng)調(diào)一致性（C）和分區(qū)容忍性（P），放棄可用性（A），當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況時(shí)，受影響的服務(wù)需要等待數(shù)據(jù)一致，因此在等待期間 就無(wú)法對(duì)外提供服務(wù)
AP：也就是強(qiáng)調(diào)可用性（A）和分區(qū)容忍性（P），放棄一致性（C），允許系統(tǒng)返回不一致的數(shù)據(jù)

BASE

ACID	BASE
原子性(Atomicity)	基本可用(Basically Available)
一致性(Consistency)	軟狀態(tài)/柔性事務(wù)(Soft state)
隔離性(Isolation)	最終一致性 (Eventual consistency)
持久性 (Durable)

一個(gè)數(shù)據(jù)庫(kù)事務(wù)具有ACID四性：

A（Atomicity）：原子性，是指事務(wù)必須是原子工作單元，對(duì)于其數(shù) 據(jù)修改，要么全都執(zhí)行，要么全都不執(zhí)行
C（Consistency）：一致性，是指事務(wù)在完成時(shí)，必須使所有的數(shù)據(jù) 都保持一致?tīng)顟B(tài)
I（Isolation）：隔離性，是指由并發(fā)事務(wù)所做的修改必須與任何其它 并發(fā)事務(wù)所做的修改隔離
D（Durability）：持久性，是指事務(wù)完成之后，它對(duì)于系統(tǒng)的影響是 永久性的，該修改即使出現(xiàn)致命的系統(tǒng)故障也將一直保持

BASE的基本含義是基本可用（Basically Availble）、軟狀態(tài)（Softstate）和最終一致性（Eventual consistency）：

基本可用：基本可用，是指一個(gè)分布式系統(tǒng)的一部分發(fā)生問(wèn)題變得不可用時(shí)，其 他部分仍然可以正常使用，也就是允許分區(qū)失敗的情形出現(xiàn)
軟狀態(tài)： “軟狀態(tài)（soft-state）”是與“硬狀態(tài)（hard-state）”相對(duì)應(yīng)的一種提法。數(shù)據(jù)庫(kù)保存的數(shù)據(jù)是“硬狀態(tài)”時(shí)，可以保證數(shù)據(jù)一致性，即保證數(shù)據(jù)一直是正確的。“軟狀態(tài)”是指狀態(tài)可以有一段時(shí)間不同 步，具有一定的滯后性

最終一致性

? 一致性的類型包括強(qiáng)一致性和弱一致性，二者的主要區(qū)別在于高并發(fā)的數(shù)據(jù)訪問(wèn)操作下，后續(xù)操作是否能夠獲取最新的數(shù)據(jù)。對(duì)于強(qiáng)一致性而言，當(dāng)執(zhí)行完一次更新操作后，后續(xù)的其他讀操作就可以保證讀到更新后的最新數(shù)據(jù)；反之，如果不能保證后續(xù)訪問(wèn)讀到的都是更新后的最新數(shù)據(jù)，那么就是弱一致性。而最終一致性只不過(guò)是弱一致性的一種特例，允許后續(xù)的訪問(wèn)操作可以暫時(shí)讀不到更 新后的數(shù)據(jù)，但是經(jīng)過(guò)一段時(shí)間之后，必須最終讀到更新后的數(shù)據(jù)。最常見(jiàn)的實(shí)現(xiàn)最終一致性的系統(tǒng)是DNS（域名系統(tǒng)）。一個(gè)域名更新操作根據(jù)配置的形式被分發(fā)出去，并結(jié)合有過(guò)期機(jī)制的緩存；最終所有的客戶端可以看到 最新的值。

最終一致性根據(jù)更新數(shù)據(jù)后各進(jìn)程訪問(wèn)到數(shù)據(jù)的時(shí)間和方式的不同， 又可以區(qū)分為：

因果一致性：如果進(jìn)程A通知進(jìn)程B它已更新了一個(gè)數(shù)據(jù)項(xiàng)，那么進(jìn)程B 的后續(xù)訪問(wèn)將獲得A寫(xiě)入的最新值。而與進(jìn)程A無(wú)因果關(guān)系的進(jìn)程C的訪問(wèn) ，仍然遵守一般的最終一致性規(guī)則
“讀己之所寫(xiě)”一致性：可以視為因果一致性的一個(gè)特例。當(dāng)進(jìn)程A自己執(zhí)行一個(gè)更新操作之后，它自己總是可以訪問(wèn)到更新過(guò)的值，絕不會(huì)看 到舊值
單調(diào)讀一致性：如果進(jìn)程已經(jīng)看到過(guò)數(shù)據(jù)對(duì)象的某個(gè)值，那么任何后續(xù) 訪問(wèn)都不會(huì)返回在那個(gè)值之前的值
會(huì)話一致性：它把訪問(wèn)存儲(chǔ)系統(tǒng)的進(jìn)程放到會(huì)話（session）的上下文中，只要會(huì)話還存在，系統(tǒng)就保證“讀己之所寫(xiě)”一致性。如果由于某些失敗情形令會(huì)話終止，就要建立新的會(huì)話，而且系統(tǒng)保證不會(huì)延續(xù)到新的會(huì)話
單調(diào)寫(xiě)一致性：系統(tǒng)保證來(lái)自同一個(gè)進(jìn)程的寫(xiě)操作順序執(zhí)行。系統(tǒng)必須 保證這種程度的一致性，否則就非常難以編程了

第六章

云數(shù)據(jù)庫(kù)的概念

云數(shù)據(jù)庫(kù)是部署和虛擬化在云計(jì)算環(huán)境中的數(shù)據(jù)庫(kù)。云數(shù)據(jù)庫(kù)是在云計(jì)算的大背景下發(fā)展起來(lái)的一種新興的共享基礎(chǔ)架構(gòu)的方法，它極大地增強(qiáng)了數(shù)據(jù)庫(kù)的存儲(chǔ)能力，消除了人員、硬件、軟件的重復(fù)配置，讓軟、硬件升級(jí)變得更加容易。

云數(shù)據(jù)庫(kù)的特性

（1）動(dòng)態(tài)可擴(kuò)展

（2）高可用性

（3）較低的使用代價(jià)

（4）易用性

（5）高性能

（6）免維護(hù)

（7）安全

第七-八章

MapReduce基本概念與“計(jì)算向數(shù)據(jù)靠攏”

基本概念：

? MapReduce采用“分而治之”策略，一個(gè)存儲(chǔ)在分布式文件系統(tǒng)中的大規(guī)模數(shù)據(jù)集，會(huì)被切分成許多獨(dú)立的 分片（split），這些分片可以被多個(gè)Map任務(wù)并行處理 。

“計(jì)算向數(shù)據(jù)靠攏”：

? MapReduce設(shè)計(jì)的一個(gè)理念就是“計(jì)算向數(shù)據(jù)靠攏”，而不是“數(shù)據(jù)向計(jì)算靠攏”，因?yàn)椋苿?dòng)數(shù)據(jù)需要大量的 網(wǎng)絡(luò)傳輸開(kāi)銷

MapReduce工作流程 與各個(gè)執(zhí)行階段工作

MapReduce工作流程：

?

不同的Map任務(wù)之間不會(huì)進(jìn)行通信

不同的Reduce任務(wù)之間也不會(huì)發(fā)生任何信息交換

用戶不能顯式地從一臺(tái)機(jī)器向另一臺(tái)機(jī)器發(fā)送消息

所有的數(shù)據(jù)交換都是通過(guò)MapReduce框架自身去實(shí)現(xiàn)的

各個(gè)執(zhí)行階段工作：

MapReduce的WORDCOUNT執(zhí)行實(shí)例計(jì)算過(guò)程

（待補(bǔ)充）

MapReduce實(shí)現(xiàn)關(guān)系運(yùn)算

關(guān)系代數(shù)運(yùn)算（選擇、投影、并、交、差、連接）

分組與聚合運(yùn)算

矩陣-向量乘法

矩陣乘法

第九章

Spark與Hadoop的對(duì)比，SPARK高性能的原因

Spark的計(jì)算模式也屬于MapReduce，但不局限于Map和Reduce操作，還提供了多種數(shù)據(jù)集操作類型，編程模型比Hadoop MapReduce更靈活
Spark提供了內(nèi)存計(jì)算，可將中間結(jié)果放到內(nèi)存中，對(duì)于迭代運(yùn)算效率更高
Spark基于DAG的任務(wù)調(diào)度執(zhí)行機(jī)制，要優(yōu)于Hadoop MapReduce的迭代執(zhí)行機(jī)制
使用Hadoop進(jìn)行迭代計(jì)算非常耗資源，Spark將數(shù)據(jù)載入內(nèi)存后，之后的迭代計(jì)算都可以直接使用內(nèi)存中的中間結(jié)果作運(yùn)算，避免了從磁盤(pán)中頻繁讀取數(shù)據(jù)

大數(shù)據(jù)處理的三種類型與其適用的Spark技術(shù)棧

在實(shí)際應(yīng)用中，大數(shù)據(jù)處理主要包括以下三個(gè)類型：

復(fù)雜的批量數(shù)據(jù)處理：通常時(shí)間跨度在數(shù)十分鐘到數(shù)小時(shí)之間
基于歷史數(shù)據(jù)的交互式查詢：通常時(shí)間跨度在數(shù)十秒到數(shù)分鐘之間
基于實(shí)時(shí)數(shù)據(jù)流的數(shù)據(jù)處理：通常時(shí)間跨度在數(shù)百毫秒到數(shù)秒之間

應(yīng)用場(chǎng)景	時(shí)間跨度	其他框架	Spark生態(tài)系統(tǒng)中的組件
復(fù)雜的批量數(shù)據(jù)處理	小時(shí)級(jí)	MapReduce、Hive	Spark Core
基于歷史數(shù)據(jù)的交互式查詢	分鐘級(jí)、秒級(jí)	Impala、Dremel、 Drill	Spark SQL
基于實(shí)時(shí)數(shù)據(jù)流的數(shù)據(jù)處理	毫秒、秒級(jí)	Storm、S4	Spark Streaming

RDD的設(shè)計(jì)與運(yùn)行原理（所有概念需要能夠理解其內(nèi)容與思想，并用自己語(yǔ)言說(shuō)明）

（待補(bǔ)充）

第十章

流數(shù)據(jù)的特征

數(shù)據(jù)快速持續(xù)到達(dá)，潛在大小也許是無(wú)窮無(wú)盡的
數(shù)據(jù)來(lái)源眾多，格式復(fù)雜
數(shù)據(jù)量大，但是不十分關(guān)注存儲(chǔ)，一旦數(shù)據(jù)中的某個(gè)元素經(jīng)過(guò)處理，要么被丟棄，要么要?dú)w檔處理
注重?cái)?shù)據(jù)的整體價(jià)值，不過(guò)分關(guān)注個(gè)別數(shù)據(jù)
數(shù)據(jù)順序顛倒，或者不完整，系統(tǒng)無(wú)法控制將要處理的新到達(dá)的數(shù)據(jù)元素的順序

批量計(jì)算與實(shí)時(shí)計(jì)算的含義

批量計(jì)算以“靜態(tài)數(shù)據(jù)”為對(duì)象，可以在很充裕的時(shí)間內(nèi)對(duì)海量數(shù)據(jù)進(jìn)行批量處理，計(jì)算得到有價(jià)值的信息。

實(shí)時(shí)計(jì)算最重要的一個(gè)需求是能夠?qū)崟r(shí)得到計(jì)算結(jié)果，一般要求響應(yīng)時(shí)間為秒級(jí)。

流數(shù)據(jù)必須采用實(shí)時(shí)計(jì)算，響應(yīng)時(shí)間為秒級(jí)

流計(jì)算的要求，Hadoop不適用于流計(jì)算的原因

對(duì)于一個(gè)流計(jì)算系統(tǒng)來(lái)說(shuō)，它應(yīng)達(dá)到如下需求：

高性能。處理大數(shù)據(jù)的基本要求，如每秒處理幾十萬(wàn)條數(shù)據(jù)。
海量式。支持TB級(jí)甚至是PB級(jí)的數(shù)據(jù)規(guī)模。
實(shí)時(shí)性。必須保證一個(gè)較低的延遲時(shí)間，達(dá)到秒級(jí)別，甚至是毫秒級(jí)別。
分布式。支持大數(shù)據(jù)的基本架構(gòu)，必須能夠平滑擴(kuò)展。
易用性。能夠快速進(jìn)行開(kāi)發(fā)和部署。
可靠性。能可靠地處理流數(shù)據(jù)。

Hadoop不適用于流計(jì)算的原因：

切分成小的片段，雖然可以降低延遲，但是也增加了任務(wù)處理的附加開(kāi)銷，而且還要處理片段之間的依賴關(guān)系，因?yàn)橐粋€(gè)片段可能需要用到前一個(gè)片段的計(jì)算結(jié)果
需要對(duì)MapReduce進(jìn)行改造以支持流式處理，Reduce階段的結(jié)果不能直接輸出，而是保存在內(nèi)存中。這種做法會(huì)大大增加MapReduce框架的復(fù)雜度，導(dǎo)致系統(tǒng)難以維護(hù)和擴(kuò)展。
降低了用戶程序的可伸縮性，因?yàn)橛脩舯仨氁褂肕apReduce接口來(lái)定義流式作業(yè)

流計(jì)算處理流程

總結(jié)

以上是生活随笔為你收集整理的大数据基础整合的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。