久久久91-久久久91精品国产一区二区-久久久91精品国产一区二区三区-久久久999国产精品-久久久999久久久精品

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

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

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

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

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

資源管理調(diào)度

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

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

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

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

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

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

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

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

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

（3）HDFS的存儲(chǔ)原理

HDFS的存儲(chǔ)主要包括以下幾種機(jī)制和策略：

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

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

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

（4）HDFS的部署和使用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）HBase簡(jiǎn)介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）ZooKeeper簡(jiǎn)介

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

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

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

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

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

（3）ZooKeeper工作原理

ZooKeeper的核心是原子廣播，這個(gè)機(jī)制保證了各個(gè)服務(wù)器之間的同步。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié)議稱為Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式（選主）和廣播模式（同步）。當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者（Leader）“崩潰”后，Zab就進(jìn)入了恢復(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)有多個(gè)proposer（申請(qǐng)者）交錯(cuò)提交時(shí)，有可能互相排斥導(dǎo)致沒有一個(gè)proposer能提交成功，而Fast Paxos進(jìn)行了一些優(yōu)化，通過選舉產(chǎn)生一個(gè)Leader，只有Leader才能提交申請(qǐng)，ZooKeeper的基本工作過程如下：

一是選舉Leader過程。

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

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

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

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

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

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

（1）NoSQL簡(jiǎn)介

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

（2）NoSQL的四大類型

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

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

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

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

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

（3）NoSQL的三大理論基石

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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