快来看，大数据两地三中心的容灾也可以如此省心！

关注

发布于: 3 小时前

摘要：随着数据湖技术从离线向实时的发展，数据湖在业务已逐渐从辅助决策向实时决策，实时干预甚至提前预防的方向发展，同时，随着国家把数据作为第五种生产要素，数据据价值在逐步提升，这样对海量数据湖的可靠性提出了新的要求。

本文分享自华为云社区《华为云FusionInsightMRS容灾：大数据两地三中心的容灾也可以如此省心》，作者： Sailing27 。

背景介绍

随着数据湖技术从离线向实时的发展，数据湖在业务已逐渐从辅助决策向实时决策，实时干预甚至提前预防的方向发展，同时，随着国家把数据作为第五种生产要素，数据据价值在逐步提升，这样对海量数据湖的可靠性提出了新的要求。

首先，数据湖作为企业全量数据存储的地方，对数据的安全性有着至关重要的作用，如何保证湖内的数据在任何情况下，都不要出现丢失的情况，是越来越多的企业在思考的问题，同时，随着数据湖逐步补齐交互式查询，实时分析等能力，大量的分析师正逐步将日常的数据分析工作转移到数据湖中，在这种背景下，一旦出现数据湖无法对外提供服务或者是数据丢失，将会对企业产生重大影响。但另一方面，数据中心级的故障在全球不断出现，火灾、水灾等各种新闻不断涌现。同时，日常运维过程中的误操作，也是时时刻刻悬在头上的一把利剑，这种情况可能比机房起火更常见，但对数据的影响却也是致命的。

每一次有新闻报道这方面的事故时，相信很多大数据平台的运维人员都是心头一紧，如何确保数据湖系统的绝对可靠，成为越来越多企业关心的问题。

对于一个数据湖平台，常见的故障包括：

数据湖一般作为大规模分布式系统，对以小范围硬件故障类一般都已在系统架构中有比较完善的考虑，本文不做详细描述。下面主要介绍的是重大灾难以及误操作场景下，MRS 的高可用方案。

MRS 灾备方案介绍

华为云 MRS 作为全球领先的数据湖平台，在可靠性方面已有比较完整的规划，为应用不同的故障场景，提供了以下三种方案：

数据备份：采用 OBS 或者备 MRS 集群来作为备份存储，将关键数据备份到 OBS/HDFS 中。

单集群跨 AZ：采用多 AZ 方式建设单集群，通过副本放置策略（BPP）和 YARN 的任务调度机制的优化，确保单 AZ 故障时数据不丢失，关键业务不中断。

异地主备容灾：分别建设主、备两个 MRS 集群，配置主备容灾关系，主集群数据周期/实时自动同步到备集群上。主集群故障时，将业务倒换到备集群上，确保业务快速恢复。

下面将对以上三种方案进行详细描述：

MRS 备份方案介绍

备份方案，作为一种最基础的数据保护方案，具有成本低，方案简单的特点，特别是相比其它方案，在数据误删保护方面，具有独特的优势。但是，大数据业务的备份，也是十分有挑战的一项工作，主要体现在：

由于大数据平台的组件多，各类组件的备份方案也不统一，实施起来较为复杂，特别是有些场景，还要考虑组件间的数据一致性问题；

数据体量巨大，全量备份成本高，正因如此，很多大数据项目都没有采用备份方案。

华为云原生数据湖 MRS，作为企业级的数据湖平台，具有简单易用的备份管理功能，支持对接多种备份存储方案。整体备份能力如下：

在组件上，支持了 Manger、DBService、HDFS、YARN、HBase、Hive、ES、Redist、ClickHouse、IotDB 等所有涉及数据的组件。同时 MRS 支持图形化的备份配置界面，用户只需要按需选择所需要备份的数据，设置好备份周期，系统将会自动周期进行备份，且会保证组件间数据关联的一致性，同时也支持手工一次性备份。

备份存储，MRS 支持将数据备份到备 MRS 集群或 OBS 上，对于有条件采用 OBS 备份的场景，可优先采用 OBS 备份，对于无 OBS 的场景，可以采用备 MRS 集群进行备份，在此场景下，考虑到成本，备集群 HDFS 可以采用两副本。

以下是备份任务的主要管理界面：

创建备份任务时的策略选择：

备份任务管理：

总结：备份方案，由于其在应对数据丢失方面的优势，一般会作为基础的数据保护能力，特别是其全量数据的保存能力，可以应对数据误删除的场景。

MRS 单集群跨 AZ 方案介绍

备份方案虽然可以解决数据可靠性的问题，但无法解决业务可靠性的问题，如果发生机房机的故障，虽然数据可以从备份系统中恢复，但这时的恢复周期会非常长，针对机房级的故障，如何同时解决业务和数据的可靠性，MRS 提供了单集群跨 AZ 的方案，此方案的核心是利用大数据的分布式能力，将一个 MRS 集群部署到多个 AZ 中，对于存储层的 HDFS，自动识别多 AZ，并将多副本分布在多 AZ 中，确保任一 AZ 故障，都不会导致数据丢失。对于计算层，支持同一个队列跨 AZ 部署，并在一个 AZ 故障时，自动将任务在另一个 AZ 中重试，实现应用层无感知的 AZ 迁移。

MRS 单集群跨 AZ 的部署架构如下：

如上图所示，同一个 MRS 集群会同时部署到 3AZ 中，对于存储层，通过块放置策略（BPP)对 AZ 的感知，将同一数据的 3 个副本，分别放置到 3 个 AZ 中，确保任一 AZ 故障，不会造成数据丢失，对于计算，通过将租户队列配置到多个 AZ 中，实现租户的应用，在一个 AZ 故障以后，仍然可以在另外一个 AZ 中执行。

在跨 AZ 的的场景下，还有一个比较大的挑战是 AZ 间的带宽，AZ 间的带宽一般会比较有限，如何降低跨 AZ 部署的时候，对 AZ 间带宽的要求是一个不可忽视的问题，MRS 的跨 AZ 方案中，为了降低对跨 AZ 带宽的诉求，MRS 从以下三个方面，对跨 AZ 的流量进行了优化：

应用内的 Shuffle 流量：基于自研的 Superior 调度器，实现了正常场景下，计算任务不跨 AZ，这样，将作务运行过程中的 Shuffle 流量全部控制在一个 AZ 内，减少了跨 AZ 的流量消耗。

业务数据读取流量：对于业务数据的读请求，通过基于数据本地化的调度，实现了数据从本 AZ 读取，将跨 AZ 的读流量降到接近于零。

业务数据写流量：HDFS 上的写流量，会有大量的临时文件、日志类的写入流量，MRS 实现了按目录配置是否需要跨 AZ，实现了只针对真正的业务数据按跨 AZ 的策略进行副本放置。消减掉了临时文件、日志类的无用的跨 AZ 流量。

如下图所示，App1 运行于跨 AZ 队列 Queue1 上，虽然此队列关联了 AZ1 和 AZ2 的计算资源，但 MRS 自研的 Superior 调度器通过 AZ 感知调度，不会将 App1 的计算任务同时分发到两个 AZ 上同时执行，而是仅在其中一个 AZ 上执行

而当 AZ1 故障时，Superior 会自动将此应用在 AZ2 上重跑，此时应用看到的任务状态并不会中断，也不需要进行失败重试的改造，实现了对应用的完全透明。

同时可以看出，无论 App 运行在哪个 AZ 上，对存储层的访问，都可以实现在本 AZ 内的闭环，并不需要跨 AZ 访问，保证性能的同时，也降低了对 AZ 间带宽的要求。

考虑到某些场景，没有足够的 3AZ 资源可用，MRS 也支持 2+1 的部署模式，即：两个主 AZ 加一个仲裁 AZ，仲裁 AZ 不用于实际的数据存储和业务计算，只需要几个工部署需要 3AZ 仲裁的组件，主要包括 Zookeeper、HDFS JournalNode。

针对某此 AZ 间资源不均的场景，MRS 也提供了灵活的配置能力，可以按需配置需要保护的业务（租户）和数据（表/目录），只要最小的 AZ 中的资源，满足需要跨 AZ 保护的业务和数据的资耗的诉求即可。不需要强制所有 AZ 的的资源完全一样。

MRS 提供了简单易用的跨 AZ 部署配置界面：

集群开启跨 AZ 能力：

选择每个 AZ 的节点：

总结：

通过在计算、存储、集群管理方面的设计，业务可以方便灵活地部署出跨 AZ 的 MRS 集群，在业务看来，跨 AZ 的集群仍然是一个单集群，且在平台内部实现了 AZ 故障时的应用重试，应用层也不用进行失败重试类的改造，真正实现了对应用的完全透明的高可用能力。

MRS 主备容灾方案介绍

虽然跨 AZ 的方案，可以解决机房级的故障，但由于单集群跨 AZ 方案对网络时延的要求，AZ 间的距离一般只能在一个城市之内。为了应对城市级的故障场景，需要采用 MRS 主备容灾的方案，实现真正的高可用，这里需要说明的是，主备容灾方案，是一个端到端的方案，不是一个大数据平台层单方面能实现的，因此很多时候需要结合数据源、应用层的架构进行完整的设计，本文主要介绍大数据平台层的主备容灾方案。大数据平台层的主备复制方案如下图：