如何对海量数据进行存储和管理，是大数据时代必须解决的问题。存储是所有大数据组件的基础，存储的关键是把数据持久保存下来，而对支撑这些的硬件资源（服务器集群、数据中心）如何进行统一管理和资源调配以提高资源利用率，也是我们需要关注的重要方面。本文介绍网络安全态势感知可能会用到的几种大数据存储与管理技术，包括：

分布式文件系统

分布式数据库

分布式协调系统

非关系型数据库

资源管理调度

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不支持抢占式调度，资源分配出去后只能等待任务运行结束后自行释放，如果是大量短作业则资源释放速度较快，这样总有新资源可分配，而对于后续任务来说可以较快获得资源，避免长时间等待。

来源：计算机与网络安全