浅谈数据仓库的基本架构

数据仓库的⽬的是构建⾯向分析的集成化数据环境，为企业提供决策⽀持（Decision Support）。其实数据仓库本⾝并不“⽣产”任何数据，同时⾃⾝也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应⽤，这也是为什么叫“仓库”，⽽不叫“⼯⼚”的原因。因此数据仓库的基本架构主要包含的是数据流⼊流出的过程，可以分为三层——源数据、数据仓库、数据应⽤：

　　从图中可以看出数据仓库的数据来源于不同的源数据，并提供多样的数据应⽤，数据⾃上⽽下流⼊数据仓库后向上层开放应⽤，⽽数据仓库只是中间集成化数据管理的⼀个平台。

　　数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流⽔线，也可以认为是数据仓库的⾎液，它维系着数据仓库中数据的新陈代谢，⽽数据仓库⽇常的管理和维护⼯作的⼤部分精⼒就是保持ETL的正常和稳定。

　　下⾯主要简单介绍下数据仓库架构中的各个模块，当然这⾥所介绍的数据仓库主要是指⽹站数据仓库。

1、数据仓库的数据来源

　　其实之前的⼀篇⽂章已经介绍过数据仓库各种源数据的类型——，所以这⾥不再详细介绍。

　　对于⽹站数据仓库⽽⾔，点击流⽇志是⼀块主要的数据来源，它是⽹站分析的基础数据；当然⽹站的数据库数据也并不可少，其记录这⽹站运营的数据及各种⽤户操作的结果，对于分析⽹站Outcome这类数据更加精准；其他是⽹站内外部可能产⽣的⽂档及其它各类对于公司决策有⽤的数据。

2、数据仓库的数据存储

　　源数据通过ETL的⽇常任务调度导出，并经过转换后以特性的形式存⼊数据仓库。其实这个过程⼀直有很⼤的争议，就是到底数据仓库需不需要储存细节数据，⼀⽅的观点是数据仓库⾯向分析，所以只要存储特定需求的多维分析模型；另⼀⽅的观点是数据仓库先要建⽴和维护细节数据，再根据需求聚合和处理细节数据⽣成特定的分析模型。我⽐较偏向后⾯⼀个观点：数据仓库并不需要储存所有的原始数据，但数据仓库需要储存细节数据，并且导⼊的数据必须经过整理和转换使其⾯向主题。简单地解释下：

　　(1).为什么不需要所有原始数据？数据仓库⾯向分析处理，但是某些源数据对于分析⽽⾔没有价值或者其可能产⽣的价值远低于储存这些数据所需要的数据仓库的实现和性能上的成本。⽐如我们知道⽤户的省份、城市⾜够，⾄于⽤户究竟住哪⾥可能只是物流商关⼼的事，或者⽤户在博客的评论内容可能只是⽂本挖掘会有需要，但将这些冗长的评论⽂本存在数据仓库就得不偿失；

　　(2).为什么要存细节数据？细节数据是必需的，数据仓库的分析需求会时刻变化，⽽有了细节数据就可以做到以不变应万变，但如果我们只存储根据某些需求搭建起来的数据模型，那么显然对于频繁变动的需求会⼿⾜⽆措；

　　(3).为什么要⾯向主题？⾯向主题是数据仓库的第⼀特性，主要是指合理地组织数据以⽅⾯实现分析。对于源数据⽽⾔，其数据组织形式是多样的，像点击流的数据格式是未经优化的，前台数据库的数据是基于OLTP操作组织优化的，这些可能都不适合分析，⽽整理成⾯向主题的组织形式才是真正地利于分析的，⽐如将点击流⽇志整理成页⾯（Page）、访问（Visit或Session）、⽤户（Visitor）三个主题，这样可以明显提升分析的效率。

　　数据仓库基于维护细节数据的基础上在对数据进⾏处理，使其真正地能够应⽤于分析。主要包括三个⽅⾯：

3、数据的聚合

　　这⾥的聚合数据指的是基于特定需求的简单聚合（基于多维数据的聚合体现在多维数据模型中），简单聚合可以是⽹站的总

Pageviews、Visits、Unique Visitors等汇总数据，也可以是Avg. time on page、Avg. time on site等平均数据，这些数据可以直接地展⽰于报表上。

4、多维数据模型

　　多维数据模型提供了多⾓度多层次的分析应⽤，⽐如基于时间维、地域维等构建的销售星形模型、雪花模型，可以实现在各时间维度和地域维度的交叉查询，以及基于时间维和地域维的细分。所以多维数据模型的应⽤⼀般都是基于联机分析处理（Online Analytical Process,OLAP）的，⽽⾯向特定需求群体的数据集市也会基于多维数据模型进⾏构建。

5、业务模型

　　这⾥的业务模型指的是基于某些数据分析和决策⽀持⽽建⽴起来的数据模型，⽐如我之前介绍过的⽤户评价模型、关联推荐模型、RFM分析模型等，或者是决策⽀持的线性规划模型、库存模型等；同时，数据挖掘中前期数据的处理也可以在这⾥完成。

6、数据仓库的数据应⽤

　　之前的⼀篇⽂章——中介绍过数据仓库的四⼤特性上的价值体现，但数据仓库的价值远不⽌这样，⽽且其价值真正的体现是在数据仓库的数据应⽤上。图中罗列的⼏种应⽤并未包含所有，其实⼀切基于数据相关的扩展性应⽤都可以基于数据仓库来实现。

7、报表展⽰

　　报表⼏乎是每个数据仓库的必不可少的⼀类数据应⽤，将聚合数据和多维分析数据展⽰到报表，提供了最为简单和直观的数据。

8、即席查询

　　理论上数据仓库的所有数据（包括细节数据、聚合数据、多维数据和分析数据）都应该开放即席查询，即席查询提供了⾜够灵活的数据获取⽅式，⽤户可以根据⾃⼰的需要查询获取数据，并提供导出到Excel等外部⽂件的功能。

9、数据分析

　　数据分析⼤部分可以基于构建的业务模型展开，当然也可以使⽤聚合的数据进⾏趋势分析、⽐较分析、相关分析等，⽽多维数据模型提供了多维分析的数据基础；同时从细节数据中获取⼀些样本数据进⾏特定的分析也是较为常见的⼀种途径。

10、数据挖掘

　　数据挖掘⽤⼀些⾼级的算法可以让数据展现出各种令⼈惊讶的结果。数据挖掘可以基于数据仓库中已经构建起来的业务模型展开，但⼤多数时候数据挖掘会直接从细节数据上⼊⼿，⽽数据仓库为挖掘⼯具诸如SAS、SPSS等提供数据接⼝。

11、元数据管理

　　元数据（Meta Date），其实应该叫做解释性数据，或者数据字典，即数据的数据。主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运⾏状态。⼀般会通过元数据资料库（Metadata Repository）来统⼀地存储和管理元数据，其主要⽬的是使数据仓库的设计、部署、操作和管理能达成协同和⼀致。

　　最后做个Ending，数据仓库本⾝既不⽣产数据也不消费数据，只是作为⼀个中间平台集成化地存储数据；数据仓库实现的难度在于整体架构的构建及ETL的设计，这也是⽇常管理维护中的重头；⽽数据仓库的真正价值体现在于基于其的数据应⽤上，如果没有有效的数据应⽤也就失去了构建数据仓库的意义。

12、⼀种Hadoop多维分析平台的架构

整个架构由四⼤部分组成：数据采集模块、数据冗余模块、维度定义模块、并⾏分析模块。如图上图所⽰。

数据采集模块采⽤了Cloudera的Flume，将海量的⼩⽇志⽂件进⾏⾼速传输和合并，并能够确保数据的传输安全性。单个collector宕机之后，数据也不会丢失，并能将agent数据⾃动转移到其他的colllecter处理，不会影响整个采集系统的运⾏。如图5所⽰。

数据冗余模块不是必须的，但如果⽇志数据中没有⾜够的维度信息，或者需要⽐较频繁地增加维度，则需要定义数据冗余模块。通过冗余维度定义器定义需要冗余的维度信息和来源（数据库、⽂件、内存等），并指定扩展⽅式，将信息写⼊数据⽇志中。在海量数据下，数据冗余模块往往成为整个系统的瓶颈，建议使⽤⼀些⽐较快的内存NoSQL来冗余原始数据，并采⽤尽可能多的节点进⾏并⾏冗余；或者也完全可以在Hadoop中执⾏批量Map，进⾏数据格式的转化。

维度定义模块是⾯向业务⽤户的前端模块，⽤户通过可视化的定义器从数据⽇志中定义维度和度量，并能⾃动⽣成⼀种多维分析语⾔，同时可以使⽤可视化的分析器通过GUI执⾏刚刚定义好的多维分析命令。

并⾏分析模块接受⽤户提交的多维分析命令，并将通过核⼼模块将该命令解析为Map-Reduce，提交给Hadoop集群之后，⽣成报表供报表中⼼展⽰。

核⼼模块是将多维分析语⾔转化为MapReduce的解析器，读取⽤户定义的维度和度量，将⽤户的多维分析命令翻译成MapReduce程序。核⼼模块的具体逻辑如图下图所⽰。

上图中根据JobConf参数进⾏Map和Reduce类的拼装并不复杂，难点是很多实际问题很难通过⼀个MapReduce Job解决，必须通过多个MapReduce Job组成⼯作流（WorkFlow），这⾥是最需要根据业务进⾏定制的部分。图7是⼀个简单的MapReduce⼯作流的例⼦。MapReduce的输出⼀般是统计分析的结果，数据量相较于输⼊的海量数据会⼩很多，这样就可以导⼊传统的数据报表产品中进⾏展现。

13、Refer

1、数据仓库的源数据类型

2、⼤数据下的数据分析平台架构

3、数据的游戏：冰与⽕

4、Teradata 数据仓库技术架构及⽅案5、淘宝数据仓库架构实践6、BI数据仓库数据分层 7、数据仓库逻辑架构设计（⼀）8、数据仓库模型的概述9、数据仓库

10、百亿级实时⼤数据分析项⽬，为什么不⽤Hadoop？11、Java BI新⽣代——百度商业运营实践12、阿⾥巴巴数据产品经理⼯作总结篇

13、⼤数据环境下互联⽹⾏业数据仓库/数据平台的架构之漫谈14、【⼲货经验分享】三种数据部门架构优与劣15、数据库schema设计与优化原⽂地址：