Power Up！MRS 2.0 更简单易用(3)

  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引入了“混合集群”概念，在同一集群中用户就可以同时部署分析和流式组件，节省了管理节点的成本，并且可以大大减少不同集群的通信成本，是小型集群和测试场景大大的福音。