前言

前言

2025 年对我来说，是一个从“支撑系统稳定运行”走向“推动关键基础能力重构”的年份。也是我真正把 AI 融入日常工程工作的第一年。

过去一年里，我主要做了三类事情：

• 继续维护基础设施底盘，保障 xxljob、Apollo、Otel、OSS、SLS、Redis、CDN 等关键系统稳定运行。
• 推动自建机器学习训练平台从云厂商体系迁移到 Kubeflow，并围绕 TensorFlow、PyTorch、训练 IO、checkpoint、模型效果对齐做了一系列工程化治理。
• 中途加入 MC 大数据迁移项目，推动方案收敛、SQL 翻译、任务迁移和双跑报告体系落地，为后续生产割接打基础。

这一年效率提升很明显，一个重要原因是年初开始全面拥抱 AI：

• 我把 AI 当成工程工作流的一部分，用在方案推演、代码实现、问题排查、文档整理、报告生成和复杂上下文总结里。
• 它没有替代工程判断，但显著放大了我的迭代速度，让个人效率提升到原来的 4 到 5 倍左右。

如果用一句话概括这一年，我觉得是：在不熟悉的领域里，把问题拆开、把链路跑通、把结果闭环。

一、基础设施：继续把底盘守稳

基础设施侧仍然是我全年持续投入的一块工作。xxljob、Apollo、Otel 这些系统本身不一定每天都被感知，但它们一旦出现问题，影响面会很大。

因此这一块工作的核心目标并不是“做出很多新功能”，而是保障关键系统在业务增长和依赖变化中持续稳定。

2025 年主要结果包括：

• 关键系统全年保持 100% 可用性。
• 持续管理 OSS、SLS、Redis、CDN 等核心资源，发现并处理了多起异常成本事件。通过资源梳理、异常定位和持续优化，月度成本优化约 30 万元，让资源使用和业务增长保持在比较健康的匹配状态。
• 完成公司分布式全链路追踪方案建设，也协助多云转晴 CDN 观测数据替换项目落地。对基础平台来说，可观测能力不是锦上添花，而是降低排障成本、提升协作效率的基础设施。很多问题只有被稳定观测到，后面才谈得上治理。

二、自建机器学习平台：从迁移任务到训练体系重构

今年最重的一条主线，是自建机器学习平台建设。

表面上看，这是一次从 DLC、XFlow 到 Kubeflow 的迁移；实际推进下来，它更像是一次训练体系的重构。因为迁移不是简单换一个任务提交入口，而是要回答一连串问题：

• 训练结果是否能对齐？
• 训练性能是否能接受？
• 云厂商闭源能力缺失后，我们自己能不能补上？
• 训练卡死、快慢 worker、内存飙升、checkpoint 膨胀这些长期问题，能不能借迁移机会一起解决？

最终，我们完成了 DLC 183 个任务与 XFlow 279 个任务的迁移，训练体系从云厂商平台切换到自建 Kubeflow 平台。这件事的价值不只是“迁完了”，而是训练链路开始变得可解释、可优化、可掌控。

1. tapio：把闭源 paiio 变成可控的训练 IO 能力

迁移过程中，一个核心问题是数据读取框架。

过去算法训练大量依赖阿里云闭源的 paiio。闭源组件在稳定时期很省心，但一旦遇到兼容性、性能或边界问题，排查空间就很小。为了解决这个问题，我自研了 tapio，基于 pyodps 实现 ODPS 表数据读取，支持 TensorFlow 和 PyTorch 的 Dataset 框架，用多线程和队列机制加速 IO。

tapio 的目标很明确：一行代码平替 paiio 的 TableRecordDataset，让训练任务可以从云厂商闭源能力中解耦出来。

从实际效果看，tapio 在多个业务模型上都带来了明显收益：

• 广告模型 ad_model_newseq_activeday_v3 训练时间从 18.5 分钟降到 13 分钟，效率提升约 30%。
• ad_model_base_gegelu 从 2.95 天降到 1.84 天，效率提升约 38%。
• 广告主模型 ad_model_material_pltv_ppr_v1_5_kl_v2 从 20 分钟降到 3 分钟，效率提升约 85%。
• 投放模型 ag_register_ctcvr_train_di_base 从 20 分钟降到 6 分钟，效率提升约 70%。

后续在 tapio 0.5.1 中，WorkQueue 进一步解决了多 worker 场景下的资源浪费和快慢 worker 问题：

• 在广告模型中，WorkQueue 可降低约 80% 内存资源占用。
• 在快慢 worker 场景下，worker 退出时间从小时级缩短到分钟级。
• 离线 AUC 测试也显示，Kubeflow + tapio + WorkQueue 模式效果最好，相比 Kubeflow base 离线 AUC 有正向提升。

这件事让我感触比较深：基础框架的价值往往不只体现在“跑得更快”，更体现在它让上层问题变得可定位、可解释、可演进。

2. 迁移不是搬家，而是系统性排障

从 XFlow、DLC 切到 Kubeflow 后，很多过去被平台屏蔽的问题开始暴露出来。

几个典型问题包括：

• 训练任务曾出现“卡死但没有任何异常”的情况。排查后发现，worker、ps 数量和资源配比不合理，CPU 能跑满 100% 甚至超核到 126%，再叠加训练框架异常捕获不完善，最终表现成无日志卡死。调整为 5 个 ps、50 个 worker、单 worker 4 核后，总训练时间保持不变，但 CPU 利用率稳定在 70% 到 80%，卡死问题消失。
• TensorFlow 1.12 评估任务无法结束。现象是评估任务跑完后，只有一个 worker 退出，大部分 worker hang 住。继续往下拆，问题有两层：第一，评估任务结束时没有显式关闭 tf.Session()；第二，触发了 TensorFlow 1.12 社区版本的 bug。DLC 中没有暴露这个问题，是因为广告使用的 PAI 镜像底层是 DeepRec TensorFlow，已经对 session close 超时做了补丁。而在社区版本里，这个问题需要我们自己解决。
• Kubeflow 和 DLC 默认行为差异也带来问题。例如 Kubeflow 默认 success_policy=ChiefWorker，只要 worker-0 成功结束，任务就可能被判定成功；而 DLC 默认更接近 AllWorkers。这个差异导致部分 worker 还没来得及提交评估数据，任务就结束了，最终评估记录比原始数据少。解决方式是把评估任务的 success policy 调整为 AllWorkers。

其中 TensorFlow 1.12 问题的解决方案也很工程化：显式关闭 session，同时过滤 worker 之间的连接。因为我们的训练是异步训练，worker 之间不需要通信，只需要 worker 与 ps 通信。这个修改让任务退出行为变得可控，也把一个“偶现 hang”的问题还原成了明确的架构约束。

这些问题单个看都很细，但合在一起，就是迁移能不能大规模落地的关键。

3. 模型效果对齐：用实验建立信任

平台迁移最难的部分，不一定是任务能不能跑，而是模型效果能不能被算法同学信任。

广告主 OCP 付费率模型迁移时，Kubeflow 离线 AUC 对比 base 一直偏低。这个问题不能靠“应该没问题”来推进，只能靠实验。

我先排除模型代码结构、特征配置、训练参数、训练迭代方式等干扰项，然后把影响因素拆成两类：dataset 框架从 paiio 到 tapio，训练资源从 XFlow 到 Kubeflow。基于这些假设分别设计实验，最终形成新的验证思路：从 base 模型一个月前的 checkpoint 切一个新分支，在 Kubeflow 上日更，再对比离线 AUC。

实验结果证明，Kubeflow 和 XFlow 训练的模型离线 AUC 没有本质偏差。这个结论很重要，因为它不是简单验证一个模型，而是建立了一套后续迁移可以复用的效果验证方法。后续 XFlow 切 Kubeflow 的模型实验，都可以用“base checkpoint 切分支”的方式缩短验证周期。

4. checkpoint 治理：把 PB 级存储成本收回来

机器学习平台另一个长期问题是 checkpoint 数据膨胀。

训练 checkpoint 的增长很容易被忽略：实验模型没有上线、上线模型被迭代下线、日更模型长时间保留历史 checkpoint，这些都会让 OSS 存储持续上涨。5 月份相关成本已经达到 32.62 万，粗略估计 6 月会超过 40 万/月。

我推动了 checkpoint 数据治理，结合手动清理和自动清理程序，最终把 PB 级存储成本收回来：

• 累计清理 6.26PB 数据。
• 自动清理首次运行清理 3.4PB，手动清理 2.86PB。
• 最终存储规模从峰值 8.97PB 降到 2.71PB，每月优化 OSS 存储成本约 31.4 万元。

更关键的是，这不是一次性清理。后续自动清理程序会每日运行，让 tapad-data 的存储稳定在 2.7PB 左右。自动化治理的价值就在这里：它不只解决一次问题，而是把问题从“定期救火”变成“持续收敛”。

三、MC 大数据迁移：把双跑体系跑起来

除了机器学习平台，今年另一个重要项目是 MC 大数据迁移。这个项目目前还没有结项，2025 年的核心结果，是先把迁移方案、工具链、双跑验证和报告体系建立起来，让后续真正的业务割接具备可执行基础。

这个项目不是我的传统领域，而且我是在项目中途加入。但项目推进到关键阶段时，最需要的是快速理解现状、识别阻塞点、把可落地方案推出来。

2025 年我主要补齐了几类能力：

• 提出并推动 V2 迁移方案落地。相比旧方案，V2 方案流程更简化，可操作性更强，降低了迁移复杂度和落地风险。方案获得项目组一致认可后进入实施。
• 自研 ODPS SQL 到 Spark SQL 的翻译引擎，在 ADN 业务实现 100% SQL 翻译覆盖，ADN 作业翻译 0 人工介入。这件事降低的不只是人力成本，也降低了人工改写带来的不一致风险。
• 自研 DataWorks 任务迁移服务，实现 ADN 全量任务自动化迁移到新的 Lakehouse 空间，保障 500+ 任务每日稳定双跑。
• 围绕双跑过程搭建 mc2lake 数据报告中心，持续输出运行报告，为 Spark vs MC 的性能与成本对比提供数据依据，支撑迁移决策和后续优化。

从结果看，这一阶段解决的是“能不能稳定迁、能不能持续双跑、能不能用数据判断差异”的问题。ODPS SQL 到 Spark SQL 的翻译、DataWorks 跨空间任务迁移、ODPS 到 DLF 的数据同步、数据一致性校验、运行报告中心，这些能力共同构成了后续生产割接的前置条件。

这个项目对我的意义在于，它证明了工程方法的可迁移性。即使进入一个不熟悉的领域，只要能把系统边界、数据链路、验证标准和回滚路径拆清楚，就可以在关键节点产生实际推动力。2025 年我在这个项目中的重点，不是完成最终割接，而是先把后续割接所依赖的基础能力搭出来、跑稳定、验证清楚。

四、这一年的得与失

1. 快速建立问题模型

今年做得比较好的地方，是我能持续在不熟悉领域里快速建立问题模型，并通过工程化手段把复杂问题拆到可执行。

在机器学习平台项目里，我不是算法训练领域的原始 owner，但通过持续排查模型效果、训练稳定性、IO 性能、资源配比、TensorFlow PS 架构、checkpoint 成本等问题，逐步把迁移从“任务能跑”推进到“结果可信、成本可控、平台可持续”。在 MC 大数据迁移项目里，我也在中途加入的情况下，把方案、工具和报告体系补齐，推动项目进入稳定双跑。

2. AI 成为工程放大器

还有一个不该被忽略的变量，是 AI。

2025 年初开始，我几乎把 AI 全面纳入个人工作流：

• 写代码时用它快速生成骨架、补测试思路和解释陌生 API。
• 做方案时用它整理约束、推演边界条件和生成对比表。
• 排障时用它辅助梳理日志、还原调用链和枚举可能原因。
• 写文档和报告时用它快速把零散信息变成结构化表达。

这件事带来的不是简单的“写代码更快”，而是整个工程闭环变短了。过去需要半天整理上下文的问题，现在可以先让 AI 帮我把信息归类，再由我判断关键假设；过去需要反复查资料、试错、写脚手架的工作，现在可以更快进入验证阶段。最终体现出来，就是个人吞吐提升到原来的 4 到 5 倍。

但 AI 只放大能力，不替代判断。真正有价值的是把 AI 和工程方法结合起来：目标要清楚，约束要说清楚，生成结果要验证，关键结论要能落到代码、数据或实验里。否则 AI 只会增加更多看似合理但无法落地的文本。

五、下一年想继续做的事

2026 年，我希望继续沿着三个方向深入。

1. 把已经落地的能力继续平台化

tapio、checkpoint 治理、Kubeflow 训练链路、mc2lake 报告中心，都已经证明了价值，后续应该沉淀成更标准、更可复用的内部基础能力。

2. 完成 MC 到 Lakehouse 的生产割接落地

2025 年已经完成了双跑链路和验证体系，2026 年要把重点放到业务割接：继续跟踪双跑结果，推进 MC 空间冻结、新任务发布、外部产物校验、模型训练切换和异常回滚机制。

为此，我准备建设一整套割接平台：

• 把割接从人工脚本、Excel 清单和聊天记录，收敛成一个可预检、可预览、可执行、可审计、可回滚的控制台。
• 围绕 Hologres SQL、DI_Holo、普通 DI 任务和 Shell 训练任务这几类典型场景展开。
• 对 SQL 和 DI 任务提供差异预览、依赖检查、发布和回滚能力。
• 对 Shell 训练任务，结合已经验证过的 Paimon 训练任务，完成旧任务冻结、实例处理和必要时的回滚。
• 这个平台的定位不是“自动迁移平台”，而是割接执行和风险控制平台，目标是让割接过程可批量推进、可审计、可回滚，而不是依赖人工经验临场处理。

3. 继续提升自己在新领域里的抽象速度

今年从机器学习平台到大数据迁移，我能明显感受到，很多复杂问题背后的工程结构是相通的：先定义目标，再拆链路，再建立验证，再做自动化，最后形成持续治理机制。这个方法值得继续强化。

同时，也要继续把 AI 作为工程放大器，用它提升信息处理、代码实现和文档沉淀效率，但关键判断和最终质量仍然要由自己负责。

过去一年，很多工作都不是“从 0 到 1 做一个新系统”这么直观，而是在复杂系统里把不稳定、不透明、不可控的部分一点点拆开。它们最后体现为更稳定的训练、更低的成本、更清晰的迁移路径和更可靠的平台能力。

这也是我对 2025 年最大的总结：真正有价值的工程工作，不只是把事情做完，而是让事情下一次更容易被做好。