Cloudera CDH迁移到 华为MRS使用场景分析与思考，是国内大数据行业的踌躇不前的原因？

Cloudera CDH迁移到 华为MRS使用场景分析与思考，是国内大数据行业的踌躇不前的原因？建议由CDH迁移到CMP 7.13 平台（类Cloudera CDP，如华为鲲鹏 ARM 版）可以做到无缝切换平缓迁移

从 Cloudera CDH（Cloudera’s Distribution Including Apache Hadoop）迁移到华为云 MRS（MapReduce Service）时，虽然整体架构相似，但由于组件版本差异、存储模型变更、安全体系重构、生态工具替换等因素，某些特定场景需要特别关注和提前规划。以下是必须重点注意的典型场景及应对建议：

---

1. 重度依赖 Impala 的交互式查询场景

• 风险：MRS 默认不提供 Impala，若业务强依赖其低延迟、高并发能力，迁移后性能可能大幅下降。
• 应对建议：

• 评估是否可用 Spark SQL + 自适应执行 + 向量化引擎 替代；

• 对高频点查场景，考虑引入 ClickHouse / Doris / StarRocks 等 MPP 引擎（需额外部署）；

• 重构 SQL：避免复杂嵌套、启用分区裁剪、预聚合宽表。

---

2. 使用 Sentry 做细粒度权限控制的多租户环境

• 风险：CDH 使用 Sentry，MRS 使用 Ranger，两者策略模型不兼容，直接迁移会导致权限丢失或越权。
• 应对建议：

• 提前导出所有用户/组 → 角色 → 数据库/表/列 的权限映射关系；

• 在 MRS Ranger 中手动重建等效策略，注意大小写敏感（MRS 默认小写）；

• 测试关键用户的数据访问边界，防止数据泄露或拒绝访问。

---

3. Hive 表包含复杂 SerDe、UDF 或自定义 InputFormat

• 风险：CDH 特有的 SerDe（如 com.cloudera.hive.serde.JSONSerDe）在 MRS 中不存在；自研 UDF 依赖 CDH 特定 JAR 包。
• 应对建议：

• 将 SerDe 替换为开源标准实现（如 org.apache.hive.hcatalog.data.JsonSerDe）；

• 重新编译 UDF，确保兼容 MRS 的 Hive/Spark 版本（如 Hive 3.x）；

• 在 MRS 中通过 ADD JAR 或资源管理上传 UDF JAR，并测试功能。

---

4. 元数据存储路径从 HDFS 迁移至 OBS

• 风险：OBS 是对象存储，不支持 HDFS 的 rename、append 等语义，可能导致建表失败或写入异常。
• 应对建议：

• 所有 Hive 表的 LOCATION 必须指向 OBS 并行文件系统路径（如 obs://bucket/path）；

• 元数据迁移时勾选 “强制建表”，绕过 OBS 目录非空检查；

• 配置 LakeFormation 的 location 映射规则，自动将 hdfs:// 替换为 obs://。

---

5. 使用 Oozie 编排复杂工作流

• 风险：MRS 不原生支持 Oozie，原有调度逻辑无法直接运行。
• 应对建议：

• 将 Oozie workflow 拆解为 Shell / Hive / Spark 脚本组合；

• 使用 MRS Manager 的 作业流（Workflow） 功能可视化编排依赖；

• 对于定时任务，可结合 云监控 + 函数工作流（FunctionGraph） 实现触发。

---

6. Kerberos 安全集群迁移

• 风险：认证失败导致服务无法启动或客户端连接被拒。
• 应对建议：

• 严格按照 MRS 文档生成 keytab，principal 格式需匹配（如 hive/_HOST@REALM）；

• 确保所有节点时间同步（NTP），偏差 ≤ 5 分钟；

• 测试 kinit 和 hdfs dfs -ls / 是否正常。

---

7. HBase 应用直连或使用 Coprocessor/Filter

• 风险：MRS HBase 版本（如 2.4.x）与 CDH（如 1.2/2.1）存在 API 差异，Coprocessor 可能失效。
• 应对建议：

• 升级客户端代码，适配新版本 HBase API；

• 验证自定义 Filter/Coprocessor 在 MRS 环境下的兼容性；

• 使用 CDM 迁移 HFile 时，注意 仅支持 MRS 1.x 集群通过 HBase 修复命令重建表（2.x+ 不支持）。

️ 注：根据华为文档，CDM 迁移 HBase 到 MRS 2.x 及以上版本时，无法使用 HBase 修复命令，需采用其他方式（如 Snapshot 或 BulkLoad）。

---

8. 使用 Flume/Kafka 实时采集 + Spark Streaming 消费

• 风险：组件版本不匹配导致序列化异常或 offset 管理失败。
• 应对建议：

• 确认 Kafka 客户端与 MRS Kafka 版本兼容（如 2.7+）；

• Spark Streaming 作业需适配 MRS Spark 3.x 的 Checkpoint 机制；

• 建议逐步过渡到 Flink + Kafka 架构（MRS 原生支持 Flink）。

---

9. 存在大量临时表、UNLOGGED TABLE 或无主键表（PostgreSQL 同步场景）

• 风险：若涉及 PostgreSQL → MRS Hudi 同步，无主键表不被支持。
• 应对建议：

• 确保源表有主键；

• 修改复制标识为 FULL：ALTER TABLE t REPLICA IDENTITY FULL;

• 避免同步临时表、视图、函数等对象。

---

10. 国产化信创环境（鲲鹏 CPU + openEuler OS）

• 风险：x86 编译的 native 库（如 Snappy、LZ4）在 ARM 上无法运行。
• 应对建议：

• 使用 MRS 提供的 ARM 兼容镜像和依赖库；

• 避免使用平台相关 JNI 代码；

• 开启 MRS 信创性能调优模板，优化 JVM 和 I/O 参数。

---

迁移前必做清单（Checklist）

项目	是否完成
[ ] 识别所有 Impala 查询并制定替代方案
[ ] 导出 Sentry 权限策略并映射到 Ranger
[ ] 清理/替换 CDH 专属 SerDe 和 UDF
[ ] 验证 OBS 路径权限与并行文件系统配置
[ ] 重构 Oozie 工作流为 MRS 作业流
[ ] 生成符合 MRS 规范的 Kerberos keytab
[ ] 测试 HBase 客户端兼容性
[ ] 确认实时链路组件版本兼容性
[ ] 主键与复制标识检查（如涉及 CDC 同步）
[ ] 在信创环境完成 POC 性能验证

---

总结：迁移不仅是“数据搬家”，更是架构演进的机会。建议以“数据先行、元数据对齐、作业重构、权限重配”为原则，分阶段验证，避免“一次性切换”带来的业务中断风险。