旧数据与新系统——重现数据迁移之旅

数据安全是与金钱紧密相关的重要环节，特别是在文件需要通过公网从AWS传输到GCP的情况下。因此，我们特别重视数据安全。虽然GCP已经提供了数据加密服务，客户仍然希望我们在应用程序层面增加额外的数据安全措施。基于数据安全的经典流程，我们在AWS端对文件进行加密和签名操作，并在GCP端完成文件的解密和验证。加密措施旨在防止数据在传输过程中被窃取，而签名则用于防止恶意篡改文件。

在数据合并方面，由于历史原因，老系统中的数据是从更老的系统迁移而来的（实际上，那个更老的系统仍在使用中）。老系统提供的API包含大量数据合并逻辑。如果从数据库源头迁移涉及数据合并的实体，将需要重写大量业务逻辑，这将是一个漫长且复杂的过程。如果直接使用当前系统的API进行迁移，由于涉及的数据量巨大，将对线上业务产生影响。

因此，我们采取了一种折衷方案，在生产环境中复制了一个只读实例，以避免对线上环境造成影响。在数据校验过程中，我们会根据业务规则对实体的各个字段进行校验，并将不符合规则的数据及其错误原因记录到错误日志表中，以便后续修正。尽管测试环境中的数据部分来自生产环境，但出于安全考虑，大部分字段都经过了混淆处理，因此难以收集到所有真实数据的错误，这使得迁移的最终结果难以保证。

为了确保数据质量，我们在上线前的几个迭代中，在生产环境中进行了多轮预迁移（但不执行加载）。每轮预迁移都会发现一部分数据错误，这些错误大多需要与客户讨论后处理，处理方式包括：客户确认并修复不合法的数据输入、根据新系统的表现形式重新确定转换逻辑、对于无法修复且不重要的数据则选择丢弃。经过多轮预迁移，我们修复了所有生产环境上的错误，确保了迁移到新系统的数据质量。

在数据审计与错误追溯方面，完成数据迁移后，我们需要进行审计和追溯以确保数据完整性。第一批数据迁移的设计导致审计和错误排查变得不友好，因为源数据转换后直接生成目标文件，分析文件时存在不便。为了解决这个问题，从第二批数据迁移开始，我们首先将转换后的数据存入中间表，实现了迁移过程的解耦。这一改变显著提升了数据审计和错误排查的效率。

在数据迁移的过程中，我们学到了很多东西。数据迁移不仅涉及三个系统之间的数据传输，还包括从AWS到GCP的云平台迁移，这个复杂过程中遇到了许多挑战。迁移不是一次性的操作，为了确保用户无缝过渡，保证多个系统的可用性和数据一致性至关重要。

实体间的依赖关系对迁移计划有很大影响。在迁移过程中，我们建立了依赖映射并监控了每个实体的迁移历史，以检查实体间的关系和依赖。出现错误时，无效数据和依赖于无效数据的数据将被过滤掉，以确保迁移过程的连续性。

保持数据的可追溯性是迁移过程的关键。通过确保所有数据都可以追溯到其来源，我们可以最大限度地减少数据丢失或损坏的风险，并确保整个迁移过程中数据的准确性和完整性。

为了确保迁移的成功，需要对复杂的业务逻辑进行彻底分析，并识别过程中可能出现的任何潜在问题。这包括将所有必要的字段映射到新系统，并解决源数据中可能存在的任何数据质量问题。

为了确保迁移过程中数据的质量，重要的是制定一个测试策略，并由团队中的每个人进行审查和维护。迁移的验证过程需要充分考虑数据完整性和无数据丢失，并确保在迁移后满足所有指定的功能和非功能方面的要求。

对于迁移期间的增量数据，我们采用事件驱动的方式，通过监听源数据库的新增或修改事件，并触发lambda函数执行转换过程，将转换后的数据存入中间表并记录修改时间。在生成增量数据文件时，通过查询所有比上次迁移时间晚的记录，得到所有增量数据并最终生成本次文件。