华为云用户手册

支持CPU硬隔离 YARN无法严格控制每个container使用的CPU资源。在使用CPU子系统时，container可能会超额占用资源。此时使用CPUset控制资源分配。 为了解决这个问题，CPU将会被严格按照虚拟核和物理核的比例分配至各个container。如果container需要一整个物理核，则分配给它一整个物理核。若container只需要部分物理核，则可能发生几个container共享同一个物理核的情况。下图为CPU配额示例，假定虚拟核和物理核的比例为2:1。 图4 CPU配额

自研超级调度器Superior Scheduler原理 Superior Scheduler是一个专门为Hadoop YARN分布式资源管理系统设计的调度引擎，是针对企业客户融合资源池，多租户的业务诉求而设计的高性能企业级调度器。 Superior Scheduler可实现开源调度器、Fair Scheduler以及Capacity Scheduler的所有功能。另外，相较于开源调度器，Superior Scheduler在企业级多租户调度策略、租户内多用户资源隔离和共享、调度性能、系统资源利用率和支持大集群扩展性方面都做了针对性的增强。设计的目标是让Superior Scheduler直接替代开源调度器。 类似于开源Fair Scheduler和Capacity Scheduler，Superior Scheduler通过YARN调度器插件接口与YARN Resource Manager组件进行交互，以提供资源调度功能。图1为其整体系统图。 图1 Superior Scheduler内部架构 图1中，Superior Scheduler的主要模块如下： Superior Scheduler Engine：具有丰富调度策略的高性能调度器引擎。 Superior YARN Scheduler Plugin：YARN Resource Manager和Superior Scheduler Engine之间的桥梁，负责同YARN Resource Manager交互。 在调度原理上，开源的调度器都是基于计算节点心跳驱动的资源反向匹配作业的调度机制。具体来讲，每个计算节点定期发送心跳到YARN的Resource Manager通知该节点状态并同时启动调度器为这个节点分配作业。这种调度机制把调度的周期同心跳结合在一起，当集群规模增大时，会遇到系统扩展性以及调度性能瓶颈。另外，因为采用了资源反向匹配作业的调度机制，开源调度器在调度精度上也有局限性，例如数据亲和性偏于随机，另外系统也无法支持基于负载的调度策略等。主要原因是调度器在选择作业时，缺乏全局的资源视图，很难做到好的选择。 Superior Scheduler内部采用了不同的调度机制。Superior Scheduler的调度器引入了专门的调度线程，把调度同心跳剥离开，避免了系统心跳风暴问题。另外，Superior Scheduler调度流程采用了从作业到资源的正向匹配方法，这样每个调度的作业都有全局的资源视图，可以很大的提高调度的精度。相比开源调度器，Superior Scheduler在系统吞吐量、利用率、数据亲和性等方面都有很大提升。 图2 Superior Scheduler性能对比 Superior Scheduler除了提高系统吞吐量和利用率，还提供了以下主要调度功能： 多资源池 多资源池有助于在逻辑上划分集群资源并在多个租户/队列之间共享它们。资源池的划分可以基于异构的资源或完全按照应用资源隔离的诉求来划分。对于一个资源池，不同队列可配置进一步的策略。 每个资源池多租户调度（reserve、min、share、max） Superior Scheduler提供了灵活的层级多租户调度策略。并允许针对不同的资源池可以访问的租户/队列，配置不同策略，如下所示。 表1 策略描述 策略名称 描述 reserve 预留租户资源。即使租户没有作业，其他租户也不能使用该预留的资源。其值可以是百分比或绝对值。如果两者都配置，调度系统动态计算转换为资源绝对值，并取两者的最大值。缺省的reserve值为0。相对于定义一个专用资源池并指定具体机器的方式，reserve的策略可以认为提供了一种灵活的浮动预留功能，由于并不限定具体的机器，可以提高计算的数据亲和性，也不会受具体机器故障的影响。 min 具有抢占支持的最低保证资源。其他租户可以使用这部分资源，但是本租户享有优先使用权。其值可以是百分比或绝对值。如果两者都配置，调度系统动态计算转换为资源绝对值，并取两者的最大值。缺省值是0。 share 不支持抢占的共享资源。本租户要使用这部分资源时，需要等待其他租户完成作业并释放资源。其值是百分比或绝对值。 max 允许的最大资源数量。租户无法获得比允许的最大资源多的资源。其值是百分比或绝对值。如果两者都配置，调度系统动态计算转换为资源绝对值，并取两者最大值。缺省值不受限制。 租户资源分配策略示意图，如图3所示。 图3 策略示意图 其中“total”表示总资源，不是调度策略。 同开源的调度器相比，Superior Scheduler同时提供了租户级百分比和绝对值的混配策略，可以很好的适应各种灵活的企业级租户资源调度诉求。例如，用户可以在一级租户提供最大绝对值的资源保障，这样租户的资源不会因为集群的规模改变而受影响。但在下层的子租户之间，可以提供百分比的分配策略，这样可以尽可能提升一级租户内的资源利用率。 异构和多维资源调度 Superior Scheduler除支持CPU和内存资源的调度外，还支持扩展以下功能： 节点标签可用于识别不同节点的多维属性，可以根据这些标签进行调度。 资源池可用于对同一类别的资源进行分组并分配给特定的租户/队列。 租户内多用户公平调度 在叶子租户里，多个用户可以使用相同的队列来提交作业。相比开源调度器，Superior Scheduler可以支持在同一租户内灵活配置不同用户的资源共享策略。例如可以为VIP用户配置更多的资源访问权重。 数据位置感知调度 Superior Scheduler采用“从作业到节点的调度策略”，即尝试在可用节点之间调度给定的作业，使得所选节点适合于给定作业。通过这样做，调度器将具有集群和数据的整体视图。如果有机会使任务更接近数据，则保证了本地化。而开源调度器采用“从节点到作业的调度策略”，在给定节点中尝试匹配适当的作业。 Container调度时动态资源预留 在异构和多样化的计算环境中，一些container需要更多的资源或多种资源，例如Spark作业可能需要更大的内存。当这些container与其他需要较小资源的container竞争时，可能没有机会在合理的时间内获得所需的资源而处于饥饿状态。由于开源的调度器是基于资源反向匹配作业的调度方式，会为这些作业盲目的进行资源预留以防进入饥饿状态。这就导致了系统资源的整体浪费。Superior Scheduler与开源特性的不同之处在于： 基于需求的匹配：由于Superior Scheduler采用“从作业到节点的调度”，能够选择合适的节点来预留资源提升这些特殊container的启动时间，并避免浪费。 租户重新平衡：启用预留逻辑时，开源调度器并不遵循配置的共享策略。Superior Scheduler采取不同的方法。在每个调度周期中，Superior Scheduler将遍历租户，并尝试基于多租户策略重新达到平衡，且尝试满足所有策略（reserve，min，share等），以便可以释放预留的资源，将可用资源流向不同租户下的其他本应得到资源的container。 动态队列状态控制（Open/Closed/Active/Inactive） 支持多个队列状态，有助于 MRS 集群管理员操作和维护多个租户。 Open状态（Open/Closed）：如果是Open（默认）状态，将接受提交到此队列的应用程序，如果是Closed状态，则不接受任何应用程序。 Active状态（Active/Inactive）：如果处于Active（默认）状态，租户内的应用程序是可以被调度和分配资源。如果处于Inactive状态则不会进行调度。 应用等待原因 如果应用程序尚未启动，则提供作业等待原因信息。 Superior Scheduler和YARN开源调度器作了对比分析，如表2所示： 表2 对比分析 领域 YARN开源调度器 Superior Scheduler 多租户调度 在同构集群上，只能选择容量调度器（Capacity Scheduler）或公平调度器（Fair Scheduler）两者之一，且集群当前不支持公平调度器（Fair Scheduler）。容量调度器只支持百分比方式配置，而公平调度器只支持绝对值方式。 支持异构集群和多资源池。 支持预留，以保证直接访问资源。 数据位置感知调度 从节点到作业的调度策略导致降低数据本地化命中率，潜在影响应用的执行性能。 从作业到节点的调度策略。可具有更精确的数据位置感知，数据本地化调度的作业命中率比较高。 基于机器负载的均衡调度 不支持 Superior Scheduler在调度时考虑机器的负载和资源分配情况，做到均衡调度。 租户内多用户公平调度 不支持 租户内用户的公平调度，支持关键字default、others。 作业等待原因 不支持 作业等待原因信息可显示为什么作业需等待。 综上所述，Superior Scheduler是一个高性能调度器，拥有丰富的调度策略，在功能、性能、资源利用率和扩展性方面都优于Capacity Scheduler。

任务优先级调度 在原生的YARN资源调度机制中，如果先提交的MapReduce Job长时间地占据整个Hadoop集群的资源，会使得后提交的Job一直处于等待状态，直到Running中的Job执行完并释放资源。 MRS集群提供了任务优先级调度机制。此机制允许用户定义不同优先级的Job，后启动的高优先级Job能够获取运行中的低优先级Job释放的资源；低优先级Job未启动的计算容器被挂起，直到高优先级Job完成并释放资源后，才被继续启动。 该特性使得业务能够更加灵活地控制自己的计算任务，从而达到更佳的集群资源利用率。 容器可重用与任务优先级调度有冲突，若启用容器重用，资源会被持续占用，优先级调度将不起作用。

Hive开源增强特性：支持HDFS Colocation HDFS Colocation（同分布）是HDFS提供的数据分布控制功能，利用HDFS Colocation接口，可以将存在关联关系或者可能进行关联操作的数据存放在相同的存储节点上。 Hive支持HDFS的Colocation功能，即在创建Hive表时，通过设置表文件分布的locator信息，可以将相关表的数据文件存放在相同的存储节点上，从而使后续的多表关联的数据计算更加方便和高效。

Hive开源增强特性：支持列加密功能 Hive支持对表的某一列或者多列进行加密。在创建Hive表时，可以指定要加密的列和加密算法。当使用insert语句向表中插入数据时，即可将对应的列进行加密。Hive列加密不支持视图以及Hive over HBase场景。 Hive列加密机制目前支持的加密算法有两种，具体使用的算法在建表时指定。 AES（对应加密类名称为：org.apache.hadoop.hive.serde2.AESRewriter） SMS 4（对应加密类名称为：org.apache.hadoop.hive.serde2.SMS4Rewriter）

Flume原理 Agent之间的可靠性 Agent之间数据交换流程如图4所示。 图4 Agent数据传输流程 Flume采用基于Transactions的方式保证数据传输的可靠性，当数据从一个Agent流向另外一个Agent时，两个Transactions已经开始生效。发送Agent的Sink首先从Channel取出一条消息，并且将该消息发送给另外一个Agent。如果接受消息的Agent成功地接受并处理消息，那么发送Agent将会提交Transactions，标识一次数据传输成功可靠地完成。 当接收Agent接受到发送Agent发送的消息时，开始一个新的Transactions，当该数据被成功处理（写入Channel中），那么接收Agent提交该Transactions，并向发送Agent发送成功响应。 如果在某次提交（commit）之前，数据传输出现了失败，将会再次开始上一次Transactions，并将上次发送失败的数据重新传输。因为commit操作已经将Transactions写入了磁盘，那么在进程故障退出并恢复业务之后，仍然可以继续上次的Transactions。

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

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

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

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

Spark原理 Spark的应用运行架构如图2所示，运行流程如下所示： 应用程序（Application）是作为一个进程的集合运行在集群上的，由Driver进行协调。 在运行一个应用时，Driver会去连接集群管理器（Standalone、Mesos、YARN）申请运行Executor资源，并启动ExecutorBackend。然后由集群管理器在不同的应用之间调度资源。Driver同时会启动应用程序DAG调度、Stage划分、Task生成。 然后Spark会把应用的代码（传递给SparkContext的JAR或者Python定义的代码）发送到Executor上。 所有的Task执行完成后，用户的应用程序运行结束。 图2 Spark应用运行架构 Spark采用Master和Worker的模式，如图3所示。用户在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已经启动之后，提交任务的客户端退出也不会影响任务的运行。 YRAN-Client模式下，Driver启动在客户端进程内，ApplicationMaster进程只用来向YARN集群申请资源。

Spark Streaming原理 Spark Streaming是一种构建在Spark上的实时计算框架，扩展了Spark处理大规模流式数据的能力。当前Spark支持两种数据处理方式：Direct Streaming和Receiver方式。 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（绿色箭头） 接收块中的元数据（Metadata）被发送到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”(path-to-directory)设置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的失败而丢失。

SparkSession原理 SparkSession是Spark2x编程的统一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

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方式的不同之处是不更新的结果集不会写入外部存储。

结构 Spark的架构如图1所示，各模块的说明如表1所示。 图1 Spark架构 表1 基本概念说明 模块 说明 Cluster Manager 集群管理器，管理集群中的资源。Spark支持多种集群管理器，Spark自带的Standalone集群管理器、Mesos或YARN。Spark集群默认采用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是基于内存的分布式计算框架。在迭代计算的场景下，数据处理过程中的数据可以存储在内存中，提供了比MapReduce高10到100倍的计算能力。Spark可以使用HDFS作为底层存储，使用户能够快速地从MapReduce切换到Spark计算平台上去。Spark提供一站式数据分析能力，包括小批量流式处理、离线批处理、SQL查询、数据挖掘等，用户可以在同一个应用中无缝结合使用这些能力。Spark2x的开源新特性请参考Spark2x开源新特性说明。 Spark的特点如下：

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开源增强特性：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双读 在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的函数接口类似。

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恢复时长。

特性简介 MRS提供标准的云上弹性大数据集群，目前可安装部署包括Hadoop、Spark等大数据组件。当前标准的云上大数据集群不能满足所有用户需求，例如如下几种场景： 通用的操作系统配置不能满足实际数据处理需求，例如需调大系统最大连接数。 需要安装自身业务所需的软件工具或运行环境，例如须安装Gradle、业务需要依赖R语言包。 根据自身业务对大数据组件包做修改，例如对Hadoop或Spark安装包做修改。 需要安装其他MRS还未支持的大数据组件。 对于上述定制化的场景，可以选择登录到每个节点上手动操作，之后每扩容一个新节点，再执行一次同样的操作，操作相对繁琐，也容易出错。同时手动执行记录不便追溯，不能实现“按需创建、创建成功后即处理数据”的目标。 因此，MRS提供了自定义引导操作，在启动集群组件前（或后）可以在指定的节点上执行脚本。用户可以通过引导操作来完成安装MRS还没支持的第三方软件，修改集群运行环境等自定义操作。如果集群扩容，选择执行引导操作，则引导操作也会以相同方式在新增节点上执行。MRS会使用root用户执行用户指定的脚本，脚本内部可以通过su - xxx命令切换用户。

概述 欢迎使用 对象存储服务 OBS（Object Storage Service）。对象存储服务提供海量、安全、高可靠、低成本的数据存储能力，可供用户存储任意类型和大小的数据。适合企业备份/归档、 视频点播 、视频监控等多种数据存储场景。 您可以使用本文档提供的API对OBS进行相关操作，如创建、修改、删除桶，上传、下载、删除对象等。支持的全部操作请参见API概览。 在调用OBS API之前，请确保已经充分了解OBS相关概念，详细信息请参见产品介绍。 父主题： 使用前必读

新增头域 SSE-OBS方式用户可以通过配置表1中的头域来实现SSE-OBS加密。 您也可以通过配置桶的默认加密方式来对桶内的对象进行加密。在为桶配置默认加密后，对于任何不带加密头域的上传对象的请求，将使用桶的默认加密配置进行加密。有关桶的加密配置的更多信息请参考设置桶的加密配置章节。 表1 SSE-OBS方式使用的头域 名称 描述 x-obs-server-side-encryption 使用该头域表示服务端加密是SSE-OBS方式。对象使用SSE-OBS方式加密。 类型：String 示例：x-obs-server-side-encryption：AES256

请求示例：在URL中携带签名并上传加密对象 PUT /destobject?AccessKeyId=UI3SN1SRUQE14OYBKTZB&Expires=1534152518&x-obs-server-side-encryption=AES256&Signature=chvmG7%2FDA%2FDCQmTRJu3xngldJpg%3D HTTP/1.1 User-Agent: curl/7.29.0 Host: examplebucket.obs.cn-north-4.myhuaweicloud.com Accept: */* Date: Wed, 06 Jun 2018 09:10:29 GMT

请求示例：使用默认密钥对上传的对象进行加密 PUT /encryp1 HTTP/1.1 User-Agent: curl/7.29.0 Host: examplebucket.obs.cn-north-4.myhuaweicloud.com Accept: */* Date: Wed, 06 Jun 2018 09:08:21 GMT Authorization: OBS H4IPJX0TQTHTHEBQQCEC:f3/7eS6MFbW3JO4+7I5AtyAQENU= x-obs-server-side-encryption:AES256 Content-Length: 5242 Expect: 100-continue [5242 Byte object contents]

请求示例：将普通对象拷贝为加密对象 PUT /destobject HTTP/1.1 User-Agent: curl/7.29.0 Host: examplebucket.obs.cn-north-4.myhuaweicloud.com x-obs-server-side-encryption:AES256 Accept: */* Date: Wed, 06 Jun 2018 09:10:29 GMT Authorization: OBS H4IPJX0TQTHTHEBQQCEC:SH3uTrElaGWarVI1uTq325kTVCI= x-obs-copy-source: /bucket/srcobject1