华为云用户手册

MRS 权限说明 默认情况下，管理员创建的 IAM 用户没有任何权限，需要将其加入用户组，并给用户组授予策略或角色，才能使得用户组中的用户获得对应的权限，这一过程称为授权。授权后，用户就可以基于被授予的权限对云服务进行操作。 MRS部署时通过物理区域划分，为项目级服务。授权时，“作用范围”需要选择“区域级项目”，然后在指定区域（如华北-北京1）对应的项目（cn-north-1）中设置相关权限，并且该权限仅对此项目生效；如果在“所有项目”中设置权限，则该权限在所有区域项目中都生效。访问MRS时，需要先切换至授权区域。 权限模型根据授权精细程度分为角色和策略。 角色：IAM最初提供的一种根据用户的工作职能定义权限的粗粒度授权机制。该机制以服务为粒度，提供有限的服务相关角色用于授权。由于各服务之间存在业务依赖关系，因此给用户授予角色时，可能需要一并授予依赖的其他角色，才能正确完成业务。角色并不能满足用户对精细化授权的要求，无法完全达到企业对权限最小化的安全管控要求。 策略：IAM最新提供的一种细粒度授权的能力，可以精确到具体服务的操作、资源以及请求条件等。基于策略的授权是一种更加灵活的授权方式，能够满足企业对权限最小化的安全管控要求。例如：针对MRS服务，管理员能够控制IAM用户仅能对集群进行指定的管理操作。如不允许某用户组删除集群，仅允许操作MRS集群基本操作，如创建集群、查询集群列表等。多数细粒度策略以API接口为粒度进行权限拆分，MRS支持的API授权项请参见权限策略和授权项。 如表1所示，包括了MRS的所有默认系统策略。 表1 MRS系统策略 策略名称 描述 策略类别 MRS FullAccess MRS管理员权限，拥有该权限的用户可以拥有MRS所有权限。 细粒度策略 MRS CommonOperations MRS服务普通用户权限，拥有该权限的用户可以拥有MRS服务使用权限，无新增、删除资源权限。 细粒度策略 MRS ReadOnlyAccess MRS服务只读权限，拥有该权限的用户仅能查看MRS的资源。 细粒度策略 MRS Administrator 操作权限： 对MRS服务的所有执行权限。 拥有该权限的用户必须同时拥有Tenant Guest和Server Administrator权限。 RBAC策略 表2列出了MRS常用操作与系统权限的授权关系，您可以参照该表选择合适的系统权限。 表2 常用操作与系统策略的授权关系 操作 MRS FullAccess MRS CommonOperations MRS ReadOnlyAccess MRS Administrator 创建集群 √ x x √ 调整集群 √ x x √ 升级节点规格 √ x x √ 删除集群 √ x x √ 查询集群详情 √ √ √ √ 查询集群列表 √ √ √ √ 设置弹性伸缩策略 √ x x √ 查询主机列表 √ √ √ √ 查询操作日志 √ √ √ √ 创建并执行作业 √ √ x √ 停止作业 √ √ x √ 删除单个作业 √ √ x √ 批量删除作业 √ √ x √ 查询作业详情 √ √ √ √ 查询作业列表 √ √ √ √ 新建文件夹 √ √ x √ 删除文件 √ √ x √ 查询文件列表 √ √ √ √ 批量操作集群标签 √ √ x √ 创建单个集群标签 √ √ x √ 删除单个集群标签 √ √ x √ 按照标签查询资源列表 √ √ √ √ 查询集群标签 √ √ √ √ 访问Manager页面 √ √ x √ 查询补丁列表 √ √ √ √ 安装补丁 √ √ x √ 卸载补丁 √ √ x √ 运维通道授权 √ √ x √ 运维通道日志共享 √ √ x √ 查询告警列表 √ √ √ √ 订阅告警消息提醒 √ √ x √ 提交SQL语句 √ √ x √ 查询SQL结果 √ √ x √ 取消SQL执行任务 √ √ x √

MRS FullAccess策略内容 { "Version": "1.1", "Statement": [ { "Action": [ "mrs:*:*", "ecs:*:*", "bms:*:*", "evs:*:*", "vpc:*:*", "kms:*:*", "rds:*:*", "bss:*:*" ], "Effect": "Allow" } ]}

MRS ReadOnlyAccess策略内容 { "Version": "1.1", "Statement": [ { "Action": [ "mrs:*:get*", "mrs:*:list*", "mrs:tag:count", "ecs:*:get*", "ecs:*:list*", "bms:*:get*", "bms:*:list*", "evs:*:get*", "evs:*:list*", "vpc:*:get*", "vpc:*:list*", "kms:*:get*", "kms:*:list*", "rds:*:get*", "rds:*:list*", "bss:*:view*" ], "Effect": "Allow" }, { "Action": [ "mrs:cluster:create", "mrs:cluster:resize", "mrs:cluster:scaleUp", "mrs:cluster:delete", "mrs:cluster:policy", "mrs:job:submit", "mrs:job:stop", "mrs:job:delete", "mrs:job:batchDelete", "mrs:file:create", "mrs:file:delete", "mrs:tag:batchOperate", "mrs:tag:create", "mrs:tag:delete", "mrs:manager:access", "mrs:patch:install", "mrs:patch:uninstall", "mrs:ops:grant", "mrs:ops:shareLog", "mrs:alarm:subscribe" ], "Effect": "Deny" } ]}

访问控制 MRS提供两种访问控制权限模型：基于角色的权限控制和基于策略的权限控制，详情请参见权限模型。 基于角色的权限控制 MRS基于用户和角色的认证统一体系，遵从账户/角色RBAC（Role-Based Access Control）模型，实现通过角色进行权限管理，对用户进行批量授权管理，同时提供单点登录能力，统一了系统用户和组件用户的管理及认证。具体机制详情描述请参见权限机制。 基于策略的权限控制 Ranger鉴权 MRS提供了基于Ranger的鉴权方案，对于MRS安全集群，默认启用了Ranger鉴权；对于安装了Ranger服务的普通集群，Ranger可以支持基于OS用户进行组件资源的权限控制。 Ranger鉴权的具体策略请参见鉴权策略。 OBS存算分离细粒度鉴权 对于OBS存算分离集群，如果您想对OBS上的资源进行细粒度的权限控制，可以通过MRS提供的基于IAM委托的细粒度权限控制方案进行配置，请参见配置MRS多用户访问OBS细粒度权限。

实时数据处理 实时数据处理通常用于异常检测、欺诈识别、基于规则告警、业务流程监控等场景，在数据输入系统的过程中，对数据进行处理。 例如在梯联网行业，智能电梯的数据，实时传入到MRS的流式集群中进行实时告警。 图3 梯联网行业低时延流式处理场景 该场景下MRS的优势如下所示。 实时数据采集：利用Flume实现实时数据采集，并提供丰富的采集和存储连接方式。 海量的数据源接入：利用Kafka实现万级别的电梯数据的实时接入。

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开源增强特性：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的规则的数据，设置存储策略和迁移数据。以这种方式，提高了数据管理效率和集群资源效率。

海量数据存储场景 用户拥有大量结构化数据后，通常需要提供基于索引的准实时查询能力，如车联网场景下，根据汽车编号查询汽车维护信息，存储时，汽车信息会基于汽车编号进行索引，以实现该场景下的秒级响应。通常这类数据量比较庞大，用户可能保存1至3年的数据。 例如在车联网行业，某车企将数据储存在HBase中，以支持PB级别的数据存储和毫秒级的数据详单查询。 图2 车联网行业海量数据存储场景 该场景下MRS的优势如下所示。 实时：利用Kafka实现海量汽车的消息实时接入。 海量数据存储：利用HBase实现海量数据存储，并实现毫秒级数据查询。 分布式数据查询：利用Spark实现海量数据的分析查询。

HDFS开源增强特性：基于标签的数据块摆放策略（HDFS Nodelabel） 用户需要通过数据特征灵活配置HDFS文件数据块的存储节点。通过设置HDFS目录/文件对应一个标签表达式，同时设置每个DataNode对应一个或多个标签，从而给文件的数据块存储指定了特定范围的DataNode。当使用基于标签的数据块摆放策略，为指定的文件选择DataNode节点进行存放时，会根据文件的标签表达式选择出将要存放的Datanode节点范围，然后在这些Datanode节点范围内，选择出合适的存放节点。 支持用户将数据块的各个副本存放在指定具有不同标签的节点，如某个文件的数据块的2个副本放置在标签L1对应节点中，该数据块的其他副本放置在标签L2对应的节点中。 支持选择节点失败情况下的策略，如随机从全部节点中选一个。 如图7所示。 /HBase下的数据存储在A，B，D /Spark下的数据存储在A，B，D，E，F /user下的数据存储在C，D，F /user/shl下的数据存储在A，E，F 图7 基于标签的数据块摆放策略样例

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负载的节点顺序调整至后面。

海量数据分析场景 海量数据分析是现代大数据系统中的主要场景。通常企业会包含多种数据源，接入后需要对数据进行ETL（Extract-Transform-Load）处理形成模型化数据，以便提供给各个业务模块进行分析梳理，这类业务通常有以下特点： 对执行实时性要求不高，作业执行时间在数十分钟到小时级别。 数据量巨大。 数据来源和格式多种多样。 数据处理通常由多个任务构成，对资源需要进行详细规划。 例如在环保行业中，可以将天气数据存储在OBS，定期转储到HDFS中进行批量分析，在1小时内MRS可以完成10TB的天气数据分析。 图1 环保行业海量数据分析场景 该场景下MRS的优势如下所示。 低成本：利用OBS实现低成本存储。 海量数据分析：利用Hive实现TB/PB级的数据分析。 可视化的导入导出工具：通过可视化导入导出工具Loader，将数据导出到DWS，完成BI分析。

Spark和YARN的关系 Spark的计算调度方式，可以通过YARN的模式实现。Spark共享YARN集群提供丰富的计算资源，将任务分布式的运行起来。Spark on YARN分两种模式：YARN Cluster和YARN Client。 YARN Cluster模式 运行框架如图 Spark on yarn-cluster运行框架所示。 图3 Spark on yarn-cluster运行框架 Spark on yarn-cluster实现流程： 首先由客户端生成Application信息，提交给ResourceManager。 ResourceManager为Spark Application分配第一个Container(ApplicationMaster)，并在该Container上启动Driver。 ApplicationMaster向ResourceManager申请资源以运行Container。 ResourceManager分配Container给ApplicationMaster，ApplicationMaster和相关的NodeManager通讯，在获得的Container上启动Executor，Executor启动后，开始向Driver注册并申请Task。 Driver分配Task给Executor执行。 Executor执行Task并向Driver汇报运行状况。 YARN Client模式 运行框架如图 Spark on yarn-client运行框架所示。 图4 Spark on yarn-client运行框架 Spark on yarn-client实现流程： 在yarn-client模式下，Driver部署在Client端，在Client端启动。yarn-client模式下，不兼容老版本的客户端。推荐使用yarn-cluster模式。 客户端向ResourceManager发送Spark应用提交请求，ResourceManager为其返回应答，该应答中包含多种信息(如ApplicationId、可用资源使用上限和下限等)。Client端将启动ApplicationMaster所需的所有信息打包，提交给ResourceManager上。 ResourceManager收到请求后，会为ApplicationMaster寻找合适的节点，并在该节点上启动它。ApplicationMaster是Yarn中的角色，在Spark中进程名字是ExecutorLauncher。 根据每个任务的资源需求，ApplicationMaster可向ResourceManager申请一系列用于运行任务的Container。 当ApplicationMaster（从ResourceManager端）收到新分配的Container列表后，会向对应的NodeManager发送信息以启动Container。 ResourceManager分配Container给ApplicationMaster，ApplicationMaster和相关的NodeManager通讯，在获得的Container上启动Executor，Executor启动后，开始向Driver注册并申请Task。 正在运行的container不会被挂起释放资源。 Driver分配Task给Executor执行。Executor执行Task并向Driver汇报运行状况。

Spark和HDFS的关系 通常，Spark中计算的数据可以来自多个数据源，如Local File、HDFS等。最常用的是HDFS，用户可以一次读取大规模的数据进行并行计算。在计算完成后，也可以将数据存储到HDFS。 分解来看，Spark分成控制端(Driver)和执行端（Executor）。控制端负责任务调度，执行端负责任务执行。 读取文件的过程如图 读取文件过程所示。 图1 读取文件过程 读取文件步骤的详细描述如下所示： Driver与HDFS交互获取File A的文件信息。 HDFS返回该文件具体的Block信息。 Driver根据具体的Block数据量，决定一个并行度，创建多个Task去读取这些文件Block。 在Executor端执行Task并读取具体的Block，作为RDD(弹性分布数据集)的一部分。 写入文件的过程如图 写入文件过程所示。 图2 写入文件过程 HDFS文件写入的详细步骤如下所示： Driver创建要写入文件的目录。 根据RDD分区分块情况，计算出写数据的Task数，并下发这些任务到Executor。 Executor执行这些Task，将具体RDD的数据写入到步骤1创建的目录下。

SQL查询语法 通过MATCH_RECOGNIZE的SQL语法实现。MATCH_RECOGNIZE子句自Oracle Database 12c起由Oracle SQL支持，用于在SQL中表示事件模式匹配。Apache Calcite同样支持MATCH_RECOGNIZE子句。 由于Flink通过Calcite分析SQL查询结果，本操作遵循Apache Calcite语法。 MATCH_RECOGNIZE ( [ PARTITION BY expression [, expression ]* ] [ ORDER BY orderItem [, orderItem ]* ] [ MEASURES measureColumn [, measureColumn ]* ] [ ONE ROW PER MATCH | ALL ROWS PER MATCH ] [ AFTER MATCH ( SKIP TO NEXT ROW | SKIP PAST LAST ROW | SKIP TO FIRST variable | SKIP TO LAST variable | SKIP TO variable ) ] PATTERN ( pattern ) [ WITHIN intervalLiteral ] [ SUBSET subsetItem [, subsetItem ]* ] DEFINE variable AS condition [, variable AS condition ]* ) MATCH_RECOGNIZE子句的语法元素定义如下： -PARTITION BY [可选]：定义分区列。该子句为可选子句。如果未定义，则使用并行度1。 -ORDER BY [可选]：定义数据流中事件的顺序。ORDER BY子句为可选子句，如果忽略则使用非确定性排序。由于事件顺序在模式匹配中很重要，因此大多数情况下应指定该子句。 -MEASURES [可选]：指定匹配成功的事件的属性值。 -ONE ROW PER MATCH | ALL ROWS PER MATCH [可选]：定义如何输出结果。ONE ROW PER MATCH表示每次匹配只输出一行，ALL ROWS PER MATCH表示每次匹配的每一个事件输出一行。 -AFTER MATCH [可选]：指定从何处开始对下一个模式匹配进行匹配成功后的处理。 -PATTERN： 将匹配模式定义为正则表达式格式。PATTERN子句中可使用以下运算符： 连接运算符，量词运算符(*，+，?，{n}，{n,}, {n,m}, {,m}),分支运算符（使用竖线‘|’），以及异运算符（‘{- -}’）。 -WITHIN [可选]：当且仅当匹配发生在指定时间内，则输出模式子句匹配。 -SUBSET [可选]：将DEFINE子句中定义的一个或多个关联变量组合在一起。 -DEFINE：指定boolean条件，该条件定义了PATTERN子句中使用的变量。 此外，还支持以下函数： -MATCH_NUMBER()：可用于MEASURES子句中，为同一成功匹配的每一行分配相同编号。 -CLASSIFIER()：可用于MEASURES子句中，以指示匹配的行与变量之间的映射关系。 -FIRST()和LAST()：可用于MEASURES子句中，返回在映射到模式变量的行集的第一行或最后一行中评估的表达式的值。 -NEXT()和PREV()：可用于DEFINE子句中，通过分区中的前一行或下一行来评估表达式。 -RUNNING和FINAL关键字：可用于确定聚合的所需语义。RUNNING可用于MEASURES和DEFINE子句中，而FINAL只能用于MEASURES子句中。 -聚合函数(COUNT，SUM，AVG，MAX，MIN)：这些聚合函数可用于MEASURES子句和DEFINE子句中。

升级Master节点规格 MRS大数据集群采用Manager实现集群的管理，而管理集群的相关服务，如HDFS存储系统的NameNode，Yarn资源管理的ResourceManager，以及MRS的Manager管理服务都部署在集群的Master节点上。 随着新业务的上线，集群规模不断扩大，Master节点承担的管理负荷也越来越高，企业用户面临CPU负载过高，内存使用率超过阈值的问题。通常自建大数据集群需要完成数据搬迁，采购升级节点硬件配置实现Master规格提升，而MRS服务借助云服务的优势，实现一键式Master节点升级，并在升级过程中通过Master节点的主备HA保证已有业务的不间断，方便快捷帮助用户解决主节点规格升级问题。 Master节点具体升级操作请参见升级Master节点规格。 父主题： 集群管理

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相关信息，恢复数据。

Manager结构 Manager的整体逻辑架构如图1所示。 图1 Manager逻辑架构 Manager由 OMS 和OMA组成： OMS：操作维护系统的管理节点，OMS一般有两个，互为主备。 OMA：操作维护系统中的被管理节点，一般有多个。 图1中各模块的说明如表1所示： 表1 业务模块说明 模块名称 描述 Web Service 是一个部署在Tomcat下的Web服务，提供Manager的https接口，用于通过浏览器访问Manager。同时还提供基于Syslog和SNMP协议的北向接入能力。 OMS 操作维护系统的管理节点，OMS节点一般有两个，互为主备。 OMA 操作维护系统中的被管理节点，一般有多个。 Controller Controller是Manager的控制中心，负责汇聚来自集群中所有节点的信息，统一向MRS集群管理员展示，以及负责接收来自MRS集群管理员的操作指令，并且依据操作指令所影响的范围，向集群的所有相关节点同步信息。 Manager的控制进程，负责各种管理动作的执行： Web Service将各种管理动作（安装、启停服务、修改配置等）下发到Controller。 Controller将命令分解，分解后将动作下发到每一个Node Agent。例如启动一个服务，会涉及多个角色和实例。 Controller负责监控每一个动作的执行情况。 Node Agent Node Agent存在于每一个集群节点，是Manager在单个节点的使能器。 Node Agent代表本节点上部署的所有组件与Controller交互，实现整个集群多点到单点的汇聚。 Node Agent是Controller对部署在该节点上组件做一切操作的使能器，其代表着Controller的功能。 Node Agent每隔3秒向Controller发送心跳信息，不支持配置时间间隔。 IAM 负责记录审计日志。在Manager的UI上每一个非查询类操作，都有对应的审计日志。 PMS 性能监控模块，搜集每一个OMA上的性能监控数据并提供查询。 CEP 汇聚功能模块。比如将所有OMA上的磁盘已用空间汇总成一个性能指标。 FMS 告警模块，收集每一个OMA上的告警并提供查询。 OMM Agent OMA上面性能监控和告警的Agent，负责收集该Agent Node上的性能监控数据和告警数据。 CAS 统一认证中心，登录Web Service时需要在CAS进行登录认证，浏览器通过URL自动跳转访问CAS。 AOS 权限管理模块，管理用户和用户组的权限。 A CS 用户和用户组管理模块，管理用户及用户归属的用户组。 Kerberos 在OMS与集群中各部署一个。 OMS Kerberos提供单点登录及Controller与Node Agent间认证的功能。 集群中Kerberos提供组件用户安全认证功能，其服务名称为KrbServer，包含两种角色实例： KerberosServer：认证服务器，为MRS提供安全认证使用。 KerberosAdmin：管理Kerberos用户的进程。 Ldap 在OMS与集群中各部署一个。 OMS Ldap为用户认证提供数据存储。 集群中的Ldap作为OMS Ldap的备份，其服务名称为LdapServer，角色实例为SlapdServer。 Database Manager的数据库，负责存储日志、告警等信息。 HA 高可用性管理模块，主备OMS通过HA进行主备管理。 NTP Server NTP Client 负责同步集群内各节点的系统时钟。

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和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会进行主备切换。

实现方案 多租户模式的HA方案原理如图1所示。 图1 Spark JD BCS erver多租户 ProxyServer在启动时，向ZooKeeper注册自身消息，在指定目录中写入节点信息，节点信息包含了该实例对应的IP，端口，版本号和序列号等信息（多节点信息之间以逗号隔开）。 多租户模式下，MRS页面上的JDBCServer实例是指ProxyServer（JDBCServer代理）。 示例如下： serverUri=192.168.169.84:22550;version=8.1.0.1;sequence=0000001244,serverUri=192.168.195.232:22550;version=8.1.0.1;sequence=0000001242,serverUri=192.168.81.37:22550;version=8.1.0.1;sequence=0000001243, 客户端连接ProxyServer时，需要指定Namespace，即访问ZooKeeper哪个目录下的ProxyServer实例。在连接的时候，会根据当前租户名的Hash值与Zookeeper下的Namespace实例个数取模获取连接的实例，详细URL参见URL连接介绍。 客户端成功连接ProxyServer服务，ProxyServer服务首先确认是否有该租户的JDBCServer存在，如果有，直接将Beeline连上真正的JDBCServer；如果没有，则以YARN-Cluster模式启动一个新的JDBCServer。JDBCServer启动成功后，ProxyServer会获取JDBCServer的地址，并将Beeline连上JDBCServer。 客户端发送SQL语句给ProxyServer，ProxyServer将语句转交给真正连上的JDBCServer处理。最后JDBCServer服务将结果返回给ProxyServer，ProxyServer再将结果返回给客户端。 在HA方案中，每个ProxyServer服务（即实例）都是独立且等同的，当其中一个实例在升级或者业务中断时，其他的实例也能接受客户端的连接请求。

Hue开源增强特性 存储策略定义。HDFS文件存储在多种等级的存储介质中，有不同的副本数。本特性可以手工设置HDFS目录的存储策略，或者根据HDSF文件最近访问时间和最近修改时间，自动调整文件存储策略、修改文件副本数、移动文件所在目录、自动删除文件，以便充分利用存储的性能和容量。 MR引擎。用户执行Hive SQL可以选择使用MR引擎执行。 可靠性增强。Hue自身主备部署。Hue与HDFS、Oozie、Hive、Yarn等对接时，支持Failover或负载均衡工作模式。

背景介绍 JDBCServer多主实例方案中，JDBCServer的实现使用YARN-Client模式，但YARN资源队列只有一个，为了解决这种资源局限的问题，引入了多租户模式。 多租户模式是将JDBCServer和租户绑定，每一个租户对应一个或多个JDBCServer，而一个JDBCServer只给一个租户提供服务。不同的租户可以配置不同的YARN队列，从而达到资源隔离，且JDBCServer根据需求动态启动，可避免浪费资源。

责任共担 华为云秉承“将公司对网络和业务安全性保障的责任置于公司的商业利益之上”。针对层出不穷的 云安全 挑战和无孔不入的云安全威胁与攻击，华为云在遵从法律法规业界标准的基础上，以安全生态圈为护城河，依托华为独有的软硬件优势，构建面向不同区域和行业的完善云服务安全保障体系。 安全性是华为云与您的共同责任，如图1所示。 华为云：负责云服务自身的安全，提供安全的云。华为云的安全责任在于保障其所提供的IaaS、PaaS和SaaS各类各项云服务自身的安全，涵盖华为云数据中心的物理环境设施和运行其上的基础服务、平台服务、应用服务等。这不仅包括华为云基础设施和各项云服务技术的安全功能和性能本身，也包括运维运营安全，以及更广义的安全合规遵从。 租户：负责云服务内部的安全，安全地使用云。华为云租户的安全责任在于对使用的IaaS、PaaS和SaaS类各项云服务内部的安全以及对租户定制配置进行安全有效的管理，包括但不限于虚拟网络、 虚拟主机 和访客虚拟机的操作系统，虚拟防火墙、API网关和高级安全服务，各项云服务，租户数据，以及身份账号和密钥管理等方面的安全配置。 《华为云安全白皮书》详细介绍华为云安全性的构建思路与措施，包括云安全战略、责任共担模型、合规与隐私、安全组织与人员、基础设施安全、租户服务与租户安全、工程安全、运维运营安全、生态安全。 图1 华为云安全责任共担模型 父主题： 安全

Loader开源增强特性：数据导入导出 Loader是在开源Sqoop组件的基础上进行了一些扩展，除了包含Sqoop开源组件本身已有的功能外，还开发了如下的增强特性： 提供数据转化功能 支持图形化配置转换步骤 支持从SFTP/FTP服务器导入数据到HDFS/OBS 支持从SFTP/FTP服务器导入数据到HBase表 支持从SFTP/FTP服务器导入数据到Phoenix表 支持从SFTP/FTP服务器导入数据到Hive表 支持从HDFS/OBS导出数据到SFTP服务器 支持从HBase表导出数据到SFTP服务器 支持从Phoenix表导出数据到SFTP服务器 支持从关系型数据库导入数据到HBase表 支持从关系型数据库导入数据到Phoenix表 支持从关系型数据库导入数据到Hive表 支持从HBase表导出数据到关系型数据库 支持从Phoenix表导出数据到关系型数据库 支持从Oracle分区表导入数据到HDFS/OBS 支持从Oracle分区表导入数据到HBase表 支持从Oracle分区表导入数据到Phoenix表 支持从Oracle分区表导入数据到Hive表 支持从HDFS/OBS导出数据到Oracle分区表 支持从HBase导出数据到Oracle分区表 支持从Phoenix表导出数据到Oracle分区表 在同一个集群内，支持从HDFS导数据到HBase、Phoenix表和Hive表 在同一个集群内，支持从HBase和Phoenix表导数据到HDFS/OBS 导入数据到HBase和Phoenix表时支持使用bulkload和put list两种方式 支持从SFTP/FTP导入所有类型的文件到HDFS，开源只支持导入文本文件 支持从HDFS/OBS导出所有类型的文件到SFTP，开源只支持导出文本文件和sequence格式文件 导入（导出）文件时，支持对文件进行转换编码格式，支持的编码格式为jdk支持的所有格式 导入（导出）文件时，支持保持原来文件的目录结构和文件名不变 导入（导出）文件时，支持对文件进行合并，如输入文件为海量个文件，可以合并为n个文件（n值可配） 导入（导出）文件时，可以对文件进行过滤，过滤规则同时支持通配符和正则表达式 支持批量导入/导出ETL任务 支持ETL任务分页查询、关键字查询和分组管理 对外部组件提供浮动IP

Loader与其他组件的关系 与Loader有交互关系的组件有HDFS、HBase、Hive、Yarn、Mapreduce和ZooKeeper等。 Loader作为客户端使用这些组件的某些功能，如存储数据到HDFS和HBase，从HDFS和HBase表读数据，同时Loader本身也是一个Mapreduce客户端程序，完成一些数据导入导出任务。 Loader通过MapReduce作业实现并行的导入或者导出作业任务，不同类型的导入导出作业可能只包含Map阶段或者同时Map和Reduce阶段。 父主题： Loader

Flume开源增强特性 提升传输速度。可以配置将指定的行数作为一个Event，而不仅是一行，提高了代码的执行效率以及减少写入磁盘的次数。 传输超大二进制文件。Flume根据当前内存情况，自动调整传输超大二进制文件的内存占用情况，不会导致Out of Memory（OOM）的出现。 支持定制传输前后准备工作。Flume支持定制脚本，指定在传输前或者传输后执行指定的脚本，用于执行准备工作。 管理客户端告警。Flume通过MonitorServer接收Flume客户端告警，并上报Manager告警管理中心。

Flink HA方案介绍 每个Flink集群只有单个JobManager，存在单点失败的情况。Flink有Yarn、Standalone和Local三种模式，其中Yarn和Standalone是集群模式，Local是指单机模式。但Flink对于Yarn模式和Standalone模式提供HA机制，使集群能够从失败中恢复。这里主要介绍Yarn模式下的HA方案。 Flink支持HA模式和Job的异常恢复。这两项功能高度依赖ZooKeeper，在使用之前用户需要在“flink-conf.yaml”配置文件中配置ZooKeeper，配置ZooKeeper的参数如下： high-availability: zookeeperhigh-availability.zookeeper.quorum: ZooKeeperIP地址:2181high-availability.storageDir: hdfs:///flink/recovery Yarn模式 Flink的JobManager与Yarn的Application Master（简称AM）是在同一个进程下。Yarn的ResourceManager对AM有监控，当AM异常时，Yarn会将AM重新启动，启动后，所有JobManager的元数据从HDFS恢复。但恢复期间，旧的业务不能运行，新的业务不能提交。ZooKeeper上还是存有JobManager的元数据，比如运行Job的信息，会提供给新的JobManager使用。对于TaskManager的失败，由JobManager上Akka的DeathWatch机制处理。当TaskManager失败后，重新向Yarn申请容器，创建TaskManager。 Yarn模式的HA方案的更多信息，可参考链接： http://hadoop.apache.org/docs/r3.1.1/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html Standalone模式 对于Standalone模式的集群，可以启动多个JobManager，然后通过ZooKeeper选举出Leader作为实际使用的JobManager。该模式下可以配置一个主JobManager（Leader JobManager）和多个备JobManager（Standby JobManager），这能够保证当主JobManager失败后，备的某个JobManager可以承担主的职责。图1为主备JobManager的恢复过程。 图1 恢复过程 TaskManager恢复 对于TaskManager的失败，由JobManager上Akka的DeathWatch机制处理。当TaskManager失败后，由JobManager负责创建一个新TaskManager，并把业务迁移到新的TaskManager上。 JobManager恢复 Flink的JobManager与Yarn的Application Master（简称AM）是在同一个进程下。Yarn的ResourceManager对AM有监控，当AM异常时，Yarn会将AM重新启动，启动后，所有JobManager的元数据从HDFS恢复。但恢复期间，旧的业务不能运行，新的业务不能提交。 Job恢复 Job的恢复必须在Flink的配置文件中配置重启策略。当前包含三种重启策略：fixed-delay、failure-rate和none。只有配置fixed-delay、failure-rate，Job才可以恢复。另外，如果配置了重启策略为none，但Job设置了Checkpoint，默认会将重启策略改为fixed-delay，且重试次数是配置项“restart-strategy.fixed-delay.attempts”的值。 三种策略的具体信息请参考Flink官网：https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/task_failure_recovery.html。配置策略的参考如下： restart-strategy: fixed-delayrestart-strategy.fixed-delay.attempts: 3restart-strategy.fixed-delay.delay: 10 s 以下场景的异常，都会导致Job重新恢复： 当JobManager失败后，所有Job会停止，直到新的JobManager运行后，所有Job恢复。 当某一TaskManager失败后，这个TaskManager上的所有作业都将停止，然后等待有可用资源后重启。 当某个Job的Task失败后，整个Job也会重启。 有关Job的配置重启策略，具体内容请参见https://ci.apache.org/projects/flink/flink-docs-release-1.12/ops/jobmanager_high_availability.html。