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

分布式文件系統(tǒng)

分布式數(shù)據(jù)庫

分布式協(xié)調(diào)系統(tǒng)

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

資源管理調(diào)度

1、分布式文件系統(tǒng)

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

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

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

（2）HDFS的整體架構(gòu)

HDFS采用了典型的主/從（Master/Slave）架構(gòu)模型，一個HDFS集群中包括一個名稱節(jié)點（NameNode）和若干個數(shù)據(jù)節(jié)點（DataNode）。

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

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

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

（3）HDFS的存儲原理

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

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

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

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

（4）HDFS的部署和使用

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

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

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

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

流式數(shù)據(jù)訪問：HDFS是為了滿足批量數(shù)據(jù)處理要求而設(shè)計的，為了提高數(shù)據(jù)吞吐率，HDFS提供了流式方式來訪問文件系統(tǒng)數(shù)據(jù)。

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

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

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

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

無法高效存儲大量小文件：HDFS處理的數(shù)據(jù)單位是塊（一般來說是64MB），采用名稱節(jié)點來管理元數(shù)據(jù)，對于文件大小小于64MB的小文件，HDFS無法高效存儲和處理，過多的小文件會嚴(yán)重影響系統(tǒng)擴展性，大大增加線程管理開銷。

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

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

2、分布式數(shù)據(jù)庫

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

（1）HBase簡介

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

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

（2）HBase數(shù)據(jù)模型

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

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

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

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

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

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

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

（3）HBase系統(tǒng)架構(gòu)

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

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

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

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

HRegionServer節(jié)點用于：①存放和管理本地HRegion，一個HRegionServer可以存放1000個HRegion；②讀寫HDFS，管理Table中的數(shù)據(jù)；③Client直接通過HRegionServer讀寫數(shù)據(jù)（從HMaster中獲取元數(shù)據(jù)，找到RowKey所在的HRegion/HRegionServer后）。

3、分布式協(xié)調(diào)系統(tǒng)

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

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

（1）ZooKeeper簡介

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

（2）ZooKeeper數(shù)據(jù)模型和操作

ZooKeeper使用Java編寫，它使用一個與文件樹結(jié)構(gòu)相似的數(shù)據(jù)模型，可以使用Java或C來方便地進行編程接入。ZooKeeper樹中的每個節(jié)點被稱為Znode。與文件系統(tǒng)的目錄樹一樣，樹中的每個節(jié)點可以擁有子節(jié)點。一個節(jié)點自身擁有表示其狀態(tài)的許多重要屬性，見表1。

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

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

（3）ZooKeeper工作原理

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

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

一是選舉Leader過程。

二是同步數(shù)據(jù)過程。

在選舉Leader的過程中算法有很多，默認(rèn)的是Fast Paxos算法，無論何種算法，要達(dá)到的選舉目標(biāo)是一致的。Leader具有最高的執(zhí)行ID，類似root權(quán)限。集群中大多數(shù)的機器得到響應(yīng)并接受選出的Leader。

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

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

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

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

（1）NoSQL簡介

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

（2）NoSQL的四大類型

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

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

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

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

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

（3）NoSQL的三大理論基石

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

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

最終一致性：只要經(jīng)過一段時間后能訪問到更新后的數(shù)據(jù)即可。

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

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

5、資源管理調(diào)度

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

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

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

（2）資源管理調(diào)度目標(biāo)和局限

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

（3）資源管理調(diào)度模型框架

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

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

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

FIFO調(diào)度：按照時間先后順序或優(yōu)先級次序?qū)⑻峤坏淖鳂I(yè)放入線性隊列中，“先進先出”地進行資源調(diào)度和分配，是Hadoop默認(rèn)的調(diào)度策略，也是最簡單的策略。

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

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

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

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

圖8是一個抽象的通用資源管理框架，它簡單描述了如何將用戶和任務(wù)組織起來并進行資源管理、分配調(diào)度的大致流程。

從圖8可見，幾個關(guān)鍵的部件將資源管理調(diào)度的整個過程運作了起來。

一是節(jié)點管理器。集群中的每臺機器上都會配置節(jié)點管理器，用于不斷向資源收集器匯報當(dāng)前機器的資源使用情況并負(fù)責(zé)容器的管理。當(dāng)一個任務(wù)被分配到某個節(jié)點執(zhí)行時，當(dāng)前的節(jié)點管理器就會將其納入某個容器中，并對該容器進行資源隔離。

二是調(diào)度器。其由資源收集器和資源調(diào)度策略構(gòu)成，同時管理著資源池和工作隊列。資源收集器不斷地從節(jié)點管理器收集和更新資源狀態(tài)信息，并將最新狀況反映到資源池中；資源池列出當(dāng)前可用的系統(tǒng)資源，而資源調(diào)度策略決定如何將資源池中的可用資源分配給工作隊列；當(dāng)用戶提交新的作業(yè)或任務(wù)時，就會排隊進入工作隊列等待分配給它的資源。

（4）資源管理調(diào)度系統(tǒng)類型

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

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

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

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

（5）資源管理調(diào)度框架YARN

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

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

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

每個節(jié)點代理的節(jié)點管理器（Node Manager，NM）。

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

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

YARN整體架構(gòu)如圖10所示。

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

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

（6）資源管理調(diào)度框架Mesos

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

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

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

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