国产欧美日韩精品a在线观看-国产欧美日韩精品一区二区三区-国产欧美日韩精品综合-国产欧美中文字幕-一区二区三区精品国产-一区二区三区精品国产欧美

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

分布式文件系統

分布式數據庫

分布式協調系統

非關系型數據庫

資源管理調度

1、分布式文件系統

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

（1）HDFS的產生背景

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

（2）HDFS的整體架構

HDFS采用了典型的主/從（Master/Slave）架構模型，一個HDFS集群中包括一個名稱節點（NameNode）和若干個數據節點（DataNode）。

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

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

這種采用一個名稱節點管理所有元數據的架構設計大大簡化了分布式文件系統的結構，可以保證數據不會脫離名稱節點的控制，同時用戶數據也永遠不會經過名稱節點，減輕了中心服務器的負擔，提高了數據管理效率。

（3）HDFS的存儲原理

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

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

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

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

（4）HDFS的部署和使用

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

（5）HDFS的優缺點

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

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

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

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

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

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

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

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

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

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

2、分布式數據庫

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

（1）HBase簡介

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

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

（2）HBase數據模型

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

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

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

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

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

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

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

（3）HBase系統架構

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

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

ZooKeeper服務器是協調系統，用于存放整個HBase集群的元數據以及集群的狀態信息，以及實現HMaster主從節點的故障轉移，避免出現“單點失效”問題。

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

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

3、分布式協調系統

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

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

（1）ZooKeeper簡介

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

（2）ZooKeeper數據模型和操作

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

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

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

（3）ZooKeeper工作原理

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

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

一是選舉Leader過程。

二是同步數據過程。

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

（4）ZooKeeper和HBase的關系

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

4、非關系型數據庫

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

（1）NoSQL簡介

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

（2）NoSQL的四大類型

近幾年來，NoSQL領域迎來了爆炸式發展，目前已經產生了150多個新的數據庫，如HBase和MongoDB就是NoSQL類型。雖然其種類多樣，但歸結起來，典型的NoSQL數據庫通常包括以下四個類型：

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

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

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

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

（3）NoSQL的三大理論基石

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

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

最終一致性：只要經過一段時間后能訪問到更新后的數據即可。

（4）NoSQL的發展趨勢

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

5、資源管理調度

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

（1）資源管理調度發展趨勢

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

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

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

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

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

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

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

FIFO調度：按照時間先后順序或優先級次序將提交的作業放入線性隊列中，“先進先出”地進行資源調度和分配，是Hadoop默認的調度策略，也是最簡單的策略。

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

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

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

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

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

從圖8可見，幾個關鍵的部件將資源管理調度的整個過程運作了起來。

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

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

（4）資源管理調度系統類型

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

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

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

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

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

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

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

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

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

每個應用都有一個的應用服務器（Application Master，AM）。

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

YARN整體架構如圖10所示。

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

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

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

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

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

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

來源：計算機與網絡安全