很多单位的数据平台迁移，最后都变成了一场灾难——老系统里几千张表、几百个任务、数不清的临时表和测试表，一股脑搬到新平台。搬完之后发现：垃圾搬过来了，秩序没搬过来。
迁移的真正问题不是"怎么搬"，而是"搬什么、不搬什么、搬过去之后怎么管"。
答案只有一句话：老系统只做最小盘点，新系统承担治理主战场。
一、为什么"先治完再搬"行不通？
行业里的传统做法是：在老系统里把数据治理做完了——表注释补齐了、字段标准化了、质量问题修复了、冗余对象清理了——然后再整整齐齐地迁到新平台。
这个想法逻辑上没问题，但落地时撞上了三个现实：
第一，老系统不具备治理条件。 很多老平台的表没有注释、字段没有标准映射、血缘链路缺失、责任人早已离职。在上面做治理，就像在一栋没有地基的危房里搞精装修——墙都裂了，你还在贴壁纸。
第二，时间和人力不允许。 一个运行了五到十年的老平台，几千张表、几百个 ETL 任务、数不清的临时表和废弃副本。在老系统上一张表一张表地治理完再迁移——光是摸底就要半年，治理完要两年。业务等不了。
第三，老系统上改了也白改。 就算你在老平台上把所有注释补全了，迁到新平台后还是要重新接入、重新编目、重新配置。老系统上的治理成果无法直接复用。
所以正确的顺序是反过来的：先迁移到新平台，在新平台上统一治理。 老系统只做一件事——把底数摸清楚。哪些是核心资产、哪些是存疑对象、哪些是早就该清理的垃圾。摸清楚之后，分区接入新平台，在新平台上完成治理、评估、上架。
老系统负责"看清楚"，新系统负责"治明白、管起来、用起来"。
二、老平台的六大"遗传病"：不是修修补补能解决的
为什么要费这么大劲做迁移，而不是在老平台上继续修修补补？因为 1.0 时代的数据平台，有一些问题是架构层面的——不换底座，永远修不好。
第一，老一代 Hadoop 体系正在从"建设主力"变成"历史包袱"。 过去政务数据平台大多以 Hadoop 为核心，Hive 做数仓、HBase 做存储、Spark 做批处理、Sqoop 做导入、Oozie 做调度。这套体系在当年解决了"数据先汇起来"的问题，但放到今天，很多组件已经显得笨重、分散、升级困难，既难支撑实时化和一体化治理，也越来越难找到愿意长期维护老版本体系的技术团队。
第二，多开源组件叠加形成的老平台，普遍存在权限、运维和治理割裂问题。 很多老平台由 Hadoop、Kafka、Flume、HBase、Spark、Elasticsearch 等多个组件组合而成。虽然部分平台做过统一认证、集中监控等整合，但整体上仍普遍存在权限模型不一致、管理界面分散、日志与监控口径不统一、故障定位链路长等问题，难以形成真正平台级的一体化管控能力。这也是为什么很多老平台"能跑"，却越来越"难管、难改、难运营"。
第三，查询性能无法支撑交互式分析。 Hive 的 MapReduce 引擎做一次全表扫描动辄几分钟到几十分钟。业务人员想交互式地"查一下、看一下、再改一下条件"——老平台根本做不到。这种批量处理模式在报表时代勉强可用，但今天的智能问数要求毫秒级到秒级响应，Hive 的架构基因决定了它不可能胜任。
第四，黑暗无效数据泛滥。 老平台上沉淀了大量"僵尸数据"——三年前的临时表、两年前跑了一半就废弃的 ETL 任务、只建了表没跑过任务的空库、来源和责任人都已离职的孤立数据集。因为没有资产管理闭环，这些对象只增不减、只建不退，像藤壶一样爬满了平台。
第五，自动化程度极低。 元数据采集靠手工填表、数据质检靠人工抽查、资产编目靠逐字段手写注释、共享审批靠发函和打电话。一个数据管理员的日常是：上午催部门上报元数据台账，下午手动更新 Excel 汇总表，晚上加班写本周的编目进度报告。
第六，与智能化彻底绝缘。 Hadoop 生态诞生于 2010 年代，设计之初就没有考虑过大模型调用、向量检索、智能体调度、自然语言问数这些场景。想给老平台加 AI 能力？要么在外围包装一层——那就是回到了"外挂式 AI"的死结；要么彻底换底座。
这六个问题，没有一个是靠"加功能"能解决的。它们是架构的问题、基因的问题、时代的问题。
解决方式只有一个：把有价值的数据资产迁出来，把老平台关掉。
三、怎么迁？——三类资产，三种通道
搞清楚了"为什么迁"，接下来是"怎么迁"。老平台上的东西大致分为三类：数据、API 服务、调度任务。每一类有不同的迁法。
数据迁移：老数据湖 → 新平台
老旧数据湖的数据大都是 Hive 表，底层是 HDFS 文件 + Hive Metastore 元数据。奥腾的数据迁移中心专门适配了这个场景：
自动对接 Hive Metastore：直连老平台的 Hive 元数据库，自动扫描所有库、表、分区、字段信息，生成迁移清单
向导式配置迁移任务：选择源库源表 → 选择目标库目标表 → 配置同步策略（全量/增量）。整个过程界面操作，不需要写一行脚本
支持全量和增量同步：全量同步一次性搬迁历史数据；增量同步持续捕获老平台上仍在更新的数据，保证新老系统并行期间数据一致
断点续传 + 速率控制：大表迁移过程中如遇网络闪断，任务自动从断点恢复，已经同步完的分区不需要重来。支持限制迁移速率，避免影响老平台剩余业务的正常运行
结构化数据从 Hive 迁出之后存到哪？ Hive 适合批量加工，不适合交互式查询和小批量高频访问。建议迁入国内落地很广的湖仓一体计算引擎之一 MPP 数据库——Doris、StarRocks等。以轻量化列式 MPP 引擎替代笨重 Hadoop 计算栈，依托秒级查询、原生实时写入更新、无缝对接 Hive 存量数据湖、低运维成本的一体化能力，承接原有离线分析同时补齐实时数仓能力，完成 Hive+Hadoop 架构的降本提速与实时化升级。MPP 的列存 + 向量化执行引擎，对聚合分析类查询的性能比 Hive 高 1-2 个数量级，才能真正支撑智能问数的秒级响应体验。奥腾数据中台原生适配 Doris 数据湖，迁移过来的 Hive 表可以直接落地为 Doris 内表或物化视图，模型开发零切换成本。
API 服务迁移：老接口 → 新网关
老平台上对外提供的数据 API，需要平滑过渡到新平台的统一 API 网关。分三步：
全量盘点：扫描老平台的 API 管理模块（或网关），提取所有在用的接口清单——URL、入参出参、调用方、调用频次、认证方式。
在新平台重建：在奥腾数据共享中心里，用同等的数据表、字段和查询逻辑，重新配置生成标准 API。入参出参保持兼容，调用方无需修改客户端代码。
分批切换引流：先在少量调用方上灰度切换，验证新 API 的响应结果与老接口一致。确认无误后，逐步将全部流量切到新网关，老接口下线。
调度任务迁移：老任务 → 新画布
老平台上基于 Oozie/Azkaban 等老调度工具编排的 ETL 任务链，不建议逐一手动重写——工作量大、容易遗漏、难以对齐逻辑。奥腾的做法是：
解析老任务链：读取 Oozie/Azkaban 的任务配置文件，提取任务依赖关系、脚本路径、执行参数。
AI 辅助翻译：将老任务的 SQL/HQL 脚本输入 AI 开发助手，自动翻译为奥腾数据开发画布上的可视化开发模型。人工校验逻辑是否一致。
在开发沙盒中验证：用样本数据在新平台跑一遍，对比结果与老平台输出是否一致。
发布到生产沙盒：验证通过后一键发布到生产环境，纳入统一调度。
四、迁移六步：从"摸清底数"到"旧系统退场"
第一步：老系统最小必要盘点
目标不是"把老系统治理干净"，而是把底数摸清楚。
盘点所有数据对象：库表、ETL 任务、API 接口、指标、模型、报表。
抽取基础元数据：对象类型、最后更新时间、存储规模。
标记需清理的对象：临时表、测试表、中间表、历史废弃副本。
梳理关键依赖：哪些任务被报表引用、哪些接口被外部系统调用、哪些表的变更会影响下游。
这一步的输出是四份清单：迁移对象清单、风险对象清单、依赖关系清单、待清理对象清单。
第二步：迁移入新平台，分区接管
不是一股脑全搬。新平台为老系统的资产开辟三个区：
核心资产域：经过第一步确认的高价值、高依赖对象，优先迁入。
待评估区：存疑对象——不确定有没有用、不确定质量如何、不确定归属的，先进来但不开放。
归档区/观察区：历史保留对象——不再更新但需要留存备查的，归入归档区，不参与日常治理。
关键原则：先接管，再治理。不要在老系统上纠结"这张表到底要不要"。
第三步：新系统统一治理与评估
这是迁移过程中最核心的一步——也是老系统永远做不到的一步。
在新平台上完成：
语义补齐：AI 自动探查 + 人工确认，补齐表描述、字段注释、业务口径
标准映射：将老系统的非标准字段映射到统一标准，关联 L5 同义属性
分类分级：自动识别敏感字段，打上分类分级标签
血缘梳理：基于 ETL 任务和 SQL 日志，还原表级和字段级血缘关系
多维评估：质量评分、合规校验、价值识别、活跃度分析、可共享性判断
第四步：资产分类决策
治理评估完成后，每一张表、每一个任务、每一个接口都要做出最终判定：
不是所有从老系统搬过来的东西都叫"资产"。 临时表不是资产，测试表不是资产，三年前就没人用的废弃副本不是资产。迁移的意义不是把旧仓库里的所有东西堆到新仓库——而是在新仓库里重新识别哪些是资产、哪些是垃圾。
第五步：资产上架与业务架构绑定
通过第四步筛选的资产，正式进入资产应用中心：
按资产类型分类上架（数据表资产、API 资产、指标资产、模型资产）
绑定 L1-L5 业务架构——每一张表归属于哪个业务域、哪个主题、哪个业务实体
生成资产详情页：基础信息、字段详情、血缘图谱、质量评分、样例数据、访问统计
开放浏览、申请、共享入口
上架的前提是可理解、可治理、可追溯。 一个连注释都没有的表，不该出现在资产市场上。
第六步：分批切换应用，旧系统退场
资产上架后，推动业务真正迁移到新平台：
切换报表、接口、指标、模型的数据源指向
迁移共享服务和调用入口
验证新旧系统结果一致性
逐步压降旧平台直接查询依赖
下线旧任务、旧接口、旧报表，归档或清退
迁移的终点不是新平台建好了——是旧平台可以关机了。
五、资产应用中心：让迁移后的资产"活"起来
资产迁移过来之后，如果只是"存在新平台里"，和存在老系统里没有本质区别——换了一个仓库而已。
奥腾资产应用中心是资产迁移完成后的统一运营平台——不只是资产目录，而是贯穿"接入→治理→评估→上架→应用→运营→退出"全生命周期的管理闭环。
这个闭环的核心价值在于：资产不是"上架即结束"，而是"上架才开始"。 上架之后，每一次检索、每一次申请、每一次调用都被记录。长期没人访问的资产，触发低活跃复核——是治理不到位没人发现？还是本身就没有业务价值？前者打回治理，后者下架退出。
资产中心不是"把数据摆出来"，而是让资产可发现、可理解、可申请、可共享、可运营、可退出。
六、迁移的四类对象：不是所有东西都叫资产
整篇文章反复提到一个概念——不是所有从老系统搬过来的东西都值得叫"资产"。落到操作层面，迁移对象分四类：
一个运行了五年的老平台，第四类对象通常占总量的 30%-50%。 这些东西如果不加区分地搬进新平台，就是在给新家堆垃圾。
结语
老旧数据平台的迁移，本质上是一次资产重构，不是一次数据搬家。
搬家思维是"把旧房子里的东西全部打包，搬到新房子里再整理"。结果搬完发现：三十年前的旧报纸搬过来了，破了的塑料袋搬过来了，甚至上一任租客留下的垃圾也搬过来了。
资产重构思维是"在新房子里重新建立秩序"。老房子只做一件事——盘点清楚每个房间里有什么。搬的时候分区搬：值钱的东西放进新家的展示柜（资产上架），不确定的东西放进储藏室（待评估区），确定没用的东西直接扔掉（退出清理）。到了新家之后，每件东西重新登记、重新分类、重新评估、定期复核。
迁移不是把旧平台的数据拷到新平台，而是在新平台上重新回答三个问题：这些数据是什么？它们值不值得留？它们应该怎么管？
老系统负责"看清楚"，新系统负责"治明白、管起来、用起来"。
迁移的终点，不是新平台上线——是旧平台关机。