佳文推介 | 如何设计逻辑数据仓库（中篇）
Posted 敏捷大数据
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了佳文推介 | 如何设计逻辑数据仓库（中篇）相关的知识，希望对你有一定的参考价值。
导读
在上篇中我们简单介绍了一下逻辑数据仓库架构以及四个视图层，参考：，中篇和下篇我们则会介绍两种创建逻辑数仓架构的方法。首先，请看中篇—从传统数据仓库架构迁移到逻辑数据仓库架构的方法~
5架构迁移法
许多企业组织已经构建了自己的数据仓库架构—设计了数据库，开发了ETL脚本，并且报表也已经正常运行。本章所介绍的是企业组织如何在不干扰现有数据消费者的情况下，逐步从传统数仓架构迁移到逻辑数仓架构。这并不是从头构建逻辑数仓的方法，而是一种从传统数仓演进为逻辑数仓的方法。但是，如果有企业组织想要开发一个新的逻辑数仓架构来支持商业智能系统，我们就会建议其采用另外一种方式（详见第6节 ）。
假设我们已经安装了JDV数据虚拟化服务器，访问Red Hat网站，查看几个操作系统的详细安装过程。
首先我们要确定现有架构的数据集市里的哪些表仍在使用中，然后为每个仍在使用的表定义一个JDV源表，并且在每个源表上定义一个视图（见图4）。这一步定义的源表和视图是虚拟基础层的一部分，这些源表和视图必须与数据集市中的表一一对应。因此，这部分定义的视图没有使用复杂的转换、连接或聚合操作。接下来，在虚拟基础层中定义的每个视图上定义数据消费层中的视图。同样，这些数据消费层视图的定义也很简单，并且必须与虚拟基础层的视图一一对应。
图4 安装JDV数据虚拟化服务器，导入源表，在虚拟基础层和数据消费层中定义视图
在第1步中，现有报表没有任何变化，接入的依然是之前传统数仓架构中的数据集市。
在这一步，我们需要对每个数据消费者进行重定向，让他们通过数据消费层中定义的视图来访问数据集市（见图5）。例如，数据消费者不再使用JDBC驱动程序来直接访问那些基于SQL的物理数据集市，而是使用JDV的JDBC驱动程序来访问JDV，JDV去访问上文所述的基于SQL的数据集市。
第2步的效果是数据消费者访问的依然是相同数据集市中的相同数据，并且查询结果保持不变，因为第1步中定义的视图有着与源表相同的数据结构和虚拟内容，而这些源表正是数据消费者最初访问的源表。因此，JDV从数据消费者那里接收查询，并将其传递到底层的数据集市，查询结果再被返回给数据消费者。与使用传统数仓架构唯一的区别是现在我们通过JDV来处理查询。
图5 在第2步中数据消费者被重定向到访问数据消费层中定义的视图
在传统数仓架构中，将包含派生数据的列和表添加到数据集市中来提高查询性能，这是很常见的。例如，在部门表中存储了员工总数（派生列），在另一个表中存储了售出产品和退回产品之间的差异 。
在第3步中，首先我们要尽可能多地移除存储在数据集市中的冗余派生数据，从而简化整体架构（见图6），这样数据消费层中视图的定义也会随之变化。例如，在第2步之后，我们仍然是从虚拟基础层视图中的相应列检索每个部门的员工数量，而虚拟基础层的视图则通过源表从数据集市中的列检索员工数量。在第3步中，我们把计算员工数量的公式添加到数据消费层的视图定义中，计算员工数量的逻辑来自负责计算派生数据的ETL脚本。ETL脚本也必须要进行改写，因为必须要删除脚本里计算派生数据的逻辑。此外，还需要移除数据集市里的派生列或派生表（在没有其他数据消费者消费派生数据的前提下）。
图6 在第3步中，数据消费层中的视图定义改变了，移除了数据集市中的派生数据，简化了ETL逻辑
派生数据的移除对于数据消费者来说是透明的，这一点很重要。但是报表结果必须和以前一样。
数据集市中的大多数表都包含从数据仓库中派生的数据。在第4步中，我们通过最小化数据集市的使用率来继续简化整体架构（见图7）。重新定义数据消费层中的视图来访问数据仓库中的原始数据。换句话说，原来访问数据集市中的表的视图，现在被重定向到访问包含相同数据的数据仓库中的表，尽管这些数据可能被组织在一组不同的表和列中。
要想重定向视图，首先要在虚拟基础层中定义源表和视图，与第1步中为数据集市中的表定义视图的方式相同，它们都要与数据仓库中的实际表一一对应。接下来，在数据消费层的现有视图中执行ETL脚本中的逻辑，这个逻辑是用来加载数据集市中的表的。这些ETL脚本中还包含一种逻辑，可以将数据仓库表中的数据转变为数据集市中的表，在数据消费层视图的定义中也应用了相同的逻辑。所有这些逻辑的转换都必须保证视图具有与原始数据集市的表相同的数据结构和相同的虚拟内容。
跟第3步一样，这种变化对于数据消费者来说是透明的，但是报表结果必须和以前一样。
图7 在第4步中，改变数据消费层中的视图定义，从而访问指向数据仓库中表的源表
由于查询已重新定向到数据仓库中的表，就不需要再访问数据集市中的表了，也就可以删除这些表了。如果删除了数据集市的所有表，那整个数据集市也可以删除（见图8）。此外，加载数据集市的ETL脚本也可以删除。
到第5步为止，现有报表没有任何更改，报表结果与引入逻辑数仓架构之前依然相同。但是，报表性能可能有所改变，根据所用数据库和硬件技术的不同，报表性能可能会有所提高或下降。
这一步主要是做一个清理操作。多个视图（可能来自不同的数据集市）具有类似的甚至相同的定义，因为第1步中定义的视图结构与数据集市中的原始表的结构相同，并且因为它们现在都从数据仓库中提取数据。例如，两个数据集市可能包含相同的产品和客户维度表，在第1步的操作之后，数据消费层中出现了两个关于产品数据的视图和两个关于购物数据的视图。
在第6步中，我们会将数据消费层中的公共视图定义移动到共享规范层中定义的视图上（见图10），如果数据消费层中的两个视图是100％相同的，我们甚至可以合并这两个视图。在第6步之后，整个视图定义集会更易于维护，因为重复规范的数量已经降到最低了。
图8 在第5步中，移除了废弃的数据集市和ETL脚本
到第6步为止，我们定义的所有视图的数据结构都直接或间接地源自现有数据集市和数据仓库的数据结构，这些数据结构可能并不完善。因此我们建议在企业数据层上中引入定义明确的具有中性和规范化数据结构的视图，然后将这些视图映射到虚拟基础层中的视图，最后，重新定义共享规范层中的视图，使其与企业数据层中的新视图一起运行。
引入企业数据层可能会导致业务概念的定义有略微调整。如果发生这种情况，视图定义和报表也会发生变化。业务用户需要注意这一点。
图9 在第6步中，数据消费层视图定义中的公共规范移到了共享规范层
在《数据虚拟化环境设计步骤分解》一文中，我们描述了传统使用形式和自助使用形式的概念。传统使用形式与第1种开发模式相关，自助使用形式与第2种开发模式相关（参阅第2节）。前面步骤中定义的视图都属于传统使用形式，对于自助使用形式，我们需要定义一个特殊区域，这个特殊区域在数据消费层和共享规范层中，业务用户可以在这里开发自己的视图。换句话说，这个区域主要用于支持自助分析和第2种开发模式。
我们仅允许业务分析师和用户在企业数据层视图之上开发视图，这可以解决两个问题。首先，因为数据消费层上的所有视图都是通过企业数据层检索数据，所以所有视图都共享相同的规范，这样可以提高模式1和模式2报表的一致性。其次，如果特定业务用户开发的报表必须对其他用户可用（产业化），我们则可以很简单地将相关视图从自助使用区域移动到传统使用区域。
图10 在第7步中，在企业数据层中定义视图，这些视图标准化了数据结构
定义缓存、优化索引以及更新统计信息等可以改善查询性能。详情可参阅《数据虚拟化环境设计步骤分解》一文。
到上一步为止，所有报表仍然是从数据仓库中检索数据，我们要研究的是可否将数据仓库中的一些查询工作量迁移到源系统，特别是一些较新的源系统可能有能力处理来自逻辑数仓的工作量。这对对操作型数据感兴趣的用户来说是一个极大的好处。
如果可以查询源系统，则逻辑数仓架构需要清洗操作型数据，这一点是非常重要的，可以通过在虚拟基础层的视图中实现清洗规则来完成，详情可参阅《数据虚拟化环境设计步骤分解》一文。
这种逐步迁移到逻辑数据仓库的方法的主要好处在于它是一种无缝迁移，已有的数据消费者不必关注系统所做的更改。此外，逻辑数仓架构更加灵活，可以更快地生成新报表以及更改已有报表。
另外，在第10步中，一些视图被重定向到操作型系统，这意味着不用再将某些源系统数据存储到数据仓库中。但是，如果去掉了数据仓库的某些组成部分，我们还能称之为数据仓库吗？或许换个名字会更合适？例如，数据储存库。这一主题我们会在下一节中详细介绍。敬请大家期待~
如想了解更多，您还可以：
1.到Github浏览更多平台信息
https://github.com/BriData/DBus
https://github.com/edp963/davinci
https://github.com/edp963/wormhole
https://github.com/edp963/moonbox
2.加入微信群，和技术大神们点对点交流
请先添加小助手：edpstack
以上是关于佳文推介 | 如何设计逻辑数据仓库（中篇）的主要内容，如果未能解决你的问题，请参考以下文章