大數據基礎整合

第一章

1. 信息科技需要處理的三大核心問題

   信息存儲、信息傳輸、信息處理

2. 數據產生方式的變革

   1. 運營式系統階段
      • 數據庫的出現使數據管理的復雜度大大降低，數據往往伴隨着一定的運營活動而產生並記錄在數據庫中，數據的產生方式是被動的
   2. 用戶原創內容階段
      • 數據爆發產生於Web2.0時代，而Web2.0的最重要的標志就是用戶原創內容
      • 智能手機等移動設備加速內容產生
      • 數據產生方式是主動的
   3. 感知式系統階段
      • 感知式系統的廣泛使用
      • 人類社會數據量第三次大的飛躍最終導致的大數據的產生

3. 大數據4V概念（能簡要概括）

   數據量大、數據類型繁多、處理速度快、價值密度低

4. 大數據對思維方式的影響

   全樣而非抽樣、效率而非准確、相關而非因果

5. 大數據技術的不同層面及其功能

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

6. 大數據計算模式

   大數據計算模式	解決問題	代表產品
   批處理計算	針對大規模數據的批量處理	MapReduce、Spark等
   流計算	針對流數據的實時計算	Storm、S4、Flume、Streams、Puma、DStream、SuperMario、銀河數據處理平台等
   圖計算	針對大規模圖結構數據的處理	Pregel、GraphX、Giraph、PowerGraph、Hama、GoldenOrb等
   查詢分析計算	大規模數據的存儲管理和查詢分析系	Dremel、Hive、Cassandra、Impala等

7. 雲計算關鍵技術

   虛擬化、分布式存儲、分布式計算、多租戶等

8. 物聯網關鍵技術

   1. 識別和感知技術
   2. 網絡與通信技術
   3. 數據挖掘與融合技術

第二-三章

1. 分布式文件系統概念

   分布式文件系統是一種通過網絡實現文件在多台主機上進行分布式存儲的文件系統

2. HDFS文件塊

   HDFS默認一個塊64MB，一個文件被分成多個塊，以塊作為存儲單位 塊的大小遠遠大於普通文件系統，可以最小化尋址開銷 。

   HDFS采用抽象的塊概念可以帶來以下幾個明顯的好處：

   • 支持大規模文件存儲
   • 簡化系統設計
   • 適合數據備份

3. 名稱節點、數據節點的功能與工作原理（能簡要概括）

   名稱節點功能：

   在HDFS中，名稱節點（NameNode）負責管理分布式文件系統的命名空間，保存了兩個核心的數據結構，即FsImage和EditLog

   名稱節點工作原理：

   1. 在名稱節點啟動的時候，它會將FsImage文件中的內容加載到內存中，之后再 執行EditLog文件中的各項操作，使得內存中的元數據和實際的同步，存在內存 中的元數據支持客戶端的讀操作。
   2. 一旦在內存中成功建立文件系統元數據的映射，則創建一個新的FsImage文件 和一個空的EditLog文件
   3. 名稱節點起來之后，HDFS中的更新操作會重新寫到EditLog文件中，因為 FsImage文件一般都很大（GB級別的很常見），如果所有的更新操作都往 FsImage文件中添加，這樣會導致系統運行的十分緩慢，但是，如果往EditLog 文件里面寫就不會這樣，因為EditLog 要小很多。每次執行寫操作之后，且在 向客戶端發送成功代碼之前，edits文件都需要同步更新

   數據節點：

   ​ 數據節點是分布式文件系統HDFS的工作節點，負責數據的存儲和讀取，會根據客戶端或者是名稱節點的調 度來進行數據的存儲和檢 索，並且向名稱節點定期發送自己所存儲的塊的列表

   ​ 每個數據節點中的數據會被保存在各自節點的本地Linux文件系統中

4. 第二名稱節點的意義與功能（理解工作原理，能用自己語言說明）

   第二名稱節點是HDFS架構中的一個組成部分，它是用來保存名稱節點中對HDFS 元數據信息的備份，並減少名稱節點重啟的時間。SecondaryNameNode一般是 單獨運行在一台機器上

   SecondaryNameNode的工作情況：

   （1）SecondaryNameNode會定期和 NameNode通信，請求其停止使用EditLog 文件，暫時將新的寫操作寫到一個新的文件 edit.new上來，這個操作是瞬間完成，上層 寫日志的函數完全感覺不到差別；

   （2）SecondaryNameNode通過HTTP GET方式從NameNode上獲取到FsImage和 EditLog文件，並下載到本地的相應目錄下 ；

   （3）SecondaryNameNode將下載下 來的FsImage載入到內存，然后一條一條地 執行EditLog文件中的各項更新操作，使得 內存中的FsImage保持最新；這個過程就是 EditLog和FsImage文件合並；

   （4）SecondaryNameNode執行完（3 ）操作之后，會通過post方式將新的 FsImage文件發送到NameNode節點上

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

5. HDFS冗余存儲的定義與意義

   定義：

   ​ 作為一個分布式文件系統，為了保證系統的容錯性和可用性，HDFS采用 了多副本方式對數據進行冗余存儲，通常一個數據塊的多個副本會被分布到不 同的數據節點上

   意義：

   ​ （1）加快數據傳輸速度

   ​ （2）容易檢查數據錯誤

   ​ （3）保證數據可靠性

6. HDFS數據存放策略，讀取策略P52 （理解工作原理，用自己的話說明）

   數據存放：

   • 第一個副本：放置在上傳文件的數據節點；如果是集群外提交，則隨機挑 選一台磁盤不太滿、CPU不太忙的節點

   • 第二個副本：放置在與第一個副本不同的機架的節點上

   • 第三個副本：與第一個副本相同機架的其他節點上

   • 更多副本：隨機節點

     

   數據讀取：

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

7. HDFS三種數據錯誤及其恢復方法（理解工作原理，用自己的話說明）

   1. 名稱節點出錯

      恢復方法：HDFS設置了備份機制，把這些核心文件 同步復制到備份服務器SecondaryNameNode上。當名稱節點出錯時， 就可以根據備份服務器SecondaryNameNode中的FsImage和Editlog 數據進行恢復。

   2. 數據節點出錯

      恢復方法：每個數據節點會定期向名稱節點發送“心跳”信息，向名稱節點報告自 己的狀態。當數據節點發生故障，或者網絡發生斷網時，名稱節點就無法收到來自 一些數據節點的心跳信息，這時，這些數據節點就會被標記為“宕機”， 節點上面的所有數據都會被標記為“不可讀”，名稱節點不會再給它們 發送任何I/O請求。這時，有可能出現一種情形，即由於一些數據節點的不可用，會導致一 些數據塊的副本數量小於冗余因子。名稱節點會定期檢查這種情況，一旦發現某個數據塊的副本數量小於冗 余因子，就會啟動數據冗余復制，為它生成新的副本

   3. 數據出錯

      恢復方法：當客戶端讀取文件的時候，會先讀取該信息文件，然后，利用該信息文件對 每個讀取的數據塊進行校驗，如果校驗出錯，客戶端就會請求到另外一個數 據節點讀取該文件塊，並且向名稱節點報告這個文件塊有錯誤，名稱節點會 定期檢查並且重新復制這個塊

第四章

1. HBASE生態系統

2. HBASE的數據模型相關概念，理解掌握其中各個概念

   • 表：HBase采用表來組織數據，表由行和列組成，列划分為若干個列族
   • 行：每個HBase表都由若干行組成，每個行由行鍵（row key）來標識。
   • 列族：一個HBase表被分組成許多“列族”（Column Family）的集合，它是基本的訪問控制單元
   • 列限定符：列族里的數據通過列限定符（或列）來定位
   • 單元格：在HBase表中，通過行、列族和列限定符確定一個“單元格”（cell），單元格中存儲的數據沒有數據類型，總被視為字節數組byte[]
   • 時間戳：每個單元格都保存着同一份數據的多個版本，這些版本采用時間戳進行索引

3. 數據坐標的含義

   HBase中需要根據行鍵、列族、列限定符和時間戳來確定一個單元格，因此，可以視為一個“四維坐標”，即[行鍵, 列族, 列限定符, 時間戳]

   

4. 概念視圖與物理視圖的實際含義

   概念視圖：在Hbase的概念視圖中，一個表可以視為一個稀疏、多維的映射關系

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

5. HBASE三層結構

   

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

第五章

1. NoSQL數據庫的含義與特點

   含義：

   ​ NoSQL是一種不同於關系數據庫的數據庫管理系統設計方式，是對非關系型數據庫的統稱，它所采用的數據模型並非傳統關系數據庫的關系模型，而是類似鍵/值、列族、文檔等菲關系模型。

   特點：

   ​ （1）靈活的可擴展性

   ​ （2）靈活的數據模型

   ​ （3）與雲計算緊密融合

2. 關系數據庫在WEB 2.0時代的局限 與WEB 2.0不適用關系型數據庫的原因

   （1）無法滿足海量數據的管理需求

   （2）無法滿足數據高並發的需求

   （3）無法滿足高可擴展性和高可用性的需求

3. 四大類型NoSQL數據庫的定義,特點,代表性產品（理解並能用自己語言說明）

   1.key-value

   Redis
   鍵值對存儲，特點：查詢數據塊
   內容緩存，主要用於處理大量數據的高訪問負載，也用於一些日志系統等等。

   鍵值數據庫適用於那些頻繁讀寫，擁有簡單數據模型的應用。鍵值數據庫中存儲的值可以是簡單的標量值，如整數或布爾值，也可以是結構化數據類型，比如列表和JSON結構。

   2.Colunmn列式存儲
   HBase
   將同一列的數據放在一起，查詢非常快

   列族數據庫被設計應用於大量數據的情況，它保證了讀取和寫入的性能和高可用性。谷歌推出Bigtable來應對其服務需求。Facebook開發Cassandra 來支持其收件箱搜索服務。

   3.document文檔存儲

   MongoDB
   經典用於web項目中，與KeyValue類似，比如MongoDB主要應用在爬蟲

   文檔型數據庫按照靈活性的標准設計。如果一個應用程序需要存儲不同的屬性以及大量的數據，那么文檔數據庫將會是一個很好的選擇。例如，要在關系數據庫中表示產品，建模者可以使用通用的屬性和額外的表來為每個產品子類型存儲屬性。文檔數據庫卻可以更為簡單的處理這種情況。

   4.Graph圖結構存儲

   neo4j
   用於社交網絡

   圖形數據庫非常適合表示網絡實體連接等問題。評估圖形數據庫有效性的一種方法是確定實例和實例間是否存在關系。

   分類	相關產品	數據模型	典型應用	優點	缺點
   鍵值數據庫（Key-Value Database)	Redis、Riak、SimplDB、Chordless、Scalaris、Memcached	鍵/值對	內容緩存，如會話、配置文件、參數、購物車等	擴展性好、靈活性好、大量寫操作時性能高	無法存儲結構化信息、條件查詢效率較低
   列族數據庫	BigTable、Hbase、Cassandra、HadoopDB、GreenPlum、PNUTS	列族	分布式數據存儲與管理	查找速度快、可擴展性強、容易進行分布式擴展、復雜性低	功能較少，大都不支持強事物一致性
   文檔數據庫	CouchDB、MongoDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit	版本化的文檔	存儲、索引並管理面向文檔的數據或者類似的半結構化數據	性能好、靈活性高、復雜性低、數據結構靈活	缺乏統一的查詢語法
   圖數據庫	Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB	圖結構	應用於大量復雜、互連接、低結構化的圖結構場合，如社交網絡、推薦系統等	靈活性高、支持復雜的圖算法、可用於構建復雜的關系圖譜	復雜性高、只能支持一定的數據規模

4. NOSQL的三大基石, 理解三大要點的准確意義和內容，要求全部掌握，並能用自己語言說明

   CAP

   所謂的CAP指的是：

   • C（Consistency）：一致性，是指任何一個讀操作總是能夠讀到之前完成的寫操作的結果，也就是在分布式環境中，多點的數據是一致的， 或者說，所有節點在同一時間具有相同的數據

   • A:（Availability）：可用性，是指快速獲取數據，可以在確定的時間 內返回操作結果，保證每個請求不管成功或者失敗都有響應；

   • P（Tolerance of Network Partition）：分區容忍性，是指當出現網絡分區的情況時（即系統中的一部分節點無法和其他節點進行通信），分離的系統也能夠正常運行，也就是說，系統中任意信息的丟失或失敗不會影響系統的繼續運作。

   CAP理論告訴我們，一個分布式系統不可能同時滿足一致性、可用性和分區容忍性這三個需求，最多只能同時滿足其中兩個，正所謂“魚和熊 掌不可兼得”

   當處理CAP的問題時，可以有幾個明顯的選擇：

   1. CA：也就是強調一致性（C）和可用性（A），放棄分區容忍性（P），最簡單的做法是把所有與事務相關的內容都放到同一台機器上。很顯然，這種 做法會嚴重影響系統的可擴展性。傳統的關系數據庫（MySQL、SQL Server 和PostgreSQL），都采用了這種設計原則，因此，擴展性都比較差
   2. CP：也就是強調一致性（C）和分區容忍性（P），放棄可用性（A），當出現網絡分區的情況時，受影響的服務需要等待數據一致，因此在等待期間 就無法對外提供服務
   3. AP：也就是強調可用性（A）和分區容忍性（P），放棄一致性（C），允許系統返回不一致的數據

   BASE

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

   一個數據庫事務具有ACID四性：

   • A（Atomicity）：原子性，是指事務必須是原子工作單元，對於其數 據修改，要么全都執行，要么全都不執行
   • C（Consistency）：一致性，是指事務在完成時，必須使所有的數據 都保持一致狀態
   • I（Isolation）：隔離性，是指由並發事務所做的修改必須與任何其它 並發事務所做的修改隔離
   • D（Durability）：持久性，是指事務完成之后，它對於系統的影響是 永久性的，該修改即使出現致命的系統故障也將一直保持

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

   • 基本可用：基本可用，是指一個分布式系統的一部分發生問題變得不可用時，其 他部分仍然可以正常使用，也就是允許分區失敗的情形出現
   • 軟狀態： “軟狀態（soft-state）”是與“硬狀態（hard-state）”相對應的一種提法。數據庫保存的數據是“硬狀態”時，可以保證數據一致性，即保證數據一直是正確的。“軟狀態”是指狀態可以有一段時間不同 步，具有一定的滯后性

   最終一致性

   ​ 一致性的類型包括強一致性和弱一致性，二者的主要區別在於高並發的數據訪問操作下，后續操作是否能夠獲取最新的數據。對於強一致性而言，當執行完一次更新操作后，后續的其他讀操作就可以保證讀到更新后的最新數據；反之，如果不能保證后續訪問讀到的都是更新后的最新數據，那么就是弱一致性。而最終一致性只不過是弱一致性的一種特例，允許后續的訪問操作可以暫時讀不到更 新后的數據，但是經過一段時間之后，必須最終讀到更新后的數據。最常見的實現最終一致性的系統是DNS（域名系統）。一個域名更新操作根據配置的形式被分發出去，並結合有過期機制的緩存；最終所有的客戶端可以看到 最新的值。

   最終一致性根據更新數據后各進程訪問到數據的時間和方式的不同， 又可以區分為：

   • 因果一致性：如果進程A通知進程B它已更新了一個數據項，那么進程B 的后續訪問將獲得A寫入的最新值。而與進程A無因果關系的進程C的訪問 ，仍然遵守一般的最終一致性規則
   • “讀己之所寫”一致性：可以視為因果一致性的一個特例。當進程A自己執行一個更新操作之后，它自己總是可以訪問到更新過的值，絕不會看 到舊值
   • 單調讀一致性：如果進程已經看到過數據對象的某個值，那么任何后續 訪問都不會返回在那個值之前的值
   • 會話一致性：它把訪問存儲系統的進程放到會話（session）的上下文中，只要會話還存在，系統就保證“讀己之所寫”一致性。如果由於某些失敗情形令會話終止，就要建立新的會話，而且系統保證不會延續到新的會話
   • 單調寫一致性：系統保證來自同一個進程的寫操作順序執行。系統必須 保證這種程度的一致性，否則就非常難以編程了

第六章

1. 雲數據庫的概念

   雲數據庫是部署和虛擬化在雲計算環境中的數據庫。雲數據庫是在雲計算的大背景下發展起來的一種新興的共享基礎架構的方法，它極大地增強了數據庫的存儲能力，消除了人員、硬件、軟件的重復配置，讓軟、硬件升級變得更加容易。

2. 雲數據庫的特性

   （1）動態可擴展

   （2）高可用性

   （3）較低的使用代價

   （4）易用性

   （5）高性能

   （6）免維護

   （7）安全

第七-八章

1. MapReduce基本概念與“計算向數據靠攏”

   基本概念：

   ​ MapReduce采用“分而治之”策略，一個存儲在分布式文件系統中的大規模數據集，會被切分成許多獨立的 分片（split），這些分片可以被多個Map任務並行處理 。

   “計算向數據靠攏”：

   ​ MapReduce設計的一個理念就是“計算向數據靠攏”，而不是“數據向計算靠攏”，因為，移動數據需要大量的 網絡傳輸開銷

2. MapReduce工作流程 與各個執行階段工作

   MapReduce工作流程：

   ​

   • 不同的Map任務之間不會進行通信

   • 不同的Reduce任務之間也不會發生任何信息交換

   • 用戶不能顯式地從一台機器向另一台機器發送消息

   • 所有的數據交換都是通過MapReduce框架自身去實現的

   各個執行階段工作：

   

3. MapReduce的WORDCOUNT執行實例計算過程

   （待補充）

4. MapReduce實現關系運算

   • 關系代數運算（選擇、投影、並、交、差、連接）

   • 分組與聚合運算

   • 矩陣-向量乘法

   • 矩陣乘法

第九章

1. Spark與Hadoop的對比，SPARK高性能的原因

   1. Spark的計算模式也屬於MapReduce，但不局限於Map和Reduce操作，還提供了多種數據集操作類型，編程模型比Hadoop MapReduce更靈活
   2. Spark提供了內存計算，可將中間結果放到內存中，對於迭代運算效率更高
   3. Spark基於DAG的任務調度執行機制，要優於Hadoop MapReduce的迭代執行機制
   4. 使用Hadoop進行迭代計算非常耗資源，Spark將數據載入內存后，之后的迭代計算都可以直接使用內存中的中間結果作運算，避免了從磁盤中頻繁讀取數據

2. 大數據處理的三種類型與其適用的Spark技術棧

   在實際應用中，大數據處理主要包括以下三個類型：

   1. 復雜的批量數據處理：通常時間跨度在數十分鍾到數小時之間
   2. 基於歷史數據的交互式查詢：通常時間跨度在數十秒到數分鍾之間
   3. 基於實時數據流的數據處理：通常時間跨度在數百毫秒到數秒之間

   應用場景	時間跨度	其他框架	Spark生態系統中的組件
   復雜的批量數據處理	小時級	MapReduce、Hive	Spark Core
   基於歷史數據的交互式查詢	分鍾級、秒級	Impala、Dremel、 Drill	Spark SQL
   基於實時數據流的數據處理	毫秒、秒級	Storm、S4	Spark Streaming

3. RDD的設計與運行原理（所有概念需要能夠理解其內容與思想，並用自己語言說明）

   （待補充）

第十章

1. 流數據的特征

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

2. 批量計算與實時計算的含義

   批量計算以“靜態數據”為對象，可以在很充裕的時間內對海量數據進行批量處理，計算得到有價值的信息。

   實時計算最重要的一個需求是能夠實時得到計算結果，一般要求響應時間為秒級。

   

   流數據必須采用實時計算，響應時間為秒級

3. 流計算的要求，Hadoop不適用於流計算的原因

   對於一個流計算系統來說，它應達到如下需求：

   1. 高性能。處理大數據的基本要求，如每秒處理幾十萬條數據。
   2. 海量式。支持TB級甚至是PB級的數據規模。
   3. 實時性。必須保證一個較低的延遲時間，達到秒級別，甚至是毫秒級別。
   4. 分布式。支持大數據的基本架構，必須能夠平滑擴展。
   5. 易用性。能夠快速進行開發和部署。
   6. 可靠性。能可靠地處理流數據。

   Hadoop不適用於流計算的原因：

   1. 切分成小的片段，雖然可以降低延遲，但是也增加了任務處理的附加開銷，而且還要處理片段之間的依賴關系，因為一個片段可能需要用到前一個片段的計算結果
   2. 需要對MapReduce進行改造以支持流式處理，Reduce階段的結果不能直接輸出，而是保存在內存中。這種做法會大大增加MapReduce框架的復雜度，導致系統難以維護和擴展。
   3. 降低了用戶程序的可伸縮性，因為用戶必須要使用MapReduce接口來定義流式作業

4. 流計算處理流程