佳文推介 | 如何设计逻辑数据仓库（下篇）
Posted 敏捷大数据
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了佳文推介 | 如何设计逻辑数据仓库（下篇）相关的知识，希望对你有一定的参考价值。
导读
在《如何设计逻辑数据仓库》这篇文章中，我们会介绍两种逻辑数仓的设计方法。由于一些企业组织已经建立了自己的数据仓库，他们不太可能抛弃传统数仓，重新建立逻辑数仓，于是我们在中篇介绍了把传统数仓架构迁移到逻辑数仓架构的方法。在本篇中，我们则针对一个全新的环境，讲解一种从头设计逻辑数仓的方法。具体内容请看文章~
6在全新的环境中开发逻辑数仓
如果企业组织没有数据仓库，想要从头开发一个逻辑数据仓库，我们就会提供一个全然不同的设计方法。本节重点介绍另一种设计方法的步骤。
开发逻辑数仓架构，第一步先要开发两个数据库：暂存区和所谓的数据储存库（参见图11）。
图11 第1步，开发暂存区和数据储存区，开发ETL脚本，将源系统中的数据加载到暂存区和数据储存区中
逻辑数仓架构中的暂存区与传统数仓架构中的暂存区用途一致，都是用来临时存储ETL处理后的源系统数据。然后我们再次使用ETL，ELT或数据复制来加载和更新暂存区，将数据复制到数据储存库之后，就可以将其从暂存区中删除了。
逻辑数仓架构中的数据储存库是一个可以更长时间保留当前和历史操作数据的数据库。虚拟基础层中的许多视图都是在数据储存库的表上定义的。我们需要这种数据储存库的原因包括：
并非所有源系统都能追踪历史数据。数据储存库保留当前数据和历史数据，从而支持历史报表和历史分析。
并非所有源系统都能处理所需的查询工作量，或者是性能缓慢，或者是查询太过干扰事务处理的工作量。
并非所有源系统都具有BI用户所需的性能。例如，一些陈旧的源系统仍然是晚上停止工作，早上重新启动。数据储存库则24x7全天候可用。
请注意，逻辑数仓架构中的数据储存库与数据仓库不同。在Bill Inmon给出的定义中，数据仓库中保存的数据是面向主题的，集成的，反映历史变化的和非易变的。数据储存库中的数据并不总是面向主题的，也不总是集成的，企业数据层中的视图负责数据的集成。数据储存库中的数据也许可以满足反映历史变化和非易变这两个要求。
数据储存库和数据仓库两者之间最大的区别在于，在逻辑数仓架构中，数据虚拟层提供用于报表和分析的所有数据。但是，并非所有数据都存储在数据储存库中。在传统数仓架构中，大多数（如果不是全部）用于报表的数据都存储在数据仓库中。
在设计这一部分时，我们必须考虑两个重要问题。首先，数据清洗的工作有多少；其次，必须实现多少数据集成。对于第一个决定，我们应在两个加载步骤中执行大部分清洗操作，没有在这两步中执行的清洗操作，则必须要在逻辑数仓架构的视图中执行。
本文主要介绍如何处理上游的数据清洗工作，应该尽可能靠近源系统。下游的数据清洗工作（更接近报表）更复杂，可能会非常耗费资源。在理想状态中，数据清洗工作完全由源系统本身处理，用户应该无法输入错误的数据。如果输入的数据不正确，源系统必须在数据复制到暂存区之前解决该问题。这样的话，存储在数据储存库中的就是清洗、转换以及规范化之后的数据。
安装JDV，从数据储存库中导入所有第一组报表可能会用到的表（见图12）。在虚拟基础层中为每一个数据储存库的表定义一个源表和一个视图。
图12 第2步，定义访问数据储存库的源表和虚拟基础层的视图，负责清洗数据
如果要检查数据储存库中数据的正确性，那么虚拟基础层的视图中就必须包含清洗规则；之后，这些视图负责改善数据质量，维持报表一致性。
有时我们需要为某些清洗规则来创建特殊表，从而帮助清洗错误值。将这些特殊表存储在数据储存库中，特殊表中的数据由逻辑数仓架构管理。
在企业数据层中，定义表示业务对象或业务对象属性的视图（见图13）。业务对象的示例包括客户、产品和发票，这可能需要将多个虚拟基础层视图中的数据加入到一个更大的企业数据层视图中。例如，客户数据分布在多个源系统中，我们把它集成在企业数据层中，形成一个视图，显示所有客户及客户的所有数据。
图13 第3步，在企业数据层定义代表业务对象的视图
有时多个数据储存库表中的数据必须集成到一起，从而开发业务对象的一个集成视图。例如，客户数据可能分布在多个数据储存库表中，在上一步中，我们会在虚拟基础层中为每个表定义一个视图，但在企业数据层中，只能有一个包含客户数据的视图。换句话说，企业数据层的视图负责集成数据，并以一种更加面向业务的形式呈现数据。该层的数据以一种中立的或者说是规范的结构存在。因此，该层有时也被称为规范数据模型。
数据消费层的视图在结构上是针对特定数据消费者或数据消费组的需求的（见图14）。例如，某些数据消费者使用的报表工具要求表形成星型模式；另外一些消费者可能更喜欢通过定义过滤器或聚合操作来处理从企业数据层中定义的视图派生出的视图；或者，某些数据消费者只想看当前客户数据，而非历史数据，这就意味着必须过滤掉历史数据。
图14 第4步，定义数据消费层，满足数据消费者的报表需求
我们可以将数据消费层中的视图视为虚拟数据集市，在物理数据集市（传统数仓架构的一部分）中，每个表的结构也旨在支持用户和报表需求。如文所述，构成虚拟数据集市的视图同样也旨在支持用户和报表需求。
在数据消费层的视图上开发报表（见图15）。大多数报表工具允许开发人员输入过滤、连接、聚合和操作数据的规范，我们应尽量减少在报表工具中输入这些规范，而是在JDV中实施上述规范，这样我们就可以在报表以及不同的报表工具中共享这些规范。在开发新的报表时出现新的业务洞察（business insights），这种情况并不罕见。而当出现新的业务洞察的时候，我们可能会需要对此层视图进行修改。
图15 第5步，在数据消费层的视图上开发报表
如上文所述，数据消费层中的视图旨在满足数据消费者的需求。这些视图很容易更改，并且如果我们利用恰当的设计技术，通过在共享规范层中实现视图定义中的规范，就可以达到重复使用这些规范的效果（见图16）。从数据消费视图中删除公共或共享规范，并在属于共享规范层的视图中实现这些规范，此步骤与第5节的第6步非常相似。
图16 第6步，开发报表，需要的话可以修改视图
如第5节的第8步所述（参见：），要支持双模式开发，就要为不同的使用形式—传统使用形式和自助使用形式—保留至少两个区域。
查询性能可以通过定义缓存、优化索引和更新统计信息等方法来提高。（具体请参见：）
7结语
在完成所有步骤后，逻辑数仓就可以访问数据仓库或数据储存库中的数据了。然而，用户还希望访问外部数据源，并将外部数据与数据仓库中的数据结合起来，那么利用数据虚拟化技术，用户就可以通过JDV视图轻松地访问到外部数据源，从而分析该数据源中的数据，并将其与现有数据相结合。
逻辑数仓同样也可以访问大数据源。有些数据源太大，其复制过程耗费太多时间，并且代价过于昂贵，因此无法复制到数据仓库中。业务用户可以通过JDV访问大数据源，从而实现报表制作和数据分析。和访问外部数据源一样，此方法可以使业务用户透明地将大数据与数据仓库的数据相结合，他们甚至不知道自己正在访问多个系统。
这种类型的数仓扩展（data warehouse augmentation，有时也被称为data warehouse extension）展示了逻辑数仓架构和JDV技术的敏捷性，强烈建议大家使用。
不管是从一个全新的环境中开发逻辑数仓架构，还是从传统数仓架构迁移到逻辑数仓架构，有一个问题我们必须要考虑：采用横向设计方法还是纵向设计方法？横向设计方法指在设计下一层视图之前，本层的设计和开发应全部完成；纵向设计方法指在设计下一层视图之前，在本层中只需定义少量视图（见图17）。如果我们使用“迭代”这个术语来形容，采用纵向设计方法，迭代周期会非常之短，而采用横向设计方法，迭代周期可能会非常长。
图17 左边为横向设计方法，右边为纵向设计方法
采用横向设计方法，在设计下一个视图层之前，要完成本层视图的设计开发。横向设计方法与企业级方式及“瀑布模型”设计技术相一致，其优点在于更容易得到一组不包含冗余规范或冗余规范最小化的视图。
采用纵向设计方法，在设计下一层视图之前，在本层中只需定义少量视图。纵向设计方法非常适合当前快速迭代开发的敏捷设计技术。此外，它还适用于现代数据仓库，现代数仓的要求是能够更快地开发，更快地更改现有报表。纵向设计方法的总体优势是：高生产率和敏捷的解决方案。如果用户需要来自某个源系统的数据，采用纵向设计可以在最短的时间内定义所需视图。换句话说，纵向设计的反应时间很短。在不考虑与其他系统集成问题的情况下，采用纵向设计方法来开发一份报表只需要几天或几周，而不是几个月。在大多数逻辑数仓项目中，纵向设计方法都倍受青睐。
纵向设计方法和横向设计方法在《数据虚拟化环境设计步骤分解》中也有出现，具体请参考：
如想了解更多，您还可以：
1.到Github浏览更多平台信息
https://github.com/BriData/DBus
https://github.com/edp963/davinci
https://github.com/edp963/wormhole
https://github.com/edp963/moonbox
2.加入微信群，和技术大神们点对点交流
请先添加小助手：edpstack
以上是关于佳文推介 | 如何设计逻辑数据仓库（下篇）的主要内容，如果未能解决你的问题，请参考以下文章