大資料技術概述復習（一）

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

參考：

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