华为云用户手册

HDFS开源增强特性：HDFS启动加速 在HDFS中，NameNode启动需要加载元数据文件fsimage，然后等待DataNode完成启动并上报数据块信息。当DataNode上报的数据块信息达到设定百分比时，NameNode退出Safemode，完成启动过程。当HDFS上保存的文件数量达到千万甚至亿级以后，以上两个过程都要耗费大量的时间，致使NameNode的启动过程变得非常漫长。该版本对加载元数据fsimage这一过程进行了优化。 在开源HDFS中，fsimage里保存了所有类型的元数据信息，每一类元数据信息（如文件元数据信息和文件夹元数据信息）分别保存在一个section块里，这些section块在启动时是串行加载的。当HDFS上存储了大量的文件和文件夹时，这两个section的加载就会非常耗时，影响HDFS文件系统的启动时间。HDFS NameNode在生成fsimage时可以将同一类型的元数据信息分段保存在多个section里，当NameNode启动时并行加载fsimage中的section以加快加载速度。

HDFS开源增强特性：HDFS冷热数据迁移 Hadoop历来主要被用于批量处理大规模的数据。相比处理低时延，批处理应用更关注原始数据处理的吞吐量，因此，目前已有的HDFS模型都运作良好。 然而，随着技术的发展，Hadoop逐渐被用于以随机I/O访问模式的操作为主的上层应用上，如Hive、HBase等，而这种时延要求较高的场景中，低时延的高速磁盘（如SSD磁盘）可以得到广泛的应用。为了支持这种特性，HDFS现在支持了异构存储类型，这样用户就可以根据自己不同的业务需求场景来选择不同的数据存储类型。 因此，HDFS可以根据数据的热度，选择不同的存储策略。如将HDFS上频繁访问多次的数据被标识为ALL_SSD或HOT，被访问几次的可以标识为WARM，而只有访问1～2次甚至更少的可以被标识为COLD等，如下图为不同的数据热度，可以选择不同的数据存储策略。 但是，这些高速低时延磁盘，例如SSD磁盘，通常比机械磁盘贵很多。大部分用户希望只有那些经常被访问的热数据才能一直被存储在昂贵的高速磁盘上，而随着数据的访问热度下降以及时间的老化，这些数据应该被迁移到价格低廉的存储介质上。 以详单查询场景作为典型的用例场景，进行说明：当最新详单数据刚刚被导入HDFS上时，会被上层业务人员频繁查询，所以为了提高查询性能，可以将这些详单数据最先导入到SSD磁盘中；但是随着时间的迁移，这些数据逐渐被老化，访问频度越来越低，这时便不适合继续存储在高速硬盘上，需要迁移到廉价的存储介质，节省成本。 目前，如下图所示，HDFS无法很好的支持这些操作，需要自己根据业务类型手动识别数据的热度，并且手动设定数据的存储策略，最后手动触发HDFS Auto Data Movement工具进行数据迁移。 因此，能够基于数据的age自动识别出老化的数据，并将它们迁移到价格低廉的存储介质（如Disk/Archive）上，会给用户节省很高的存储成本，提高数据管理效率。 HDFS Auto Data Movement工具是HDFS冷热数据迁移的核心，根据数据的使用频率自动识别数据冷热设定不同的存储策略。该工具主要支持以下功能： 根据数据的age，access time和手动迁移规则，将数据存储策略标识为All_SSD/One_SSD/Hot/Warm/Cold。 根据数据age，access time和手动迁移规则，定义区分冷热数据的规则。 定义基于age的规则匹配时要采取的行为操作。 MARK：表示只会基于age规则标识出数据的冷热度，并设置出对应的存储策略。 MOVE：表示基于age规则识别出相应的数据冷热度，并标记出对应的存储策略后，并触发HDFS Auto Data Movement工具进行数据搬迁，调用HDFS冷热数据迁移工具并跨层迁移数据的行为操作。 SET_REPL：为文件设置新的副本数的行为操作。 MOVE_TO_FOLDER：将文件移动到目标文件夹的行为操作。 DELETE：删除文件/目录的行为操作。 SET_NODE_LABEL：设置文件节点标签（NodeLabel）的操作。 使用HDFS冷热数据迁移功能，只需要定义age，基于access time的规则。由HDFS冷热数据迁移工具来匹配基于age的规则的数据，设置存储策略和迁移数据。以这种方式，提高了数据管理效率和集群资源效率。

HDFS开源增强特性：硬盘坏卷设置 在开源版本中，如果为DataNode配置多个数据存放卷，默认情况下其中一个卷损坏，则DataNode将不再提供服务。配置项“dfs.datanode.failed.volumes.tolerated”可以指定失败的个数，小于该个数，DataNode可以继续提供服务。 “dfs.datanode.failed.volumes.tolerated”取值范围为-1~DataNode上配置的磁盘卷数，默认值为-1，效果如图3所示。 图3 选项设置为0 例如：某个DataNode中挂载了3个数据存放卷，“dfs.datanode.failed.volumes.tolerated”配置为1，则当该DataNode中的其中一个数据存放卷不能使用的时候，该DataNode会继续提供服务。如图4所示。 图4 选项设置为1 这个原生的配置项，存在一定的缺陷。当DataNode的数据存放卷数量不一致的时候，就需要对每个DataNode进行单独配置，而无法配置为所有节点统一生成配置文件，造成用户使用的不便。 例如：集群中存在3个DataNode节点，第一个节点有3个数据目录，第二个节点有4个数据目录，第三个节点有5个数据目录，如果需要实现当节点有一个目录还可用的时候DataNode服务依然可用的效果，就需要如图5所示进行设置。 图5 未增强前属性设置 在自研增强版本的HDFS中，对该配置项进行了增强，增加了-1的值选项。当配置成-1的时候，所有DataNode节点只要还有一个数据存放卷，DataNode就能继续提供服务。 所以对于上面提到的例子，该属性的配置将统一成-1，如图6所示。 图6 增强后属性配置

HDFS开源增强特性：文件块同分布（Colocation） 离线数据汇总统计场景中，Join是一个经常用到的计算功能，在MapReduce中的实现方式大体如下： Map任务分别将两个表文件的记录处理成（Join Key，Value），然后按照Join Key做Hash分区后，送到不同的Reduce任务里去处理。 Reduce任务一般使用Nested Loop方式递归左表的数据，并遍历右表的每一行，对于相等的Join Key，处理Join结果并输出。 以上方式的最大问题在于，由于数据分散在各节点上，所以在Map到Reduce过程中，需要大量的网络数据传输，使得Join计算的性能大大降低，该过程如图1所示： 图1 无同分布数据传输流程 由于数据表文件是以HDFS Block方式存放在物理文件系统中，如果能把两个需要Join的文件数据块按Join Key分区后，一一对应地放在同一台机器上，则在Join计算的Reduce过程中无需传递数据，直接在节点本地做Map Join后就能得到结果，性能显著提升。 HDFS数据同分布特性，使得需要做关联和汇总计算的两个文件FileA和FileB，通过指定同一个分布ID，使其所有的Block分布在一起，不再需要跨节点读取数据就能完成计算，极大提高MapReduce Join性能。 图2 无同分布与同分布数据块分布对比

HDFS开源增强特性：HDFS Load Balance HDFS的现有读写策略主要以数据本地性优先为主，并未考虑节点或磁盘的实际负载情况。HDFS Load Balance功能是基于不同节点的I/O负载情况，在HDFS客户端进行读写操作时，尽可能地选择I/O负载较低的节点进行读写，以此达到I/O负载均衡，以及充分利用集群整体吞吐能力。 写文件时，如果开启写文件的HDFS Load Balance功能，NameNode仍然是根据正常顺序（本地节点—本机架—远端机架）进行DataNode节点的选取，只是在每次选择节点后，如果该节点I/O负载较高，会舍弃并从其他节点中重新选取。 读文件时，Client会向NameNode请求所读Block所在的DataNode列表。NameNode会返回根据网络拓扑距离进行排序的DataNode列表。开启读取的HDFS Load Balance功能时，NameNode会在原先网络拓扑距离排序的基础上，根据每个节点的平均I/O负载情况进行顺序调整，把高I/O负载的节点顺序调整至后面。

ZooKeeper和HBase的关系 ZooKeeper与HBase的关系如图3所示。 图3 ZooKeeper和HBase的关系 RegionServer以Ephemeral node的方式注册到ZooKeeper中。其中ZooKeeper存储HBase的如下信息：HBase元数据、HMaster地址。 HMaster通过ZooKeeper随时感知各个RegionServer的健康状况，以便进行控制管理。 HBase也可以部署多个HMaster，类似HDFS NameNode，当HMaster主节点出现故障时，HMaster备用节点会通过ZooKeeper获取主HMaster存储的整个HBase集群状态信息。即通过ZooKeeper实现避免HBase单点故障问题的问题。

ZooKeeper和YARN的关系 ZooKeeper与YARN的关系如图2所示。 图2 ZooKeeper与YARN的关系 在系统启动时，ResourceManager会尝试把选举信息写入ZooKeeper，第一个成功写入ZooKeeper的ResourceManager被选举为Active ResourceManager，另一个为Standby ResourceManager。Standby ResourceManager定时去ZooKeeper监控Active ResourceManager选举信息。 Active ResourceManager还会在ZooKeeper中创建Statestore目录，存储Application相关信息。当Active ResourceManager产生故障时，Standby ResourceManager会从Statestore目录获取Application相关信息，恢复数据。

ZooKeeper和Kafka的配合关系 ZooKeeper与Kafka的关系如图 ZooKeeper和Kafka的关系所示。 图4 ZooKeeper和Kafka的关系 Broker端使用ZooKeeper用来注册broker信息，并进行partition leader选举。 Consumer端使用ZooKeeper用来注册consumer信息，其中包括consumer消费的partition列表等，同时也用来发现broker列表，并和partition leader建立socket连接，并获取消息。

ZooKeeper和HDFS的关系 ZooKeeper与HDFS的关系如图1所示。 图1 ZooKeeper和HDFS的关系 ZKFC（ZKFailoverController）作为一个ZooKeeper集群的客户端，用来监控NameNode的状态信息。ZKFC进程仅在部署了NameNode的节点中存在。HDFS NameNode的Active和Standby节点均部署有ZKFC进程。 HDFS NameNode的ZKFC连接到ZooKeeper，把主机名等信息保存到ZooKeeper中，即“/hadoop-ha”下的znode目录里。先创建znode目录的NameNode节点为主节点，另一个为备节点。HDFS NameNode Standby通过ZooKeeper定时读取NameNode信息。 当主节点进程异常结束时，HDFS NameNode Standby通过ZooKeeper感知“/hadoop-ha”目录下发生了变化，NameNode会进行主备切换。

Storm原理 基本概念 表1 概念介绍 概念 说明 Tuple Storm核心数据结构，是消息传递的基本单元，不可变Key-Value对，这些Tuple会以一种分布式的方式进行创建和处理。 Stream Storm的关键抽象，是一个无边界的连续Tuple序列。 Topology 在Storm平台上运行的一个实时应用程序，由各个组件（Component）组成的一个DAG（Directed Acyclic Graph）。一个Topology可以并发地运行在多台机器上，每台机器上可以运行该DAG中的一部分。Topology与Hadoop中的MapReduce Job类似，不同的是，它是一个长驻程序，一旦开始就不会停止，除非人工中止。 Spout Topology中产生源数据的组件，是Tuple的来源，通常可以从外部数据源（如消息队列、数据库、文件系统、TCP连接等）读取数据，然后转换为Topology内部的数据结构Tuple，由下一级组件处理。 Bolt Topology中接受数据并执行具体处理逻辑（如过滤，统计、转换、合并、结果持久化等）的组件。 Worker 是Topology运行态的物理进程。每个Worker是一个JVM进程，每个Topology可以由多个Worker并行执行，每个Worker运行Topology中的一个逻辑子集。 Task Worker中每一个Spout/Bolt的线程称为一个Task。 Stream groupings Storm中的Tuple分发策略，即后一级Bolt以什么分发方式来接收数据。当前支持的策略有：Shuffle Grouping， Fields Grouping， All Grouping， Global Grouping， Non Grouping， Directed Grouping。 图3描述了一个由Spout、Bolt组成的DAG，即Topology。图中每个矩形框代表Spout或者Bolt，矩形框内的节点表示各个并发的Task，Task之间的“边”代表数据流——Stream。 图3 Topology示意图 可靠性 Storm提供三种级别的数据可靠性： 至多一次：处理的数据可能会丢失，但不会被重复处理。此情况下，系统吞吐量最大。 至少一次：保证数据传输可靠，但可能会被重复处理。此情况下，对在超时时间内没有获得成功处理响应的数据，会在Spout处进行重发，供后续Bolt再次处理，会对性能稍有影响。 精确一次：数据成功传递，不丢失，不冗余处理。此情况下，性能最差。 可靠性不同级别的选择，需要根据业务对可靠性的要求来选择、设计。例如对于一些对数据丢失不敏感的业务，可以在业务中不考虑数据丢失处理从而提高系统性能；而对于一些严格要求数据可靠性的业务，则需要使用精确一次的可靠性方案，以确保数据被处理且仅被处理一次。 容错 Storm是一个容错系统，提供较高可用性。表2从Storm的不同部件失效的情况角度解释其容错能力： 表2 容错能力 失效场景 说明 Nimbus失效 Nimbus是无状态且快速失效的。当主Nimbus失效时，备Nimbus会接管，并对外提供服务。 Supervisor失效 Supervisor是工作节点的后台守护进程，是一种快速失效机制，且是无状态的，并不影响正在该节点上运行的Worker，但是会无法接收新的Worker分配。当Supervisor失效时，OMS会侦测到，并及时重启该进程。 Worker失效 该Worker所在节点上的Supervisor会在此节点上重新启动该Worker。如果多次重启失败，则Nimbus会将该任务重新分配到其他节点。 节点失效 该节点上的所有分配的任务会超时，而Nimbus会将这些Worker重新分配到其他节点。

Storm开源特性 分布式实时计算框架 开源Storm集群中的每台机器上都可以运行多个工作进程，每个工作进程又可创建多个线程，每个线程可以执行多个任务，任务是并发进行数据处理。 高容错 如果在消息处理过程中有节点、进程等出现异常，提供重新部署该处理单元的能力。 可靠的消息保证 支持At-Least Once、At-Most Once、Exactly Once的数据处理模式。 安全机制 提供基于Kerberos的认证以及可插拔的授权机制，提供支持SSL的Storm UI以及Log Viewer界面，同时支持与大数据平台其他组件（如ZooKeeper，HDFS等）进行安全集成。 灵活的拓扑定义及部署 使用Flux框架定义及部署业务拓扑，在业务DAG发生变化时，只需对YAML DSL（domain-specific language）定义进行修改，无需重新编译及打包业务代码。 与外部组件集成 支持与多种外部组件集成，包括：Kafka、HDFS、HBase、Redis或JDBC/RDBMS等服务，便于实现涉及多种数据源的业务。

Hive结构 Hive为单实例的服务进程，提供服务的原理是将HQL编译解析成相应的MapReduce或者HDFS任务，图1为Hive的结构概图。 图1 Hive结构 表1 模块说明 名称 说明 HiveServer 一个集群内可部署多个HiveServer，负荷分担。对外提供Hive数据库服务，将用户提交的HQL语句进行编译，解析成对应的Yarn任务或者HDFS操作，从而完成数据的提取、转换、分析。 MetaStore 一个集群内可部署多个MetaStore，负荷分担。提供Hive的元数据服务，负责Hive表的结构和属性信息读、写、维护和修改。 提供Thrift接口，供HiveServer、Spark、WebHCat等MetaStore客户端来访问，操作元数据。 WebHCat 一个集群内可部署多个WebHCat，负荷分担。提供Rest接口，通过Rest执行Hive命令，提交MapReduce任务。 Hive客户端 包括人机交互命令行Beeline、提供给JDBC应用的JDBC驱动、提供给Python应用的Python驱动、提供给MapReduce的HCatalog相关JAR包。 ZooKeeper集群 ZooKeeper作为临时节点记录各HiveServer实例的IP地址列表，客户端驱动连接ZooKeeper获取该列表，并根据路由机制选取对应的HiveServer实例。 HDFS/HBase集群 Hive表数据存储在HDFS集群中。 MapReduce/Yarn集群 提供分布式计算服务：Hive的大部分数据操作依赖MapReduce，HiveServer的主要功能是将HQL语句转换成MapReduce任务，从而完成对海量数据的处理。 HCatalog建立在Hive Metastore之上，具有Hive的DDL能力。从另外一种意义上说，HCatalog还是Hadoop的表和存储管理层，它使用户能够通过使用不同的数据处理工具（比如MapReduce），更轻松地在网格上读写HDFS上的数据，HCatalog还能为这些数据处理工具提供读写接口，并使用Hive的命令行接口发布数据定义和元数据探索命令。此外，经过封装这些命令，WebHCat Server还对外提供了RESTful接口，如图2所示。 图2 WebHCat的逻辑架构图

Hive原理 Hive作为一个基于HDFS和MapReduce架构的数据仓库，其主要能力是通过对HQL（Hive Query Language）编译和解析，生成并执行相应的MapReduce任务或者HDFS操作。Hive与HQL相关信息，请参考HQL 语言手册。 图3为Hive的结构简图。 Metastore：对表，列和Partition等的元数据进行读写及更新操作，其下层为关系型数据库。 Driver：管理HQL执行的生命周期并贯穿Hive任务整个执行期间。 Compiler：编译HQL并将其转化为一系列相互依赖的Map/Reduce任务。 Optimizer：优化器，分为逻辑优化器和物理优化器，分别对HQL生成的执行计划和MapReduce任务进行优化。 Executor：按照任务的依赖关系分别执行Map/Reduce任务。 ThriftServer：提供thrift接口，作为JDBC的服务端，并将Hive和其他应用程序集成起来。 Clients：包含WebUI和JDBC接口，为用户访问提供接口。 图3 Hive结构

Kafka结构 生产者（Producer）将消息发布到Kafka主题（Topic）上，消费者（Consumer）订阅这些主题并消费这些消息。在Kafka集群上一个服务器称为一个Broker。对于每一个主题，Kafka集群保留一个用于缩放、并行化和容错性的分区（Partition）。每个分区是一个有序、不可变的消息序列，并不断追加到提交日志文件。分区的消息每个也被赋值一个称为偏移顺序（Offset）的序列化编号。 图1 Kafka结构

Kafka原理 消息可靠性 Kafka Broker收到消息后，会持久化到磁盘，同时，Topic的每个Partition有自己的Replica（备份），每个Replica分布在不同的Broker节点上，以保证当某一节点失效时，可以自动故障转移到可用消息节点。 高吞吐量 Kafka通过以下方式提供系统高吞吐量： 数据磁盘持久化：消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写性能。 Zero-copy：减少IO操作步骤。 数据批量发送：提高网络利用率。 Topic划分为多个Partition，提高并发度，可以由多个Producer、Consumer数目之间的关系并发来读、写消息。Producer根据用户指定的算法，将消息发送到指定的Partition。 消息订阅-通知机制 消费者对感兴趣的主题进行订阅，并采取pull的方式消费数据，使得消费者可以根据其消费能力自主地控制消息拉取速度，同时，可以根据自身情况自主选择消费模式，例如批量、重复消费，从尾端开始消费等；另外，需要消费者自己负责维护其自身消息的消费记录。 可扩展性 当在Kafka集群中可通过增加Broker节点以提供更大容量时。新增的Broker会向ZooKeeper注册，而Producer及Consumer会及时从ZooKeeper感知到这些变化，并作出调整。

Kafka开源特性 可靠性 提供At-Least Once，At-Most Once，Exactly Once消息可靠传递。消息被处理的状态是在Consumer端维护，需要结合应用层实现Exactly Once。 高吞吐 同时为发布和订阅提供高吞吐量。 持久化 将消息持久化到磁盘，因此可用于批量消费以及实时应用程序。通过将数据持久化到硬盘以及replication的方式防止数据丢失。 分布式 分布式系统，易于向外扩展。每个集群支持部署多个Producer、Broker和Consumer，从而形成分布式的集群，无需停机即可扩展系统。

Kafka UI Kafka UI提供Kafka Web服务，通过界面展示Kafka集群中Broker、Topic、Partition、Consumer等功能模块的基本信息，同时提供Kafka服务常用命令的界面操作入口。该功能作为Kafka Manager替代，提供符合安全规范的Kafka Web服务。 通过Kafka UI可以进行以下操作： 支持界面检查集群状态（主题，消费者，偏移量，分区，副本，节点） 支持界面执行集群内分区重新分配 支持界面选择配置创建主题 支持界面删除主题（Kafka服务设置了参数“delete.topic.enable = true”） 支持为已有主题增加分区 支持更新现有主题的配置 可以为分区级别和主题级别度量标准启用JMX查询

Hue结构 Hue是建立在Django Python（开放源代码的Web应用框架）的Web框架上的Web应用程序，采用了MTV（模型M-模板T-视图V）的软件设计模式。 Hue由“Supervisor Process”和“WebServer”构成，“Supervisor Process”是Hue的核心进程，负责应用进程管理。“Supervisor Process”和“WebServer”通过“THRIFT/REST”接口与WebServer上的应用进行交互，如图1所示。 图1 Hue架构示意图 图1中各部分的功能说明如表1所示。 表1 结构图说明 名称 描述 Supervisor Process Supervisor负责WebServer上APP的进程管理：启动、停止、监控等。 Hue WebServer 通过Django Python的Web框架提供如下功能。 部署APPs。 提供图形化用户界面。 与数据库连接，存储APP的持久化数据。

KrbServer及LdapServer简介 为了管理集群中数据与资源的访问控制权限，推荐安装安全模式集群。在安全模式下，客户端应用程序在访问集群中的任意资源之前均需要通过身份认证，建立安全会话链接。MRS通过KrbServer为所有组件提供Kerberos认证功能，实现了可靠的认证机制。 LdapServer支持轻量目录访问协议（Lightweight Directory Access Protocol，简称为LDAP），为Kerberos认证提供用户和用户组数据保存能力。

KrbServer及LdapServer结构 用户登录时安全认证功能主要依赖于Kerberos和LDAP。 图1 安全认证场景架构 图1可分为三类场景： 登录Manager WebUI 认证架构包含步骤1、2、3、4 登录组件Web UI 认证架构包含步骤5、6、7、8 组件间访问 认证架构为步骤9 表1 关键模块解释 名称 含义 Manager 集群Manager Manager WS WebBrowser Kerberos1 部署在Manager中的KrbServer（管理平面）服务，即OMS Kerberos Kerberos2 部署在集群中的KrbServer（业务平面）服务 LDAP1 部署在Manager中的LdapServer（管理平面）服务，即OMS LDAP LDAP2 部署在集群中的LdapServer（业务平面）服务 Kerberos1访问LDAP数据：以负载均衡方式访问主备LDAP1两个实例和双备LDAP2两个实例。只能在主LDAP1主实例上进行数据的写操作，可以在LDAP1或者LDAP2上进行数据的读操作。 Kerberos2访问LDAP数据：读操作可以访问LDAP1和LDAP2，数据的写操作只能在主LDAP1实例进行。

KrbServer及LdapServer原理 Kerberos认证 图2 认证流程图 LDAP数据读写 图3 数据修改过程 LDAP数据同步 安装集群前OMS LDAP数据同步 图4 OMS LDAP数据同步 安装集群前数据同步方向：主OMS LDAP同步到备OMS LDAP。 安装集群后LDAP数据同步 图5 LDAP数据同步 安装集群后数据同步方向：主OMS LDAP同步到备OMS LDAP、备组件LDAP和备组件LDAP。

ZooKeeper开源增强特性：ZooKeeper SSL通信（Netty连接） ZooKeeper设计最初含有Nio包，且不能较好的支持3.5版本后的SSL。为了解决这个问题，Netty被加入到ZooKeeper中。所以如果用户需要使用SSL，启用Netty并设置Server端和Client端的以下参数。 开源的服务端只支持简单的文本密码，这可能导致相关安全问题。为此在服务端将不再使用此类文本密码。 Client端 将“zkCli.sh/zkEnv.sh”文件中的参数“-Dzookeeper.client.secure”设置为“true”以在Client端使用安全通信。之后客户端可以连接服务端的secureClientPort。 通过设置“zkCli.sh/zkEnv.sh”文件中的以下参数配置客户端环境。 参数 描述 -Dzookeeper.clientCnxnSocket 用于客户端的Netty通信。 默认值："org.apache.zookeeper.ClientCnxnSocketNetty" -Dzookeeper.ssl.keyStore.location keystore文件路径。 -Dzookeeper.ssl.keyStore.password 加密密码。 -Dzookeeper.ssl.trustStore.location truststore文件路径。 -Dzookeeper.ssl.trustStore.password 加密密码。 -Dzookeeper.config.crypt.class 用于加密密码的解密。 -Dzookeeper.ssl.password.encrypted 默认值：false 当keystore和truststore的密码为加密密码时设置为true。 -Dzookeeper.ssl.enabled.protocols 通过配置此参数定义SSL协议以适用于SSL上下文。 -Dzookeeper.ssl.exclude.cipher.ext 通过配置此参数定义SSL上下文中应排除的密码列表，之间以逗号间隔。 以上参数须在“zkCli.sh/zk.Env.sh”文件内设置。 Server端 在文件“zoo.cfg”中将SSL端口参数“secureClientPort”设置为“3381”。 在server端将文件“zoo.cfg”中的参数“zookeeper.serverCnxnFactory”设置为“org.apache.zookeeper.server.NettyServerCnxnFactory”。 设置文件zoo.cfg（路径：“zookeeper/conf/zoo.cfg”）中的以下参数来配置服务端环境。 参数 描述 ssl.keyStore.location keystore.jks文件路径。 ssl.keyStore.password 加密密码。 ssl.trustStore.location truststore文件路径。 ssl.trustStore.password 加密密码。 config.crypt.class 用于加密密码的解密。 ssl.keyStore.password.encrypted 默认值：false 设置为true时可使用加密密码。 ssl.trustStore.password.encrypted 默认值：false 设置为true时可使用加密密码。 ssl.enabled.protocols 通过配置此参数定义SSL协议以适用于SSL上下文。 ssl.exclude.cipher.ext 通过配置此参数定义SSL上下文中应排除的密码列表，之间以逗号间隔。 启动ZKserver，然后将安全客户端连接到安全端口。 凭证 ZooKeeper上Client和Server之间的凭证由X509AuthenticationProvider执行。根据以下参数指定服务端证书及信任客户端证书，并通过这些证书初始化X509AuthenticationProvider。 zookeeper.ssl.keyStore.location zookeeper.ssl.keyStore.password zookeeper.ssl.trustStore.location zookeeper.ssl.trustStore.password 若用户不想使用ZooKeeper的默认机制，可根据所需配置不同的ZooKeeper信任机制。

MapReduce开源增强特性：特定场景优化MapReduce的Merge/Sort流程提升MapReduce性能 下图展示了MapReduce任务的工作流程。 图2 MapReduce 作业 图3 MapReduce作业执行流程 Reduce过程分为三个不同步骤：Copy、Sort（实际应当称为Merge）及Reduce。在Copy过程中，Reducer尝试从NodeManagers获取Maps的输出并存储在内存或硬盘中。紧接着进行Shuffle过程（包含Sort及Reduce），这个过程将获取到的Maps输出进行存储并有序地合并然后提供给Reducer。当Job有大量的Maps输出需要处理的时候，Shuffle过程将变得非常耗时。对于一些特定的任务（例如hash join或hash aggregation类型的SQL任务），Shuffle过程中的排序并非必须的。但是Shuffle却默认必须进行排序，所以需要对此处进行改进。 此特性通过对MapReduce API进行增强，能自动针对此类型任务关闭Sort过程。当Sort被关闭，获取Maps输出数据以后，直接合并后输出给Reduce，避免了由于排序而浪费大量时间。这种方式极大程度地提升了大部分SQL任务的效率。

MapReduce开源增强特性：History Server优化解决日志小文件问题 运行在Yarn上的作业在执行完成后，NodeManager会通过LogAggregationService把产生的日志收集到HDFS上，并从本地文件系统中删除。日志收集到HDFS上以后由HistoryServer来进行统一的日志管理。LogAggregationService在收集日志时会把container产生的本地日志合并成一个日志文件上传到HDFS，在一定程度上可以减少日志文件的数量。但在规模较大且任务繁忙的集群上，经过长时间的运行，HDFS依然会面临存储的日志文件过多的问题。 以一个20节点的计算场景为例，默认清理周期（15日）内将产生约1800万日志文件，占用NameNode近18G内存空间，同时拖慢HDFS的系统响应速度。 由于收集到HDFS上的日志文件只有读取和删除的需求，因此可以利用Hadoop Archives功能对收集的日志文件目录进行定期归档。 日志归档 在HistoryServer中新增AggregatedLogArchiveService模块，定期检查日志目录中的文件数。在文件数达到设定阈值时，启动归档任务进行日志归档，并在归档完成后删除原日志文件，以减少HDFS上的文件数量。 归档日志清理 由于Hadoop Archives不支持在归档文件中进行删除操作，因此日志清理时需要删除整个归档文件包。通过修改AggregatedLogDeletionService模块，获取归档日志中最新的日志生成时间，若所有日志文件均满足清理条件，则清理该归档日志包。 归档日志浏览 Hadoop Archives支持URI直接访问归档包中的文件内容，因此浏览过程中，当History Server发现原日志文件不存在时，直接将URI重定向到归档文件包中即可访问到已归档的日志文件。 本功能通过调用HDFS的Hadoop Archives功能进行日志归档。由于Hadoop Archives归档任务实际上是执行一个MR应用程序，所以在每次执行日志归档任务后，会新增一条MR执行记录。 本功能归档的日志来源于日志收集功能，因此只有在日志收集功能开启状态下本功能才会生效。

MapReduce开源增强特性：JobHistoryServer HA特性 JobHistoryServer（JHS）是用于查看MapReduce历史任务信息的服务器，当前开源JHS只支持单实例服务。JobHistoryServer HA能够解决JHS单点故障时，应用访问MapReduce接口无效，导致整体应用执行失败的场景，从而大大提升MapReduce服务的高可用性。 图1 JobHistoryServer HA主备倒换的状态转移过程 JobHistoryServer高可用性 采用ZooKeeper实现主备选举和倒换。 JobHistoryServer使用浮动IP对外提供服务。 兼容JHS单实例，也支持HA双实例。 同一时刻，只有一个节点启动JHS进程，防止多个JHS操作同一文件冲突。 支持扩容减容、实例迁移、升级、健康检查等。

YARN结构 YARN分层结构的本质是ResourceManager。这个实体控制整个集群并管理应用程序向基础计算资源的分配。ResourceManager将各个资源部分（计算、内存、带宽等）精心安排给基础NodeManager（YARN的每个节点代理）。ResourceManager还与Application Master一起分配资源，与NodeManager一起启动和监视它们的基础应用程序。在此上下文中，Application Master承担了以前的TaskTracker的一些角色，ResourceManager承担了JobTracker的角色。 Application Master管理一个在YARN内运行的应用程序的每个实例。Application Master负责协调来自ResourceManager的资源，并通过NodeManager监视容器的执行和资源使用（CPU、内存等的资源分配）。 NodeManager管理一个YARN集群中的每个节点。NodeManager提供针对集群中每个节点的服务，从监督对一个容器的终生管理到监视资源和跟踪节点健康。MRv1通过插槽管理Map和Reduce任务的执行，而NodeManager管理抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。 图1 YARN结构 图1中各部分的功能如表1所示。 表1 结构图说明 名称 描述 Client YARN Application客户端，用户可以通过客户端向ResourceManager提交任务，查询Application运行状态等。 ResourceManager(RM) 负责集群中所有资源的统一管理和分配。接收来自各个节点（NodeManager）的资源汇报信息，并根据收集的资源按照一定的策略分配给各个应用程序。 NodeManager(NM) NodeManager（NM）是YARN中每个节点上的代理，管理Hadoop集群中单个计算节点，包括与ResourceManger保持通信，监督Container的生命周期管理，监控每个Container的资源使用（内存、CPU等）情况，追踪节点健康状况，管理日志和不同应用程序用到的附属服务（auxiliary service）。 ApplicationMaster(AM) 即图中的App Mstr，负责一个Application生命周期内的所有工作。包括：与RM调度器协商以获取资源；将得到的资源进一步分配给内部任务（资源的二次分配）；与NM通信以启动/停止任务；监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。 Container Container是YARN中的资源抽象，封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等（目前仅封装内存和CPU），当AM向RM申请资源时，RM为AM返回的资源便是用Container表示。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。 在YARN中，资源调度器是以层级队列方式组织资源的，这种组织方式有利于资源在不同队列间分配和共享，进而提高集群资源利用率。如下图所示，Superior Scheduler和Capacity Scheduler的核心资源分配模型相同。 调度器会维护队列的信息。用户可以向一个或者多个队列提交应用。每次NM心跳的时候，调度器会根据一定规则选择一个队列，再选择队列上的一个应用，并尝试在这个应用上分配资源。若因参数限制导致分配失败，将选择下一个应用。选择一个应用后，调度器会处理此应用的资源申请。其优先级从高到低依次为：本地资源的申请、同机架的申请，任意机器的申请。 图2 资源分配模型

YARN原理 新的Hadoop MapReduce框架被命名为MRv2或YARN。YARN主要包括ResourceManager、ApplicationMaster与NodeManager三个部分。 ResourceManager：RM是一个全局的资源管理器，负责整个系统的资源管理和分配。主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager）。 调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念Container表示。Container是一个动态资源分配单位，将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler等。 应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等。 NodeManager：NM是每个节点上的资源和任务管理器，一方面，会定时向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，接收并处理来自AM的Container启动/停止等请求。 ApplicationMaster：AM负责一个Application生命周期内的所有工作。包括： 与RM调度器协商以获取资源。 将得到的资源进一步分配给内部的任务（资源的二次分配）。 与NM通信以启动/停止任务。 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

开源容量调度器Capacity Scheduler原理 Capacity Scheduler是一种多用户调度器，它以队列为单位划分资源，为每个队列设定了资源最低保证和使用上限。同时，也为每个用户设定了资源使用上限以防止资源滥用。而当一个队列的资源有剩余时，可暂时将剩余资源共享给其他队列。 Capacity Scheduler支持多个队列，为每个队列配置一定的资源量，并采用FIFO调度策略。为防止同一用户的应用独占队列资源，Capacity Scheduler会对同一用户提交的作业所占资源量进行限定。调度时，首先计算每个队列使用的资源，选择使用资源最少的队列；然后按照作业优先级和提交时间顺序选择，同时考虑用户资源量的限制和内存限制。Capacity Scheduler主要有如下特性： 容量保证。MRS集群管理员可为每个队列设置资源最低保证和资源使用上限，而所有提交到队列的应用程序共享这些资源。 灵活性。如果一个队列中的资源有剩余，可以暂时共享给那些需要资源的队列，而一旦该队列有新的应用程序提交，则占用资源的队列将资源释放给该队列。这种资源灵活分配的方式可明显提高资源利用率。 多重租赁。支持多用户共享集群和多应用程序同时运行。为防止单个应用程序、用户或者队列独占集群中的资源，MRS集群管理员可为之增加多重约束（比如单个应用程序同时运行的任务数等）。 安全保证。每个队列有严格的ACL列表规定它的访问用户，每个用户可指定哪些用户允许查看自己应用程序的运行状态或者控制应用程序。此外，MRS集群管理员可指定队列管理员和集群系统管理员。 动态更新配置文件。MRS集群管理员可根据需要动态修改配置参数以实现在线集群管理。 Capacity Scheduler中每个队列可以限制资源使用量。队列间的资源分配以使用量作为排列依据，使得容量小的队列有竞争优势。集群整体吞吐较大，延迟调度机制使得应用可以有机会放弃跨机器或者跨机架的调度，争取本地调度。

HDFS HA方案背景 在Hadoop 2.0.0之前，HDFS集群中存在单点故障问题。由于每个集群只有一个NameNode，如果NameNode所在机器发生故障，将导致HDFS集群无法使用，除非NameNode重启或者在另一台机器上启动。这在两个方面影响了HDFS的整体可用性： 当异常情况发生时，如机器崩溃，集群将不可用，除非重新启动NameNode。 计划性的维护工作，如软硬件升级等，将导致集群停止工作。 针对以上问题，HDFS高可用性方案通过自动或手动（可配置）的方式，在一个集群中为NameNode启动一个热替换的NameNode备份。当一台机器故障时，可以迅速地自动进行NameNode主备切换。或者当主NameNode节点需要进行维护时，通过MRS集群管理员控制，可以手动进行NameNode主备切换，从而保证集群在维护期间的可用性。 有关HDFS自动故障转移功能，请参阅： MRS 3.2.0之前版本：http://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html#Automatic_Failover MRS 3.2.0及之后版本：https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html#Automatic_Failover

HDFS HA实现方案 图1 典型的HA部署方式 在一个典型的HA集群中（如图1），需要把两个NameNodes配置在两台独立的机器上。在任何一个时间点，只有一个NameNode处于Active状态，另一个处于Standby状态。Active节点负责处理所有客户端操作，Standby节点时刻保持与Active节点同步的状态以便在必要时进行快速主备切换。 为保持Active和Standby节点的数据一致性，两个节点都要与一组称为JournalNode的节点通信。当Active对文件系统元数据进行修改时，会将其修改日志保存到大多数的JournalNode节点中，例如有3个JournalNode，则日志会保存在至少2个节点中。Standby节点监控JournalNodes的变化，并同步来自Active节点的修改。根据修改日志，Standby节点将变动应用到本地文件系统元数据中。一旦发生故障转移，Standby节点能够确保与Active节点的状态是一致的。这保证了文件系统元数据在故障转移时在Active和Standby之间是完全同步的。 为保证故障转移快速进行，Standby需要时刻保持最新的块信息，为此DataNodes同时向两个NameNodes发送块信息和心跳。 对一个HA集群，保证任何时刻只有一个NameNode是Active状态至关重要。否则，命名空间会分为两部分，有数据丢失和产生其他错误的风险。为保证这个属性，防止“split-brain”问题的产生，JournalNodes在任何时刻都只允许一个NameNode写入。在故障转移时，将变为Active状态的NameNode获得写入JournalNodes的权限，这会有效防止其他NameNode的Active状态，使得切换安全进行。 关于HDFS高可用性方案的更多信息，可参考如下链接： MRS 3.2.0之前版本：http://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html MRS 3.2.0及之后版本：https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html