常见的DWH的构架，简易的来说如下图一和图二和图三。一般的企业，从数据生命周期而言，只有5-7年，特别是明细数据，数据的粒度层次越低，生命周期越短，数据的粒度越高，生命越长。对于一个银行的流水账数据而言，你或许在10年之后还想查询一下这个记录的明细，但是这样的概率是非常的低的，我们的企业也不可能为了一个在10年之后只有万分之一操作概率，而把这10年的数据都保留在一个实时查询的数据库中，当然我这里说的只是当前应用的数据仓库，交易系统那又另当别论了。
图一没有明确的表示出如何处理历史数据，而只是简单的应用构架。
图一：
图二和图一的区别在于2和3的区别（仅从图形的表示方式而言），但是这样的意义其实是不一样的，虽然DWH（数据仓库DataWareHousing）和DWHHistory（数据仓库历史库），在数据本质上是没有区别的，但是我们可以预见的效率是不一样的，他们的存储有数量级上的明显差异
图二：
而图三只是将图一和二合并，但是我们可以看到的是构架上的完整性。
图三：
在论述之前，我们先明确一下几个重要的词汇
1：数据粒度：数据有汇总数据，也有明细数据，每天的数据就是明细数据，而每个月，每年的数据就是汇总数据。数据的粒度是伴随维度而存在的。维度层次越低，数据粒度越低。
2：数据的生命周期：数据是有生命的，它的使用频率就是他的生命，当前月份的数据一般都是生命值最高的，而离现在越久的数据，使用频率一般都是越低的。所以在规划DWH的构架时，我们可以按照业务上的使用价值，存储空间的大小，以及成本几个方面，将数据按照其粒度，可以定义成不同的生命周期。比如日，月，年这就是简单的时间维度，而日数据的生命周期可以定义为2年，月数据可以定义为5年，年数据可以定义为10年等等。如果现在是2008年1月1日，那么系统就可以将2005年及以前的数据都汇总从月数据和年数据，然后2006年1月1日以前的日数据全部放入到历史数据库中，然后将当前数据仓库中的相关数据删除掉，将2003年1月以前的月数据全部汇总为年数据，然后加载到历史库中，然后删除。年数据的处理办法亦如此。如下图的表示
再来谈谈历史数据的会遇到的问题
历史数据如何应用？对于历史数据的应用有两种办法，第一是单独为历史数据仓库建立一个web应用，第二是和当前库一起使用，只是在数据源的查询上做出区分。比如我们可以设置一个查询历史信息的接口和一个查询当前应用的接口。如果历史数据库和当前数据库都是同一服务器上，则可以使用视图的方式进行查询。
历史数据如何存放？历史数据可以存放在和当前数据库不同的服务器中，或者是同一服务器的不同数据库中。如果是同一服务器，则对数据管理成本相对而言要少，当时不够稳定，因为服务器的崩溃可以直接导致两数据库都不在线。而放在不同的服务器成本增加，但是对应用而言是很方便的。
历史数据的结构是怎么样的？历史数据表的结构，涉及到表名和列名，如果按照时间来区分的话，大数据量的企业，可以按照年份来存储历史数据，比如当前库的表名为T_name，那么历史库中2000年的数据，可以为T_name_2000，当然这些必须是有时间戳的，一般没有时间戳的数据量很大的表是很少见的，如果遇到这样的情况，可以放在同一张表中。至于列名，可以和当前库一致，也可以和当前库不一致，如果不一样，一定要建立一个相关的视图来映射源表。
如何简单有效的进行加载？建议采用一张日志表。每一次对于DWH和DWHHistory的数据互动，都做出详细的表述。具体有一下几类记录
l 加载批处理号（BatchID）
l 操作时间
l 源数据库名
l 目标数据库名
l 源数据表
l 目标数据表
l 需迁移数据的起始时间（比如需要从2000-1-1到2000-12-31的数据转移到DWHHistory，那么这里的时间就是2000-1-1）
l 需迁移数据的终止时间（同上，2000-12-31）
l 加载起始时间（从什么时候开始执行ETL加载的）
l 加载结束时间（从什么时候完成执行ETL加载的）
l 加载数据量（本次批操作，有多少数据量）
l 汇总维度粒度
l 操作标志（删除，插入还是更新）
l 完成标识
l 加载描述
l 错误信息
l 重新加载次数
数据集市中的数据如何展现？如果数据集市中既有2年前的月数据和年数据，也有2年内的明细日数据，这样对于同一度量是存在不同粒度的数据，简单的说，这是不能在同一个cube中展现的，因为cube是自动汇总的，除非将维度按照量度变量来处理。所以最好能将明细数据展现和汇总的月度数据、年度数据展现区分开。
怎么样处理在数据集市中需要分析历史明细数据的需求？对这样的应用，我们可以将历史数据插入到数据集市中，因为数据集市的数据是不需要逆转的，也就是不像DWH需要回写到DWHHistory中。