28、净变更模式：数据集成的有效策略

净变更模式：数据集成的有效策略

在数据集成过程中，捕获源应用程序中的变更数据是设计的基础组成部分。下面将介绍一些关键的考虑因素以及四种常见的净变更模式。

1. 净变更捕获的关键考虑因素

在设计净变更捕获机制时，有以下重要因素需要考虑：
1. 效率 ：高效的净变更方法应根据集成过程的需求，尽量减少消息的数量和大小，从而减轻网络和相关应用程序的负担，使集成过程性能更佳、更不易出错且更易于故障排除。
2. 可靠性 ：强大的集成过程需要捕获并发布所有符合定义标准的记录修改和业务事件，否则会导致数据完整性问题和业务流程中断。
3. 防止回跳 ：在两个应用程序之间同步数据时，回跳或回声现象较为常见。为避免这种情况，需要具备忽略集成过程中产生的变更的能力。
4. 实时处理 ：许多集成过程要求在数秒或数分钟内处理变更，特别是在业务用户对同步数据的延迟要求较低或涉及对时间敏感的业务流程时。
5. 事务排序 ：跨多个应用程序的业务流程通常涉及多个事务的依赖关系，事务处理的顺序至关重要，确保正确的排序可以避免不必要的错误并减少“重试”处理。
6. 按需应用支持 ：按需或软件即服务（SaaS）应用程序通常不允许访问数据库层，这限制了建立净变更机制的选项，因此需要高效的处理方式。
7. 删除支持 ：某些设计模式对记录删除的捕获支持较少或不支持。
8. 保证消息传递 ：仅仅发布变更记录或业务事务是不够的，需要在端到端的集成过程中构建机制，以确保所有记录都能得到充分处理。
9. 多播支持 ：许多集成过程涉及两个以上的应用程序，此时变更记录或事务可能需要发布并处理到两个或多个应用程序。

2. 四种常见的净变更模式

2.1 模式 1：应用程序发布者

此模式利用源应用程序内的功能，根据源应用程序中特定事件的发生主动发布变更。它通常借助应用程序内的工作流功能，在很多方面类似于数据库触发器，但在应用程序级别运行。

优点 ：
- 提供实时、事件驱动的变更通知，无需对应用程序或数据库服务器进行轮询，无额外开销。
- 通常支持删除操作。
- 通常是一种高度可靠的方法，很少会忽略数据变更或事件。

缺点 ：
- 需要特定应用程序和适配器的发布者支持，只有应用程序架构提供变更通知或回调功能时才能使用，而大多数应用程序架构不支持此功能。
- 可能不支持按用户过滤以防止回跳。

实施提示 ：
- 变更通常按发生顺序排队，但不保证。可能需要设计集成过程来处理乱序消息，包括构建重试机制。
- 如果要一起发送标题/行项目（或主/明细）变更，需要确定所需的行项目变更是否总是触发标题通知。如果不是，也需要考虑行项目变更的通知。

2.2 模式 2：修改标志

该模式通过切换同步标志或字段来跟踪变更，当源应用程序中的数据发生变更时标志关闭，变更在目标应用程序中处理后标志打开。最常见的实现方式是在源应用程序数据库中创建数据库触发器和影子表。

操作步骤 ：
1. 为需要跟踪变更的每个应用程序基表添加触发器。
2. 触发器在影子表中添加或更新记录以跟踪变更。
3. 创建一个影子表，通过对象（表）名称字段和对象键（记录主键）的组合来跟踪多个应用程序表中记录的变更。
4. 当基表记录创建、更新或删除时，相应的影子表记录也进行更新。
5. 执行查询，将影子表与基表连接，以获取所有当前字段值。

优点 ：
- 通过在基表记录删除后保留影子表记录来支持删除操作。
- 支持双向集成并通过可靠的忽略用户机制防止回跳。
- 通过提供多个同步状态字段支持变更的多播。
- 具有内在的重试机制，因为记录在成功处理到目标应用程序之前不会标记为同步。

缺点 ：
- 如果应用程序无法配置为在每次插入和更新时切换字段值，可能需要数据库引擎触发器，这要求数据库引擎支持触发器。
- 需要详细了解物理数据库架构来开发脚本和触发器，并且需要掌握触发器编码知识。
- 这是一种轮询机制，本质上效率较低，无论是否有源变更，查询过程都会执行。
- 如果使用触发器和影子表方法，需要直接连接到数据库。
- 应用程序升级时，触发器可能会受到影响或被删除，需要保存触发器脚本以便重新应用。

实施提示 ：
- 应用程序逻辑或触发器代码应设计为，如果变更是由指定的“集成用户”应用的，则忽略该变更（不切换同步标志）。
- 可以在源查询中构建重试超时机制，通过将记录修改日期/时间戳与当前时间减去 x 分钟进行比较，在超过 x 分钟后停止。

2.3 模式 3：修改日期/时间戳

该模式使用基表或对象中的修改日期/时间戳字段来识别已更改的记录。通过查询源数据库，结合上次查询执行时的源系统时间作为“绑定变量”，可以识别自上次查询以来更新的记录。

操作步骤 ：
1. 确保应用程序表包含修改日期/时间字段，如果没有，可以尝试添加，但可能需要应用程序修改或数据库触发器。
2. 执行查询时，使用上次查询执行时的源系统时间作为绑定变量，以识别更改的记录。

优点 ：
- 支持将变更多播到多个系统，因为可以为多个源查询独立跟踪绑定变量。
- 如果应用程序表已经包含修改日期/时间字段，设置简单。
- 可以与任何支持过滤查询的应用程序 API 或数据源一起使用，无需直接连接到 SQL 数据库，适用于按需应用程序环境。

缺点 ：
- 对于双向同步过程可能不完全可靠，需要实现“忽略用户”过滤器来防止回跳，但可能会导致错过更新。
- 如果修改日期字段不是使用源数据库服务器（或应用程序服务器）的时钟设置，则在时钟同步方面存在重大挑战。
- 需要构建额外的功能来支持对目标应用程序的拒绝记录进行重试。
- 通常不支持删除操作，除非应用程序执行“软删除”，但软删除的清理通常不可预测。
- 如果同时跟踪父记录和子记录的变更，源查询可能会变得复杂。

实施提示 ：
- 集成过程应包含捕获未成功处理到目标应用程序的记录的机制，可通过消息队列或维护拒绝行表或文件来实现。
- 确保修改字段包含时间信息（不仅仅是日期）。
- 确保修改字段基于数据库（或应用程序）服务器，以避免时钟不同步问题。
- 在执行查询前，获取与设置修改日期/时间相同的数据库或应用程序服务器时钟的日期/时间，用于下一次查询。
- 确保修改日期/时间字段在数据库中是索引字段，以提高性能。
- 在实现双向同步时，研究是否可以抑制来自其他应用程序的变更对修改时间戳字段的更新，以避免错过更新问题。
- 如果一起捕获父记录和子记录的变更，检查是否所有子记录的必要变更都会导致父记录修改时间戳的更改，如果是，则可以仅使用父记录的时间戳。

2.4 模式 4：快照比较

该模式使用源应用程序数据集的精确副本，通过比较不同时间点的副本，逐行逐字段地识别新的、修改的和删除的记录。

操作步骤 ：
1. 在时间点 A 制作源数据的副本。
2. 在时间点 B 获取最新的源数据。
3. 将时间点 B 的数据与时间点 A 的副本进行比较，识别变更。
4. 识别变更后，制作新的源数据副本，用于下一次比较。

优点 ：
- 几乎可以与任何数据源一起使用，特殊系统和应用程序要求最少。
- 可以与任何支持有序查询的应用程序 API 或数据源一起使用，无需直接连接到 SQL 数据库。
- 不易出现因按用户过滤以避免回跳而导致的错过更新问题。
- 支持可靠的删除检测。
- 可以对处理进行定时或排序，以防止依赖记录的排序问题。
- 如果对未包含在集成中的源字段进行了更改，则不进行处理，减少了无变更消息的处理，降低了更新冲突的可能性。
- 可以将标题和行项目记录分组到一个消息中，以检测组内的任何变更，并生成单个标题和行项目消息或事务。
- 机制可靠，确保不会错过任何变更。

缺点 ：
- 创建过程可能很复杂，涉及大量编码。
- 检测变更的效率较低，可能需要花费数分钟的处理时间才能找到少量变更。
- 由于处理所有源记录需要很长时间，支持的频率较低（通常仅为每日）。
- 不包含防止回跳的机制，目标系统发起的所有变更都会完整循环回目标系统，可能导致更新冲突问题。

3. 总结

模式	优点	缺点	适用场景
应用程序发布者	实时通知、支持删除、可靠性高	需要特定支持、可能不支持过滤	应用程序架构支持变更通知且对实时性要求高的场景
修改标志	支持删除、双向集成、多播支持、有重试机制	需要数据库触发器、效率低、受升级影响	对删除支持和双向集成有要求的场景
修改日期/时间戳	多播支持、设置简单、适用于按需应用	双向同步不可靠、时钟同步挑战、不支持删除	单向同步且应用表有修改日期字段的场景
快照比较	数据源适用性广、可靠检测变更	创建复杂、效率低、不防回跳	对数据准确性要求高、对处理频率要求不高的场景

在选择净变更模式时，需要根据具体的业务需求、应用程序架构和数据特点进行综合考虑，以确保集成过程的高效性、可靠性和稳定性。

以下是模式 2 的流程图：

graph LR
    A[应用程序数据变更] --> B[数据库触发器]
    B --> C[更新影子表记录]
    D[查询影子表] --> E{IntegrationFlag = 0?}
    E -- 是 --> F[集成处理]
    F --> G{处理成功?}
    G -- 是 --> H[设置 IntegrationFlag = 1]
    G -- 否 --> I[重试]
    E -- 否 --> J[无操作]

通过对这些净变更模式的了解和合理应用，可以更好地实现数据集成，满足不同业务场景的需求。

4. 不同模式的性能对比与选择建议

4.1 性能对比

为了更直观地比较四种净变更模式的性能，我们从多个关键指标进行分析，如下表所示：
| 模式 | 实时性 | 效率 | 可靠性 | 对删除的支持 | 双向集成支持 | 多播支持 | 实现复杂度 |
| — | — | — | — | — | — | — | — |
| 应用程序发布者 | 高 | 高 | 高 | 通常支持 | 可能不支持过滤 | 一般 | 高，需特定应用支持 |
| 修改标志 | 低（轮询机制） | 低 | 高 | 支持 | 支持 | 支持 | 中，需数据库知识 |
| 修改日期/时间戳 | 低（依赖查询频率） | 中 | 中（双向同步有问题） | 通常不支持 | 需额外过滤 | 支持 | 低，设置简单 |
| 快照比较 | 低（处理时间长） | 低 | 高 | 支持 | 不支持防回跳 | 支持 | 高，涉及大量编码 |

从实时性来看，应用程序发布者模式表现最佳，能够在数据变更或应用事件发生时立即触发通知。而修改标志、修改日期/时间戳和快照比较模式都依赖于轮询或定期处理，实时性相对较低。

在效率方面，应用程序发布者模式由于只在特定事件发生时才采取行动，避免了不必要的查询和处理，效率较高。修改日期/时间戳模式在应用表已有相关字段时设置简单，也具有一定效率，但在双向同步和时钟同步方面存在挑战。修改标志和快照比较模式则效率较低，前者是轮询机制，后者需要逐行逐字段比较大量数据。

可靠性上，应用程序发布者、修改标志和快照比较模式通常较为可靠，能够准确捕获数据变更。修改日期/时间戳模式在双向同步时可能会出现问题，需要额外的过滤机制。

对删除的支持上，应用程序发布者、修改标志和快照比较模式通常可以较好地处理删除操作，而修改日期/时间戳模式一般不支持，除非应用执行软删除。

双向集成支持方面，修改标志模式通过可靠的忽略用户机制表现出色，应用程序发布者模式可能需要额外配置，修改日期/时间戳模式需要实现“忽略用户”过滤器，而快照比较模式不包含防回跳机制。

多播支持上，修改标志、修改日期/时间戳和快照比较模式都可以通过不同方式实现，应用程序发布者模式在一般情况下也可支持，但可能受应用架构限制。

实现复杂度上，应用程序发布者和快照比较模式较高，前者需要特定应用支持，后者涉及大量编码。修改标志模式需要一定的数据库知识和触发器配置，复杂度适中。修改日期/时间戳模式在应用表已有相关字段时设置简单，复杂度较低。

4.2 选择建议

• 实时性要求高 ：如果业务流程对数据变更的实时性要求极高，如金融交易系统、实时监控系统等，应用程序发布者模式是首选。它能够在数据发生变化的瞬间就发出通知，确保业务的及时性和准确性。
• 双向集成和删除支持 ：当需要进行双向数据同步，并且对删除操作有明确要求时，修改标志模式是比较合适的选择。它可以通过影子表和触发器机制，有效地跟踪数据变更，包括删除操作，同时通过可靠的忽略用户机制防止回跳。
• 单向同步和按需应用 ：对于单向同步场景，特别是在按需应用环境中，修改日期/时间戳模式是一个不错的选择。如果应用表已经包含修改日期/时间字段，设置简单，并且可以与各种应用 API 或数据源配合使用，无需直接连接到 SQL 数据库。
• 数据准确性要求高 ：在对数据准确性要求极高，对处理频率要求不高的场景下，如数据仓库的定期更新、历史数据的同步等，快照比较模式可以确保不遗漏任何数据变更。虽然它的处理效率较低，但能够提供最准确的数据同步结果。

5. 净变更模式的实际应用案例

5.1 案例一：电商订单系统与库存系统的集成

某电商企业需要将订单系统与库存系统进行集成，以确保订单处理时库存的实时更新。由于订单处理对实时性要求较高，该企业选择了应用程序发布者模式。

操作步骤 ：
1. 在订单系统中配置工作流，当订单创建、修改或取消时，触发相应的通知。
2. 订单系统的工作流将变更信息发送到集成处理模块。
3. 集成处理模块接收到通知后，对库存系统进行相应的操作，如减少库存、恢复库存等。

通过这种方式，订单系统的任何变更都能立即反映到库存系统中，保证了库存数据的实时性和准确性。

5.2 案例二：企业 CRM 与 ERP 系统的双向集成

一家制造企业需要将 CRM 系统和 ERP 系统进行双向集成，以实现客户信息、订单信息等的同步。由于涉及双向数据同步和删除操作，该企业采用了修改标志模式。

操作步骤 ：
1. 在 CRM 和 ERP 系统的数据库中创建影子表和触发器。
2. 当 CRM 或 ERP 系统中的数据发生变更时，触发器更新相应的影子表记录。
3. 定期执行查询，将影子表与基表连接，获取变更数据。
4. 对变更数据进行集成处理，将数据同步到对方系统。
5. 处理成功后，更新影子表中的同步标志。

这种方式确保了 CRM 和 ERP 系统之间的数据一致性，同时通过忽略用户机制防止了回跳问题。

5.3 案例三： SaaS 应用的数据同步

某 SaaS 应用需要将用户数据同步到多个外部系统，由于 SaaS 应用通常不允许直接访问数据库，该应用选择了修改日期/时间戳模式。

操作步骤 ：
1. 确保 SaaS 应用的用户表中包含修改日期/时间字段。
2. 定期执行查询，使用上次查询执行时的时间作为绑定变量，获取变更的用户数据。
3. 将变更数据发送到各个外部系统进行同步。

这种模式简单易用，无需直接连接到数据库，适合 SaaS 应用的特点。

5.4 案例四：数据仓库的定期更新

某企业的数据仓库需要定期从多个数据源更新数据，对数据准确性要求较高，但处理频率较低。该企业采用了快照比较模式。

操作步骤 ：
1. 定期制作数据源的快照。
2. 将最新的数据源数据与之前的快照进行比较，识别新的、修改的和删除的记录。
3. 根据比较结果更新数据仓库。
4. 制作新的快照，用于下一次比较。

通过这种方式，数据仓库能够准确地反映数据源的最新状态。

6. 未来发展趋势

随着信息技术的不断发展，净变更模式也将不断演进和完善。以下是一些可能的发展趋势：
- 智能化与自动化 ：未来的净变更模式可能会更加智能化和自动化，能够自动识别最适合的变更捕获方式，根据业务需求动态调整处理策略。例如，系统可以根据数据变更的频率、实时性要求等因素，自动选择应用程序发布者模式或修改日期/时间戳模式。
- 与新兴技术的融合 ：随着人工智能、机器学习等新兴技术的发展，净变更模式可能会与之融合，提高数据处理的效率和准确性。例如，利用机器学习算法预测数据变更的可能性，提前做好数据同步的准备。
- 云原生支持 ：随着云计算的普及，净变更模式将更好地支持云原生应用。云原生应用具有弹性伸缩、高可用性等特点，净变更模式需要适应这些特点，提供更高效、更可靠的数据集成解决方案。
- 安全与隐私保护 ：在数据集成过程中，安全和隐私保护越来越重要。未来的净变更模式将更加注重数据的安全性和隐私性，采用加密技术、访问控制等手段，确保数据在传输和处理过程中的安全。

7. 结论

净变更模式在数据集成中起着至关重要的作用。通过对四种常见净变更模式的详细介绍、性能对比和实际应用案例分析，我们可以看到每种模式都有其优缺点和适用场景。在实际应用中，需要根据具体的业务需求、应用程序架构和数据特点，综合考虑各种因素，选择最合适的净变更模式。同时，随着技术的不断发展，我们也需要关注净变更模式的未来发展趋势，不断探索和创新，以实现更高效、更可靠的数据集成。

以下是模式 4 的流程图：

graph LR
    A[时间点 A 制作源数据副本] --> B[时间点 B 获取最新源数据]
    B --> C[比较副本与最新数据]
    C --> D{有变更?}
    D -- 是 --> E[识别变更记录]
    E --> F[更新目标系统]
    F --> G[制作新的副本用于下次比较]
    D -- 否 --> H[无操作]

希望通过本文的介绍，能够帮助读者更好地理解净变更模式，为数据集成工作提供有益的参考。