SAP数据集成从源系统到目标系统：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。