云原生化迁移的血泪教训，数据平台上华为云实录

 

数据平台上云，不是把服务器搬到云上那么简单。

2025年我经手了一个大活，把一个汽车集团的数据平台从自建机房整体迁移到华为云。多个系统，涉及营销、BI、金融、车联网、安全运维，从传统的超融合架构搬到云原生架构。这不是一次普通的搬家，更像是拆楼重建。

迁移这事，在外行看来就是「把数据复制过去」，但凡真正做过的人都知道，坑多到你想退钱。技术选型只是第一步，真正的战场在迁移过程中，在每一个组件兼容性报错、每一条SQL跑不通、每一次停机窗口的博弈里。

这篇不是理论文章，是踩坑实录。我把迁移背景、技术选型、五个最大的坑、灰度切换方案和最终效果复盘全部摆出来。如果你正在做或者即将做数据平台上云，这篇能帮你少走弯路。

---

为什么要上云

先说背景，不交代清楚背景，后面的坑就没有语境。

FT企是一家合资汽车品牌，原来的数据平台跑在自建机房的超融合环境上，上百台虚机，运维了七八年。系统越加越多，资源越来越紧张，加一台虚机要走半个月的审批流程。机房本身的租期也到了，续租还是搬迁是个大问题。加上信创要求越来越明确，x86架构的服务器早晚要换国产ARM架构，与其等到最后被动换，不如借着上云一起做了。

三个推力叠在一起，上云就不是选择题了。

第一，IDC到期，机房要么续租要么搬迁，无论哪条路成本都不低。

第二，信创要求，国产化替代的时间表已经排下来了，x86生态迟早要换鲲鹏ARM生态。

第三，资源弹性，自建机房扩容慢，业务旺季加机器要等审批，云上点几下就能扩容。

决策层拍板，上华为云。原因不复杂，华为在汽车行业的信创生态最成熟，鲲鹏芯片加上MRS大数据平台加上DataArts Studio，基本能覆盖数据平台从开发到调度到分析的全链路。

---

技术选型，华为云全家桶

上云第一件事是选型。我们没有用「东拼西凑」的方式，而是选择了华为云全家桶方案。

数据平台核心用的是华为云MRS（MapReduce Service），版本3.2.0-LTS，底层组件包括Hadoop 3.3.1、Ranger 2.3.0、ZooKeeper 3.8.1，基本就是CDH的华为云替代版。开发工具用的是DataArts Studio企业版，替代原来的开源ETL工具。数据库从原来的MySQL迁移到华为云TaurusDB，兼容MySQL协议但底层是华为自研引擎。数据仓库用的是华为云DWS，存算分离架构。对象存储用华为云OBS多AZ存储。OLAP分析引擎保留ClickHouse，但部署到鲲鹏ARM节点上。

选型阶段最纠结的一件事是，要不要全量用华为云原生组件，还是保留部分自建开源组件。最后选了全量原生化方案，原因很直接，混部维护成本太高，出了问题甩锅都甩不清楚。

但这个选择也直接导致了后面的第一个坑。

---

坑一，鲲鹏ARM架构，x86的包袱跑不动

迁移的第一个大坑，是架构差异。

原来跑在x86上的一切，jar包、Python依赖、编译产物，到了鲲鹏ARM节点上全要重新适配。Hadoop生态本身对ARM的兼容性还行，但有些自研的UDF函数和第三方jar包就不一定了。

我们踩的具体坑是一个加密解密的自研jar包，调了JNI接口依赖一个x86编译的C动态库。迁到鲲鹏节点之后，jar包能加载，但一调用加密方法就报UnsatisfiedLinkError。查了半天，根因是C动态库没有ARM版本，必须重新编译。但原始C代码找不到了，最后只能用纯Java重写了一遍加密逻辑。

Python那块也有坑。有个数据抽取脚本用了PyArrow的某个版本，那个版本的wheel只有x86的，ARM环境pip install直接失败。解决方案是降级到一个有ARM wheel的版本，但降级之后某些API行为变了，代码又得改。

经验就一条，迁移之前先把所有自研组件和第三方依赖做一次ARM兼容性扫描，别等迁完再一个一个踩。最好搭一个鲲鹏测试环境，把所有作业跑一遍，过不了的提前处理。

---

坑二，数据库迁移，SQL兼容性坑死人

第二个坑是数据库迁移。

源端原来跑的是MySQL，目标端选了华为云TaurusDB。TaurusDB号称兼容MySQL协议，但「兼容」两个字背后藏了多少坑，只有跑过的人才知道。

存储过程语法基本能过，但有些MySQL特有的函数和系统变量在TaurusDB上行为不一样。我们有一个批量跑数的存储过程，原来在MySQL上跑15分钟，迁过来跑了一个半小时。查下来是一个临时表的索引行为差异，MySQL自动建索引，TaurusDB不会，加了显式索引之后才恢复到正常速度。

DWS那块更头疼。DWS底层是PostgreSQL内核，和MySQL的SQL方言差异很大。我们有些分析报表原来跑在MySQL上，迁到DWS之后SQL基本要重写。日期函数、字符串处理、窗口函数语法全不一样。好在DWS的性能确实强，重写完之后查询速度提升了一个量级，算是苦尽甘来。

最大的教训是别相信「兼容」两个字，迁移之前把所有SQL导出来做一次全量回归测试，不能只测一部分，因为你不知道哪个角落藏着一个不兼容的函数。

---

坑三，数据入湖标准，各系统各写各的

第三个坑不是技术坑，是管理坑。

数据平台迁到云上之后，数据入湖要从头规范。FT企有一百多个业务系统，每个系统的数据格式、字段命名、编码标准全不一样。我们推了一套「数据入湖标准」，要求所有接入系统的数据按照统一格式入到OBS和DWS。PPT讲了好几轮，模板发了好几版，但真正落地的时候发现标准是标准，执行是执行。

举个例子，同一个「客户编号」字段，CRM系统叫customer_id，销售系统叫cust_no，售后系统叫client_code。入湖的时候各自保持各自的命名，到了湖里一碰头全对不上。命名规范早在PPT里写了要用snake_case统一命名，但各系统开发团队说改不了，老代码动不了。

最后我们的做法是在入湖环节加了一层适配，每个系统入湖之前跑一个字段映射脚本，把各系统字段名统一转成标准命名。这层适配不是最优解，但是最现实的解。标准推不动的时候，先加一层兜底，别硬来。

---

坑四，网络通信，云上IDC混合阶段像走迷宫

第四个坑是网络。

迁移不是一刀切，有个漫长的混合阶段，一部分系统在云上，一部分还在原IDC机房。这段时间的网络通信是最复杂的。云上的系统要访问IDC的数据库，IDC的系统要调云上的API，跨环境通信全靠专线和VPN打通。

迁移统计表里每个系统都有一栏「内外网络通信要件」，要明确列出这个系统对外通信的IP、端口、协议，安全组怎么放通。多个系统，每个系统三五条通信要件，加起来几百条网络规则。有一条没配通，迁移当天就会卡住。

我们踩过一个坑，一个H5活动页面迁到云上之后，调用IDC侧的订单接口超时。查下来是安全组的出方向规则只放了通443端口，但那个接口跑在8080上。这种问题在自建机房里不存在，因为内网全通。到了云上，安全组是白名单模式，没放通就是不通。

经验是，网络通信要件表在迁移前一个月就要开始填，每个系统都要明确列出全部对外通信，别等迁移当天才发现少了端口。

---

坑五，灰度切换，停机窗口的博弈

第五个坑是切换本身。

大部分系统选的是「关机迁移」，在停机窗口内把源端数据全量同步到云上，然后切流量。但停机窗口是有限制的，业务部门不可能给你一整天。FT企的电子型录H5、潜客拉新活动这些面向C端的系统，停机窗口只有凌晨两点到六点，四个小时。

四个小时要完成什么，全量数据同步、应用启动、接口联调、烟囱测试。数据量大的系统，全量同步本身就要两个小时，留给联调测试的时间不到一个小时。一旦某个环节卡住，要么超时，要么硬切，硬切就有风险。

更头疼的是K8S环境的迁移。K8S集群里跑着十几个微服务，镜像、配置、存储卷全要迁。容器存储从本地卷迁到云盘，数据复制慢，存储卷绑定和解绑的顺序搞错就会丢数据。

---

灰度切换方案，双写双读加对账

五个坑踩完之后，我们总结了一套灰度切换方案，核心就四个字，双写双读。

迁移不是一次性全切，而是分批。先把非核心系统迁过去，跑稳了再迁核心系统。每个系统切换分三个阶段。

第一阶段，双写。新系统在云上起来，和老系统同时接收数据写入，但流量还走老系统。这个阶段主要验证云上新系统能不能正常跑。

第二阶段，对账。每天把云上和IDC的数据做一次全量对账，逐表逐字段比对。对账工具是自己写的，跑在DataArts的调度上，早上自动出报告。对账不一致的表标记出来，人工排查根因。

第三阶段，切流量。对账连续七天全通过，说明数据一致了，开始切流量。流量切换走灰度，先切10%，观察半小时没问题再切50%，最后全切。切完之后老系统保持只读一周，万一云上有问题还能回切。

这个方案不快，一个系统从启动双写到全切平均要三周。多个系统分了五批，整个迁移项目跑了半年。但稳，整个迁移期间没有出现过数据丢失和业务中断。

---

效果复盘

迁完之后的变化是实实在在的。

资源弹性是最直接的。原来加一台虚机走半个月审批，现在调规格点几下，几分钟生效。营销旺季做活动的时候，DWS集群从8核扩到64核，活动完了再缩回去，成本可控。

性能也有提升。分析报表从MySQL迁到DWS之后，原来跑十几分钟的复杂查询，DWS上十几秒出结果。ClickHouse在鲲鹏节点上跑聚合分析，速度比原来x86环境快了两成，ARM的并发能力确实不差。

运维方式变了。原来一个系统出问题，SSH登上去看日志。现在全在云控制台上操作，告警、监控、日志全在华为云的运维面板上。对老运维来说有个适应期，但习惯了之后效率确实高。

也有遗留问题。双写双读阶段产生的历史数据冗余，迁完之后清理了大半年。有些小系统的技术债一直没还，云上跑着但不完全云原生，还有改造的空间。信创适配也不是一步到位的，有些组件至今还在x86节点上跑，等后续版本再切鲲鹏。

---

写在最后

数据平台上云，技术选型只是开始，真正的考验在迁移过程。每一个组件兼容性、每一条SQL语法、每一条网络规则，都是坑。踩过坑的人才知道，迁移这事没有捷径，就是一个个问题死磕。

如果你正在做或者即将做数据平台云迁移，我给你三条最实在的建议。

第一，迁移之前做一次全量兼容性扫描，自研代码、第三方依赖、SQL脚本，全部过一遍，别迁完再补。

第二，灰度切换用双写双读加对账，慢一点没关系，数据丢了才是大事。

第三，给迁移项目留足时间，别信「三个月搞定」的承诺，102个系统至少要半年。快不是目的，稳才是。

---

作者，凌波，18年汽车行业数字化老兵，CDGP数据治理专家。从DMS运维到数据中台架构，干过甲方也干过乙方。

博客园「凌波微数」，持续分享数据治理、数据架构、企业数字化的实战经验。如果对你有用，点个推荐吧~~

下一篇，《从经验驱动到数据驱动，到底差在哪一步》