华为云用户手册

请求参数 表2 请求Header参数 参数 是否必选 参数类型 描述 Content-Type 是 String 消息体的类型（格式） X-Auth-Token 是 String 用户Token。通过调用 IAM 服务获取用户Token接口获取（响应消息头中X-Subject-Token的值） 表3 请求Body参数 参数 是否必选 参数类型 描述 name 否 String 环境名称 description 否 String 环境描述信息

Flink滑动窗口增强 本节主要介绍Flink滑动窗口以及滑动窗口的优化方式。 Flink窗口的详细内容请参见官网：https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/stream/operators/windows.html。 窗口介绍 窗口中数据的保存形式主要有中间结果和原始数据两种，对窗口中的数据使用公共算子，如sum等操作时（window(SlidingEventTimeWindows.of(Time.seconds(20), Time.seconds(5))).sum）仅会保留中间结果；当用户使用自定义窗口时（window(SlidingEventTimeWindows.of(Time.seconds(20), Time.seconds(5))).apply(new UDF)）保存所有的原始数据。 用户使用自定义SlidingEventTimeWindow和SlidingProcessingTimeWindow时，数据以多备份的形式保存。假设窗口的定义如下： window(SlidingEventTimeWindows.of(Time.seconds(20), Time.seconds(5))).apply(new UDFWindowFunction) 当一个数据到来时，会被分配到20/5=4个不同的窗口中，即数据在内存中保存了4份。当窗口大小/滑动周期非常大时，冗余现象非常严重。 图1 窗口原始结构示例 假设一个数据在102秒时到来，它将会被分配到[85, 105)、[90, 110)、[95, 115)以及[100, 120)四个不同的窗口中。 窗口优化 针对上述SlidingEventTimeWindow和SlidingProcessingTimeWindow在保存原始数据时存在的数据冗余问题，对保存原始数据的窗口进行重构，优化存储，使其存储空间大大降低，具体思路如下： 以滑动周期为单位，将窗口划分为若干相互不重合的pane。 每个窗口由一到多个pane组成，多个pane对窗口构成了覆盖关系。所谓一个pane即一个滑动周期，如：在窗口window(SlidingEventTimeWindows.of(Time.seconds(20), Time.seconds.of(5)))中pane的大小为5秒，假设这个窗口为[100, 120)，则包含的pane为[100, 105), [105, 110), [110, 115), [115, 120)。 图2 窗口重构示例 当某个数据到来时，并不分配到具体的窗口中，而是根据自己的时间戳计算出该数据所属的pane，并将其保存到对应的pane中。 一个数据仅保存在一个pane中，内存中只有一份。 图3 窗口保存数据示例 当需要触发某个窗口时，计算该窗口包含的所有pane，并取出合并成一个完整的窗口计算。 图4 窗口触发计算示例 当某个pane不再需要时，将其从内存中删除。 图5 窗口删除示例 通过优化，可以大幅度降低数据在内存以及快照中的数量。 父主题： Flink开源增强特性

组件WebUI便捷访问 大数据组件都有自己的WebUI页面管理自身系统，但是由于网络隔离的原因，用户并不能很简便地访问到该页面。比如访问HDFS的WebUI页面，传统的操作方法是需要用户创建E CS ，使用ECS远程登录组件的UI，这使得组件的页面UI访问很是繁琐，对于很多初次接触大数据的用户很不友好。 MRS 提供了基于弹性公网IP来便捷访问组件WebUI的安全通道，并且比用户自己绑定弹性公网IP更便捷，只需界面鼠标操作，即可简化原先用户需要自己登录虚拟私有云添加安全组规则，获取公网IP等步骤，减少了用户操作步骤。分析集群Hadoop、Spark、HBase、Hue及流式集群Storm，都可以在Manager上找到组件页面入口，快速访问。 父主题： 产品功能

CarbonData特性 SQL功能：CarbonData与Spark SQL完全兼容，支持所有可以直接在Spark SQL上运行的SQL查询操作。 简单的Table数据集定义：CarbonData支持易于使用的DDL（数据定义语言）语句来定义和创建数据集。CarbonData DDL十分灵活、易于使用，并且足够强大，可以定义复杂类型的Table。 便捷的数据管理：CarbonData为数据加载和维护提供多种数据管理功能。CarbonData支持加载历史数据以及增量加载新数据。加载的数据可以基于加载时间进行删除，也可以撤销特定的数据加载操作。 CarbonData文件格式是HDFS中的列式存储格式。该格式具有许多新型列存储文件的特性，例如，分割表，数据压缩等。CarbonData具有以下独有的特点： 伴随索引的数据存储：由于在查询中设置了过滤器，可以显著加快查询性能，减少I/O扫描次数和CPU资源占用。CarbonData索引由多个级别的索引组成，处理框架可以利用这个索引来减少需要安排和处理的任务，也可以通过在任务扫描中以更精细的单元（称为blocklet）进行skip扫描来代替对整个文件的扫描。 可选择的数据编码：通过支持高效的数据压缩和全局编码方案，可基于压缩/编码数据进行查询，在将结果返回给用户之前，才将编码转化为实际数据，这被称为“延迟物化”。 支持一种数据格式应用于多种用例场景：例如，交互式OLAP-style查询，顺序访问（big scan），随机访问（narrow scan）。

CarbonData关键技术和优势 快速查询响应：高性能查询是CarbonData关键技术的优势之一。CarbonData查询速度大约是Spark SQL查询的10倍。CarbonData使用的专用数据格式围绕高性能查询进行设计，其中包括多种索引技术、全局字典编码和多次的Push down优化，从而对TB级数据查询进行最快响应。 高效率数据压缩：CarbonData使用轻量级压缩和重量级压缩的组合压缩算法压缩数据，可以减少60%~80%数据存储空间，很大程度上节省硬件存储成本。

CarbonData结构 CarbonData作为Spark内部数据源运行，不需要额外启动集群节点中的其他进程，CarbonData Engine在Spark Executor进程之中运行。 图2 CarbonData结构 存储在CarbonData Table中的数据被分成若干个CarbonData数据文件，每一次数据查询时，CarbonData Engine模块负责执行数据集的读取、过滤等实际任务。CarbonData Engine作为Spark Executor进程的一部分运行，负责处理数据文件块的一个子集。 Table数据集数据存储在HDFS中。同一Spark集群内的节点可以作为HDFS的数据节点。

YARN HA原理与实现方案 YARN中的ResourceManager负责整个集群的资源管理和任务调度，在Hadoop2.4版本之前，ResourceManager在YARN集群中存在单点故障的问题。YARN高可用性方案通过引入冗余的ResourceManager节点的方式，解决了这个基础服务的可靠性和容错性问题。 图1 ResourceManager高可用性实现架构 ResourceManager的高可用性方案是通过设置一组Active/Standby的ResourceManager节点来实现的（如图1）。与HDFS的高可用性方案类似，任何时间点上都只能有一个ResourceManager处于Active状态。当Active状态的ResourceManager发生故障时，可通过自动或手动的方式触发故障转移，进行Active/Standby状态切换。 在未开启自动故障转移时，YARN集群启动后，MRS集群管理员需要在命令行中使用yarn rmadmin命令手动将其中一个ResourceManager切换为Active状态。当需要执行计划性维护或故障发生时，则需要先手动将Active状态的ResourceManager切换为Standby状态，再将另一个ResourceManager切换为Active状态。 开启自动故障转移后，ResourceManager会通过内置的基于ZooKeeper实现的ActiveStandbyElector来决定哪一个ResourceManager应该成为Active节点。当Active状态的ResourceManager发生故障时，另一个ResourceManager将自动被选举为Active状态以接替故障节点。 当集群的ResourceManager以HA方式部署时，客户端使用的“yarn-site.xml”需要配置所有ResourceManager地址。客户端（包括ApplicationMaster和NodeManager）会以轮询的方式寻找Active状态的ResourceManager，也就是说客户端需要自己提供容错机制。如果当前Active状态的ResourceManager无法连接，那么会继续使用轮询的方式找到新的ResourceManager。 备RM升主后，能够恢复故障发生时上层应用运行的状态（详见ResourceManger Restart）。当启用ResourceManager Restart时，重启后的ResourceManager就可以通过加载之前Active的ResourceManager的状态信息，并通过接收所有NodeManager上container的状态信息重构运行状态继续执行。这样应用程序通过定期执行检查点操作保存当前状态信息，就可以避免工作内容的丢失。状态信息需要让Active/Standby的ResourceManager都能访问。当前系统提供了三种共享状态信息的方法：通过文件系统共享（FileSystem RMS tateStore）、通过LevelDB数据库共享（LeveldbRMStateStore）或通过ZooKeeper共享（ZKRMStateStore）。这三种方式中只有ZooKeeper共享支持Fencing机制。Hadoop默认使用ZooKeeper共享。 关于YARN高可用性方案的更多信息，可参考如下链接： MRS 3.2.0之前版本：http://hadoop.apache.org/docs/r3.1.1/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html MRS 3.2.0及之后版本：https://hadoop.apache.org/docs/r3.3.1/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html

节点隔离 当用户发现某个主机出现异常或故障，无法提供服务或影响集群整体性能时，可以临时将主机从集群可用节点排除，使客户端访问其他可用的正常节点。在为集群安装补丁的场景中，也支持排除指定节点不安装补丁。隔离主机仅支持隔离非管理节点。 主机隔离后该主机上的所有角色实例将被停止，且不能对主机及主机上的所有实例进行启动、停止和配置等操作。另外，主机隔离后无法统计并显示该主机硬件和主机上实例的监控状态及指标数据。 父主题： 集群管理

Spark2x开源新特性说明 Spark2x版本相对于Spark 1.5版本新增了一些开源特性。 具体特性或相关概念如下： DataSet，详见SparkSQL和DataSet原理。 Spark SQL Native DDL/DML，详见SparkSQL和DataSet原理。 SparkSession，详见SparkSession原理。 Structured Streaming，详见Structured Streaming原理。 小文件优化。 聚合算法优化。 Datasource表优化。 合并CBO优化。 父主题： Spark2x开源增强特性

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信任机制。

组件及版本号信息（已下线版本） MRS已下线集群版本配套的组件及版本号信息如表2所示。 表2 MRS组件版本信息（已下线版本） MRS支持的组件 MRS 1.5.1 MRS 1.6.3 MRS 1.7.2 MRS 2.0.5（适用于MRS 2.0.x版本） MRS 1.8.10（适用于MRS 1.8.x） MRS 2.1.0（适用于MRS 2.1.x） MRS 3.0.5 Alluxio - - - - - - 2.3.0 CarbonData 1.3.1 1.3.1 1.3.1 1.5.1 1.6.1(MRS 1.8.10) 1.3.1(MRS 1.8.7及之前) 1.6.1（MRS 2.1.0） 2.0.0(MRS 2.1.1及之后) 2.0.1 ClickHouse - - - - - - 21.3.4.25 DBService 1.0.0 1.0.0 1.0.0 1.0.0 1.0.0 1.0.0 2.7.0 Flink - - - - 1.7.0 1.7.0 1.10.0 Flume 1.6.0 1.6.0 1.6.0 1.6.0 1.6.0 1.6.0 1.9.0 HBase 1.0.2 1.3.1 1.3.1 2.1.1 1.3.1 2.1.1 2.2.3 HDFS 2.7.2 2.7.2 2.8.3 3.1.1 2.8.3 3.1.1 3.1.1 Hive 1.2.1 1.2.1 1.2.1 3.1.0 1.2.1 3.1.0 3.1.0 Hue 3.11.0 3.11.0 3.11.0 3.11.0 3.11.0 3.11.0 4.7.0 Impala - - - - - 3.2.0 3.4.0 Kafka 0.10.0.0 0.10.0.0 0.10.2.0 1.1.0 1.1.0 1.1.0 2.11-2.4.0 KafkaManager - - - - 1.3.3.1 - - KrbServer 1.10.7 1.10.7 1.10.7 1.15.2 1.10.7 1.15.2 1.17 Kudu - - - - - 1.9.0 1.12.1 LdapServer 1.0.0 1.0.0 1.0.0 1.0.0 1.0.0 1.0.0 2.7.0 Loader 2.0.0 2.0.0 2.0.0 2.0.0 2.0.0 2.0.0 1.99.3 MapReduce 2.7.2 2.7.2 2.8.3 3.1.1 2.8.3 3.1.1 3.1.1 Oozie - - - - - - 5.1.0 Opentsdb - - - - 2.3.0 - - Presto - - - 308 0.215 308 333 Phoenix - - - - - - 5.0.0 Ranger - - - - - - 2.0.0 Spark 2.1.0 2.1.0 2.2.1 2.3.2 2.2.1 2.3.2 - Spark2x - - - - - - 2.4.5 Storm 1.0.2 1.0.2 1.0.2 1.2.1 1.2.1 1.2.1 1.2.1 Tez - - - 0.9.1 - 0.9.1 0.9.2 YARN 2.7.2 2.7.2 2.8.3 3.1.1 2.8.3 3.1.1 3.1.1 ZooKeeper 3.5.1 3.5.1 3.5.1 3.5.1 3.5.1 3.5.1 3.5.6 MRS Manager 1.5.1 1.6.3 1.7.2 2.0.5 1.8.10 2.1.0 - FusionInsight Manager - - - - - - 8.0.2.1

组件及版本号信息 MRS各集群版本配套的组件及版本号信息如表1所示。 Hadoop组件包含HDFS、Yarn、Mapreduce服务，DBService、ZooKeeper、KrbServer及LdapServer等集群内部使用的组件，在创建集群时的组件列表中不呈现。 MRS组件的版本号通常与组件开源版本号保持一致。 MRS集群内各组件不支持单独升级，请根据实际需要选择对应版本的集群。 LTS（Long Term Support）版本集群与普通版本集群区别可参考MRS集群版本说明。 表1 MRS组件版本信息 MRS支持的组件 MRS 1.9.x MRS 3.1.0 MRS 3.1.2-LTS.x MRS 3.1.5 MRS 3.2.0-LTS.x Alluxio 2.0.1 - - - - CarbonData 1.6.1 2.0.1 2.2.0 2.2.0 2.2.0 CDL - - - - - ClickHouse - 21.3.4.25 21.3.4.25 21.3.4.25 22.3.2.2 DBService 1.0.0 2.7.0 2.7.0 2.7.0 2.7.0 Flink 1.7.0 1.12.0 1.12.2 1.12.2 1.15.0 Flume 1.6.0 1.9.0 1.9.0 1.9.0 1.9.0 Guardian - - - 0.1.0 - HBase 1.3.1 2.2.3 2.2.3 2.2.3 2.2.3 HDFS 2.8.3 3.1.1 3.1.1 3.1.1 3.3.1 HetuEngine - - 1.2.0 - 1.2.0 Hive 2.3.3 3.1.0 3.1.0 3.1.0 3.1.0 Hudi - 0.7.0 0.9.0 0.9.0 0.11.0 Hue 3.11.0 4.7.0 4.7.0 4.7.0 4.7.0 Impala - 3.4.0 - 3.4.0 - IoTDB - - - - 0.14.0 Kafka 1.1.0 2.11-2.4.0 2.11-2.4.0 2.11-2.4.0 2.11-2.4.0 KafkaManager 1.3.3.1 - - - - KrbServer 1.15.2 1.17 1.18 1.18 1.18 Kudu - 1.12.1 - 1.12.1 - LdapServer 1.0.0 2.7.0 2.7.0 2.7.0 2.7.0 Loader 2.0.0 - 1.99.3 - 1.99.3 MapReduce 2.8.3 3.1.1 3.1.1 3.1.1 3.3.1 Oozie - 5.1.0 5.1.0 5.1.0 5.1.0 Opentsdb 2.3.0 - - - - Presto 0.216 333 - 333 - Phoenix（集成在HBase中） - 5.0.0 5.0.0 5.0.0 5.0.0 Ranger 1.0.1 2.0.0 2.0.0 2.0.0 2.0.0 Spark/Spark2x 2.2.2 2.4.5 3.1.1 3.1.1 3.1.1 Sqoop - 1.4.7 - 1.4.7 - Storm 1.2.1 - - - - Tez 0.9.1 0.9.2 0.9.2 0.9.2 0.9.2 Yarn 2.8.3 3.1.1 3.1.1 3.1.1 3.3.1 ZooKeeper 3.5.1 3.5.6 3.6.3 3.6.3 3.6.3 MRS Manager 1.9.2 - - - - FusionInsight Manager - 8.1.0 8.1.2.x 8.1.2 8.2.0.x

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中每个队列可以限制资源使用量。队列间的资源分配以使用量作为排列依据，使得容量小的队列有竞争优势。集群整体吞吐较大，延迟调度机制使得应用可以有机会放弃跨机器或者跨机架的调度，争取本地调度。

Storm和Streaming的关系 Storm和Streaming都使用的开源Apache Storm内核，不同的是，Storm使用的内核版本是1.2.1，Streaming使用的是0.10.0。Streaming组件一般用来在升级场景继承过渡业务，比如之前版本已经部署Streaming并且有业务在运行的情况下，升级后仍然可以使用Streaming。如果是新搭建的集群，则建议使用Storm。 Storm 1.2.1新增特性说明： 分布式缓存：提供命令行工具共享和更新拓扑的所需要的外部资源（配置），无需重新打包和部署拓扑。 Native Streaming Window API：提供基于窗口的API。 资源调度器：新增基于资源的调度器插件，可以在拓扑定义时指定可使用的最大资源，并且通过配置的方式指定用户的资源配额，从而管理该用户名下的拓扑资源。 State Management：提供带检查点机制的Bolt接口，当事件失败时，Storm会自动管理bolt的状态并且执行恢复。 消息采样和调试：在Storm UI界面可以开关拓扑或者组件级别的调试，将流消息按采样比率输出到指定日志中。 Worker动态分析：在Storm UI界面可以收集Wokrer进程的Jstack、Heap日志，并且可以重启Worker进程。 拓扑日志级别动态调整：提供命令行和Storm UI两种方式对运行中的拓扑日志进行动态修改。 性能提升：与之前的版本相比，Storm的性能得到了显著提升。虽然，拓扑的性能和用例场景及外部服务的依赖有很大的关系，但是对于大多数场景来说，性能可以提升3倍。

实现方案 多主实例模式的HA方案原理如下图所示。 图1 Spark JD BCS erver HA JDBCServer在启动时，向ZooKeeper注册自身消息，在指定目录中写入节点，节点包含了该实例对应的IP，端口，版本号和序列号等信息（多节点信息之间以逗号隔开）。 示例如下： [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] 客户端连接JDBCServer时，需要指定Namespace，即访问ZooKeeper哪个目录下的JDBCServer实例。在连接的时候，会从Namespace下随机选择一个实例连接，详细URL参见URL连接介绍。 客户端成功连接JDBCServer服务后，向JDBCServer服务发送SQL语句。 JDBCServer服务执行客户端发送的SQL语句后，将结果返回给客户端。 在HA方案中，每个JDBCServer服务（即实例）都是独立且等同的，当其中一个实例在升级或者业务中断时，其他的实例也能接受客户端的连接请求。 多主实例方案遵循以下规则： 当一个实例异常退出时，其他实例不会接管此实例上的会话，也不会接管此实例上运行的业务。 当JDBCServer进程停止时，删除在ZooKeeper上的相应节点。 由于客户端选择服务端的策略是随机的，可能会出现会话随机分配不均匀的情况，进而可能引起实例间的负载不均衡。 实例进入维护模式（即进入此模式后不再接受新的客户端连接）后，当达到退服超时时间，仍在此实例上运行的业务有可能会发生失败。

背景介绍 基于社区已有的JDBCServer基础上，采用多主实例模式实现了其高可用性方案。集群中支持同时共存多个JDBCServer服务，通过客户端可以随机连接其中的任意一个服务进行业务操作。即使集群中一个或多个JDBCServer服务停止工作，也不影响用户通过同一个客户端接口连接其他正常的JDBCServer服务。 多主实例模式相比主备模式的HA方案，优势主要体现在对以下两种场景的改进。 主备模式下，当发生主备切换时，会存在一段时间内服务不可用，该段时间JDBCServer无法控制，取决于Yarn服务的资源情况。 Spark中通过类似于HiveServer2的Thrift JDBC提供服务，用户通过Beeline以及JDBC接口访问。因此JDBCServer集群的处理能力取决于主Server的单点能力，可扩展性不够。 采用多主实例模式的HA方案，不仅可以规避主备切换服务中断的问题，实现服务不中断或少中断，还可以通过横向扩展集群来提高并发能力。

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子句中。

Spark应用运行原理 Spark的应用运行架构如图 Spark应用运行架构所示，运行流程如下所示： 应用程序（Application）是作为一个进程的集合运行在集群上的，由Driver进行协调。 在运行一个应用时，Driver会去连接集群管理器（Standalone、Mesos、YARN）申请运行Executor资源，并启动ExecutorBackend。然后由集群管理器在不同的应用之间调度资源。Driver同时会启动应用程序DAG调度、Stage划分、Task生成。 然后Spark会把应用的代码（传递给SparkContext的JAR或者Python定义的代码）发送到Executor上。 所有的Task执行完成后，用户的应用程序运行结束。 图2 Spark应用运行架构 Spark采用Master和Worker的模式，如图 Spark的Master和Worker所示。用户在Spark客户端提交应用程序，调度器将Job分解为多个Task发送到各个Worker中执行，各个Worker将计算的结果上报给Driver（即Master），Driver聚合结果返回给客户端。 图3 Spark的Master和Worker 在此结构中，有几个说明点： 应用之间是独立的。 每个应用有自己的executor进程，Executor启动多个线程，并行地执行任务。无论是在调度方面，或者是executor方面。各个Driver独立调度自己的任务；不同的应用任务运行在不同的JVM上，即不同的Executor。 不同Spark应用之间是不共享数据的，除非把数据存储在外部的存储系统上（比如HDFS）。 因为Driver程序在集群上调度任务，所以Driver程序建议和worker节点比较近，比如在一个相同的局部网络内。 Spark on YARN有两种部署模式： yarn-cluster模式下，Spark的Driver会运行在YARN集群内的ApplicationMaster进程中，ApplicationMaster已经启动之后，提交任务的客户端退出也不会影响任务的运行。 yarn-client模式下，Driver启动在客户端进程内，ApplicationMaster进程只用来向YARN集群申请资源。

Spark结构 Spark的结构如图1所示，各模块的说明如表 基本概念说明所示。 图1 Spark结构 表1 基本概念说明 模块 说明 Cluster Manager 集群管理器，管理集群中的资源。Spark支持多种集群管理器，Spark自带的Standalone集群管理器、Mesos或YARN，系统默认采用YARN模式。 Application Spark应用，由一个Driver Program和多个Executor组成。 Deploy Mode 部署模式，分为cluster和client模式。cluster模式下，Driver会在集群内的节点运行；而在client模式下，Driver在客户端运行（集群外）。 Driver Program 是Spark应用程序的主进程，运行Application的main()函数并创建SparkContext。负责应用程序的解析、生成Stage并调度Task到Executor上。通常SparkContext代表Driver Program。 Executor 在Work Node上启动的进程，用来执行Task，管理并处理应用中使用到的数据。一个Spark应用一般包含多个Executor，每个Executor接收Driver的命令，并执行一到多个Task。 Worker Node 集群中负责启动并管理Executor以及资源的节点。 Job 一个Action算子（比如collect算子）对应一个Job，由并行计算的多个Task组成。 Stage 每个Job由多个Stage组成，每个Stage是一个Task集合，由DAG分割而成。 Task 承载业务逻辑的运算单元，是Spark平台上可执行的最小工作单元。一个应用根据执行计划以及计算量分为多个Task。

Spark Streaming原理 Spark Streaming是一种构建在Spark上的实时计算框架，扩展了Spark处理大规模流式数据的能力。当前Spark支持两种数据处理方式： Direct Streaming Direct Streaming方式主要通过采用Direct API对数据进行处理。以Kafka Direct接口为例，与启动一个Receiver来连续不断地从Kafka中接收数据并写入到WAL中相比，Direct API简单地给出每个batch区间需要读取的偏移量位置。然后，每个batch的Job被运行，而对应偏移量的数据在Kafka中已准备好。这些偏移量信息也被可靠地存储在checkpoint文件中，应用失败重启时可以直接读取偏移量信息。 图4 Direct Kafka接口数据传输 需要注意的是，Spark Streaming可以在失败后重新从Kafka中读取并处理数据段。然而，由于语义仅被处理一次，重新处理的结果和没有失败处理的结果是一致的。 因此，Direct API消除了需要使用WAL和Receivers的情况，且确保每个Kafka记录仅被接收一次，这种接收更加高效。使得Spark Streaming和Kafka可以很好地整合在一起。总体来说，这些特性使得流处理管道拥有高容错性、高效性及易用性，因此推荐使用Direct Streaming方式处理数据。 Receiver 在一个Spark Streaming应用开始时（也就是Driver开始时），相关的StreamingContext（所有流功能的基础）使用SparkContext启动Receiver成为长驻运行任务。这些Receiver接收并保存流数据到Spark内存中以供处理。用户传送数据的生命周期如图5所示： 图5 数据传输生命周期 接收数据（蓝色箭头） Receiver将数据流分成一系列小块，存储到Executor内存中。另外，在启用预写日志（Write-ahead Log，简称WAL）以后，数据同时还写入到容错文件系统的预写日志中。 通知Driver（绿色箭头） 接收块中的元数据被发送到Driver的StreamingContext。这个元数据包括： 定位其在Executor内存中数据位置的块Reference ID。 若启用了WAL，还包括块数据在日志中的偏移信息。 处理数据（红色箭头） 对每个批次的数据，StreamingContext使用Block信息产生RDD及其Job。StreamingContext通过运行任务处理Executor内存中的Block来执行Job。 周期性的设置检查点（橙色箭头） 为了容错的需要，StreamingContext会周期性的设置检查点，并保存到外部文件系统中。 容错性 Spark及其RDD允许无缝地处理集群中任何Worker节点的故障。鉴于Spark Streaming建立于Spark之上，因此其Worker节点也具备了同样的容错能力。然而，由于Spark Streaming的长正常运行需求，其应用程序必须也具备从Driver进程（协调各个Worker的主要应用进程）故障中恢复的能力。使Spark Driver能够容错是件很棘手的事情，因为可能是任意计算模式实现的任意用户程序。不过Spark Streaming应用程序在计算上有一个内在的结构：在每批次数据周期性地执行同样的Spark计算。这种结构允许把应用的状态（也叫做Checkpoint）周期性地保存到可靠的存储空间中，并在Driver重新启动时恢复该状态。 对于文件这样的源数据，这个Driver恢复机制足以做到零数据丢失，因为所有的数据都保存在了像HDFS这样的容错文件系统中。但对于像Kafka和Flume等其他数据源，有些接收到的数据还只缓存在内存中，尚未被处理，就有可能会丢失。这是由于Spark应用的分布操作方式引起的。当Driver进程失败时，所有在Cluster Manager中运行的Executor，连同在内存中的所有数据，也同时被终止。为了避免这种数据损失，Spark Streaming引进了WAL功能。 WAL通常被用于数据库和文件系统中，用来保证任何数据操作的持久性，即先将操作记入一个持久的日志，再对数据施加这个操作。若施加操作的过程中执行失败了，则通过读取日志并重新施加前面指定的操作，系统就得到了恢复。下面介绍了如何利用这样的概念保证接收到的数据的持久性。 Kafka数据源使用Receiver来接收数据，是Executor中的长运行任务，负责从数据源接收数据，并且在数据源支持时还负责确认收到数据的结果（收到的数据被保存在Executor的内存中，然后Driver在Executor中运行来处理任务）。 当启用了预写日志以后，所有收到的数据同时还保存到了容错文件系统的日志文件中。此时即使Spark Streaming失败，这些接收到的数据也不会丢失。另外，接收数据的正确性只在数据被预写到日志以后Receiver才会确认，已经缓存但还没有保存的数据可以在Driver重新启动之后由数据源再发送一次。这两个机制确保了零数据丢失，即所有的数据或者从日志中恢复，或者由数据源重发。 如果需要启用预写日志功能，可以通过如下动作实现： 通过“streamingContext.checkpoint”设置checkpoint的目录，这个目录是一个HDFS的文件路径，既用作保存流的checkpoint，又用作保存预写日志。 设置SparkConf的属性“spark.streaming.receiver.writeAheadLog.enable”为“true”（默认值是“false”）。 在WAL被启用以后，所有Receiver都获得了能够从可靠收到的数据中恢复的优势。建议缓存RDD时不采取多备份选项，因为用于预写日志的容错文件系统很可能也复制了数据。 在启用了预写日志以后，数据接收吞吐率会有降低。由于所有数据都被写入容错文件系统，文件系统的写入吞吐率和用于数据复制的网络带宽，可能就是潜在的瓶颈了。在此情况下，建议创建更多的Recevier增加数据接收的并行度，或使用更好的硬件以增加容错文件系统的吞吐率。 恢复流程 当一个失败的Driver重启时，按如下流程启动： 图6 计算恢复流程 恢复计算（橙色箭头） 使用checkpoint信息重启Driver，重新构造SparkContext并重启Receiver。 恢复元数据块（绿色箭头） 为了保证能够继续下去所必备的全部元数据块都被恢复。 未完成作业的重新形成（红色箭头） 由于失败而没有处理完成的批处理，将使用恢复的元数据再次产生RDD和对应的作业。 读取保存在日志中的块数据（蓝色箭头） 在这些作业执行时，块数据直接从预写日志中读出。这将恢复在日志中可靠地保存的所有必要数据。 重发尚未确认的数据（紫色箭头） 失败时没有保存到日志中的缓存数据将由数据源再次发送。因为Receiver尚未对其确认。 因此通过预写日志和可靠的Receiver，Spark Streaming就可以保证没有输入数据会由于Driver的失败而丢失。

Structured Streaming原理 Structured Streaming是构建在Spark SQL引擎上的流式数据处理引擎，用户可以使用Scala、Java、Python或R中的Dataset/DataFrame API进行流数据聚合运算、按事件时间窗口计算、流流Join等操作。当流数据连续不断的产生时，Spark SQL将会增量的、持续不断的处理这些数据并将结果更新到结果集中。同时，系统通过checkpoint和Write Ahead Logs确保端到端的完全一次性容错保证。 Structured Streaming的核心是将流式的数据看成一张不断增加的数据库表，这种流式的数据处理模型类似于数据块处理模型，可以把静态数据库表的一些查询操作应用在流式计算中，Spark执行标准的SQL查询，从不断增加的无边界表中获取数据。 图8 Structured Streaming无边界表 每一条查询的操作都会产生一个结果集Result Table。每一个触发间隔，当新的数据新增到表中，都会最终更新Result Table。无论何时结果集发生了更新，都能将变化的结果写入一个外部的存储系统。 图9 Structured Streaming数据处理模型 Structured Streaming在OutPut阶段可以定义不同的存储方式，有如下3种： Complete Mode：整个更新的结果集都会写入外部存储。整张表的写入操作将由外部存储系统的连接器完成。 Append Mode：当时间间隔触发时，只有在Result Table中新增加的数据行会被写入外部存储。这种方式只适用于结果集中已经存在的内容不希望发生改变的情况下，如果已经存在的数据会被更新，不适合适用此种方式。 Update Mode：当时间间隔触发时，只有在Result Table中被更新的数据才会被写入外部存储系统。注意，和Complete Mode方式的不同之处是不更新的结果集不会写入外部存储。

SparkSession原理 SparkSession是Spark编程的统一API，也可看作是读取数据的统一入口。SparkSession提供了一个统一的入口点来执行以前分散在多个类中的许多操作，并且还为那些较旧的类提供了访问器方法，以实现最大的兼容性。 使用构建器模式创建SparkSession。如果存在SparkSession，构建器将自动重用现有的SparkSession；如果不存在则会创建一个SparkSession。 在I/O期间，在构建器中设置的配置项将自动同步到Spark和Hadoop。 import org.apache.spark.sql.SparkSession val sparkSession = SparkSession.builder .master("local") .appName("my-spark-app") .config("spark.some.config.option", "config-value") .getOrCreate() SparkSession可以用于对数据执行SQL查询，将结果返回为DataFrame。 sparkSession.sql("select * from person").show SparkSession可以用于设置运行时的配置项，这些配置项可以在SQL中使用变量替换。 sparkSession.conf.set("spark.some.config", "abcd") sparkSession.conf.get("spark.some.config") sparkSession.sql("select ${spark.some.config}") SparkSession包括一个“catalog”方法，其中包含使用Metastore（即数据目录）的方法。方法返回值为数据集，可以使用相同的Dataset API来运行。 val tables = sparkSession.catalog.listTables() val columns = sparkSession.catalog.listColumns("myTable") 底层SparkContext可以通过SparkSession的SparkContext API访问。 val sparkContext = sparkSession.sparkContext

Spark简介 Spark是一个开源的，并行数据处理框架，能够帮助用户简单、快速的开发大数据应用，对数据进行离线处理、流式处理、交互式分析等。 Spark提供了一个快速的计算、写入及交互式查询的框架。相比于Hadoop，Spark拥有明显的性能优势。Spark使用in-memory的计算方式，通过这种方式来避免一个MapReduce工作流中的多个任务对同一个数据集进行计算时的IO瓶颈。Spark利用Scala语言实现，Scala能够使得处理分布式数据集时，能够像处理本地化数据一样。除了交互式的数据分析，Spark还能够支持交互式的数据挖掘，由于Spark是基于内存的计算，很方便处理迭代计算，而数据挖掘的问题通常都是对同一份数据进行迭代计算。除此之外，Spark能够运行于安装Hadoop 2.0 Yarn的集群。之所以Spark能够在保留MapReduce容错性，数据本地化，可扩展性等特性的同时，能够保证性能的高效，并且避免繁忙的磁盘IO，主要原因是因为Spark创建了一种叫做RDD（Resilient Distributed Dataset）的内存抽象结构。 原有的分布式内存抽象，例如key-value store以及数据库，支持对于可变状态的细粒度更新，这一点要求集群需要对数据或者日志的更新进行备份来保障容错性。这样就会给数据密集型的工作流带来大量的IO开销。而对于RDD来说，它只有一套受限制的接口，仅支持粗粒度的更新，例如map，join等等。通过这种方式，Spark只需要简单的记录建立数据的转换操作的日志，而不是完整的数据集，就能够提供容错性。这种数据的转换链记录就是数据集的溯源。由于并行程序，通常是对一个大数据集应用相同的计算过程，因此之前提到的粗粒度的更新限制并没有想象中的大。事实上，Spark论文中阐述了RDD完全可以作为多种不同计算框架，例如MapReduce，Pregel等的编程模型。并且，Spark同时提供了操作允许用户显式地将数据转换过程持久化到硬盘。对于数据本地化，是通过允许用户能够基于每条记录的键值，控制数据分区实现的。（采用这种方式的一个明显好处是，能够保证两份需要进行关联的数据将会被同样的方式进行哈希）。如果内存的使用超过了物理限制，Spark将会把这些比较大的分区写入到硬盘，由此来保证可扩展性。 Spark具有如下特点： 快速：数据处理能力，比MapReduce快10-100倍。 易用：可以通过Java，Scala，Python，简单快速的编写并行的应用处理大数据量，Spark提供了超过80种的操作符来帮助用户组建并行程序。 普遍性：Spark提供了众多的工具，例如Spark SQL和Spark Streaming。可以在一个应用中，方便地将这些工具进行组合。 与Hadoop集成：Spark能够直接运行于Hadoop的集群，并且能够直接读取现存的Hadoop数据。 MRS服务的Spark组件具有以下优势： MRS服务的Spark Streaming组件支持数据实时处理能力而非定时触发。 MRS服务的Spark组件支持Structured Streaming，支持DataSet API来构建流式应用，提供了exactly-once的语义支持，流和流的join操作支持内连接和外连接。 MRS服务的Spark组件支持pandas_udf，可以利用pandas_udf替代pyspark中原来的udf对数据进行处理，可以减少60%-90%的处理时长（受具体操作影响）。 MRS服务的Spark组件支持Graph功能，支持图计算作业使用图进行建模。 MRS服务的SparkSQL兼容部分Hive语法（以Hive-Test-benchmark测试集上的64个SQL语句为准）和标准SQL语法（以tpc-ds测试集上的99个SQL语句为准）。 Spark的架构和详细原理介绍，请参见：https://archive.apache.org/dist/spark/docs/3.1.1/。

作业管理 作业管理为用户提供向集群提交作业的入口，支持包括MapReduce、Spark、HQL和SparkSQL等类型的作业。结合华为云 数据治理中心 DataArts Studio，提供一站式的大数据协同开发环境、全托管的大数据调度能力，帮助用户快速构建大数据处理中心。 通过 数据治理 中心 DataArts Studio ，用户可以先在线开发调试MRS HQL/SparkSQL脚本、拖拽式地开发MRS作业，完成MRS与其他20多种异构数据源之间的数据迁移和数据集成；通过强大的作业调度与灵活的监控告警，轻松管理数据作业运维。 父主题： 产品功能

DBService简介 DBService是一个高可用性的关系型数据库存储系统，适用于存储小量数据（10GB左右），比如：组件元数据。DBService仅提供给集群内部的组件使用，提供数据存储、查询、删除等功能。 DBService是集群的基础组件，Hive、Hue、Oozie、Loader、CDL、Flink、HuteEngine、Kafka、Metadata、Ranger等组件将元数据存储在DBService上，并由DBService提供这些元数据的备份与恢复功能。

DBService结构 DBService组件在集群中采用主备模式部署两个DBServer实例，每个DBServer实例包含三个模块：HA、Database和FloatIP。 其逻辑结构如图1所示。 图1 DBService结构 图1中各模块的说明如表1所示。 表1 模块说明 名称 描述 HA 高可用性管理模块，主备DBServer通过HA进行管理。 Database 数据库模块，存储Client模块的元数据。 FloatIP 浮动IP，对外提供访问功能，只在主DBServer实例上启动浮动IP，Client模块通过该IP访问Database。 Client 使用DBService组件的客户端，部署在组件实例节点上，通过Floatip连接数据库，执行元数据的增加、删除、修改等操作。

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

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