2024年1月6日，夜色如墨，而深圳C局客户机房内的灯光却异常明亮，现场支撑的淞哥，眼睛紧盯着屏幕，手指在键盘上飞速敲击，随着最后一行代码的执行，他难掩激动地在大网改造保障群对话框里迅速写下：“服务启动完成、OSS（无线运营商业务系统）正常接入、定时报表正常生成、数据迁移范围符合预期……”这不仅是一条消息，更是一声胜利的号角。

消息一发出，群里立刻沸腾了，点赞和鼓掌的表情包不断在屏幕上跳动着。这一刻，我们所有人的心都紧紧相连，共同分享着这份来之不易的喜悦。

我坐在电脑前，闭上眼睛，任由思绪穿越时空，回到了过去一年中的每一个日夜……

在OMC（无线网络管理）的先进领域，运营商客户始终在追求拥有一个高效管理系统——能够统一掌控庞大网络设备的理想平台。无论省份、设备制造商如何分散，都能通过统一的OMC系统实现无缝运维管理，这将极大提升运维效率，优化网络性能。

此前，我们的PRS（无线网络性能评估系统）作为无线网络管理领域的创新成果，成为了运营商客户日常网络运维不可或缺的一部分。客户对我们的信赖和对大网能力的期待，成为我们不断追求技术突破的动力。

2019年，我们迈出了重要的一步：PRS首套1W大网商用系统上线。“1W大网”能够管理一万个等效网元，为了有效处理海量T级别网络性能数据，我们首次引入了“Hadoop分布式集群系统”。同时，我们还有灵活管理规模小于一万个网元的 “PRS小网”系统，它一直依赖于公司自主研发的高斯数据库来存储数据。因此在大网商用之初，研发团队面临的一大挑战便是同时维护Hadoop和高斯两套技术栈。

随着高斯数据库性能的持续优化，我们看到了将Hadoop大网改造至高斯数据库的可能性。技术预研的成果令人鼓舞，如果大网和小网技术栈都归一到高斯数据库，这不仅可以节约研发成本，而且客户最常用的报表查询等功能的使用效率将成倍提升，极大提升客户体验，进而增强华为大网竞争力。在一次关键的RAT（需求分析团队）会议上，团队决策通过了采用高斯数据库作为大网的新方案。

如何平稳地升级和改造已经商用的存量Hadoop大网？

要解决这个问题，我们面临两项挑战。首先，是T级数据的迁移，这不仅仅是数据的物理转移，更是一次深层次的数据结构重塑。我们的目标是将庞大的数据量从Hadoop大网的分布式文件系统中无缝迁移到高斯数据库，这就像是一项精细的外科手术，需要在不损伤任何数据的前提下，完成数据的精准转移和转换。其次，工程改造的复杂性考验着我们的技术和耐心。由于客户硬件资源的限制，我们无法引入新的硬件，只能在现有的硬件基础上进行改造，这就像是在一张已经完成的画作上重新作画，既要保留原有的精髓，又要赋予它新的生命力，其中涉及超过30个精细的操作步骤，每一步都必须精确无误，任何微小的差错都可能导致整个项目失败。

作为PRS工程组的PL（项目组长），我的主要任务便是确保PRS系统的工程运维顺畅，包括产品的安装、升级、扩容等一系列关键环节，面对大网改造这一重大任务，我们团队无疑是工程模块的最佳人选。然而，原本负责数据迁移的业务组，因承担打造产品性能中心的重任而无法抽调人力支撑数据迁移。版本经理坤哥满心焦虑，特意将我叫到会议室，直截了当地说：“元，你们团队现在是我唯一的依靠。请评估一下，你们是否有能力独自承担起大网改造的全部任务？”

坤哥的话语如重锤一般，砸在我的心上。我的内心充满挣扎，虽然我们团队在产品安装和升级方面积累了丰富的经验，但对于性能数据表结构和网络性能评估业务却是知之甚少。我不禁自问：我们真的准备好迎接这一挑战了吗？我们能否跨越业务领域的界限，成功挑战自我？

坤哥深知这个项目的重要性和难度，静静等待着我的回答。作为工程组的一员，我清楚地了解我们肩负“作为一支轻骑兵使能业务成功”的使命，回想起过去面对产品构建、安装、升级、工程运维种种挑战，每一次我们都迎难而上，每一次都取得了成功。这一次也不会例外，我应了下来：“你放心，交给我们吧！”

既然接下了任务，肯定要扫除一切障碍，达成目标。为了能够在2023年完成全球全网的存量Hadoop大网改造，统一收编到高斯大网，我们定下计划：在6月前将大网改造工具发布上网。此时已是1月，时不我待，我们决定立即组织攻关，进行技术穿刺和方案打磨，以探索各种可行方法并验证。

溪村的会议室是我们经常开展思想碰撞的地方。每当团队成员有了新发现或创新思路，就会急切地召集大家：“走，碰一下！”会议室里，激烈的讨论声此起彼伏，不同的声音交织碰撞出火花。

“我认为我们应该优化数据导入流程，直接在DB（数据库）节点操作，避免跨节点链接带来的延迟。”负责数据导入的小王坚持道。

“但是，如果数据量过大，DB节点的压力也会随之增加，我们不能不考虑系统的稳定性。”SE（系统工程师）鑫爷迅速反驳。

这样的争论屡见不鲜，每个方案的提出都会引发激烈的辩论，每个人都在为了寻找最佳解决方案而努力。

2月初，我们将视之为拦路虎之一的数据迁移的原型做出来了。然而，在实验室测试中，尽管我们采用了并发解析技术，仍发现原型的性能远未达到预期，特别是数据解析效率与设定的标准相差甚远，效果并不理想。

为了解决这个问题，我们向部门的首席架构师求助。他详细了解业务场景后，逐行检视了我们的代码，最后说的一句话让我们豁然开朗：“你们数据解析的顺序要调整下，数据读取完之后，要做一下行列转置，先做列的拆分，再做行的拆分。”

原来，Hadoop的数据表是宽表结构，最宽有6000多列，一张表要进行多达30次列的拆分操作，如果我们先按行将数据表拆分成最多14个子表，然后再进行列拆分，这意味着我们将执行高达N*30次的列拆分，其中N是子表的数量，这无疑增加了重复操作的频率。我们迅速调整了策略，果然改进后的数据迁移效率提升了数倍，终于达到了规格要求！

我们不仅在数据解析和导入上寻求突破，更在工程改造过程中充分考虑了DFX（面向各种需求的设计），确保能够应对各种可能的异常场景。在密集的研讨和技术攻关下，拦路虎已经变成纸老虎，2023年4月，我们打通了数据解析、数据导入及工程改造等难关的每一个环节，终于有信心启动与TAC（技术支持中心）和TD（一线技术主管）等关键角色的沟通了。

大网改造团队研讨方案（左一为作者）

沟通之前，我们精心准备好了胶片，将改造背景和方案、客户面影响、客户收益等都做了详细说明。

将大网改造为高斯数据库大网后，客户体验成倍增加，这正是“以客户为中心”，技术支持中心对此非常认可。但当听到我们的改造方案必须卸载原来的系统，再重装为高版本的高斯数据库大网时，专家们立马表示这个方案存在极大风险，“中国区升级时间窗严格打点，要求在两小时内完成，你们这个方案，升级和改造耦合在一起，是绝对不行的，30多个操作步骤，风险太高了！”

这番话让会议室瞬间安静了下来。中国区这么严苛的升级限制，确实是我们之前忽略了的关键要素。我们原本的方案是先将存量低版本的Hadoop大网进行数据备份后卸载掉，再重装为高版本的高斯大网，然后将备份好的数据迁移过来，这个方案本意是在进行大网改造的过程中，也同步将版本进行升级。但是，正如TAC所担心的，中国区对于升级有非常严格的操作时间窗限制，如果改造要与版本升级耦合在一起，意味着我们要在一个时间窗内完成升级和改造两件事，风险不可控。我们不得不重新调整方案，先将存量大网升级到高版本，然后再另外申请操作时间窗进行改造。

新的方案，看起来是简单地将一个步骤拆分成了两个步骤，做了顺序的调整，但是做过软件测试的人应该都清楚，这意味着无论是数据迁移，还是工程改造环节，都要重新适配新场景。但质量高于一切，技术支持中心专家们的这个建议，确实能够将风险降到最小。于是，我们又紧锣密鼓地开展新方案的适配。时间紧迫，只剩不到2个月的时间就要发布工具了，我们与测试人员结对，把所有验证场景都覆盖验证了一遍，确保场景无任何遗漏。

终于，在大家夜以继日的攻关冲刺下，我们顺利完成了新方案的实现和测试验证，新的方案隔离了改造对升级的影响，降低了操作风险，TAC对我们的新方案也表示了支持。

大网改造工具在众人的期待中如期发布了！

纸上得来终觉浅，客户真实环境的改造才是真正的考验。海内外存量Hadoop大网，先改造谁，后改造谁，是个值得斟酌的问题。深思熟虑后，我们选择香港A局作为突破口，它不仅在数据迁移量上具有代表性，而且该局客户对新架构的大网充满期待。

我们在实验室已经通过镜像环境做过多轮验证，派出了技术骨干轩哥，深入客户交付现场，全程保障改造顺利进行。

然而，在实施改造过程中，还是遇到了波折。在第一步数据解析阶段，解析进度没有如预期那样“唰唰”飞起。眼看，每耽误一分钟，就多压缩了一分后续操作的时间，轩哥内心焦急万分，快速查看日志、排查代码和监控进度，进行问题的定位。为了应对解析过缓带来的风险，我和团队其他远程保障的兄弟也积极准备备选方案。

正当我们评估备选方案能节省多少时间时，在客户现场的轩哥忽然惊喜地说道：“我好像找到问题原因了，你们快看，其他节点都快解析完了，就只有这三个节点进度拉垮！”我们立刻围在电脑前紧盯屏幕，果然，其他节点进度都到90%了，另外三个节点才50%。

“轩哥，你进到那三个节点看下，我们分配到这几个节点的数据表都是什么类型？”鑫爷马上说道。

轩哥熟练地跳转到那三个节点，打开数据表存放的路径，鑫爷盯着屏幕看了几秒，激动地说：“果然如此，这三个节点的数据表要做额外的数据加工，会大大增加耗时！”

数据加工耗时会因表而异且产生巨大影响，这一点确实在我们的预料之外，立即解决对我们而言并不容易。在大家面面相觑时，我提出：“分布式处理提效的关键是保证各节点处理时间的均衡，而算法是决定能否均衡的关键。” 我立刻把负责数据分发的鼎哥叫过来，详细询问了分发的算法。原来数据分发尽管采用了负载均衡的算法，但是主要是根据数据文件的大小来做负载均衡，这能够保证分配到每个节点的数据量是一致的，但是没有考虑到不同数据表数据解析的复杂度。如果想要保证每个节点耗时基本一致，不出现“木桶效应”，导致个别节点耗时过长，其他节点空闲等待，就必须针对不同的数据表进行加权，再做负载均衡。

技术上的根因，我们算是找到了，但是香港局点当前已经到了解析的关键时刻，不可能等我们优化了负载均衡算法再处理。我继续引导大家集思广益：“这三个节点的资源消耗已经到达瓶颈，我们有没有其他办法提效，例如加个buff实现多线程并行？”鑫爷提出，可以将这三个节点尚未解析的数据挪到其他空闲节点进行解析，追回时间。说干就干，鑫爷指挥着操作步骤，在客户机房的轩哥一条条命令地敲击着，终于预期时间内完成了解析。

我们将改造完的系统交给一线同事和客户体验，界面流畅、查询效率成倍提升，大家对我们赞不绝口，还发来了感谢信。客户的点赞，是我们最好的通行证！

此次实战成功，我们不仅优化了数据分发的负载均衡算法，保证各数据节点解析耗时均衡，同时也积累了宝贵的实战经验，更加坚定了其他局点一线和客户进行大网改造的信心。

香港首局的成功，吹响了存量Hadoop大网全网收编的冲锋号角，然而，横亘在我们面前的还有另一座大山——荷兰B局。

荷兰B局的情况特殊，作为全球唯一一套被集成的环境，其硬件资源是客户自行提供的三方资源，在操作系统I层加装了第三方的安全加固工具，而大网改造的方案涉及重装虚拟化层，这意味着改造完，客户需要重新安装安全加固工具，会给客户带来额外工作量。

第一次周例会时，我们介绍完改造方案后，客户主管立即提出质疑：“这样有必要吗？是否有其他不需要重装虚拟化层的方案？”这让我们压力山大，一线兄弟也是焦急万分。与此同时，客户主管即将休假一个月，如果不能在这两周内说服客户接受当前方案或者提出一个令客户满意的替代方案，我们将会错过最佳的改造时机，造成运维成本增加。

回去后，我们紧锣密鼓地研讨出一个不重装虚拟化层的备选方案，将该方案和原方案的过程细节、每个步骤的影响、预期收益等方面进行了详尽的对比分析。最终证明，我们的原方案无论在操作步骤还是风险影响上，都比不重装虚拟化层的备选方案有优势。

我们赶紧抓住下一个周例会的机会跟客户沟通。这一次，客户态度终于有所松动，当听到香港首局改造后，查询效率提升了4倍，客户激动地说道：“真的吗？如果能做到，那就太好了！”随即客户认可了我们的方案，表示改造后如能达到预期收益，对于重新安装安全加固工具产生的额外工作，他们愿意协调专家全力配合。

方案谈妥，客户也放心地休假去享受旅行时光了，当客户结束假期归来，惊喜地发现大网网络已经焕然一新，历史数据得到了完整保存，报表查询导出效率实现了成倍提升，体验非常棒。看到客户脸上洋溢的笑容和认可的眼神，我们的心里也乐开了花，一切的付出都是值得的。

香港A局和荷兰B局的实战的胜利，令我们信心高涨，开始了全面进攻。存量收编就好似滚雪球，每攻下一局，积累的势能也越大，后续局点的改造一路高歌猛进，2023年11月和12月，江苏、四川、安徽等局点全部完成改造，随即深圳C客户也在2024年1月完成大网改造，数据迁移完整，业务功能平稳。我们在一片平静祥和顺利中收官。

每次改造成功后，我们都会走访所有的一线、网优及客户，收集他们对升级改造后产品的使用体验。得到的反馈令我们倍感欣慰，大家都一致认为操作流畅、响应及时，客户经常使用的报表查询功能，查询效率从原来的分钟级降低到秒级。而令我印象最深的是香港A局的一位客户说：“这次真的很惊喜，想不到升级改造后变化这么大，跟以前比完全像是两套不同的环境！”

Hadoop大网存量全网收编，为客户带去了更优的体验，更高的产品竞争力，同时也甩开了两套技术栈同时商用的包袱，轻装前行，为后续的2W乃至5W大网铺平了道路。

大网改造团队（左一为作者）

犹记得刚承接大网改造任务时，兄弟们问我：“这么难顶的活，我们真能行吗？”我回答道：“干就是了。”当时的念头很简单，就是曾国藩说的那句话：“天下事，在局外呐喊议论，总是无益，必须躬身入局，挺膺负责，方有成事之可冀。”现在想来，我们在大网浇筑的一腔热血，因为有了果敢的行动，终于开出了美丽的花！