MapReduce服务上线以来，我们在用户的意见和建议中不断地进行改进和优化。如今MRS已来到2.0时代。MRS 2.0对大数据引擎做了全面升级，并推出实时流与批分析一体的混合集群，支持计算存储分离的统一存储方案，为客户提供低成本、高性能、更易用的全新一站式大数据平台服务。
下面就由小编给大家详细介绍下MapReduce 2.0的新特性。
MRS 2.0新特性一览表
一、MRS 2.0 vs 1.x ——Hadoop篇：
冷数据占存储空间更小
对于冷数据的存储，我们一直希望能够减少其所占存储空间。纠删码作为给HDFS拓展的新特性，是一种与副本相比更节省存储空间的数据持久化方法。
传统HDFS数据只采用冗余的方式来获得数据可靠性(默认冗余200%)，带来了存储成本的提升。该技术在HDFS实现了纠删码使得数据冗余减少到50%，且可靠性更高(使用Reed-Solomon(10,4)编码的数据可以允许4个节点失效)，并引入条带化的块存储结构，最大化的利用现代集群单节点多磁盘的能力，使得数据写入性能在引入编码过程后，仍和原来多副本冗余的性能接近，更值得一提的是，应用层无需改动写入数据的实现方式即可获得这部分提升。
使用场景上，纠删码编码的数据在读写数据时，会耗费更多的CPU，在CPU资源富裕的大数据应用场景，能给客户带来更大的成本空间。
Yarn的Opportunistic Containers
过去的YARN集群，资源利用率较低，主要有两个因素，一是延迟反馈，YARN依赖心跳管理集群资源，空闲资源能够再次被申请，需要多次心跳交互才能感知到；二是YARN应用声明的资源比实际使用量大，导致利用率低。
Opportunistic Containers相对于之前的Guaranteed Container来说，优先级更低，会被Guaranteed Container抢占，但其优势在于让container请求在YARN的NodeManager节点排队(即使资源不足)，一旦有空闲资源，可以立即开始执行，消除了延迟反馈，提升了Container启动速度，从而提高了集群利用率。
新机制实现Yarn的高扩展
新引入Yarn federation机制：将一个超大的集群分解成多个子集群的方式来实现Yarn的高扩展性，每个子集群有自己的ResourceManager和NodeManager，Yarn federation将这些子集群拼接在一起使他们成为一个大集群。在Yarn federation环境中，Application看到的是一个超大的集群，并且能够在整个集群的任何节点执行Task。
支持自定义资源模型
从MRS 2.0开始，Yarn支持自定义资源模型(support user-defined countable resource types)，不仅仅支持CPU和内存，比如集群管理员可以自定义诸如GPU，软件许可证等等资源，Yarn任务可以根据这些资源的可用性进行调度。
除此之外，华为云MRS服务2.0全面兼容Hadoop 3版本，提供了DataNode节点内多磁盘均衡工具，来处理添加或替换磁盘时可能导致的DataNode内部多块磁盘存储的数据不均衡的问题。
二、MRS 2.0 vs 1.x ——Hive篇：
新执行引擎Tez
MRS 2.0上的Hive，使用新的执行引擎Tez代替原先的MapReduce，性能有了显著提升。
Tez可以将多个有依赖的作业转换为一个作业(这样只需写一次HDFS，且中间节点较少)，从而大大提升DAG作业的性能。下面的图表阐述了这个过程：
左图表展示的流程包含多个 MR 任务，每个任务都将中间结果存储到 HDFS 上(前一个步骤中的 reducer 为下一个步骤中的 mapper 提供数据)。右图表展示了使用 Tez 时的流程，仅在一个任务中就能完成同样的处理过程，任务之间不需要访问HDFS。
使用 Tez 完成Hive 查询的好处包括：
• 它为你提供了全面的 DAG 支持，同时会自动地在集群上完成大量的工作，因而它能够充分利用集群的并行能力，在多个 MR 任务之间不需要从 HDFS 上读 / 写数据，通过一个单独的 Tez 任务就能完成所有的计算。
• 它提供了会话和可重用的容器，因此延迟低，能够尽可能地避免重组。
• 兼容原先MR任务。
Tez提供了的全新的UI界面，可以更加方便的查看每个任务的执行情况。
提供了HPLSQL
MRS 2.0中的Hive支持存储过程(HPLSQL)。使用存储过程能够更加方便的执行具有关联性的HQL语句集，通过定义变量和传参，灵活地调用方法获取事务的执行结果，比之前反复执行多条hql语句效率更高。通过定义连接，可以在一个HPLSQL中访问不同的关系型数据库。
下面是一个简单的HPLSQL例子：
CREATE FUNCTION hello(text STRING)
RETURNS STRING
BEGIN
RETURN 'Hello, ' || text || '!';
END;
FOR item IN (
SELECT s1,s2 FROM test limit 10
)
LOOP
PRINT item.s1 || '|' || item.s2 || '|' || hello(item.s1);
END LOOP;
CREATE FUNCTION hello(text STRING)
RETURNS STRING
BEGIN
RETURN 'Hello, ' || text || '!';
END;
FOR item IN (
SELECT s1,s2 FROM test limit 10
)
LOOP
PRINT item.s1 || '|' || item.s2 || '|' || hello(item.s1);
END LOOP;
HiveWebUI使运维更加简单
HiveServer如今提供的web界面，可以方便查看正在运行的SQL有哪些，执行了多长时间等，可以说是运维同学的一大福音。
新版本的Hive还充分利用现代CPU提供的SIMD，AVX2等指令集，来提高CPU利用效率。例外，CBO这种基于代价的查询优化，对于多表join性能优化效果显著。使用新版本后，根据不同场景，Hive的性能提升了不止50%呢。
三、MRS 2.0 vs 1.x ——Spark篇：
真正毫秒级低延迟处理
无论是最早的Spark Streaming，还是Spark 2.0中推出的Structured Streaming，均采用定时触发，生成微批的方式实现流式处理。
Spark Streaming的处理逻辑如下：当新的数据到达时，Driver需要等到定时器下一个触发的时刻，将这段时间内到达的所有新数据生成一个新的批次，并将其加到一个队列中。之后，会由Driver的另一个线程获取队列中的批次，解析处理后生成Task并分发给各个Executor执行。显然，等待定时器触发，以及分发Task到Executor执行，都带来了额外的时间开销Structured Streaming处理逻辑有所不同，但存在相同的问题。
MRS 2.0中包含的Spark 2.3版本，在Structured Streaming中新加入了Continuous Processing模式，正是解决了上述问题。使用该模式时，会在各个Executor上启动一组长时间运行的任务，而不再是定时触发。数据一旦到达，就会立刻被计算处理，从而避免了等待定时器下一次触发的额外时间消耗，以及生成Task并分发到Executor的额外时间消耗，实现了真正毫秒级的低延迟处理，最小延迟从原先的100毫秒左右，降低到现在的3-5毫秒左右。
支持流和流的join操作
在MRS 2.0之前，Structured Streaming仅支持流和静态数据集之间的join操作，MRS 2.0中包含了Spark 2.3版本，加入了期待已久的流和流的join操作。流和流的join操作，支持内连接和外连接，可用在大量的实时场景中，例如比较常见的点击日志流的join操作，现在就可以通过几行代码轻松实现。
Structured Streaming之前在Spark 2.0版本中推出，用来替代原先的Spark Streaming。Structured Streaming基于Spark SQL引擎，使用户能够使用与批处理一样的DataSet API来构建流式应用，并能享受Spark SQL引擎带来的性能提升，另外，Structured Streaming还提供了exactly-once的语义支持，因此推荐大家使用Structured Streaming替代原有的Spark Streaming程序。
PySpark性能优化
基于Apache Arrow和Pandas库，实现了pandas_udf。利用pandas对数据进行矢量化的优化，并通过Arrow降低Python与Spark的通信开销。使用pandas_udf替代pyspark中原来的udf对数据进行处理，可以减少60%-90%的处理时长(受具体操作影响)。
MLLib优化提升
在Spark 2.3中带来了许多MLLib方面的提升，例如，支持Structured Streaming中使用MLLib的模型和pipeline；支持创建图像数据的DataFrame；使用Python编写自定义机器学习算法的API简化等。
四、MRS 2.0 vs 1.x ——HBase篇：
HBase on OBS: 数据与MRS集群解耦
HBase2支持为WAL和HFile设置存储在不同类型的文件系统，MRS 2.0中的HBase2.1支持设置WAL on HDFS和HFile on OBS，实现存储和计算分离的目的，并有以下几个优点：
• 计算存储分离可以根据需要对RegionServer进行弹性扩缩容，避免计算和存储绑定造成的资源浪费；
• 华为云OBS的单价低于云盘和直通盘，在大容量存储需求下极大的降低存储成本；
• OBS支持跨AZ和跨Region的数据复制，极大提高数据的可靠性。
此外，相比开源HBase2，MRS HBase2.1对on OBS场景做了更多的可靠性优化：
• 创建集群支持on OBS的模式，简化操作步骤；
• 简化Region Location计算的算法，不再对数据本地性作要求；
• 数据恢复过程中的WAL Split阶段统一在HDFS中完成，恢复时长同on HDFS。
新的多租户方案
RegionServer Group作为新的多租户方案，可以将多个RegionServer进行分组，组成不同的RGS。不同的表可以分布在不同的RGS中，不同RGS中的表不会互相受到影响，以这种从RegionSever中物理隔离的方式，从而实现多租户的方案。
优化region状态转换
AssignmentManager V2基于Procedure V2实现，能够更快速的分配Region，维护的region状态机存储不再依赖于ZooKeeper，移除了region在zookeeper中的状态信息，只在HMaster的内存和Meta表中维护region状态，极大的解决了region状态转换过程中引起的问题。
优化HFile实现方式
MemStore中的数据达到一定大小以后，先Flush到内存中的一个不可改写的Segment，内存中的多个Segments可以预先合并，达到一定的大小以后，才Flush成HDFS中的HFile文件，这样做能够有效降低Compaction所带来的写IO放大问题。
此外，HBASE 2.x更改了数据的读写方式，会直接在二级缓存中进行读写，采用堆外内存Offheap替代之前的堆内内存，减少对Heap内存的使用，有效减少GC压力。HBase2.x 开始默认使用NettyRpcServer替代HBase原生的RPC server，大大提升了HBaseRPC的吞吐能力，降低了延迟。
五、MRS 2.0 vs 1.x ——Kafka篇：
支持Kafka MirrorMaker
MirrorMaker用于Kafka集群之间的流数据同步，可以把Kafka集群中的消息复制到另一个Kafka集群中，这在测试环境引流的时候，或者需要把多个不同的Kafka集群的消息合并在一个大集群时非常有用。Kafka mirrormaker通过Kafka集群间的数据镜像能力，实现跨kafka集群的消息实时同步备份，可用作在线kafka集群的数据容灾场景和kafka集群的数据在线迁移场景，提高数据迁移的吞吐量和容错性。
六、MRS 2.0 vs 1.x ——集群管理篇：
混合集群
原先MRS只支持独立的分析集群和流式集群，对于一些小型数据场景及测试场景，既要部署分析和流式组件，就需要部署两套集群。
于是MRS 2.0引入了“混合集群”概念，在同一集群中用户就可以同时部署分析和流式组件，节省了管理节点的成本，并且可以大大减少不同集群的通信成本，是小型集群和测试场景大大的福音。
混合计费模式的弹性伸缩
企业生产环境长期使用大数据集群，为节省成本往往会选择价格更优惠的包周期预付费购买模式。但大数据的计算资源率随着业务时段存在峰谷变化，如果包年包月购买的资源按照峰值就会存在大量时间段的浪费，按照谷值购买又会存在忙时资源不足影响业务。因此MRS 2.0提供了混合计费的弹性伸缩能力，可以在包周期集群上配置弹性策略(按时间段或者业务指标进行集群节点弹性伸缩)，弹性部分节点按需收费。客户可以根据业务情况配置自动弹性伸缩策略，MRS服务会在繁忙时申请额外资源，空闲时释放多余资源，帮助客户降低成本，聚焦核心业务。
Manager的监控展示的优化
MRS 2.0的Manager界面默认显示历史监控数据，用户可以选择实时或者任意区间查看监控数据查看监控数据更便捷。
磁盘使用率、内存使用率等指标细化显示，主机监控更细致，星型符号标注主备管理节点，用户体验更友好。
MRS 2.0新增了这么多特性，进一步实现了完整统一的计算系统，为大家提供7*24小时不间断服务的系统级平台。同时具有强大的包容的生态圈，并支持计算存储分离的功能，大家从各个平台迁移过来都非常方便。开源中的所有新特性，都可以来MRS 2.0上抢先一步体验到。
扫码了解MRS更多详情~
328
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
