可以想象,我们的应用程序需要从关系数据库到另一个关系数据库的ETL(提取,转换,加载)数据.
最简单(和性能最好的IMHO)方式是在数据库之间建立链接并编写简单的存储过程.在这种情况下,我们使用最小的技术和组件,所有功能都是“开箱即用”.
最简单(和性能最好的IMHO)方式是在数据库之间建立链接并编写简单的存储过程.在这种情况下,我们使用最小的技术和组件,所有功能都是“开箱即用”.
但是SOA(面向服务的体系结构)的良好做法？紧耦合怎么办？我们是否坚定地将数据库相互联系在一起？
还有另一种方法可以做到这一点：我们在每个方面构建2个java应用程序,并通过SOAP Web服务进行通信.这更加SOA友好！但性能下降和其他失败点值得吗？
在这种情况下最好的做法是什么？ ETL如何适应SOA？
解决方法
在SOA中,您可以适应
Biztalk或
SAP BusinessObjects Data Integrator的处理方式.基本上,它是一个调度程序作业/ Windows服务,或类似的东西.您提供两个服务点,1个为调度程序检索数据,另一个为调度程序发送数据.调度程序在这里的责任只是定期运行和转换数据.
所以,基本步骤是：
步骤1：调度程序运行并从服务A获取数据
Scheduler --get--> Service A Service A --data--> Scheduler
步骤2：调度器进行数据转换
[ 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?
性能影响将会发生,因为现在您有额外的连接/认证步骤(webservice)和运输步骤(通过协议的web服务调度程序).但是出于容易出错的问题,我认为与其他服务调用需要处理的错误相同.
这值得么？这取决于.如果您在相同的环境中工作(相同的数据库),那么这是有争议的.如果您在不同的环境中工作(例如,从Asp.Net到SAP或至少不同的数据库实例两个不同的系统),那么这种体系结构是处理ETL的最佳选择.
