大數據技術概述複習（一）

大數據技術概述複習（一）

本文整理複習自用，僅供參考

引用：

1《大數據技術原理與應用（第3版）》

2 https://blog.csdn.net/weixin_45207388/article/details/102933958

3 https://buwenbuhuo.blog.csdn.net/article/details/105690566

1.大數據的四大特點（4V）

Volume（大量）

根據IDC作出的估測，數據一直都在以每年50%的速度增長，也就是說每兩年就增長一倍（大數據摩爾定律）

人類在最近兩年產生的數據量相當於之前產生的全部數據量

預計到2020年，全球將總共擁有35ZB的數據量，相較於2010年，數據量將增長近30倍

Velocity（高速）

這是大數據區於傳統數據挖掘的最顯著特徵。

從數據的生成到消耗，時間窗口非常小，可用於生成決策的時間非常少

Variety（多樣）

相對於以往便儲存的以數據庫/文本爲主的結構化數據，非結構化數據越來越多，包括網絡日誌、音頻、視頻、圖片、地理位置信息等。這些多類型的數據對數據的處理能力提出了更高要求。

Value（低價值密度）

價值密度低，商業價值高。

2.大數據兩大核心技術

2.1分佈式存儲

2.1.1概述

大數據時代的到來促成了分佈式文件系統：

*數據更新快、數據量大、數據種類多、數據來源廣，傳統的單機存儲系統無法適應。

• 互聯網上一分鐘內有3萬小時的音樂播放記錄
• 43萬次維基百科頁面的訪問記錄
• 4百萬條谷歌搜索記錄
• 單臺計算機磁盤無法存放海量數據

於是出現了分佈式存儲

將海量數據分配到多個操作系統管理的磁盤中進行存儲。

2.1.2分佈式文件系統

特點

• 數據分塊，分佈式的存儲在多臺機器上。
• 各個節點可分佈在不同地點，通過網絡進行節點間的通信和數據傳輸。
• 節點符合主從結構，主節點存儲元數據，從節點存儲時間數據。
• 數據塊冗餘存儲在多臺機器以提高數據塊的高可用性。
• 用戶調用數據時，不用關心數據在從節點的存儲位置，客戶端向主節點發送請求即可。
  
  

2.2分佈式計算

2.2.1概述

分佈式計算簡單來說，是把一個大計算任務拆分成多個小計算任務分佈到若干臺機器上去計算，然後再進行結果彙總。

目的在於分析計算海量的數據，從雷達監測的海量歷史信號中分析異常信號，淘寶雙十一實時計算各地區的消費習慣等。

海量計算最開始的方案是提高單機計算性能，如大型機，後來由於數據的爆發式增長、單機性能卻跟不上，纔有分佈式計算這種妥協方案。 因爲計算一旦拆分，問題會變得非常複雜，像一致性、數據完整、通信、容災、任務調度等問題也都來了。

2.2.2計算過程概覽

3.Hadoop及其生態圈

Hadoop生態圈基本上是爲了處理超過單機尺度的數據處理而誕生的。

可以把生態圈比作一個廚房所需要的各種工具：鍋碗瓢盆，各有各的用處，互相之間又有重合。你可以用湯鍋直接當碗喫飯喝湯，你也可以用小刀或者刨子去皮。每個工具都有自己的特性，也能組合起來工作，但要達到最佳效果，則需要一番努力。

3.1 Hadoop

Hadoop是Apache軟件基金會旗下的一個開源分佈式計算平臺，爲用戶提供了系統底層細節透明的分佈式基礎架構

• Hadoop是基於Java語言開發的，具有很好的跨平臺特性，並且可以部署在廉價的計算機集羣中
• Hadoop的核心是分佈式文件系統HDFS（Hadoop Distributed File System）和MapReduce
• Hadoop被公認爲行業大數據標準開源軟件，在分佈式環境下提供了海量數據的處理能力

幾乎所有主流廠商都圍繞Hadoop提供開發工具、開源軟件、商業化工具和技術服務，如谷歌、雅虎、微軟、思科、淘寶等，都支持Hadoop

​ Hadoop是一個能夠對大量數據進行分佈式處理的軟件框架，並且是以一種可靠、高效、可伸縮的方式進行處理的，它具有以下幾個方面的特性：

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

3.1.1版本演變

• Apache Hadoop版本分爲兩代，我們將第一代Hadoop稱爲Hadoop 1.0，第二代Hadoop稱爲Hadoop 2.0
• 第一代Hadoop包含三個大版本，分別是0.20.x，0.21.x和0.22.x，其中，0.20.x最後演化成1.0.x，變成了穩定版，而0.21.x和0.22.x則增加了NameNode HA等新的重大特性
• 第二代Hadoop包含兩個版本，分別是0.23.x和2.x，它們完全不同於Hadoop 1.0，是一套全新的架構，均包含HDFS Federation和YARN兩個系統，相比於0.23.x，2.x增加了NameNode HA和Wire-compatibility兩個重大特性

3.1.1.1 YARN

Apache Hadoop YARN （Yet Another Resource Negotiator，另一種資源協調者）是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統和調度平臺，可爲上層應用提供統一的資源管理和調度。

它的引入爲集羣在利用率、資源統一管理和數據共享等方面帶來了巨大好處。

我們可以把yarn理解爲相當於一個分佈式的操作系統平臺，而mapreduce等運算程序則相當於運行於操作系統之上的應用程序，Yarn爲這些程序提供運算所需的資源（CPU，內存，磁盤等）。

同時大家需要了解以下幾點:

• yarn並不清楚用戶提交的程序的運行機制
• yarn只提供運算資源的調度（用戶程序向yarn申請資源，yarn就負責分配資源）
• yarn中的主管角色叫ResourceManager
• yarn中具體提供運算資源的角色叫NodeManager
• yarn與運行的用戶程序完全解耦，意味着yarn上可以運行各種類型的分佈式運算程序，比如mapreduce、storm，spark等
• spark、storm等運算框架都可以整合在yarn上運行，只要他們各自的框架中有符合yarn規範的資源請求機制即可
• yarn成爲一個通用的資源調度平臺.企業中以前存在的各種運算集羣都可以整合在一個物理集羣上，提高資源利用率，方便數據共享

3.1.2配置文件

僞分佈式安裝需要修改的配置文件

1.修改配置文件 core-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路徑的邏輯名稱

2.修改配置文件 hdfs-site.xml

<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的地方

3.2 Hadoop-分佈式文件系統HDFS

首先你要能存的下大數據。

HDFS（Hadoop Distributed File System）的設計本質上是爲了大量的數據能橫跨成百上千臺機器，但是你看到的是一個文件系統而不是很多文件系統。

比如你說我要獲取路徑爲“/hdfs/tmp/file1”的數據，你可以只用引用一個文件路徑，但是實際的數據存放在很多不同的機器上。

你作爲用戶，不需要知道這些，就好比在單機上你不關心文件分散在什麼磁道什麼扇區一樣。HDFS爲你透明地管理這些分佈式的數據。

總體而言，HDFS要實現以下目標：

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

3.2.1HDFS分塊存儲

HDFS將所有的文件全部抽象成爲block塊來進行存儲，不管文件大小，全部一視同仁都是以block塊的統一大小和形式進行存儲，方便我們的分佈式文件系統對文件的管理。

塊的默認大小在Hadoop2.x版本中是128M，老版本爲64M。block塊的大小可以通過hdfs-site.xml當中的配置文件進行指定。

<property>
     <name>dfs.block.size</name>
     <value>塊大小 以字節爲單位</value>  //只寫數值就可以
</property> 

抽象成數據塊的好處

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

​ ● 支持大規模文件存儲：文件以塊爲單位進行存儲，一個大規模文件可以被分拆成若干個文件塊，不同的文件塊可以被分發到不同的節點上，

因此，一個文件的大小不會受到單個節點的存儲容量的限制，可以遠遠大於網絡中任意節點的存儲容量

​ ● 簡化系統設計：首先，大大簡化了存儲管理，因爲文件塊大小是固定的，這樣就可以很容易計算出一個節點可以存儲多少文件塊；

以塊作爲存儲單位,塊的大小遠遠大於普通文件系統，可以最小化尋址開銷；

其次，方便了元數據的管理，元數據不需要和文件塊一起存儲，可以由其他系統負責管理元數據。

​ ● 適合數據備份：每個文件塊都可以冗餘存儲到多個節點上，大大提高了系統的容錯性和可用性

3.2.2HDFS相關概念

①NameNode（Master）

• 1.管理HDFS的名稱空間，保存了兩個核心的數據結構，即FsImage和EditLog

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

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

• 2.配置副本策略

• 3.管理數據塊(Block)映射信息

  名稱節點記錄了每個文件中各個塊所在的數據節點的位置信息

• 4.處理客戶端讀寫請求

  試述HDFS1.0中只包含—個名稱節點會帶來哪些問題?

  HDFS1.0只設置唯一的名稱節點，這樣做雖然大大簡化了系統設計，但也帶來了一些明顯的侷限性，具體如下：

  （1）命名空間的限制：名稱節點是保存在內存中的，因此，名稱節點能夠容納的對象（文件、塊）的個數會受到內存空間大小的限制。

  （2）性能的瓶頸：整個分佈式文件系統的吞吐量，受限於單個名稱節點的吞吐量。

  （3）隔離問題：由於集羣中只有一個名稱節點，只有一個命名空間，因此，無法對不同應用程序進行隔離。

  （4）集羣的可用性：一旦這個唯一的名稱節點發生故障，會導致整個集羣變得不可用。

②DataNode（Slave）

• 1.存儲實際的數據塊

• 2.執行數據塊的讀/寫操作

  根據客戶端或者是名稱節點的調度來進行數據的存儲和檢索

  向名稱節點定期發送自己所存儲的塊的列表

③ Client

• 1.文件切分。文件上傳HDFS的時候，Client將文件切分成一個一個的Block，然後進行上傳
• 2.與NaneNode交互，獲取文件的位置信息
• 3.與DataNode交互，讀取或者寫入數據
• 4.Client提供一些命令來管理HDFS，比如NameNode格式化
• 5.Client可以通過一些命令來訪問HDFS，比如對HDFS增刪查改操作

④SecondaryNameNode：

• 1.輔助NameNode，分擔其工作量，比如定期合併Fsimage和Edits，並推送給NameNode
• 2.在緊急情況下，可輔助恢復NameNode

3.2.3HDFS的組成架構

在HDFS中，使用主從節點的方式，即使用Master和Slave結構對集羣進行管理。一般一個 HDFS 集羣只有一個Namenode 和一定數目的Datanode 組成。

Namenode 是 HDFS 集羣主節點，Datanode 是 HDFS集羣從節點，兩種角色各司其職，共同協調完成分佈式的文件存儲服務。

3.2.4命名空間

HDFS的命名空間包含目錄、文件和塊

在HDFS1.0體系結構中，在整個HDFS集羣中只有一個命名空間，並且只有唯一一個名稱節點，該節點負責對這個命名空間進行管理

**HDFS 支持傳統的層次型文件組織結構。**用戶或者應用程序可以創建目錄，然後將文件保存在這些目錄裏。文件系統名字空間的層次結構和大多數現有的文件系統類似：用戶可以創建、刪除、移動或重命名文件。

Namenode 負責維護文件系統的名字空間，任何對文件系統名字空間或屬性的修改都將被Namenode 記錄下來。HDFS 會給客戶端提供一個統一的抽象目錄樹，客戶端通過路徑來訪問文件，
形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。

3.2.5冗餘數據保存

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

如圖所示，數據塊1被分別存放到數據節點A和C上，數據塊2被存放在數據節點A和B上。這種多副本方式具有以下幾個優點：

（1）加快數據傳輸速度

（2）容易檢查數據錯誤

（3）保證數據可靠性

3.2.6數據錯誤與恢復

​ HDFS具有較高的容錯性，可以兼容廉價的硬件，它把硬件出錯看作一種常態，而不是異常，並設計了相應的機制檢測數據錯誤和進行自動恢復，主要包括以下幾種情形：名稱節點出錯、數據節點出錯和數據出錯。

1. 名稱節點出錯

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

2. 數據節點出錯

• 每個數據節點會定期向名稱節點發送“心跳”信息，向名稱節點報告自己的狀態

• 當數據節點發生故障，或者網絡發生斷網時，名稱節點就無法收到來自一些數據節點的心跳信息，這時，這些數據節點就會被標記爲“宕機”，節點上面的所有數據都會被標記爲“不可讀”，名稱節點不會再給它們發送任何I/O請求

  這時，有可能出現一種情形，即由於一些數據節點的不可用，會導致一些數據塊的副本數量小於冗餘因子

  名稱節點會定期檢查這種情況，一旦發現某個數據塊的副本數量小於冗餘因子，就會啓動數據冗餘複製，爲它生成新的副本

  HDFS和其它分佈式文件系統的最大區別就是可以調整冗餘數據的位置

3. 數據出錯

網絡傳輸和磁盤錯誤等因素，都會造成數據錯誤

• 客戶端在讀取到數據後，會採用md5和sha1對數據塊進行校驗，以確定讀取到正確的數據
• 在文件被創建時，客戶端就會對每一個文件塊進行信息摘錄，並把這些信息寫入到同一個路徑的隱藏文件裏面
• 當客戶端讀取文件的時候，會先讀取該信息文件，然後，利用該信息文件對每個讀取的數據塊進行校驗，如果校驗出錯，客戶端就會請求到另外一個數據節點讀取該文件塊，並且向名稱節點報告這個文件塊有錯誤，名稱節點會定期檢查並且重新複製這個塊

3.2.7數據存取策略

1.數據存放

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

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

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

更多副本：隨機節點

2. 數據讀取

HDFS提供了一個API可以確定一個數據節點所屬的機架ID，客戶端也可以調用API獲取自己所屬的機架ID

當客戶端讀取數據時，從名稱節點獲得數據塊不同副本的存放位置列表，列表中包含了副本所在的數據節點，可以調用API來確定客戶端和這些數據節點所屬的機架ID，

當發現某個數據塊副本對應的機架ID和客戶端對應的機架ID相同時，就優先選擇該副本讀取數據，如果沒有發現，就隨機選擇一個副本讀取數據

3.2.8HDFS數據讀寫過程

• FileSystem是一個通用文件系統的抽象基類，可以被分佈式文件系統繼承，所有可能使用Hadoop文件系統的代碼，都要使用這個類
• Hadoop爲FileSystem這個抽象類提供了多種具體實現,DistributedFileSystem就是FileSystem在HDFS文件系統中的具體實現
• FileSystem的open()方法返回的是一個輸入流FSDataInputStream對象，在HDFS文件系統中，具體的輸入流就是DFSInputStream；FileSystem中的create()方法返回的是一個輸出流FSDataOutputStream對象，在HDFS文件系統中，具體的輸出流就是DFSOutputStream。

3.2.8.1 讀數據

3.2.8.2寫數據

3.3 Hadoop-分佈式計算引擎MapReduce

存下數據之後，你就開始考慮怎麼處理數據。

雖然HDFS可以爲你整體管理不同機器上的數據，但是這些數據太大了。如果只讓一臺機器讀取成T上P的數據，很多時候需要好幾天甚至好幾周的時間。因此，對於很多應用場景來說，單機處理是不可忍受的，比如微博要更新24小時熱博，它必須在24小時之內跑完這些處理。那麼我如果要用很多臺機器處理，我就面臨瞭如何分配工作，如果一臺機器掛了如何重新啓動相應的任務，機器之間如何互相通信交換數據以完成複雜的計算等等。這就是MapReduce/Tez/Spark的功能。

MapReduce是第一代計算引擎，Tez和Spark是第二代。MapReduce的設計，採用了很簡化的計算模型，只有Map和Reduce兩個計算過程（中間用Shuffle串聯），用這個模型，已經可以處理大數據領域很大一部分問題了。

3.3.2MapReduce的核心思想

MapReduce的思想核心是“分而治之”，適用於大量複雜的任務處理場景（大規模數據處理場景）。

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

• Map負責“分”，即把複雜的任務分解爲若干個“簡單的任務”來並行處理。可以進行拆分的前提是這些小任務可以並行計算，彼此間幾乎沒有依賴關係。
• Reduce負責“合”，即對map階段的結果進行全局彙總。
  這兩個階段合起來正是MapReduce思想的體現。
  

比較形象的語言解釋MapReduce：　　
我們要數圖書館中的所有書。你數1號書架，我數2號書架。這就是“Map”。我們人越多，數書就更快。
現在我們到一起，把所有人的統計數加在一起。這就是“Reduce”。

3.3.2分佈式並行計算框架

計算框架是指實現某項任務或某項工作從開始到結束的計算過程或流的結構。

MapReduce具體的計算框架分佈如下所示:

並行計算框架

• 一個大的任務拆分成多個小任務，將多個小任務分發到多個節點上。每個節點同時執行計算的框架即爲並行計算框架
  
  

MapReduce相較於傳統的並行計算框架有什麼優勢

3.3.3 MapReduce設計構思

MapReduce是一個分佈式運算程序的編程框架，核心功能是將用戶編寫的業務邏輯代碼和自帶默認組件整合成一個完整的分佈式運算程序，併發運行在Hadoop集羣上。

既然是做計算的框架，那麼表現形式就是有個輸入（input），MapReduce操作這個輸入（input），通過本身定義好的計算模型，得到一個輸出（output）。

對許多開發者來說，自己完完全全實現一個並行計算程序難度太大，而MapReduce就是一種簡化並行計算的編程模型，降低了開發並行應用的入門門檻。

MapReduce構思體現在如下的方面：

1. 如何對付大數據處理：分而治之

對相互間不具有計算依賴關係的大數據，實現並行最自然的辦法就是採取分而治之的策略。並行計算的第一個重要問題是如何劃分計算任務或者計算數據以便對劃分的子任務或數據塊同時進行計算。不可分拆的計算任務或相互間有依賴關係的數據無法進行並行計算！

2. 構建抽象模型：Map和Reduce

	MapReduce借鑑了函數式語言中的思想，用Map和Reduce兩個函數提供了高層的並行編程抽象模型。
	Map: 對一組數據元素進行某種重複式的處理；
	Reduce: 對Map的中間結果進行某種進一步的結果整理。
	MapReduce中定義瞭如下的Map和Reduce兩個抽象的編程接口，由用戶去編程實現:
	map: (k1; v1) → [(k2; v2)]
	reduce: (k2; [v2]) → [(k3; v3)]

Map和Reduce爲程序員提供了一個清晰的操作接口抽象描述。

通過以上兩個編程接口，大家可以看出MapReduce處理的數據類型是<key,value>鍵值對。

3. 統一構架，隱藏系統層細節

如何提供統一的計算框架，如果沒有統一封裝底層細節，那麼程序員則需要考慮諸如數據存儲、劃分、分發、結果收集、錯誤恢復等諸多細節；爲此，MapReduce設計並提供了統一的計算框架，爲程序員隱藏了絕大多數系統層面的處理細節。

MapReduce最大的亮點在於通過抽象模型和計算框架把需要做什麼(what need to do)與具體怎麼做(how to do)分開了，爲程序員提供一個抽象和高層的編程接口和框架。

程序員僅需要關心其應用層的具體計算問題，僅需編寫少量的處理應用本身計算問題的程序代碼。如何具體完成這個並行計算任務所相關的諸多系統層細節被隱藏起來,交給計算框架去處理：從分佈代碼的執行，到大到數千小到單個節點集羣的自動調度使用。

3.3.4MapReduce工作流程概述

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

3.4 分佈式數據庫HBASE

3.4.1NoSQL

3.4.1.1簡介

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

3.4.1.2NoSQL興起的原因

3.4.1.2.1傳統的關係數據庫無法滿足web2.0網站的需求

隨着互聯網web2.0網站的興起，傳統的關係數據庫在應付web2.0網站，特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，主要表現在以下幾個方面：

• 無法滿足海量數據的管理需求
• 無法滿足數據高併發的需求
• 無法滿足高可擴展性和高可用性的需求

而非關係型的數據庫則由於其本身的特點得到了非常迅速的發展。

NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題，包括超大規模數據的存儲。

3.4.1.2.2關係數據庫的關鍵特性在web2.0時代成爲“雞肋”

關係數據庫的關鍵特性包括完善的事務機制和高效的查詢機制。但是，關係數據庫引以爲傲的兩個關鍵特性，到了Web2.0時代卻成了雞肋，主要表現在以下幾個方面：

• Web2.0網站系統通常不要求嚴格的數據庫事務
• Web2.0並不要求嚴格的讀寫實時性
• Web2.0通常不包含大量複雜的SQL查詢（去結構化，存儲空間換取更好的查詢性能）

3.4.1.3NoSQL與SQL的比較

3.4.1.3.1兩種數據庫的優缺點總結

NoSQL數據庫的優點：

1.可以很容易通過添加更多設備來支持更大規模的數據，NoSQL在設計之初就充分考慮了橫向擴展的需求，可以很容易通過添加廉價設備實現擴展，可以和雲計算緊密結合

2.不存在數據庫模式，可以自由靈活定義並存儲各種不同類型的數據

3.在NoSQL數據庫卻無法實現數據完整性

4.大多數NoSQL都能提供較高的可用性

NoSQL數據庫的缺點：

1.沒有關係代數理論作爲基礎

2.很多NoSQL數據庫沒有面向複雜查詢的索引，雖然NoSQL可以使用MapReduce來加速查詢，但是，在複雜查詢方面的性能仍然不如RDBMS

3.很多NoSQL數據庫放鬆了對事務ACID四性的要求，而是遵守BASE模型，只能保證最終一致性

4.NoSQL還沒有行業標準，不同的NoSQL數據庫都有自己的查詢語言，很難規範應用程序接口

5.NoSQL在技術支持方面仍然處於起步階段，還不成熟，缺乏有力的技術支持

6.NoSQL數據庫雖然沒有DBMS複雜，也難以維護

RDBMS關係數據庫的優點：

1.有關係代數理論作爲基礎

2.藉助於索引機制可以實現快速查詢（包括記錄查詢和範圍查詢）

3.任何一個RDBMS都可以很容易實現數據完整性，比如通過主鍵或者非空約束來實現實體完整性，通過主鍵、外鍵來實現參照完整性，通過約束或者觸發器來實現用戶自定義完整性

4.RDBMS已經標準化（SQL）

5.RDBMS經過幾十年的發展，已經非常成熟，Oracle等大型廠商都可以提供很好的技術支持

RDBMS關係數據庫的缺點：

1.很難實現橫向擴展，縱向擴展的空間也比較有限，性能會隨着數據規模的增大而降低

2.需要定義數據庫模式，嚴格遵守數據定義和相關約束條件

3.RDBMS嚴格遵守事務ACID模型，可以保證事務強一致性

4.RDBMS在任何時候都以保證數據一致性爲優先目標，其次纔是優化系統性能，隨着數據規模的增大，RDBMS爲了保證嚴格的一致性，只能提供相對較弱的可用性

5.RDBMS需要專門的數據庫管理員(DBA)維護

3.4.1.4NoSQL數據庫的四大類型

鍵值數據庫、列族數據庫、文檔數據庫和圖數據庫

3.4.1.5NoSQL的三大基石

3.4.1.5.1CAP

所謂的CAP指的是：

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

不同產品在設計時對CAP理論的運用：

3.4.1.5.2BASE

與BASE相對的ACID：

ACID四性的含義

• 原子性（Atomicity)

指事務必須是原子工作單元，對於其數據修改，要麼全都執行，要麼全都不執行。

• 一致性（consistency）

指事務在完成時，必須使所有的數據都保持一致狀態。

• 隔離性（Isolation)

指併發事務所做的修改必須與其他併發事務所做的修改隔離。

• 持久性（Durability)

指事務完成之後，它對於系統的影響是永久性的，該修改即使出現致命的系統故障也將一直保持。

關係型數據庫系統中設計了複雜的事務管理機制來保證執行過程中嚴格滿足ACID要求，故其較好地滿足了銀河等領域對數據一致性的要求，得到了廣泛的商業應用。

但是，Web2.0網站等場景中，對數據一致性的要求並不高，而是強調系統的高可用性，因此NoSQL適當犧牲了一致性或者分區容忍性，從而獲取可用性或可靠性,BASE的思想就是在這個基礎上發展起來的。

BASE的具體含義

1. 基本可用（Basically Availble）

   基本可用是指一個分佈式系統的一部分發生故障變得不可用時，其他部分仍可以正常使用，也就是允許分區失敗的情形出現。

2. 軟狀態（Soft-state）

   “軟狀態（soft-state）”是與“硬狀態（hard-state）”相對應的一種提法。

   數據庫保存的數據是“硬狀態”時，可以保證數據一致性，即保證數據一直是正確的。

   “軟狀態”是指狀態可以有一段時間不同步，具有一定的滯後性。

3. 最終一致性（Eventual consistency）

   一致性的類型包括強一致性和若一致性

   強一致性：系統中的某個數據被成功更新後，後續任何對該數據的讀取操作都將得到更新後的值；

   弱一致性：系統中的某個數據被更新後，後續對該數據的讀取操作可能得到更新後的值，也可能是更改前的值。但經過“不一致時間窗口”這段時間後，後續對該數據的讀取都是更新後的值；

   最終一致性：是弱一致性的特殊形式，允許後續更新的訪問操作可以暫時讀不到更新後的數據，但是一段時間後必須最終讀到更新後的數據。

3.4.2HBASE

3.4.2.1HBASE概述

HBase是一種分佈式、可擴展、支持海量數據存儲的NoSQL數據庫。

HBase是一個高可靠、高性能、面向列、可伸縮的分佈式數據庫，是谷歌BigTable的開源實現，主要用來存儲非結構化和半結構化的鬆散數據。HBase的目標是處理非常龐大的表，可以通過水平擴展的方式，利用廉價計算機集羣處理由超過10億行數據和數百萬列元素組成的數據表

HBase是Google Bigtable的開源實現，但是也有很多不同之處。比如：

• Google Bigtable利用GFS作爲其文件存儲系統，HBase利用Hadoop HDFS作爲其文件存儲系統；
• Google運行MAPREDUCE來處理Bigtable中的海量數據，HBase同樣利用Hadoop MapReduce來處理HBase中的海量數據；
• Google Bigtable利用Chubby作爲協同服務，HBase利用Zookeeper作爲對應。

3.4.2.2HBase與傳統的關係數據庫的區別

（1）數據類型：關係數據庫採用關係模型，具有豐富的數據類型和存儲方式，HBase則採用了更加簡單的數據模型，它把數據存儲爲未經解釋的字符串

（2）數據操作：關係數據庫中包含了豐富的操作，其中會涉及複雜的多表連接。HBase操作則不存在複雜的表與表之間的關係，只有簡單的插入、查詢、刪除、清空等，因爲HBase在設計上就避免了複雜的表和表之間的關係

（3）存儲模式：關係數據庫是基於行模式存儲的。HBase是基於列存儲的，每個列族都由幾個文件保存，不同列族的文件是分離的

（4）數據索引：關係數據庫通常可以針對不同列構建複雜的多個索引，以提高數據訪問性能。HBase只有一個索引——行鍵，通過巧妙的設計，HBase中的所有訪問方法，或者通過行鍵訪問，或者通過行鍵掃描，從而使得整個系統不會慢下來

（5）數據維護：在關係數據庫中，更新操作會用最新的當前值去替換記錄中原來的舊值，舊值被覆蓋後就不會存在。而在HBase中執行更新操作時，並不會刪除數據舊的版本，而是生成一個新的版本，舊有的版本仍然保留

（6）可伸縮性：關係數據庫很難實現橫向擴展，縱向擴展的空間也比較有限。相反，HBase和BigTable這些分佈式數據庫就是爲了實現靈活的水平擴展而開發的，能夠輕易地通過在集羣中增加或者減少硬件數量來實現性能的伸縮

3.4.2.3HBASE是面向列的存儲

傳統的數據庫是關係型的，且是按行來存儲的。如下圖：

其中只有張三把一行數據填滿了，李四王五趙六的行都沒有填滿。因爲這裏的行結構是固定的，每一行都一樣，即使你不用，也必須空到那裏，而不能沒有。

列式存儲

爲了與傳統的區別，新型數據庫叫做非關係型數據庫，是按列來存儲的。如下圖：

行存與列存的轉換：

原來張三的一列（單元格）數據對應現在張三的一行數據。原來張三的六列數據變成了現在的六行。

原來的六列數據是在一行，所以共用一個主鍵（即張三）。現在變成了六行，每行都需要一個主鍵（不然不知道這行數據是誰的），所以原來的主鍵（即張三）重複了六次。如下圖：

行列對比

① 行式存儲傾向於結構固定，列式存儲傾向於結構弱化。

（行式存儲相當於套餐，即使一個人來了也給你上八菜一湯，造成浪費；列式存儲相等於自助餐，按需自取，人少了也不浪費）

② 行式存儲一行數據只需一份主鍵，列式存儲一行數據需要多份主鍵。

③ 行式存儲存的都是業務數據，列式存儲除了業務數據外，還要存儲列名。

④ 行式存儲更像一個Java Bean，所有字段都提前定義好，且不能改變；列式存儲更像一個Map，不提前定義，隨意往裏添加key/value。

3.4.2.4HBase數據模型

3.4.2.4.1概述

• HBase是一個稀疏、多維度、排序的映射表，這張表的索引是行鍵、列族、列限定符和時間戳
• 每個值是一個未經解釋的字符串，沒有數據類型
• 用戶在表中存儲數據，每一行都有一個可排序的行鍵和任意多的列
• 表在水平方向由一個或者多個列族組成，一個列族中可以包含任意多個列，同一個列族裏面的數據存儲在一起
• 列族支持動態擴展，可以很輕鬆地添加一個列族或列，無需預先定義列的數量以及類型，所有列均以字符串形式存儲，用戶需要自行進行數據類型轉換
• HBase中執行更新操作時，並不會刪除數據舊的版本，而是生成一個新的版本，舊有的版本仍然保留（這是和HDFS只允許追加不允許修改的特性相關的）

3.4.2.4.2相關概念

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

3.4.2.4.3數據模型實例

3.4.2.4.4數據座標

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

3.4.2.4.5HBase數據的概念視圖和物理視圖

• 概念視圖

• 物理視圖—按列族進行物理存儲

列族contents

列族anchor

3.4.2.5HBASE的實現原理

3.4.2.5.1 HBase功能組件

• HBase各功能組建及其作用

  （1）庫函數：鏈接到每個客戶端；

  （2）一個Master主服務器：主服務器Master主要負責表和Region的管理工作；

  （3）許多個Region服務器：Region服務器是HBase中最核心的模塊，負責維護分配給自己的Region，並響應用戶的讀寫請求

3.4.2.5.2數據分區機制。

HBase採用分區存儲，一個大的表會被分拆許多個Region，這些Region會被分發到不同的服務器上實現分佈式存儲。

3.4.2.5.3HBase中的分區定位

通過構建的映射表的每個條目包含兩項內容，一個是Regionde 標識符，另一個是Region服務器標識，這個條目就標識Region和Region服務器之間的對應關係，從而就可以知道某個Region被保存在哪個Region服務器中。

3.4.2.6HBASE的運行機制

3.4.2.6.1HBase系統基本架構以及每個組成部分的作用。

（1）客戶端

客戶端包含訪問HBase的接口，同時在緩存中維護着已經訪問過的Region位置信息，用來加快後續數據訪問過程

（2）Zookeeper服務器

Zookeeper可以幫助選舉出一個Master作爲集羣的總管，並保證在任何時刻總有唯一一個Master在運行，這就避免了Master的“單點失效”問題

（3）Master

主服務器Master主要負責表和Region的管理工作：管理用戶對錶的增加、刪除、修改、查詢等操作；實現不同Region服務器之間的負載均衡；在Region分裂或合併後，負責重新調整Region的分佈；對發生故障失效的Region服務器上的Region進行遷移

（4）Region服務器

Region服務器是HBase中最核心的模塊，負責維護分配給自己的Region，並響應用戶的讀寫請求

3.4.2.6.2Region服務器向HDFS文件系統中讀寫數據的基本原理

Region服務器內部管理一系列Region對象和一個HLog文件，其中，HLog是磁盤上面的記錄文件，它記錄着所有的更新操作。

每個Region對象又是由多個Store組成的，每個Store對象了表中的一個列族的存儲。

每個Store又包含了MemStore和若干個StoreFile，其中，MemStore是在內存中的緩存。

HStore的工作原理

每個Store對應了表中的一個列族的存儲。每個Store包括一個MenStore緩存和若干個StoreFile文件。MenStore是排序的內存緩衝區，當用戶寫入數據時，系統首先把數據放入MenStore緩存，當MemStore緩存滿時，就會刷新到磁盤中的一個StoreFile文件中，當單個StoreFile文件大小超過一定閾值時，就會觸發文件分裂操作。

HLog的工作原理

答：HBase系統爲每個Region服務器配置了一個HLog文件，它是一種預寫式日誌（Write Ahead Log），用戶更新數據必須首先寫入日誌後，才能寫入MemStore緩存，並且，直到MemStore緩存內容對應的日誌已經寫入磁盤，該緩存內容才能被刷寫到磁盤。

3.5 雲數據庫

3.5.1雲數據庫的概念

雲數據庫是部署和虛擬化在雲計算環境中的數據庫。

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

雲數據庫具有高可擴展性、高可用性、採用多租形式和支持資源有效分發等特點。

3.5.2雲計算模式的優勢

3.5.3雲數據庫特性

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

3.5.4 雲數據庫廠商及其代表性產品

數據庫供應商主要分爲三類。

1. 傳統的數據庫廠商，如Teradata、Oracle、IBM DB2和Microsoft SQL Server等。

2. 涉足數據庫市場的雲供應商，如Amazon、Google.Yahoo!、阿里、百度、騰訊等。

3. 新興廠商，如IVertica.LongJump 和EnterpriseDB等。