华为云用户手册

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开源增强特性

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的数据节点。

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）。

特性描述 MRS 联合 消息通知 服务( SMN )，采用主题订阅模型，提供一对多的消息订阅以及通知功能，能够实现一站式集成多种推送通知方式。 首先，作为主题拥有者，可以先创建一个主题，并对主题设置访问控制权限来决定哪些发布者和订阅者可以通过该主题进行交流。MRS将集群消息发送至您有权限发布消息的主题，然后所有订阅了该主题的订阅者（可以是手机短信、邮箱等）都将收到集群变更以及组件告警的消息。 图1 实现过程

特性简介 大数据集群运行过程中经常会进行如下操作： 大数据集群变更，比如扩容、缩容集群。 业务数据量突然变化，集群触发弹性伸缩。 相关业务结束，需要终止大数据集群等。 用户想要及时得知这些操作是否执行成功，以及当集群出现大数据服务不可用，或节点故障时，用户希望不用频繁登录集群查看，就可以及时地收到告警通知。MRS联合消息通知服务(SMN)，可以将以上信息主动地通知到用户的手机及邮箱，让维护更加省心省力。

集群内服务认证 在使用安全模式的MRS集群中，任意服务间的相互访问基于Kerberos安全架构方案。集群内某个服务（例如HDFS）在启动准备阶段的时候，会首先在Kerberos中获取该服务对应的服务名称sessionkey（即keytab，用于应用程序进行身份认证）。其他任意服务（例如YARN）需要访问HDFS并在HDFS中执行增、删、改、查数据的操作时，必须获取对应的TGT和ST，用于本次安全访问的认证。

应用开发认证 MRS各组件提供了应用开发接口，用于客户或者上层业务产品集群使用。在应用开发过程中，安全模式的集群提供了特定的应用开发认证接口，用于应用程序的安全认证与访问。例如hadoop-common api提供的UserGroupInformation类，该类提供了多个安全认证API接口： setConfiguration()主要是获取对应的配置，设置全局变量等参数。 loginUserFromKeytab()获取TGT接口。

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

MRS集群版本类型 MRS集群版本类型分为普通版与LTS版本，不同版本集群所包含的组件内容及特性略有不同，用户可根据自身业务需求进行选择。 普通版 功能说明 普通版支持集群基础操作如配置、管理和运维等，具体可以查看用户指南。 组件介绍 除共有组件外，普通版集群还支持Presto、Impala、Kudu、Sqoop等组件，可以根据不同集群版本选择不同的组件，具体各版本集群的组件详情可以参考MRS组件版本一览表和组件操作指南。 LTS版 功能说明 LTS版集群除支持集群基础操作外，还提供版本升级能力。如需使用该功能请联系智能数据专家服务。 组件介绍 除共有组件外，LTS版集群还支持HetuEngine、IoTDB等组件，可以根据不同集群版本选择不同的组件，具体各版本集群的组件详情可以参考MRS组件版本一览表和组件操作指南。

MRS集群版本选择建议 LTS版集群支持版本升级能力，如果您需要使用版本升级能力，您可以选择购买LTS版集群。 LTS版集群具备多可用区部署能力，可以实现集群可用区级别的容灾。如果您需要MRS集群具备更高的安全性能和容灾能力，您可以选择购买LTS版集群。 LTS版集群支持HetuEngine、IoTDB等组件，如果您需要使用相关组件，您可以选择购买LTS版集群。 由于已购买的LTS版集群无法切换为普通版，请根据需要选择购买。

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

Hudi支持两种表类型 Copy On Write 写时复制表也简称cow表，使用parquet文件存储数据，内部的更新操作需要通过重写原始parquet文件完成。 优点：读取时，只读取对应分区的一个数据文件即可，较为高效。 缺点：数据写入的时候，需要复制一个先前的副本再在其基础上生成新的数据文件，这个过程比较耗时。且由于耗时，读请求读取到的数据相对就会滞后。 Merge On Read 读时合并表也简称mor表，使用列格式parquet和行格式Avro两种方式混合存储数据。其中parquet格式文件用于存储基础数据，Avro格式文件（也可叫做log文件）用于存储增量数据。 优点：由于写入数据先写delta log，且delta log较小，所以写入成本较低。 缺点：需要定期合并整理compact，否则碎片文件较多。读取性能较差，因为需要将delta log和老数据文件合并。

Hudi支持三种视图，针对不同场景提供相应的读能力 Snapshot View 实时视图：该视图提供当前hudi表最新的快照数据，即一旦有最新的数据写入hudi表，通过该视图就可以查出刚写入的新数据。 cow表和mor均支持这种视图能力。 Incremental View 增量视图：该视图提供增量查询的能力，可以查询指定COMMIT之后的增量数据，可用于快速拉取增量数据。 cow表支持该种视图能力， mor表也可以支持该视图，但是一旦mor表完成compact操作其增量视图能力消失。 Read Optimized View 读优化视图：该视图只会提供最新版本的parquet文件中存储的数据。 该视图在cow表和mor表上表现不同： 对于cow表，该视图能力和实时视图能力是一样的（cow表只用parquet文件存数据）。 对于mor表，仅访问基本文件，提供给定文件片自上次执行compact操作以来的数据， 可简单理解为该视图只会提供mor表parquet文件存储的数据，log文件里面的数据将被忽略。 该视图数据并不一定是最新的，但是mor表一旦完成compact操作，增量log数据被合入到了base数据里面，这个时候该视图和实时视图能力一样。

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

StarRocks简介 StarRocks是一款高性能分析型 数据仓库 ，使用向量化、MPP架构、CBO、智能物化视图、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。 StarRocks既支持从各类实时和离线的数据源高效导入数据，也支持直接分析 数据湖 上各种格式的数据。 StarRocks兼容MySQL协议，可使用MySQL客户端和常用BI工具对接进行数据分析，同时StarRocks具备水平扩展、高可用、高可靠、易运维等特性，广泛应用于实时数仓、OLAP报表、数据湖分析等场景。 更多相关介绍请参见StarRocks。 该组件当前为公测阶段，若需使用需联系技术支持申请白名单开通。

StarRocks基本概念 在StarRocks中，数据都以表（Table）的形式进行逻辑上的描述。 StarRocks中的表由行和列构成，每行数据对应用户一条记录，每列数据具有相同的数据类型。所有数据行的列数相同，可以动态增删列。在StarRocks中，一张表的列可以分为维度列（也称为Key列）和指标列（也称为Value列），维度列用于分组和排序，指标列的值可以通过聚合函数sum、count、min、max、hll_union_agg和bitmap_union等累加起来。 列式存储 在StarRocks中，表数据按列存储。物理上，一列数据会经过分块编码、压缩等操作，然后持久化存储到非易失设备上。但在逻辑上，一列数据可以看成是由相同类型的元素构成的一个数组， 一行数据的所有列值在各自的数组中按照列顺序排列，即拥有相同的数组下标。数组下标是隐式的，不需要存储。表中所有的行按照维度列，做多重排序，排序后的位置就是该行的行号。 索引 StarRocks通过前缀索引 (Prefix Index) 和列级索引，能够快速找到目标行所在数据块的起始行号。 加速处理 StarRocks通过预先聚合、分区分桶、物化视图、列级索引等机制实现数据的加速处理。 数据模型 StarRocks支持四种数据模型，分别是明细模型（Duplicate Key Model）、聚合模型（Aggregate Key Model）、更新模型（Unique Key Model）和主键模型（Primary Key Model）。 这四种数据模型能够支持多种数据分析场景，例如 日志分析 、数据汇总分析、实时分析等。创建表时，您需要指定数据模型（Data Model），当数据导入至数据模型时，StarRocks会按照排序键对数据进行排序、处理和存储。四种数据模型介绍如下： 明细模型 明细模型是StarRocks默认的建表模型。如果在建表时未指定任何模型，默认创建明细类型的表。 聚合模型 建表时，支持定义排序键和指标列，并为指标列指定聚合函数。当多条数据具有相同的排序键时，指标列会进行聚合。在分析统计和汇总数据时，聚合模型能够减少查询时所需要处理的数据，提升查询效率。 更新模型 建表时，支持定义主键和指标列，查询时返回主键相同的一组数据中的最新数据。相对于明细模型，更新模型简化了数据导入流程，能够更好地支撑实时和频繁更新的场景。 主键模型 主键模型支持分别定义主键和排序键。数据导入至主键模型的表中时，先按照排序键排序后再存储。查询时返回主键相同的一组数据中的最新数据。相对于更新模型，主键模型在查询时不需要执行聚合操作，并且支持谓词和索引下推，能够在支持实时和频繁更新等场景的同时，提供高效查询。 数据分布 建表时，您可以通过设置合理的分区和分桶，实现数据均匀分布和查询性能提升。数据均匀分布是指数据按照一定规则划分为子集，并且均衡地分布在不同节点上。查询时能够有效裁剪数据扫描量，最大限度地利用集群的并发性能，从而提升查询性能。

StarRocks架构 StarRocks整体架构如下图所示，FE和BE节点可以水平无限扩展。 图1 StarRocks架构 表1 StarRocks节点及角色说明 名称 说明 Client Application StarRocks兼容MySQL协议，支持标准SQL语法，用户可通过各类MySQL客户端和常用BI工具对接。 FE StarRocks的前端节点，主要负责管理元数据、管理客户端连接、进行查询规划、查询调度等工作。 BE StarRocks的后端节点，主要负责数据存储和SQL计算等工作。 Leader Leader从Follower中自动选出，FE Leader提供元数据读写服务，Follower和Observer只有读取权限，无写入权限。 Follower Follower只有元数据读取权限，无写入权限，Follower参与Leader选举。 Observer Observer主要用于扩展集群的查询并发能力，可选部署。Observer不参与选主，不会增加集群的选主压力。

组件及版本号信息（已下线版本） 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

更新内容 服务模块 主要变更点 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

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汇报运行状况。

Yarn和ZooKeeper的关系 ZooKeeper与Yarn的关系如图3所示。 图3 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相关信息，恢复数据。

元数据管理 当创建MRS集群选择部署Hive和Ranger组件时，MRS提供多种元数据存储方式，您可以根据自身需要进行选择： 本地元数据：元数据存储于集群内的本地 GaussDB 中，当集群删除时元数据同时被删除，如需保存元数据，需提前前往数据库手动保存元数据。 外置数据连接：MRS集群创建完成后，可选择关联与当前集群同一虚拟私有云和子网的RDS服务中的PostgresDB或MySQL数据库或云数据库GaussDB(for MySQL)、也可以选择与当前集群同一虚拟私有云和子网的LakeFormation实例，元数据将存储于关联的数据库或LakeFormation实例中，不会随当前集群的删除而删除，多个MRS集群可共享同一份元数据。 Hive组件可选元数据存储方式功能在MRS 1.9.x及之后版本支持。 父主题： 产品功能

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创建的目录下。

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汇报运行状况。

ClickHouse应用场景 ClickHouse是Click Stream + Data WareHouse的缩写，起初应用于一款Web流量分析工具，基于页面的点击事件流，面向数据仓库进行OLAP分析。当前ClickHouse被广泛的应用于互联网广告、App和Web流量、电信、金融、物联网等众多领域，非常适用于商业智能化应用场景，在全球有大量的应用和实践，具体请参考：https://clickhouse.tech/docs/en/introduction/adopters/。

ClickHouse简介 ClickHouse是一款开源的面向联机分析处理的列式数据库，其独立于Hadoop大数据体系，最核心的特点是压缩率和极速查询性能。同时，ClickHouse支持SQL查询，且查询性能好，特别是基于大宽表的聚合分析查询性能非常优异，比其他分析型数据库速度快一个数量级。 ClickHouse核心的功能特性介绍如下： 完备的DBMS功能 ClickHouse拥有完备的DBMS数据库管理系统（Database Management System），基本功能如下所示。 DDL （数据定义语言）：可以动态地创建、修改或删除数据库、表和视图，而无须重启服务。 DML（数据操作语言）：可以动态查询、插入、修改或删除数据。 权限控制：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性。 数据备份与恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求。 分布式管理：提供集群模式，能够自动管理多个数据库节点。 列式存储与数据压缩 ClickHouse是一款使用列式存储的数据库，数据按列进行组织，属于同一列的数据会被保存在一起，列与列之间也会由不同的文件分别保存。 在执行数据查询时，列式存储可以减少数据扫描范围和数据传输时的大小，提高了数据查询的效率。 例如在传统的行式数据库系统中，数据按如下表1顺序存储： 表1 行式数据库 row ID Flag Name Event Time 0 12345678901 0 name1 1 2020/1/11 15:19 1 32345678901 1 name2 1 2020/5/12 18:10 2 42345678901 1 name3 1 2020/6/13 17:38 N … … … … … 行式数据库中处于同一行中的数据总是被物理的存储在一起，而在列式数据库系统中，数据按如下表2顺序存储： 表2 列式数据库 row: 0 1 2 N ID: 12345678901 32345678901 42345678901 … Flag: 0 1 1 … Name: name1 name2 name3 … Event: 1 1 1 … Time: 2020/1/11 15:19 2020/5/12 18:10 2020/6/13 17:38 … 该示例中只展示了数据在列式数据库中数据的排列方式。对于存储而言，列式数据库总是将同一列的数据存储在一起，不同列的数据也总是分开存储，列式数据库更适合于OLAP（Online Analytical Processing）场景。 向量化执行引擎 ClickHouse利用CPU的SIMD指令实现了向量化执行。SIMD的全称是Single Instruction Multiple Data，即用单条指令操作多条数据，通过数据并行以提高性能的一种实现方式 ( 其他的还有指令级并行和线程级并行 )，它的原理是在CPU寄存器层面实现数据的并行操作。 关系模型与SQL查询 ClickHouse完全使用SQL作为查询语言，提供了标准协议的SQL查询接口，使得现有的第三方分析可视化系统可以轻松与它集成对接。 同时ClickHouse使用了关系模型，所以将构建在传统关系型数据库或数据仓库之上的系统迁移到ClickHouse的成本会变得更低。 数据分片与分布式查询 ClickHouse集群由1到多个分片组成，而每个分片则对应了ClickHouse的1个服务节点。分片的数量上限取决于节点数量（1个分片只能对应1个服务节点）。 ClickHouse提供了本地表 （Local Table）与分布式表 （Distributed Table）的概念。一张本地表等同于一份数据的分片。而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。