概要介紹

??????? 大數據整理。
往期文章
數據可視化思維導圖
網頁設計整理歸納

[Linux系統編程/網絡編程] 筆記目錄
[STL]六大組件介紹（目錄 全）
[計算機網絡]筆記+題庫解析目錄[2021]

文章目錄

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

第一章

1. 大數據的4個v

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

2. 大數據的影響

在思維方式方面：大數據完全顛覆了傳統的思維方式：全樣而非抽樣、效率而非精確、相關而非因果
在社會發展方面：大數據決策逐漸成為一種新的決策方式，大數據應用有力促進了信息技術與各行業的深度融合，大數據開發大大推動了新技術和新應用的不斷涌現。
在就業市場方面：大數據的興起使得數據科學家成為熱門職業。
在人才培養方面：大數據的興起，將在很大程度上改變中國高校信息技術相關專業的現有教學和科研體制。

3. 大數據的兩大核心技術及對應關系

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

4. 產品對應關系

5. 三者關系

：云計算、大數據和物聯網代表了IT領域最新的技術發展趨勢，三者相輔相成，既有聯系又有區別

第二章

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

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

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

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

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

4. hadoop生態系統

5. hadoop項目組建功能

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>

其中 name 標簽表示配置項的名稱 value 表示配置的值。
hadoop.tmp.dir表示存放臨時數據的目錄，即包括NameNode的數據，也包括DataNode的數據。該路徑任意指定，只要實際存在該文件夾即可
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表示副本的數量，偽分布式要設置為1
dfs.namenode.name.dir表示本地磁盤目錄，是存儲fsimage文件的地方
dfs.datanode.data.dir表示本地磁盤目錄，HDFS數據存放block的地方

第三章

1. 總而言之 HDFS實現以下目標

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

2. HDFS特殊的設置，使得本身具有一些應用局限性

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

3.塊的概念

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

4. HDFS主要組件的功能 （名稱節點 數據節點）（課本更詳細）

名稱節點

• 負責管理分布式文件系統的命名空間，保存了兩個核心的數據結構，即FsImage 和 EditLog
• 記錄了每個文件中各個塊所在的數據節點和位置信息
• 存儲元數據
• 元數據保存在內存中
• 保存文件block，datanode之間的映射關系
• 管理客戶端對文件的訪問

數據節點：

• 數據節點是分布式文件系統HDFS的工作節點，負責數據的存儲和讀取，會根據客戶端或者名稱節點的調度來驚醒數據的存儲和檢索，并且向名稱節點定期發送自己所存儲的塊的列表
• 存儲文本內容
• 文件內容保存在磁盤
• 維護了block id 到 datanode本地文件的映射關系
  
  

5. 名稱節點的數據結構

名稱節點負責管理分布式文件系統的命名空間，保存了兩個核心的數據結構，即FsImage EditLog并且名稱節點記錄了每個文件中各個塊所在的數據節點的位置信息。

FsImage用于維護文件系統樹以及文件樹中所有的文件和文件夾的元數據

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

6. 第二名稱節點：

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

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

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

8. HDFS體系機構概述

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

client 向名稱節點發送文件寫入請求，名稱節點根據文件的大小和文件塊的配置情況，返回給client它所管理的datanode的信息，client將文件劃分成多個block，根據數據節點的信息，按照順序寫入到每一個數據節點塊中。

HDFS采用的是主從（Master/Slave）結構模型，一個HDFS集群包括一個名稱節點和若干個數據節點

數據節點的數據保存在本地Linux文件系統中

數據節點會周期性向名稱節點發送“心跳信息”

9. HDFS通信協議

概述：

• HDFS是一個部署在集群上的分布式文件系統，因此很多數據需要通過網絡進行傳輸
• 所有的HDFS通信協議都是構建在TCP/IP協議基礎之上的

10. 多副本方式冗余數據的保存

目的：為了保證系統的容錯性和可用性
優點：加快數據傳輸速度

• 加快數據傳輸速度

• 容易檢查數據錯誤

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

11. 數據存儲策略（重點）

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

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

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

• 更多副本：隨機節點
  

12. 數據錯誤與恢復（名稱節點出錯 數據節點出錯 數據出錯）（了解）

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

數據節點出錯
????

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

數據錯誤
????

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

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

HDFS有很多命令，其中fs命令可以說是HDFS最常用的命令，利用fs命令可以查看HDFS文件系統的目錄結構、上傳和下載數據、創建文件信息等。該命令的用法如下
hadoop fs [genericOptions] [commandOptions]

第四章

1. 從BigTable說起

• BigTable是一個分布式存儲系統
• BigTable起初是用于解決典型的互聯網搜索問題

2. HBase 和BigTable的底層技術對應關系

3. HBase與傳統關系數據庫的對比分析

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

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

4. HBase數據模型概述

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

補充 ：HBase數據的物理視圖—按列族進行物理存儲

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

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

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

6. HBase的三層結構（名稱+各自作用）

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

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

7. Region服務器工作原理(理解)

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

8 .HLog工作原理

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

9 .HBase實際應用中的性能優化方法

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

10 . HBase常用Shell命令

查看命令的使用描述

語法：help ‘命令名’

返回hbase版本信息

語法：version

列出hbase中存在的所有表

語法：list

創建表

語法：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"運動 - > 現在表示關系和非關系式數據庫各有優缺點彼此都無法相互取代

2 NoSQL數據庫具有以下幾個特點：

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

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

（1） 關系數據庫無法滿足web2.0的需求

• 無法滿足海量數據的管理需求

• 無法滿足數據高并發的需求

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

• Web2.0網站系統通常不要求嚴格的數據庫事務

• Web2.0并不要求嚴格的讀寫實時性

• Web2.0通常不包含大量復雜的SQL查詢（去結構化，存儲空間換取更好的查詢性能）

4 . NoSQL與關系數據庫的比較（表格簡單比較）

5 . NoSQL與關系數據庫的比較各自優缺點

（1）關系數據庫
優勢：以完善的關系代數理論作為基礎，有嚴格的標準，支持事務ACID四性，借助索引機制可以實現高效的查詢，技術成熟，有專業公司的技術支持
劣勢：可擴展性較差，無法較好支持海量數據存儲，數據模型過于死板、無法較好支持Web2.0應用，事務機制影響了系統的整體性能等

（2）NoSQL數據庫
優勢：可以支持超大規模數據存儲，靈活的數據模型可以很好地支持Web2.0應用，具有強大的橫向擴展能力等
劣勢：缺乏數學理論基礎，復雜查詢性能不高，大都不能實現事務強一致性，很難實現數據完整性，技術尚不成熟，缺乏專業團隊的技術支持，維護較困難等

6 .NoSQL與關系數據庫的應用場景

關系數據庫和NoSQL數據庫各有優缺點，彼此無法取代

關系數據庫應用場景： 電信、銀行等領域的關鍵業務系統，需要保證強事務一致性
NoSQL數據庫應用場景：互聯網企業、傳統企業的非關鍵業務（比如數據分析）

7 .NoSQL的四大類型

• 文檔數據庫（mongoDB）
• 圖數據庫（Neo4j）
• 鍵值數據庫（redis）
• 列族數據庫（HBase）
  

8 . 關注四類數據庫的相關產品，典型應用，優點，缺點（其它了解）

鍵值數據庫

列族數據庫

文檔數據庫

圖形數據庫

9 .CAP指的是什么，說明了什么(重點)

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

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

10 .ACID的四個性質

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

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

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

• 基本可用（Basically Availble）

• 軟狀態（Soft-state）

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

12 .MongoDB概念解析（注意SQL->MongoDB中的對應關系）

概述：在mongodb中基本的概念是文檔、集合、數據庫

第六章

1 . 云數據庫的概念

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

2 . 云數據庫的特性

• 動態可擴展
• 高可用性
• 較低的使用代價
• 易用性
• 高性能
• 免維護
• 安全

3 .云數據庫廠商概述，（企業->產品）對應關系

第七章

1 . MapReduce和傳統的并行計算框架比對及其優勢（要求能寫出對應位置的比對）

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

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

3 .Map和Reduce函數的含義

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

概述： MapReduce體系結構主要由四個部分組成，分別是：Client、JobTracker、TaskTracker以及Task

• Client

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

• JobTracker

  • JobTracker負責資源監控和作業調度
  • JobTracker 監控所有TaskTracker與Job的健康狀況，一旦發現失敗，就將相應的任務轉移到其他節點
  • JobTracker 會跟蹤任務的執行進度、資源使用量等信息，并將這些信息告訴任務調度器，而調度器會在資源出現空閑時，選擇合適的任務去使用這些資源

• TaskTracker

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

• Task

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

5 .MapReduce各個執行階段

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

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

7 .Map任務的數量（取決于split）

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

8 .Reduce任務的數量

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

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

第八章

1 . Hadoop1.0的局限和不足

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

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

3 .HDFS HA 相關信息（如何工作？？？）

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

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

5 .YARN體系結構( 具體ppt 8.3.3筆記 )

ResourceManager

• 處理客戶端請求
• 啟動/監控ApplicationMaster
• 監控NodeManager
• 資源分配與調度

NodeManager

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

ApplicationMaster

• 為應用程序申請資源，并分配給內部任務 任務調度、監控與容錯

6 .YARN發展目標

YARN的目標就是實現“一個集群多個框架”

第九章

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

• 運行速度快：使用DAG執行引擎以支持循環數據流與內存計算

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

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

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

2 .Scala的特性(了解)

• Scala具備強大的并發性，支持函數式編程，可以更好地支持分布式系統
• Scala語法簡潔，能提供優雅的API
• Scala兼容Java，運行速度快，且能融合到Hadoop生態圈中

3 .Hadoop 存在如下一些缺點

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

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

• Spark的計算模式也屬于MapReduce，但不局限于Map和Reduce操作，還提供了多種數據集操作類型，編程模型比Hadoop MapReduce更靈活
• Spark提供了內存計算，可將中間結果放到內存中，對于迭代運算效率更高
• Spark基于DAG的任務調度執行機制，要優于Hadoop MapReduce的迭代執行機制

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

一個軟件棧滿足不同應用場景，spark所提供的生態系統足矣應對同時支持批處理、交互式查詢和流數據處理三種場景。

補充：數據的流處理可以理解為系統需要接收并處理一系列連續不斷變化的數據

補充：數據的批處理，可以理解為一系列相關的任務按順序或并行的，一個接一個地執行。批處理地輸入是在一段時間內收集好地數據。每次批處理地輸出都可以是下次批處理地輸入。

6 .spark的生態系統包含的幾大組件

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

7 .spark的生態系統組件的應用場景

8 .基本概念（見ppt）

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

9 .Spark運行基本流程

• 首先為應用構建起基本的運行環境，即由Driver創建一個SparkContext，進行資源的申請、任務的分配和監控
• 資源管理器為Executor分配資源，并啟動Executor進程
• SparkContext根據RDD的依賴關系構建DAG圖，DAG圖提交給DAGScheduler解析成Stage，然后把一個個TaskSet提交給底層調度器TaskScheduler處理；Executor向SparkContext申請Task，Task
  Scheduler將Task發放給Executor運行，并提供應用程序代碼
• Task在Executor上運行，把執行結果反饋給TaskScheduler，然后反饋給DAGScheduler，運行完畢后寫入數據并釋放所有資源
  

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

補充：
行動：執行計算并指定輸出的類型
轉換：指定RDD之間的相互依賴關系

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

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

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

12 .RDD的依賴關系（窄依賴 寬依賴 ）

• 窄依賴表現為一個父RDD的分區對應于一個子RDD的分區或多個父RDD的分區對應于一個子RDD的分區
• 寬依賴則表現為存在一個父RDD的一個分區對應一個子RDD的多個分區
  

13 .RDD在Spark運行過程

• 創建RDD對象；
• SparkContext負責計算RDD之間的依賴關系，構建DAG；
• DAGScheduler負責把DAG圖分解成多個Stage，每個Stage中包含了多個Task，每個Task會被TaskScheduler分發給各個WorkerNode上的Executor去執行

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

15 . Spark SQL中的 Catalyst

Spark SQL在Hive兼容層面僅依賴HiveQL解析、Hive元數據，也就是說，從HQL被解析成抽象語法樹（AST）起，就全部由Spark SQL接管了。Spark SQL執行計劃生成和優化都由Catalyst（函數式關系查詢優化框架）負責

16 .Spark 三種部署方式

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

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

最后更新時間2020/1/8

總結

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

總結

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

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