概要介紹

??????? 大數(shù)據(jù)整理。
往期文章
數(shù)據(jù)可視化思維導(dǎo)圖
網(wǎng)頁設(shè)計整理歸納

[Linux系統(tǒng)編程/網(wǎng)絡(luò)編程] 筆記目錄
[STL]六大組件介紹（目錄 全）
[計算機網(wǎng)絡(luò)]筆記+題庫解析目錄[2021]

文章目錄

• 第一章
• • 1. 大數(shù)據(jù)的4個v
  • 2. 大數(shù)據(jù)的影響
  • 3. 大數(shù)據(jù)的兩大核心技術(shù)及對應(yīng)關(guān)系
  • 4. 產(chǎn)品對應(yīng)關(guān)系
  • 5. 三者關(guān)系
• 第二章
• • 1. hadoop最初是創(chuàng)始人Doug Cutting 開發(fā)的文本搜索庫，hadoop源自于2002年的Apache Nutch項目
  • 2. hadoop分布式處理的軟件框架 ，特性如下
  • 3. Apache hadoop 版本演變 1.0-》2.0
  • 4. hadoop生態(tài)系統(tǒng)
  • 5. hadoop項目組建功能
  • 6. 配置文件 core-site.xml hdfs-site.xml 參數(shù)（屬性）理解
• 第三章
• • 1. 總而言之 HDFS實現(xiàn)以下目標(biāo)
  • 2. HDFS特殊的設(shè)置，使得本身具有一些應(yīng)用局限性
  • 3.塊的概念
  • 4. HDFS主要組件的功能 （名稱節(jié)點 數(shù)據(jù)節(jié)點）（課本更詳細(xì)）
  • 5. 名稱節(jié)點的數(shù)據(jù)結(jié)構(gòu)
  • 6. 第二名稱節(jié)點：
  • 7. 第二名稱節(jié)點的工作流程（個人概括）
  • 8. HDFS體系機構(gòu)概述
  • 9. HDFS通信協(xié)議
  • 10. 多副本方式冗余數(shù)據(jù)的保存
  • 11. 數(shù)據(jù)存儲策略（重點）
  • 12. 數(shù)據(jù)錯誤與恢復(fù)（名稱節(jié)點出錯 數(shù)據(jù)節(jié)點出錯 數(shù)據(jù)出錯）（了解）
  • 13. HDFS數(shù)據(jù)讀寫操作（背）(待補充)
• 第四章
• • 1. 從BigTable說起
  • 2. HBase 和BigTable的底層技術(shù)對應(yīng)關(guān)系
  • 3. HBase與傳統(tǒng)關(guān)系數(shù)據(jù)庫的對比分析
  • 4. HBase數(shù)據(jù)模型概述
  • 5. HBase功能組件及各組件功能（注意區(qū)別HDFS）
  • 6. HBase的三層結(jié)構(gòu)（名稱+各自作用）
  • 7. Region服務(wù)器工作原理(理解)
  • 8 .HLog工作原理
  • 9 .HBase實際應(yīng)用中的性能優(yōu)化方法
  • 10 . HBase常用Shell命令
• 第五章
• • 1 . NoSQL簡介
  • 2 NoSQL數(shù)據(jù)庫具有以下幾個特點：
  • 3 NoSQL興起的原因（兩個大點）
  • 4 . NoSQL與關(guān)系數(shù)據(jù)庫的比較（表格簡單比較）
  • 5 . NoSQL與關(guān)系數(shù)據(jù)庫的比較各自優(yōu)缺點
  • 6 .NoSQL與關(guān)系數(shù)據(jù)庫的應(yīng)用場景
  • 7 .NoSQL的四大類型
  • 8 . 關(guān)注四類數(shù)據(jù)庫的相關(guān)產(chǎn)品，典型應(yīng)用，優(yōu)點，缺點（其它了解）
  • 9 .CAP指的是什么，說明了什么(重點)
  • 10 .ACID的四個性質(zhì)
  • 11 BASE的基本含義（不確定部分）
  • 12 .MongoDB概念解析（注意SQL->MongoDB中的對應(yīng)關(guān)系）
• 第六章
• • 1 . 云數(shù)據(jù)庫的概念
  • 2 . 云數(shù)據(jù)庫的特性
  • 3 .云數(shù)據(jù)庫廠商概述，（企業(yè)->產(chǎn)品）對應(yīng)關(guān)系
• 第七章
• • 1 . MapReduce和傳統(tǒng)的并行計算框架比對及其優(yōu)勢（要求能寫出對應(yīng)位置的比對）
  • 2 .MapReduce模型簡介（兩個特點）
  • 3 .Map和Reduce函數(shù)的含義
  • 4 .MapReduce的體系框架及其各部分功能
  • 5 .MapReduce各個執(zhí)行階段
  • 6 .關(guān)于Split(分片)的相關(guān)概念
  • 7 .Map任務(wù)的數(shù)量（取決于split）
  • 8 .Reduce任務(wù)的數(shù)量
  • 9 .代碼(待補充) 三個方面
• 第八章
• • 1 . Hadoop1.0的局限和不足
  • 2 . 針對Hadoop的改進(jìn)與提升，hadoop框架從1.0->2.0
  • 3 .HDFS HA 相關(guān)信息（如何工作？？？）
  • 4 .YARN設(shè)計思路( 具體ppt 8.3.2筆記 )
  • 5 .YARN體系結(jié)構(gòu)( 具體ppt 8.3.3筆記 )
  • 6 .YARN發(fā)展目標(biāo)
• 第九章
• • 1 .spark的特點（注意支持語言）
  • 2 .Scala的特性(了解)
  • 3 .Hadoop 存在如下一些缺點
  • 4 .Spark與Hadoop 的對比(主要說明Spark優(yōu)點)
  • 5 . spark設(shè)計理念（可再具體參考ppt）
  • 6 .spark的生態(tài)系統(tǒng)包含的幾大組件
  • 7 .spark的生態(tài)系統(tǒng)組件的應(yīng)用場景
  • 8 .基本概念（見ppt）
  • 9 .Spark運行基本流程
  • 10 .RDD運行原理（注意黑體）
  • 11 .RDD的特性（高效計算的原因）
  • 12 .RDD的依賴關(guān)系（窄依賴 寬依賴 ）
  • 13 .RDD在Spark運行過程
  • 14 .Shark到sql流程（待補充）
  • 15 . Spark SQL中的 Catalyst
  • 16 .Spark 三種部署方式
  • 16 .Spark RDD 的基本操作（待補充）
• 最后更新時間2020/1/8
• 總結(jié)

第一章

1. 大數(shù)據(jù)的4個v

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

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

在思維方式方面：大數(shù)據(jù)完全顛覆了傳統(tǒng)的思維方式：全樣而非抽樣、效率而非精確、相關(guān)而非因果
在社會發(fā)展方面：大數(shù)據(jù)決策逐漸成為一種新的決策方式，大數(shù)據(jù)應(yīng)用有力促進(jìn)了信息技術(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ù)及對應(yīng)關(guān)系

• 分布式存儲（GFS HDFS NOSQL NewSQL）
• 分布式處理（MapReduce Sparlk）

4. 產(chǎn)品對應(yīng)關(guān)系

5. 三者關(guān)系

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

第二章

1. hadoop最初是創(chuàng)始人Doug Cutting 開發(fā)的文本搜索庫，hadoop源自于2002年的Apache Nutch項目

2. hadoop分布式處理的軟件框架 ，特性如下

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

3. Apache hadoop 版本演變 1.0-》2.0

，即增加了分布式資源調(diào)度管理框架YARN 和 HDFS HA

4. hadoop生態(tài)系統(tǒng)

5. hadoop項目組建功能

6. 配置文件 core-site.xml hdfs-site.xml 參數(shù)（屬性）理解

<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>

其中 name 標(biāo)簽表示配置項的名稱 value 表示配置的值。
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的地方

第三章

1. 總而言之 HDFS實現(xiàn)以下目標(biāo)

- 兼容廉價的硬件設(shè)備- 流數(shù)據(jù)讀寫- 大數(shù)據(jù)集- 簡單的文件模型- 強大的跨平臺兼容性

2. HDFS特殊的設(shè)置，使得本身具有一些應(yīng)用局限性

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

3.塊的概念

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

4. HDFS主要組件的功能 （名稱節(jié)點 數(shù)據(jù)節(jié)點）（課本更詳細(xì)）

名稱節(jié)點

• 負(fù)責(zé)管理分布式文件系統(tǒng)的命名空間，保存了兩個核心的數(shù)據(jù)結(jié)構(gòu)，即FsImage 和 EditLog
• 記錄了每個文件中各個塊所在的數(shù)據(jù)節(jié)點和位置信息
• 存儲元數(shù)據(jù)
• 元數(shù)據(jù)保存在內(nèi)存中
• 保存文件block，datanode之間的映射關(guān)系
• 管理客戶端對文件的訪問

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

• 數(shù)據(jù)節(jié)點是分布式文件系統(tǒng)HDFS的工作節(jié)點，負(fù)責(zé)數(shù)據(jù)的存儲和讀取，會根據(jù)客戶端或者名稱節(jié)點的調(diào)度來驚醒數(shù)據(jù)的存儲和檢索，并且向名稱節(jié)點定期發(fā)送自己所存儲的塊的列表
• 存儲文本內(nèi)容
• 文件內(nèi)容保存在磁盤
• 維護(hù)了block id 到 datanode本地文件的映射關(guān)系
  
  

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

名稱節(jié)點負(fù)責(zé)管理分布式文件系統(tǒng)的命名空間，保存了兩個核心的數(shù)據(jù)結(jié)構(gòu)，即FsImage EditLog并且名稱節(jié)點記錄了每個文件中各個塊所在的數(shù)據(jù)節(jié)點的位置信息。

FsImage用于維護(hù)文件系統(tǒng)樹以及文件樹中所有的文件和文件夾的元數(shù)據(jù)

操作日志文件EditLog中記錄了所有針對文件的創(chuàng)建、刪除、重命名等操作

6. 第二名稱節(jié)點：

第二名稱節(jié)點是HDFS架構(gòu)中的一個組成部分，它是用來保存名稱節(jié)點中對HDFS元數(shù)據(jù)信息的備份，并減少名稱節(jié)點重啟的時間。SecondaryNameNode一般是單獨運行在一臺機器上。
補充
（所有更新操作寫入Editlog，導(dǎo)致過大，每次名稱節(jié)點重啟的時候把Fsimage里面所有內(nèi)容映射到內(nèi)存，再一條一條執(zhí)行EditLog中的記錄會非常的慢當(dāng)Editlog文件非常大）（引出第二名稱節(jié)點）

7. 第二名稱節(jié)點的工作流程（個人概括）

• 第二名稱節(jié)點定期要求名稱節(jié)點停止使用editlog文件
• 將新的寫操作寫在edit.new
• 第二名稱節(jié)點通過get方式獲取FsImage和Editlog
• FsImage加載內(nèi)存，Editlog執(zhí)行文件中的更新操作，合并為新的FsImage
• 新的FsImage通過post發(fā)送到名稱節(jié)點替換舊的，而edit.new替換為新的Editlog

8. HDFS體系機構(gòu)概述

修改時間：2021/1/10 第一點

client 向名稱節(jié)點發(fā)送文件寫入請求，名稱節(jié)點根據(jù)文件的大小和文件塊的配置情況，返回給client它所管理的datanode的信息，client將文件劃分成多個block，根據(jù)數(shù)據(jù)節(jié)點的信息，按照順序?qū)懭氲矫恳粋€數(shù)據(jù)節(jié)點塊中。

HDFS采用的是主從（Master/Slave）結(jié)構(gòu)模型，一個HDFS集群包括一個名稱節(jié)點和若干個數(shù)據(jù)節(jié)點

數(shù)據(jù)節(jié)點的數(shù)據(jù)保存在本地Linux文件系統(tǒng)中

數(shù)據(jù)節(jié)點會周期性向名稱節(jié)點發(fā)送“心跳信息”

9. HDFS通信協(xié)議

概述：

• HDFS是一個部署在集群上的分布式文件系統(tǒng)，因此很多數(shù)據(jù)需要通過網(wǎng)絡(luò)進(jìn)行傳輸
• 所有的HDFS通信協(xié)議都是構(gòu)建在TCP/IP協(xié)議基礎(chǔ)之上的

10. 多副本方式冗余數(shù)據(jù)的保存

目的：為了保證系統(tǒng)的容錯性和可用性
優(yōu)點：加快數(shù)據(jù)傳輸速度

• 加快數(shù)據(jù)傳輸速度

• 容易檢查數(shù)據(jù)錯誤

• 保證數(shù)據(jù)可靠性
  什么是多副本：通常一個數(shù)據(jù)塊的多個副本會被分布到不同的數(shù)據(jù)節(jié)點
  

11. 數(shù)據(jù)存儲策略（重點）

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

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

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

• 更多副本：隨機節(jié)點
  

12. 數(shù)據(jù)錯誤與恢復(fù)（名稱節(jié)點出錯 數(shù)據(jù)節(jié)點出錯 數(shù)據(jù)出錯）（了解）

名稱節(jié)點出錯
????
名稱節(jié)點保存了所有的元數(shù)據(jù)信息，其中，最核心的兩大數(shù)據(jù)結(jié)構(gòu)是FsImage和Editlog，如果這兩個文件發(fā)生損壞，那么整個HDFS實例將失效。因此，HDFS設(shè)置了備份機制，把這些核心文件同步復(fù)制到備份服務(wù)器SecondaryNameNode上。當(dāng)名稱節(jié)點出錯時，就可以根據(jù)備份服務(wù)器SecondaryNameNode中的FsImage和Editlog數(shù)據(jù)進(jìn)行恢復(fù)。

數(shù)據(jù)節(jié)點出錯
????

• 每個數(shù)據(jù)節(jié)點會定期向名稱節(jié)點發(fā)送“心跳”信息，向名稱節(jié)點報告自己的狀態(tài)
• 當(dāng)數(shù)據(jù)節(jié)點發(fā)生故障，或者網(wǎng)絡(luò)發(fā)生斷網(wǎng)時，名稱節(jié)點就無法收到來自一些數(shù)據(jù)節(jié)點的心跳信息，這時，這些數(shù)據(jù)節(jié)點就會被標(biāo)記為“宕機”，節(jié)點上面的所有數(shù)據(jù)都會被標(biāo)記為“不可讀”，名稱節(jié)點不會再給它們發(fā)送任何I/O請求
• 這時，有可能出現(xiàn)一種情形，即由于一些數(shù)據(jù)節(jié)點的不可用，會導(dǎo)致一些數(shù)據(jù)塊的副本數(shù)量小于冗余因子
• 名稱節(jié)點會定期檢查這種情況，一旦發(fā)現(xiàn)某個數(shù)據(jù)塊的副本數(shù)量小于冗余因子，就會啟動數(shù)據(jù)冗余復(fù)制，為它生成新的副本
• HDFS和其它分布式文件系統(tǒng)的最大區(qū)別就是可以調(diào)整冗余數(shù)據(jù)的位置

數(shù)據(jù)錯誤
????

• 網(wǎng)絡(luò)傳輸和磁盤錯誤等因素，都會造成數(shù)據(jù)錯誤
• 客戶端在讀取到數(shù)據(jù)后，會采用md5和sha1對數(shù)據(jù)塊進(jìn)行校驗，以確定讀取到正確的數(shù)據(jù)
• 在文件被創(chuàng)建時，客戶端就會對每一個文件塊進(jìn)行信息摘錄，并把這些信息寫入到同一個路徑的隱藏文件里面
• 當(dāng)客戶端讀取文件的時候，會先讀取該信息文件，然后，利用該信息文件對每個讀取的數(shù)據(jù)塊進(jìn)行校驗，如果校驗出錯，客戶端就會請求到另外一個數(shù)據(jù)節(jié)點讀取該文件塊，并且向名稱節(jié)點報告這個文件塊有錯誤，名稱節(jié)點會定期檢查并且重新復(fù)制這個塊

13. HDFS數(shù)據(jù)讀寫操作（背）(待補充)

HDFS有很多命令，其中fs命令可以說是HDFS最常用的命令，利用fs命令可以查看HDFS文件系統(tǒng)的目錄結(jié)構(gòu)、上傳和下載數(shù)據(jù)、創(chuàng)建文件信息等。該命令的用法如下
hadoop fs [genericOptions] [commandOptions]

第四章

1. 從BigTable說起

• BigTable是一個分布式存儲系統(tǒng)
• BigTable起初是用于解決典型的互聯(lián)網(wǎng)搜索問題

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

3. HBase與傳統(tǒng)關(guān)系數(shù)據(jù)庫的對比分析

HBase與傳統(tǒng)的關(guān)系數(shù)據(jù)庫的區(qū)別主要體現(xiàn)在以下幾個方面：

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

補充 ：HBase數(shù)據(jù)的物理視圖—按列族進(jìn)行物理存儲

5. HBase功能組件及各組件功能（注意區(qū)別HDFS）

• 庫函數(shù)：鏈接到每個客戶端
• 一個Master主服務(wù)器
• 許多個Region服務(wù)器

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

6. HBase的三層結(jié)構(gòu)（名稱+各自作用）

什么是region：表示一個分區(qū)，包含了位于某個值域區(qū)間內(nèi)的所有數(shù)據(jù)，它是負(fù)載均衡和數(shù)據(jù)分發(fā)的基本單位，初始時候，一個表只有一個Region,隨著數(shù)據(jù)插入，持續(xù)變多

• 元數(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里面寫入一個標(biāo)記
  ②每次刷寫都生成一個新的StoreFile文件，因此，每個Store包含多個StoreFile文件
  ③每個Region服務(wù)器都有一個自己的HLog 文件，每次啟動都檢查該文件，確認(rèn)最近一次執(zhí)行緩存刷新操作之后是否發(fā)生新的寫入操作；如果發(fā)現(xiàn)更新，則先寫入MemStore，再刷寫到StoreFile，最后刪除舊的Hlog文件，開始為用戶提供服務(wù)
• StoreFile的合并：①每次刷寫都生成一個新的StoreFile，數(shù)量太多，影響查找速度
  ②調(diào)用Store.compact()把多個合并成一個
  ③合并操作比較耗費資源，只有數(shù)量達(dá)到一個閾值才啟動合并

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ù)進(jìn)行拆分，分別放到相應(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īng)用中的性能優(yōu)化方法

• 行鍵（Row Key）：行鍵是按照字典序存儲，因此，設(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命令

查看命令的使用描述

語法：help ‘命令名’

返回hbase版本信息

語法：version

列出hbase中存在的所有表

語法：list

創(chuàng)建表

語法：create ‘表名’, ‘列族名1’, ‘列族名2’, ‘列族名N’

添加或修改的表的值（列名=列限定符 注意：）

put ‘表名’, ‘行鍵’, ‘列族名:列名’, ‘列值’

通過對表的掃描來獲取對用的值

語法：
1 scan ‘表名’
2 掃描某個列族： scan ‘表名’, {COLUMN=>‘列族名’}
3 掃描某個列族的某個列： scan ‘表名’, {COLUMN=>‘列族名:列名’}
4 查詢同一個列族的多個列： scan ‘表名’, {COLUMNS => [ ‘列族名1:列名1’, ‘列族名1:列名2’, …]}

獲取行或單元（cell）的值

語法：
get ‘表名’, ‘行鍵’
get ‘表名’, ‘行鍵’, ‘列族名’

使表有效（使表無效）

語法：
enable ‘表名’ disable ‘表名’

刪除表

語法：
drop的表必須是disable的
disable ‘表名’
drop ‘表名’

第五章

1 . NoSQL簡介

• 最初表示“反SQL"運動 - > 現(xiàn)在表示關(guān)系和非關(guān)系式數(shù)據(jù)庫各有優(yōu)缺點彼此都無法相互取代

2 NoSQL數(shù)據(jù)庫具有以下幾個特點：

• 靈活的可擴展性
• 靈活的數(shù)據(jù)模型
• 與云計算緊密融合

3 NoSQL興起的原因（兩個大點）

（1） 關(guān)系數(shù)據(jù)庫無法滿足web2.0的需求

• 無法滿足海量數(shù)據(jù)的管理需求

• 無法滿足數(shù)據(jù)高并發(fā)的需求

• 無法滿足高可擴展性和高可用性的需求
  （2）關(guān)系數(shù)據(jù)庫的關(guān)鍵特性包括完善的事務(wù)機制和高效的查詢機制,但是到了Web2.0時代兩個關(guān)鍵特性卻成了雞肋，主要表現(xiàn)在以下幾個方面

• Web2.0網(wǎng)站系統(tǒng)通常不要求嚴(yán)格的數(shù)據(jù)庫事務(wù)

• Web2.0并不要求嚴(yán)格的讀寫實時性

• Web2.0通常不包含大量復(fù)雜的SQL查詢（去結(jié)構(gòu)化，存儲空間換取更好的查詢性能）

4 . NoSQL與關(guān)系數(shù)據(jù)庫的比較（表格簡單比較）

5 . NoSQL與關(guān)系數(shù)據(jù)庫的比較各自優(yōu)缺點

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

（2）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è)團(tuán)隊的技術(shù)支持，維護(hù)較困難等

6 .NoSQL與關(guān)系數(shù)據(jù)庫的應(yīng)用場景

關(guān)系數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫各有優(yōu)缺點，彼此無法取代

關(guān)系數(shù)據(jù)庫應(yīng)用場景： 電信、銀行等領(lǐng)域的關(guān)鍵業(yè)務(wù)系統(tǒng)，需要保證強事務(wù)一致性
NoSQL數(shù)據(jù)庫應(yīng)用場景：互聯(lián)網(wǎng)企業(yè)、傳統(tǒng)企業(yè)的非關(guān)鍵業(yè)務(wù)（比如數(shù)據(jù)分析）

7 .NoSQL的四大類型

• 文檔數(shù)據(jù)庫（mongoDB）
• 圖數(shù)據(jù)庫（Neo4j）
• 鍵值數(shù)據(jù)庫（redis）
• 列族數(shù)據(jù)庫（HBase）
  

8 . 關(guān)注四類數(shù)據(jù)庫的相關(guān)產(chǎn)品，典型應(yīng)用，優(yōu)點，缺點（其它了解）

鍵值數(shù)據(jù)庫

列族數(shù)據(jù)庫

文檔數(shù)據(jù)庫

圖形數(shù)據(jù)庫

9 .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é)點進(jìn)行通信），分離的系統(tǒng)也能夠正常運行，也就是說，系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。

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

10 .ACID的四個性質(zhì)

• 原子性
• 一致性
• 隔離性
• 持久性

一個數(shù)據(jù)庫事務(wù)具有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)故障也將一直保持

11 BASE的基本含義（不確定部分）

• 基本可用（Basically Availble）

• 軟狀態(tài)（Soft-state）

• 最終一致性（Eventual consistency）
  一致性的類型包括強一致性和弱一致性，二者的主要區(qū)別在于高并發(fā)的數(shù)據(jù)訪問操作下，后續(xù)操作是否能夠獲取最新的數(shù)據(jù)。對于強一致性而言，當(dāng)執(zhí)行完一次更新操作后，后續(xù)的其他讀操作就可以保證讀到更新后的最新數(shù)據(jù)；反之，如果不能保證后續(xù)訪問讀到的都是更新后的最新數(shù)據(jù)，那么就是弱一致性。

12 .MongoDB概念解析（注意SQL->MongoDB中的對應(yīng)關(guān)系）

概述：在mongodb中基本的概念是文檔、集合、數(shù)據(jù)庫

第六章

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

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

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

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

3 .云數(shù)據(jù)庫廠商概述，（企業(yè)->產(chǎn)品）對應(yīng)關(guān)系

第七章

1 . MapReduce和傳統(tǒng)的并行計算框架比對及其優(yōu)勢（要求能寫出對應(yīng)位置的比對）

2 .MapReduce模型簡介（兩個特點）

• MapReduce采用“分而治之”策略，一個存儲在分布式文件系統(tǒng)中的大規(guī)模數(shù)據(jù)集，會被切分成許多獨立的分片（split），這些分片可以被多個Map任務(wù)并行處理。
• MapReduce設(shè)計的一個理念就是“計算向數(shù)據(jù)靠攏”，而不是“數(shù)據(jù)向計算靠攏”，因為，移動數(shù)據(jù)需要大量的網(wǎng)絡(luò)傳輸開銷。

3 .Map和Reduce函數(shù)的含義

4 .MapReduce的體系框架及其各部分功能

概述： MapReduce體系結(jié)構(gòu)主要由四個部分組成，分別是：Client、JobTracker、TaskTracker以及Task

• Client

  • 用戶編寫的MapReduce程序通過Client提交到JobTracker端
  • 用戶可通過Client提供的一些接口查看作業(yè)運行狀態(tài)

• JobTracker

  • JobTracker負(fù)責(zé)資源監(jiān)控和作業(yè)調(diào)度
  • JobTracker 監(jiān)控所有TaskTracker與Job的健康狀況，一旦發(fā)現(xiàn)失敗，就將相應(yīng)的任務(wù)轉(zhuǎn)移到其他節(jié)點
  • JobTracker 會跟蹤任務(wù)的執(zhí)行進(jìn)度、資源使用量等信息，并將這些信息告訴任務(wù)調(diào)度器，而調(diào)度器會在資源出現(xiàn)空閑時，選擇合適的任務(wù)去使用這些資源

• TaskTracker

  • TaskTracker 會周期性地通過“心跳”將本節(jié)點上資源的使用情況和任務(wù)的運行進(jìn)度匯報給JobTracker，同時接收J(rèn)obTracker 發(fā)送過來的命令并執(zhí)行相應(yīng)的操作（如啟動新任務(wù)、殺死任務(wù)等）
  • TaskTracker 使用“slot”等量劃分本節(jié)點上的資源量（CPU、內(nèi)存等）。一個Task 獲取到一個slot 后才有機會運行，而Hadoop調(diào)度器的作用就是將各個TaskTracker上的空閑slot分配給Task使用。slot 分為Map slot 和Reduce slot 兩種，分別供MapTask 和Reduce Task 使用

• Task

  • Task 分為Map Task 和Reduce Task 兩種，均由TaskTracker 啟動

5 .MapReduce各個執(zhí)行階段

6 .關(guān)于Split(分片)的相關(guān)概念

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

7 .Map任務(wù)的數(shù)量（取決于split）

Hadoop為每個split創(chuàng)建一個Map任務(wù)，split 的多少決定了Map任務(wù)的數(shù)目。大多數(shù)情況下，理想的分片大小是一個HDFS塊

8 .Reduce任務(wù)的數(shù)量

• 最優(yōu)的Reduce任務(wù)個數(shù)取決于集群中可用的reduce任務(wù)槽(slot) 的數(shù)目
• 通常設(shè)置比reduce任務(wù)槽數(shù)目稍微小一些的Reduce任務(wù)個數(shù)（這樣可以預(yù)留一些系統(tǒng)資源處理可能發(fā)生的錯誤）

9 .代碼(待補充) 三個方面

第八章

1 . Hadoop1.0的局限和不足

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

2 . 針對Hadoop的改進(jìn)與提升，hadoop框架從1.0->2.0

3 .HDFS HA 相關(guān)信息（如何工作？？？）

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

4 .YARN設(shè)計思路( 具體ppt 8.3.2筆記 )

5 .YARN體系結(jié)構(gòu)( 具體ppt 8.3.3筆記 )

ResourceManager

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

NodeManager

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

ApplicationMaster

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

6 .YARN發(fā)展目標(biāo)

YARN的目標(biāo)就是實現(xiàn)“一個集群多個框架”

第九章

1 .spark的特點（注意支持語言）

• 運行速度快：使用DAG執(zhí)行引擎以支持循環(huán)數(shù)據(jù)流與內(nèi)存計算

• 容易使用：支持使用Scala、Java、Python和R語言進(jìn)行編程，可以通過Spark Shell進(jìn)行交互式編程

• 通用性：Spark提供了完整而強大的技術(shù)棧，包括SQL查詢、流式計算、機器學(xué)習(xí)和圖算法組件

• 運行模式多樣：可運行于獨立的集群模式中，可運行于Hadoop中，也可運行于Amazon EC2等云環(huán)境中，并且可以訪問HDFS、Cassandra、HBase、Hive等多種數(shù)據(jù)源

2 .Scala的特性(了解)

• Scala具備強大的并發(fā)性，支持函數(shù)式編程，可以更好地支持分布式系統(tǒng)
• Scala語法簡潔，能提供優(yōu)雅的API
• Scala兼容Java，運行速度快，且能融合到Hadoop生態(tài)圈中

3 .Hadoop 存在如下一些缺點

• 表達(dá)能力有限
• 磁盤IO開銷大
• 延遲高
  • 任務(wù)之間的銜接涉及IO開銷
  • 在前一個任務(wù)執(zhí)行完成之前，其他任務(wù)就無法開始，難以勝任
  • 復(fù)雜、多階段的計算任務(wù)

4 .Spark與Hadoop 的對比(主要說明Spark優(yōu)點)

• Spark的計算模式也屬于MapReduce，但不局限于Map和Reduce操作，還提供了多種數(shù)據(jù)集操作類型，編程模型比Hadoop MapReduce更靈活
• Spark提供了內(nèi)存計算，可將中間結(jié)果放到內(nèi)存中，對于迭代運算效率更高
• Spark基于DAG的任務(wù)調(diào)度執(zhí)行機制，要優(yōu)于Hadoop MapReduce的迭代執(zhí)行機制

5 . spark設(shè)計理念（可再具體參考ppt）

一個軟件棧滿足不同應(yīng)用場景，spark所提供的生態(tài)系統(tǒng)足矣應(yīng)對同時支持批處理、交互式查詢和流數(shù)據(jù)處理三種場景。

補充：數(shù)據(jù)的流處理可以理解為系統(tǒng)需要接收并處理一系列連續(xù)不斷變化的數(shù)據(jù)

補充：數(shù)據(jù)的批處理，可以理解為一系列相關(guān)的任務(wù)按順序或并行的，一個接一個地執(zhí)行。批處理地輸入是在一段時間內(nèi)收集好地數(shù)據(jù)。每次批處理地輸出都可以是下次批處理地輸入。

6 .spark的生態(tài)系統(tǒng)包含的幾大組件

• Spark Core
• Spark SQL
• Spark Streaming
• MLLib
• GraphX

7 .spark的生態(tài)系統(tǒng)組件的應(yīng)用場景

8 .基本概念（見ppt）

• RDD：是Resillient Distributed
  Dataset（彈性分布式數(shù)據(jù)集）的簡稱，是分布式內(nèi)存的一個抽象概念，提供了一種高度受限的共享內(nèi)存模型
• DAG：是Directed Acyclic Graph（有向無環(huán)圖）的簡稱，反映RDD之間的依賴關(guān)系
• Executor：是運行在工作節(jié)點（WorkerNode）的一個進(jìn)程，負(fù)責(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ù)集

9 .Spark運行基本流程

• 首先為應(yīng)用構(gòu)建起基本的運行環(huán)境，即由Driver創(chuàng)建一個SparkContext，進(jìn)行資源的申請、任務(wù)的分配和監(jiān)控
• 資源管理器為Executor分配資源，并啟動Executor進(jìn)程
• 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)用程序代碼
• Task在Executor上運行，把執(zhí)行結(jié)果反饋給TaskScheduler，然后反饋給DAGScheduler，運行完畢后寫入數(shù)據(jù)并釋放所有資源
  

10 .RDD運行原理（注意黑體）

補充：
行動：執(zhí)行計算并指定輸出的類型
轉(zhuǎn)換：指定RDD之間的相互依賴關(guān)系

• 一個RDD就是一個分布式對象集合，本質(zhì)上是一個只讀的分區(qū)記錄集合，每個RDD可分成多個分區(qū)，每個分區(qū)就是一個數(shù)據(jù)集片段，并且一個RDD的不同分區(qū)可以被保存到集群中不同的節(jié)點上，從而可以在集群中的不同節(jié)點上進(jìn)行并行計算
• RDD提供了一種高度受限的共享內(nèi)存模型，即RDD是只讀的記錄分區(qū)的集合，不能直接修改，只能基于穩(wěn)定的物理存儲中的數(shù)據(jù)集創(chuàng)建RDD，或者通過在其他RDD上執(zhí)行確定的轉(zhuǎn)換操作（如map、join和group
  by）而創(chuàng)建得到新的RDD
• RDD提供了一組豐富的操作以支持常見的數(shù)據(jù)運算，分為“動作”（Action）和“轉(zhuǎn)換”（Transformation）兩種類型
• RDD提供的轉(zhuǎn)換接口都非常簡單，都是類似map、filter、groupBy、join等粗粒度的數(shù)據(jù)轉(zhuǎn)換操作，而不是針對某個數(shù)據(jù)項的細(xì)粒度修改（不適合網(wǎng)頁爬蟲）
• 表面上RDD的功能很受限、不夠強大，實際上RDD已經(jīng)被實踐證明可以高效地表達(dá)許多框架的編程模型（比如MapReduce、SQL、Pregel）
• Spark用Scala語言實現(xiàn)了RDD的API，程序員可以通過調(diào)用API實現(xiàn)對RDD的各種操作
  

11 .RDD的特性（高效計算的原因）

• 高效的容錯性
  • 現(xiàn)有容錯機制：數(shù)據(jù)復(fù)制或者記錄日志
  • RDD：血緣關(guān)系、重新計算丟失分區(qū)、無需回滾系統(tǒng)、重算過程在不同節(jié)點之間并行、只記錄粗粒度的操作
• 中間結(jié)果持久化到內(nèi)存，數(shù)據(jù)在內(nèi)存中的多個RDD操作之間進(jìn)行傳遞，避免了不必要的讀寫磁盤開銷
• 存放的數(shù)據(jù)可以是Java對象，避免了不必要的對象序列化和反序列化

12 .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ū)
  

13 .RDD在Spark運行過程

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

14 .Shark到sql流程（待補充）

15 . Spark SQL中的 Catalyst

Spark SQL在Hive兼容層面僅依賴HiveQL解析、Hive元數(shù)據(jù)，也就是說，從HQL被解析成抽象語法樹（AST）起，就全部由Spark SQL接管了。Spark SQL執(zhí)行計劃生成和優(yōu)化都由Catalyst（函數(shù)式關(guān)系查詢優(yōu)化框架）負(fù)責(zé)

16 .Spark 三種部署方式

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

16 .Spark RDD 的基本操作（待補充）

最后更新時間2020/1/8

總結(jié)

??文章純屬期末復(fù)習(xí)整理，如有不足和錯誤的地方，希望評論指出或私信。
最后希望給文章點個贊，整理不易！！！
最后希望給文章點個贊，整理不易！！！
最后希望給文章點個贊，整理不易！！！

總結(jié)

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

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