前不久，我经历了一个数据迁移项目。前几天和一个架构师讨论了当时的各个步骤，以及我选择和进一步开发的方案。我觉得应该告诉他一些信息，以免他以后迁移数据的时候踩坑。在我们的谈话中，我提到了我们遇到的各种数据迁移挑战和问题。现在我意识到这些东西对很多从事数据迁移项目的人都有用。我听说这些是非常普遍的问题，最有可能被正在进行数字化转型的公司遇到。数据迁移项目通常是一种解决方案，可让您将遗留数据提取、转换和存储到新系统中。没想到我在软件行业只参与过一个数据迁移项目。感觉又回到了当年苦苦学习SQL的年代。那是一次有趣的经历，你在Oracle和MariaDB上都使用PL/SQL，并且有很多头疼的事情。您只能自己猜测哪个是旧系统，哪个是闪亮的新系统。不过今天不说这个，说说我认为导致延迟发货的最大坑。意见是我自己的，但每个人都会发生这种情况，等等等等。1.以SQL脚本为主要工具这是昨天早上忘记跟同事强调的问题，今天早上又冒出来了。不要误会我的意思，SQL是一种强大的数据检索和显示工具。但是当你有一个由多个开发人员组成的团队在同一个代码库上工作时，确保你的更改与其余代码很好地集成是至关重要的。问题在于，在验证不同场景时，我们不能只花几秒钟或几分钟来运行典型的单元测试。我们必须进行实际迁移，因此我不会将其称为“集成测试”，因为集成测试环境与真实环境不同（稍后会详细介绍）。我们必须启动docker镜像，然后为我们将来使用真实数据处理的每个场景加载虚拟数据。我觉得我们的Jenkins构建一次需要2-3个小时才能完成。这使得本地开发变得更加困难，因为没有人愿意花5分钟更改代码，然后再花2-3小时进行测试。最初我们更改为只运行我们需要的那些测试用例。那时候CI太慢了，我什至在去年发了一篇关于它的帖子。最后，我们将它缩短到40分钟，虽然仍然很慢，但考虑到我们正在做的事情，这可能是我们能做的最好的了。https://www.codingnagger.com/2019/01/31/slow-ci/现在我不是在谈论我自己的经历，而是关于我在那个项目中与之交谈的一些架构师，甚至在项目结束了，真正的编程语言可以让我们免于这种痛苦：你可以测试任意组件，完成检索、转换和加载操作只需要几秒钟。然后针对理想路径运行集成测试。我们本可以将CI构建时间控制在一分钟以内，从而节省大量时间。2、源字段和目标字段的不匹配是一个非常痛苦的痛点。我不是说源数据字段到目标数据字段的对应关系错误，而是说字段对应关系没问题，但是目标字段类型不对。由于数据的敏感性，我们在研究解决方案时无法访问真实数据。所以这种问题只有在生产环境运行的时候才会暴露出来。您的源字段可能是字符串，但目标字段是整数。当所有测试数据都是数字时这很好，但是当数百万个实体中甚至有一个或两个包含字母时，一切都结束了。也有数据被截断的时候，因为目标字段可以表达比源字段更小的取值范围。这种问题不是数据迁移项目的责任，因为目标系统不是我们设计的，但实际上我们在交付数据迁移方案时必须修复这种问题。是的，现实并没有那么理想。所以我在这里要强调的是，如果你是在构建新版本的系统，请确保新数据库字段的类型和格式能够与源数据相匹配。我们不能截断地址或电话号码，尤其是当我们的系统需要此类信息时。3.和其他团队的界限不清晰当时我的团队在做数据迁移。我们设计了一个将数据从这里移动到那里的解决方案。但如上所述，我们有时必须解决其他团队为各种功能而努力的目标数据库的问题。最重要的是，我不明白我的团队是如何成为其他团队的测试数据提供者的。这些团队不会将所有测试数据放在一起来测试它们的功能，而是会来找我们并为他们生成随机测试数据。回想起来，这样做是愚蠢的。因此，我们构建了一个测试框架，其中包含一个用于生成数据的类。在开发过程中，我们将这些数据存储在源数据库中，然后运行迁移过程以将这些数据提取、转换并存储在目标数据库中。这些数据随后从目标系统导出并发送给这些团队。我们不得不这样做，因为我们不想在我们的职权范围之外产生数据。但是，我认为我们做得太多了。我们应该控制“请创建您自己的测试数据”这一底线。帮助别人固然可以，但当我们没有做好自己的工作时，我们就无法做到。最终的结果是，我们负责整个项目的三个主要部分：数据迁移、目标数据库的问题修复以及为大家生成测试数据。4.不同环境的设置我记得当时并没有想太多关于各种部署环境的不同设置。开发环境、暂存环境和生产环境之间存在许多差异。显然，我们为此付出了代价。你可能会想，不同版本的Oracle数据库或者MariaDB数据库之间应该没有太大的问题吧？但是如果我告诉你下一个版本和这个版本之间的差异会破坏你所有的SQL脚本呢？就像必须用VALUE替换VALUES一样。想象一个在本地运行良好的迁移工具，然后你将它推送到一个缓慢的CI流程。然后你将它发布到一个环境中，运行迁移过程并检查，没问题。结果生产环境出了问题，因为生产环境的MariaDB版本太旧了。此外，生产环境是EC2实例，而暂存环境是RDS。该项目在开发和生产中具有完全相同的变量设置，但我对输出的差异感到惊讶。您摆脱了到处更改代码以在不同集成环境中工作的痛苦。应该证明您的解决方案可以在生产中运行的生产配置，但它看起来根本不像真正的生产配置，必然会导致问题。这绝对是我这次经历中最大的收获。5.总结我将在余生中继续吸取旧项目的经验教训。我什至会重新访问这篇博文，以确保我不会忘记这些课程，因为它们将在我下次进行数据迁移时派上用场。更好的是，其中一些经验教训不仅可以应用于数据迁移，还可以应用于其他领域。即便这次没有找到工具来做，但这篇文章讲到的经验让我相信，我应该找到一个好的工具来做好这件事。相信你已经拥有的信息是件好事，但“四处看看”也无妨。有时这些工具并不比SQL查询慢。其次，确保您的开发环境的设置尽可能与您的生产环境相匹配。这将避免许多集成问题。最后，当职责明确时，避免为自己承担更多妨碍工作的工作。塞尔吉奥·拉莫斯并不是世界上最好的后卫，因为他本赛季的进球数超过了菲尔米诺。最好的防守者是那些做他们最擅长的事情然后偶尔进球的人。
