大數(shù)據(jù)技術(shù)原理與應(yīng)用

• 大數(shù)據(jù)技術(shù)原理與應(yīng)用
• • 第一章 大數(shù)據(jù)概述
  • • 1、大數(shù)據(jù)的4v特征
    • 2、大數(shù)據(jù)的影響
    • 3、大數(shù)據(jù)的兩大核心技術(shù)
    • 4、大數(shù)據(jù)計算模式及代表產(chǎn)品
    • 5、大數(shù)據(jù)與云計算、物聯(lián)網(wǎng)的關(guān)系
  • 第二章 大數(shù)據(jù)處理架構(gòu)Hadoop
  • • 1、Hadoop的發(fā)展歷史
    • 2、Hadoop的特性
    • 3、Hadoop1.0與Hadoop2.0的區(qū)別
    • 4、Hadoop生態(tài)系統(tǒng)
    • 5、Hadoop生態(tài)系統(tǒng)組件及功能
    • 6、core-site.xml和hdfs-site.xml配置文件
  • 第三章 分布式文件系統(tǒng)HDFS
  • • 1、分布式文件系統(tǒng)的結(jié)構(gòu)
    • 2、HDFS的局限性
    • 3、塊的概念
    • 4、名稱節(jié)點和數(shù)據(jù)節(jié)點
    • 5、名稱節(jié)點的數(shù)據(jù)結(jié)構(gòu)和啟動
    • 6、數(shù)據(jù)節(jié)點
    • 7、第二名稱節(jié)點
    • 8、HDFS體系結(jié)構(gòu)
    • 9、HDFS通信協(xié)議
    • 10、HDFS存儲原理
    • • 冗余數(shù)據(jù)保存
      • 數(shù)據(jù)存取策略
      • 數(shù)據(jù)錯誤的種類
    • 11、HDFS常用命令
  • 第四章 分布式數(shù)據(jù)庫HBase
  • • 1、HBase從BigTable說起
    • 2、HBase和BigTable的底層技術(shù)對應(yīng)關(guān)系：
    • 3、HBase與傳統(tǒng)數(shù)據(jù)庫相比：
    • 4、HBase數(shù)據(jù)模型
    • 5、HBase的實現(xiàn)包含三個功能組件
    • 6、HBase的三層結(jié)構(gòu)
    • 7、Region服務(wù)器工作原理
    • 8、HLog工作原理
    • 9、HBase性能優(yōu)化的方法
    • 10、HBase常見的shell命令
  • 第五章 NoSQL
  • • 1、NoSQL的含義
    • 2、NoSQL興起的原因
    • 3、Web2.0的特點
    • 4、NoSQL與關(guān)系數(shù)據(jù)庫對比
    • • 關(guān)系數(shù)據(jù)庫
      • NoSQL數(shù)據(jù)庫
    • 5、NoSQL數(shù)據(jù)庫的四大類型
    • 6、CAP
    • 7、BASE
    • 8、MongoDB的概念
  • 第六章 云數(shù)據(jù)庫
  • • 1、概念
    • 2、特性
  • 第七章 MapReduce
  • • 1、傳統(tǒng)并行計算框架與MapReduce的區(qū)別
    • 2、模型介紹
    • 3、Map函數(shù)和Reduce函數(shù)
    • 4、MapReduce體系結(jié)構(gòu)
    • 5、MapReduce的執(zhí)行過程
    • 6、分片
    • 7、任務(wù)數(shù)量
  • 第八章 Hadoop架構(gòu)再探討
  • • 1、Hadoop1.0的不足
    • 2、Hadoop1.0到2.0的改進
    • 3、HA工作原理
    • 4、新一代資源管理調(diào)度框架YARN
    • • ResourceManager
      • ApplicationMaster
      • NodeManager
  • 第九章Spark
  • • 1、spark的特點
    • 2、spark和Hadoop對比
    • 3、spark設(shè)計理念
    • 4、spark生態(tài)系統(tǒng)組件
    • 5、spark中的基本概念
    • 6、spark運行基本流程
    • 7、RDD運行原理
    • 8、RDD之間的依賴關(guān)系
    • 9、Stage的劃分
    • • Stage的類型
    • 10、RDD執(zhí)行過程
    • 11、spark SQL部署方式
  • 第十章 流計算
  • • 1、常見的流計算框架
    • 2、流處理系統(tǒng)與傳統(tǒng)的數(shù)據(jù)處理系統(tǒng)有如下不同

大數(shù)據(jù)技術(shù)原理與應(yīng)用

第一章 大數(shù)據(jù)概述

1、大數(shù)據(jù)的4v特征

volume大量化、velocity快速化、variety多樣化、value價值化

2、大數(shù)據(jù)的影響

• 思維方式方面：大數(shù)據(jù)完全顛覆了傳統(tǒng)的思維方式（全樣而非抽樣、效率而非精確、相關(guān)而非因果）。
• 社會發(fā)展方面：大數(shù)據(jù)決策逐漸成為一種新的決策方式，大數(shù)據(jù)應(yīng)用有力促進了信息技術(shù)與各行業(yè)的深度融合，大數(shù)據(jù)開發(fā)大大推動了新技術(shù)和新應(yīng)用的不斷涌現(xiàn)。
• 就業(yè)市場方面：大數(shù)據(jù)的興起使得數(shù)據(jù)科學(xué)家成為熱門職業(yè)。
• 人才培養(yǎng)方面：大數(shù)據(jù)的興起將在很大程度上改變中國高校信息技術(shù)相關(guān)專業(yè)的現(xiàn)有教學(xué)。

3、大數(shù)據(jù)的兩大核心技術(shù)

• 分布式存儲：GFS/HDFS、BigTable/HBase、NoSQL
• 分布式處理：MapReduce

4、大數(shù)據(jù)計算模式及代表產(chǎn)品

• 批處理計算：針對大規(guī)模數(shù)據(jù)的批量處理。MapReduce、Spark。
• 流計算：針對流數(shù)據(jù)的實時計算。Storm、S4、Flume、Streams、Puma、DStream、SuperMario、銀河流數(shù)據(jù)處理平臺。
• 圖計算：針對大規(guī)模圖結(jié)構(gòu)數(shù)據(jù)的處理。Pregel、GraphX、Giraph、PowerGraph、Hama、GoldenOrb。
• 查詢分析計算：大規(guī)模數(shù)據(jù)的存儲管理和查詢分析。Dremel、Hive、Cassandra、Impala。

5、大數(shù)據(jù)與云計算、物聯(lián)網(wǎng)的關(guān)系

云計算、大數(shù)據(jù)和物聯(lián)網(wǎng)代表了IT領(lǐng)域最新的技術(shù)發(fā)展趨勢，三者相輔相成，既有聯(lián)系又有區(qū)別。

• 云計算為大數(shù)據(jù)提供了技術(shù)基礎(chǔ)；大數(shù)據(jù)為云計算提供用武之地。
• 云計算為物聯(lián)網(wǎng)提供海量數(shù)據(jù)存儲能力；物聯(lián)網(wǎng)為云計算技術(shù)提供了廣闊的應(yīng)用空間。
• 物聯(lián)網(wǎng)是大數(shù)據(jù)的重要來源；大數(shù)據(jù)技術(shù)為物聯(lián)網(wǎng)數(shù)據(jù)分析提供支撐。

第二章 大數(shù)據(jù)處理架構(gòu)Hadoop

1、Hadoop的發(fā)展歷史

Apache軟件基金會旗下的開源分布式平臺，基于Java語言開發(fā)，具有很好的跨平臺性，核心是分布式文件系統(tǒng)HDFS和MapReduce。Hadoop源自始于Apache Nutch項目。

2、Hadoop的特性

高可靠性、高效性、高可擴展性、高容錯性、成本低、運行在Linux平臺、支持多種編程語言。

3、Hadoop1.0與Hadoop2.0的區(qū)別

Hadoop2.0增加了HDFS HA和YARN兩個系統(tǒng)。

4、Hadoop生態(tài)系統(tǒng)

5、Hadoop生態(tài)系統(tǒng)組件及功能

6、core-site.xml和hdfs-site.xml配置文件

<configuration><property><name>hadoop.tmp.dir</name><value>file:/usr/local/hadoop/tmp</value><description>Abase for other temporary directories.</description></property><property><name>fs.defaultFS</name><value>hdfs://localhost:9000</value></property> </configuration>

• hadoop.tmp.dir表示存放臨時數(shù)據(jù)的目錄，即包括NameNode的數(shù)據(jù)，也包括DataNode的數(shù)據(jù)。該路徑任意指定，只要實際存在該文件夾即可。
• name為fs.defaultFS的值，表示hdfs路徑的邏輯名稱。

<configuration><property><name>dfs.replication</name><value>1</value></property><property><name>dfs.namenode.name.dir</name><value>file:/usr/local/hadoop/tmp/dfs/name</value></property><property><name>dfs.datanode.data.dir</name><value>file:/usr/local/hadoop/tmp/dfs/data</value></property></configuration>

• dfs.replication表示副本的數(shù)量，偽分布式要設(shè)置為1。
• dfs.namenode.name.dir表示本地磁盤目錄，是存儲fsimage文件的地方。
• dfs.datanode.data.dir表示本地磁盤目錄，HDFS數(shù)據(jù)存放block的地方。

第三章 分布式文件系統(tǒng)HDFS

1、分布式文件系統(tǒng)的結(jié)構(gòu)

分布式文件系統(tǒng)把文件分布存儲到多個計算機節(jié)點上，成千上萬的計算機節(jié)點構(gòu)成計算機集群。分布式文件系統(tǒng)在物理結(jié)構(gòu)上是由計算機集群中的多個節(jié)點構(gòu)成的，這些節(jié)點分為兩類，一類叫“主節(jié)點”(Master Node)或者也被稱為“名稱結(jié)點”(NameNode)，另一類叫“從節(jié)點”（Slave Node）或者也被稱為“數(shù)據(jù)節(jié)點”(DataNode)。

2、HDFS的局限性

不適合低延遲數(shù)據(jù)訪問、無法高效存儲大量小文件、不支持多用戶寫入及任意修改文件。

3、塊的概念

HDFS默認一個塊64MB，HDFS2.0后默認大小128MB。
塊的優(yōu)點：

• 支持大規(guī)模文件存儲：一個文件的大小不會受到單個節(jié)點的存儲容量的限制，可以遠遠大于網(wǎng)絡(luò)中任意節(jié)點的存儲容量
• 簡化系統(tǒng)設(shè)計：大大簡化了存儲管理，方便了元數(shù)據(jù)的管理，元數(shù)據(jù)不需要和文件塊一起存儲，可以由其他系統(tǒng)負責(zé)管理元數(shù)據(jù)
• 適合數(shù)據(jù)備份：每個文件塊都可以冗余存儲到多個節(jié)點上，大大提高了系統(tǒng)的容錯性和可用性

4、名稱節(jié)點和數(shù)據(jù)節(jié)點

• 名稱節(jié)點：存儲元數(shù)據(jù)、元數(shù)據(jù)保存在內(nèi)存中、保存文件，block，datanode之間的映射關(guān)系。
• 數(shù)據(jù)節(jié)點：存儲文件內(nèi)容、文件內(nèi)容保存在磁盤、維護了block id到datanode本地文件的映射關(guān)系。

5、名稱節(jié)點的數(shù)據(jù)結(jié)構(gòu)和啟動

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

• FsImage用于維護文件系統(tǒng)樹以及文件樹中所有的文件和文件夾的元數(shù)據(jù)。
• 操作日志文件EditLog中記錄了所有針對文件的創(chuàng)建、刪除、重命名等操作。
• 名稱節(jié)點記錄了每個文件中各個塊所在的數(shù)據(jù)節(jié)點的位置信息
  
  在名稱節(jié)點啟動的時候，它會將FsImage文件中的內(nèi)容加載到內(nèi)存中，之后再執(zhí)行EditLog文件中的各項操作，使得內(nèi)存中的元數(shù)據(jù)和實際的同步，存在內(nèi)存中的元數(shù)據(jù)支持客戶端的讀操作。
  一旦在內(nèi)存中成功建立文件系統(tǒng)元數(shù)據(jù)的映射，則創(chuàng)建一個新的FsImage文件和一個空的EditLog文件。
  名稱節(jié)點啟動之后，HDFS中的更新操作會重新寫到EditLog文件中，因為FsImage文件一般都很大（GB級別的很常見），如果所有的更新操作都往FsImage文件中添加，這樣會導(dǎo)致系統(tǒng)運行的十分緩慢，但是，如果往EditLog文件里面寫就不會這樣，因為EditLog 要小很多。每次執(zhí)行寫操作之后，且在向客戶端發(fā)送成功代碼之前，edits文件都需要同步更新。
  需要注意的是，名稱節(jié)點在啟動的過程中處于“安全模式”，只能對外提供讀操作，無法提供寫操作。啟動過程結(jié)束后，系統(tǒng)會退出安全模式，進入正常運行狀態(tài)，提供寫操作。

6、數(shù)據(jù)節(jié)點

數(shù)據(jù)節(jié)點是分布式文件系統(tǒng)HDFS的工作節(jié)點，負責(zé)數(shù)據(jù)的存儲和讀取，會根據(jù)客戶端或者是名稱節(jié)點的調(diào)度來進行數(shù)據(jù)的存儲和檢索，并且向名稱節(jié)點定期發(fā)送自己所存儲的塊的列表。每個數(shù)據(jù)節(jié)點中的數(shù)據(jù)會被保存在各自節(jié)點的本地Linux文件系統(tǒng)中。

7、第二名稱節(jié)點

在名稱節(jié)點運行期間，HDFS的所有更新操作都是直接寫到EditLog中，久而久之， EditLog文件將會變得很大。雖然這對名稱節(jié)點運行時候是沒有什么明顯影響的，但是，當(dāng)名稱節(jié)點重啟的時候，名稱節(jié)點需要先將FsImage里面的所有內(nèi)容映像到內(nèi)存中，然后再一條一條地執(zhí)行EditLog中的記錄，當(dāng)EditLog文件非常大的時候，會導(dǎo)致名稱節(jié)點啟動操作非常慢，而在這段時間內(nèi)HDFS系統(tǒng)處于安全模式，一直無法對外提供寫操作，影響用戶的使用。
第二名稱節(jié)點是HDFS架構(gòu)中的一個組成部分，它是用來保存名稱節(jié)點中對HDFS 元數(shù)據(jù)信息的備份，并減少名稱節(jié)點重啟的時間。SecondaryNameNode一般是單獨運行在一臺機器上。

第二名稱節(jié)點的工作：

• 1、每隔一段時間，第二名稱節(jié)點會和名稱節(jié)點通信，請求其停止使用EditLog文件，暫時將新到達的寫操作添加到一個新文件EditLog.new中。
• 2、第二名稱節(jié)點把名稱中的FsImage文件和EditLog文件拉回本地，再加載到內(nèi)存中。
• 3、對二者執(zhí)行合并操作。在內(nèi)存中逐條執(zhí)行EditLog文件中的操作，使得FsImage保持最新。
• 4、合并結(jié)束后，第二名稱節(jié)點會把合并后得到的最新的FsImage文件發(fā)送到名稱節(jié)點。
• 5、名稱節(jié)點收到后，會用最新的FsImage文件替換舊的FsImage文件，同時用EditLog.new文件替換EditLog文件。

8、HDFS體系結(jié)構(gòu)

HDFS采用了主從（Master/Slave）結(jié)構(gòu)模型，一個HDFS集群包括一個名稱節(jié)點（NameNode）和若干個數(shù)據(jù)節(jié)點（DataNode）。名稱節(jié)點作為中心服務(wù)器，負責(zé)管理文件系統(tǒng)的命名空間及客戶端對文件的訪問。集群中的數(shù)據(jù)節(jié)點一般是一個節(jié)點運行一個數(shù)據(jù)節(jié)點進程，負責(zé)處理文件系統(tǒng)客戶端的讀/寫請求，在名稱節(jié)點的統(tǒng)一調(diào)度下進行數(shù)據(jù)塊的創(chuàng)建、刪除和復(fù)制等操作。每個數(shù)據(jù)節(jié)點的數(shù)據(jù)實際上是保存在本地Linux文件系統(tǒng)中的。

9、HDFS通信協(xié)議

• HDFS是一個部署在集群上的分布式文件系統(tǒng)，因此，很多數(shù)據(jù)需要通過網(wǎng)絡(luò)進行傳輸。
• 所有的HDFS通信協(xié)議都是構(gòu)建在TCP/IP協(xié)議基礎(chǔ)之上的。
• 客戶端通過一個可配置的端口向名稱節(jié)點主動發(fā)起TCP連接，并使用客戶端協(xié)議與名稱節(jié)點進行交互。
• 名稱節(jié)點和數(shù)據(jù)節(jié)點之間則使用數(shù)據(jù)節(jié)點協(xié)議進行交互。
• 客戶端與數(shù)據(jù)節(jié)點的交互是通過RPC（Remote Procedure
  Call）來實現(xiàn)的。在設(shè)計上，名稱節(jié)點不會主動發(fā)起RPC，而是響應(yīng)來自客戶端和數(shù)據(jù)節(jié)點的RPC請求。

10、HDFS存儲原理

冗余數(shù)據(jù)保存

HDFS采用多副本方式對數(shù)據(jù)進行冗余存儲，通常一個數(shù)據(jù)塊的多個副本會被分布到不同的數(shù)據(jù)節(jié)點上。
優(yōu)點：加快數(shù)據(jù)傳輸速度、容易檢查數(shù)據(jù)錯誤、保證數(shù)據(jù)可靠性。

數(shù)據(jù)存取策略

• 數(shù)據(jù)存放：
  第一個副本：放置在上傳文件的數(shù)據(jù)節(jié)點；如果是集群外提交，則隨機挑選一臺磁盤不太滿、CPU不太忙的節(jié)點
  第二個副本：放置在與第一個副本不同的機架的節(jié)點上
  第三個副本：與第一個副本相同機架的其他節(jié)點上
  更多副本：隨機節(jié)點
• 數(shù)據(jù)讀取：
  HDFS提供了一個API可以確定一個數(shù)據(jù)節(jié)點所屬的機架ID，客戶端也可以調(diào)用API獲取自己所屬的機架ID。當(dāng)客戶端讀取數(shù)據(jù)時，從名稱節(jié)點獲得數(shù)據(jù)塊不同副本的存放位置列表，列表中包含了副本所在的數(shù)據(jù)節(jié)點，可以調(diào)用API來確定客戶端和這些數(shù)據(jù)節(jié)點所屬的機架ID，當(dāng)發(fā)現(xiàn)某個數(shù)據(jù)塊副本對應(yīng)的機架ID和客戶端對應(yīng)的機架ID相同時，就優(yōu)先選擇該副本讀取數(shù)據(jù)，如果沒有發(fā)現(xiàn)，就隨機選擇一個副本讀取數(shù)據(jù)。

數(shù)據(jù)錯誤的種類

數(shù)據(jù)錯誤的三種：名稱節(jié)點出錯、數(shù)據(jù)節(jié)點出錯、數(shù)據(jù)出錯。

11、HDFS常用命令

• hadoop fs -ls <path>:顯示指定的文件的詳細信息
• hadoop fs -mkdir <path>:創(chuàng)建<path>指定的文件夾
• hadoop fs -cat <path>:將<path>指定的文件的內(nèi)容輸出到標準輸出（stdout）
• hadoop fs -copyFromLocal <localsrc><dst>:將本地源文件<localsrc>復(fù)制到路徑<dst>指定的文件或文件夾中

第四章 分布式數(shù)據(jù)庫HBase

1、HBase從BigTable說起

BigTable是一個分布式存儲系統(tǒng)

2、HBase和BigTable的底層技術(shù)對應(yīng)關(guān)系：

• 文件存儲系統(tǒng)：HDFS（HBase）和GFS（BigTable）
• 海量數(shù)據(jù)處理：Hadoop MapReduce（HBase）和MapReduce（BigTable）
• 協(xié)同服務(wù)管理：Zookeeper（HBase）和Chubby（BigTable）

3、HBase與傳統(tǒng)數(shù)據(jù)庫相比：

• 數(shù)據(jù)類型：關(guān)系數(shù)據(jù)庫采用關(guān)系模型，具有豐富的數(shù)據(jù)類型和存儲方式，HBase則采用了更加簡單的數(shù)據(jù)模型，它把數(shù)據(jù)存儲為未經(jīng)解釋的字符串。
• 數(shù)據(jù)操作：關(guān)系數(shù)據(jù)庫中包含了豐富的操作，其中會涉及復(fù)雜的多表連接。HBase操作則不存在復(fù)雜的表與表之間的關(guān)系，只有簡單的插入、查詢、刪除、清空等，因為HBase在設(shè)計上就避免了復(fù)雜的表和表之間的關(guān)系。
• 存儲模式：關(guān)系數(shù)據(jù)庫是基于行模式存儲的。HBase是基于列存儲的，每個列族都由幾個文件保存，不同列族的文件是分離的。
• 數(shù)據(jù)索引：關(guān)系數(shù)據(jù)庫通常可以針對不同列構(gòu)建復(fù)雜的多個索引，以提高數(shù)據(jù)訪問性能。HBase只有一個索引——行鍵，通過巧妙的設(shè)計，HBase中的所有訪問方法，或者通過行鍵訪問，或者通過行鍵掃描，從而使得整個系統(tǒng)不會慢下來。
• 數(shù)據(jù)維護：在關(guān)系數(shù)據(jù)庫中，更新操作會用最新的當(dāng)前值去替換記錄中原來的舊值，舊值被覆蓋后就不會存在。而在HBase中執(zhí)行更新操作時，并不會刪除數(shù)據(jù)舊的版本，而是生成一個新的版本，舊有的版本仍然保留。
• 可伸縮性：關(guān)系數(shù)據(jù)庫很難實現(xiàn)橫向擴展，縱向擴展的空間也比較有限。相反，HBase和BigTable這些分布式數(shù)據(jù)庫就是為了實現(xiàn)靈活的水平擴展而開發(fā)的，能夠輕易地通過在集群中增加或者減少硬件數(shù)量來實現(xiàn)性能的伸縮。

4、HBase數(shù)據(jù)模型

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

HBase中需要根據(jù)行鍵、列族、列限定符和時間戳來確定一個單元格，因此，可以視為一個“四維坐標”，即[行鍵, 列族, 列限定符, 時間戳]
注意：HBase按列族進行物理存儲。

5、HBase的實現(xiàn)包含三個功能組件

• 庫函數(shù)：鏈接到每個客戶端
• Master主服務(wù)器：負責(zé)管理和維護HBase表的分區(qū)信息，維護Region服務(wù)器列表，分配Region，負載均衡
• Region服務(wù)器：負責(zé)存儲和維護分配給自己的Region，處理來自客戶端的讀寫請求

客戶端并不是直接從Master主服務(wù)器上讀取數(shù)據(jù)，而是在獲得Region的存儲位置信息后，直接從Region服務(wù)器上讀取數(shù)據(jù)。
客戶端并不依賴Master，而是通過Zookeeper來獲得Region位置信息，大多數(shù)客戶端甚至從來不和Master通信，這種設(shè)計方式使得Master負載很小 。
開始只有一個Region，后來不斷分裂。

Region拆分操作非常快，接近瞬間，因為拆分之后的Region讀取的仍然是原存儲文件，直到“合并”過程把存儲文件異步地寫到獨立的文件之后，才會讀取新文件。

6、HBase的三層結(jié)構(gòu)

• 元數(shù)據(jù)表，又名.META.表，存儲了Region和Region服務(wù)器的映射關(guān)系。當(dāng)HBase表很大時，
  .META.表也會被分裂成多個Region
• 根數(shù)據(jù)表，又名-ROOT-表，記錄所有元數(shù)據(jù)的具體位置。-ROOT-表只有唯一一個Region，名字是在程序中被寫死的
• Zookeeper文件記錄了-ROOT-表的位置
  

7、Region服務(wù)器工作原理

• 用戶讀寫數(shù)據(jù)過程：用戶寫入數(shù)據(jù)時，被分配到相應(yīng)Region服務(wù)器去執(zhí)行。用戶數(shù)據(jù)首先被寫入到MemStore和Hlog中。只有當(dāng)操作寫入Hlog之后，commit()調(diào)用才會將其返回給客戶端。當(dāng)用戶讀取數(shù)據(jù)時，Region服務(wù)器會首先訪問MemStore緩存，如果找不到，再去磁盤上面的StoreFile中尋找。
• 緩存的刷新：系統(tǒng)會周期性地把MemStore緩存里的內(nèi)容刷寫到磁盤的StoreFile文件中，清空緩存，并在Hlog里面寫入一個標記。每次刷寫都生成一個新的StoreFile文件，因此，每個Store包含多個StoreFile文件。每個Region服務(wù)器都有一個自己的HLog文件，每次啟動都檢查該文件，確認最近一次執(zhí)行緩存刷新操作之后是否發(fā)生新的寫入操作；如果發(fā)現(xiàn)更新，則先寫入MemStore，再刷寫到StoreFile，最后刪除舊的Hlog文件，開始為用戶提供服務(wù)。
• StoreFile的合并：每次刷寫都生成一個新的StoreFile，數(shù)量太多，影響查找速度。調(diào)用Store.compact()把多個合并成一個。合并操作比較耗費資源，只有數(shù)量達到一個閾值才啟動合并。

8、HLog工作原理

• 分布式環(huán)境必須要考慮系統(tǒng)出錯。HBase采用HLog保證系統(tǒng)恢復(fù)。HBase系統(tǒng)為每個Region服務(wù)器配置了一個HLog文件，它是一種預(yù)寫式日志（Write
  Ahead Log）。
• 用戶更新數(shù)據(jù)必須首先寫入日志后，才能寫入MemStore緩存，并且，直到MemStore緩存內(nèi)容對應(yīng)的日志已經(jīng)寫入磁盤，該緩存內(nèi)容才能被刷寫到磁盤。
• Zookeeper會實時監(jiān)測每個Region服務(wù)器的狀態(tài)，當(dāng)某個Region服務(wù)器發(fā)生故障時，Zookeeper會通知Master。
• Master首先會處理該故障Region服務(wù)器上面遺留的HLog文件，這個遺留的HLog文件中包含了來自多個Region對象的日志記錄。
• 系統(tǒng)會根據(jù)每條日志記錄所屬的Region對象對HLog數(shù)據(jù)進行拆分，分別放到相應(yīng)Region對象的目錄下，然后，再將失效的Region重新分配到可用的Region服務(wù)器中，并把與該Region對象相關(guān)的HLog日志記錄也發(fā)送給相應(yīng)的Region服務(wù)器。
• Region服務(wù)器領(lǐng)取到分配給自己的Region對象以及與之相關(guān)的HLog日志記錄以后，會重新做一遍日志記錄中的各種操作，把日志記錄中的數(shù)據(jù)寫入到MemStore緩存中，然后，刷新到磁盤的StoreFile文件中，完成數(shù)據(jù)恢復(fù)。
• 共用日志優(yōu)點：提高對表的寫操作性能；缺點：恢復(fù)時需要分拆日志。

9、HBase性能優(yōu)化的方法

• 行鍵：行鍵是按照字典序存儲，因此，設(shè)計行鍵時，要充分利用這個排序特點，將經(jīng)常一起讀取的數(shù)據(jù)存儲到一塊，將最近可能會被訪問的數(shù)據(jù)放在一塊。
  舉個例子：如果最近寫入HBase表中的數(shù)據(jù)是最可能被訪問的，可以考慮將時間戳作為行鍵的一部分，由于是字典序排序，所以可以使用Long.MAX_VALUE - timestamp作為行鍵，這樣能保證新寫入的數(shù)據(jù)在讀取時可以被快速命中。
• InMemory：創(chuàng)建表的時候，可以通過HColumnDescriptor.setInMemory(true)將表放到Region服務(wù)器的緩存中，保證在讀取的時候被cache命中。
• Max Version：創(chuàng)建表的時候，可以通過HColumnDescriptor.setMaxVersions(int
  maxVersions)設(shè)置表中數(shù)據(jù)的最大版本，如果只需要保存最新版本的數(shù)據(jù)，那么可以設(shè)置setMaxVersions(1)。
• Time To Live：創(chuàng)建表的時候，可以通過HColumnDescriptor.setTimeToLive(int
  timeToLive)設(shè)置表中數(shù)據(jù)的存儲生命期，過期數(shù)據(jù)將自動被刪除，例如如果只需要存儲最近兩天的數(shù)據(jù)，那么可以設(shè)置setTimeToLive(2 * 24 * 60 * 60)。

10、HBase常見的shell命令

create ‘temptable’,’f1’,’f2’,’f3’ list put ‘temptable’,’r1’,’f1:c1’,’hello,dblab’ scan ‘temptable’ get ‘temptable’,’r1’,{COLUMN=>’f1:c1’} enable/disable ‘temptable’ drop ‘temptable’

第五章 NoSQL

1、NoSQL的含義

2、NoSQL興起的原因

關(guān)系數(shù)據(jù)庫無法滿足海量數(shù)據(jù)的管理需求、數(shù)據(jù)高并發(fā)的需求、高可擴展性和高可用性的需求

3、Web2.0的特點

• 網(wǎng)站系統(tǒng)通常不要求嚴格的數(shù)據(jù)庫事務(wù)
• 不要求嚴格的讀寫實時性
• 通常不包含大量復(fù)雜的SQL查詢（去結(jié)構(gòu)化，存儲空間換取更好的查詢性能）

4、NoSQL與關(guān)系數(shù)據(jù)庫對比

關(guān)系數(shù)據(jù)庫

• 優(yōu)勢：以完善的關(guān)系代數(shù)理論作為基礎(chǔ)，有嚴格的標準，支持事務(wù)ACID四性，借助索引機制可以實現(xiàn)高效的查詢，技術(shù)成熟，有專業(yè)公司的技術(shù)支持
• 劣勢：可擴展性較差，無法較好支持海量數(shù)據(jù)存儲，數(shù)據(jù)模型過于死板、無法較好支持Web2.0應(yīng)用，事務(wù)機制影響了系統(tǒng)的整體性能等

NoSQL數(shù)據(jù)庫

• 優(yōu)勢：可以支持超大規(guī)模數(shù)據(jù)存儲，靈活的數(shù)據(jù)模型可以很好地支持Web2.0應(yīng)用，具有強大的橫向擴展能力等
• 劣勢：缺乏數(shù)學(xué)理論基礎(chǔ)，復(fù)雜查詢性能不高，大都不能實現(xiàn)事務(wù)強一致性，很難實現(xiàn)數(shù)據(jù)完整性，技術(shù)尚不成熟，缺乏專業(yè)團隊的技術(shù)支持，維護較困難等

5、NoSQL數(shù)據(jù)庫的四大類型

• 鍵值數(shù)據(jù)庫
  
• 列族數(shù)據(jù)庫
  
• 文檔數(shù)據(jù)庫
  
• 圖形數(shù)據(jù)庫
  

6、CAP

• C（Consistency）：一致性，是指任何一個讀操作總是能夠讀到之前完成的寫操作的結(jié)果，也就是在分布式環(huán)境中，多點的數(shù)據(jù)是一致的，或者說，所有節(jié)點在同一時間具有相同的數(shù)據(jù)；
• A:（Availability）：可用性，是指快速獲取數(shù)據(jù)，可以在確定的時間內(nèi)返回操作結(jié)果，保證每個請求不管成功或者失敗都有響應(yīng)；
• P（Tolerance of Network Partition）：分區(qū)容忍性，是指當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況時（即系統(tǒng)中的一部分節(jié)點無法和其他節(jié)點進行通信），分離的系統(tǒng)也能夠正常運行，也就是說，系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。
  

7、BASE

說起B(yǎng)ASE（Basically Availble, Soft-state, Eventual consistency），不得不談到ACID。

ACID的四性：

• A（Atomicity）：原子性，是指事務(wù)必須是原子工作單元，對于其數(shù)據(jù)修改，要么全都執(zhí)行，要么全都不執(zhí)行
• C（Consistency）：一致性，是指事務(wù)在完成時，必須使所有的數(shù)據(jù)都保持一致狀態(tài)
• I（Isolation）：隔離性，是指由并發(fā)事務(wù)所做的修改必須與任何其它并發(fā)事務(wù)所做的修改隔離
• D（Durability）：持久性，是指事務(wù)完成之后，它對于系統(tǒng)的影響是永久性的，該修改即使出現(xiàn)致命的系統(tǒng)故障也將一直保持
  
  BASE的基本含義：
  基本可用（Basically Availble）、軟狀態(tài)（Soft-state）、最終一致性（Eventual consistency）
• 基本可用：指一個分布式系統(tǒng)的一部分發(fā)生問題變得不可用時，其他部分仍然可以正常使用，也就是允許分區(qū)失敗的情形出現(xiàn)。
• 軟狀態(tài)：“軟狀態(tài)（soft-state）”是與“硬狀態(tài)（hard-state）”相對應(yīng)的一種提法。數(shù)據(jù)庫保存的數(shù)據(jù)是“硬狀態(tài)”時，可以保證數(shù)據(jù)一致性，即保證數(shù)據(jù)一直是正確的。“軟狀態(tài)”是指狀態(tài)可以有一段時間不同步，具有一定的滯后性。
• 最終一致性：
  一致性的類型包括強一致性和弱一致性，二者的主要區(qū)別在于高并發(fā)的數(shù)據(jù)訪問操作下，后續(xù)操作是否能夠獲取最新的數(shù)據(jù)。對于強一致性而言，當(dāng)執(zhí)行完一次更新操作后，后續(xù)的其他讀操作就可以保證讀到更新后的最新數(shù)據(jù)；反之，如果不能保證后續(xù)訪問讀到的都是更新后的最新數(shù)據(jù)，那么就是弱一致性。
  最終一致性是弱一致性的一種特例，允許后續(xù)的訪問操作可以暫時讀不到更新后的數(shù)據(jù)，但是經(jīng)過一段時間之后，必須最終讀到更新后的數(shù)據(jù)。

8、MongoDB的概念

第六章 云數(shù)據(jù)庫

1、概念

云數(shù)據(jù)庫是部署和虛擬化在云計算環(huán)境中的數(shù)據(jù)庫。云數(shù)據(jù)庫是在云計算的大背景下發(fā)展起來的一種新興的共享基礎(chǔ)架構(gòu)的方法，它極大地增強了數(shù)據(jù)庫的存儲能力，消除了人員、硬件、軟件的重復(fù)配置，讓軟、硬件升級變得更加容易。云數(shù)據(jù)庫具有高可擴展性、高可用性、采用多租形式和支持資源有效分發(fā)等特點。

2、特性

動態(tài)可擴展性、高可用性、較低的使用代價、易用性、高性能、免維護、安全。

第七章 MapReduce

1、傳統(tǒng)并行計算框架與MapReduce的區(qū)別

2、模型介紹

• MapReduce將復(fù)雜的、運行于大規(guī)模集群上的并行計算過程高度地抽象到了兩個函數(shù)：Map和Reduce。
• 編程容易，不需要掌握分布式并行編程細節(jié)，也可以很容易把自己的程序運行在分布式系統(tǒng)上，完成海量數(shù)據(jù)的計算。
• MapReduce采用“分而治之”策略，一個存儲在分布式文件系統(tǒng)中的大規(guī)模數(shù)據(jù)集，會被切分成許多獨立的分片（split），這些分片可以被多個Map任務(wù)并行處理。
• MapReduce設(shè)計的一個理念就是“計算向數(shù)據(jù)靠攏”，而不是“數(shù)據(jù)向計算靠攏”，因為，移動數(shù)據(jù)需要大量的網(wǎng)絡(luò)傳輸開銷。
• MapReduce框架采用了Master/Slave架構(gòu)，包括一個Master和若干個Slave。Master上運行JobTracker，Slave上運行TaskTracker。
• Hadoop框架是用Java實現(xiàn)的，但是，MapReduce應(yīng)用程序則不一定要用Java來寫。

3、Map函數(shù)和Reduce函數(shù)

4、MapReduce體系結(jié)構(gòu)

主要由四個部分組成，分別是：Client、JobTracker、TaskTracker以及Task。

• Client：用戶編寫的MapReduce程序通過Client提交到JobTracker端，用戶可通過Client提供的一些接口查看作業(yè)運行狀態(tài)。
• JobTracker：JobTracker負責(zé)資源監(jiān)控和作業(yè)調(diào)度，JobTracker監(jiān)控所有TaskTracker與Job的健康狀況，一旦發(fā)現(xiàn)失敗，就將相應(yīng)的任務(wù)轉(zhuǎn)移到其他節(jié)點，JobTracker會跟蹤任務(wù)的執(zhí)行進度、資源使用量等信息，并將這些信息告訴任務(wù)調(diào)度器（TaskScheduler），而調(diào)度器會在資源出現(xiàn)空閑時，選擇合適的任務(wù)去使用這些資源。
• TaskTracker：TaskTracker
  會周期性地通過“心跳”將本節(jié)點上資源的使用情況和任務(wù)的運行進度匯報給JobTracker，同時接收JobTracker發(fā)送過來的命令并執(zhí)行相應(yīng)的操作（如啟動新任務(wù)、殺死任務(wù)等），TaskTracker使用“slot”等量劃分本節(jié)點上的資源量（CPU、內(nèi)存等）。一個Task 獲取到一個slot后才有機會運行，而Hadoop調(diào)度器的作用就是將各個TaskTracker上的空閑slot分配給Task使用。slot 分為Mapslot 和Reduce slot 兩種，分別供MapTask 和Reduce Task 使用。
• Task：Task 分為Map Task 和Reduce Task 兩種，均由TaskTracker 啟動。

5、MapReduce的執(zhí)行過程

• 不同的Map任務(wù)之間不會進行通信
• 不同的Reduce任務(wù)之間也不會發(fā)生任何信息交換
• 用戶不能顯式地從一臺機器向另一臺機器發(fā)送消息
• 所有的數(shù)據(jù)交換都是通過MapReduce框架自身去實現(xiàn)的
  

6、分片

HDFS 以固定大小的block 為基本單位存儲數(shù)據(jù)，而對于MapReduce 而言，其處理單位是split。split 是一個邏輯概念，它只包含一些元數(shù)據(jù)信息，比如數(shù)據(jù)起始位置、數(shù)據(jù)長度、數(shù)據(jù)所在節(jié)點等。它的劃分方法完全由用戶自己決定。

7、任務(wù)數(shù)量

• Map任務(wù)的數(shù)量：Hadoop為每個split創(chuàng)建一個Map任務(wù)，split的多少決定了Map任務(wù)的數(shù)目。大多數(shù)情況下，理想的分片大小是一個HDFS塊
• Reduce任務(wù)的數(shù)量：最優(yōu)的Reduce任務(wù)個數(shù)取決于集群中可用的reduce任務(wù)槽(slot)的數(shù)目。通常設(shè)置比reduce任務(wù)槽數(shù)目稍微小一些的Reduce任務(wù)個數(shù)（這樣可以預(yù)留一些系統(tǒng)資源處理可能發(fā)生的錯誤）

第八章 Hadoop架構(gòu)再探討

1、Hadoop1.0的不足

• 抽象層次低，需人工編碼
• 表達能力有限
• 開發(fā)者自己管理作業(yè)（Job）之間的依賴關(guān)系
• 難以看到程序整體邏輯
• 執(zhí)行迭代操作效率低
• 資源浪費（Map和Reduce分兩階段執(zhí)行）
• 實時性差（適合批處理，不支持實時交互式）

2、Hadoop1.0到2.0的改進

3、HA工作原理

HDFS HA（High Availability）是為了解決單點故障問題。HA集群設(shè)置兩個名稱節(jié)點，“活躍（Active）”和“待命（Standby）”。兩種名稱節(jié)點的狀態(tài)同步，可以借助于一個共享存儲系統(tǒng)來實現(xiàn)。一旦活躍名稱節(jié)點出現(xiàn)故障，就可以立即切換到待命名稱節(jié)點。Zookeeper確保一個名稱節(jié)點在對外服務(wù)。名稱節(jié)點維護映射信息，數(shù)據(jù)節(jié)點同時向兩個名稱節(jié)點匯報信息

4、新一代資源管理調(diào)度框架YARN

ResourceManager

• 處理客戶端請求
• 啟動/監(jiān)控ApplicationMaster
• 監(jiān)控NodeManager
• 資源分配與調(diào)度

ApplicationMaster

• 為應(yīng)用程序申請資源，并分配給內(nèi)部任務(wù)
• 任務(wù)調(diào)度、監(jiān)控與容錯

NodeManager

• 單個節(jié)點上的資源管理
• 處理來自ResourceManger的命令
• 處理來自ApplicationMaster的命令

第九章Spark

1、spark的特點

運行速度快、容易使用、通用性、運行模式多樣

2、spark和Hadoop對比

• 使用Hadoop進行迭代計算非常耗資源
• Spark將數(shù)據(jù)載入內(nèi)存后，之后的迭代計算都可以直接使用內(nèi)存中的中間結(jié)果作運算，避免了從磁盤中頻繁讀取數(shù)據(jù)
• Spark基于DAG的任務(wù)調(diào)度執(zhí)行機制，要優(yōu)于Hadoop MapReduce的迭代執(zhí)行機制

3、spark設(shè)計理念

一個軟件棧滿足不同應(yīng)用場景

4、spark生態(tài)系統(tǒng)組件

5、spark中的基本概念

• RDD：是Resillient Distributed Dataset（彈性分布式數(shù)據(jù)集）的簡稱，是分布式內(nèi)存的一個抽象概念，提供了一種高度受限的共享內(nèi)存模型
• DAG：是Directed Acyclic Graph（有向無環(huán)圖）的簡稱，反映RDD之間的依賴關(guān)系
• Executor：是運行在工作節(jié)點（WorkerNode）的一個進程，負責(zé)運行Task
• Application：用戶編寫的Spark應(yīng)用程序
• Task：運行在Executor上的工作單元
• Job：一個Job包含多個RDD及作用于相應(yīng)RDD上的各種操作
• Stage：是Job的基本調(diào)度單位，一個Job會分為多組Task，每組Task被稱為Stage，或者也被稱為TaskSet，代表了一組關(guān)聯(lián)的、相互之間沒有Shuffle依賴關(guān)系的任務(wù)組成的任務(wù)集

6、spark運行基本流程

• 1、首先為應(yīng)用構(gòu)建起基本的運行環(huán)境，即由Driver創(chuàng)建一個SparkContext，進行資源的申請、任務(wù)的分配和監(jiān)控。
• 2、資源管理器為Executor分配資源，并啟動Executor進程。
• 3、SparkContext根據(jù)RDD的依賴關(guān)系構(gòu)建DAG圖，DAG圖提交給DAGScheduler解析成Stage，然后把一個個TaskSet提交給底層調(diào)度器TaskScheduler處理；Executor向SparkContext申請Task，Task
  Scheduler將Task發(fā)放給Executor運行，并提供應(yīng)用程序代碼。
• 4、Task在Executor上運行，把執(zhí)行結(jié)果反饋給TaskScheduler，然后反饋給DAGScheduler，運行完畢后寫入數(shù)據(jù)并釋放所有資源。

總體而言，Spark運行架構(gòu)具有以下特點：
（1）每個Application都有自己專屬的Executor進程，并且該進程在Application運行期間一直駐留。Executor進程以多線程的方式運行Task
（2）Spark運行過程與資源管理器無關(guān)，只要能夠獲取Executor進程并保持通信即可
（3）Task采用了數(shù)據(jù)本地性和推測執(zhí)行等優(yōu)化機制

7、RDD運行原理

• 1、RDD讀入外部數(shù)據(jù)源進行創(chuàng)建
• 2、RDD經(jīng)過一系列的轉(zhuǎn)換（Transformation）操作，每一次都會產(chǎn)生不同的RDD，供給下一個轉(zhuǎn)換操作使用
• 3、最后一個RDD經(jīng)過“動作”操作進行轉(zhuǎn)換，并輸出到外部數(shù)據(jù)源
  

8、RDD之間的依賴關(guān)系

• 窄依賴表現(xiàn)為一個父RDD的分區(qū)對應(yīng)于一個子RDD的分區(qū)或多個父RDD的分區(qū)對應(yīng)于一個子RDD的分區(qū)
• 寬依賴則表現(xiàn)為存在一個父RDD的一個分區(qū)對應(yīng)一個子RDD的多個分區(qū)

9、Stage的劃分

Spark通過分析各個RDD的依賴關(guān)系生成了DAG，再通過分析各個RDD中的分區(qū)之間的依賴關(guān)系來決定如何劃分Stage，具體劃分方法是：

• 在DAG中進行反向解析，遇到寬依賴就斷開
• 遇到窄依賴就把當(dāng)前的RDD加入到Stage中
• 將窄依賴盡量劃分在同一個Stage中，可以實現(xiàn)流水線計算

被分成三個Stage，在Stage2中，從map到union都是窄依賴，這兩步操作可以形成一個流水線操作

分區(qū)7通過map操作生成的分區(qū)9，可以不用等待分區(qū)8到分區(qū)10這個map操作的計算結(jié)束，而是繼續(xù)進行union操作，得到分區(qū)13，這樣流水線執(zhí)行大大提高了計算的效率。

Stage的類型

ShuffleMapStage和ResultStage
（1）ShuffleMapStage：在它之后還有其他Stage，它的輸出一定需要經(jīng)過Shuffle過程，并作為后續(xù)Stage的輸入；這種Stage是以Shuffle為輸出邊界，其輸入邊界可以是從外部獲取數(shù)據(jù)，也可以是另一個ShuffleMapStage的輸出，其輸出可以是另一個Stage的開始；在一個Job里可能有該類型的Stage，也可能沒有該類型Stage；
（2）ResultStage：最終的Stage，沒有輸出，而是直接產(chǎn)生結(jié)果或存儲。這種Stage是直接輸出結(jié)果，其輸入邊界可以是從外部獲取數(shù)據(jù)，也可以是另一個ShuffleMapStage的輸出。在一個Job里必定有該類型Stage。因此，一個Job含有一個或多個Stage，其中至少含有一個ResultStage。

10、RDD執(zhí)行過程

a、創(chuàng)建RDD對象；
b、SparkContext負責(zé)計算RDD之間的依賴關(guān)系，構(gòu)建DAG；
c、DAGScheduler負責(zé)把DAG圖分解成多個Stage，每個Stage中包含了多個Task，每個Task會被TaskScheduler分發(fā)給各個WorkerNode上的Executor去執(zhí)行。

11、spark SQL部署方式

• Standalone（類似于MapReduce1.0，slot為資源分配單位）
• Spark on Mesos（和Spark有血緣關(guān)系，更好支持Mesos）
• Spark on YARN

第十章 流計算

1、常見的流計算框架

商業(yè)級的流計算平臺（IBM …）、開源流計算框架（Twitter storm，yahoo）、公司為支持自身業(yè)務(wù)開發(fā)的流計算框架（Facebook，dstream）

2、流處理系統(tǒng)與傳統(tǒng)的數(shù)據(jù)處理系統(tǒng)有如下不同

• 流處理系統(tǒng)處理的是實時的數(shù)據(jù)，而傳統(tǒng)的數(shù)據(jù)處理系統(tǒng)處理的是預(yù)先存儲好的靜態(tài)數(shù)據(jù)。
• 用戶通過流處理系統(tǒng)獲取的是實時結(jié)果，而通過傳統(tǒng)的數(shù)據(jù)處理系統(tǒng)，獲取的是過去某一時刻的結(jié)果。
• 流處理系統(tǒng)無需用戶主動發(fā)出查詢，實時查詢服務(wù)可以主動將實時結(jié)果推送給用戶。

總結(jié)

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

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