介绍增强型分层可扩展架构 (LSA++)

学习目标

  • 描述 LSA++ 如何支持 SAP BW/4HANA 的最佳实践实施

在我们介绍新的增强型分层可扩展架构 (LSA++) 之前，有必要回顾一下为 SAP BW 引入的原始架构，因为它是新开发的基础。原始架构称为 LSA（没有 ++）。

分层可扩展架构 (LSA) — 旧有架构

SAP 围绕数据仓库领域的思想领袖之一 Bill Inmon 创建的最佳实践模型构建了分层可扩展架构 (LSA)。Inmon 模型（称为企业信息工厂，Corporate Information Factory）的基本原理是开发一组一致且高度可复用的数据建模层，包括数据获取、主存储和数据交付。“一次获取数据，多次传播”是这种方法背后的关键理念。SAP 在此架构基础上加入了自己的设计原则，例如在数据持久层与报表之间引入虚拟层。

让我们回顾一下 LSA 的各层以及用于实现这些层的对象：

  • 数据获取层：此层代表数据仓库与其源系统之间的接口。它从各种系统获取源数据，并启动 SAP BW 中的处理。数据以源系统的格式保存，尚未更改。此层的典型对象类型是 SAP BW DataSource 及其对应的 PSA 表。

  • 协调层：在此层，数据被调整为标准化形式。缺失的数据字段被添加，值被更正和转换。数据来自多个系统，因此此层的关键作用是协调数据，从而得到一致的数据集。协调工作的多少在很大程度上取决于数据的来源。此层不处理任何目标应用程序特定的逻辑；只应用对所有目标应用程序都有效的更改。如果需要多个转换，可以通过 InfoSource 将它们连接起来；不过在例外情况下，将数据持久缓存在 DataStore Object 中也是可以接受的。此层的典型对象类型是 Transformation 和 InfoSource。

  • EDW 传播层：此层代表系统的核心，因为它服务于所有 BI 应用程序。快速分发和可复用性是此层的关键目标。信息存储在 DataStore Object 中，在大型系统中这些对象还应进行语义分区。此层的典型对象类型是标准 DataStore Object。

  • 业务转换层：在此层，数据按照各个应用程序的单独要求（业务逻辑）进行转换。与协调层一样，InfoSource 使您能够链接多个转换规则。根据所需业务逻辑的复杂程度，可能还需要在 DataStore Object 中缓冲数据。此层的典型对象类型是 Transformation 和 InfoSource。

  • 架构化数据集市层：业务转换的结果存储在此层，以便可以为分析定义 SAP BW 报表。这里通常使用 InfoCube，以便快速灵活地处理结果数据。为进一步提高数据库性能，您可以创建额外的聚合、执行语义分区或使用 BW Accelerator。您还可以在此层映射计划场景。此层的典型对象类型是 InfoCube。

  • 虚拟化层：出于灵活性的考虑，始终建议在虚拟 InfoProvider 上创建查询。这将报表层与物理数据分离。此层的典型对象类型是 MultiProvider 和 InfoSet。

  • BW 报表层：在此层，各个数据集市的数据模型可供报表工具访问。报表的基础对象是报表定义，它以 SAP BW Query 的形式创建，并在运行时由 BW 分析管理器处理。此层的相关对象类型是 BW 查询。

  • 企业内存（Corporate Memory）：企业内存独立于所有其他层，由源数据填充。构建所加载数据的完整细粒度历史记录，这样在发生错误时，您无需依赖源系统进行重建。典型对象类型是写优化的 DataStore Object。

  • 运营数据存储（Operational Data Store） : 此区域用于运营性和及时的数据分析。源数据以较短的时间间隔抽取，并在适用时集成到 EDW 传播层中。除了这种资源密集型流程之外，您还可以虚拟且直接地访问数据，以更好地满足实时性要求。典型对象类型是 DataStore Object、虚拟 InfoCube 或 HybridProvider。

SAP HANA 优化的分层可扩展架构 (LSA++)

现在我们已经回顾了 LSA，接下来介绍为支持 SAP BW/4HANA 而开发的增强版本。它称为分层可扩展架构 (LSA++)。

LSA++ 在原始 LSA 概念的基础上进行了以下创新：

  • 新方法提供了 高度的灵活性 ，因为各层不再是强制性的。您只需实现自己需要的层。各层不再严格相互依赖，数据可以从每个单独的 LSA++ 层消费。这意味着业务需求驱动每个应用程序的复杂性，并且应尽量减少冗余。当您将应用程序迁移到 LSA++ 或从头重新设计时，应仔细评估在多大程度上需要保留持久层。例如，只有当需要实现下层无法实现的业务逻辑时，才应在架构化数据集市层中定义单独的 DataStore Object。如果附加逻辑并不复杂，也值得检查它是否可以在 BW 查询定义中或在下层中实现。

  • 新的 SAP HANA 优化的 InfoProvider 取代了过时的 InfoProvider。

  • 新增了一个区域：BW Workspace 层，为业务用户提供他们自己的本地数据建模空间。

  • 入站层，以前称为数据获取层，已重命名为 Open Operational Data Store 层，并且功能范围已扩展。例如，LSA Operational Data Store 的所有功能都由这个新的 LSA++ 层承接，这意味着现在虚拟数据集市层可以直接访问 EDW 的输入层。

  • 虚拟化层为报表工具提供数据，在 LSA++ 中它显著更广泛、更灵活，因为它可以从几乎每个其他层消费数据。这之所以可行，是因为 SAP BW/4HANA 查询也可以对 DataStore Object (advanced) 执行，而不会出现性能问题。例如，您可以在 EDW 传播层上构建报表，而无需设置业务转换和单独的数据集市。

以下部分描述所有 LSA++ 层，并在适用时也提及它们在 LSA 上下文中的先前含义。我们还列出了通常使用的 SAP BW/4HANA 对象：

  • Open Operational Data Store 层（DataStore Object (advanced)、SAP HANA Calculation View、DB 表或 DB 视图）：此层是 LSA++ 架构的中央输入层，将在本课下一节中更详细地讨论。

  • EDW 转换层：LSA 协调层的新名称；用途和对象类型不变。

  • EDW 传播层：基于 DataStore Object (advanced)，并增强了通过虚拟化层将此层的数据模型直接提供给 SAP BW 报表层的选项；除此之外不变。

  • 业务转换层：作用不变，但已成为可选。

  • 架构化数据集市层：此层的重要性已降低，因为在 LSA++ 中，不再需要设置数据集市来为报表映射完整的 EDW 架构。不过，省略此层的前提是业务转换层的逻辑可以集成到其他位置（BW 报表层或 EDW 转换层）。

  • 虚拟数据集市层：虚拟化层的新名称，通常基于 CompositeProvider。Open ODS View 和 BAdI-Provider 也可用于特定场景。

  • BW 报表层：BW 查询现在在 BW Modeling Tools 中维护，除此之外不变。

  • 企业内存（Corporate Memory）：现在由 DataStore Object (advanced) 创建；除此之外不变。

  • BW Workspace 层 这个新区域旨在支持临时（ad-hoc）需求，这些需求若在数据仓库的核心架构中实现则过于冗长且资源密集。其目标是使有经验的用户能够独立于中央 IT 部门对现有 SAP BW 模型进行增强。为此，他们获得相应的工具，即基于 Local Provider（本地数据集）以及本地 CompositeProvider 的 BW workspace。

LSA++ 的 Open Operational Data Store 层

LSA++ 将 Open Operational Data Store 层定义为数据以虚拟或物理方式获取到数据仓库中的第一层。这意味着获取的数据带有源系统的语义、语法和质量，它满足以下需求：

  1. 基于标准 BW 对象（如 DataSource、Transformation 或 DataStore Object (advanced)）以及用于例外情况的 BAdI-Provider，将数据初始暂存到 SAP BW/4HANA 一致的 EDW 核心中，数据在此可根据需要接受质量检查和协调流程。交付和数据管理完全由 SAP BW/4HANA 应用程序控制。也就是说，它由 SAP BW/4HANA 应用程序管理，数据存储在 SAP HANA 数据库所谓的 BW 管理架构（BW-managed schema）中，只有 SAP 应用程序具有读取权限。

  2. 数据的即时消费，无需进一步暂存和集成到 SAP BW/4HANA 的 EDW 核心中。这意味着数据绕过 SAP BW/4HANA 数据集成接口（源系统、DataSource）。在这种情况下，数据在客户定义的、不同于 SAP BW 管理架构的 SAP HANA 架构（又称外部管理架构，Externally managed schema）的 DB 表或 DB 视图中进行管理。这些数据可以基于 Open ODS View 或 SAP HANA Calculation View 以任何所需的程度建模并集成到 SAP BW/4HANA 中。数据可能在独立于 SAP BW/4HANA 的 SAP HANA 架构中进行管理，原因有很多：

  3. 直接预配： 数据基于 ETL 工具（SAP Data Services 或第三方工具）等预配方法以及复制技术（例如 SAP LT Replication）直接加载到 SAP HANA。

  4. 其他应用程序： 与 SAP BW/4HANA 不同的应用程序运行在同一个 SAP HANA 系统上，并将其数据写入自己的应用程序管理架构中。某些 SAP 应用程序可以与 SAP BW/4HANA 共存于同一 SAP HANA 平台，请参见 SAP 注释 1661202（支持多个应用程序共用一个 SAP HANA 数据库）。

  5. 数据联邦： 数据在外部源上管理，但基于所谓的远程连接（Remote Connections）利用 SAP HANA 标准集成功能（即 SAP HANA Smart Data Access (SDA) 或 SAP HANA Smart Data Integration (SDI)）虚拟集成到 SAP HANA 中。 这些数据不在 BW 应用程序的影响范围内。因此，它在 EDW 中最初是未知的，但可以通过专用建模对象（Open ODS View、SAP HANA Calculation View）集成到 SAP BW/4HANA 中。因此，Open Operational Data Store 层为整个 SAP HANA 平台上的数据以及通过标准 BW 源系统连接的源提供了标准化访问。 Open Operational Data Store 层的所有数据都可以通过虚拟化层直接消费。集成到其他 LSA++ 层是可能的，但不是强制性的。例如，实时运营报表就是一个典型的用例，其中省略了其他 LSA++ 层。另一方面，如果报表需求要求数据清理、协调或转换，那么在 LSA++ EDW 传播层中处理数据就是默认方法。

本课其余配图

LSA_LJ

LSApp2_LJ

OOV_external_Schema_LJ