原創不易，未經允許，請勿轉載，

博客主頁：https://xiaojujiang.blog.csdn.net/

本復習提綱只適用于JMU軟體工程大資料課程

第一章

1.1 大資料問題的定義和來源 P3-5

• 存盤設備容量不斷增加，（資訊存盤）
• CPU處理能力大幅提升，（資訊處理）
• 網路帶寬不斷增加，（資訊傳輸）

1.2 大資料問題的特點 P7-9

關于什么是大資料，大家比較認可大資料的”4V“說法，大資料的4個”V“，或者說大資料的四個特點，包括4個層面：

• 資料量大，
• 資料型別繁多，
• 處理速度快，
• 價值密度低，

1.3 大資料應用四大層面的關鍵技術 P15

• 資料采集與預處理：利用ETL工具將分布的、異構資料源中的資料，如關系資料、平面資料檔案等，抽取到臨時中間層后進行清洗、轉換、集成，最后加載到資料倉庫或資料集市中，成為聯機分析處理、資料挖掘的基礎;也可以利用日志采集工具(如 Flume、Kafka 等）把實時采集的資料作為流計算系統的輸人,進行實時處理分析，
• 資料存盤與管理：利用分布式檔案系統、資料倉庫、關系資料庫、NoSQL 資料庫、云資料庫等，實作對結構化、半結構化和非結構化海量資料的存盤和管理，
• 資料處理與分析：利用分布式并行編程模型和計算框架，結合機器學習和資料挖掘演算法,實作對海量資料的外理和分析；對分析結果進行可視化呈現，幫助人們更好地理解資料、分析資料，
• 資料安全和隱私保護：在從大資料中挖掘潛在的巨大商業價值和學術價值的同時,構建隱私資料保護體系和資料安全體系,有效保護個人隱私和資料安全

1.4 大資料四大計算模式：除圖計算外詳細了解 P16

1.5 云計算的概念，物聯網的概念，云計算與物聯網之間的關系 P18-19,21-22,26

1.5.1 云計算的概念

云計算實作了通過網路提供可伸縮的、廉價的分布式計算能力，用戶只需要在具備網路接入條件的地方，就可以隨時隨地獲得所需的各種IT資源，云計算代表了以虛擬化為核心、以低成本為目標的、動態可擴展的網路應用基礎設施，是近年最有代表性的網路計算計算與模式，

云計算包括3種典型的服務模式，即IaaS（基礎設施即服務），PaaS（平臺即服務）和SaaS（軟體即服務），IaaS醬基礎設施（計算資源和存盤）作為服務出租，PaaS把平臺作為服務出租，SaaS把軟體作為服務出租，

1.5.2 物聯網的概念

物聯網是物物相連的互聯網，是互聯網的延申，它利用區域網路或互聯網等通信技術把傳感器、控制器、機器、人員和物等通過新的方式連在一起，形成人與物、物與物相連，實作資訊化和遠程管理控制，

從技術架構上來看，物聯網可分為四層：感知層、網路層、處理層和應用層，物聯網各個層次的功能如下表：

### 1.5.3 云計算與物聯網之間的關系

大資料、云計算和物聯網的聯系，從敷體上看、大資料、云計算和物聯網這三者是相輔相成的，大資料根植于云計算，大資料分析的很多技術都來自于云計算，云計算的分布式資料存盤和管理系統(包括分布式檔案系統和分布式資料庫系統)提供了海量資料的存盤和管理能力,分布式并行處理框架 MapReduce提供了海量資料分析能力，沒有這些云計算技術作為支撐，大資料分析就無從談起，反之，大資料為云計算提供了“用武之地”,沒有大資料這個“練兵場”，云計算技術再先進,也不能發揮它的應用價值，物聯網的傳感器源源不斷產生的大量資料，構成了大資料的重要資料來源，沒有物聯網的飛速發展，就不會帶來資料產生方式的變革,即由人工產生階段轉向自動產生階段，大資料時代也不會這么快就到來，同時,物聯網需要借助于云計算利大資料技術,實作物聯網大資料的存盤、分析和處理，

第三章

3.1 HDFS的本質：分布式檔案系統

3.2 塊的概念和優勢P46

塊的概念：

在傳統的檔案系統中，為了提高磁盤讀寫效率，一般以資料塊為單位，而不是以位元組為單位，以塊為單位讀寫資料，可以把磁盤尋道時間分攤到大量資料中，

塊的優勢：

• 支持大規模檔案存盤，
• 簡化系統設計，
• 適合資料備份，

3.3 名稱節點和資料節點的定義P46-47

3.3.1 名稱節點的定義

稱節點（NameNode)負責管理分布式檔案系統的命名空間，保存了兩個核心的資料結構，即FsImage和EditLog，FsImage用于維護檔案系統樹以及檔案樹中所有的檔案和檔案夾的元資料，操作日志檔案EditLog記錄了所有針對檔案的創建、重命名等操作，名稱節點記錄了每個檔案中各個塊所在的資料節點為位置資訊（相當于一個資料目錄），但是并不持久化存盤這些資訊，而是在系統每次啟動時掃描所有資料節點重構得到這些資訊，

3.3.2 資料節點的定義

資料節點（DataNode）是分布式檔案系統HDFS的作業節點，負責資料的存盤和讀取，會根據客戶端或者名稱節點的調度來進行資料的存盤和檢索，并且向名稱節點定期發送自己所存盤的塊的串列，每個資料節點種的資料會被保存在各自節點的本地Linux檔案系統中，

3.4 第二名稱節點的意義和作業原理P47

3.4.1 第二名稱節點的意義

第二名稱節點是為了解決EditLog逐漸變大帶來的問題，

在名稱節點運行期間，HDFS會不斷發生更新操作，這些更新操作都是直接被寫入到EditLog檔案，因此 EditLog 檔案也會逐漸變大，在名稱節點運行期間，不斷變大的EditLog 檔案通常對于系統性能不會產生顯著影響，但是當名稱節點重啟時，需要將FsImage加載到記憶體中,然后逐條執行EditLog中的記錄，使得FsImage保持最新，可想而知，如果EditLog很大,就會導致整個程序變得非常緩慢,使得名稱節點在啟動程序中長期處于“安全模式”,無法正常對外提供寫操作，影響了用戶的使用，

3.4.2 作業原理

具體介紹翻書（P47-48）

3.5 冗余存盤的具體實作方法和優勢P50-51

3.5.1 具體實作方式

作為一個分布式檔案系統，為了保證系統的容錯性和可用性，HDFS采用了多副本方式對資料進行冗余存盤，通常一個資料塊的多個副本會被分布到不同的資料節點上，

3.5.2 優勢

• 加快資料傳輸速度，
• 容易檢查資料錯誤，
• 保證資料可靠性，

3.6 資料存放策略和原因P51

3.6.1 策略

為了提高資料的可靠性于系統的可用性，以及充分利用網路帶寬，HDFS采用了以機架（Rack）為基礎的資料存放策略，一個HDFS集群通常包含多個機架，不同機架之間的資料通信需要經過交換機或路由器，同一個機架不同機器之間的通信則不需要通過交換機和路由器，這意味著同一個機架中的不同機器之間的通信要比不同機架之間的通信帶寬大，

3.6.2 原因

首先，可以獲得很高的資料可靠性，即使一個機架發生故障，位于其他機架上的資料副本仍然可用的，其次，在讀取資料的時候，可以在多個機架上并行的處理資料，大大提高了資料讀取速度；最后，可以更容易地實作系統內部負載均衡和錯誤處理，

3.7 資料讀取與復制P52

3.7.1 資料讀取

HDFS提供了一個API可以確定一個資料節點所屬地機架ID，客戶端也可以呼叫API獲取自己所屬地機架ID，當客戶端讀取資料時，從名稱節點獲得資料塊不同副本地存放位置串列，串列中包含了副本所在的資料節點，可以呼叫API來確定客戶端和這些資料節點所屬的機架ID，當發現某個資料塊副本對應的機架ID和客戶端對用的機架ID相同時，就優先選擇該副本讀取資料，如果沒有發現，就隨機選擇一個副本讀取資料，

3.7.2 資料復制

HDFS的資料復制采用了流水線復制的策略，大大提高了資料復制程序的效率，

3.8 HDFS中三種可能的錯誤和恢復方法 P52

• 名稱節點出錯：

  第一，把名稱節點上的元資料資訊同步存盤到其他檔案系統中；第二，運行一個第二名稱節點，當名稱節點宕機以后，可以把第二名稱節點作為一種彌補措施，利用第二名稱節點的元資料資訊進行系統恢復，但是從前面對第二名稱節點的介紹中可以看出，這樣做仍然會丟失部分資料，因此，一般會把上述兩種方法結合使用，當名稱節點發生宕機時，首先到遠程掛載的網路檔案系統中獲取備份的元資料資訊，放到第二名稱節點上進行恢復，并把第二名稱節點作為名稱節點來使用，

• 資料節點出錯：

  ? 每個資料節點會定期向名稱節點發送“心跳”資訊，向名稱節點報告自己的狀態，當資料節點發生故障，或者網路發生斷網時，名稱節點就無法收到來自一些資料節點的“心跳”資訊，這時這些資料節點就會被標記為“宕機”,節點上面的所有資料都會被標記為“不可讀”，名稱節點不會再給它們發送任何IO請求，這時，有可能出現一種情形，即由于一些資料節點的不可用，會導致一些資料塊的副本數量小于冗余因子，名稱節點會定期檢查這種情況，一旦發現某個資料塊的副本數量小于冗余因子，就會啟動資料冗余復制，為它生成新的副本，HDFS 與其他分布式檔案系統的最大區別就是可以調整冗余資料的位置，

• 資料出錯：

  資料校驗出錯，客戶端會請求另外一個資料節點讀取改資料塊，并且向名稱節點報告這個檔案塊有錯誤，名稱節點會定期檢查并重新復制這個塊，

第四章

4.1 HBASE與傳統資料庫的對比 P64-65

HBase與傳統的關系資料庫區別主要體現在以下幾個方面：

• 資料型別， 關系資料庫采用關系模型，具有豐富的資料型別和存盤方式，HBase采用更簡單的資料模型，它把資料存盤為未經解釋的字串，用戶可以把不同格式的結構化資料和非結構化資料都序列化成字符粗保存到HBase中，用戶需要自己撰寫程式把字符粗決議成不同的資料型別，
• 資料操作， 關系資料庫中包含了豐富的操作，如插入、洗掉、更新、查詢等，其中會涉及到多表連接，通常是借助于多個表之間的主外鍵關聯來實作的，HBase操作則不存在復雜的表與表之間的關系，只有簡單的插入、查詢、洗掉、清空等（，因為HBase在設計上就避免了復雜的表與表之間的關系，通常只采用單表的主鍵查詢，所以它無法實作像關系資料庫中那樣的表與表之間的連接操作，
• 存盤模式，關系資料庫基于行模式存盤，元組或行會被連續地存盤在磁盤頁中，HBase基于列存盤，每個列族都有幾個檔案保存，不同列族的檔案是分離的，
• 資料索引，關系資料庫通常可以針對不同列構建復雜的多個索引以提高資料訪問性能，HBase只有一個索引——行鍵，
• 資料維護，在關系資料庫中，更新操作會用最新的當前值去替換記錄中掉原來的值，舊值被覆寫后就不會存在，而HBase的更新操作時，并不會洗掉資料舊的版本，而是生產一個新的版本，舊的版本仍然保留，
• 可伸縮性，關系資料庫很難實作橫向擴展,縱向擴展的空間也比較有限，相反，HBase和BigTable這些分布式資料庫就是為了實作靈活的水平擴展而開發的,因此能夠輕易地通過在集群中增加或者減少硬體數量來實作性能的伸縮，

4.2 HBASE的資料模型概念、資料坐標P66-68

4.2.1 資料模型概念

• 表：HBase采用表來組織資料，表由行和列組成，列分為若干個列族，

• 行：HBase 表中的每行資料都由一個 RowKey 和多個 Column（列）組成，資料是按照 RowKey

  的字典順序存盤的，并且查詢資料時只能根據 RowKey 進行檢索，所以 RowKey 的設計十分重

  要，

• 列族：HBase 中的每個列都由 Column Family(列族)和 Column Qualifier（列限定符）進行限

  定，例如 info：name，info：age，建表時，只需指明列族，而列限定符無需預先定義，

• 單元格：由{rowkey, column Family：column Qualifier, time Stamp} 唯一確定的單元，cell 中的數

  據是沒有型別的，全部是位元組碼形式存貯，

• 時間戳：用于標識資料的不同版本（version），每條資料寫入時，如果不指定時間戳，系統會

  自動為其加上該欄位，其值為寫入 HBase 的時間，

4.2.2 資料作標

對于我們熟悉的關系資料塊而言，資料定位可以理解為采用”二維坐標“，即根據行和列就可以確定表中一個確定的值，HBase中需要根據行鍵、列族、列限定符和時間戳來確定一個單格，即四維坐標{行鍵，列族，列限定符，時間戳}

4.3 HBASE列式存盤的基本模型 P70 圖4-4

http://c.biancheng.net/view/3586.html

4.4 HBASE的三層結構 P73

4.5 HBASE的系統結構與客戶端、Zookeeper服務器、Master服務器、Region服務器功能P74-75

• 客戶端

  客戶端包含訪問HBase的介面，同時快取中維護著已經訪問過的Region資訊，用來加快后續資料訪問程序，

• Region服務器

  Region Server 為 Region 的管理者，其實作類為 HRegionServer，主要作用如下:

  對于資料的操作：get, put, delete；

  對于 Region 的操作：splitRegion、compactRegion，

• Master

  Master 是所有 Region Server 的管理者，其實作類為 HMaster，主要作用如下：

  對于表的操作：create, delete, alter

  對于 RegionServer的操作：分配 regions到每個RegionServer，監控每個 RegionServer

  的狀態，負載均衡和故障轉移，

• Zookeeper

  HBase 通過 Zookeeper 來做 Master 的高可用、RegionServer 的監控、元資料的入口以及

  集群配置的維護等作業，

第五章

5.1 NoSQL資料庫三大特點 P94-95

• 靈活的可拓展性
• 靈活的資料模型
• 與云計算緊密融合

5.2 關系型資料庫不滿足Web2.0應用的三大原因 P96

• Web2.0網站系統通常不要求嚴格的資料庫事務
• Web2.0并不要求嚴格的讀寫實時性
• Web2.0通常不包含大量復雜的SQL查詢

5.3 四大型別NOSQL資料庫名稱與特點P99-101

• 鍵值資料庫
• 列族資料庫
• 檔案資料庫
• 圖資料庫

5.4 NoSQL三大基石：CAP的定義，CAP三種選擇兩種的實作方法P102-103

• C（Consistenct）:一致性，它是指任何一個讀操作總是能夠讀到之前完成的寫操作的結果，也就是分布式環境中，多點資料是一致的，
• A（Availability) :可用性，它是指快速獲取資料，可以在確定的時間內回傳結果，
• P（Tolerance of Network Partition):磁區容忍性，它是指當出現網路磁區的情況時，分離的系統也能夠正常運行，

5.4.1 CAP三種選兩種

• CA：也就是強調一致性?和可用性（A)，放棄磁區容忍性§,最簡單的做法是把所有與事務相關的內容都放到同一臺機器上，很顯然，這種做法會嚴重影響系統的可擴展性，傳統的關系資料庫(MySQL、SQL Server 和 PostgreSQL)都采用了這種設計原則,因此擴展性都比較差，
• CP：也就是強調一致性(C）和磁區容忍性§，放棄可用性（A),當出現網路磁區的情況時,受影響的服務需要等待資料一致,因此在等待期間就無法對外提供服務，Neo4J、BigTable和 HBase等NoSQL 資料庫都采用了CP設計原則，
• AP：也就是強調可用性(A)和磁區容忍性§，放棄一致性?,允許系統回傳不一致的資料，這對于許多Web 2.0網站而言是可行的，這些網站的用戶首先關注的是網站服務是否可用,當用戶需要發布一條微博時，必須能夠立即發布，否則，用戶就會放棄使用，但是這條微博發布后什么時候能夠被其他用戶讀取到,則不是非常重要的問題，不會影響到用戶體驗，因此，對于Web 2.0網站而言,可用性與磁區容忍性優先級要高于資料一致性,網站一般會盡量朝著AP的方向設計，當然,在采用AP設計時,也可以不完全放棄一致性,轉而采用最終一致性，Dynamo、Riak、CouchDB、Cassandra 等NoSQL 資料庫就采用了AP設計原則，

5.5 NoSQL四大特性：BASE定義 P104

• 基本可用

  基本可用是指一個分布式系統的一部分發生問題變得不可用時，其他部分仍然可以正常使用，也就是允許磁區失敗的情形出現，

• 軟狀態

  “軟狀態”是與“硬狀態”相對應的一種提法，資料庫保存的資料是“硬狀態”時，可以保證資料的一致性，即保證資料一直是正確的，“軟狀態”是指狀態可以有一段時間不同步，具有一定的滯后性，

• 最終一致性

  一致性的型別包括強一致性和弱一致性，二者的主要區別在于高并發的資料訪問操作下，后續操作是否能夠獲取最新資料，

第七章

7.1 Map與Reduce的基本定義P133表7-1

?

7.2 MapReduce基本作業流程 P134

7.3 使用combiner與不使用combiner時的MapReduce執行Wordcount的基本流圖 P141-142 圖7-7、8、9

?

7. 4 使用MapReduce進行自然連接運算流程 P143

第九章

9.1 Spark相比Hadoop的核心優勢，核心優勢的實作方法P174

• Spark的計算模式也屬于MapReduce，但不限于Map和Reduce操作，還提供了多種資料集操作型別，編程模型比MapReduce更靈活，
• Spark提供了記憶體計算，中間結果直接存放到記憶體中，帶來了更高的迭代運算效率，
• Spark基于DAG的任務調度執行機制，要優于MapReduce的迭代執行機制，

9.2 RDD轉換操作、行動操作、惰性呼叫與DAG構建 P180

9.3 常用RDD API P188表9-2 9-3

9.4 Spark面向不同功能的組件 P176

• Spark Core

  Spark Core包含了Spark基本功能,如記憶體計算、任務調度、部署模式、故障恢復、存盤管理等,主要面對批資料處理場景，Spark建立在統一的抽象RDD之上，使其可以以基本一致的方式應對不同的大資料處理場景，

• Spark SQL

  Spark SQL允許開發人員直接處理RDD，同時也可查詢Hive、HBase等外部資料源，Spark SQL的一個重要特點是其能夠統一處理關系表和RDD，使得開發人員不需要自己撰寫Spark應用程式，開發人員可以輕松使用你SQL命令進行查詢，并進行更復雜的資料分析，

• Spark Streaming

  Spark Streaming支持高吞吐量、可容錯處理的實時流資料處理，其核心思路是將流資料分解成一系列短小的批處理作業，每個短小的批處理作業都可以使用Spark Core進行快速處理，Spark Streaming支持多種資料輸入源，如Kafka、Flume和TCP套接字等，

• MLlib（機器學習）

  MLlib提供了常用機器學習演算法的實作，包括聚類、分類、回歸、協同過濾等，降低了機器學習的門檻，開發人員只需要具備一定的理論知識就能進行機器學習作業，

• GraphX（圖計算）

  GraphX是Spark中用于圖計算的API，可認為是Pregel在Spark上的重寫優化，GraphX性能良好，擁有豐富的功能和運算子，能在海量資料上自如地運行復雜地圖演算法，

第十章

10.1 流資料的特點P195

• 資料快速持續到達，潛在大小也許是無窮無盡地，
• 資料來源眾多，格式復雜，
• 資料量大，但是不十分關注存盤，一旦流資料中的某個元素經過處理，要么被丟棄，要么被歸檔存盤，
• 注重資料的整體價值，不過分關注個別資料，
• 資料順序顛倒，或者不完整，系統無法控制將要處理的新到達的資料元素順序，

10.2 靜態資料分析與流資料處理的不同（批處理與流計算）P199

• 流處理系統處理的是實時的資料，而傳統的資料處理系統處理的是預先存盤好的靜態資料，
• 用戶通過流處理系統獲取的是實時結果，而通過傳統的資料處理系統獲取的是過去某一時刻的結果，并且，流處理系統，無需用戶主動發出查詢，實時查詢服務可以主動將實時結果推送給用戶，

10.3 流計算的概念，MapReduce為什么不適用于流計算

10.3.1 流計算的概念

流計算平臺實時獲取來自不同資料源的海量資料，經過實時分析處理，獲得有價值的資訊，

10.3.2 MapReduce為什么不適用于流計算

MapReduce是專門面向靜態資料的批量處理的，內部各種實作機制都是為批處理做了高度優化，不適用于處理持續到達的動態資料，

10.4 流計算的資料處理流程 P198

包含三個階段：資料實時采集、資料實時計算、實時查詢服務

10.5 Storm的基本設計思想 （Spouts Bolts Topology）P202

• Spouts

  Storm認為每個Stream都有一個源頭，并把這個源頭抽象為Sputs，Spouts會從外部讀取流資料并持續發出Tuple，
  

• Bolts

  Storm將Stream的狀態轉換程序抽象為Bolts，Bolts既可以處理Tuple，也可以將處理后的Tuple作為新的Streams發送給其他Bolts，對Tuple的處理邏輯都被封裝到Bolts中，可執行過濾、聚合、查詢等操作，

• Topology

  Storm將Spouts 和 Bolts組成的網路抽像成Topology，Topology是Storm中高層次的抽象概念，它可以被提交到Storm集群執行，一個Topology就是一個流轉換圖，圖中節點就是一個Spout活Bolt，圖中的邊則表示Bolt訂閱了哪個Stream，當Spout或者Bolt發送元組時，它會把元組發送到每個訂閱了該Stream的Bolt上進行處理，

10.6 Spark Streaming的基本設計思想 P207

拒絕白嫖從一鍵三連開始！

原創不易，未經允許，請勿轉載，

博客主頁：https://xiaojujiang.blog.csdn.net/