现代业务系统处理的数据越来越大，尤其大型金融机构、电商平台等，账户表，订单表都是庞大的。数据仓库要保留历史变更情况，需要每天加载当天的变更数据到仓库。相比整个全量数据来说，每天变化的数据还是属于少数的。比如千万账户级别的银行每天交易量一般也就是几十万条，也就意味着账户表中涉及变动的记录最多也就是几十万条。电商订单表可能数千万条，但每天新增以及之前订单变化的，可能不到一百万条。这种情况下，拉链方式做

面向大量数据的时候，想极大提高处理效率，最简单的办法就是增加处理的服务器。当然，从根本上来说，优化算法得到的提升可能是指数级的，通过横向扩展计算节点的提升只能是倍数级的，而且远达不到N个节点处理时间是1/N的效果。但目前的分布式计算框架都支持廉价的服务器和存储，因此很可以通过很低的成本获得极大的性能提升。

数据标准化是数据仓库建立过程中的另一个难点和重点。可以说如果企业没有建立自己的数据标准，基本上是无法建立统一的、整合的数据仓库模型的。数据标准有很多理论标准的，比如，国家标准有一个叫《数据元的规范与标准化》。这里叫数据元，不是我们前面讨论的元数据，虽然有点接近。简单的来说，这个标准就是描述了如何描述一个数据。比起对表和字段的描述更基础了一层。本人之前有一段时间专门为几个银行做了数据标准的事情。对此

曾经有几年逻辑数据模型很火热，大家都研究这个。道理上来说，逻辑数据模型并不仅仅是用在数据仓库。在OLTP系统中建立良好的数据模型更加重要。但只不过这东西从实践上被推广开来，很大程度是原NCR/Teradata适用于金融行业的数据模型在某大型国有银行项目实施后传播开来。确实是好东西，感觉一下子给我打开了天眼，原来系统设计还能这样做。

报表绝对是让人痛苦的东西。格式复杂、需求多变，没事就增加几个。虽然说起报表感觉很老土，但确实是需求量最大的一个东西。貌似做报表多的人，基本上都会做一个自己的工具，至少也会做一个引擎，按照自己的理解用一种结构化加动态的方式去定义所需要的报表，可以灵活的选择所需要的数据，设计展现样式生成报表。当年有幸开始给银行做报表，一不小心做了很多年，也算是总结出一套报表处理的机制。

数据仓库实践杂谈-（二）-整体数据分层对于数据仓库的整体框架，我们用一种称作“从端到端”的流程框架描述，即从数据源头到用户使用的全流程。上图是一种典型的基于数据整合、加工，并为客户提供数据服务的场景。简单来说，就是用户到平台来查询某些数据，而这些数据从多个源头聚集在一起，并且经过了整合加工。用户的查询一般来说有两种方式：查询明细。这种服务就是把来自数据源的数据直接提供给客户即可，基本不需...

不管在数据仓库还是大数据领域中，元数据都是最重要的一个东西。元数据被定义为：描述数据的数据，对数据及信息资源的描述性信息。

数据仓库的两个重要的概念是：-进入仓库的数据不可变；-记录数据的变化历史。如何理解呢？不可变，意味着进到仓库的数据就类似归档了。原则上，不能对仓库里面的数据进行修改；如果随意的对仓库里面的数据进行修改，这个“仓库”就和交易系统没区别了，无法起到正确反映业务过程的作用。此外，适合于数据仓库的存储服务，如早年Oracle和DB2都有针对数据仓库的Data Warehouse产品，以及Hadoop体系的

渐变维也叫缓慢渐变维度。这个概念提出来，其实也就直接意味着，我们分析的角度并不是一成不变，而是会变化的。前面谈增量/拉链的时候，更多讨论“事实”数据的变化。业务每天都在发生这个是必然的。但对应的分析维度也一定会变化。

从数据源卸载出来的数据，进入仓库之前的第一个步骤就需要进行数据校验。数据校验的前提是在元数据中建立一套合适的数据标准。而其中，最重要的是确定每个字段的取值范围。基于这个数据标准，同步建立一套程序用于检查将要进入仓库的数据的有效性。