当人们无法理解复杂技术时，它就会失败。我将高压技术决策转化为清晰的故事，从而节省预算和精力。
假设你继承了一个储物单元。来自一个你几乎不认识的朋
你发现到处都是箱子。没有一个贴了标签。它们可能是宝藏，也可能是垃圾。
你有两个选择来弄清楚。自己翻遍每一个箱子。这个过程很慢，但这样你不会错过任何东西。或者你可以叫一家遗产清理公司来快速清空。这是一个快速的过程，但他们在清理储物单元时可能会把你奶奶的照片连同垃圾一起扔掉。
现在，数据迁移也是如此。只不过那些箱子是遗留的旧数据库——那些多年没人碰过、放在某个过时服务器上、月复一月、没人记得设置过的数据库。
而可怕的部分呢？嗯，大多数数据迁移失败并不是因为规划不善。它们失败是因为没人知道那些多年前创建的遗留数据库里有什么。事实上，研究表明，在迁移进行之前，没人能发现隐藏的数据问题。而到那时，已经太晚，无法围绕它制定计划。到那个地步，这只是一项昂贵的清理工作。
所以问题来了。如果你遇到这样的情况，你宁愿自己梳理每一个数据库？还是让 AI 来做这项昂贵的清理工作？
嗯，两者都能让你到达同一个地方。但如何到达那里，才是真正产生所有差异的关键。
所以，让我们先深入探讨老派的方法。
当你使用自定义 ETL 时会发生什么
在这种情况下，你的开发人员需要自己编写每一个脚本。他们映射每一列。他们从零开始构建每一个自定义的提取-转换-加载（ETL）脚本，以实现无缝迁移。
除非开发人员决定应该移动，否则什么都不会动。这其实就是关键所在。
那么，为什么这很重要：你对迁移过程拥有完全控制权。如果某个东西在数据管道中，那是有人出于他们能解释的原因把它放在那里的。当风险极高时——财务记录、医疗记录、客户 ID 号码，任何一旦出错就意味着官司而非仅仅糟糕一天的事情——这一点至关重要。当有人问“为什么这个数据映射是这样做的”，会有一个实际的答案。一个人、一个决定、一段你可以指出的代码。
但麻烦的部分在于：这很累人。你的开发人员要花数周时间解读某个开发人员在 2016 年构建、离职前从未解释过的系统。他们现在不是在构建任何新东西。他们只是在试图弄清楚那个开发人员的意思。每一个没有文档的列都是一次小查询、一个问号，而这样的列有数百个。事情拖得很久。预算不断消耗。你最好的人，那些本应构建新东西的人，却卡在那里当侦探。
想象一下让 AI 掌控
AI 不只是重写你的遗留旧代码。AI 会读取它。它会理解它。它会弄清楚你的数据如何连接。然后以极快的速度构建新的管道。
资深工程师需要四周才能完成的事情？AI 只需一个提示就能完成。
那么，为什么你应该认为它有益：因为 AI 保证了速度。令人瞠目结舌的速度。不再需要手动编写样板代码，不再需要逐列映射数据。IDC 发现，AI 辅助迁移相比手动迁移可将时间缩短 30% 到 50%。这意味着数周变成了仅仅几天。你的团队快速交付成果，在不超出预定时间线的情况下满足客户需求，开发人员可以专注于核心工程任务，而不是把整个季度埋没在工程部门以外永远不会有人注意到的脚本中。
但 AI 可能不是最佳选择，因为它会撒谎。不是故意的——它只是在猜测，而有时猜测是错的。一段编码脚本可能看起来没问题且完美无瑕。而 AI 仍然可能悄悄地把一个数字从 68 翻成 86，错误地四舍五入一个小数，或者漏掉深埋在三个连接中的边缘情况。主要问题是，它看起来没有任何糟糕或损坏的地方。一切似乎都很完美。这个错误可能今天不会出现。但遗憾的是，它会在一个月后出现，静静地躺在某人即将向管理层展示的销售报告里。
实际的遗留系统
我曾参与过一个 2016 年构建的旧订单系统。我发现它是一张巨大的表。没有任何文档。构建它的开发人员已于 2017 年离职。
-- Legacy table (MySQL) CREATE TABLE ord_mst ( ord_id INT, cust_nm VARCHAR(50), ord_dt VARCHAR(6), -- '050319' = 5 March 2019? Or 3 May? Nobody knows. amt INT, -- 45050 means $450.50. Yes, cents. sts CHAR(1) -- 'A', 'C', 'X', 'P'... no legend anywhere );
每一列都令人困惑。这就是我之前提到的“侦探工作”。
我不得不在多个部分中融入 AI
我将模式、一些样本行和遗留过程提供给 AI。仅仅几分钟内，AI 就帮助我起草了新表和一个非常有用的转换逻辑。这是工程师们过去需要花费数周时间做的苦差事，而 AI 出手相救，在几天内就完成了。
-- AI-drafted target table (Postgres) CREATE TABLE orders ( order_id INT PRIMARY KEY, customer_name TEXT NOT NULL, order_date DATE, amount_usd NUMERIC(12,2), status TEXT ); -- AI-drafted transformation INSERT INTO orders SELECT ord_id, TRIM(cust_nm), TO_DATE(ord_dt, 'DDMMYY'), amt / 100.0, sts FROM legacy.ord_mst;
然而，尽管表面看起来干净，我注意到了一个 问题。
我让我的工程师手动运行任务，以验证 AI 是否 100% 正确
我的工程师团队仔细检查了 AI 无法知道的业务规则。我的工程师询问财务团队 sts 到底是什么意思。结果发现 'X' 意味着已取消，而 'C' 意味着已完成。而 AI 猜的正好相反。这真是个不小的失误。于是，我的工程师打开遗留代码结构来确认日期格式。
-- Engineer-written fix: real status meanings, confirmed with finance CASE sts WHEN 'A' THEN 'active' WHEN 'C' THEN 'completed' WHEN 'X' THEN 'cancelled' WHEN 'P' THEN 'pending' ELSE 'unknown_review' -- never guess, flag it END AS status
那个 unknown_review 行是个救星。坏行立即被标记出来，而不是继续被错误标记。
我们犯了一些错误，也做出了一些重要的权衡
现在，我想在这里诚实地说。是的，AI 在项目中犯了真正的错误。它猜测日期格式为 DDMMYY，但遗留格式使用的是 MMDDYY。所以，每个三月的订单都变成了五月的订单。速度导致在多个领域做出了妥协：我把节省下来的时间花在了审查关键部分上。这是值得的，因为我们在上线前发现了严重错误；否则，它们可能会导致更大的失误。
-- Caught in review: date format was wrong -- Before (AI): TO_DATE(ord_dt, 'DDMMYY') -- After (engineer): TO_DATE(ord_dt, 'MMDDYY')
验证最终结果
我在遗留结构和较新格式之间进行了对账检查：行数、总计、对真实订单的检查。
-- 1. Row counts must match SELECT (SELECT COUNT(*) FROM legacy.ord_mst) AS old_rows, (SELECT COUNT(*) FROM orders) AS new_rows; -- 2. Money must match to the cent SELECT (SELECT SUM(amt)/100.0 FROM legacy.ord_mst) AS old_total, (SELECT SUM(amount_usd) FROM orders) AS new_total; -- 3. Any rows that fell through the cracks? SELECT * FROM orders WHERE status = 'unknown_review';
只有在我们的计数和总计匹配后，我才接触生产环境。
在相同条件下，你会选择自定义 ETL 还是 AI？
别想太多。问这六个问题。我们用 ord_mst 迁移作为衡量标准。
| 考虑因素 | 选择自定义 ETL 如果…… | 选择 AI 迁移如果…… | | --- | --- | --- | | 数据敏感性 | 一个错误的数字会触及真金白银。想想银行记录或健康数据。我们的 amt 列用于财务报告。一个错误的总数，就是危险信号。 | 如果某个值有偏差，没有人会被起诉。 | | 代码库状况 | 像 sts 和 ord_dt 这样的列有数据字典。或者构建一切的开发者还在那里工作。 | 它看起来像 ord_mst。晦涩的名称。零文档。开发者已经不在那里工作了。让 AI 起草第一版。 | | 隐藏的业务规则 | 含义只存在于人们的头脑中。'X' 表示取消还是完成？AI 在我们的案例中猜错了。 | 规则写在 AI 可以读取的地方，比如存储过程或清晰的代码注释。 | | 团队能力 | 你的工程师有时间手写和审查每个映射。 | 你的团队人手紧张。AI 在几分钟内起草。工程师只审查有风险的部分。 | | 数据量和错误成本 | 你要移动数百万行。一个错误的日期格式（DDMMYY vs MMDDYY）可能会让情况变得更糟，而且之后修复可能很麻烦。 | 这是一个相当可管理的数据集。如果看起来有错误，你可以在几分钟内重新运行加载。 | | 验证能力 | 你没有真实的旧总数可以比较。你无法证明输出是正确的，所以必须由人工准备逻辑。 | 你可以轻松对账。行数匹配。总数精确到分。异常行会被标记（比如我们的 unknown_review）。 |
现在你必须注意一件事。大多数真实项目不会落在表格的一边。
例如，看看我们的。数据是敏感的（钱）。代码库一团糟（没有文档）。业务规则是隐藏的（sts）。但我们可以用简单的对账查询验证一切。
那我做了什么？我把它拆分了。我让 AI 起草表和转换。同时我让我的工程师负责状态码、日期格式和最终检查。
这就是我遵循的模式。只要某一行偏左，我就安排一个人。只要某一行偏右，我就让 AI 运行任务。
我的建议
不要选边。选择一个拆分。
让 AI 做单调、重复、低风险的任务。让你的人负责敏感逻辑和有风险的部分。就这样。这就是整个剧本。
想象一辆在高速公路上行驶的自动驾驶汽车。巡航并行驶数英里。
但你仍然把手放在方向盘附近。不是吗？
记住，在速度不会伤害你的地方追求极速，在错误真正让你付出代价的地方保持谨慎。一旦你做到这两点，你就不再需要在破产和精疲力竭之间做选择。
关于作者
复杂的技术在人们无法理解时会失败。我将高压技术决策转化为清晰的故事，从而节省预算和精力。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文来源：Hacker Noon
原文作者：aparnamitra；如有侵权，请联系管理员删除。
