Embed Size (px)
Citation preview
通过实用数据仓库参考架构
实现普及化 BI
Oracle 白皮书 2010 年 2 月
注意：
以下内容旨在概述产品的总体发展方向。该内容仅供参考，不可纳入任何合
同。该内容不构成提供任何材料、代码或功能的承诺，并且不应该作为制定购
买决策的依据。所描述的有关 Oracle 产品的任何特性或功能的开发、发布和时
间安排均由 Oracle 自行决定。
通过实用数据仓库参考架构
实现普及化 BI
引言 ..............................................................................................................................4
背景 ..............................................................................................................................5
建模方法 ..............................................................................................................5
变化如何影响需求 ..............................................................................................6
参考架构的要求 ..................................................................................................8
打包应用程序和参考架构 ..................................................................................9
ORACLE 数据仓库参考架构..................................................................................10
数据源 ................................................................................................................ 11
核心数据仓库 ....................................................................................................12
临时数据层 ................................................................................................12
基础数据层 ................................................................................................12
访问和性能层 ............................................................................................13
业务智能和性能管理工具 ................................................................................14
BI 抽象和查询生成 ...................................................................................14
通过 SOA 将洞察和操作联系起来 ..........................................................15
ETL、消息传递和元数据 ................................................................................16
安全性................................................................................................................16
数据加载过程 ....................................................................................................17
信息供应过程 ....................................................................................................18
总结 ............................................................................................................................20
通过实用数据仓库参考架构实现普及化 BI 第 4 页
通过实用数据仓库参考架构实现普及化 BI
引言
毋庸置疑，“信息”是当今全球每个成功、赢利和透明企业的核心。企业领导
者、行业权威人士和学术界都认同信息是通过信息技术实现竞争优势和利益相关
方价值的关键所在。但是，为了实现这一目标，必须在企业内部普遍提供信息，
并且为更广泛的贸易团体和客户群提供信息，还要具有所需级别的卓越管理来完
成转换。
自数据仓库开始普及以来，业务和 IT 领域发生了翻天覆地的变化。许多研究
表明，到目前为止，大部分 IT 预算仅用于运行业务而不是改变业务：只是保持
正常运行而不是打造竞争优势。在业务智能和数据仓储方面，这通常体现在 IT
团队花费太多时间进行临时的集成和数据重新设计，业务分析人员花费时间
收集和准备数据而不是分析数据并根据分析结果采取措施。为了真正改变业
务，数据仓库必须通过 Web 服务“洞察”业务流程的要害之处，通过业务智能
工具提供分析流程。
如果我们要真正在企业内外普遍提供业务智能，则构建业务智能所基于的架构必
须能够以近实时的方式加载和查询数据，并且其准确性和高可用性与对其他每个
运营系统的期望一样。随着数据量的日益增加和所需分析的更加深入，架构还必
须能够扩展以满足未来需求，并且能够管理信息生命周期从而降低实际安全平台
中的成本。
本白皮书将讨论数据仓储的背景，探讨推动对“下一代”数据仓储和业务智能平
台的需求的一些动态和业务趋势。本白皮书将以企业参考架构的形式提供这样一
种架构：该架构可以用于指导新的实施，也可以用于制定现有数据仓库的发展规
划以引入本白皮书中所述的部分或全部设计理念。
通过实用数据仓库参考架构实现普及化 BI 第 5 页
背景
在本节中，我们将探讨一些数据仓储背景，了解全球各行各业的业务对数据仓库和
业务智能解决方案不断提出的新的要求。
建模方法
数据仓库由来已久，它们在 20 世纪 80 年代后期首先作为解决方案出现，理所当
然地在同时代的 IT 架构中赢得一席之地。就其本质而言，数据仓库具有高度战略
性，一方面是因为它们承载了业务群体的诸多需要和要求，另一方面是因为它们
花费的资本/运营支出和解决方案的复杂性。
过去，成功的数据仓库必须做以下三件事情。它们必须加载数据，长期管理数
据，提供对数据的访问（通常是为有限数量的分析人员和高级业务用户提供对数
据的访问）。
当时，对于用于仓库的底层数据模型的最佳方法，流行两种观点。Ralph Kimball 推广的一种观点是维度方法，此方法可简化数据模型以便于访问数据，从而最终用
户可使用星型或雪花型模式查询数据。这是一种非常物理化的模型，下钻路径、层
次结构和查询配置文件嵌入数据模型本身而不是数据中，这至少是最终用户可如此
直接地导航模型的部分原因。
维度模型侧重于数据仓储的信息访问而不是数据管理部分。它们简化了用户沿熟
知路径进行的访问，但也存在此方法中包含的技术不能很好解决的一些问题，从
而需要引入查找、辅助表、“非事实型”事实表等。此方法简化了访问，但是可
限制可能的分析深度。当然，这对于某些业务而言可能不是问题，但对于其他业
务而言将是问题。
由于需要长期管理信息资产，为了实现我们可能希望进行的更改（例如组织和报
表层次结构更改）常常需要花费大量的时间，进行繁琐的工作，导致大量的数据
操作。对于那些具有数百万个产品和数千个产品属性（不一定重叠）的企业而
言，更加深入的分析需要（从而需要丰富的产品属性）也是一项挑战。对于维度
方法而言，真正的挑战之一是对整个业务进行一致的不会限制分析的维度开发。
如果使用迭代开发方法，其实现并非易事，但如果没有此开发，数据仓库差不多只
是一些数据集市孤岛。
第二种观点更为传统。Barry Devlin 和 Bill Inmon 等作者认为数据的详细信息
十分重要，因此必须保留详细信息！第三范式数据结构 (3NF) 侧重于数据仓
库的数据管理部分，并在此部分与信息访问部分之间做出权衡取舍。它们
保留每个事务的详细记录而没有任何数据冗余，并允许对属性以及数据元素之间
通过实用数据仓库参考架构实现普及化 BI 第 6 页
的所有关系进行丰富的编码，但用户通常需要充分了解数据才能可靠地导航更为详
细的结构。
当然，采用 3NF 构建模型并不确保模型不受业务更改的影响。例如，层次结
构可能仅通过仓库中的一个表来表示每个层次结构级别，但如果企业决定更改层
次结构中的级别数量或者针对某一部门或产品要跳过某些级别，将出现什么情
况？ 这两种更改都需要对物理数据模型进行更改，这样也会不可避免地使得保
留“是什么”报表的观点存在问题。在这种情况下，如包含级别表的“物料清单”结构这样的简单方法可避免这些结构更改。
无论您的观点如何，这两种模型模式显然都有各自的优缺点。事实上，从纯数据
库的角度来看，Oracle 始终对使用的设计一无所知，因为不同于其他供应
商，Oracle 数据库表现十分出色，它通过专门优化的功能支持 3NF 设计和维
度设计两者。但是，下一代数据仓库必须能够完成更多的工作，而不仅仅单独遵
循 3NF 或维度方法加载、管理数据，然后将数据提供给几个临时用户。为了
更具成效，您需要利用两种模型形式（而不仅仅是其中一种）的优势。而任何其
他方法都是一种妥协让步！ 变化如何影响需求
目前的 DW 平台 自数据仓储流行以来，业务需求以及数据库技术和工具有了长足的发展。数据仓库
不再孤立，逐渐成为每个业务流程的基本元素，成为通过洞察运营系统来支持业务
执行的平台的一部分。虽然高效的业务流程必须自动执行并且以流程为中心，但有
效的业务流程还必须由信息驱动！
通过数据实现更多业务价值的迫切需要促使组织在寻求为 BI 和数据仓储建立新的
基础时考虑许多其他设计因素。这些考虑因素包括：
• 实时 (R/T) 和混合负载。当然，夜间一次性批量加载数据的旧概念早已不复
存在，但是凸显的运营要求已经迫切需要能够加载和查询数据，而同时不产
生锁升级的复杂性，也不读取可影响业务可信度和可用性的脏数据。
• 普及化。业务智能日益普及，在企业内部已扩展到利益相关方，在外部已扩
展到贸易伙伴、监管者和客户。此外，流程通过 Web 服务使用它，使用更
传统的工具的人们也使用它。重要的是，一旦考虑将业务智能作为服务来
提供，您还必须了解这对用于提供业务智能的平台的影响。业务智能必须
满足运营应用程序必须满足的同样严格的性能和高可用性要求；数据仓储
系统日益成为任务关键的系统。
• 加载数据
• 长期管理
• 方便访问
下一代 DW 平台
• • 丰富数据资产
• 长期管理
• • • •
近实时加载数据
方便访问
加载和管理非结构化数据
将洞察与操作相关联
在实际安全平台上
通过实用数据仓库参考架构实现普及化 BI 第 7 页
• 工具更改。工具随时间而更改并可能继续更改，尽管由于工具整合的趋势所
致，更改速度减慢。任何新的数据仓库架构都必须允许此类工具更改，为
此，需要将数据存储方法与对数据提供给工具本身所用的方法提出的任何要
求相分离。
• 分析要求。与过去相比，业务更加以分析为中心，并且在许多公司中，执行
此分析通常涉及使用电子表格和其他专用工具。这会再次增加额外的平台成
本和安全性风险（隔离用户而不是允许共享洞察）并产生延迟。对于数据仓
库而言，需要的是实现真正的分析深度，而不仅是提供简单的信息板和
报告。
• 实际平台。数据量和分析需要随业务周期而变化，随时间而快速增长。为了
应对这些需求变化，需要实际可行的平台 — 此平台可以扩展容量以满足这
些需求，其成本是企业可负担得起的，并且可以通过市场上提供的技能进行
管理。
• 数据质量。根据错误数据制定的决策必然是错误的决策！如果企业数据仓库
的目标是通过使用正确工具在正确时间提供对正确信息的访问来支持战略
性、战术性的运营决策，则数据质量和可用性将成为关键考虑事项。即使数
据不完美（很少完美），也必须尽力分析和改善数据质量，还要公布质量标
准和问题，以便在全面了解所有限制的情况下制定决策。
• 法规要求。不断发展的法规要求迫使公司关注其全面的公司治理、风险以及
合规性战略。这促使保留更多数据（包括非结构化数据），并且为此保留更
长时间。
• 规划和管理更改。一方面是要了解更改架构的一部分或工具的需求，另一方
面是在如今的服务级别协议基础上提供更改！ 任何新的架构都必须通过支
持现代迭代设计技术以及隔离更改以防止它们波及架构，来促进更改。
• 非结构化数据。总体上，企业内保存的大部分数据都是非结构化数据。公司
可以通过对此信息进行合理化和整合来降低成本，通过提取数据含义制定更
好的决策，并使用结果值进一步丰富现有数据。
另一个发生变化的重要方面是，业务本身的变化速度。过去，仅根据运行单个供
应商提供的 ERP 制定 IT 战略可能是合理的。在许多行业中，如果考虑到所发
生的整合的速度，这可能不再是要采用的可行定位。数据仓库不仅必须为更改做
好准备，还必须在发生更改时将其作为可靠信息包含进来，从而使其成为真正的
优势。
通过实用数据仓库参考架构实现普及化 BI 第 8 页
一种方法是将数据向下游推向专门的数据集市，此方法由于业务挫败而产生或者
作为专用数据仓库硬件平台限制的直接结果而产生。虽然从业务的角度来看可提
供对数据的更好访问，但这种信息资产破碎会降低整体业务价值，增加数据延
迟，增加长期业务成本，并带来与安全性及合规性有关的额外风险。它还会进一
步限制需要数据集成的分析，导致数据集市之间通用测量的定义差异。应该避免
数据仓库环境分裂，因为它会影响决策准确性，并使到以决策为中心的业务的集
成更容易出现问题。
参考架构的要求
如果我们要以实用、经济高效的方式在整个企业内普遍提供 BI，任何现代数据
仓库设计都应该满足以下条件：
• 在一个设计概念中平衡对信息管理和信息访问的要求。
• 允许信息资产长期保留和丰富而不必随业务更改（包括对层次结构和产品属
性或用于分析的样式、深度及工具进行的更改）重构数据。
• 提供抽象层，以便工具的变化和采用的分析类型以及通过企业收购实现的新
数据源的纳入不会对架构的其余部分产生连锁更改反应。
• 确保信息资产的安全性，并能够证明数据的起源以及何人查询数据以满足
法规要求。即使对于特权数据库用户以及数据库由于硬件和其他故障而丢
失的情况，也必须如此。
• 便于对未来硬件技术的使用，这些技术可能进一步降低管理大量数据的成
本和复杂性。
通过实用数据仓库参考架构实现普及化 BI 第 9 页
图 1 核心业务流程和上下文业
务流程的分析深度
打包应用程序和参考架构
从头开始开发完整的企业数据仓库可确保完全符合您的要求，但总是需要在成
本、人力、时间和组织投入这些方面付出代价。构建企业数据仓库是一项非常艰
巨的任务，尤其对于小型组织或使用更动态的方法的组织（可能没有耐心或行政
支持来完成此项工作）而言更是如此。
虽然对于任何业务的核心方面，这可使业务在市场竞争中脱颖而出，因而此类定
制解决方案确实是有益的，但是与业务运营方式更为上下文相关的其他方面可能
不需要如此的分析深度或灵活性。
图 1 通过所需的分析深度和业务流程的涵盖范围，显示了核心业务流程和上下
文业务流程之间的区别。该图显示出，对于上下文流程，可能只需提供相当标
准的报告和信息板，但核心流程将需要更全面的分析功能和工具，例如例外管
理、统计分析、预测、OLAP、文本挖掘、数据挖掘、空间分析等。
对于那些基于上下文的业务流程，例如那些通常通过商用现成的程序包 (COTS)（包括 HR、财务、CRM、销售和服务）提供的业务流程，最佳策略可能是
购买现成的分析程序包并修改 /扩展它们以便更好地满足需求。Oracle 将这
些程序包称为 BI 应用程序，它们包括 ETL、数据集市、元数据以及最佳实践
报告和信息板。
在许多方面，这是有关构建还是购买的争论，曾经在一段时间内围绕 ERP 和 CRM 应用程序进行了这样的激烈争论。根据过去的证据，我们有理由得出这样的
结论：BI 应用程序将继续使用，而任何现代数据仓库架构需要将这些应用程
序集成到设计中。
为了保持 BI 应用程序的高增值和快速价值实现，应该尽可能以最少的更改实施
它们。另外，将需要底层数据源中的一些数据以便为更广泛的查询提供上下
文。这些被视为不同的流，而单一数据源可以通过 BI Server 组件（将在后面详
细讨论）保留。
可以通过组合来自 COTS 的多个 BI 应用程序和来自事务系统的核心数据内容，
构建企业数据仓库以及满足我们的“T”形分析需要。
对于规划目的，可以通过 BI 应用程序的零散？分片传送为业务提供常值，从而有
足够时间完成对要执行的业务核心部分进行建模这一更复杂的任务。另外一个优
点是当通过预构建的 ETL 和报表基础架构完成 BI 应用程序时，这些有助于开始
了解 ETL 映射和建立报表层。
通过实用数据仓库参考架构实现普及化 BI 第 10 页
1994 年，英国一家领先品牌零售商
在实施数据仓库时使用了该参考架构。从
那时起，由于引入了会员卡系统，他们看
到业务和分析需要发生了巨大变化。
即使经历了这些变化，他们也从来不用
返回并重构数据。他们可以只添加新的
数据和工具。
ORACLE 数据仓库参考架构
Oracle 数据仓库参考架构的目标是长期以极低的成本提供高质量的集成系统和信
息。这一目标的实现是由于，我们认识到数据仓库必须同时满足数据管理和信息
访问的不同需求，以一种分层、抽象的方法对数据管理和信息访问应用不同类型
的数据建模。
该参考架构旨在作为指南而不是说明手册。架构中的每个层都在提供支持下一
代业务执行所需的分析平台中担当一个角色。该参考架构提供了一些进行回测
的方法，因此我们可以通过进行特定的架构、技术和工具选择来了解所做出的折
衷。该参考架构既适用于制定规划以迁移所有的现有部署，也同样适用于新的数
据仓库部署。
本白皮书的以下各节简要介绍了架构的每个主要组件（如下面的图 2 所示）以及
加载过程和数据供应过程。
虽然本白皮书是全新的，但提供的参考架构却不是。该架构的开发和完善已历时
多年。实际上，一些客户大约在 14 年以前就使用在此所述的方法率先开发了基于
Oracle 的数据仓库。只是底层数据库技术和工具的功能有所更改。
在每个新版本中，都添加了数据仓储特定的特性或安全性和可用性特性，从而使架
构的实施和部署更加快速和轻松。
图 2 参考架构的主要组件
通过实用数据仓库参考架构实现普及化 BI 第 11 页
如图 2所示，参考架构具有三个主要部分。它包括信息源、数据仓库本身以及业
务智能和性能管理工具（在图中显示为 BI/PM 工具），还包括 ETL、消息传
递、元数据和安全性，包括所有这些部分。将在以下各节分别介绍这些不同的部
分。
数据源
数据源表示数据仓库的原始数据的所有可能来源，业务需要数据源来满足其信
息要求（参见图 3）。
源包括内部和外部系统，其数据可通过各种机制提供，这些机制包括通过消息传递
系统进行实时供应、通过日志挖掘进行更改跟踪、数据库复制、简单文件传输。所
采用的方法各不相同，具体取决于源的功能、容量、合规性和访问要求。
图 3 Oracle 数据仓库参考架构
虽然数据仓库的大部分数据源本质上是高度结构化的，但还是日益需要以非结构
化数据进行补充。此数据通常用于简单引用（例如，市场营销分析人员可能需要
查看用于反应迅速的客户群的市场营销宣传资料），或者用于通过文本挖掘或
分类、集群或特性提取技术进一步处理来丰富结构化数据。
可以考虑使用主数据管理 (MDM) 解决方案来保存任何给定业务实体的“主数
据”。就 MDM 而言，数据仓库的任务是跨越时间保留更改记录，以便能够对这
些更改进行分析以及将数据作为上下文提供给其他分析。而且，可能在数据仓库中
进行数据质量相关检查（作为单独过程，而不是 ETL 的一部分），这有可能导致
主数据更改。通过标准流，将这些更改返回到 MDM 解决方案并将新的更新重
新接收到数据仓库。
通过实用数据仓库参考架构实现普及化 BI 第 12 页
核心数据仓库
主数据仓库可以进一步细分为 3 个概念（而不是物理）层：临时数据层、基础
数据层、访问和性能层。在图 3 中显示了这些层，下面几节进一步介绍它们。
临时数据层
从源中提取的数据的第一个目的地是临时层。此层在数据进入数据仓库之前作为
数据处理的临时存储区域，旨在区分数据仓库接收数据的速度与数据刷新并可供
最终用户使用的频率。例如，在移动电话中，UMS 设备通常每 100,000 个记录
或 10 分钟间隔（取其中较快者）创建包含呼叫详细信息的文件。收到这
些文件之后，将它们加载到临时数据层，但只能因业务需求的要求才可用于查
询。也就是说，这由业务需求驱动，而不是发话端交换机一时兴起所致！
现在，虽然与数据仓库静态质量有关的许多旧规则已不复存在，但数据仓库必须
包含干净、一致、完整以及尽可能实际的数据，这仍是事实。临时数据层是应用
业务规则以实现这些目标的地方。被拒绝的数据保留在此层中以便手动或自动修
正。与设计中的所有其他层一样，临时数据层对 BI 工具层公开，以便在适当情
况下为最终用户提供加载性能（包括数据质量信息）。
基础数据层
基础数据层有时称为原子数据层。顾名思义，此层以尽可能低级别的粒度记录数
据。它表示数据仓库的核心，并且是负责长期管理数据的层。
基础数据层以接近于第三范式 (3NF) 的规范化方式建模，以提高存储效率。由
于业务领域变化如此迅速，因此数据也以业务中立方式重新编码。这可消除业务变
化的影响，并可避免任何不必要的数据重构。例如，逻辑模型可以在自己的表（例
如 Sub-Dept、Dept、Division、Group）中表示层次结构中的每个级别，并且每个
级别之间具有固定的一对多关系。如果级别数量改变，将会怎样？ 如果组织转变为网络管理结构或者针对某些部门跳过一些级别，将会怎样？ 可以使用一些简单的设计模式，围绕这些问题进行设计。
逻辑模型设计的起点可以是一张白纸和现有源系统图。更典型的设计是利用来自一
个行业机构的企业信息模型或者来自数据库供应商（如 Oracle）或专业模型供应
商的企业数据仓储模型。
通过实用数据仓库参考架构实现普及化 BI 第 13 页
通常需要改变逻辑模型的一些元素来满足本地需求，并且模型中包括的所有面向
流程的表示都必须在模型转换为最终物理模型之前删除。由于关键关系和实体全
部在一个企业模型中标识，因此可以安全地使用定制开发和商业化的现成程序包 (COTS)/BI 应用程序实施的任意组合进行增量实施。
访问和性能层
如上所述，就提供用户对数据的访问而论，用于实现基础数据层的数据管理目标的 3NF 模型方法并不是很有用，因为更难以导航。访问和性能层为我们的架构添
加了信息访问组件。但是，最重要的是要意识到我们用于访问数据仓库的工具将
随时间而改变。我们可能很难控制特定业务部门所采用的工具，我们可能都不希
望如此！由于新工具可能对数据结构化方法提出不同的要求，因此我们必须能够
从底层数据池中创建这些数据（或重新创建它们），这一点极其重要。将数据重
构为不同表示（逻辑或物理）的能力是访问和性能层的全部“存在理由”。
从概念上讲，这是数据子集的面向主题的表示，可在保持通用维度的同时简化业务
分析 — 仅此而已。视图或第二层聚合结构中的物理实现通常是实现细节。它们根据
需要创建，以便于特定模块或工具集进行访问。Oracle 提供的所有聚合结构均可通
过标准 SQL 访问，并且可以根据需要添加，从而针对最终用户和应用程序实现明显
的性能改进。
访问数据层结构的填充和更新可以通过以下方式高度自动化进行：使用可跟踪源
中数据更改的物化视图，或者将 ETL 的范围扩展到 ETL 内部流程。
此层中面向主题的表示称为“嵌入式”相关数据集市。嵌入这些结构而不是将数
据推出到不同的下游数据集市具有多个优势。这些优势包括：
• 降低平台成本。 不需要购买完全独立的硬件平台来运行数据集市。还减少了额外的网络带宽、
电力和制冷需求。
• 减少数据和分析延迟。 不需要在第二个平台上卸载、传输、重新加载和聚合数据。这减少了延迟，并
且可以改善准确性和结果，因为数据较新。
• 减少开发延迟。 开发通常非常迅速。使用 Oracle 的 ETL 工具，可以通过对元数据进行少量
更改来创建逻辑数据集市设计，然后决定是以关系方式还是多维度方式实
现此设计。
通过实用数据仓库参考架构实现普及化 BI 第 14 页
• 改善安全性和管理。
嵌入数据集市之后，不再需要管理第二个平台。此外，Oracle 数据库非常
强健、安全和易于管理，而其他平台通常并不如此。
专业化分析领域（例如数据挖掘和预测）通常需要以非常具体的方式提供数据，
并且还可能涉及修改数据和写回新数据。设计中还包括“分析沙坑”的概念。可
以根据项目、用户或组创建沙坑。提供数据，执行分析（仅在项目区域读取和写
入）。一旦完成，所有结果与平常一样通过临时层（正确地）返回到目标平台或
仓库。例如，可以从访问和性能层的其他结构中进行数据采样，并将数据重构到
项目模式中。然后，使用数据挖掘工具创建一系列新客户细分。通过分析选择最佳
细分模式，并针对每个客户将新的客户群标识符写回到客户主数据解决方案。
业务智能和性能管理工具
本白皮书首先讲述了推动对新一代数据仓库的需求的一些力量，特别强调了不仅
需要在企业内部普遍提供 BI，而且还需要为外部利益相关方（如供应商和客户）
普遍提供 BI。 普及化 BI 对于管理数据仓库中数据的方法以及通过 BI 和性能管理 (PM) 工具提供数据的方法都具有重要的意义。
最近还有一个趋势是趋向工具标准化，以便实现更加普及化、提高开发产能和降
低总拥有成本。Oracle 拥有一套极佳的 BI 工具，并有许多客户成功案例，这些
案例说明，通过采用合适的技术平台，工具如何可以在组织中实现普及化。但
总体上，本白皮书的关注点并不是工具而是架构，因此以下各节将介绍数据仓库
架构的最重要方面。
在此并不涉及与 BI 工具更密切关联的其他领域，例如集群、负载平衡、缓存和
用户友好 UI。虽然在参考架构一节中已指出，但为了简洁起见，本白皮书在此并
不尝试明晰性能管理应用程序的角色。
BI 抽象和查询生成
大多数数据仓库解决方案都会实现各种最终用户工具和应用程序，以满足一系列
业务报表和分析要求。各种此类工具以及同步数据仓库中任何数据结构更改与最
终用户报表环境的任务常常涉及到效率问题。如果使用多个工具访问数据仓库，则
每个工具通常还对自己的通用关键性能指标 (KPI) 定义进行编码，这样即使仓库提
供单一数据源，此数据源在 BI 工具内也会支离破碎并可能更改。
通过实用数据仓库参考架构实现普及化 BI 第 15 页
Oracle 的 BI Server 在数据仓库和报表工具之间提供进一步抽象，以便数据仓库
数据模型和工具可以以不同的速度更改。BI Server 包括在架构中以提供单一企
业信息视图，而无论用于访问企业数据仓库的工具为何。BI Server 提供单个一
致的元数据模型，其中包括得出的复杂 KPI 以供任意 BI 工具通过 ODBC 接口
使用。
迭代设计方法通常基于会议室模拟的开发以及关键项目利益相关方。对于数据仓
储，这通常可能存在问题，因为当项目开始时，所需数据通常并不以适当的形式驻
留在仓库内。这意味着必须根据企业模型或源系统图人工生成数据（本身即是一项
挑战）或者采用更瀑布式的方法，以便首先确定数据元素，从而可以在探讨需求之
前建立对数据的理解。此强制性顺序意义不大，并通常导致返工。
BI Server 的查询联合功能通过允许在开发设计时将报表工具直接连接到源，提
供了另一种开发方法。了解需求之后，便可对逻辑模型采用更为严格的方法，并
以标准方式通过数据仓库供应数据。从 BI 工具的角度来看，这仅需要更改 BI Server 元数据物理映射。这种查询联合功能对于相对适中的数据量以及在所述开
发环境中非常有用，但它显然无法应对在数据仓储中常常遇到的更广泛的数据集
成、数据质量和生产数据量挑战。因此，专业管理仓库中数据的这第二步至关重
要，并且应该从一开始就包括在项目计划中。
从物理实现的角度来看，BI Server 还以集群形式提供了强健的架构式基础架
构，以实现高可用性、负载平衡和数据缓存。当考虑更普及的 BI 功能时，这
使 BI Server 成为明智的选择。
通过 SOA 将洞察和操作联系起来
我们的目标是使洞察具有可操作性以响应在分析中获得的洞察。我们使用 Oracle BI Suite 的 SOA（面向服务的架构）集成功能实现了这一目标。它允许通过信息板
调用 BPEL（业务流程执行语言）工作流，将参数（包括那些用户提示的参数）传
播到使用 SOA 编排的 BPEL 流程。它还允许将 BI 查询嵌入 BPEL 流程工作流
中。
通过 SOA 实现的 BPEL 集成可产生高效环境，在这个环境中，可以在应用程序
中，或者在编排流程组件并将组件结合在一起的流程中，通过信息板和报告执行
完全相同的查询。
通过实用数据仓库参考架构实现普及化 BI 第 16 页
ETL、消息传递和元数据
ETL 的范围从数据源通过所有数据仓库层一直延伸到 BI Server 层，以便实现
物理对象的用户表示。提取、转换和加载可实现几个过程，其中包括：
• 负载管理
• 信息生命周期管理
• 仓库管理
• 数据质量管理
参考架构一节显示了 ETL、消息传递和元数据如何像指针一样将仓库中的每个
层联系起来。以这种方式提供元数据可允许使用标准 BI 工具基于数据仓库中的 ETL、数据加载和数据质量进行报告。这可以显著提高数据的质量、可靠性和可信
度。此外，仓库管理可实现各种如下活动：流程监视和审计、序列控制和执行、
作业错误和重新启动处理。
元数据涵盖整个环境的技术和业务前景，因此可以使用元数据分析数据问题或分
析更改影响，并可由最终用户在报告和分析活动期间使用。
安全性
数据安全性是每个组织越来越关注的问题。在参考架构中，管理安全性得以极大
简化：设计中包括具有嵌入式数据集市的单一数据存储（表示单点管理和安全性实
施），而不是将数据分成多个下游数据集市以进行分析。
安全性遍及参考架构中的所有层，并具有多面性。数据仓库和 BI 工具在任意企业
范围内实现安全性，例如 LDAP 和 Active Directory。此外，至少在行级使用基于
角色的安全性保护数据库中的数据。还可能需要使用诸如虚拟专用数据库和细粒
度标签安全性之类的特性，具体取决于数据的性质和面临的威胁。使用诸如“只
读表空间”之类的其他数据库特性以防止意外更改数据也可能很有用。
最佳实践还建议特权 DBA 职责分离，以便允许他们管理数据库而不访问数据库包
含的数据。Oracle Database Vault 提供了此功能。
还可能需要能够完全审计何人实际访问了何种数据，以完全遵守一些监管机构
的规定。
通过实用数据仓库参考架构实现普及化 BI 第 17 页
数据加载过程
数据通过数据加载过程加载到数据仓库并可供查询使用。
如下面的图 4 所示。
数据通过各种机制以同步和异步方式接收到初始临时数据层。数据通过清理、丰
富、验证和集成步骤进行处理，并为加载到基础数据层作好准备。如前面所述，
将数据接收到仓库平台的速度和在仓库中刷新数据的频率由业务需求驱动。
通常，使用适当的模式（例如日期范围和地区）进行数据分区。这允许在整个数
据生命周期内进行更细粒度的管理。例如，可以在每个分区而不是整个数据集上
构建索引，并在数据分区进入和离开数据生命周期时从基础数据层加载和卸载数
据分区。
图 4 数据加载过程
数据在临时数据层准备好之后，便可以移到基础数据层，这由业务对给定数据流的
需求而决定。在 Oracle 中，这需要元数据更改而不是成本高昂的大规模数据移
动。大部分访问和性能层由自动刷新的对象组成。例如，对于视图、物化视图和多
维数据集组成的物化视图便是如此。在物化视图和多维数据集组成的物化视图中，
它们的定义还将定义如何在数据变得陈旧时或用户查询视图时刷新视图，因此将聚
合推迟在一段时间之后进行。对于需要运行加载脚本的对象，例如对于 Create Table as Select (CTAS)，在临时数据层的加载之后将执行一个 ETL 内部作
业。
为了使业务用户对数据仓库充满信心并使数据仓库作为监管报告的基础，数据质量
和查询准确性至关重要。Oracle 通过多版本读取一致性机制确保不读取或写入
脏数据，这在行业中是独一无二的。
通过实用数据仓库参考架构实现普及化 BI 第 18 页
我们在前面介绍了如何以及为什么将 COTS 程序包中的两个流引入数据仓库
中。一个流是预打包的 BI 应用程序所需的，将预定义的 ETL 作为应用程序
的一部分。从 COTS 到临时数据层和基础数据层的另一个流以标准方式处
理，与任何其他源流相同。两个流之间的任何潜在数据冲突在 BI 抽象层中解
决，以便为用户保留“单一数据源”。
信息供应过程
数据可以供任意 BI 工具引用，它们包括任意数据仓库层以及 ETL 和数据质量
流程元数据。这允许提供更广泛的分析功能，从而增加分析深度和业务流程范围
广度。大部分查询理所当然在访问和性能层进行，因为此层的全部“存在理
由”是简化用户对数据的访问。
图 5 发往 BI/PM 工具及其他的出站数据供应
性能管理应用程序还能够直接查询底层源系统，但这实际上超出了数据仓库的范
围，因此本白皮书中并没有更详细地介绍。
BI Server 还可以根据元数据将逻辑值动态映射到多个源，并使此值可用于查
询。例如，可以通过将访问和性能层中的数据与临时数据层中可用的数据结合来
生成即日销售的实时图。
对于诸如主数据管理之类的解决方案和诸如 BPEL 之类的技术，其他 Web 服务功
能可在组织内部以及为更广泛的贸易团体实现无缝数据操作化。
高级分析工具和应用程序（如预测和数据挖掘）可以通过分析流程创建新数据。
在工具或应用程序的控制下，可以从访问和性能层的分析沙坑区域读取数据并将
数据写入其中。最终确定一组数据（如客户的得分列表）之后，将执行标准数据
通过实用数据仓库参考架构实现普及化 BI 第 19 页
流，此数据流通过临时数据层获得数据并将数据移到运营系统、MDM 解决方
案或移回数据仓库。数据永远不会从访问和性能层直接加载回基础数据层。
通过实用数据仓库参考架构实现普及化 BI 第 20 页
总结
现代企业对业务智能和数据仓储解决方案的要求越来越多。不再仅由几个
临时用户仅用于标准化报表，现代企业要求更快、更普遍地访问关键业务
决策所依据的信息。这种信息量、速度和范围的变化转而推动了对支撑解
决方案的解决方案架构和技术的变革。
本白皮书旨在介绍一种实用数据仓库参考架构，该架构支持以此方式普遍
实现业务智能。此参考架构以一个设计理念在数据仓库的数据管理需求和
信息访问需求之间达成平衡，该设计理念是，确保以可持续的方式长期提
供业务价值，而在重新设计数据时没有大的重新设计或服务丢失。
参考架构是一个非常有用的设计，可以用作新数据仓库设计的设计模板，
也可以用作一种“量尺”来评估现有数据仓库实施并以此为基础制定可能
的发展规划。参考架构的基本原则十分有用，无论实际采用哪些技术来实
现参考架构都是如此。但是，Oracle Corporation 是唯一能够提供集成
组件（从磁盘到参考架构的信息板）的公司。请联系您当地的 Oracle 客户团队，了解有关 Oracle 技术如何帮助您在组织中更普遍地
实现业务智能的更多信息。
甲骨文（中国）软件系统有限公司 北京远洋光华中心办公室 地址：北京市朝阳区景华南街5号远洋光华中心C座21层 邮编：100020 电话：(86.10) 6535-6688 传真：(86.10) 6515-1015 北京上地6号办公室 地址：北京市海淀区上地信息产业基地，上地西路8号，上地六号大厦D座702室 邮编：100085 电话：(86.10) 8278-7300 传真：(86.10) 8278-7373 上海分公司 地址：上海市黄浦区天津路155号名人商业大厦12层 邮编：200021 电话：(86.21) 2302-3000 传真：(86.21) 6340-6055 广州分公司 地址：广州市天河区珠江新城华夏路8号合景国际金融广场18楼 邮编：510623 电话：(86.20) 8513-2000 传真：(86.20) 8513-2380 成都分公司（川信大厦办公室） 地址：成都市人民南路二段18号四川川信大厦20层A&D座 邮编：610016 电话：(86.28) 8619-7200 传真：(86.28) 8619-9573 成都分公司（高新国际广场办公室） 地址：成都市高新区天韵路150号高新国际广场D座四楼18-19，22-25单元 邮编：610041 电话：(86.28) 8530-8600 传真：(86.28) 8530-8699 大连分公司 地址：大连软件园东路23号大连软件园国际信息服务中心2号楼五层502号A区 邮编：116023 电话：(86.411) 8465-6000 传真：(86.411) 8465-6499 济南分公司 地址：济南市泺源大街150号，中信广场11层1113单元 邮编：250011 电话：(86.531) 8518-1122 传真：(86.531) 8518-1133 沈阳分公司 地址：沈阳市沈河区青年大街219号，华新国际大厦17层D单元 邮编：110016 电话：(86.24) 2396 1175 传真：(86.24) 2396 1033
南京分公司 地址：南京市玄武区洪武北路55号，置地广场19层1911室 邮编：210028 电话：(86.25) 8476-5228 传真：(86.25) 8476-5226 杭州分公司 地址：杭州市西湖区杭大路15号，嘉华国际商务中心702室 邮编：310007 电话：(86.571) 8717-5300 传真：(86.571) 8717-5299 西安分公司 地址：西安市高新区科技二路72号，零壹广场主楼1401室 邮编：710075 电话：(86.29) 8833-9800 传真：(86.29) 8833-9829 福州分公司 地址：福州市五四路158号，环球广场1601室 邮编：350003 电话：(86.591) 8801-0338 传真：(86.591) 8801-0330 重庆分公司 地址：重庆市渝中区邹容路68号，大都会商厦1611室 邮编：400010 电话：(86.23) 6370-8898 传真：(86.23) 6370-8700 深圳分公司 地址：深圳市南山区高新南一道飞亚达大厦16层 邮编：518057 电话：(86.755) 8396-5000 传真：(86.755) 8601-3837 甲骨文软件研究开发中心（北京）有限公司 地址：北京市海淀区中关村软件园孵化器2号楼A座一层 邮编：100094 电话：(86.10) 8278-6000 传真：(86.10) 8282-6455 深圳分公司 地址：深圳市南山区高新南一道德赛科技大厦8层0801-0803单元 邮编：518057 电话：(86.755) 8660-7100 传真：(86.755) 2167-1299 甲骨文亚洲研发中心-上海 地址：上海市杨浦区淞沪路290号创智天地10号楼512-516单元 邮编：200433 电话：(86.21) 6095-2500 传真：(86.21) 6095-2555
通过实用数据仓库参考架构实现普及化 BI
2010 年 2 月 作者：Doug Cackett
特别感谢：Andrew Bond、Kevin Lancaster 和 Keith Laker 公司网址：http://www.oracle.com（英文） 中文网址：http://www.oracle.com/cn（简体中文） 销售中心：800-810-0161 售后服务热线：800-810-0366 培训服务热线：800-810-9931 欢迎访问： http://www.oracle.com（英文） http://www.oracle.com/cn（简体中文） 版权© 2011 归 Oracle 公司所有。未经允许，不得以任何
形式和手段复制和使用。 本文的宗旨只是提供相关信息，其内容如有变动，恕不另行
通知。Oracle 公司对本文内容的准确性不提供任何保证，
也不做任何口头或法律形式的其他保证或条件，包括关于适
销性或符合特定用途的所有默示保证和条件。本公司特别声
明对本文档不承担任何义务，而且本文档也不能构成任何直
接或间接的合同责任。未经 Oracle 公司事先书面许可，严
禁将此文档为了任何目的，以任何形式或手段(无论是电子
的还是机械的)进行复制或传播。 Oracle 是 Oracle 公司和/或其分公司的注册商标。其他名
字均可能是各相应公司的商标。
