少个分号

这个话题来自网友提交和项目上真实的案例，即如何实现企业内部多个应用之间的数据交换。

这个话题非常实用，我们先从问题开始聊起（在很多系统设计的过程中，我们发现问题比答案有时候更有价值，因为问题贴合业务价值）。

问题

案例 1 业务和推荐系统集成

假设有两个系统，分别是 A 系统和 B 系统。A 系统是一个事务处理系统，而 B 系统则是一个算法和推荐系统。A 系统向 B 系统提供了一组数据，而 B 系统则根据主数据和业务数据生成了一份业务中间处理结果。

问题是：A、B 系统如何进行数据交换，以进行后续的业务处理？

案例 2 保单遗留系统迁移

某保险公司新开发了一套保单系统，业务部门希望实现渐进上线，也就是新旧系统并存。如何应对这一挑战？同时，我们需要考虑如何迁移数据以及保持数据同步，同时满足以下约束条件：

  • 外部系统对接：新旧系统都需要与外部系统进行集成。
  • 定时任务：新旧系统都包含定时任务。
  • 数据共享：新旧系统需要能够访问并共享彼此的数据。

案例 3 业财一体化异步处理

某企业数字化转型，需要实现业财一体化，在这个过程中，其数据处理方式和传统的业务系统略有不同。

如何有效处理大量订单的周期性财务结算和对账，以确保准确性和效率？且同时满足以下关键要求：

  • 大量数据处理：面对大量订单数据，如何高效地进行数据处理、清洗和整合，以便进行结算和对账操作？
  • 数据溯源：如何追溯统计数据来源，并核对准确性。
  • 数据工程成本：如何减少数据成本？
  • 报告和洞察：如何生成有用的结算报告和数据可视化，以便管理层能够了解业务的财务状况和趋势？

案例 4 基础数据提取

某企业新创建的系统需要一些基础数据，这些基础数据来自于现有其它系统。例如，用户数据来自 IAM，品类数据来自于产品管理系统。

对于新创建的系统来说，如何使用企业内现有的基础数据？

常见解决方案

如何实现数据集成呢？根据经验，我们可能有常见方案:

  • 共享数据库
  • API 实时调用
  • MQ
  • 人工数据重新配置（例如 Excel 数据导入）
  • 使用 ETL 或 CDC 等数据同步平台
  • MDM（主数据管理系统）
  • 数仓

下面逐个分析这些方案的利弊，以及适用场景。

共享数据库

共享数据库是一种直接的数据同步和共享的方案，顾名思义，直接访问对方数据库。其优点和缺点如下：

优点：

  • 实时数据共享：共享数据库可以实现实时数据共享，多个系统可以立即访问和更新数据，确保数据的及时性。

  • 数据一致性：由于所有系统使用的是同一个数据库，因此可以确保数据的一致性，减少了数据不一致的可能性。

  • 简化开发和维护：相对于其他复杂的数据同步解决方案，共享数据库可能更容易实施和维护，尤其是在小型系统中。

缺点：

  • 安全性风险：共享数据库可能导致安全性风险，因为多个系统都能够直接访问数据库。必须严格管理数据库的访问权限，以防止数据泄露或不当访问。

  • 性能问题：多个系统同时访问数据库可能导致性能问题，特别是在高负载时，可能会降低数据库的性能（可以用从库解决这个问题）。

  • 紧耦合：共享数据库会导致系统之间的紧耦合，如果一个系统的数据库结构发生变化，可能会影响其他系统的功能，增加了维护的复杂性。

  • 难以扩展：共享数据库可能难以扩展到大规模系统，因为性能和一致性的问题可能会变得更加复杂。

在早期的项目中，共享数据库非常常见。但是由于多个团队都拥有数据访问权限和变更，会导致各种技术、管理上的问题，在业界已经不再推荐，同理也不推荐多个微服务直接共享数据库（权责利边界问题）。

不过，可以作为特殊场景下的权衡方案。

API 实时调用

API 实时调用一般是指使用 RESTFul 风格的 API 调用，是系统之间最常用的数据交换方式。

优点：

  • 实时性：允许实时数据传输和更新。
  • 灵活性：可适应各种数据格式和需求，且可以封装业务逻辑（最重要的一点）。

缺点：

  • 维护成本：需要投入资源来开发和维护 API。
  • 性能挑战：高频率 API 调用可能导致性能问题。
  • 成本：需要成本来处理开发和维护。
  • 同步：API 调用往往是同步进行的，如果需要改造成异步实现，需要额外成本。

对于少量、实时性要求高、封装有业务逻辑和动作的场景，可以使用 API 的方式交换数据。

MQ

和 API 类比的方案自然是 MQ，例如 Rabbit MQ 或 Kafka。

优点:

  • 异步通信：MQ 支持异步通信，不需要实时等待响应，提高系统的可伸缩性和性能，以及可靠性。
  • 消息重试：MQ 通常支持消息重试机制，以处理消息传递失败或处理失败的情况。

缺点：

  • 复杂性：配置和管理 MQ 系统可能会比较复杂，特别是沟通文档，没有 API 友好。
  • 错误处理：在处理消息传递失败或消息处理失败时，不好 Debug。

MQ 需要结合 API 使用，从维护和管理上来说，在应用之间集成尽量使用 API。

人工数据重新配置（例如 Excel 数据导入）

对于案例 4 的场景，很多企业会使用人工数据重新配置（直接拷贝过来用），例如使用 Excel 数据导入的方式，其实也是一种方案。

优点：

  • 灵活性：用户可以根据需要手动配置和处理数据，适用于小规模的数据导入和处理任务。
  • 成本低廉：不需要开发程序，适合一次性处理的场景。
  • 业务再优化：在配置的过程可以对数据进一步清晰、整理（关键要素）。

缺点：

  • 无法应对更新：对于需要频繁数据导入或大规模数据处理的任务，人工方法不切实际，难以扩展。
  • 不适用于实时需求：无法满足需要实时或高频数据同步的场景，因为它是手动的过程。

很多人调侃企业信息系统的日常就是用户从一个系统导出 Excel 再导入另外一个系统，现代企业信息化改造和数字化转型就是解决这类问题。

让信息系统从能用到好用，再到一体化的过程，所以应该谨慎使用人工数据重新配置的方案。

使用 ETL 或 CDC 等数据同步平台

ETL（Extract, Transform, Load）和 CDC（Change Data Capture）都是数据同步和处理的技术，用于将数据从一个地方移动到另一个地方。

ETL 的关键步骤包括提取、转换、加载。CDC 可以视为 ETL 的一种，CDC 是一种用于捕获数据变更的技术（Mysql 基于 BinLog，PostgreSQL 基于 WAL），它关注的是源数据的变动，以便及时将这些变动同步到目标系统。

ETL 方案的特征是对应用透明的数据迁移，而 CDC 通常需要数据库支持。。

ETL 优点：

  • 批处理处理：ETL 通常按批处理方式执行，适用于处理大量数据和定期数据同步需求。
  • 数据转换和清洗：ETL 允许对数据进行复杂的转换、清洗和整合，以满足目标系统的需求，确保数据质量和一致性。

ETL 缺点：

  • 延迟：由于是批处理，ETL 可能会导致一定的数据同步延迟，不适用于实时需求。
  • 复杂：ETL 过程可能需要复杂的数据转换和处理逻辑，需要更多的开发和维护工作。

CDC 优点:

  • 实时或近实时同步：CDC 可以捕获源数据的变更并实时或近实时地同步到目标系统，适用于需要快速反应的场景。
  • 数据实时性：CDC 确保目标系统与源系统的数据保持同步，有助于提高数据的实时性。

CDC 缺点:

  • 复杂：实时数据同步通常需要更多的技术和架构复杂性，需要具备相应的技术知识。
  • 数据一致性：需要确保CDC过程的稳定性和数据一致性，避免数据丢失或冲突。
  • 无法业务干预：无法在 CDC 传输过程中执行额外的业务逻辑，例如解析数据并做一些 API 查询，这点往往是 CDC 最致命的缺点。

ETL 和 CDC 都需要团队中有专业的数据工程师或者精通数据操作能力的人，前期投入成本比较高，但是平台搭建好后可以长期受益。

CDC 和 MQ 的方案有一些重叠，不过 MQ 更多的是指应用层面的消息发送，CDC 是通过 MQ 直接传输数据库变更。

MDM（主数据管理系统）

MDM 是主数据管理系统（MDM，Master Data Management）的英文缩写，它是一种用于集中管理和维护组织中关键的主数据的技术和方法。

主数据通常是指与业务操作和决策密切相关的核心数据，例如客户信息、产品数据、供应商信息。

MDM 系统通常有下面的特性：

  • 数据收集和整合：MDM 系统从各个数据源（如 ERP 系统、CRM 系统、数据库等）收集主数据，并将其整合到一个集中的存储库中。
  • 数据标准化：MDM 系统可用于标准化主数据，确保数据采用一致的格式和规范（关键要素）。
  • 数据共享：MDM 系统允许多个应用程序和系统访问和共享相同的主数据，确保数据的一致性和可用性。
  • 数据版本控制：MDM 系统允许记录和管理主数据的不同版本，以便跟踪和审计数据的变更历史。

MDM 非常适合案例 3 中的需求，有些 MDM 系统还搭配有小型的 ETL 能力，通过 Pull、Push 的方式集成企业内部基础数据。

优点：

  • 数据一致性：MDM 系统确保主数据在整个组织中的一致性，避免了不同部门或系统中的数据不一致性。
  • 数据集成：MDM 系统集成多个数据源，确保各系统使用的数据是同一版本的主数据，消除了数据孤岛问题。

缺点：

  • 数据治理：MDM 系统需要强大的数据治理策略和流程，以确保数据的一致性和质量。
  • 数据所有权：确定主数据的所有权和管理责任可能会引发组织内部的问题和争议。
  • 适用范围：MDM 通常只适用于主数据管理，不进行 ETL、数据分析等能力，也不适用于业务数据集成。

MDM 的定位非常清晰，只做主数据管理，相比后面介绍的数仓相比同时具有轻量级的特点。

数仓

最后一个方案是数仓，也是最重的一个方案。数据仓库（Data Warehouse）是一个用于集中存储和管理组织内部各种数据的专用数据库系统。

数仓的常见特点：

  • 数据整合：数据仓库从多个数据源（例如操作性数据库、日志文件、外部数据等）中提取数据，并将其整合到一个集中的存储库中。这确保了数据的一致性和可用性。
  • 数据清洗和转换：数仓平台通常集成了 ETL，可以用于数据清洗、验证和转换，以确保数据的质量和一致性。
  • 拓展性强：数仓架构中，通常会将数仓进行分区，包含 Staging、Marts 等区域。Marts 为数据集市，通过集市和消费数仓的数据对接，可以让数仓适用于几乎所有联机应用。
  • 数据溯源：数仓可以通过对数据来源进行追溯，构建数据被加工前后的关联关系，实现对数据溯源（俗称血缘分析）。

数仓尤其适合处理案例 1 和案例 4 的问题，用于数据结果交换，主数据录入、提取、消费等场景。

当然，数仓的代价是比 ETL 更重，甚至需要一个专门的团队才能运转。

案例和方案总结

结合上面这些常见方案，我们对文章前的几个问题进行归纳。

案例 1 业务和推荐系统集成

可参考方案：

  • 业务系统 ETL 进推荐系统，并通过 API 提供给前端输出推荐结果。
  • 如有数仓使用数仓的 ETL，推荐系统使用数据集市完成。

设计原因：

  • 推荐系统往往没有实时需求，ETL 是一个性价比不错的方案。
  • 推荐系统可以作为独立的服务，能提供完整的推荐能力给前端，业务系统往往不需要再使用推荐结果。

案例 2 保单遗留系统迁移

可参考方案：

  • 使用 ETL，但可以不用进仓，直接在新老系统之间交换数据。

设计原因：

  • 不建议仅仅为了数据迁移而进仓，数据仓库是个中心化的系统，在其它业务系统无需消费的情况下无需使用过长的数据链路。
  • 不建议使用 CDC，因为可能需要使用做一些业务映射，而不是单纯的数据同步。

案例 3 业财一体化异步处理

可参考方案：

  • 如果需要实时触发结算动作，推荐使用 MQ 或者 Flink 等流计算平台。
  • 如果不需要实时结算，可以使用 ETL 作业。

设计原因：

  • 业务结算对结算时点敏感，T+1 作业可能不能满足需求，所以数仓通常不适合。

案例 4 基础数据提取

可参考方案：

  • 如果已经有数仓平台和团队，优先使用数仓。
  • 如果有 MDM 平台，可以使用 MDM 平台。
  • 如果都没有，优先使用手动变更。
  • 如果没有基础设施，业务希望自动更新，则可以使用定时任务通过 API 更新基础数据。

设计原因：

  • 取决于基础设施，选择性价比合适的方案。

参考资料

[1] https://medium.com/@ramesh.esl/change-data-capture-cdc-in-postgresql-7dee2d467d1b

[2] https://datacater.io/blog/2021-09-02/postgresql-cdc-complete-guide.html

[3] https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-a-data-lake/#data-lake-vs-data-warehouse

[4] 部分内容参考使用了 ChatGPT 结果

Last Updated:
Contributors: lin