文章发表人是: 2simple

完善的文档制度，需要在仓库中的各个部分介入，具体的有哪些文档，前面也提到一些，如：
需求模板、临时统计流程文档（数据流、引用的口径）、IT工单设计文档等。

其中，需求模板除了要详细描述本次需求的内容，同时还需要描述清楚需求的类型、计划完成时间、它的紧迫性。在该次需求中涉及到的维度和相关的口径（这次口径的内容、是否存在相似口径）。是否存在相似需求对需求实现人员来说，也是很重要的参考。
而在流程文档中，需要描述清楚数据的流向，在每一步中实现的口径。方便后续建立统一统计库，形成知识共享。

关于设计的随意性，是由许多因素导致的。数据仓库的数据，是有层次之分的。这种数据分层，可以在逻辑上和物理上进行。逻辑上的层可以对应同一个物理层。物理层可以在同一个数据库上，也可以在多个数据库上。如果某层对部分数据没有太多必要，可以考虑降低该层数据的保存周期，可以腾出空间来支持上层数据的存储空间，但是不支持直接跳过该层。

建模师在开始建模前，通常会制定一组原则或规则。这些规则包括：
1、命名规范
ER图命名
程序命名
DFD（数据流图）命名

2、设计细节说明数据保留期限数据类型说明
（整型—4字节，长整型—8字节，自定义数据类型）

3、程序设计编写细则。。。

这些规范在后续的建模过程，用来指导建模师构建统一模型，是建模师沟通的语言！

在优化仓库时，我们容易掉入一个陷阱，以为把仓库中的现有问题解决了，就达到目的，实际上，这只完成了仓库调优的一部分，尽管这一部分很重要，
更重要的是，需要找出为什么会出现这些问题，从根源上来解决这些问题。而这些问题往往被我们所忽略

1、没有完善的文档管理制度
任何改动，都必须有文档记录。文档的缺失，久而久之，就没有人记得了。就成了系统的黑洞了。

2、设计的随意性太大
数据仓库是一个整体，每个小的设计，都必须从全局的角度来考虑。缺乏全局的考虑，导致各自的设计很独立，最终的仓库变成了一个割裂的东西。

怎么来完善这些东西呢？
1、文档的模板化：需求模板、临时统计流程文档（数据流、引用的口径）、IT工单设计文档
2、设计从全局考虑，这考验设计人员的水平

待续...

数据获取路径不方便：
这一点目前看来是最严重的，把问题分解下，我们分别从横向和纵向来看待这个问题。

横向：这一点比较直观，也是最容易引发抱怨的地方。获取某些数据，经常需要组合N多的数据表，既耗性能，又耗时间。
纵向：这个问题表现在各个应用的数据来源层次不一致。有些应用的数据来源于ods层，有些来源于dw层，也有些来源于应用层。数据来源层次的无端扩展，导致统计口径的不一致，引起了数据结果的混乱。更重要的是造成了仓库的维护困难！牵一发而动全身啊！

需要做的事情：
1、数据表本身的设计需要多有考量，一张表在兼顾性能的同时尽量做到信息的充足
2、引入宽表的设计，减少不必要的跨表关联
3、统一数据来源层次
4、需要一个设计较好的基础数据层

此外，在做仓库优化时，还得考虑客户对它的期望。忽略了这点，所有的工作都是难得到认可。那么客户对它的期望有哪些呢？
1、方便维护（留有完备的文档）
2、减少存储（现有仓库对存储的消耗太大，直接影响成本）
3、提升性能（对一些耗时的应用优化，但是需要有可以量化的指标）

仓库优化从大的来讲，优化分为两个部分
1、仓库模型的优化
2、仓库应用的优化

仓库模型的优化，是从面上来考虑，考虑的是如何更好的支撑业务的开展
仓库应用的优化，是从点上来考虑，考虑更多的是性能上的问题。

平常我们对仓库模型的优化讲的比较多，好像仓库的问题集中在模型上较多点。主要体现在模型对现有需求的支撑不够。
1、数据量不够
2、数据的获取路径不方便
3、数据的统计口径不统一

数据量不够：主要是指现有仓库在支撑新需求时，发生需要的数据不存在，需要重新从boss侧抽取原始数据。

考虑到仓库的建设是个渐进的过程，随着业务环境的变化，数据源本身也在变化，因而发生数据量不够的现象是可以理解的，关键在于将新的数据加入到仓库中时，如何才能减少对现有数据的冲击，如果跟现有数据融合在一起？

需要做的事情：
1、已有数据模型的设计需要更多的考虑可扩展性、可重用性
2、数据模型的设计需要有相应的规范，保证新数据的加入符合已有的规范
3、测试的引入，只有通过引入相应的测试流程，才能最终保证新数据的一致

待续。。。