【Glue系列文章】从源系统到目标系统:SAP数据源和SNP Glue

当考虑SAP和基于云的数据仓库(例如Snowflake)之间的数据集成时,大多数架构师在考虑SAP的业务应用程序时会考虑表。一般来说,这当然没有错,但是值得关注更多可能更适合的数据来源。在这个glue文章系列中,我们将向您简述这些数据源,并且讨论不同数据源带来的一些限制和机会。




关于数据库表的提示和技巧

在我们查看除普通表以外的数据源之前,先了解一些关于数据库表的提示和技巧。

首先,需要注意的是:根据SAP版本的不同,某些表可能不是那么容易访问。例如,SAP会压缩一些表以有效管理数据库空间。在S/4HANA中,由于采用基于列的表存储方法,压缩是很正常的。例如,SAP R/3和ECC中的财务文档行项目等业务数据存储在表BSEG中。在数据库中,这个表根本不存在—它与其他一些财务表一起存储在称为RFBLG的BLOB样式表中。对于变更文档和其他一些主要的SAP表也是如此。


查看表时需要考虑的事项

其次,即使在看表格的时候,也有一些事情需要考虑:

■ 有些表包含非结构化数据,您不希望将它们1:1地公开给任何数据湖。例如长文本,还有文件附件都可以直接存储在SAP中。

■ 关键字:在模式创建期间,即当您在数据仓库上创建SAP-copycat表时,由于使用的关键字受到限制,您可能需要重命名一些列。这可能导致在SAP和数据湖/数据仓库/数据网格之间映射“fun”。


■ SAP表中的货币字段不带小数点。需要根据货币密钥的自定义来插入点。如果你所有的货币都是美元、欧元和其他带有两个小数点的货币,这可能不是问题。然而,如果您真的是全球化的,那么您的货币也会有或多或少的小数位。


■ SAP ERP最初是作为一种多租户SAP构建的。第一个关键字段“client”基本上是一个租户字段。


■ 您肯定希望使用一种集成解决方案,它能够以更小的开销和性能影响提供真正的增量捕获。您不希望定期从SAP到云数据存储执行全表加载,以避免对SAP的性能影响、复制大型表的长等待时间或数据过时。


■ 忽略“virtual tables”从数据仓库按需获取数据,虽然技术上可行,但这可能导致SAP数据库意外承受沉重负荷。


■ SAP中的一些数据可能被归档的,即它存在归档文件中(可能在归档服务器上),而不是直接在SAP表中。对于这种情况,可能值得研究您的集成解决方案可以访问SAP归档的能力(SNP Glue可以做到这一点,而大多数经典的ETL工具将会严重失败,考虑到数据已归档并且不再驻留在SAP中)。


SAP中要考虑的其他数据源

SNP Glue为所有这些数据源提供了现成的技术。当然,有些人可能比其他人更适合某种目的。例如,带有“重负载”的直接表访问对于大数据量可能更好,并且与使用SNP Glue的CDC一起用于近实时数据复制(以及streaming)非常强大。


然而,当您更喜欢在业务对象级别上工作时,您可以使用业务事件作为数据复制的触发器,例如,当SAP用户在SD模块中创建出站交付时,将数据发送到消息代理。在这个例子中, LIKP/LIPS 数据将在 SAP 中保存过帐后直接发送到(例如)Kafka。


我们经常听到的最后一个问题是:这也适用于SAP RISE吗? 答复是:是的,只是SNP Glue的设置和配置将与经典的本地安装略有不同。



更多新闻资讯请点击:

干活 | SAP数据如何集成到任意云平台 – snpgroup

如何将SAP数据抽取到Azure数据湖平台? – snpgroup

数据库迁移软件SNP Glue – SAP数据集成用例介绍 – snpgroup

SAP系统怎么抽取数据?  – snpgroup