大数据技术原理与应用——期末复习
大數據技術原理與應用
- 大數據技術原理與應用
- 第一章 大數據概述
- 1、大數據的4v特征
- 2、大數據的影響
- 3、大數據的兩大核心技術
- 4、大數據計算模式及代表產品
- 5、大數據與云計算、物聯網的關系
- 第二章 大數據處理架構Hadoop
- 1、Hadoop的發展歷史
- 2、Hadoop的特性
- 3、Hadoop1.0與Hadoop2.0的區別
- 4、Hadoop生態系統
- 5、Hadoop生態系統組件及功能
- 6、core-site.xml和hdfs-site.xml配置文件
- 第三章 分布式文件系統HDFS
- 1、分布式文件系統的結構
- 2、HDFS的局限性
- 3、塊的概念
- 4、名稱節點和數據節點
- 5、名稱節點的數據結構和啟動
- 6、數據節點
- 7、第二名稱節點
- 8、HDFS體系結構
- 9、HDFS通信協議
- 10、HDFS存儲原理
- 冗余數據保存
- 數據存取策略
- 數據錯誤的種類
- 11、HDFS常用命令
- 第四章 分布式數據庫HBase
- 1、HBase從BigTable說起
- 2、HBase和BigTable的底層技術對應關系：
- 3、HBase與傳統數據庫相比：
- 4、HBase數據模型
- 5、HBase的實現包含三個功能組件
- 6、HBase的三層結構
- 7、Region服務器工作原理
- 8、HLog工作原理
- 9、HBase性能優化的方法
- 10、HBase常見的shell命令
- 第五章 NoSQL
- 1、NoSQL的含義
- 2、NoSQL興起的原因
- 3、Web2.0的特點
- 4、NoSQL與關系數據庫對比
- 關系數據庫
- NoSQL數據庫
- 5、NoSQL數據庫的四大類型
- 6、CAP
- 7、BASE
- 8、MongoDB的概念
- 第六章 云數據庫
- 1、概念
- 2、特性
- 第七章 MapReduce
- 1、傳統并行計算框架與MapReduce的區別
- 2、模型介紹
- 3、Map函數和Reduce函數
- 4、MapReduce體系結構
- 5、MapReduce的執行過程
- 6、分片
- 7、任務數量
- 第八章 Hadoop架構再探討
- 1、Hadoop1.0的不足
- 2、Hadoop1.0到2.0的改進
- 3、HA工作原理
- 4、新一代資源管理調度框架YARN
- ResourceManager
- ApplicationMaster
- NodeManager
- 第九章Spark
- 1、spark的特點
- 2、spark和Hadoop對比
- 3、spark設計理念
- 4、spark生態系統組件
- 5、spark中的基本概念
- 6、spark運行基本流程
- 7、RDD運行原理
- 8、RDD之間的依賴關系
- 9、Stage的劃分
- Stage的類型
- 10、RDD執行過程
- 11、spark SQL部署方式
- 第十章 流計算
- 1、常見的流計算框架
- 2、流處理系統與傳統的數據處理系統有如下不同
大數據技術原理與應用
第一章 大數據概述
1、大數據的4v特征
volume大量化、velocity快速化、variety多樣化、value價值化
2、大數據的影響
- 思維方式方面：大數據完全顛覆了傳統的思維方式（全樣而非抽樣、效率而非精確、相關而非因果）。
- 社會發展方面：大數據決策逐漸成為一種新的決策方式，大數據應用有力促進了信息技術與各行業的深度融合，大數據開發大大推動了新技術和新應用的不斷涌現。
- 就業市場方面：大數據的興起使得數據科學家成為熱門職業。
- 人才培養方面：大數據的興起將在很大程度上改變中國高校信息技術相關專業的現有教學。
3、大數據的兩大核心技術
- 分布式存儲：GFS/HDFS、BigTable/HBase、NoSQL
- 分布式處理：MapReduce
4、大數據計算模式及代表產品
- 批處理計算：針對大規模數據的批量處理。MapReduce、Spark。
- 流計算：針對流數據的實時計算。Storm、S4、Flume、Streams、Puma、DStream、SuperMario、銀河流數據處理平臺。
- 圖計算：針對大規模圖結構數據的處理。Pregel、GraphX、Giraph、PowerGraph、Hama、GoldenOrb。
- 查詢分析計算：大規模數據的存儲管理和查詢分析。Dremel、Hive、Cassandra、Impala。
5、大數據與云計算、物聯網的關系
云計算、大數據和物聯網代表了IT領域最新的技術發展趨勢，三者相輔相成，既有聯系又有區別。
- 云計算為大數據提供了技術基礎；大數據為云計算提供用武之地。
- 云計算為物聯網提供海量數據存儲能力；物聯網為云計算技術提供了廣闊的應用空間。
- 物聯網是大數據的重要來源；大數據技術為物聯網數據分析提供支撐。
第二章 大數據處理架構Hadoop
1、Hadoop的發展歷史
Apache軟件基金會旗下的開源分布式平臺，基于Java語言開發，具有很好的跨平臺性，核心是分布式文件系統HDFS和MapReduce。Hadoop源自始于Apache Nutch項目。
2、Hadoop的特性
高可靠性、高效性、高可擴展性、高容錯性、成本低、運行在Linux平臺、支持多種編程語言。
3、Hadoop1.0與Hadoop2.0的區別
Hadoop2.0增加了HDFS HA和YARN兩個系統。
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>- hadoop.tmp.dir表示存放臨時數據的目錄，即包括NameNode的數據，也包括DataNode的數據。該路徑任意指定，只要實際存在該文件夾即可。
- name為fs.defaultFS的值，表示hdfs路徑的邏輯名稱。
- dfs.replication表示副本的數量，偽分布式要設置為1。
- dfs.namenode.name.dir表示本地磁盤目錄，是存儲fsimage文件的地方。
- dfs.datanode.data.dir表示本地磁盤目錄，HDFS數據存放block的地方。
第三章 分布式文件系統HDFS
1、分布式文件系統的結構
分布式文件系統把文件分布存儲到多個計算機節點上，成千上萬的計算機節點構成計算機集群。分布式文件系統在物理結構上是由計算機集群中的多個節點構成的，這些節點分為兩類，一類叫“主節點”(Master Node)或者也被稱為“名稱結點”(NameNode)，另一類叫“從節點”（Slave Node）或者也被稱為“數據節點”(DataNode)。
2、HDFS的局限性
不適合低延遲數據訪問、無法高效存儲大量小文件、不支持多用戶寫入及任意修改文件。
3、塊的概念
HDFS默認一個塊64MB，HDFS2.0后默認大小128MB。
塊的優點：
- 支持大規模文件存儲：一個文件的大小不會受到單個節點的存儲容量的限制，可以遠遠大于網絡中任意節點的存儲容量
- 簡化系統設計：大大簡化了存儲管理，方便了元數據的管理，元數據不需要和文件塊一起存儲，可以由其他系統負責管理元數據
- 適合數據備份：每個文件塊都可以冗余存儲到多個節點上，大大提高了系統的容錯性和可用性
4、名稱節點和數據節點
- 名稱節點：存儲元數據、元數據保存在內存中、保存文件，block，datanode之間的映射關系。
- 數據節點：存儲文件內容、文件內容保存在磁盤、維護了block id到datanode本地文件的映射關系。
5、名稱節點的數據結構和啟動
在HDFS中，名稱節點（NameNode）負責管理分布式文件系統的命名空間（Namespace），保存了兩個核心的數據結構，即FsImage和EditLog。
- FsImage用于維護文件系統樹以及文件樹中所有的文件和文件夾的元數據。
- 操作日志文件EditLog中記錄了所有針對文件的創建、刪除、重命名等操作。
- 名稱節點記錄了每個文件中各個塊所在的數據節點的位置信息
在名稱節點啟動的時候，它會將FsImage文件中的內容加載到內存中，之后再執行EditLog文件中的各項操作，使得內存中的元數據和實際的同步，存在內存中的元數據支持客戶端的讀操作。
一旦在內存中成功建立文件系統元數據的映射，則創建一個新的FsImage文件和一個空的EditLog文件。
名稱節點啟動之后，HDFS中的更新操作會重新寫到EditLog文件中，因為FsImage文件一般都很大（GB級別的很常見），如果所有的更新操作都往FsImage文件中添加，這樣會導致系統運行的十分緩慢，但是，如果往EditLog文件里面寫就不會這樣，因為EditLog 要小很多。每次執行寫操作之后，且在向客戶端發送成功代碼之前，edits文件都需要同步更新。
需要注意的是，名稱節點在啟動的過程中處于“安全模式”，只能對外提供讀操作，無法提供寫操作。啟動過程結束后，系統會退出安全模式，進入正常運行狀態，提供寫操作。
6、數據節點
數據節點是分布式文件系統HDFS的工作節點，負責數據的存儲和讀取，會根據客戶端或者是名稱節點的調度來進行數據的存儲和檢索，并且向名稱節點定期發送自己所存儲的塊的列表。每個數據節點中的數據會被保存在各自節點的本地Linux文件系統中。
7、第二名稱節點
在名稱節點運行期間，HDFS的所有更新操作都是直接寫到EditLog中，久而久之， EditLog文件將會變得很大。雖然這對名稱節點運行時候是沒有什么明顯影響的，但是，當名稱節點重啟的時候，名稱節點需要先將FsImage里面的所有內容映像到內存中，然后再一條一條地執行EditLog中的記錄，當EditLog文件非常大的時候，會導致名稱節點啟動操作非常慢，而在這段時間內HDFS系統處于安全模式，一直無法對外提供寫操作，影響用戶的使用。
第二名稱節點是HDFS架構中的一個組成部分，它是用來保存名稱節點中對HDFS 元數據信息的備份，并減少名稱節點重啟的時間。SecondaryNameNode一般是單獨運行在一臺機器上。
第二名稱節點的工作：
- 1、每隔一段時間，第二名稱節點會和名稱節點通信，請求其停止使用EditLog文件，暫時將新到達的寫操作添加到一個新文件EditLog.new中。
- 2、第二名稱節點把名稱中的FsImage文件和EditLog文件拉回本地，再加載到內存中。
- 3、對二者執行合并操作。在內存中逐條執行EditLog文件中的操作，使得FsImage保持最新。
- 4、合并結束后，第二名稱節點會把合并后得到的最新的FsImage文件發送到名稱節點。
- 5、名稱節點收到后，會用最新的FsImage文件替換舊的FsImage文件，同時用EditLog.new文件替換EditLog文件。
8、HDFS體系結構
HDFS采用了主從（Master/Slave）結構模型，一個HDFS集群包括一個名稱節點（NameNode）和若干個數據節點（DataNode）。名稱節點作為中心服務器，負責管理文件系統的命名空間及客戶端對文件的訪問。集群中的數據節點一般是一個節點運行一個數據節點進程，負責處理文件系統客戶端的讀/寫請求，在名稱節點的統一調度下進行數據塊的創建、刪除和復制等操作。每個數據節點的數據實際上是保存在本地Linux文件系統中的。
9、HDFS通信協議
- HDFS是一個部署在集群上的分布式文件系統，因此，很多數據需要通過網絡進行傳輸。
- 所有的HDFS通信協議都是構建在TCP/IP協議基礎之上的。
- 客戶端通過一個可配置的端口向名稱節點主動發起TCP連接，并使用客戶端協議與名稱節點進行交互。
- 名稱節點和數據節點之間則使用數據節點協議進行交互。
- 客戶端與數據節點的交互是通過RPC（Remote Procedure
Call）來實現的。在設計上，名稱節點不會主動發起RPC，而是響應來自客戶端和數據節點的RPC請求。
10、HDFS存儲原理
冗余數據保存
HDFS采用多副本方式對數據進行冗余存儲，通常一個數據塊的多個副本會被分布到不同的數據節點上。
優點：加快數據傳輸速度、容易檢查數據錯誤、保證數據可靠性。
數據存取策略
- 數據存放：
第一個副本：放置在上傳文件的數據節點；如果是集群外提交，則隨機挑選一臺磁盤不太滿、CPU不太忙的節點
第二個副本：放置在與第一個副本不同的機架的節點上
第三個副本：與第一個副本相同機架的其他節點上
更多副本：隨機節點 - 數據讀取：
HDFS提供了一個API可以確定一個數據節點所屬的機架ID，客戶端也可以調用API獲取自己所屬的機架ID。當客戶端讀取數據時，從名稱節點獲得數據塊不同副本的存放位置列表，列表中包含了副本所在的數據節點，可以調用API來確定客戶端和這些數據節點所屬的機架ID，當發現某個數據塊副本對應的機架ID和客戶端對應的機架ID相同時，就優先選擇該副本讀取數據，如果沒有發現，就隨機選擇一個副本讀取數據。
數據錯誤的種類
數據錯誤的三種：名稱節點出錯、數據節點出錯、數據出錯。
11、HDFS常用命令
- hadoop fs -ls <path>:顯示指定的文件的詳細信息
- hadoop fs -mkdir <path>:創建<path>指定的文件夾
- hadoop fs -cat <path>:將<path>指定的文件的內容輸出到標準輸出（stdout）
- hadoop fs -copyFromLocal <localsrc><dst>:將本地源文件<localsrc>復制到路徑<dst>指定的文件或文件夾中
第四章 分布式數據庫HBase
1、HBase從BigTable說起
BigTable是一個分布式存儲系統
2、HBase和BigTable的底層技術對應關系：
- 文件存儲系統：HDFS（HBase）和GFS（BigTable）
- 海量數據處理：Hadoop MapReduce（HBase）和MapReduce（BigTable）
- 協同服務管理：Zookeeper（HBase）和Chubby（BigTable）
3、HBase與傳統數據庫相比：
- 數據類型：關系數據庫采用關系模型，具有豐富的數據類型和存儲方式，HBase則采用了更加簡單的數據模型，它把數據存儲為未經解釋的字符串。
- 數據操作：關系數據庫中包含了豐富的操作，其中會涉及復雜的多表連接。HBase操作則不存在復雜的表與表之間的關系，只有簡單的插入、查詢、刪除、清空等，因為HBase在設計上就避免了復雜的表和表之間的關系。
- 存儲模式：關系數據庫是基于行模式存儲的。HBase是基于列存儲的，每個列族都由幾個文件保存，不同列族的文件是分離的。
- 數據索引：關系數據庫通常可以針對不同列構建復雜的多個索引，以提高數據訪問性能。HBase只有一個索引——行鍵，通過巧妙的設計，HBase中的所有訪問方法，或者通過行鍵訪問，或者通過行鍵掃描，從而使得整個系統不會慢下來。
- 數據維護：在關系數據庫中，更新操作會用最新的當前值去替換記錄中原來的舊值，舊值被覆蓋后就不會存在。而在HBase中執行更新操作時，并不會刪除數據舊的版本，而是生成一個新的版本，舊有的版本仍然保留。
- 可伸縮性：關系數據庫很難實現橫向擴展，縱向擴展的空間也比較有限。相反，HBase和BigTable這些分布式數據庫就是為了實現靈活的水平擴展而開發的，能夠輕易地通過在集群中增加或者減少硬件數量來實現性能的伸縮。
4、HBase數據模型
- 表：HBase采用表來組織數據，表由行和列組成，列劃分為若干個列族
- 行：每個HBase表都由若干行組成，每個行由行鍵（row key）來標識。
- 列族：一個HBase表被分組成許多“列族”（Column Family）的集合，它是基本的訪問控制單元
- 列限定符：列族里的數據通過列限定符（或列）來定位
- 單元格：在HBase表中，通過行、列族和列限定符確定一個“單元格”（cell），單元格中存儲的數據沒有數據類型，總被視為字節數組byte[]
- 時間戳：每個單元格都保存著同一份數據的多個版本，這些版本采用時間戳進行索引
HBase中需要根據行鍵、列族、列限定符和時間戳來確定一個單元格，因此，可以視為一個“四維坐標”，即[行鍵, 列族, 列限定符, 時間戳]
注意：HBase按列族進行物理存儲。
5、HBase的實現包含三個功能組件
- 庫函數：鏈接到每個客戶端
- Master主服務器：負責管理和維護HBase表的分區信息，維護Region服務器列表，分配Region，負載均衡
- Region服務器：負責存儲和維護分配給自己的Region，處理來自客戶端的讀寫請求
客戶端并不是直接從Master主服務器上讀取數據，而是在獲得Region的存儲位置信息后，直接從Region服務器上讀取數據。
客戶端并不依賴Master，而是通過Zookeeper來獲得Region位置信息，大多數客戶端甚至從來不和Master通信，這種設計方式使得Master負載很小 。
開始只有一個Region，后來不斷分裂。
Region拆分操作非常快，接近瞬間，因為拆分之后的Region讀取的仍然是原存儲文件，直到“合并”過程把存儲文件異步地寫到獨立的文件之后，才會讀取新文件。
6、HBase的三層結構
- 元數據表，又名.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性能優化的方法
- 行鍵：行鍵是按照字典序存儲，因此，設計行鍵時，要充分利用這個排序特點，將經常一起讀取的數據存儲到一塊，將最近可能會被訪問的數據放在一塊。
舉個例子：如果最近寫入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命令
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興起的原因
關系數據庫無法滿足海量數據的管理需求、數據高并發的需求、高可擴展性和高可用性的需求
3、Web2.0的特點
- 網站系統通常不要求嚴格的數據庫事務
- 不要求嚴格的讀寫實時性
- 通常不包含大量復雜的SQL查詢（去結構化，存儲空間換取更好的查詢性能）
4、NoSQL與關系數據庫對比
關系數據庫
- 優勢：以完善的關系代數理論作為基礎，有嚴格的標準，支持事務ACID四性，借助索引機制可以實現高效的查詢，技術成熟，有專業公司的技術支持
- 劣勢：可擴展性較差，無法較好支持海量數據存儲，數據模型過于死板、無法較好支持Web2.0應用，事務機制影響了系統的整體性能等
NoSQL數據庫
- 優勢：可以支持超大規模數據存儲，靈活的數據模型可以很好地支持Web2.0應用，具有強大的橫向擴展能力等
- 劣勢：缺乏數學理論基礎，復雜查詢性能不高，大都不能實現事務強一致性，很難實現數據完整性，技術尚不成熟，缺乏專業團隊的技術支持，維護較困難等
5、NoSQL數據庫的四大類型
- 鍵值數據庫
- 列族數據庫
- 文檔數據庫
- 圖形數據庫
6、CAP
- C（Consistency）：一致性，是指任何一個讀操作總是能夠讀到之前完成的寫操作的結果，也就是在分布式環境中，多點的數據是一致的，或者說，所有節點在同一時間具有相同的數據；
- A:（Availability）：可用性，是指快速獲取數據，可以在確定的時間內返回操作結果，保證每個請求不管成功或者失敗都有響應；
- P（Tolerance of Network Partition）：分區容忍性，是指當出現網絡分區的情況時（即系統中的一部分節點無法和其他節點進行通信），分離的系統也能夠正常運行，也就是說，系統中任意信息的丟失或失敗不會影響系統的繼續運作。
7、BASE
說起BASE（Basically Availble, Soft-state, Eventual consistency），不得不談到ACID。
ACID的四性：
- A（Atomicity）：原子性，是指事務必須是原子工作單元，對于其數據修改，要么全都執行，要么全都不執行
- C（Consistency）：一致性，是指事務在完成時，必須使所有的數據都保持一致狀態
- I（Isolation）：隔離性，是指由并發事務所做的修改必須與任何其它并發事務所做的修改隔離
- D（Durability）：持久性，是指事務完成之后，它對于系統的影響是永久性的，該修改即使出現致命的系統故障也將一直保持
BASE的基本含義：
基本可用（Basically Availble）、軟狀態（Soft-state）、最終一致性（Eventual consistency） - 基本可用：指一個分布式系統的一部分發生問題變得不可用時，其他部分仍然可以正常使用，也就是允許分區失敗的情形出現。
- 軟狀態：“軟狀態（soft-state）”是與“硬狀態（hard-state）”相對應的一種提法。數據庫保存的數據是“硬狀態”時，可以保證數據一致性，即保證數據一直是正確的。“軟狀態”是指狀態可以有一段時間不同步，具有一定的滯后性。
- 最終一致性：
一致性的類型包括強一致性和弱一致性，二者的主要區別在于高并發的數據訪問操作下，后續操作是否能夠獲取最新的數據。對于強一致性而言，當執行完一次更新操作后，后續的其他讀操作就可以保證讀到更新后的最新數據；反之，如果不能保證后續訪問讀到的都是更新后的最新數據，那么就是弱一致性。
最終一致性是弱一致性的一種特例，允許后續的訪問操作可以暫時讀不到更新后的數據，但是經過一段時間之后，必須最終讀到更新后的數據。
8、MongoDB的概念
第六章 云數據庫
1、概念
云數據庫是部署和虛擬化在云計算環境中的數據庫。云數據庫是在云計算的大背景下發展起來的一種新興的共享基礎架構的方法，它極大地增強了數據庫的存儲能力，消除了人員、硬件、軟件的重復配置，讓軟、硬件升級變得更加容易。云數據庫具有高可擴展性、高可用性、采用多租形式和支持資源有效分發等特點。
2、特性
動態可擴展性、高可用性、較低的使用代價、易用性、高性能、免維護、安全。
第七章 MapReduce
1、傳統并行計算框架與MapReduce的區別
2、模型介紹
- MapReduce將復雜的、運行于大規模集群上的并行計算過程高度地抽象到了兩個函數：Map和Reduce。
- 編程容易，不需要掌握分布式并行編程細節，也可以很容易把自己的程序運行在分布式系統上，完成海量數據的計算。
- MapReduce采用“分而治之”策略，一個存儲在分布式文件系統中的大規模數據集，會被切分成許多獨立的分片（split），這些分片可以被多個Map任務并行處理。
- MapReduce設計的一個理念就是“計算向數據靠攏”，而不是“數據向計算靠攏”，因為，移動數據需要大量的網絡傳輸開銷。
- MapReduce框架采用了Master/Slave架構，包括一個Master和若干個Slave。Master上運行JobTracker，Slave上運行TaskTracker。
- Hadoop框架是用Java實現的，但是，MapReduce應用程序則不一定要用Java來寫。
3、Map函數和Reduce函數
4、MapReduce體系結構
主要由四個部分組成，分別是：Client、JobTracker、TaskTracker以及Task。
- Client：用戶編寫的MapReduce程序通過Client提交到JobTracker端，用戶可通過Client提供的一些接口查看作業運行狀態。
- JobTracker：JobTracker負責資源監控和作業調度，JobTracker監控所有TaskTracker與Job的健康狀況，一旦發現失敗，就將相應的任務轉移到其他節點，JobTracker會跟蹤任務的執行進度、資源使用量等信息，并將這些信息告訴任務調度器（TaskScheduler），而調度器會在資源出現空閑時，選擇合適的任務去使用這些資源。
- TaskTracker：TaskTracker
會周期性地通過“心跳”將本節點上資源的使用情況和任務的運行進度匯報給JobTracker，同時接收JobTracker發送過來的命令并執行相應的操作（如啟動新任務、殺死任務等），TaskTracker使用“slot”等量劃分本節點上的資源量（CPU、內存等）。一個Task 獲取到一個slot后才有機會運行，而Hadoop調度器的作用就是將各個TaskTracker上的空閑slot分配給Task使用。slot 分為Mapslot 和Reduce slot 兩種，分別供MapTask 和Reduce Task 使用。 - Task：Task 分為Map Task 和Reduce Task 兩種，均由TaskTracker 啟動。
5、MapReduce的執行過程
- 不同的Map任務之間不會進行通信
- 不同的Reduce任務之間也不會發生任何信息交換
- 用戶不能顯式地從一臺機器向另一臺機器發送消息
- 所有的數據交換都是通過MapReduce框架自身去實現的
6、分片
HDFS 以固定大小的block 為基本單位存儲數據，而對于MapReduce 而言，其處理單位是split。split 是一個邏輯概念，它只包含一些元數據信息，比如數據起始位置、數據長度、數據所在節點等。它的劃分方法完全由用戶自己決定。
7、任務數量
- Map任務的數量：Hadoop為每個split創建一個Map任務，split的多少決定了Map任務的數目。大多數情況下，理想的分片大小是一個HDFS塊
- Reduce任務的數量：最優的Reduce任務個數取決于集群中可用的reduce任務槽(slot)的數目。通常設置比reduce任務槽數目稍微小一些的Reduce任務個數（這樣可以預留一些系統資源處理可能發生的錯誤）
第八章 Hadoop架構再探討
1、Hadoop1.0的不足
- 抽象層次低，需人工編碼
- 表達能力有限
- 開發者自己管理作業（Job）之間的依賴關系
- 難以看到程序整體邏輯
- 執行迭代操作效率低
- 資源浪費（Map和Reduce分兩階段執行）
- 實時性差（適合批處理，不支持實時交互式）
2、Hadoop1.0到2.0的改進
3、HA工作原理
HDFS HA（High Availability）是為了解決單點故障問題。HA集群設置兩個名稱節點，“活躍（Active）”和“待命（Standby）”。兩種名稱節點的狀態同步，可以借助于一個共享存儲系統來實現。一旦活躍名稱節點出現故障，就可以立即切換到待命名稱節點。Zookeeper確保一個名稱節點在對外服務。名稱節點維護映射信息，數據節點同時向兩個名稱節點匯報信息
4、新一代資源管理調度框架YARN
ResourceManager
- 處理客戶端請求
- 啟動/監控ApplicationMaster
- 監控NodeManager
- 資源分配與調度
ApplicationMaster
- 為應用程序申請資源，并分配給內部任務
- 任務調度、監控與容錯
NodeManager
- 單個節點上的資源管理
- 處理來自ResourceManger的命令
- 處理來自ApplicationMaster的命令
第九章Spark
1、spark的特點
運行速度快、容易使用、通用性、運行模式多樣
2、spark和Hadoop對比
- 使用Hadoop進行迭代計算非常耗資源
- Spark將數據載入內存后，之后的迭代計算都可以直接使用內存中的中間結果作運算，避免了從磁盤中頻繁讀取數據
- Spark基于DAG的任務調度執行機制，要優于Hadoop MapReduce的迭代執行機制
3、spark設計理念
一個軟件棧滿足不同應用場景
4、spark生態系統組件
5、spark中的基本概念
- 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依賴關系的任務組成的任務集
6、spark運行基本流程
- 1、首先為應用構建起基本的運行環境，即由Driver創建一個SparkContext，進行資源的申請、任務的分配和監控。
- 2、資源管理器為Executor分配資源，并啟動Executor進程。
- 3、SparkContext根據RDD的依賴關系構建DAG圖，DAG圖提交給DAGScheduler解析成Stage，然后把一個個TaskSet提交給底層調度器TaskScheduler處理；Executor向SparkContext申請Task，Task
Scheduler將Task發放給Executor運行，并提供應用程序代碼。 - 4、Task在Executor上運行，把執行結果反饋給TaskScheduler，然后反饋給DAGScheduler，運行完畢后寫入數據并釋放所有資源。
總體而言，Spark運行架構具有以下特點：
（1）每個Application都有自己專屬的Executor進程，并且該進程在Application運行期間一直駐留。Executor進程以多線程的方式運行Task
（2）Spark運行過程與資源管理器無關，只要能夠獲取Executor進程并保持通信即可
（3）Task采用了數據本地性和推測執行等優化機制
7、RDD運行原理
- 1、RDD讀入外部數據源進行創建
- 2、RDD經過一系列的轉換（Transformation）操作，每一次都會產生不同的RDD，供給下一個轉換操作使用
- 3、最后一個RDD經過“動作”操作進行轉換，并輸出到外部數據源
8、RDD之間的依賴關系
- 窄依賴表現為一個父RDD的分區對應于一個子RDD的分區或多個父RDD的分區對應于一個子RDD的分區
- 寬依賴則表現為存在一個父RDD的一個分區對應一個子RDD的多個分區
9、Stage的劃分
Spark通過分析各個RDD的依賴關系生成了DAG，再通過分析各個RDD中的分區之間的依賴關系來決定如何劃分Stage，具體劃分方法是：
- 在DAG中進行反向解析，遇到寬依賴就斷開
- 遇到窄依賴就把當前的RDD加入到Stage中
- 將窄依賴盡量劃分在同一個Stage中，可以實現流水線計算
被分成三個Stage，在Stage2中，從map到union都是窄依賴，這兩步操作可以形成一個流水線操作
分區7通過map操作生成的分區9，可以不用等待分區8到分區10這個map操作的計算結束，而是繼續進行union操作，得到分區13，這樣流水線執行大大提高了計算的效率。
Stage的類型
ShuffleMapStage和ResultStage
（1）ShuffleMapStage：在它之后還有其他Stage，它的輸出一定需要經過Shuffle過程，并作為后續Stage的輸入；這種Stage是以Shuffle為輸出邊界，其輸入邊界可以是從外部獲取數據，也可以是另一個ShuffleMapStage的輸出，其輸出可以是另一個Stage的開始；在一個Job里可能有該類型的Stage，也可能沒有該類型Stage；
（2）ResultStage：最終的Stage，沒有輸出，而是直接產生結果或存儲。這種Stage是直接輸出結果，其輸入邊界可以是從外部獲取數據，也可以是另一個ShuffleMapStage的輸出。在一個Job里必定有該類型Stage。因此，一個Job含有一個或多個Stage，其中至少含有一個ResultStage。
10、RDD執行過程
a、創建RDD對象；
b、SparkContext負責計算RDD之間的依賴關系，構建DAG；
c、DAGScheduler負責把DAG圖分解成多個Stage，每個Stage中包含了多個Task，每個Task會被TaskScheduler分發給各個WorkerNode上的Executor去執行。
11、spark SQL部署方式
- Standalone（類似于MapReduce1.0，slot為資源分配單位）
- Spark on Mesos（和Spark有血緣關系，更好支持Mesos）
- Spark on YARN
第十章 流計算
1、常見的流計算框架
商業級的流計算平臺（IBM …）、開源流計算框架（Twitter storm，yahoo）、公司為支持自身業務開發的流計算框架（Facebook，dstream）
2、流處理系統與傳統的數據處理系統有如下不同
- 流處理系統處理的是實時的數據，而傳統的數據處理系統處理的是預先存儲好的靜態數據。
- 用戶通過流處理系統獲取的是實時結果，而通過傳統的數據處理系統，獲取的是過去某一時刻的結果。
- 流處理系統無需用戶主動發出查詢，實時查詢服務可以主動將實時結果推送給用戶。
總結
以上是生活随笔為你收集整理的大数据技术原理与应用——期末复习的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Anaconda 安装操作及遇到的坑
- 下一篇： MyBatis官方下载地址（含mybat