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