华为云用户手册

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

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

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

实现方案 多租户模式的HA方案原理如图1所示。 图1 Spark JDBCServer多租户 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服务（即实例）都是独立且等同的，当其中一个实例在升级或者业务中断时，其他的实例也能接受客户端的连接请求。

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告警管理中心。

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

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。

OpenTSDB OpenTSDB是一个基于HBase的分布式、可伸缩的时间序列数据库。OpenTSDB的设计目标是用来采集大规模集群中的监控类信息，并可实现数据的秒级查询，解决海量监控类数据在普通数据库中查询存储的局限性。 OpenTSDB由时间序列守护进程（TSD）和一组命令行实用程序组成。与OpenTSDB的交互主要通过运行一个或多个TSD来实现。每个TSD都是独立的。没有主服务器，没有共享状态，因此您可以根据需要运行任意数量的TSD来处理您向其投入的任何负载。每个TSD使用CloudTable集群中的HBase来存储和检索时间序列数据。数据模式经过高度优化，可快速聚合相似的时间序列，从而最大限度地减少存储空间。TSD的用户不需要直接访问底层存储。您可以通过HTTP API与TSD进行通信。所有通信都发生在同一个端口上（TSD通过查看它收到的前几个字节来确定客户端的协议）。 图1 OpenTSDB架构 OpenTSDB使用场景有如下几个特点： 采集指标在某一时间点具有唯一值，没有复杂的结构及关系。 监控的指标具有随着时间不断变化的特点。 具有HBase的高吞吐，良好的伸缩性等特点。 OpenTSDB提供基于HTTP的应用程序编程接口，以实现与外部系统的集成。 几乎所有OpenTSDB功能都可通过API访问，例如查询时间序列数据，管理元数据和存储数据点。详情请参见：https://opentsdb.net/docs/build/html/api_http/index.html。 父主题： 组件介绍

MapReduce和HDFS的关系 HDFS是Hadoop分布式文件系统，具有高容错和高吞吐量的特性，可以部署在价格低廉的硬件上，存储应用程序的数据，适合有超大数据集的应用程序。 MapReduce是一种编程模型，用于大数据集（大于1TB）的并行运算。在MapReduce程序中计算的数据可以来自多个数据源，如Local FileSystem、HDFS、数据库等。最常用的是HDFS，利用HDFS的高吞吐性能读取大规模的数据进行计算，同时在计算完成后，也可以将数据存储到HDFS。

Ranger与其他组件的关系 Ranger为组件提供基于PBAC的鉴权插件，供组件服务端运行，目前支持Ranger鉴权的组件有HDFS、Yarn、Hive、HBase、Kafka、Storm和Spark等，后续会支持更多组件。 Ranger为各组件提供了基于PBAC（Policy-Based Access Control）的权限管理插件，用于替换组件自身原来的鉴权插件。Ranger插件都是由组件侧自身的鉴权接口扩展而来，用户在Ranger WebUI上对指定service设置权限策略，Ranger插件会定期从RangerAdmin处更新策略并缓存在组件本地文件，当有客户端请求需要进行鉴权时，Ranger插件会对请求中携带的用户在策略中进行匹配，随后返回接受或拒绝。 组件每次启动都会检查组件默认的Ranger Service是否存在，如果不存在则会创建以及为其添加默认Policy。如果用户在使用过程中误删了Service，可以重启或者滚动重启相应组件服务来恢复，如果是误删了默认Policy，可先手动删除Service，再重启组件服务。 图1 Ranger与组件的关系 父主题： Ranger

节点可靠性 操作系统健康状态监控 周期采集操作系统硬件资源使用率数据，包括CPU、内存、硬盘、网络等资源的使用率状态。 进程健康状态监控 MRS提供业务实例的状态以及业务实例进程的健康指标的检查，能够让用户第一时间感知进程健康状态。 硬盘故障的自动处理 MRS对开源版本进行了增强，可以监控各节点上的硬盘以及文件系统状态。如果出现异常，立即将相关分区移出存储池；如果硬盘恢复正常（通常是因为用户更换了新硬盘），也会将新硬盘重新加入业务运作。这样极大简化了维护人员的工作，更换故障硬盘可以在线完成；同时用户可以设置热备盘，从而极大缩减了故障硬盘的修复时间，有利于提高系统的可靠性。 节点磁盘LVM配置 MRS支持将多个磁盘配置成LVM（Logic Volume Management），多个磁盘规划成一个逻辑卷组。配置成LVM可以避免各磁盘间使用不均的问题，保持各个磁盘间均匀使用在HDFS和Kafka等能够利用多磁盘能力的组件上尤其重要。并且LVM可以支持磁盘扩容时不需要重新挂载，避免了业务中断。

系统可靠性 管理节点均实现HA Hadoop开源版本的数据、计算节点已经是按照分布式系统进行设计的，单节点故障不影响系统整体运行；而以集中模式运作的管理节点可能出现的单点故障，就成为整个系统可靠性的短板。 MRS对所有业务组件的管理节点都提供了类似的双机的机制，包括Manager、HDFS NameNode、HiveServer、HBase HMaster、YARN ResourceManager、KerberosServer、LdapServer等，全部采用主备或负荷分担配置，有效避免了单点故障场景对系统可靠性的影响。 异常场景下的可靠性保证 通过可靠性分析方法，梳理软件、硬件异常场景下的处理措施，提升系统的可靠性。 保障意外掉电时的数据可靠性，不论是单节点意外掉电，还是整个集群意外断电，恢复供电后系统能够正常恢复业务，除非硬盘介质损坏，否则关键数据不会丢失。 硬盘亚健康检测和故障处理，对业务不造成实际影响。 自动处理文件系统的故障，自动恢复受影响的业务。 自动处理进程和节点的故障，自动恢复受影响的业务。 自动处理网络故障，自动恢复受影响的业务。 数据备份与恢复 为应对数据丢失或损坏对用户业务造成不利影响，在异常情况下快速恢复系统，MRS根据用户业务的需要提供全量备份、增量备份和恢复功能。 自动备份 MRS对集群管理系统Manager上的数据提供自动备份功能，根据制定的备份策略可自动备份集群上的数据，包括LdapServer、DBService的数据。 手动备份 在系统进行扩容、打补丁等重大操作前，需要通过手动备份集群管理系统的数据，以便在系统故障时，恢复集群管理系统功能。 为进一步提供系统的可靠性，在将Manager、HBase上的数据备份到第三方服务器时，也需要通过手动备份。

MapReduce和YARN的关系 MapReduce是运行在YARN之上的一个批处理计算框架。MRv1是Hadoop 1.0中的MapReduce实现，它由编程模型（新旧编程接口）、运行时环境（由JobTracker和TaskTracker组成）和数据处理引擎（MapTask和ReduceTask）三部分组成。该框架在扩展性、容错性（JobTracker单点）和多框架支持（仅支持MapReduce一种计算框架）等方面存在不足。MRv2是Hadoop 2.0中的MapReduce实现，它在源码级重用了MRv1的编程模型和数据处理引擎实现，但运行时环境由YARN的ResourceManager和ApplicationMaster组成。其中ResourceManager是一个全新的资源管理系统，而ApplicationMaster则负责MapReduce作业的数据切分、任务划分、资源申请和任务调度与容错等工作。

HBase开源增强特性：Batch TRSP HBase 2.x内核版本使用HBase Procedure框架重写了region assignment的逻辑（AMV2）。每个Region的open或者close都会有一个TransitRegionStateProcedure(TRSP)与之关联。当RegionServer因为故障或重启需要恢复业务时，HMaster会为每个需要恢复的Region创建一个TRSP，大量的TRSP需要把数据持久化到Proc WAL文件中并且需要跟RegionServer进行RPC交互，可能造成HMaster性能瓶颈，导致服务恢复时间过长。 本功能主要通过在TRSP中添加attach region的方式，利用一个TRSP将一个RegionServer所有的Region进行恢复处理，RegionServer也将进行Region的批量open/close并一次性全部上报给HMaster。 该特性只支持将Region恢复到原来的RegionServer，因此该优化生效的前提为HMaster在创建TRSP时，故障或重启的RegionServer已经重新上线。因此，该特性主要用于优化HBase重启或者服务故障恢复的时长，如果是少量RegionServer发生故障，可能因为HMaster在RegionServer重新上线前已经创建了TRSP而不生效。 该内容适用于MRS 3.2.0及之后版本。

HBase开源增强特性：HBase热点自愈 该功能适用于MRS 3.3.0及之后版本。 HBase是一个分布式的KV数据库，Region是HBase数据管理的最小单元。如果用户在规划表和设计rowkey不合理，请求过于集中在少量固定Region时，会导致业务压力集中在单节点，造成业务侧可感知的性能下降甚至请求失败。 HBase服务增加了MetricController实例，开启热点检测能力，能够监控每个RegionServer节点的请求流量，通过聚合分析，识别出请求偏高的节点和Region，有助于快速发现热点问题；并提供一定的热点问题自愈能力，比如热点Region自动转移或Split。对于无法提供自愈的热点场景（单rowkey热点、顺序写热点等），提供了热点限流的能力，避免单点问题影响同节点的其他正常业务。

HBase开源增强特性：使用HAR文件格式拆分WAL文件 该内容适用于MRS 3.2.0及之后版本。 当RegionServer发生故障或重启时，HMaster会使用ServerCrashProcedure对RegionServer的业务进行恢复，恢复过程中包括拆分WAL文件。在WAL文件拆分过程中，会产生大量的小文件，可能造成HDFS的性能瓶颈，导致服务恢复时间过长。 本功能主要在拆分过程中将原本的小文件写入到HAR文件中，旨在减少拆分WAL过程中产生的小文件，从而缩短RegionServer恢复时长。

HBase开源增强特性：支持多点分割 当用户在HBase创建Region预先分割的表时，用户可能不知道数据的分布趋势，所以Region的分割可能不合适，所以当系统运行一段时间后，Region需要重新分割以获得更好的查询性能，HBase只会分割空的Region。 HBase自带的Region分割只有当Region到达设定的Threshold后才会进行分割，这种分割被称为单点分割。 为了实现根据用户的需要动态分割Region以获得更好的性能这一目标，开发了多点分割又称动态分割，即把空的Region预先分割成多个Region。通过预先分割，避免了因为Region空间不足出现Region分割导致性能下降的现象。 图2 多点分割

HBase开源增强特性：容灾增强 主备集群之间的容灾能力可以增强HBase数据的高可用性，主集群提供数据服务，备用集群提供数据备份，当主集群出现故障时，备集群可以提供数据服务。相比开源Replication功能，做了如下增强： 备集群白名单功能，只接受指定集群IP的数据推送。 开源版本中replication是基于WAL同步，在备集群回放WAL实现数据备份的。对于BulkLoad，由于没有WAL产生，BulkLoad的数据不会replicate到备集群。通过将BulkLoad操作记录在WAL上，同步至备集群，备集群通过WAL读取BulkLoad操作记录，将对应的主集群的HFile加载到备集群，完成数据的备份。 开源版本中HBase对于系统表ACL做了过滤，ACL信息不会同步至备集群，通过新加一个过滤器org.apache.hadoop.hbase.replication.SystemTableWALEntryFilterAllowACL，允许ACL信息同步至备集群，用户可以通过配置hbase.replication.filter.sytemWALEntryFilter使用该过滤器实现ACL同步。 备集群只读限制，备集群只接受备集群节点内的内置管理用户对备集群的HBase进行修改操作，即备集群节点之外的HBase客户端只能对备集群的HBase进行读操作。

HBase开源增强特性：Phoenix CsvBulkLoad工具导入支持用户自定义分隔符 该内容适用于MRS 3.2.0及之后版本。 Phoenix开源CsvBulkLoad工具当前仅支持指定单个字符作为数据分隔符，当用户数据文件中可能包含任意字符时，一般会采用特殊的字符串作为分隔符，为了满足此类场景，增加了对用户自定义分隔符的支持，用户可以采用限定长度内的任意可见字符进行组合作为分隔符来导入数据文件。

HBase开源增强特性：HBase双读 在HBase存储场景下，因为GC、网络抖动、磁盘坏道等原因，很难保证99.9%的查询稳定性。为了满足用户大数据量随机读低毛刺的要求，新增了HBase双读特性。 HBase双读特性是建立在主备集群容灾能力之上，两套集群同时产生毛刺的概率要远远小于一套集群，即采用双集群并发访问的方式，保证查询的稳定性。当用户发起查询请求时，同时查询两个集群的HBase服务，在等待一段时间（最大容忍的毛刺时间）后，如果主集群没有返回结果，则可以使用响应最快的集群数据。原理图如下：

HBase开源增强特性：HFS HBase文件存储模块（HBase FileStream，简称HFS）是HBase的独立模块，它作为对HBase与HDFS接口的封装，应用在MRS的上层应用，为上层应用提供文件的存储、读取、删除等功能。 在Hadoop生态系统中，无论是HDFS，还是HBase，均在面对海量文件的存储的时候，在某些场景下，都会存在一些很难解决的问题： 如果把海量小文件直接保存在HDFS中，会给NameNode带来极大的压力。 由于HBase接口以及内部机制的原因，一些较大的文件也不适合直接保存到HBase中。 HFS的出现，就是为了解决需要在Hadoop中存储海量小文件，同时也要存储一些大文件的混合的场景。简单来说，就是在HBase表中，需要存放大量的小文件（10MB以下），同时又需要存放一些比较大的文件（10MB以上）。 HFS为以上场景提供了统一的操作接口，这些操作接口与HBase的函数接口类似。

更新内容 服务模块 主要变更点 ClickHouse 升级到22.3.2.2版本。 ClickHouse支持多租户，通过CPU优先级和内存限额分配资源。 Flink 升级到1.15.0版本。 FlinkServer支持审计日志。 Hadoop 升级到3.3.1版本。 HetuEngine HetuEngine支持物化视图及自动刷新。 HetuEngine支持配置IoTDB数据源。 Hudi 升级到0.11.0版本。 IoTDB 新增组件，一体化收集、存储、管理与分析物联网时序数据的服务。 集群管理 支持补丁在线推送及更新。

组件版本信息 表1 MRS组件版本信息 组件 版本 CarbonData 2.2.0 ClickHouse 22.3.2.2 DBService 2.7.0 Flink 1.15.0 Flume 1.9.0 HBase 2.2.3 HDFS 3.3.1 HetuEngine 1.2.0 Hive 3.1.0 Hudi（集成在Spark2x中） 0.11.0 Hue 4.7.0 IoTDB 0.14.0 Kafka 2.11-2.4.0 KrbServer 1.18 LdapServer 2.7.0 Loader 1.99.3 Mapreduce 3.3.1 Oozie 5.1.0 Phoenix（集成在HBase中） 5.0.0 Ranger 2.0.0 Spark2x 3.1.1 Tez 0.9.2 Yarn 3.3.1 ZooKeeper 3.6.3 FusionInsight Manager 8.2.0.1

ClickHouse开源增强特性 MRS ClickHouse具备“手动挡”集群模式升级、平滑弹性扩容、高可用HA部署架构等优势能力，具体详情如下： 手动挡集群模式升级 如图1所示，多个ClickHouse节点组成的集群，没有中心节点，更多的是一个静态资源池的概念，业务要使用ClickHouse集群模式，需要预先在各个节点的配置文件中定义cluster信息，等所有参与的节点达成共识，业务才可以正确的交互访问，也就是说配置文件中的cluster才是通常理解的“集群”概念。 图1 ClickHouse集群 常见的数据库系统，隐藏了表级以下的数据分区、副本存储等细节，用户是无感知的，而ClickHouse则要求用户主动来规划和定义数据分片（shard）、分区（partition）、副本（replica）位置等详细配置。它的这种类似“手动挡”的属性，给用户带来极不友好的体验，所以MRS服务的ClickHouse实例对这些工作做了统一的打包处理，适配成了“自动挡”，实现了统一管理，灵活易用。 具体部署形态上，一个ClickHouse实例将包含3个ZooKeeper节点和多个ClickHouse节点，采用Dedicated Replica模式，数据双副本高可靠。 图2 ClickHouse的cluster结构 平滑的弹性扩容能力 随着业务的快速增长，面对集群存储容量或者CPU计算资源接近极限等场景，MRS服务提供了ClickHouse数据迁移工具，该工具可以将某几个ClickHouseServer实例节点上的一个或多个MergeTree引擎分区表的部分分区迁移至其他ClickHouseServer节点上相同的表中，以便保障业务可用性，实现了更加平滑的扩容能力。 在用户对集群进行扩容ClickHouse节点时，可以使用该工具将原节点上的部分数据迁移至新增节点上，从而达到扩容后的数据均衡。 高可用HA部署架构 MRS服务提供了基于ELB的HA部署架构，可以将用户访问流量自动分发到多台后端节点，扩展系统对外的服务能力，实现更高水平的应用容错。如图3所示，客户端应用请求集群时，使用ELB（Elastic Load Balance）来进行流量分发，通过ELB的轮询机制，写不同节点上的本地表（Local Table），读不同节点上的分布式表（Distributed Table），这样，无论集群写入的负载、读的负载以及应用接入的高可用性都具备了有力的保障。 ClickHouse集群发放成功后，每个ClickHouse实例节点对应一个副本replica，两个副本组成一个shard逻辑分片。如创建ReplicatedMergeTree引擎表时，可以指定分片，相同分片内的两个副本数据就可以自动进行同步。 图3 高可用HA部署架构图 父主题： ClickHouse

更新内容 服务模块 主要变更点 CarbonData 升级到2.2.0版本。 ClickHouse 支持通过FusionInsight Manager备份恢复元数据及业务数据。 Flink 升级到1.12.2版本。 FlinkServer支持上传、管理UDF。 Guardian 新增组件，支持存算分离场景下集群外客户端委托功能。 Hadoop 普通集群访问HDFS Web UI需要进行CAS认证。 Hudi 升级到0.9.0版本。 Impala 支持在MRS Manager页面上进行Impala SQL作业管理。 Spark2x 升级到3.1.1版本。 ZooKeeper 升级到3.6.3版本。 管理控制台 支持补丁在线推送及更新。 支持包周期集群中的部分节点退订。 作业提交API新增支持FlinkSQL作业类型。 支持指定资源池的弹性伸缩能力。 Master主机规格升级功能支持多Master节点集群。 Bootstrap脚本支持以root用户身份执行。 集群主机系统盘支持最小100GB容量，数据盘支持最小200GB容量。

组件版本信息 组件 版本 CarbonData 2.2.0 ClickHouse 21.3.4.25 DBService 2.7.0 Flink 1.12.2 Flume 1.9.0 Guardian 0.1.0 HBase 2.2.3 HDFS 3.1.1 Hive 3.1.0 Hudi（集成在Spark2x中） 0.9.0 Hue 4.7.0 Impala 3.4.0 Kafka 2.11-2.4.0 KrbServer 1.18 Kudu 1.12.1 LdapServer 2.7.0 Mapreduce 3.1.1 Oozie 5.1.0 Presto 333 Phoenix（集成在HBase中） 5.0.0 Ranger 2.0.0 Spark2x 3.1.1 Sqoop 1.4.7 Tez 0.9.2 Yarn 3.1.1 ZooKeeper 3.6.3

组件版本信息 表1 MRS组件版本信息 组件 版本 CarbonData 2.2.0 ClickHouse 21.3.4.25 DBService 2.7.0 Flink 1.12.2 Flume 1.9.0 HBase 2.2.3 HDFS 3.1.1 HetuEngine 1.2.0 Hive 3.1.0 Hudi（集成在Spark2x中） 0.9.0 Hue 4.7.0 Kafka 2.11-2.4.0 KrbServer 1.18 LdapServer 2.7.0 Loader 1.99.3 Mapreduce 3.1.1 Oozie 5.1.0 Phoenix（集成在HBase中） 5.0.0 Ranger 2.0.0 Spark2x 3.1.1 Tez 0.9.2 Yarn 3.1.1 ZooKeeper 3.6.3 FusionInsight Manager 8.1.2

Yarn和MapReduce的关系 MapReduce是运行在Yarn之上的一个批处理的计算框架。MRv1是Hadoop 1.0中的MapReduce实现，它由编程模型（新旧编程接口）、运行时环境（由JobTracker和TaskTracker组成）和数据处理引擎（MapTask和ReduceTask）三部分组成。该框架在扩展性、容错性（JobTracker单点）和多框架支持（仅支持MapReduce一种计算框架）等方面存在不足。MRv2是Hadoop 2.0中的MapReduce实现，它在源码级重用了MRv1的编程模型和数据处理引擎实现，但运行时环境由Yarn的ResourceManager和ApplicationMaster组成。其中ResourceManager是一个全新的资源管理系统，而ApplicationMaster则负责MapReduce作业的数据切分、任务划分、资源申请和任务调度与容错等工作。

Yarn和Spark组件的关系 Spark的计算调度方式，可以通过Yarn的模式实现。Spark共享Yarn集群提供丰富的计算资源，将任务分布式的运行起来。Spark on Yarn分两种模式：Yarn Cluster和Yarn Client。 Yarn Cluster模式 运行框架如图1所示。 图1 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模式 运行框架如图2所示。 图2 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汇报运行状况。