这个话题来自网友提交和项目上真实的案例,即如何实现企业内部多个应用之间的数据交换。
这个话题非常实用,我们先从问题开始聊起(在很多系统设计的过程中,我们发现问题比答案有时候更有价值,因为问题贴合业务价值)。
问题
案例 1 业务和推荐系统集成
假设有两个系统,分别是 A 系统和 B 系统。A 系统是一个事务处理系统,而 B 系统则是一个算法和推荐系统。A 系统向 B 系统提供了一组数据,而 B 系统则根据主数据和业务数据生成了一份业务中间处理结果。
问题是:A、B 系统如何进行数据交换,以进行后续的业务处理?
案例 2 保单遗留系统迁移
某保险公司新开发了一套保单系统,业务部门希望实现渐进上线,也就是新旧系统并存。如何应对这一挑战?同时,我们需要考虑如何迁移数据以及保持数据同步,同时满足以下约束条件:
- 外部系统对接:新旧系统都需要与外部系统进行集成。
- 定时任务:新旧系统都包含定时任务。
- 数据共享:新旧系统需要能够访问并共享彼此的数据。
案例 3 业财一体化异步处理
某企业数字化转型,需要实现业财一体化,在这个过程中,其数据处理方式和传统的业务系统略有不同。
如何有效处理大量订单的周期性财务结算和对账,以确保准确性和效率?且同时满足以下关键要求:
- 大量数据处理:面对大量订单数据,如何高效地进行数据处理、清洗和整合,以便进行结算和对账操作?
- 数据溯源:如何追溯统计数据来源,并核对准确性。
- 数据工程成本:如何减少数据成本?
- 报告和洞察:如何生成有用的结算报告和数据可视化,以便管理层能够了解业务的财务状况和趋势?
案例 4 基础数据提取
某企业新创建的系统需要一些基础数据,这些基础数据来自于现有其它系统。例如,用户数据来自 IAM,品类数据来自于产品管理系统。
对于新创建的系统来说,如何使用企业内现有的基础数据?
常见解决方案
如何实现数据集成呢?根据经验,我们可能有常见方案:
下面逐个分析这些方案的利弊,以及适用场景。
共享数据库
共享数据库是一种直接的数据同步和共享的方案,顾名思义,直接访问对方数据库。其优点和缺点如下:
优点:
-
实时数据共享:共享数据库可以实现实时数据共享,多个系统可以立即访问和更新数据,确保数据的及时性。
-
数据一致性:由于所有系统使用的是同一个数据库,因此可以确保数据的一致性,减少了数据不一致的可能性。
-
简化开发和维护:相对于其他复杂的数据同步解决方案,共享数据库可能更容易实施和维护,尤其是在小型系统中。
缺点:
-
安全性风险:共享数据库可能导致安全性风险,因为多个系统都能够直接访问数据库。必须严格管理数据库的访问权限,以防止数据泄露或不当访问。
-
性能问题:多个系统同时访问数据库可能导致性能问题,特别是在高负载时,可能会降低数据库的性能(可以用从库解决这个问题)。
-
紧耦合:共享数据库会导致系统之间的紧耦合,如果一个系统的数据库结构发生变化,可能会影响其他系统的功能,增加了维护的复杂性。
-
难以扩展:共享数据库可能难以扩展到大规模系统,因为性能和一致性的问题可能会变得更加复杂。
在早期的项目中,共享数据库非常常见。但是由于多个团队都拥有数据访问权限和变更,会导致各种技术、管理上的问题,在业界已经不再推荐,同理也不推荐多个微服务直接共享数据库(权责利边界问题)。
不过,可以作为特殊场景下的权衡方案。
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 结果
-END-
文 | 少个分号 (转载请注明出处)
本文仅供学习!所有权归属原作者。侵删!文章来源: DDD和微服务 -shaogefenhao :http://mp.weixin.qq.com/s?__biz=MzA4Mzc2MzcyMQ==&mid=2247484954&idx=1&sn=becd19104293ad2fb8ec308412430d4f&chksm=9ff0317ca887b86ac8c8f6a446cfb910e599b9301bd053b34e49c3a4b3de0ebd7d848a1266ab&scene=21#wechat_redirect
文章评论