一、摘要

传统数据仓库架构在过去25年中为许多组织提供了优质服务。这种结构的典型特征是它由一系列数据库组成，例如暂存区（staging area）、中央数据仓库和数个数据集市，利用ETL（提取-转换-加载）程序把数据从一个数据库推送到另一个数据库。但是，业务需求是随着时间的推移而发生变化的，适合15到25年前业务需求的架构，不一定还能适合现在的需求。目前，传统数仓架构具有以下缺点：

灵活性有限

对操作型商业智能（operational business intelligence）的支持有限

大数据整合复杂

自助式BI受限

对双模式BI（Bi‐modalBI）的重要支持

外部数据导入复杂

重复数据

数据质量下降

最近出现了许多可以开发更灵活架构的新技术，数据虚拟化技术便是其中之一。本文介绍了逻辑数据仓库架构的一种设计方法，该方法利用了Red Hat基于社区项目Teiid研发的JBoss数据虚拟化服务器（JDV）。逻辑数仓架构是一种更为灵活的架构，BI技术人员利用这种架构可以更快地开发新报表或更改现有报表; 同时，它能更容易的将新数据源（如大数据和外部数据）纳入到数仓之中。另外，用户查看运营数据的难度较低，因为在逻辑数仓架构中没有开发数据库链路（chain of databases），换句话说，逻辑数仓架构需要的重复数据更少。

本文介绍了利用JDV开发逻辑数仓架构的两种方法。第一种方法是将现有传统数仓架构迁移到逻辑数仓架构。这种渐进式方法可帮助企业组织逐步迁移，几乎不会对当前BI工作量造成任何干扰。第二种方法则侧重于介绍如何在全新的环境中设置逻辑数仓架构。

注意：阅读本文前，建议读者首先阅读文章《数据虚拟化环境设计步骤分解》，这篇文章分步骤介绍了如何基于JDV设计和开发数据虚拟化环境。

二、传统数据仓库架构

数据仓库不是一个新概念，大多数企业组织都已经开发了数据仓库来支持他们的报表和分析工作。数据仓库存在几种定义，其中Bill Inmon给出了通俗的定义：“数据仓库是一个面向主题的、集成的、反映历史变化的、非易变的数据集合，用于支持管理决策过程。”

通常，数据仓库不是孤立存在的，而是存在于一个较大的数据库链或数据库网络中的数据库，它们共同组成数据仓库架构（见图1）。构成此架构的其它数据库通常还有一个暂存区（staging area），一个操作型数据存储（Operational Data Store）和多个数据集市。此架构所处理的数据来自多个源系统。ETL程序将数据从一个数据库复制到另一个数据库。数据集市则是为满足用户对于信息和报表的需求而设置的数据库。

图1 传统数仓架构包括一个数据库链，数据仓库只是其中一个数据库

在过去超过25年的时间里，这种架构为许多企业组织提供了很好的服务。因此，长期以来，依赖硬件和软件技术状态的传统数仓是合适的架构。但考虑到现在这些新的业务需求和技术，它仍然合适吗？对于某些企业组织而言，可能仍然合适；但对于许多企业组织而言，传统数仓架构具有了一定的局限性。

1 灵活性有限

由于该架构由一系列相互关联的数据库和程序组成，因此其灵活性有限。即使是最简单的报表更改（例如添加新列或维度），也可能导致整个架构多处发生变化：它可能导致数据集市和数据仓库本身表格的更改，也能导致ETL程序的更改。此外，如果业务概念的定义发生变化，那么它在整个架构中的实现都要有所变化。添加源系统也是一项重大任务，因为它会导致ETL程序和现有数据库结构的改变。

2 对操作型BI的支持有限

越来越多的用户需要通过查看最新或接近最新的数据才能做出决策。他们需要查看实时数据，而不是昨天的数据，特别是运营经理更是需要100％最新的数据。在传统数仓架构中，数据从源系统传输到报表，需要一次一次的从上一个数据库复制到下一个数据库，数据库链路过长，这个复杂的复制过程并不能在几微秒内完成。要支持操作型BI，需要对传统架构做重大改动，通过移除数据存储和减少复制步骤来简化架构。

3 大数据整合复杂

在传统架构中，整合来自大数据系统的数据（如传感器数据和社交媒体数据）的需求正在迅速增加。但是，如何将大数据纳入传统数仓架构中呢？我们不能将大数据系统视为普通的源系统。想象一下，大数据系统中的所有新数据必须定期复制到暂存区，然后复制到数据仓库，最后将聚合的大数据复制到多个数据集市。我们不建议采用此方法，原因如下：

存储多份大数据副本会增加数据存储成本

将大数据从一个数据库传输到另一个数据库会花费大量时间

加载数次大数据会十分耗时

大数据加重了现有数据库的负担，造成查询性能下降

备份和还原操作都会变慢，并且会消耗大量资源

我们不能像处理普通源系统那样来处理大数据系统，需要选择一种特殊的方式。

4 自助BI受限

最近几年出现了许多可供大家使用的自助式BI工具，如QlikView，Tableau，以及TibcoSpotfire。它们有着直观、图形化且易于使用的界面，这使得IT背景很少、甚至没有IT背景的业务用户和决策者都能够以他们想要的任何方式来开发报表和分析数据。这些工具可以让他们自由分析数据。

人们不断强调着自助式BI对商业用户的重要价值，但没什么东西是完美的。最初，所有这些工具看起来都很容易使用，但Wayne Eckerson的一项研究展示出了它们的一些缺点。报告中指出：64％的企业组织在自助式BI中苦苦挣扎，给自己在自助式BI能动性方面的评价为“普通”或更低，29％的自助式BI评级为“一般”或“较差”。显然，部署自助式BI工具并非没有问题。

最初，IT技术人员为传统数据使用形式开发了传统数据仓库架构，而在某种程度上，这种传统的数据使用形式与自助服务的形式相冲突。通常，自助服务用户仅可以访问一个或两个数据集市。但是，就算IT只限制他们使用某个特定的数据集市，它们的自助服务仍然会受到这个数据集市的限制，包括这个数据集市中包含什么数据，数据如何定义以及实现哪些关系。用户仍然没有完全自由地分析数据。

5 对双模式BI的重要支持

双模式（Bi-modal）概念是由Gartner公司引入的，指IT开发的两种模式。 模式1是传统的IT开发形式，其中每个系统都必须可靠、可预测且安全，必须经过正式地测试、治理、管理，并且必须是可审计的等等。模式2指的是更敏捷的开发风格，更注重速度和敏捷性。同样，报表和分析的开发模式也可以用这种方式区分。一些报表必须可靠、可预测，经过测试和治理，并且可复用等，这是典型的第1种开发模式；而自助式BI显然是第2种开发模式的一个例子，因为自助式BI追求的就是快速开发和敏捷性。

我们的挑战在于将两种开发模式合并到一起。首先，利用两种模式开发出的报表的结果必须一致；其次，利用第2种开发模式开发的报表必须能迁移到第1种开发模式的环境中；这有时被称为工程化。实践表明，这种合并在传统数仓架构中并不明显。大多数情况下，这两种模式保持彼此独立。

企业组织必须支持这两种开发模式。在Gartner公司的调查中，45％的CIO表示他们目前正在利用第2种开发模式，并且预测到2017年将有75％的IT组织具有双模式功能，也就意味着他们会支持两种模式。

6 外部数据导入复杂

内部数据一般由IT部门管理，存储在源系统中。越来越多的业务分析师和数据科学家不再局限于分析内部数据，而是利用所有他们可以得到的数据，其中就包括外部数据。特别是精通技术的分析师从互联网获取数据（如研究结果），访问社交媒体数据，分析开放数据和公共数据，获取同事分析结果的文件等等。他们将这些外部数据与内部数据相结合，从而得到最完整、最准确的业务洞察。

每天都会有更多带有开放数据的文件公开，例如包含天气相关数据、医疗数据、污染数据、社会人口统计数据、犯罪数据、机场数据、车辆碰撞数据的数据集，特别是政府部门提供了大量有价值的数据。在撰写本文时，可使用的包含美国政府开放数据的数据集有189,920个。

那么如何将外部数据集成到传统数仓架构中呢？这是我们所面临的难题。如果将外部数据源视为与内部数据源相同的源，则必须将其添加到架构左侧的数据源。还要添加数据仓库和多个数据集市中的数据结构，并且开发许多新的ETL程序来处理外部数据。这需要相当长的开发时间，而目前用户没有时间等待。他们希望自己集成这些新数据源，从而绕过所有现有业务规则。此外，在这种情况下，许多用户正在一遍又一遍地重新造轮子，因为他们都在开发自己的集成解决方案。

7 重复数据

传统数仓架构中存储着大量的重复数据。例如，大多数数据集市的数据源自数据仓库，这意味着数据集市中的数据全部都是多余的；即使数据暂存区和数据仓库也包含大量的重叠数据。此外，许多重复数据以索引、物化查询表、具有聚合数据的列和表等形式存储在每个数据库内部。显然，存储这些重复数据有许多原因，但查询性能、报表性能和ETL脚本的性能是主要原因。

存储不再像以前那样昂贵，那么重复数据带来的问题是什么呢？答案是敏捷性。存储的重复数据越多，架构就越不灵活。每次更改数据，都需要对那些重复数据进行更改。保持重复数 据的同步涉及到各种成本。因此，删除大多数重复数据，可以大大简化数仓架构。

8 数据质量下降

当同一数据有多个副本时，总会存在数据变得不一致的风险。换句话说，数据的复制和存储是在传统数仓架构中完成的，过程会涉及数据质量降低的风险。David Loshin这样描述：“......每次复制数据时，或多或少的会发生数据转换，每一次的数据转换都增加了数据错误的几率，每一次复制后的数据越来越偏离原始数据源。复制数据只会导致熵以及数据不一致。”对于每个数仓架构来说，其中一个目标必须是最大限度地减少数据重复，从而最大限度地减少数据质量下降的风险。

三、逻辑数据仓库架构

逻辑数据仓库架构是传统数仓架构的一种替代方案，这是一种灵活的架构，利用这种架构所设计、开发和运行的系统可以支持各种形式的商业智能。逻辑数仓架构的本质是数据消费者和数据源相互解耦，但是共享元数据规范（见图2）。

图2 在逻辑数仓架构中，数据消费者与数据源相互解耦

1 逻辑数仓架构定义

“逻辑数据仓库架构向数据消费者提供数据和元数据，以支持决策、报表和数据检索; 数据和元数据存储通过元数据驱动层与数据消费者解耦，从而提高灵活性，并且数据和元数据以面向主题的、集成的、反映历史变化的以及可复用的风格呈现。”

请注意，Bill Inmon对数据仓库的定义（参阅第2节）同样也适用于逻辑数据仓库。在这个定义中并没有声明必须存储数据集合。逻辑数仓架构的定义显然是基于Inmon对数据仓库的定义，除了在定义的最后，“可复用的（reproducible）”替换了“非易变的（non‐volatile）”。Inmon使用“非易变的”这个词来表示许多用户希望随着时间的推移仍然能看到不变的报表结果，他们每天运行几次报表，想看到相同的结果。但是，数据库的设计方式应该是这样：尽管它是易变的，但是仍然能呈现始终一致的报表结果。因此，在逻辑数仓架构的定义中，使用的词语是“可复用的”。

2 数据虚拟化技术

目前存在若干用于开发逻辑数仓的技术，诸如数据库服务器视图，企业服务总线（ESB），数据网格，内存数据库服务器以及数据虚拟化服务器。这些技术都有各自的优点，但数据虚拟化服务器最适合用于开发逻辑数据仓库。这就是本文介绍如何使用Red Hat的数据虚拟化产品数据虚拟化服务器（JBoss Data VirtualizationServer，JDV）设计和开发逻辑数仓架构的原因。

但是请注意，逻辑数仓只是数据虚拟化的其中一个用例。JDV等数据虚拟化产品还可用于简化应用程序服务接口的开发，使用户更容易访问数据，在多个数据源上实现整体数据安全层，转换API以进行数据访问等等。

四、四个视图层

JDV的关键组件是视图，每个视图都有一个数据结构和一个定义虚拟内容的定义。实践表明，在定义逻辑数据仓库时，需要多层视图。事实上，我们一般建议至少使用四层视图（见图3），这一点与《数据虚拟化环境设计步骤分解》一文是一致的。

在这个架构中，每个视图层都有它自己的作用（从底层开始）：

虚拟基础层：虚拟基础层中的视图显示的是存储在源系统中的数据。我们为源系统中的每个物理表或文件都定义一个或多个视图，每个视图定义都可能包含清洗规范，从而提高源系统的数据质量。除了修正数据之外，这层视图的虚拟内容与源系统的内容相同。

企业数据层：第二层的视图提供了源系统中所有数据的集成视图，因此称为企业数据层。每个视图的结构都是“中性的”，换句话说，它不针对某个数据消费者的需求，而是支持尽可能多的使用形式。如果可能的话，每个视图都根据第三范式构建。

共享规范层：为避免数据消费视图中存在太多重复或可能相互矛盾的规范，第三层包含的主要是共享规范。共享规范层存在的目的是避免重复规范，构建尽可能敏捷的环境。共享规范层也可以包含授权规范（比如允许哪位用户使用哪个视图）。

数据消费层：数据消费层每个视图的结构侧重于简化数据消费者的数据访问。例如，某些数据消费者希望将数据组织为星型模式，而另外一些数据消费者则希望能够在一个包含大量列的视图中查看所需的所有数据。在数据消费层指定过滤、映射、转换和聚合等操作，仅向数据消费者展示他们所需的相关数据。

图3 利用数据虚拟化技术设计的包含四层视图的逻辑数仓架构

对比四个视图层与传统数仓架构中的数据库，数据消费层及共享规范层中的视图和传统数仓架构中的数据集市十分相似，只不过传统架构中的数据集市是物理数据库，而这里的视图可以看作是虚拟数据库。同样，企业数据层与传统数仓架构的数据仓库大体上也可以看作是对应的。

五、从传统数仓架构迁移到逻辑数仓架构

许多企业组织已经构建了自己的数据仓库架构—设计了数据库，开发了ETL脚本，并且报表也已经正常运行。本章所介绍的是企业组织如何在不干扰现有数据消费者的情况下，逐步从传统数仓架构迁移到逻辑数仓架构。这并不是从头构建逻辑数仓的方法，而是一种从传统数仓演进为逻辑数仓的方法。但是，如果有企业组织想要开发一个新的逻辑数仓架构来支持商业智能系统，我们就会建议其采用另外一种方式（详见第6节 ）。

1. 导入源系统

假设我们已经安装了JDV数据虚拟化服务器，访问Red Hat网站，查看几个操作系统的详细安装过程。

首先我们要确定现有架构的数据集市里的哪些表仍在使用中，然后为每个仍在使用的表定义一个JDV源表，并且在每个源表上定义一个视图（见图4）。这一步定义的源表和视图是虚拟基础层的一部分，这些源表和视图必须与数据集市中的表一一对应。因此，这部分定义的视图没有使用复杂的转换、连接或聚合操作。接下来，在虚拟基础层中定义的每个视图上定义数据消费层中的视图。同样，这些数据消费层视图的定义也很简单，并且必须与虚拟基础层的视图一一对应。

图4

2. 重定向数据消费者

在这一步，我们需要对每个数据消费者进行重定向，让他们通过数据消费层中定义的视图来访问数据集市（见图5）。例如，数据消费者不再使用JDBC驱动程序来直接访问那些基于SQL的物理数据集市，而是使用JDV的JDBC驱动程序来访问JDV，JDV去访问上文所述的基于SQL的数据集市。

第2步的效果是数据消费者访问的依然是相同数据集市中的相同数据，并且查询结果保持不变，因为第1步中定义的视图有着与源表相同的数据结构和虚拟内容，而这些源表正是数据消费者最初访问的源表。因此，JDV从数据消费者那里接收查询，并将其传递到底层的数据集市，查询结果再被返回给数据消费者。与使用传统数仓架构唯一的区别是现在我们通过JDV来处理查询。

图5 在第2步中数据消费者被重定向到访问数据消费层中定义的视图

3. 移除派生数据

在传统数仓架构中，将包含派生数据的列和表添加到数据集市中来提高查询性能，这是很常见的。例如，在部门表中存储了员工总数（派生列），在另一个表中存储了售出产品和退回产品之间的差异 。

在第3步中，首先我们要尽可能多地移除存储在数据集市中的冗余派生数据，从而简化整体架构（见图6），这样数据消费层中视图的定义也会随之变化。例如，在第2步之后，我们仍然是从虚拟基础层视图中的相应列检索每个部门的员工数量，而虚拟基础层的视图则通过源表从数据集市中的列检索员工数量。在第3步中，我们把计算员工数量的公式添加到数据消费层的视图定义中，计算员工数量的逻辑来自负责计算派生数据的ETL脚本。ETL脚本也必须要进行改写，因为必须要删除脚本里计算派生数据的逻辑。此外，还需要移除数据集市里的派生列或派生表（在没有其他数据消费者消费派生数据的前提下）。

图6 在第3步中，数据消费层中的视图定义改变了，移除了数据集市中的派生数据，简化了ETL逻辑

派生数据的移除对于数据消费者来说是透明的，这一点很重要。但是报表结果必须和以前一样。

4. 把ETL逻辑迁移到视图中

数据集市中的大多数表都包含从数据仓库中派生的数据。在第4步中，我们通过最小化数据集市的使用率来继续简化整体架构（见图7）。重新定义数据消费层中的视图来访问数据仓库中的原始数据。换句话说，原来访问数据集市中的表的视图，现在被重定向到访问包含相同数据的数据仓库中的表，尽管这些数据可能被组织在一组不同的表和列中。

要想重定向视图，首先要在虚拟基础层中定义源表和视图，与第1步中为数据集市中的表定义视图的方式相同，它们都要与数据仓库中的实际表一一对应。接下来，在数据消费层的现有视图中执行ETL脚本中的逻辑，这个逻辑是用来加载数据集市中的表的。这些ETL脚本中还包含一种逻辑，可以将数据仓库表中的数据转变为数据集市中的表，在数据消费层视图的定义中也应用了相同的逻辑。所有这些逻辑的转换都必须保证视图具有与原始数据集市的表相同的数据结构和相同的虚拟内容。

跟第3步一样，这种变化对于数据消费者来说是透明的，但是报表结果必须和以前一样。

图7 在第4步中，改变数据消费层中的视图定义，从而访问指向数据仓库中表的源表

5. 移除数据集市中废弃的表

由于查询已重新定向到数据仓库中的表，就不需要再访问数据集市中的表了，也就可以删除这些表了。如果删除了数据集市的所有表，那整个数据集市也可以删除（见图8）。此外，加载数据集市的ETL脚本也可以删除。

到第5步为止，现有报表没有任何更改，报表结果与引入逻辑数仓架构之前依然相同。但是，报表性能可能有所改变，根据所用数据库和硬件技术的不同，报表性能可能会有所提高或下降。

6. 确定公共视图定义

这一步主要是做一个清理操作。多个视图（可能来自不同的数据集市）具有类似的甚至相同的定义，因为第1步中定义的视图结构与数据集市中的原始表的结构相同，并且因为它们现在都从数据仓库中提取数据。例如，两个数据集市可能包含相同的产品和客户维度表，在第1步的操作之后，数据消费层中出现了两个关于产品数据的视图和两个关于购物数据的视图。

在第6步中，我们会将数据消费层中的公共视图定义移动到共享规范层中定义的视图上（见图10），如果数据消费层中的两个视图是100％相同的，我们甚至可以合并这两个视图。在第6步之后，整个视图定义集会更易于维护，因为重复规范的数量已经降到最低了。

图8 在第5步中，移除了废弃的数据集市和ETL脚本

7. 定义企业数据层

到第6步为止，我们定义的所有视图的数据结构都直接或间接地源自现有数据集市和数据仓库的数据结构，这些数据结构可能并不完善。因此我们建议在企业数据层上中引入定义明确的具有中性和规范化数据结构的视图，然后将这些视图映射到虚拟基础层中的视图，最后，重新定义共享规范层中的视图，使其与企业数据层中的新视图一起运行。

引入企业数据层可能会导致业务概念的定义有略微调整。如果发生这种情况，视图定义和报表也会发生变化。业务用户需要注意这一点。

图9 在第6步中，数据消费层视图定义中的公共规范移到了共享规范层

8. 为自助使用留出空间

在《数据虚拟化环境设计步骤分解》一文中，我们描述了传统使用形式和自助使用形式的概念。传统使用形式与第1种开发模式相关，自助使用形式与第2种开发模式相关（参阅第2节）。前面步骤中定义的视图都属于传统使用形式，对于自助使用形式，我们需要定义一个特殊区域，这个特殊区域在数据消费层和共享规范层中，业务用户可以在这里开发自己的视图。换句话说，这个区域主要用于支持自助分析和第2种开发模式。

我们仅允许业务分析师和用户在企业数据层视图之上开发视图，这可以解决两个问题。首先，因为数据消费层上的所有视图都是通过企业数据层检索数据，所以所有视图都共享相同的规范，这样可以提高模式1和模式2报表的一致性。其次，如果特定业务用户开发的报表必须对其他用户可用（产业化），我们则可以很简单地将相关视图从自助使用区域移动到传统使用区域。

图10 在第7步中，在企业数据层中定义视图，这些视图标准化了数据结构

9. 优化性能

定义缓存、优化索引以及更新统计信息等可以改善查询性能。详情可参阅数据虚拟化环境设计步骤分解一文。

10. 访问源系统

到上一步为止，所有报表仍然是从数据仓库中检索数据，我们要研究的是可否将数据仓库中的一些查询工作量迁移到源系统，特别是一些较新的源系统可能有能力处理来自逻辑数仓的工作量。这对对操作型数据感兴趣的用户来说是一个极大的好处。

如果可以查询源系统，则逻辑数仓架构需要清洗操作型数据，这一点是非常重要的，可以通过在虚拟基础层的视图中实现清洗规则来完成，详情可参阅《数据虚拟化环境设计步骤分解》一文。

这种逐步迁移到逻辑数据仓库的方法的主要好处在于它是一种无缝迁移，已有的数据消费者不必关注系统所做的更改。此外，逻辑数仓架构更加灵活，可以更快地生成新报表以及更改已有报表。

另外，在第10步中，一些视图被重定向到操作型系统，这意味着不用再将某些源系统数据存储到数据仓库中。但是，如果去掉了数据仓库的某些组成部分，我们还能称之为数据仓库吗？或许换个名字会更合适？例如，数据储存库。这一主题我们会在下一节中详细介绍。

六、在全新的环境中开发逻辑数仓

如果企业组织没有数据仓库，想要从头开发一个逻辑数据仓库，我们就会提供一个全然不同的设计方法。本节重点介绍另一种设计方法的步骤。

1. 开发暂存区和数据储存库

开发逻辑数仓架构，第一步先要开发两个数据库：暂存区和所谓的数据储存库（参见图11）。

图11 第1步，开发暂存区和数据储存区，开发ETL脚本，将源系统中的数据加载到暂存区和数据储存区中

逻辑数仓架构中的暂存区与传统数仓架构中的暂存区用途一致，都是用来临时存储ETL处理后的源系统数据。然后我们再次使用ETL，ELT或数据复制来加载和更新暂存区，将数据复制到数据储存库之后，就可以将其从暂存区中删除了。

逻辑数仓架构中的数据储存库是一个可以更长时间保留当前和历史操作数据的数据库。虚拟基础层中的许多视图都是在数据储存库的表上定义的。我们需要这种数据储存库的原因包括：

并非所有源系统都能追踪历史数据。数据储存库保留当前数据和历史数据，从而支持历史报表和历史分析。

并非所有源系统都能处理所需的查询工作量，或者是性能缓慢，或者是查询太过干扰事务处理的工作量。

并非所有源系统都具有BI用户所需的性能。例如，一些陈旧的源系统仍然是晚上停止工作，早上重新启动。数据储存库则24x7全天候可用。

请注意，逻辑数仓架构中的数据储存库与数据仓库不同。在Bill Inmon给出的定义中，数据仓库中保存的数据是面向主题的，集成的，反映历史变化的和非易变的。数据储存库中的数据并不总是面向主题的，也不总是集成的，企业数据层中的视图负责数据的集成。数据储存库中的数据也许可以满足反映历史变化和非易变这两个要求。

数据储存库和数据仓库两者之间最大的区别在于，在逻辑数仓架构中，数据虚拟层提供用于报表和分析的所有数据。但是，并非所有数据都存储在数据储存库中。在传统数仓架构中，大多数（如果不是全部）用于报表的数据都存储在数据仓库中。

在设计这一部分时，我们必须考虑两个重要问题。首先，数据清洗的工作有多少；其次，必须实现多少数据集成。对于第一个决定，我们应在两个加载步骤中执行大部分清洗操作，没有在这两步中执行的清洗操作，则必须要在逻辑数仓架构的视图中执行。

本文主要介绍如何处理上游的数据清洗工作，应该尽可能靠近源系统。下游的数据清洗工作（更接近报表）更复杂，可能会非常耗费资源。在理想状态中，数据清洗工作完全由源系统本身处理，用户应该无法输入错误的数据。如果输入的数据不正确，源系统必须在数据复制到暂存区之前解决该问题。这样的话，存储在数据储存库中的就是清洗、转换以及规范化之后的数据。

我们还需要将数据储存库中表的设计规范化：每一个fact仅存储一次。如果源系统中的表结构没有真正规范化，建议使用ETL脚本将数据转换为更加关系型的结构。例如，如果源系统中的表包含重复组（如某个员工有多个电话号码，那么这个员工的其他信息也会重复多次），在这种情况下，必须在数据储存库中为其电话号码创建单独的表，源系统中该员工表的数据就会被复制到数据储存库的两个表中。

数据储存库中的表必须具备一种结构，它可以支持同一业务对象的多个版本。例如，客户表必须能够保存客户的当前地址以及以前的地址。换句话说，这些表必须能够存储历史数据，并且可以利用ETL脚本加载新数据，并将现有数据转换为历史数据。我们有几种解决方案可以正确有效地处理这个问题。

2. 导入源系统

安装JDV，从数据储存库中导入所有第一组报表可能会用到的表（见图12）。在虚拟基础层中为每一个数据储存库的表定义一个源表和一个视图。

图12 第2步，定义访问数据储存库的源表和虚拟基础层的视图，负责清洗数据

如果要检查数据储存库中数据的正确性，那么虚拟基础层的视图中就必须包含清洗规则；之后，这些视图负责改善数据质量，维持报表一致性。

有时我们需要为某些清洗规则来创建特殊表，从而帮助清洗错误值。将这些特殊表存储在数据储存库中，特殊表中的数据由逻辑数仓架构管理。

3. 定义企业数据层视图

在企业数据层中，定义表示业务对象或业务对象属性的视图（见图13）。业务对象的示例包括客户、产品和发票，这可能需要将多个虚拟基础层视图中的数据加入到一个更大的企业数据层视图中。例如，客户数据分布在多个源系统中，我们把它集成在企业数据层中，形成一个视图，显示所有客户及客户的所有数据。

图13 第3步，在企业数据层定义代表业务对象的视图

有时多个数据储存库表中的数据必须集成到一起，从而开发业务对象的一个集成视图。例如，客户数据可能分布在多个数据储存库表中，在上一步中，我们会在虚拟基础层中为每个表定义一个视图，但在企业数据层中，只能有一个包含客户数据的视图。换句话说，企业数据层的视图负责集成数据，并以一种更加面向业务的形式呈现数据。该层的数据以一种中立的或者说是规范的结构存在。因此，该层有时也被称为规范数据模型。

4. 定义数据消费层视图

数据消费层的视图在结构上是针对特定数据消费者或数据消费组的需求的（见图14）。例如，某些数据消费者使用的报表工具要求表形成星型模式；另外一些消费者可能更喜欢通过定义过滤器或聚合操作来处理从企业数据层中定义的视图派生出的视图；或者，某些数据消费者只想看当前客户数据，而非历史数据，这就意味着必须过滤掉历史数据。

图14 第4步，定义数据消费层，满足数据消费者的报表需求

我们可以将数据消费层中的视图视为虚拟数据集市，在物理数据集市（传统数仓架构的一部分）中，每个表的结构也旨在支持用户和报表需求。如文所述，构成虚拟数据集市的视图同样也旨在支持用户和报表需求。

5. 开发报表

在数据消费层的视图上开发报表（见图15）。大多数报表工具允许开发人员输入过滤、连接、聚合和操作数据的规范，我们应尽量减少在报表工具中输入这些规范，而是在JDV中实施上述规范，这样我们就可以在报表以及不同的报表工具中共享这些规范。在开发新的报表时出现新的业务洞察（business insights），这种情况并不罕见。而当出现新的业务洞察的时候，我们可能会需要对此层视图进行修改。

图15 第5步，在数据消费层的视图上开发报表

6. 定义共享规范层视图

如上文所述，数据消费层中的视图旨在满足数据消费者的需求。这些视图很容易更改，并且如果我们利用恰当的设计技术，通过在共享规范层中实现视图定义中的规范，就可以达到重复使用这些规范的效果（见图16）。从数据消费视图中删除公共或共享规范，并在属于共享规范层的视图中实现这些规范，此步骤与第5节的第6步非常相似。

图16 第6步，开发报表，需要的话可以修改视图

7. 为不同的使用形式定义区域

如第5节的第8步所述（参见：佳文推介 | 如何设计逻辑数据仓库（中篇）），要支持双模式开发，就要为不同的使用形式—传统使用形式和自助使用形式—保留至少两个区域。

8. 优化性能

查询性能可以通过定义缓存、优化索引和更新统计信息等方法来提高。（具体请参见：数据虚拟化环境设计步骤分解（下篇））

七、结语

1 数据仓库扩展

在完成所有步骤后，逻辑数仓就可以访问数据仓库或数据储存库中的数据了。然而，用户还希望访问外部数据源，并将外部数据与数据仓库中的数据结合起来，那么利用数据虚拟化技术，用户就可以通过JDV视图轻松地访问到外部数据源，从而分析该数据源中的数据，并将其与现有数据相结合。

逻辑数仓同样也可以访问大数据源。有些数据源太大，其复制过程耗费太多时间，并且代价过于昂贵，因此无法复制到数据仓库中。业务用户可以通过JDV访问大数据源，从而实现报表制作和数据分析。和访问外部数据源一样，此方法可以使业务用户透明地将大数据与数据仓库的数据相结合，他们甚至不知道自己正在访问多个系统。

这种类型的数仓扩展（data warehouse augmentation，有时也被称为data warehouse extension）展示了逻辑数仓架构和JDV技术的敏捷性，强烈建议大家使用。

2 纵向 or 横向

不管是从一个全新的环境中开发逻辑数仓架构，还是从传统数仓架构迁移到逻辑数仓架构，有一个问题我们必须要考虑：采用横向设计方法还是纵向设计方法？横向设计方法指在设计下一层视图之前，本层的设计和开发应全部完成；纵向设计方法指在设计下一层视图之前，在本层中只需定义少量视图（见图17）。如果我们使用“迭代”这个术语来形容，采用纵向设计方法，迭代周期会非常之短，而采用横向设计方法，迭代周期可能会非常长。

图17 左边为横向设计方法，右边为纵向设计方法

采用横向设计方法，在设计下一个视图层之前，要完成本层视图的设计开发。横向设计方法与企业级方式及“瀑布模型”设计技术相一致，其优点在于更容易得到一组不包含冗余规范或冗余规范最小化的视图。

采用纵向设计方法，在设计下一层视图之前，在本层中只需定义少量视图。纵向设计方法非常适合当前快速迭代开发的敏捷设计技术。此外，它还适用于现代数据仓库，现代数仓的要求是能够更快地开发，更快地更改现有报表。纵向设计方法的总体优势是：高生产率和敏捷的解决方案。如果用户需要来自某个源系统的数据，采用纵向设计可以在最短的时间内定义所需视图。换句话说，纵向设计的反应时间很短。在不考虑与其他系统集成问题的情况下，采用纵向设计方法来开发一份报表只需要几天或几周，而不是几个月。在大多数逻辑数仓项目中，纵向设计方法都倍受青睐。