如何對海量數據進(jìn)行存儲和管理，是大數據時(shí)代必須解決的問(wèn)題。存儲是所有大數據組件的基礎，存儲的關(guān)鍵是把數據持久保存下來(lái)，而對支撐這些的硬件資源（服務(wù)器集群、數據中心）如何進(jìn)行統一管理和資源調配以提高資源利用率，也是我們需要關(guān)注的重要方面。本文介紹網(wǎng)絡(luò )安全態(tài)勢感知可能會(huì )用到的幾種大數據存儲與管理技術(shù)，包括：

分布式文件系統

分布式數據庫

分布式協(xié)調系統

非關(guān)系型數據庫

資源管理調度

1、分布式文件系統

分布式文件系統是一種通過(guò)網(wǎng)絡(luò )實(shí)現文件在多臺主機上進(jìn)行分布式存儲的文件系統，一般采用客戶(hù)端/服務(wù)器模式，客戶(hù)端以特定的通信協(xié)議通過(guò)網(wǎng)絡(luò )與服務(wù)器建立連接，提出文件訪(fǎng)問(wèn)請求，客戶(hù)端和服務(wù)器可以通過(guò)設置訪(fǎng)問(wèn)權來(lái)限制請求方對底層數據存儲塊的訪(fǎng)問(wèn)。目前應用較為廣泛的分布式文件系統主要包括谷歌開(kāi)發(fā)的GFS和Hadoop項目里的HDFS，后者是模仿GFS開(kāi)發(fā)的開(kāi)源系統，整體架構與GFS大致相同，在各個(gè)應用場(chǎng)合被廣泛使用。

（1）HDFS的產(chǎn)生背景

HDFS（Hadoop Distributed File System）是Hadoop中的大規模分布式文件系統，也是該項目的兩大核心之一，為解決海量數據的高效存儲而生，具有處理超大數據、流式處理、可以運行在廉價(jià)商用服務(wù)器上等諸多優(yōu)點(diǎn)。HDFS的設計目標就是要運行在廉價(jià)的大型服務(wù)器集群上，因此其在設計上就將硬件故障作為一種常態(tài)來(lái)考慮，保證在部分硬件發(fā)生故障的情況下整個(gè)文件系統的可用性和可靠性，具有很好的容錯能力，并且兼容廉價(jià)的硬件設備，可以較低的成本利用現有機器實(shí)現大流量和大數據量的讀寫(xiě)。HDFS能夠實(shí)現以流的形式訪(fǎng)問(wèn)文件系統中的數據，在訪(fǎng)問(wèn)應用程序數據時(shí)可以有很高的吞吐率，因此對于超大數據集的應用程序來(lái)說(shuō)，選擇HDFS作為底層數據存儲是較好的選擇。

（2）HDFS的整體架構

HDFS采用了典型的主/從（Master/Slave）架構模型，一個(gè)HDFS集群中包括一個(gè)名稱(chēng)節點(diǎn)（NameNode）和若干個(gè)數據節點(diǎn)（DataNode）。

HDFS的命名空間包含目錄、文件和塊（Block）。命名空間支持對HDFS中的目錄、文件和塊做類(lèi)似文件系統的創(chuàng )建、修改和刪除等基本操作。在當前的HDFS體系結構中，整個(gè)HDFS集群中只有一個(gè)命名空間，并且只有唯一一個(gè)名稱(chēng)節點(diǎn)，它作為中心服務(wù)器是整個(gè)文件系統的管理節點(diǎn)，維護著(zhù)整個(gè)文件系統的文件目錄樹(shù)、文件/目錄的元數據（Metadata）和每個(gè)文件對應的數據塊列表，還接收用戶(hù)的操作請求。

集群中的數據節點(diǎn)一般是一個(gè)節點(diǎn)運行一個(gè)數據節點(diǎn)進(jìn)程，提供真實(shí)文件數據的存儲服務(wù)，負責處理文件系統客戶(hù)端的讀/寫(xiě)請求，在名稱(chēng)節點(diǎn)的統一調度下進(jìn)行數據塊的創(chuàng )建、復制和刪除等操作。每個(gè)數據節點(diǎn)會(huì )周期性地向名稱(chēng)節點(diǎn)發(fā)送“心跳”信息，報告自己的狀態(tài)，沒(méi)有按時(shí)發(fā)送“心跳”信息的數據節點(diǎn)會(huì )認為出現宕機，而名稱(chēng)節點(diǎn)不會(huì )再給它分配任何I/O請求。此外，多副本一般情況默認是三個(gè)，可以通過(guò)hdfs-site.xml的dfs.replication屬性進(jìn)行設置。

這種采用一個(gè)名稱(chēng)節點(diǎn)管理所有元數據的架構設計大大簡(jiǎn)化了分布式文件系統的結構，可以保證數據不會(huì )脫離名稱(chēng)節點(diǎn)的控制，同時(shí)用戶(hù)數據也永遠不會(huì )經(jīng)過(guò)名稱(chēng)節點(diǎn)，減輕了中心服務(wù)器的負擔，提高了數據管理效率。

（3）HDFS的存儲原理

HDFS的存儲主要包括以下幾種機制和策略：

數據的冗余存儲：HDFS采用多副本方式對數據進(jìn)行冗余存儲，將一個(gè)數據塊的多個(gè)副本分布保存到不同的數據節點(diǎn)上，即使某個(gè)數據節點(diǎn)出現故障，也不會(huì )造成數據損失。

數據存取策略：主要包括數據存放、數據讀取和數據復制。HDFS采用了以Rack（機架）為基礎的數據存放策略，一個(gè)集群包含多個(gè)機架，不同機架之間可進(jìn)行數據通信；HDFS提供了一個(gè)API以確定一個(gè)數據節點(diǎn)所屬的機架ID，客戶(hù)端也可以調用API獲取自己所屬的機架ID；HDFS的數據復制采用流水線(xiàn)復制方式，多個(gè)數據節點(diǎn)形成一條數據復制的流水線(xiàn)，大大提高了數據復制效率。

數據容錯處理：HDFS將硬件出錯視為常態(tài)，因此在設計上具有較高的容錯性。保存元數據信息的名稱(chēng)節點(diǎn)會(huì )定時(shí)把元數據同步存儲到其他文件系統，HDFS 2.0還增加了第二名稱(chēng)節點(diǎn)（Secondary Namenode）作為備份，防止主名稱(chēng)節點(diǎn)數據丟失。每個(gè)數據節點(diǎn)會(huì )定期向名稱(chēng)節點(diǎn)發(fā)送自己的狀態(tài)信息，以便名稱(chēng)節點(diǎn)動(dòng)態(tài)調整資源分配。當客戶(hù)端讀取數據時(shí)，會(huì )采用MD5和SHA1對數據塊進(jìn)行校驗，以保證讀取的是正確的數據。

（4）HDFS的部署和使用

HDFS采用Java語(yǔ)言開(kāi)發(fā)，任何支持JVM（Java Virtual Machine）的機器都可以部署為名稱(chēng)節點(diǎn)和數據節點(diǎn)，一般情況下，建議選擇一臺性能高的機器作為名稱(chēng)節點(diǎn)，其他的作為數據節點(diǎn)。當然，一臺機器也可以既作為名稱(chēng)節點(diǎn)，也作為數據節點(diǎn)，但不建議這樣做。由于所有的HDFS都是基于TCP/IP進(jìn)行數據通信的，所以客戶(hù)端通過(guò)一個(gè)可配置的端口向名稱(chēng)節點(diǎn)發(fā)起TCP連接，并采用客戶(hù)端協(xié)議與名稱(chēng)節點(diǎn)進(jìn)行交互，名稱(chēng)節點(diǎn)和數據節點(diǎn)之間使用數據節點(diǎn)協(xié)議進(jìn)行交互，客戶(hù)端與數據節點(diǎn)之間則通過(guò)RPC（Remote Procedure Call）來(lái)實(shí)現。用戶(hù)通過(guò)客戶(hù)端對HDFS進(jìn)行操作和使用，客戶(hù)端在HDFS部署時(shí)就有，可以進(jìn)行打開(kāi)、讀/寫(xiě)等操作，并且提供類(lèi)似Shell的命令行方式來(lái)訪(fǎng)問(wèn)HDFS中的數據，此外，HDFS也提供了Java API，作為應用程序訪(fǎng)問(wèn)文件系統的客戶(hù)端編程接口。

（5）HDFS的優(yōu)缺點(diǎn)

HDFS與MapReduce共同成為Hadoop的核心組成部分，HDFS在設計上采用了多種機制保證其硬件容錯能力，總體而言，HDFS有以下優(yōu)點(diǎn)：

簡(jiǎn)單的文件模型：HDFS采用了“一次寫(xiě)入、多次讀取”的簡(jiǎn)單文件模型，文件一旦完成寫(xiě)入，關(guān)閉后就無(wú)法再次寫(xiě)入，只能被讀取。

流式數據訪(fǎng)問(wèn)：HDFS是為了滿(mǎn)足批量數據處理要求而設計的，為了提高數據吞吐率，HDFS提供了流式方式來(lái)訪(fǎng)問(wèn)文件系統數據。

大數據集處理能力：HDFS支持對海量數據的存儲和讀寫(xiě)，其中的文件往往可以達到GB甚至TB級別，一個(gè)數百臺服務(wù)器組成的集群可以支持千萬(wàn)級別這樣的文件。

兼容廉價(jià)的硬件設備：由于運行在廉價(jià)的大型服務(wù)器集群上，在數百甚至數千臺廉價(jià)服務(wù)器中存儲數據經(jīng)常會(huì )出現某些節點(diǎn)失效的情況，為此HDFS設計了快速檢測硬件故障和進(jìn)行自動(dòng)恢復的機制，可以實(shí)現持續監控、錯誤檢查、容錯處理和自動(dòng)恢復，從而使得在硬件出錯的情況下也能實(shí)現數據的完整性。

強大的跨平臺兼容性：由于Hadoop項目大都采用Java語(yǔ)言實(shí)現，因此與Hadoop一樣，HDFS具有良好的跨平臺兼容性，支持JVM的機器都可以運行HDFS。

盡管擁有優(yōu)良的特性，由于特殊的設計，HDFS也難免具有一些應用局限性，主要包括以下缺陷：

無(wú)法高效存儲大量小文件：HDFS處理的數據單位是塊（一般來(lái)說(shuō)是64MB），采用名稱(chēng)節點(diǎn)來(lái)管理元數據，對于文件大小小于64MB的小文件，HDFS無(wú)法高效存儲和處理，過(guò)多的小文件會(huì )嚴重影響系統擴展性，大大增加線(xiàn)程管理開(kāi)銷(xiāo)。

不適合低延遲數據訪(fǎng)問(wèn)：HDFS主要是面向大規模數據批量處理而設計的，采用流式數據讀取，具有很高的數據吞吐率，但這也意味著(zhù)較高的延遲，因此，HDFS不適合用在需要較低延遲的應用場(chǎng)合。

不支持多用戶(hù)寫(xiě)入及任意修改文件：HDFS只允許一個(gè)文件有一個(gè)寫(xiě)入者，不允許多個(gè)用戶(hù)對同一文件執行寫(xiě)操作，而且只允許對文件執行追加操作，不能執行隨機寫(xiě)操作。

2、分布式數據庫

從20世紀70年代至今，關(guān)系數據庫已經(jīng)發(fā)展成為一種非常成熟穩定的數據庫管理系統，通常具備面向磁盤(pán)的存儲和索引結構、多線(xiàn)程訪(fǎng)問(wèn)、基于鎖的同步訪(fǎng)問(wèn)、基于日志的恢復和事務(wù)機制等功能。然而，隨著(zhù)Web 2.0應用的不斷發(fā)展，傳統關(guān)系數據已無(wú)法滿(mǎn)足大數據時(shí)代的需求，無(wú)論是在數據的高并發(fā)性、高擴展性，還是高可用性等方面，都顯得力不從心，于是以HBase為代表的分布式數據庫出現了，有效彌補了傳統關(guān)系數據庫的不足，在大數據時(shí)代得到了廣泛使用。

（1）HBase簡(jiǎn)介

HBase是一個(gè)提供高可靠、高性能、可伸縮、實(shí)時(shí)讀寫(xiě)、分布式的列式數據庫，主要用于存儲非結構化的松散數據。HBase與傳統關(guān)系數據庫的一個(gè)重要區別在于，它采用基于列的存儲，而后者采用基于行的存儲。HBase具有良好的橫向擴展能力，可以通過(guò)不斷增加廉價(jià)的商用服務(wù)器從而提高存儲能力，也可以處理非常龐大的表。在低延時(shí)要求上，HBase要比HDFS更勝一籌。

HBase也是Hadoop子項目之一，是對谷歌BigTable的開(kāi)源實(shí)現。它位于結構化存儲層，HDFS為HBase提供了高可靠性的底層存儲支持，Hadoop MapReduce為HBase提供了高性能的計算能力，ZooKeeper為HBase提供了穩定服務(wù)和故障轉移機制。此外，Pig和Hive還為HBase提供了高層語(yǔ)言支持，使得在HBase上進(jìn)行數據統計處理變得非常簡(jiǎn)單。Sqoop則為HBase提供了方便的關(guān)系數據庫數據導入功能，使得傳統數據庫數據向HBase中遷移變得非常方便。HBase在Hadoop生態(tài)系統中的位置如圖2所示。

（2）HBase數據模型

就像關(guān)系型數據庫的數據模型是二維表，HBase數據模型是一個(gè)稀疏的、多維度的、排序的映射表，表由行（Row）和列（Column）組成，列劃分為若干個(gè)列族（Column Family）。它主要采用以下概念：

行鍵（RowKey）：與NoSQL數據庫一樣，用來(lái)檢索表中每條記錄的“主鍵”，方便快速查找，可以是任意字符串（最大長(cháng)度是64KB），保存為字節數組（Byte Array）。

列族（Column Family）：基本的訪(fǎng)問(wèn)控制單元，擁有一個(gè)名稱(chēng)，包含一個(gè)或者多個(gè)相關(guān)列。每個(gè)列都屬于某一個(gè)列族，列族是表的一部分，而列不是，必須在使用表之前定義，列名都以列族作為前綴。

單元格（Value Cell）：在HBase表中通過(guò)行和列族確定一個(gè)單元格。單元格中存儲的數據沒(méi)有數據類(lèi)型，總被視為字節數組byte[]。每個(gè)單元格都保存著(zhù)同一份數據的多個(gè)版本。

時(shí)間戳（Timestamp）：版本通過(guò)時(shí)間戳來(lái)索引。時(shí)間戳的類(lèi)型是64位整型。時(shí)間戳可以由HBase在數據寫(xiě)入時(shí)自動(dòng)賦值，此時(shí)時(shí)間戳是精確到毫秒的當前系統時(shí)間。時(shí)間戳也可以由客戶(hù)顯式賦值。

HBase的物理存儲方式是：Table在行的方向上分割為多個(gè)HRegion，HRegion按大小分割，每個(gè)表一開(kāi)始只有一個(gè)HRegion，隨著(zhù)數據不斷插入表，HRegion不斷增大，當增大到一個(gè)閾值時(shí)，HRegion就會(huì )等分為兩個(gè)新的HRegion。

HRegion雖然是分布式存儲的最小單元，但并不是存儲的最小單元。事實(shí)上，HRegion由一個(gè)或者多個(gè)Store組成，每個(gè)Store保存一個(gè)列族。每個(gè)Store又由一個(gè)memStore和零至多個(gè)StoreFile組成。StoreFile以HFile格式保存在HDFS上。

（3）HBase系統架構

HBase采用主/從架構搭建集群，它隸屬于Hadoop生態(tài)系統，主要包括主服務(wù)器（HMaster）節點(diǎn)、HRegionServer節點(diǎn)、ZooKeeper服務(wù)器和客戶(hù)端（Client），而在底層，它將數據存儲于HDFS中，因而涉及HDFS的NameNode、DataNode等，總體結構如圖6所示。

HMaster節點(diǎn)用于：①管理HRegionServer，實(shí)現其負載均衡；②管理和分配HRegion；③在HRegionServer退出時(shí)遷移其內的HRegion到其他HRegionServer上；④實(shí)現DDL操作（例如對列族的增刪改等）；⑤管理元數據（實(shí)際存儲在HDFS上）；⑥權限控制（ACL）。

ZooKeeper服務(wù)器是協(xié)調系統，用于存放整個(gè)HBase集群的元數據以及集群的狀態(tài)信息，以及實(shí)現HMaster主從節點(diǎn)的故障轉移，避免出現“單點(diǎn)失效”問(wèn)題。

Client包含訪(fǎng)問(wèn)HBase的接口，同時(shí)在緩存中維護著(zhù)已經(jīng)訪(fǎng)問(wèn)過(guò)的HRegion位置信息，用來(lái)加快后續數據訪(fǎng)問(wèn)過(guò)程，它通過(guò)RPC機制與HMaster、HRegionServer通信。

HRegionServer節點(diǎn)用于：①存放和管理本地HRegion，一個(gè)HRegionServer可以存放1000個(gè)HRegion；②讀寫(xiě)HDFS，管理Table中的數據；③Client直接通過(guò)HRegionServer讀寫(xiě)數據（從HMaster中獲取元數據，找到RowKey所在的HRegion/HRegionServer后）。

3、分布式協(xié)調系統

我們首先來(lái)認識一下分布式協(xié)調技術(shù)，分布式協(xié)調技術(shù)主要用來(lái)解決分布式環(huán)境當中多個(gè)進(jìn)程之間的同步控制，讓它們有序地訪(fǎng)問(wèn)某種臨界資源，防止造成“臟數據”的后果。為了在分布式系統中進(jìn)行資源調度，我們需要一個(gè)協(xié)調器，也就是“鎖”。例如進(jìn)程1在使用某資源的時(shí)候，首先要獲得鎖，進(jìn)程1獲得鎖以后會(huì )對該資源保持獨占，這樣其他進(jìn)程就無(wú)法訪(fǎng)問(wèn)該資源，進(jìn)程1用完該資源以后將鎖釋放，以便讓其他進(jìn)程來(lái)獲得鎖。通過(guò)這個(gè)鎖機制，我們就能保證分布式系統中多個(gè)進(jìn)程有序地訪(fǎng)問(wèn)該臨界資源。這個(gè)分布式鎖也就是分布式協(xié)調技術(shù)實(shí)現的核心內容。

目前，在分布式協(xié)調技術(shù)方面做得比較好的就是谷歌的Chubby和Apache的ZooKeeper，它們都是分布式鎖的實(shí)現者。

（1）ZooKeeper簡(jiǎn)介

ZooKeeper是一個(gè)開(kāi)源的分布式應用程序協(xié)調服務(wù)系統，是對谷歌Chubby的一個(gè)開(kāi)源實(shí)現，也是Hadoop子項目和HBase的重要組件。它為分布式應用提供一致性服務(wù)，提供的功能包括配置維護、域名服務(wù)、分布式同步、組服務(wù)等。ZooKeeper的目標就是封裝好復雜易出錯的關(guān)鍵服務(wù)，將簡(jiǎn)單易用的接口和性能高效、功能穩定的系統提供給用戶(hù)。

（2）ZooKeeper數據模型和操作

ZooKeeper使用Java編寫(xiě)，它使用一個(gè)與文件樹(shù)結構相似的數據模型，可以使用Java或C來(lái)方便地進(jìn)行編程接入。ZooKeeper樹(shù)中的每個(gè)節點(diǎn)被稱(chēng)為Znode。與文件系統的目錄樹(shù)一樣，樹(shù)中的每個(gè)節點(diǎn)可以擁有子節點(diǎn)。一個(gè)節點(diǎn)自身?yè)碛斜硎酒錉顟B(tài)的許多重要屬性，見(jiàn)表1。

在ZooKeeper中有9個(gè)基本操作，如表2所示。

盡管ZooKeeper看上去像是一個(gè)文件系統，但為了方便，它摒棄了一些文件系統的操作原語(yǔ)。這是因為它的文件非常小且為整體讀寫(xiě)的，所以不需要打開(kāi)、關(guān)閉或尋址的操作。ZooKeeper可以為所有的讀操作設置watch，這些讀操作包括exists()、getChildren()及getData()。watch事件是一次性的觸發(fā)器，當watch的對象狀態(tài)發(fā)生改變時(shí)，將會(huì )觸發(fā)此對象上watch所對應的事件。watch事件將被異步地發(fā)送給客戶(hù)端，并且ZooKeeper為watch機制提供了有序的一致性保證。理論上，客戶(hù)端接收watch事件的時(shí)間要快于其看到watch對象狀態(tài)變化的時(shí)間。

（3）ZooKeeper工作原理

ZooKeeper的核心是原子廣播，這個(gè)機制保證了各個(gè)服務(wù)器之間的同步。實(shí)現這個(gè)機制的協(xié)議稱(chēng)為Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務(wù)啟動(dòng)或者在領(lǐng)導者（Leader）“崩潰”后，Zab就進(jìn)入了恢復模式，當Leader被選舉出來(lái)，且大多數服務(wù)器完成了與Leader的狀態(tài)同步以后，恢復模式就結束了。狀態(tài)同步保證了Leader和服務(wù)器具有相同的系統狀態(tài)。

ZooKeeper是以Fast Paxos算法為基礎的，Paxos算法存在活鎖的問(wèn)題，即當有多個(gè)proposer（申請者）交錯提交時(shí)，有可能互相排斥導致沒(méi)有一個(gè)proposer能提交成功，而Fast Paxos進(jìn)行了一些優(yōu)化，通過(guò)選舉產(chǎn)生一個(gè)Leader，只有Leader才能提交申請，ZooKeeper的基本工作過(guò)程如下：

一是選舉Leader過(guò)程。

二是同步數據過(guò)程。

在選舉Leader的過(guò)程中算法有很多，默認的是Fast Paxos算法，無(wú)論何種算法，要達到的選舉目標是一致的。Leader具有最高的執行ID，類(lèi)似root權限。集群中大多數的機器得到響應并接受選出的Leader。

（4）ZooKeeper和HBase的關(guān)系

ZooKeeper和HBase的關(guān)系是：HBase內置有ZooKeeper，但也可以使用外部ZooKeeper。讓HBase使用一個(gè)已有的不被HBase托管的ZooKeeper集群，需要設置conf/hbase env sh文件中的HBASE_MANAGES_ZK屬性為false，并指明ZooKeeper的host和端口。當HBase托管ZooKeeper時(shí)，ZooKeeper集群的啟動(dòng)是HBase啟動(dòng)腳本的一部分。

4、非關(guān)系型數據庫

傳統的關(guān)系數據庫能夠較好地支持結構化數據存儲和管理，但大數據時(shí)代的到來(lái)使得關(guān)系數據庫發(fā)展越來(lái)越力不從心，因為大數據時(shí)代的數據類(lèi)型繁多，既包括結構化數據，還有大量的非結構化數據，且后者比例高達90%。由于數據模型不靈活、數據并發(fā)能力差、擴展性和可用性不佳等缺陷，關(guān)系型數據庫已經(jīng)無(wú)法滿(mǎn)足各種類(lèi)型的非結構化數據的大規模存儲需求，進(jìn)而出現了多種不同于關(guān)系數據庫的數據庫管理系統設計方式，如近幾年來(lái)快速流行的NoSQL和新興的NewSQL等。

（1）NoSQL簡(jiǎn)介

NoSQL是對非關(guān)系型數據庫的統稱(chēng)，它所采用的數據模型并非傳統關(guān)系數據庫的二維表形式的關(guān)系模型，而是類(lèi)似鍵值、列族、文檔等非關(guān)系模型。NoSQL沒(méi)有固定的表結構，也不存在連接操作，沒(méi)有嚴格遵守ACID約束，它支持Hadoop MapReduce風(fēng)格的編程，能夠很好地用于大數據的管理。當應用場(chǎng)合需要簡(jiǎn)單的數據模型、較高的數據性能、靈活的擴展系統和較低的數據庫一致性時(shí)，NoSQL數據庫是一個(gè)推薦的選擇，因為它具有靈活的橫向擴展能力（廉價(jià)硬件的堆積）和靈活的數據模型（非關(guān)系模型，一個(gè)數據元素里可存儲多類(lèi)型數據），且能與云計算環(huán)境很好地融合使用。

（2）NoSQL的四大類(lèi)型

近幾年來(lái)，NoSQL領(lǐng)域迎來(lái)了爆炸式發(fā)展，目前已經(jīng)產(chǎn)生了150多個(gè)新的數據庫，如HBase和MongoDB就是NoSQL類(lèi)型。雖然其種類(lèi)多樣，但歸結起來(lái)，典型的NoSQL數據庫通常包括以下四個(gè)類(lèi)型：

鍵值數據庫：采用散列表，表中有一個(gè)特定的鍵和一個(gè)指針指向特定的值，前者用來(lái)定位值的位置以進(jìn)行檢索，后者可以存儲任何類(lèi)型的數據。鍵值數據庫適合需要大量寫(xiě)操作的場(chǎng)合，具有良好的伸縮性，可實(shí)現數據量的無(wú)限擴容，缺點(diǎn)是條件查詢(xún)比較弱。該類(lèi)型數據庫產(chǎn)品有Riak、Redis、Chordless、Scalaris、SimpleDB等。

列族數據庫：采用列族數據模型，由多個(gè)行構成，每行數據包含多個(gè)列族，不同行可具有不同數量的列族，屬于同一列族的數據被存放在一起。每行數據通過(guò)行鍵進(jìn)行定位。列族數據庫常用于分布式數據存儲和管理，具有查找速度快、容易進(jìn)行分布式擴展等優(yōu)點(diǎn)，但功能較少，不支持事務(wù)一致性。該類(lèi)型數據庫產(chǎn)品有Cassandra系列、HBase等。

文檔數據庫：在該類(lèi)數據庫中，文檔是數據庫的最小單位，它假定文檔以某種標準化格式封裝并對數據進(jìn)行加密，并用多種格式進(jìn)行解碼。文檔數據庫通過(guò)鍵（Key）定位一個(gè)文檔，因此可看成是鍵值數據庫的一個(gè)衍生品，但是其具有更高的查詢(xún)效率。文檔數據庫適合存儲、索引和管理那些面向文檔的數據，具有高性能、數據結構靈活等優(yōu)點(diǎn)，但是缺少統一的查詢(xún)語(yǔ)法。該類(lèi)型數據庫產(chǎn)品有各種MongoDB、RavenDB等。

圖數據庫：采用圖作為數據模型將完全不同于鍵值、列族和文檔數據模型，可以高效存儲不同頂點(diǎn)之間的關(guān)系。圖數據庫專(zhuān)門(mén)用來(lái)處理具有高度關(guān)聯(lián)關(guān)系的數據，適用于大量復雜、互連接、低結構化的圖結構場(chǎng)合，如社交網(wǎng)絡(luò )、推薦系統等，其他場(chǎng)合其性能表現不如其他NoSQL數據庫。該類(lèi)型數據庫產(chǎn)品主要有各種Neo4J等。

（3）NoSQL的三大理論基石

CAP：C（Consistency）是指一致性，在分布式環(huán)境中，多點(diǎn)的數據是一致的；A（Availability）即可用性，可快速獲取數據并在確定的時(shí)間內返回操作結果；P（Tolerance of Network Partition）即分區容忍性，指當出現網(wǎng)絡(luò )分區時(shí)，分離的系統也能正常運行。一個(gè)分布式系統不可能同時(shí)滿(mǎn)足以上3個(gè)要求，最多只能同時(shí)滿(mǎn)足兩個(gè)，可以是CA、CP或AP等。

BASE：全稱(chēng)“Basically Available，Soft-state，Eventual consistency”，也就是基本可用（分布式系統的一部分發(fā)生問(wèn)題失效時(shí)，其他部分仍能正常使用）、軟狀態(tài)（數據狀態(tài)可以有一段時(shí)間不同步，具有一定的滯后性）以及最終一致性（只要最終數據一致就行，不需要保證時(shí)時(shí)刻刻的數據一致性）。

最終一致性：只要經(jīng)過(guò)一段時(shí)間后能訪(fǎng)問(wèn)到更新后的數據即可。

（4）NoSQL的發(fā)展趨勢

雖然NoSQL數據庫具有很多傳統關(guān)系數據庫不具備的優(yōu)勢，對非結構化數據處理起來(lái)很方便，但其存在對結構化數據查詢(xún)能力弱、不支持事務(wù)ACID等缺點(diǎn)，因此市面上又逐漸出現一種更新的數據庫類(lèi)型，即NewSQL。NewSQL數據庫是對各種新的可擴展、高性能數據庫的簡(jiǎn)稱(chēng)，它不僅具有NoSQL對海量數據的管理能力，還保持了傳統關(guān)系數據庫的ACID和SQL等特性，既能高效處理結構化數據，也能高效處理非結構化數據。比較有代表性的NewSQL數據庫產(chǎn)品有Spanner、Clustrix、Shooner、ScaleDB、ScaleBase、Drizzle等。

5、資源管理調度

對于硬件資源較多的組織，在搭建大數據平臺的過(guò)程中如何充分挖掘硬件資源潛力，并提高其利用率、加快所有計算任務(wù)的整體完成速度是非常重要的問(wèn)題。這就涉及資源的管理調度，即對集群、數據中心級別的硬件資源進(jìn)行統一管理和分配。其中，多租戶(hù)、彈性伸縮、動(dòng)態(tài)分配是資源管理調度要解決的核心問(wèn)題。

（1）資源管理調度發(fā)展趨勢

雖然，目前對資源管理調度的研究尚處于摸索期，還未成熟，但整體發(fā)展趨勢已經(jīng)很明朗了，那就是：在集群硬件層之上抽象出一個(gè)功能獨立的集群資源管理系統，將所有可用資源當作一個(gè)整體進(jìn)行管理，并對其他所有計算任務(wù)提供統一的資源管理和調度框架及接口，計算任務(wù)按需向其申請資源，使用完畢后釋放資源。這也是大數據平臺搭建過(guò)程中整個(gè)體系架構非?；A且重要的部分。這樣做的好處很明顯，一是能提高集群整體資源利用率；二是能提高數據共享能力；三是支持多類(lèi)型計算框架和多版本計算框架。

（2）資源管理調度目標和局限

資源管理調度的目標是對子系統進(jìn)行高效調度、提高全系統的資源利用率以及支持動(dòng)態(tài)調整切分資源并增強系統可擴展性。資源管理調度的局限在于不適合實(shí)時(shí)性要求高的應用、應用框架資源規劃并不容易（需要高級的算法支撐）、內存使用也難以分配準確等。

（3）資源管理調度模型框架

資源管理調度主要目的是將集群中的各種資源通過(guò)一定的策略分配給提交到系統里的各種用戶(hù)任務(wù)，常見(jiàn)的資源主要包括內存、CPU、網(wǎng)絡(luò )資源與硬盤(pán)I/O資源4種。這就涉及三個(gè)要素，即資源組織、調度策略和任務(wù)組織，資源管理調度就是要對這三個(gè)要素進(jìn)行組織安排，如圖7所示。

資源組織模型：將集群中的當前可用資源按照一定的方式組織起來(lái)，以方便后續的資源分配。資源組織的方式多種多樣，有單隊列式、平級多隊列式以及多層級隊列式等，可根據需要進(jìn)行資源的組織。

調度策略模型：將資源按照一定的方式分配給提交到系統的任務(wù)，常見(jiàn)的調度策略包括FIFO調度、公平調度、能力調度、延遲調度等。

FIFO調度：按照時(shí)間先后順序或優(yōu)先級次序將提交的作業(yè)放入線(xiàn)性隊列中，“先進(jìn)先出”地進(jìn)行資源調度和分配，是Hadoop默認的調度策略，也是最簡(jiǎn)單的策略。

公平調度：將用戶(hù)的多個(gè)任務(wù)分配到多個(gè)資源池中，每個(gè)資源池設定資源分配最低保障和最高上限，區分資源池的優(yōu)先級，優(yōu)先級高的會(huì )被分配更多資源，對于有剩余的資源池，可將剩余資源共享給其他資源池，是一種較高級的多用戶(hù)多任務(wù)調度策略，也是Hadoop常用策略，其特點(diǎn)是支持搶占式調度且盡量保證作業(yè)間的資源分配公平性。

能力調度：將用戶(hù)和任務(wù)組織成多個(gè)隊列，每個(gè)隊列可以設定資源最低保障和最高上限，當一個(gè)隊列的資源有剩余時(shí)，可將剩余資源分享給其他隊列，在調度時(shí)優(yōu)先將資源分配給資源使用率最低的隊列，在隊列內部按照優(yōu)先級順序遵循FIFO策略調度。它也是Hadoop常用策略，適合用戶(hù)量眾多的場(chǎng)景，與公平調度相比，更強調資源在用戶(hù)之間而非作業(yè)之間的公平性。

延遲調度：對于當前被調度到要被分配資源的任務(wù)i，若當前資源不滿(mǎn)足數據局部性，則可以暫時(shí)放棄分配公平性，不接受當前資源，繼續等待后續資源分配，若任務(wù)i被跳過(guò)n次后仍等不到滿(mǎn)足局部性的資源，則放棄數據局部性，被迫接受當前資源來(lái)啟動(dòng)任務(wù)執行。延遲調度是一種增強數據局部性的附加策略，并非一種獨立使用的調度策略，常與其他調度策略結合應用，作為其他策略的輔助手段。

任務(wù)組織模型：將多用戶(hù)提交的任務(wù)按照一定的方式組織起來(lái)，以方便后續資源的分配。任務(wù)組織的方式也是多樣的，如層級隊列、樹(shù)形隊列、全局隊列等。

圖8是一個(gè)抽象的通用資源管理框架，它簡(jiǎn)單描述了如何將用戶(hù)和任務(wù)組織起來(lái)并進(jìn)行資源管理、分配調度的大致流程。

從圖8可見(jiàn)，幾個(gè)關(guān)鍵的部件將資源管理調度的整個(gè)過(guò)程運作了起來(lái)。

一是節點(diǎn)管理器。集群中的每臺機器上都會(huì )配置節點(diǎn)管理器，用于不斷向資源收集器匯報當前機器的資源使用情況并負責容器的管理。當一個(gè)任務(wù)被分配到某個(gè)節點(diǎn)執行時(shí)，當前的節點(diǎn)管理器就會(huì )將其納入某個(gè)容器中，并對該容器進(jìn)行資源隔離。

二是調度器。其由資源收集器和資源調度策略構成，同時(shí)管理著(zhù)資源池和工作隊列。資源收集器不斷地從節點(diǎn)管理器收集和更新資源狀態(tài)信息，并將最新?tīng)顩r反映到資源池中；資源池列出當前可用的系統資源，而資源調度策略決定如何將資源池中的可用資源分配給工作隊列；當用戶(hù)提交新的作業(yè)或任務(wù)時(shí)，就會(huì )排隊進(jìn)入工作隊列等待分配給它的資源。

（4）資源管理調度系統類(lèi)型

當前，根據其宏觀(guān)運行機制的不同大致可將資源管理調度系統分為三種類(lèi)型：集中式調度、兩級調度和狀態(tài)共享調度。如圖9所示。

集中式調度：在整個(gè)資源管理調度系統中只運行一個(gè)全局的中央調度器，所有任務(wù)的資源請求和調度都經(jīng)由中央調度器來(lái)滿(mǎn)足。根據能否支持多種調度策略，集中式調度又分為單路徑調度和多路徑調度，前者采用統一的調度策略進(jìn)行資源管理調度，后者則能夠支持多種調度策略。無(wú)論哪種類(lèi)型，都需要將調度全部融入中央調度器進(jìn)行集中式調度，因此系統的并發(fā)性能差、可擴展性差、調度靈活度低，適合于小規模的集群。

兩級調度：調度工作不僅僅由一個(gè)中央調度器完成，還包括一個(gè)框架調度器，為兩級架構模式。中央調度器完成全局粗粒度的資源調度，框架調度器看不到全局，只能看到由中央調度器分配給自己的資源。采用這種架構的系統具有較好的可擴展性和并發(fā)性能，后面要介紹的YARN、Mesos框架都是兩級調度類(lèi)型，它適合于大規模集群下的多任務(wù)高負載（同質(zhì)）計算場(chǎng)合。

狀態(tài)共享調度：這種調度模式使得每個(gè)計算框架都能獲取整個(gè)集群中的資源使用狀況信息，并采用相互競爭的方式來(lái)獲取所需的資源，且能依據自身特性采取不同的資源調度策略，同時(shí)系統采用了樂(lè )觀(guān)并發(fā)控制手段來(lái)解決不同計算框架在資源競爭過(guò)程中出現的沖突。這種模式大大提高了系統的并發(fā)性能，提高了效率，當然公平性就相對弱一些，畢竟是強調“叢林法則”的自由競爭策略，它更適合于異質(zhì)性較強且資源沖突不多的大規模集群應用場(chǎng)景。

（5）資源管理調度框架YARN

YARN（Yet Another Resource Negotiator，另一個(gè)資源協(xié)調器）的名字看上去很特別，它從Hadoop 1.0發(fā)展而來(lái)，目前是Hadoop 2.0的重要組成部分。它重點(diǎn)解決了Hadoop 1.0的兩個(gè)問(wèn)題：一個(gè)是單管理節點(diǎn)的性能瓶頸問(wèn)題和系統的可擴展性問(wèn)題，另一個(gè)是Hadoop 1.0的資源共享的局限性和浪費問(wèn)題。

作為Hadoop領(lǐng)域的一個(gè)比較有名的資源調度管理框架，YARN是典型的兩級調度類(lèi)型，它的核心思想是將JobTracker和TaskTracker分離，將資源管理和作業(yè)調度/監控劃分成兩個(gè)獨立進(jìn)程，由下面幾大組件構成：

一個(gè)全局的資源管理器（Resource Manager，RM）。

每個(gè)節點(diǎn)代理的節點(diǎn)管理器（Node Manager，NM）。

每個(gè)應用都有一個(gè)的應用服務(wù)器（Application Master，AM）。

每個(gè)AM擁有多個(gè)容器（Container）在NM上運行。

YARN整體架構如圖10所示。

YARN的核心是RM，它負責全局的資源管理工作，控制整個(gè)集群并管理應用程序對基礎計算資源的分配。NM管理YARN集群中的每個(gè)節點(diǎn)，提供針對集群中每個(gè)節點(diǎn)的服務(wù)，從對一個(gè)容器的終生管理到監視資源和跟蹤節點(diǎn)健康。RM將各種資源（計算、內存、網(wǎng)絡(luò )等）精心安排給基礎NM（YARN的每個(gè)節點(diǎn)的代理）。RM還與AM一起分配資源，與NM一起啟動(dòng)和監視它們的基礎應用程序。在YARN的這種結構里，RM承擔了JobTracker的角色，AM則承擔了以前TaskTracker的一些角色。AM管理在YARN內運行的一個(gè)應用程序的每個(gè)實(shí)例。AM負責協(xié)調來(lái)自RM的資源，并通過(guò)NM監視容器的執行和資源使用情況。

YARN的優(yōu)點(diǎn)主要體現在它大大減少了RM的資源消耗，讓監測每個(gè)作業(yè)子任務(wù)狀態(tài)的程序分布式化了，更安全、更優(yōu)美，它使得Hadoop的各個(gè)組件能夠快速地接入YARN框架中，支持的調度算法和策略更豐富。YARN的局限性主要表現在，由于RM負責所有應用的任務(wù)調度，各個(gè)應用作為YARN的一個(gè)客戶(hù)端庫，這樣的模式使得傳統數據庫應用接入之后效率不高，難以真正用起來(lái)。

（6）資源管理調度框架Mesos

Mesos最初由加州大學(xué)伯克利分校的AMPLab開(kāi)發(fā)，后來(lái)在Twitter上得到廣泛應用，是Apache下的開(kāi)源分布式資源管理調度框架。從結構上看，它也是典型的兩級調度類(lèi)型。Mesos的設計理念吸收了操作系統微內核的思想，在中央調度器級別采取極簡(jiǎn)功能和極小接口，只是根據一定策略決定分配給各個(gè)框架多少資源，將數據局部性保證等具體資源調度策略下推到各個(gè)框架，從而減少中央調度器的負載，提高調度效率，同時(shí)也因為其極簡(jiǎn)設計策略，使得中央調度器支持將來(lái)新出現的框架改動(dòng)最小化，增強了調度系統的可擴展性和健壯性。

Mesos采用典型的“主/從”架構，中央調度器由多個(gè)主控服務(wù)器（Master）構成，通過(guò)ZooKeeper可以保證當正在工作的主控服務(wù)器出現故障時(shí)，備用的主控服務(wù)器（Standby Master）可以快速將管理工作接替過(guò)來(lái)，以此增強整個(gè)調度系統的健壯性。Master相當于中央調度器，為每個(gè)計算框架分配資源。每個(gè)計算框架需要向Mesos注冊?xún)蓚€(gè)接口：框架調度器（Scheduler）和執行器（Executor），前者起到第二層級調度器的作用，中央調度器將資源供給提交給Scheduler，Scheduler再按照自身資源分配策略將其分配給任務(wù)；后者運行在集群中的從節點(diǎn)（Mesos Slave）中以執行具體的任務(wù)，執行器相互之間的資源隔離由Mesos通過(guò)Linux Container來(lái)保障。

YARN和Mesos有很大的共性，因為它們的整體架構和各個(gè)架構的組件/構件相似，都是典型的兩級調度類(lèi)型。但二者也有比較明顯的區別，主要體現在YARN的中央調度器RM支持“搶占式調度”，當集群資源稀缺時(shí)，RM可以通過(guò)協(xié)議命令AM釋放特定的資源。此外，YARN的RM在申請資源時(shí)可以明確提出數據局部性條件，讓AM在資源請求信息內明確指明數據局部性偏好。Mesos則比較適合不同框架任務(wù)同質(zhì)化場(chǎng)景，尤其是大部分都是短作業(yè)的情景，比如批處理任務(wù)，因為Mesos不支持搶占式調度，資源分配出去后只能等待任務(wù)運行結束后自行釋放，如果是大量短作業(yè)則資源釋放速度較快，這樣總有新資源可分配，而對于后續任務(wù)來(lái)說(shuō)可以較快獲得資源，避免長(cháng)時(shí)間等待。

來(lái)源：計算機與網(wǎng)絡(luò )安全