设计

大数据在云上的部署架构设计请参考大数据架构设计，本节不再赘述。这里重点介绍数据迁移方案和任务迁移方案的设计。

设计数据迁移方案

大数据的数据迁移涉及到3类数据，如下表：

表1 大数据迁移的三类数据
分类	说明
元数据	Hive元数据或外置元数据
存量数据	历史数据，短期内不会变化
增量数据	数据定期更新

这3类数据的迁移方法如下：

表2 大数据三类数据的迁移方式
数据分类		迁移方法
元数据	HIVE元数据	导出源端HIVE元数据，导入华为云MRS-Hive
元数据	外置元数据MySQL	使用华为云DRS服务同步MySQL中的元数据到云上RDS
存量数据	Hive历史数据存放在HDFS	使用华为云CDM工具迁移所有历史数据到华为云MRS服务或华为云OBS存储（存算分离场景）
存量数据	Hbase历史数据	使用华为云CDM工具迁移所有历史数据到华为云MRS服务使用Hbase快照方式，迁移Hbase数据到华为云MRS服务
增量数据	Hive增量数据	根据源端元数据查询每日变化数据，识别出需要迁移的数据目录，使用华为云CDM工具迁移增量数据上云
增量数据	Hbase增量数据	使用华为云CDM工具迁移所有增量数据(根据时间戳)到华为云MRS服务

企业可以根据不同的数据类型选择合适的迁移方案，CDM是数据迁移阶段主要使用的工具。大数据的数据迁移通常按照如下顺序执行：

图1 大数据的数据迁移顺序

元数据迁移
首先，进行元数据的迁移。元数据是描述数据的数据，包括数据结构、数据定义、数据关系等信息。在元数据迁移阶段，需要将原始数据的元数据信息导出，并在目标系统中重新建立或导入元数据，以确保目标系统能够正确理解和解析数据。

历史数据迁移
在元数据迁移完成之后，进行历史数据的迁移。历史数据是指在过去某个时间段内生成的数据，它们需要被迁移到目标系统中进行后续的分析和处理。历史数据迁移可能涉及将数据从原始存储位置导出，并按照预定的规则和格式加载到目标系统中。

增量数据迁移
当历史数据迁移完成后，进行增量数据的迁移。增量数据是在历史数据迁移之后生成的新数据，需要实时或定期迁移到目标系统中。增量数据迁移通常通过数据同步或数据传输的方式进行，确保新数据能够及时和准确地被目标系统所使用。

设计数据校验标准

在大数据迁移过程中，并不是所有数据类型都要求100%的数据一致，需要根据业务需求和数据的重要性来确定数据一致性的要求，并采取相应的数据迁移策略和技术手段来保证数据的正确性和完整性。

从数据类型来看：对于包含事务性数据（例如银行交易记录），通常需要确保迁移过程中的数据一致性。这意味着在迁移完成后，源数据和目标数据需要精确匹配，以避免数据不一致引发的问题。而对于非事务性数据，一些微小的数据差异可能是可以接受的。
从数据重要性来看：关键业务数据对于迁移过程中的数据一致性要求更高，这些数据可能包含了企业核心业务的重要信息，因此在迁移过程中需要确保数据的准确性和完整性。而对于非关键性业务数据，一些小的数据差异可能可以被容忍。

因此在数据迁移实施前，企业需要确定不同数据的校验标准，可以参考如下模板：

表3 数据类型和校验标准
数据类型	校验标准	详细表名
X类数据	100%一致	A表、B表、C表…
Y类数据	误差小于0.01%	D表、E表、F表…
…	自定义标准	…

设计任务迁移方案

大数据的任务包括三类：Jar类任务、SQL类任务、脚本类任务（Python、Shell），可以根据不同的任务类型选择合适的迁移方案。

表4 任务类型和迁移方案
任务类型	迁移方案
JAR类任务	所有Jar类任务都需要根据云上集群版本重新编译jar包，适配云上环境
SQL类任务	同版本： Hive大版本相同，可平迁SQL类任务不同版本：Hive大版本不同，先平迁SQL类任务，然后根据版本语法变动，微调SQL语句以适配云上版本语法
脚本类任务（Python、Shell）	同调度平台：平迁脚本类任务不同调度平台：平迁脚本类任务，根据云上调度平台，对脚本进行适配改造，以适应新的调度平台运行环境

大数据任务迁移通常按照如下顺序执行：

图2 大数据的任务迁移顺序

历史作业全量迁移
首先，将历史作业的数据和相关代码迁移至新的大数据平台。这包括将数据从原来的存储系统导出，并重新加载到新的存储系统。同时，将原有的作业脚本和相关配置文件进行调整和迁移，以适应新的计算环境。

作业调测
在全量迁移完成后，对已迁移的历史作业进行调测和验证。这包括运行作业并检查输出结果是否符合预期，以及验证作业执行过程中的性能和稳定性。如果发现问题或异常，需要进行适当的调整和修复。

定期同步增量作业
在历史作业成功迁移并通过调测后，开始进行增量作业的迁移和同步。增量作业是指在迁移过程中新增的、需要定期运行的作业。

作业双跑
在增量作业迁移和同步成功后，进行作业双跑。作业双跑是指在新的大数据平台上同时运行原有系统和新系统的作业，以验证新系统的结果和原有系统的一致性。这可以通过比较作业输出、日志和指标等来判断两个系统的结果是否一致。
应用割接
最后，作业双跑一段时间没有问题后，就可以进行大数据应用割接，业务全部切换到新大数据平台。

设计大数据双跑方案
双跑方案是一种常见的大数据迁移策略，通过双平台同时运行，持续验证数据和任务，双跑运行一段时间稳定以后，再将业务切换到新的大数据平台。如下图：
图3 大数据双跑方案

双跑方案的设计思路如下：
1. 数据和任务迁移
  在数据源接入前，先进行数据和任务的迁移，包括将历史数据从原平台迁移到新的大数据平台，并迁移相关的作业代码、脚本和配置文件等。迁移工具和方法根据具体需求选择，例如使用离线数据传输工具、大数据迁移工具CDM等。
2. 数据源接入
  将目标大数据集群接入与原大数据集群相同的数据源。这确保了源数据的一致性。可以使用数据同步工具、ETL工具或自定义脚本等方式实现数据源的连接和数据同步。离线计算任务的数据源可以使用数据同步工具CDM、ETL工具或自定义脚本实现数据接入；对于实时计算任务的数据源，可以使用Kafka MirrorMaker、Nginx流量镜像配置等方式，将实时数据上报到双跑的两个平台。
3. 双平台同时运行
  目标大数据集群、任务调度平台与原大数据集群、任务调度平台同时运行一段时间。在这段时间内，两个平台会并行处理任务，并产生相应的结果。
4. 运行稳定性验证
  在双平台同时运行期间，需要对目标大数据平台任务执行的稳定性、数据一致性进行持续的观察和验证。这包括监测任务的执行情况、检查任务日志和结果的一致性等。如果发现任何问题或异常情况，需要及时处理和修复。
5. 业务正式切换
  在确认目标大数据集群和任务调度平台的运行稳定性以及数据和任务迁移的完整性和准确性后，可以进行业务的正式切换，这包括将业务流量和作业任务切换到目标大数据平台上，并停止原大数据集群和任务调度平台。