database - ETL(数据库到数据库)如何适应 SOA？

Question

让我们想象一下，我们的应用程序需要从关系数据库到另一个关系数据库的 ETL(提取、转换、加载)数据。最简单(也是最高效，恕我直言)的方法是在数据库之间建立链接并编写简单的存储过程。在这种情况下，我们使用最少的技术和组件，所有功能都是“开箱即用”的。

但这对 SOA(面向服务的架构)来说是好的做法吗？紧耦合呢？我们是否永远将数据库彼此强耦合？

还有另一种方法:我们在每一侧构建 2 个 java 应用程序，并通过 SOAP 网络服务进行通信。这对 SOA 更友好!但是性能下降和额外的故障点值得吗？

在这种情况下，最佳做法是什么？ ETL 如何适应 SOA？

Answer 1

在SOA中，你可以适配Biztalk或 SAP BusinessObjects Data Integrator处理方式。基本上，它是一个调度程序作业/Windows 服务，或类似的东西。您提供两个服务点，一个供调度程序检索数据，另一个供调度程序发送数据。调度程序在这里的职责只是定期运行和转换数据。

所以，基本步骤是:

第 1 步:调度程序运行并从服务 A 获取数据

Scheduler --get--> Service A
Service A --data--> Scheduler

第二步:调度器做数据转换

[ Conversion --> Conversion --> Conversion --> Conversion ]

第 3 步:调度程序将数据发送到另一个服务

Scheduler --data--> Service B

在 Biztalk 和 SAP BusinessObject Data Integrator 中，步骤都是可配置的(它们可以从任何服务中检索并可以执行脚本数据转换)，因此更加灵活。

但是，ETL 处理仍然会出现常见问题。例如:数据太大、网络性能影响、RTO、重复数据等。因此 ETL 最佳实践仍然是这里的要求(使用暂存表、日志记录等)。

But are the performance degradation and additional points of failure worth it?

性能影响将会发生，因为现在您有额外的连接/身份验证步骤(到 web 服务)和传输步骤(通过协议(protocol)从 web 服务到调度程序)。但对于容易出错的问题，我认为这与您需要处理其他服务调用的错误相同。

值得吗？这取决于。如果您在相同的环境(相同的数据库)中工作，那么这是有争议的。如果您在不同的环境中工作(例如，两个不同的系统，从 Asp.Net 到 SAP，或者至少是不同的数据库实例)，那么此架构是处理 ETL 的最佳选择。