企业级数据仓库构建

数据仓库架构

首先对数据仓库的架构简单介绍：

facebook的ppt上了解到的是他们在hive上做大数据量的分析，计算结果放到oracle上做BI展示和计算hadoop MR or hive上ETL计算完的结果表，同步到oracle中，连接传统BI工具，呈现报表，阿里、腾讯、盛大都是这样的。

※即席查询：（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。

浅析即席查询：

在数据仓库领域有一个概念叫Ad hoc queries，中文一般翻译为“即席查询”。即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。即席查询与通常查询从SQL语句上来说，并没有本质的差别。它们之间的差别在于，通常的查询在系统设计和实施时是已知的，所有我们可以在系统实施时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时生产的，系统无法预先优化这些查询，所以即席查询也是评估数据仓库的一个重要指标。即席查询的位置通常是在关系型的数据仓库中，即在EDW或者ROLAP中。多维数据库有自己的存储方式，对即席查询和通常查询没有区别。在一个数据仓库系统中，即席查询使用的越多，对数据仓库的要求就越高，对数据模型的对称性的要求也越高。对称性的数据模型对所有的查询都是相同的，这也是维度建模的一个优点。

简陋版数据仓库架构图：

1、数据采集

数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些ETL操作。数据源种类可以有多种：

①日志：所占份额最大，存储在备份服务器上
②业务数据库：如Mysql、Oracle
③来自HTTP/FTP的数据：合作伙伴提供的接口
④其他数据源：如Excel等需要手工录入的数据

2、数据存储与分析

HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。离线数据分析与计算，也就是对实时性要求不高的部分，Hive是不错的选择。使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算。Spark性能比MapReduce好很多，同时使用SparkSQL操作Hive。

3、数据共享

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据。这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库。

4、数据应用

报表：报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层。

接口：接口的数据都是直接查询数据共享层即可得到。

即席查询：即席查询通常是现有的报表和数据共享层的数据并不能满足需求，需要从数据存储层直接查询。一般都是通过直接操作SQL得到。

主流数据仓库架构图：

主流数据仓库架构与简陋版对比，增加了以下功能：

数据采集：采用Flume收集日志，采用Sqoop将RDBMS以及NoSQL中的数据同步到HDFS上。

消息系统：可以加入Kafka防止数据丢失。

实时计算：实时计算使用Spark Streaming消费Kafka中收集的日志数据，实时计算结果大多保存在Redis中。

机器学习：使用了Spark MLlib提供的机器学习算法。

多维分析OLAP：使用Kylin作为OLAP引擎。

数据可视化：提供可视化前端页面，方便运营等非开发人员直接查询。

ETL构建企业级数据仓库

一、什么是ETL？

在数据仓库构建中，ETL贯穿于项目始终，它是整个数据仓库的生命线，包括了从数据清洗，整合，到转换，加载等的各个过程，如果说数据仓库是一座大厦，那么ETL就是大厦的根基，ETL抽取整合数据的好坏直接影响到最终的结果展现。所以ETL在整个数据仓库项目中起着十分关键的作用，必须摆到十分重要的位置。ETL是数据抽取（Extract）、转换（Transform）、加载（Load ）的简写：它是将OLTP系统中的数据经过抽取，并将不同数据源的数据进行转换、整合，得出一致性的数据，然后加载到数据仓库中。简而言之ETL是完成从OLTP系统到OLAP系统的过程。

二、数据仓库的架构
数据仓库（Data Warehouse\DW）是基于OLTP(联机事务处理过程)系统的数据源，为了便于多维分析和多角度展现将其数据按特定的模式进行存储而建立的关系型数据库。它不同于多维数据库，数据库中的数据是细节的，集成的，数据仓库是面向主题的，是以OLAP(联机分析处理)系统为分析目的。它包括星型架构与雪花型架构，其中星型架构中间为事实表，四周为维度表，类似星星；雪花型架构中间为事实表，两边的维度表可以再有其关联子表，而在星型中只允许一张表作为维度表与事实表关联，雪花型一维度可以有多张表，而星型不可以。考虑到效率时，星型聚合快，效率高，不过雪花型结构明确，便于与OLTP系统交互。

星型：

雪花型

在实际项目中，我们将综合运用星型架构与雪花型架构。

三、ETL构建企业级数据仓库五步法的流程

1、确定主题，即确定数据分析或前端展现的某一方面的分析主题，例如我们分析某年某月某一地区的啤酒销售情况，就是一个主题。主题要体现某一方面的各分析角度（维度）和统计数值型数据（量度），确定主题时要综合考虑，一个主题在数据仓库中即为一个数据集市，数据集市体现了某一方面的信息，多个数据集市构成了数据仓库。    
2、确定量度在确定了主题以后，我们将考虑要分析的技术指标，诸如年销售额此类，一般为数值型数据，或者将该数据汇总，或者将该数据取次数，独立次数或取最大最小值等，这样的数据称之为量度。量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性能指标（KPI）等的计算。    
3、确定事实数据粒度在确定了量度之后我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况，考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置到最小，例如我们将按照时间对销售额进行汇总，目前的数据最小记录到天，即数据库中记录了每天的交易额，那么我们不能在ETL时将数据进行按月或年汇总，需要保持到天，以便于后续对天进行分析。而且我们不必担心数据量和数据没有提前汇总带来的问题，因为在后续的建立CUBE时已经将数据提前汇总了。    
4、确定维度    
维度是要分析的各个角度，例如我们希望按照时间，或者按照地区，或者按照产品进行分析，那么这里的时间、地区、产品就是相应的维度，基于不同的维度我们可以看到各量度的汇总情况，我们可以基于所有的维度进行交叉分析。这里我们首先要确定维度的层次（Hierarchy）和级别（Level）维度的层次是指该维度的所有级别，包括各级别的属性；维度的级别是指该维度下的成员，例如当建立地区维度时我们将地区维度作为一个级别，层次为省、市、县 三层，考虑到维度表要包含尽量多的信息，所以建立维度时要符合“矮胖原则”，即维度表要尽量宽，尽量包含所有的描述性信息，而不是统计性的数据信息。还有一种常见的情况，就是父子型维度，该维度一般用于非叶子节点含有成员等情况，例如公司员工的维度，在统计员工的工资时，部门主管的工资不能等于下属成员工资的简单相加，必须对该主管的工资 单独统计，然后该主管部门的工资等于下属员工工资加部门主管的工资，那么在建立员工维度时，我们需要将员工维度建立成父子型维度，这样在统计时，主管的工资会自动加上，避免了都是叶子节点才有数据的情况。 另外，在建立维度表时要充分使用代理键，代理键是数值型的ID号码，好处是代理键唯一标识了每一维度成员信息，便于区分，更重要的是在聚合时由于数值型匹配，JOIN效率高，便于聚合，而且代理键对缓慢变化维度有更重要的意义，它起到了标识历史数据与新数据的作用，在原数据主键相同的情况下，代理键起到了对新数据与历史数据非常重要的标识作用。有时我们也会遇到维度缓慢变化的情况，比如增加了新的产品，或者产品的ID号码修改了，或者产品增加了一个新的属性，此时某一维度的成员会随着新的数据的加入而增加新的维度成员，这样我们要考虑到缓慢变化维度的处理，对于缓慢变化维度，有三种情况：    
①缓慢变化维度第一种类型：历史数据需要修改。这样新来的数据要改写历史数据，这时我们要使用UPDATE，例如产品的ID号码为123，后来发现ID号码错误了，需要改写成456，那么在修改好的新数据插入时，维度表中原来的ID号码会相应改为456，这样在维度加载时要使用第一种类型，做法是完全更改。    
②缓慢变化维度第二种类型：历史数据保留，新增数据也要保留。这时要将原数据更新，将新数据插入，需要使用UPDATE/INSERT，比如某一员工2005年在A部门，2006年时他调到了B部门。那么在统计2005年的数据时就应该将该员工定位到A部门；而在统计2006年数据时就应该定位到B部门，然后再有新的数据插入时，将按照新部门（B部门）进行处理，这样我们的做法是将该维度成员列表加入标识列，将历史的数据标识为“过期”，将目前的数据标识为“当前的”。另一种方法是将该维度打上时间戳，即将历史数据生效的时间段作为它的一个属性，在与原始表匹配生成事实表时将按照时间段进行关联，这样的好处是该维度成员生效时间明确。    
③缓慢变化维度第三种类型：新增数据维度成员改变了属性。例如某一维度成员新加入了一列，该列在历史数据中不能基于它浏览，而在目前数据和将来数据中可以按照它浏览，那么此时我们需要改变维度表属性，即加入新的列，那么我们将使用存储过程或程序生成新的维度属性，在后续的数据中将基于新的属性进行查看。    
5、创建事实表在确定好事实数据和维度后，我们将考虑加载事实表。    
在公司的大量数据堆积如山时，我们想看看里面究竟是什么，结果发现里面是一笔笔生产记录，一笔笔交易记录… 那么这些记录是我们将要建立的事实表的原始数据，即关于某一主题的事实记录表。我们的做法是将原始表与维度表进行关联，生成事实表注意在关联时有为空的数据时（数据源脏），需要使用外连接，连接后我们将各维度的代理键取出放于事实表中，事实表除了各维度代理键外，还有各量度数据，这将来自原始表，事实表中将存在维度代理键和各量度，而不应该存在描述性信息，即符合“瘦高原则”，即要求事实表数据条数尽量多（粒度最小），而描述性信息尽量少。如果考虑到扩展，可以将事实表加一唯一标识列，以为了以后扩展将该事实作为雪花型维度，不过不需要时一般建议不用这样做。事实数据表是数据仓库的核心，需要精心维护，在JOIN后将得到事实数据表，一般记录条数都比较大，我们需要为其设置复合主键和索引，以为了数据的完整性和基于数据仓库的查询性能优化，事实数据表与维度表一起放于数据仓库中，如果前端需要连接数据仓库进行查询，我们还需要建立一些相关的中间汇总表或物化视图，以方便查询。

四、ETL中高级技巧的运用

1、准备区的运用：
在构建数据仓库时，如果数据源位于一服务器上，数据仓库在另一服务器端，考虑到数据源Server端访问频繁，并且数据量大，需要不断更新，所以可以建立准备区数据库。先将数据抽取到准备区中，然后基于准备区中的数据进行处理，这样处理的好处是防止了在原OLTP系统中中频繁访问，进行数据运算或排序等操作。例如我们可以按照天将数据抽取到准备区中，基于数据准备区，我们将进行数据的转换，整合，将不同数据源的数据进行一致性处理。数据准备区中将存在原始抽取表，一些转换中间表和临时表以及ETL日志表等。    
2、时间戳的运用：
时间维度对于某一事实主题来说十分重要，因为不同的时间有不同的统计数据信息，那么按照时间记录的信息将发挥很重要的作用。在ETL中，时间戳有其特殊的作用，在上面提到的缓慢变化维度中，我们可以使用时间戳标识维度成员；在记录数据库和数据仓库的操作时，我们也将使用时间戳标识信息，例如在进行数据抽取时，我们将按照时间戳对OLTP系统中的数据进行抽取，比如在午夜0：00取前一天的数据，我们将按照OLTP系统中的时间戳取GETDATE到GETDATE减一天，这样得到前一天数据。    
3、日志表的运用：
在对数据进行处理时，难免会发生数据处理错误，产生出错信息，那么我们如何获得出错信息并及时修正呢? 方法是我们使用一张或多张Log日志表，将出错信息记录下来，在日志表中我们将记录每次抽取的条数，处理成功的条数，处理失败的条数，处理失败的数据，处理时间等等，这样当数据发生错误时，我们很容易发现问题所在，然后对出错的数据进行修正或重新处理。    
4、使用调度：
在对数据仓库进行增量更新时必须使用调度。即对事实数据表进行增量更新处理，在使用调度前要考虑到事实数据量，需要多长时间更新一次，比如希望按天进行查看，那么我们最好按天进行抽取，如果数据量不大，可以按照月或半年对数据进行更新，如果有缓慢变化维度情况，调度时需要考虑到维度表更新情况，在更新事实数据表之前要先更新维度表。调度是数据仓库的关键环节，要考虑缜密，在ETL的流程搭建好后，要定期对其运行，所以调度是执行ETL流程的关键步骤，每一次调度除了写入Log日志表的数据处理信息外，还要使用发送Email或报警信息等，这样也方便的技术人员对ETL流程的把握，增强了安全性和数据处理的准确性。

五、总结

ETL构建数据仓库需要简单的五步，掌握了这五步的方法我们将构建一个强大的数据仓库，不过每一步都有很深的需要研究与挖掘，尤其在实际项目中，我们要综合考虑，例如如果数据源的脏数据很多，在搭建数据仓库之前我们首先要进行数据清洗，以剔除掉不需要的信息和脏数据。总之，ETL是数据仓库的核心，掌握了ETL构建数据仓库的五步法，就掌握了搭建数据仓库的根本方法。不过，我们不能教条，基于不同的项目，我们还将要进行具体分析，如父子型维度和缓慢变化维度的运用等。在数据仓库构建中，ETL关系到整个项目的数据质量，所以马虎不得，必须将其摆到重要位置，将ETL这一大厦根基筑牢！