数据仓库

系统角度上，影响建设数据仓库的解决方案的因素

    1.操作出现的频率，即业务部门每隔多长时间做一次查询分析。

    2.在系统中需要保存多久的数据，是一年、两年还是五年、十年。

    3.用户查询数据的主要方式，如在时间维度上是按照自然年，还是财政年。

    4.用户所能接受的响应时间是多长、是几秒钟，还是几小时。

数据采集

    通过ETL工具采集数据源数据

数据存储与分析

    HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。离线数据分析与计算，也就是对实时性要求不高的部分，Hive是不错的选择。

数据共享

    这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库。

数据应用

    报表、接口、即席查询

流程图：

流程图 Hive的历史由来

    Hive适用于海量结构化数据的离线分析，如果有需求是需要统计计算大数据量而且对于时效性没有过高要求的情况下，建议采用Hive来做处理。不适用于复杂的机器学习算法，因为机器学习算法大多涉及大量的迭代计算，而hive默认情况下底层封装的计算框架是MapReduce，计算效率比较低下不适合复杂的计算，（Hive on Spark另议），因为底层的计算框架是MapReduce， 所以也不适合交互式实时查询，有交互式实时查询建议使用Impala。

某公司数据仓库架构图

数据仓库设计步骤

1、确定主题

    主题与业务密切相关，所以设计数仓之前应当充分了解业务有哪些方面的需求，据此确定主题

2、确定量度

    在确定了主题以后，我们将考虑要分析的技术指标，诸如年销售额之类。量度是要统计的指标，必须事先选择恰当，基于不同的量度将直接产生不同的决策结果。

3、确定数据粒度

    考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置到最小。例如如果知道某些数据细分到天就好了，那么设置其粒度到天；但是如果不确定的话，就将粒度设置为最小，即毫秒级别的。

4、确定维度

    设计各个维度的主键、层次、层级，尽量减少冗余。

5、创建事实表

    事实表中将存在维度代理键和各量度，而不应该存在描述性信息，即符合“瘦高原则”，即要求事实表数据条数尽量多(粒度最小)，而描述性信息尽量少。

星形/雪花形/事实星座，这三者就是数据仓库多维数据模型建模的模式

下图所示就是一个标准的星形模型，事实表和维表通过ID相关联：

星型模型

技术点：

1、ETL工具的使用

2、Hadoop、Hive

3、数据的导入与导出

4、数据展现(即席查询)工具

5、什么时候进行数据采集？什么时候进行数据统计与计算？什么方式触发？crontab？

Ending

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