桂林電子科技大學 大數據課程 復習筆記
考試范圍：
教材:《大數據技術原理與應用》第三版 林子雨
第1章：大數據概述 🎉
第2章：大數據處理架構Hadoop 🎉
第3章：分布式文件系統HDFS 🎉
第4章：分布式數據庫HBase🎉
第5章：NoSQL數據庫🎉
第7章：MapReduce🎉
第10章：Spark🎉
第11章：流計算(Storm)🎉

第1章 大數據概述

重要知識點：
1、大數據的4V
數據量大：在Web2.0時代、網絡用戶數目極大，在視頻、照片社交軟件火熱的今天，用戶產生的數據量非常大。
數據類型繁多：有金融大數據、醫療大數據、城市大數據等等。
處理速度快：1分鐘，新浪微博產生2萬條微博，Twitter產生10萬條推文。
價值密度低：例如監控視頻的存儲，沒有調取監控視頻用時可能價值并沒有體現，但在使用時可能會產生很大的價值。

2、大數據的應用
智能汽車、能源、體育與娛樂等等、大數據應用非常廣泛。

3、大數據關鍵技術
數據采集與預處理、數據存儲和管理（HDFS）、數據處理與分析（如MapReduce）、數據安全和隱私保護。

4、大數據計算模式
批處理計算：對大規模數據的批量處理 （MapReduce、Spark）
流計算：針對流數據的實時計算(Spark)
圖計算：針對大規模圖結構的數據的處理
查詢分析計算：大規模數據的存儲管理和查詢分析（Hive）

5、大數據與云計算、物聯網的關系

云計算為大數據提供技術基礎、大數據為云計算提供用武之地。
物聯網是大數據的重要來源、大數據技術為物聯網數據分析提供支撐。
云計算為物聯網提供海量數據存儲能力，物聯網為云計算技術提供了廣闊的應用控件。

第2章 大數據處理架構Hadoop

1、Hadoop的核心
HDFS是分布式文件存儲系統(Hadoop Distributed File System) 、也是Hadoop的核心。

2、Hadoop的特性
高可靠性 、高效性、高可擴展性 、高容錯性 、成本低 、支持操作系統與編程語言廣泛

3、HDFS常用命令
創建文件夾(-p 遞歸創建) hadoop fs -mkdir -p /user/hadop
顯示文件內容 hadoop fs -cat hdfs文件
文件上傳 hadoop fs -put 本地 hdfs文件
刪除文件夾 hadoop fs -rm -r hdfs文件夾
刪除文件 hadoop fs -rm hdfs文件
切換目錄：cd
查看文件與目錄：ls -R(-R在hdfs為遞歸查看)
刪除空目錄：rmdir
復制文件或目錄：cp
裁剪:mv
創建文件:touchz
拉取文件 get

第3章 分布式系統 HDFS

1、 HDFS計算機集群結構
分布式文件系統把文件分布存儲到多個計算機節點上、成千上萬的計算機節點構成計算機集群。

2、 HDFS的結構
一個默認塊大小為64MB,如果一個文件小于一個數據塊的大小，在分布式文件系統，它并不占用整個數據塊的存儲空間。
名稱節點負責文件和目錄的創建、刪除、和重命名等，同時管理著數據節點和文件快的映射關系。
數據節點負責數據的存儲和讀取，在存儲時，由名稱節點分配存儲文職，客戶端將數據直接寫入相應數據節點。
為了保證數據的完整性，文件塊會被賦值為多個副本存儲到多個不同的節點上，而存儲同一文件塊的不同副本又會分布在不同的機架上。

3、 HDFS特點
優點：
兼容廉價的設備硬件。
流數據讀寫：支持流式方式來訪問文件。
大數據集：單個文件可達到GB甚至TB級別
簡單的文件模型：一次寫入，多次讀取。
強大的跨平臺兼容性。
缺點：
不適合低延遲數據訪問。
無法高效存儲大量小文件。
不支持多用戶寫入及任意修改文件。

4、 HDFS的相關概念（重點）
重點：塊、名稱節點和數據節點與第二名稱節點。
塊：HDFS文件塊的大小默認為64MB，一個文件會被拆分為多個塊進行存儲。(相關知識點:MapReduce中的Map任務一次只能處理一塊中的數據。)
采用塊抽象化的好處：支持大規模文件存儲、簡化系統設計、設和數據備份。
名稱節點負責管理分布式文件系統的命名空間，保存了FsImage和EditLog.
FsImage用于維護文件系統樹以及文件樹中所有的文件和問價夾的元數據。
EditLog(操作日志文件)記錄了所有針對文件的創建、刪除、重命名、等操作。
名稱節點存儲文件名與文件在數據節點中的位置的映射關系、但并不是持久化存儲在名稱節點，而是當名稱節點啟動時掃描分布式文件系統得到的。
名稱節點啟動?將FsImage加載到內存-> 重新執行EditLog->建立新的空FsImage和EditLog->工作記錄時使用新的FsImage和EditLog當變大后系統寫入到總的FsImage和EditLog內（工作模式請看第二名稱節點）

數據節點 負責數據的存儲和讀取，根據客戶端和名稱節點的調度進行數據的存儲和檢索。也會定時向名稱節點匯報自己的存儲塊列表信息。

第二名稱節點：
功能：完成FsImage和EditLog的合并操作，減小EditLog文件大小。
EditLog和FsImage的合并操作：

5、 HDFS體系結構
主從結構
客戶端向名稱節點請求文件名或者數據塊號，名稱節點將數據塊號、數據塊位置發送至客戶端。
客戶端與數據節點通信進行數據的讀寫操作。HDFS集群只有一個名稱節點，其帶寬、計算性能會影響整個系統的性能。

HDFS命名空間管理
HDFS集群只有一個命名空間,即/ some/some /some /some… ,向Linux的文件目錄結構一樣。

通信協議
HDFS通信協議建立在TCP/IP基礎之上。
名稱節點與數據節點采用數據節點協議進行交互。
客戶端與數據節點交互通過遠程過程調用(RPC)

HDFS體系結構局限性
命名空間限制、性能瓶頸(原因靠名稱節點)、隔離問題（一個命名空間、和一個名稱節點無法做到讀寫權限分配等）、集群可用性(一個名稱節點)

6、 HDFS的存儲原理
多副本冗余存儲，加快了數據傳輸的速率、容易檢查數據錯誤、保證數據的可靠性。

存放策略
HDFS默認的冗余復制因子是3，每一個文件塊被保存到3個地方。
（1） 如果是集群內發起的寫操作，則把第1個副本放置發起寫操作請求的數據節點上，實現就近寫入數據，如果集群外發起寫操作，則在集群內選一個磁盤空間充足且CPU不太忙的數據節點，做為第1個副本的存放位置。
（2） 第2個副本被放置在與第1個副本不同的機架的數據節點上。
（3） 第3個副本會被放置在與第1個副本相同的機架的其他節點上。
（4） 如果還有更多的副本、則繼續從集群中隨機選擇數據節點進行存放。

讀取策略
客戶端請求名稱節點獲取文件塊不同副本的存儲位置，由客戶端確定從哪里獲取文件塊。

數據復制
文件在客戶端被切分成多個塊，名稱節點返回數據節點列表。
客戶端向一個數據節點寫入，同時把數據節點列表傳給第一個數據節點，當第一個節點接收數據大小4KB時并像列表第二個數據接待你發起寫請求，將數據寫入第二個數據節點、當第二個數據節點接收到4KB時向第三個數據節點執行類似操作。最后當文件寫完時，數據的復制也同時完成了。

名稱節點出錯補救方案
一：遠程掛載到NFS上
二:運行一個第二名稱節點，能夠進行有限的補救(第二名稱節點中由FsImage和EditLog),但還是會可能遺失拉去FsImage和EditLog后，名稱節點的一系列操作。
數據節點出錯補救方案
數據節點定期向名稱節點發起”心跳“，沒有”心跳”時，名稱節點不再向其分配讀寫任務，且一旦發現某些塊的復制因子小了，名稱節點又會安排任務，進行文件塊復制。
數據出錯
客戶端采用MD5和SHA-1校驗，出錯將向名稱節點匯報，請求其他副本，名稱節點也會定期檢查塊。

第4章 分布式數據庫HBase

1、HBase是什么?
一個高可靠、高性能、面向列、可伸縮的分布式數據庫。
2、HBase與Hadoop其他部分關系。
使用MapReduce處理海量數據，ZooKeeper作為協同服務。HDFS底層數據存儲。Pig和Hive提供高級語言支持。
3、HBase與傳統數據庫對比。
數據類型：采用未經解釋的字符串。
數據操作：行鍵查詢、只有簡單的插入、查詢、刪除、清空等。
存儲模式：列式存儲。
數據索引：行鍵索引。
數據維護：并不刪除原來的數據。
橫向可伸縮性：面向列存儲。
缺陷：不支持事務、無法實現跨行原子性。
4、HBase數據模型
行鍵：任意字符串，最大64KB。
列族、列限定符(列名，不需要提前定義好)。
單元格，每個單元格可以存儲多個版本、每個版本對應一個時間戳。
事件戳：每次對單元格執行操作，HBase會隱式自動生成并存儲一個時間戳。
數據坐標：[行鍵、列族、列限定符、時間戳]
5、概念視圖與物理視圖
概念視圖：邏輯模型，認為規定建立。

物理視圖：

在物理視圖中，空的列并不會被存儲為null，而是不會存儲，當請求空白的單元格時返回null。

6、 面向列的存儲
從嚴格的關系數據庫角度來看，HBase并不是一個列式存儲的數據庫，HBase是以列族為單位進行分解的，而不是每個列都單獨存儲。

7、 HBase實現原理
與HDFS具有很多相似之處、有一個Master節點負責HBase表的分區信息，表被分為Region存儲到多個Region服務器，Master會檢測Region服務器 工作狀態、負責性能均衡。客戶端并不從Master獲得數據，從ZooKeeper獲得Region位置，從Region服務器中拉取數據。

8、 表和Region、Region的定位

9、 HBase系統架構
客戶端：緩存Region位置、與Master進行RPC通信、與Region服務器RPC通信進行數據的讀寫。
Zookeeper服務器：通常由集群組成，每個Region服務器要到Zookeeper服務器注冊，Zookeeper實時監控Region,Master通過Zookeeper感知Region服務器狀態。
Master服務器：管理用戶對表操作、Region服務器的負載均衡、Region分裂與合并、Region遷移（如有Region服務器故障時）
Region服務器：Region存儲、向客戶端提供訪問接口。

10、 Region服務器工作原理

第5章 NoSQL數據庫

1、 NoSQL特點
靈活的可擴展性、靈活的數據模型、與云計算緊密耦合。

2、 NoSQL與Web2.0
無法滿足海量數據的管理需求、無法滿足高并發的需求、無法滿足高可擴展性和高可復用性的要求。
Web2.0網站系統通常不需要嚴格的數據庫事務、并不要求嚴格的讀寫實時性、通常不包含大量復雜的SQL查詢。

3、 NoSQL的四大類型
鍵值數據庫、列族數據庫、文檔數據庫、圖數據庫。

4、 NoSQL三大基石，CAP、BASE、最終一致性。
C (Consistency) :一致性，指任何一個讀操作總是能夠讀到之前完成的寫操作的結果，在分布式環境中、多點數據是一致的。
A（Availability）：可用性。指快速獲取數據，且可以在確定的時間內返回操作結果。
P（tolerance of network partition）：分區容忍性，當出現網絡分區的情況，分離的系統可以正常運行。

組合：
CA 強調一致性和可用性，可擴展性較差。
CP 強調一致性和分區容忍性，當出現網絡分區的情況時，受影響的服務需要的等待數據一致，因此在等待期間就無法對外提供服務。
AP 在采用AP設計時，可以不完全放棄一致性，轉而采用最終一致性。

BASE
A(atomicity)原子性：對數據的修改、要么全部執行、要么全部不執行。
C(Consistency)一致性：在事務完成時，必須是所有數據都保持一致狀態。
I(Isolation) 隔離性：并發事務所作的修改必須與其他并發事務所做的改變隔離。
D(Durability) 持久性：事務完成后、對系統的影響是永久性的。

最終一致性
是弱一致性的特例，允許后續的訪問操作可以暫時讀不到更新后的數據，但經過一段時間后，用戶可以讀到更新后的數據，最終一致性也是ACID的最終目的，只要最終數據是一致的就可以了，而不是每時每刻都保持實時一致性。

第7章 MapReduce

Hadoop MapReduce是基于谷歌MapReduce的開源實現。

大規模數據集 -> 分片小數據集 -> 處理為<key,value> -> 交給Map任務 -> 輸出List(<k2,v2>) -> Map Shuffle -> Reduce Shuffle -> 輸入<k2,List(v2)> -> Reduce -> 輸出<k3,v3>。

當Map任務全部結束時，才會開始Reduce任務。
在切分大文件時沒并不是真正的切分物理文件、而是利用RecordReader記錄要處理數據的位置和長度。

Shuffle過程，分為Map端的Shuffle過程、和Reduce端的Shuffle過程，Shuffle是指對Map任務輸出結果進行分區，排序、合并、歸并等處理并交給Reduce的過程。

Map端的Shuffle過程
輸入數據和執行Map任務，Map輸出結果寫入緩存、緩存滿了則進行溢寫(分區、排序、合并) 生成多個溢寫文件、當Map任務全部結束之前，溢寫文件會被歸并為一個大的磁盤文件。

Reduce任務從Map端的不同Map機器”領取”屬于自己處理的那部分數據，然后對數據進行歸并后交給Reduce處理。具有相同key的<key,value>會被發送到同一個Reduce任務。

關于溢寫，提供給MapReduce的緩存的容量是有限的，默認大小100MB。隨著Map任務執行，很快寫滿緩存區，進行溢寫操作，首先對這些鍵值進行分區，默認的分區方式為Hash函數對key哈希。
“合并”是指將具有相同key的<key,value>的value加起來。并非所有場景都適合合并操作。
每次溢寫操作都會生成一個新得溢寫文件，寫入溢寫文件中得所有鍵值對都是經過分區和排序得。

“歸并” ,溢寫文件數量越來越多，最終在Map任務全部結束前，系統對所有溢寫文件數據進行歸并操作，具有相同key的鍵值被合并為一個鍵值，如<k1,v1><k1,v2><k1,v3> 會被歸并為一個新的鍵值，<k1,<v1,v2,v3>>。JobTracker檢測Map任務，當Map任務完成時，通知Reduce任務來領取數據。然后開始Reduce端的Shuffle過程。

Reduce端的Shuffle過程
從Map端讀取Map任務結果，執行歸并操作，，最后送給Reduce任務進行處理。
JobTracker檢測Map任務，通知Reduce任務領取數據，先放置到Reduce任務機器的緩存中，同樣存在溢寫操作，當溢寫過程啟動時，具有相同key的鍵值對會被歸并。同樣存在溢寫文件的合并。
經過多輪歸并后得到若干個大文件，直接輸入Reduce任務。

WordCount實例

MapReduce模型的關系上的標準運算
選擇、投影、并、交、差、自然連接
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

第10章 Spark

1、 什么是Spark?
Spark是基于內存計算的大數據并行計算框架，可用于構建大型的、低延時的數據分析應用程序.
2、 Spark的特點。
運行速度快、使用有向無環圖執行引擎、支持循環數據流與內存計算。
容易使用，支持多種編程語言。
通用性：提供完整的技術棧，SQL查詢、流式計算、機器學習等等。
運行模式多樣：可運行在集群、EC2等環境中。

3、 Spark與Hadoop的對比

Hadoop缺點：
（1）表達能力有限，需要轉化為Map和Reduce操作。
（2）磁盤IO開銷大，需要先內存緩存寫入，緩存內容溢寫到磁盤。
（3）延遲高：一次計算可能要多個MapReduce任務，任務之間設計IO開銷，在前一個任務完成之前，其他任務無法開始。

Spark優點：
（1） Spark計算模式也屬于MapReduce，但不局限于Map和Reduce操作。
（2） 提供內存計算、計算結果放置于內存中。
（3） 基于DAG任務調度執行機制，由于MapReduce的迭代執行機制。

4、 Spark生態系統
大數據處理主要包括3個·類型
（1） 復雜的批量數據處理
（2） 基于歷史數據的交互式查詢
（3） 基于實時數據流的數據處理

Spark應用場景
場景 時間跨度 spark生態組件
復雜的批量數據處理 小時級 spark core
基于歷史數據的交互式查詢 分鐘、秒級別 Spark SQL
實時數據流的數據處理 毫秒級、秒級別 spark streaming、structured streaming
歷史數據的數據挖掘 MLib
圖結構數據的處理 GraphX

5、 Spark運行架構
RDD：一種高度受限的共享內存模型
DAG：反應RDD之間的依賴關系
Spark基本運行流程：

6、 RDD相關原理

7、 RDD特性
（1） 高效的容錯性
（2） 中間結果持久化道內存
（3） 存放的數據可以是Java對象

8、 RDD之間的依賴關系

M*R個bucket M: map任務數量 R：Reduce任務數量
Spark多個桶寫入同一個文件
Map任務產生 數據文件與索引文件，Reduce任務通過索引文件信息，獲取自己應該處理的數據信息。
Reduce任務并不進行排序，而是利用HashMap進行分類，Reduce內存必須滿足存放所有其應該存儲的<key,value>否則內存會溢出。但內存過大時操作也會從內存到磁盤。Spark的Shuffle過程也有把數據寫入到磁盤的情況。

9、 寬依賴與窄依賴

10、 階段劃分
只有窄依賴才能完成流水線優化。Spark通過分析RDD之間的依賴關系生成DAG，再通過分析各個RDD中的分區之間的依賴關系，劃分階段。
具體方法：在DAG中反向解析，遇到寬依賴就斷開，遇到窄依賴就把當前的RDD加入當前的階段。

11、 RDD運行過程
（1） 創建RDD對象
（2） SparkContent負責計算RDD之間的依賴關系，構建DAG
（3） DAGScheduler負責把DAG分解成多個階段、每個階段中包含多個任務，每個任務會被任務調度器分發給各個工作節點上的Executor去執行

第11章 流計算

1、 流數據
（1） 快速持續到達、潛在數據量也許是無窮無盡的
（2） 數據來源眾多、格式復雜
（3） 數據量大、但不是十分關注存儲。
（4） 注重數據的整體價值，不過分關注個別數據
（5） 數據順序顛倒，或者不完整，系統無法控制將要處理的新到達的數據元素的順序。

2、 流計算
MapReduce負責海量數據執行批量計算
（1） 高性能 （2）海量式 （3）實時性 （4）分布式（5）易用性 （6）可靠性

3、 傳統數據處理與流計算對比

4、 數據處理流程詳情
（1） 數據實時采集
Agent：主動采集數據、并把數據推送到Collector部分
Collector：接收多個Agent的數據，并實現有序、可靠、高性能轉發
Store：存儲，一般不存儲，直接發送給流計算平臺進行計算

（2） 數據實時計算
數據流入 流處理系統實時計算 計算結果與數據流出

（3） 實時查詢服務
流計算處理的數據是實時的，用戶通過流處理系統獲取的是實施結果，無須人為查詢，系統推送給用戶

5、 流計算應用場景
（1） 實時分析，如用戶商品推薦、廣告推薦。
（2） 實時交通，導航路線實時交通狀況。

6、 Storm
Storm 免費的、開源的分布式實時計算系統。

7、 Storm的特點
（1） 整合性。方便地與隊列系統和數據庫系統進行整合
（2） 簡易的API。Storm的API在使用上簡單方便。
（3） 可擴展性。并行特點，可以部署在分布式集群。
（4） 容錯性。自動故障節點重啟。
（5） 可靠的消息處理。保證每個消息都能完整處理。
（6） 支持各種編程語言。
（7） 快速部署。
（8） 開源、免費。

8、 Storm設計思想
Streams:流數據是一個無限的Tuple序列。
Spouts：流數據的源頭。
Bolts：流數據的轉換過程。
Topology：Spouts和Bolts組成的拓撲網絡，流轉換圖。
Stream Groupings: 告知兩個Bolt之間怎樣進行Tuple傳遞。
ShuffleGrouping: 隨機分組，隨即分發Stream中的Tuple,保證每個Bolt的Task接收Tuple數量大致一致。
FiledsGouping: 按照字段分組，保證相同字段的Tuple分配到同一個Task中。
AllGrouping: 廣播發送，每一個Task都會收到所有的Tuple.
GlobalGrouping：全局分組，所有Tuple分到同一個Task中。
NonGrouping： 不分組。
DirectGrouping：直接分組，直接指定由某個Task來執行Tuple的處理。

9、 Storm的框架設計

（1） 提交Topology到Storm集群
（2） Nimbus將分配給Supervisor的任務寫入Zookeeper
（3） Supervisor從Zookeeper獲取所分配的任務，并啟動Worker進程。
（4） Worker進行執行任務。

10、 Spark Streaming
Spark Streaming提供 整合多種輸入數據源，將實時輸入數據流以時間片為單位進行拆分，經過Spark引擎處理每個時間片數據，Spark Streaming的輸入數據按照時間片分成一段一段的Dstream,每一段數據轉換為Spark中的RDD,對Dstream的操作最終轉變為相對應的RDD操作。
Spark streaming無法完成毫秒級的流計算，因為其將流數據按批處理窗口大小分解為一系列的批量處理的作業。

總結

以上是生活随笔為你收集整理的《大数据技术原理与应用》 期末复习的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。