大数据环境下数据仓库的实践（三）—— 数据仓库的组成部分

数据仓库从全局来看会涉及到四大块：业务源系统、ETL系统、数据应用层、数据消费层。

 

业务源系统

数据仓库中数据的来源是各个业务源系统。严格说来业务源系统不属于数据仓库的范畴。但是如果业务系统模型设计不好，对后续的数据处理将极为不利，甚至会极大的增加数据仓库建设的投入成本。

现状往往是业务系统的设计人员水平参差不齐，业务系统设计千奇百怪，甚至缺乏第三范式的考量，缺乏基本的审计字段(created_time, updated_time, created_by, updated_by)等。尤其如今在实现上大量取消主外键的主流方式下，用程序来保证外键的引用一致性更是因开发人员的思维缜密度而千差万别。因此，如果各业务系统在设计阶段有一套规范或者能让有经验的数据仓库人员共同参与考虑，对后续数据仓库的建设将产生积极作用。例如mysql中不推荐使用text改用varchar(max)，不推荐使用timestamp改用datetime等。

 

ETL系统

ETL是由三个英文单词的首字母组成的，分别是Extract, Transform, Load表示对数据的抽取、转换和加载操作。

在大数据环境下，准确来说传统的ETL变成了ELTL，也就是通常使用的sqoop、datax甚至通过流式的kafka+flume将业务源系统中的数据抽取出来并加载到Hive的时候没有做什么转换，而是在Hive中进行转换并最终加载到数据应用层里。

当我们将这一块称作一个系统的时候，它应当包含了从业务源系统抽数据开始，到数据被加载进数据应用层，以及之间的所有环节。

通常情况下将业务源系统的数据抽取过来的第一层被称作落地层(Staging Layer)，它类似于一个缓冲区，隔离了对业务系统的多次访问。除了Informatica这类专门的ETL工具，以当前Hive SQL的方式也是无法兼容从关系型数据库(RDBMS)抽取的同时做转换并加载到Hive里的。落地层在国内普遍被称作ODS层，这是一个由误用名称开始却形成了广泛命名习惯的情况。当我最早接触到ODS这个词的时候，Kimball将它描述成Operational Data Store的简写，并且它是介于业务源系统和Staging之间可选的一层。后来Kimball Group直接将ODS去掉了。Margy Ross跟我说原因是ODS这个词定义有些杂，Kimball Group内部总结后将它定性为主要服务于操作型业务目的的存储层，它是维度展现层潜在的一个数据源。维基百科中也说ODS服务于经营报表，并且可以成为数据仓库的一个来源。

在传统数据仓库中，Kimball认为ETL系统不应当支持用户的查询。但是在大数据环境下，我们不得不提供开发者对该第一手源数据进行查询的功能——这也是数据仓库开始支持业务需求的第一个表现。原因是业务源数据可能进行了分片存储，并且对查询超时做了限制，导致开发者无法对其进行统计层面的访问。

从落地层往后，到数据应用层之间是数据转换(Transform)集中的地方。在使用Hive SQL作为几乎是唯一Transform手段的大数据环境下，这中间的层级划分、数据流向，相互依赖，工作流组织等等都是需要提前规划的。我们将在后续文章中对这部分进行更细致的描述。

 

数据应用层

这块也被称作数据展现层，但是由于它同时肩负着为BI分析和业务系统提供数据的责任，我更愿意将它称作数据应用层。在这里数据已经被加工完成，所有的描述必须清晰、口径必须一致。它应当是维度建模理论的集中体现。

由于大数据的关联表现远不如Oracle等这类数据库，所以在数据应用层使用关联后的宽表是很多公司的一种选择。然而它的一个弊端也是很明显的：因为表太宽，导致各业务数据之间的耦合非常紧。其直接风险就是，当一个不重要的数据跑挂了的时候，可能会导致整个宽表不可用，最终影响了真正重要的数据。另外表过宽会导致过多的字段冗余而不清晰，从而增加数据的使用成本。

关于维度建模的更多理论和实践，会在后续章节中不断被阐述和探讨。

 

数据消费层

BI应用是这一块的大户，即使没有其他消费方，这已经是一个完整的数据仓库闭环了；其次是业务方，这在传统数仓里是不需要考虑的；最后还有数据挖掘，它可以出现在BI之后的部分，也可以独立消费数据应用层。

强大的BI工具是数据报表展现、数据可视化、即时查询以及数据分析的利器。在BI工具购买还是自研这点上，绝大多数的情况下购买的投入成本应该是更低的，除了两种情况：一种是自研能力超强且打算将来把自研的BI产品商业化；另外一种则是对BI工具的要求非常简朴，但是难保需求不会增长。

业务系统对数据统计层面的需求往往是通过API形式来满足的。因为业务查询对响应时间(rt, response time)的要求比较高，因此需要用关系型数据库、HBase或者ES(Elasticsearch)这类能满足rt的数据存储方式。这部分和业务源系统一样，不归属数据仓库的范畴。

数据挖掘可以基于数据仓库预先处理过的数据进行，挖掘技术也会部分应用到数据仓库内部。另外很多成熟的BI工具也都提供了数据挖掘的经典算法实现。