★中国海洋石油集团有限公司 王小玲

摘要：本文通过对企业数据仓库体系架构的分析，开展了对模型设计和数据迁移路径的研究，发现可以通过系统架构的优化有效地支持企业数据仓库中数据模型和历史数据迁移的顺利完成。此架构优化的好处也体现在保证了数据分析服务的连续性，业务不会受到企业数据仓库升级期间模型传输和冻结期的影响。另一个关键点就是企业数据仓库底层的分布式大规模并行数据库所提供的多租户云架构。基于此共享架构所搭建的企业数据仓库可以灵活部署数据应用项目，在升级和迁移过程中，利用合理资源部署所需要的开发和测试环境，不仅满足了独立性的要求，也能减轻数据冗余。多租户的系统架构除了满足迁移和升级外，也可以在资源发生瓶颈时进行横向扩展。不仅在系统架构和部署方面应用多租户，通过探索简化数据冗余，更好地履行数据的单一来源的原则方面也可以探索和应用这种系统架构。从而提供用户更好的应用效果、更低的运营成本和最大化的资源投入。

十八大以来，党和国家高度重视数字化发展，企业中的第一把手也要求坚持以科技创新为驱动，积极推动数字化转型。做好数字化转型工作，其中之一就是要求加强数据集成共享，构建一体化经营管理平台。ERP时期形成的统一数据仓库系统经过15年的应用，全面覆盖了主要二级单位及核心业务领域，成为集成、统一、共享的经营管理核心系统。随着大数据、人工智能等信息技术的发展，业务的精细化管理要求也不断提升。ERP系统近11年来没有进行过升级，系统功能欠缺、运行效率低下、扩展能力不足、用户体验不佳，越来越难以支撑数字化转型智能化发展需要。所以，进行ERP系统技术更新换代工作势在必行。ERP系统已经融入企业经营管理日常运营流程中，企业数据仓库通过数据建模和处理，也支撑着经营管理的数据分析及报告出具。在ERP系统的升级改造过程中，要保证经营管理的流程不中断，其关联的企业数据仓库中的历史数据也要完成平稳迁移，这都是面临着必须解决的关键问题。通过系统架构的优化能有效地支持此项工作的顺利完成。

1 企业数据仓库的体系架构概述

企业数据仓库（Enterprise Data Warehouse，EDW）的体系架构包含了从数据源系统到最终前端的多层组件，其中技术底座决定了数据仓库运行的稳定性、高性能、可扩展性和易用性。随着大数据技术的发展，作为支撑企业经营管理的商务智能（BI）应用和报表的数据仓库如何通过底层技术架构的优化和完善来适应企业大数据的应用仍然是一个值得研究和探讨的话题。EDW不仅与企业业务架构、数据架构、应用架构联系紧密，更是与技术架构密不可分，它决定了其他领域功能的可行性。

数据仓库系统架构包括了技术架构和数据架构，除了强调其中包括的组件及组件之间的关系外，它应该还强调反映和调整其自身系统内各个功能组件元素及其演化状态的能力，以及这些能力的获得是否容易，也就是架构的扩展性和兼容性。如果将EDW看做一个有机体的话，架构就是在整体系统设计视角下，其内部各个细胞体的新陈代谢的过程。

数据仓库中的经典数据模型有：

关系建模（也叫范式建模），侧重效率的数据仓库用第一范式建模，侧重规范的数据仓库用第三范式建模，关系模型设计的主要目的是可以准确表达业务数据，且存储一个消除冗余的事实。这种建模方式中常见的就是事实表通过两个或两个以上的外键链接多个维度或属性表，强调通过ERD实体—关系设计和建模。此类型的建模方式主要来自于Inmon在上世纪80年代提出的企业信息工厂理论，早期的基于关系型数据库的数据仓库大多基于此种方式建模。强调面向主题的、集成的、与时间相关的、不可修改的数据集合。此建模理论与其他数据库应用不同的是，数据仓库更像一种过程，对分布在企业内部各处的业务数据的整合、加工和分析的过程。而不是一种可以购买的产品。

维度建模，数据被重构优化，用于满足数据的查询和分析的需要。维度建模侧重大量数据分析。构建指标数据分析的系统一般标准用的是维度建模。“尽管维度模型通常应用在关系数据库管理系统之上，但并不要求维度模型必须满足第三范式”^[1]。此种类型的建模是由数据仓库领域的Kimball倡导的，维度建模的兴起解决了数据模型过于复杂的问题，通过多维所产生的点和度量相结合，可以实现业务上的指标分析。适用于对不太成熟、快速变化的业务进行建模。

数据拱顶（Data Vault）建模。随着大数据技术的发展，Inmon和Daniel提出了此种建模方式。Data Vault 2.0（DV2）是一个商业智能系统，包括模型、架构、方法论和实施这四个方面的最佳实践^[2]。如图1所示。

图1 商业智能Data Vault系统

DV2建模主要引入了散列键和链接表的概念，实现跨业务主题的数据集的融合，它们通过业务流程中的键值结合数据集与业务过程，采用第三范式和维度建模方法混合而成，同时满足NoSQL和RDBMS，往往也称为混合建模。

DV2建模理论的价值就在于提出了跨业务主题域的键值的概念，提供了跟踪和追寻多个业务范围的数据的能力，是将数据作为可溯源的资产的一个重要组成部分，体现数据价值。其它的建模方法还包括锚建模，面向对象建模，基于事实建模，基于时间建模，完全通信建模，NOSQL建模等方法，在此不再赘述。

大数据系统可以基于企业数据仓库进行扩展建设。通过扩展主数据系统、元数据管理系统，并建成全域数据资产，为企业的数据流入提供了一条新的途径^[3]。

从以上数据仓库建模的几种经典方法可以看出，每一种理论的提出和广泛使用都与当时的数据库与大数据技术密不可分。技术的进步所支持的业务需求的快速迭代和实施对数据仓库的系统架构提出相应的要求，这便有了从关系建模到维度建模再到Data Vault建模的整个理论体系的发展。

那么，如何利用已经建成的EDW的系统架构来完成历史数据迁移和改造升级呢？本文主要以SAP EDW为例进行论述。

2 SAP EDW的数据建模架构的演进和优化

基于SAP数据仓库建模先期主要通过关系建模的方式进行建设，采用Oracle的结构化数据库搭建逻辑上的维度、属性和星型模型。这种建模方式与所匹配的ERP流程系统契合度较好，所以能支持前端用户的商务智能和报表需求。随着SAP自有的高性能内存数据库HANA的问世，以及大数据技术的发展，原有严谨的外键对事实表和维表进行关联的界限变得模糊，在内存数据库中也可以实现维度的建模。如图2所示。

图2 SAP EDW建模

利用SAP HANA数据库可以实现三种方式的建模。

第一种，基于SQL的建模，客户的数据源大多是非SAP的系统，可以通过基于SQL的数据仓库工具，在HANA数据之上进行模型搭建。这种情况下可以利用HANA里面的计算视图进行实施，大部分第三方数据仓库产品可以提取HANA的计算视图数据。第二种，混合模式，如果客户本身已经具有了SAP BW和其他品牌的数据仓库，可以同时利用这两种系统环境进行模型搭建。BW数据模型中的大部分对象也可以映射成对应的视图与外部SQL数据仓库进行融合。第三种，SAP EDW建模方式。这种方式的体系架构比较清晰，中央元数据存储库能有效支持端到端的基于架构的数据仓库中的数据管理。

参考以上模式的数据仓库实施方法，传统的BW建模变成轻量级，复杂的层层加载的数据链除了处理复杂逻辑打包的SAP事务端标准数据源的抽取、传输和上载外，大部分的数据处理任务通过底层的HANA数据库建模，通过虚拟化封装，以数据服务的形式提供最终商务智能消费端，包括报表出具与移动应用。

当EDW已经逐渐向混合式转变时，如何有效利用数据仓库的已有优势和未来数据仓库的灵活架构来实现平稳迁移呢？

3 基于企业数据仓库的优化实现平稳迁移的关键点

（1）应用系统架构的优化实现EDW平稳迁移的关键点之一：通过读取优化的操作型数据存储模型（ADSO）实现平稳的数据模型的迁移。

（2）EDW中的数据是分层汇聚并处理的。这种分层和汇聚按照分层可伸缩架构（Layered Scalable Architecture，LSA）来实现。LSA代表了可靠的管理数据和元数据生命周期的数据仓库框架体系。随着HANA的不断应用，LSA框架扩展到LSA++整体框架，以满足高效运营和敏捷BI的需求。如图3所示。

图3 LSA++分层模型

LSA++的重要部分包括EDW部分，其中缓冲/企业内存部分包括了源模型与EDW模型之间的链接，企业内存持久层。开放的操作数据层（ODSO）加快了模型中数据的激活时间，一个模型至少加速10%。在进行对SAP BW 7.30 SP 10迁移到BW/4过程中，所有标准数据存储对象执行SAP HANA优化激活，而无需进行任何设置，也无需进行任何手动转换或迁移活动，节省了迁移过程中的工作量消耗。除了激活，SID（主数据ID）生成也经过HANA优化。因此，如果在数据激活期间设置SID生成，则几乎不会对正在进行生产系统运行的数据仓库性能产生任何影响。

除此之外，如图3中的箭头所示，查询不仅可以在虚拟的体系结构数据集市之上运行，也可以跨层直接从开放的操作数据层（ODS）以及传播层DSO上运行查询，其性能与EDW之上的信息立方体多维模型（Info Cube）上运行类似。

EDW升级和迁移过程中，并行实施项目及已上线的应用往往是受影响最大的，特别是在并行实施过程中用到EDW中企业内存持久层的内容或者标准数据源时。现实中往往发生这样的情况，如果EDW升级和迁移的A项目的冻结期安排在3月初至6月底，而业务单位将EDW的标准数据源作为贴源层，实施6月底上线的B项目，如何实现两个项目的并行运行并保证相互不受影响？基于以上的系统架构能保证A、B项目同时进行，相互不会产生影响。如图4所示。所以，关键点就在实施B项目时，将贴源层的数据模型搭建在DSO之上，通过BW/4的升级转换，这些DSO自动转换为ADSO，成为HANA工作区可以识别的视图（通过路径③），不需要再到BW/4工作区进行模型调整，也不必等待BW/4应用工作区迁移完成才开始工作。而其他的BW模型及与BW Infocube等相关的HANA View同样需要通过路径①、②和④进行转换和迁移，受到冻结期和BW/4模型调整的影响。

图4 BW/4数据迁移

综上所述，基于LSA++的端对端框架，原有的数据仓库通过远程迁移的方式，分步骤地传输到目标系统时，可以花费较小代价和资源，完成数据模型和历史数据迁移和升级任务。

（2）应用系统架构的优化实现EDW平稳迁移的关键点之二：多租户的使用。

由于SAP HANA是一种分布式大规模并行分析数据库（Analytical Massively Parallel Processing（MPP）Databases），不仅能通过列式存储方式对数据进行压缩，同时能平衡和配置大数据分析工作的负载，这种体系结构使复杂的分析查询可以更快、更有效地处理。

SAP HANA租户数据库是SAP HANA中多租户的基础。能够在一个SAP HANA系统中运行和管理多租户数据库，有助于降低资本支出、简化数据库管理并构建多租户云应用程序。从HANA2.0以后自动转换成多租户（Multi-tenant Database Container，MDC）模式。如图5所示。

图5 多租户数据库

一个系统始终只有一个用于中央系统管理的系统数据库，以及任意数量的租户数据库（包括零个），多个应用程序在不同的租户数据库中运行。SAP HANA系统有单个系统ID（SID，请区分此SID与前面所述的主数据SID的不同）标识。数据库由SID和数据库名称标识。

从管理的角度来看，在系统级执行的任务和在数据库级执行的任务之间存在区别。在多租户的情况下，可以共享相同的数据库系统、软件安装、相同的计算资源和相同的系统管理。但是，每个DB Schema都是独立的。这种多租户的MPP架构使得其上的数据应用项目部署更加灵活。在进行EDW迁移和升级过程中，就利用了多租户系统架构，从而节省了迁移和升级过程中所需要耗费的数据库和硬件资源。系统架构如图6所示。

图6 迁移和升级场景下的多租户

在节点3上，有3套系统，系统DB、开发环境和测试环境。System DB安装时默认SID为D12，建立开发环境租户时，这个环境的SID为D12@D12，后期又根据需求增加了测试环境的租户，SID为Q12@D12。这种方式，保证了同一节点下继续增加租户时每个租户系统的独立性。

除此之外，其他基于多租户数据仓库系统架构还可以适用横向扩展（Scale Out）场景，应用于集团公司及下属需要独立性的上市公司的系统架构。

一般来说，企业集团统建系统会先实施SAP HANA系统，如下示例，统建系统形成了6个节点，每个节点容量为2TB的EDW系统。除Standby节点的2TB外，其他5个节点中的4个节点有8TB内存容量可用。所以Tenant DB1.1~1.4可以分布在集团公司的4个主要节点上，减轻主节点上的数据压力。下属公司可以在Host5（节点5）下面建立自己独立的数据应用环境，保证了2TB的内存容量。由主节点共同管理底层系统资源，实现成本效益最大化。如图7所示。

图7 横向扩展场景下的多租户

以上模式的优势：使用HANA多租户MDC特性，可以实现跨租户的数据查询访问。一台Standby节点可待命两套系统。租户的拓展缩减方便，比如可以再增加或者删除租户3而不影响其他租户的使用。劣势：如果租户1和租户2同时出现故障时，Standby节点无法同时兼顾。另外，停机维护时，租户1和租户2的应用同时受影响。

以上两种都是常用的多租户数据仓库的应用场景。目前我们也在继续探索其他应用场景，比如用于业务上关联紧密，贴源层共享的两个独立DB Schema系统。这种类型的场景往往发生在不同的两个应用系统需要向同一个数据仓库系统提取数据，并且这些数据具有高度的一致性。如果单独建立两个数据库系统，分别存放一份数据，必然引起数据冗余，而且这些冗余数据极易导致数据的不一致。另外，考虑到多一份数据库系统将耗费更多的运维资源，所以采用多租户是一种各方面评估后均合适的方案。

4 结语

综上论述，EDW系统作为是集团数据平台的一部分，发挥着支撑企业数据分析和辅助决策的作用。特别是底层的体系架构的能力以及其变化发展对EDW所构建及支撑的数据平台满足最终用户需求的能力起着决定性的作用。利用虚拟化的高级操作型数据模型对象ADSO可以尽可能减少EDW迁移和升级对并行数据平台实施项目的影响；利用多租户的MPP架构可以扩展数据仓库的能力，使得更多的系统环境经济高效实现。

作者简介：

王小玲 （1972-），女，四川宜宾人，高级工程师，硕士，现就职于中国海洋石油集团有限公司信息技术中心，研究方向为大数据及商务智能应用。

参考文献：

[1]RalphKimball.数据仓库工具箱:维度建模权威指南[M].王念滨,周连科,韦正现,译.北京:清华大学出版社,2015.38.

[2]W.H.InmonDanielLinstedt.数据架构[M].唐富年,译.北京:人民邮电出版社,2016.106.

[3]DAMA国际:DAMA数据管理知识体系指南[M].DAMA中国分会翻译组,译.北京:机械工业出版社,2020.297.

摘自《自动化博览》2022年9月刊