漫谈纬度表如何设计（二）
一：纬度设计时遇到的复杂背景
数据仓库的重要数据来源是大量的、分散的面向应用的操作型环境。不同的应用在设计过程中，可以自由决策，主要满足本应用的需求， 很少会考虑和其他系统进行数据集成。应用之间的差异具体表现在如下几个方面：
•应用在编码、命名习惯、度量单位等方面会存在很大的差异。比如不同应用对于用户的性别编码不同，有o和1、F和M等；不同应用的用户ID含义相同，但字段名称不同，有user、user_id 等，不同应用对于金额的度量单位不同，有元、分等。
•应用出于性能和扩展性的考虑，或者随技术架构的演变，以及业务的发展，采用不同的物理实现。拆分至不同类型数据库中，部分数据釆用关系型数据库存储（如Oracle、MySQL等），部分数据采用NoSQL数据库存储（如HBase、Tair等）。拆分成同一类型数据库中的多个物理表，比如对于淘宝商品，有商品主表和商品扩展表，商品主表存储商品基本信息，商品扩展表存储商品特殊信息，如不同产品线的定制化信息等；对于淘宝会员，有会员主表和会员扩展表，会员主表存储用户基本信息，会员扩展表存储用户扩展信息，如用户的各种标签信息等。
-- 引用《大数据之路》
二：纬度表如何进行整合
面对如何复杂的业务，复杂的数据来源，如何设计出统一，规范，高效，质量的纬度表是一个难点，一般需要遵循以下规范：
- 命名规范统一
表名和字段名的命名应该要统一，一般情况下表的命名需要看到是什么纬度表，是主表还是从表，字段的命名应该要见名知意，描述相同业务含义的字段在不同表，不允许命名不同。 - 字段类型要统一
实践发现，如果字段类型不统一，后续对数据进行加工，导入导出就会产生不必要的麻烦，更加致命的可能会造成精度丢失。 - 公共代码及代码值统一
公共代码及标志性字段的数据类型、 命名方式等统一。 - 业务含义相似的表统一
如果两个纬度表描述的业务场景比较类似，但是也有差异的部分，这种情况下，一般有如下处理方式：
1.主从表设计
将共有的公共核心属性进行下沉，抽象出主纬度表，每个纬度表差异的部分抽象成从纬度表。这样做的好处是，保证了主表的稳定，不会因从表的变更影响到主表，并且更加有利于扩展，遵循了类似于软件设计的思想，高内聚，低耦合。但是缺点是使用起来会有不便，可能会多join一张表。
2.直接合并
另外一种就是直接合并，这个方式的好处是将多个描述相似业务场景的纬度表进行垂直整合，使得这张表的纬度属性很丰富，符合我们纬度表设计的原则，并且查询起来也很方便。但是也会出现一个问题，就是这张表会存在很有空值，表很稀疏。
3.不合并
如果两张纬度表描述的业务场景差异较大，那么可以选择不合并，分开维护也是可以的，这样可以凸显出每张纬度表的核心注意，不易混淆。 - 表级别的整合问题
在上述业务含义相似的表统一里面也提到表的整合，这里来详细讨论一下表级别的整合问题。
1.垂直整合
如果不同的来源表有相似的业务含义，只是存储的数据集不一样，比如会员基础信息表，会员扩展信息表，其实都是存的会员信息，只是字段表述不一样，那么这样的话就可以垂直整合到一张会员表里面去，这样就可以使纬度属性尽可能的丰富起来。
2.水平整合
如果不同的来源表，表结构都类似，而且描述的也是相似业务场景下的环境，那么可以进行水平整合，比如说淘宝会员，1688会员等。由于是水平整合，需要考虑到唯一主键的问题。如果整合完以后不同子集各自的主键不冲突，那么可以不用做处理，如果存在冲突就需要设置超自然键，保证唯一性。
有合并就会有拆分，思路是一样的，只不过拆分是逆思维，这里就不做详述了。不管是整合还是拆分一般要遵循一下几点：
扩展性：当源系统、业务逻辑变化时，能通过较少的成本快速扩展模型，保持核心模型的相对稳定性。软件工程中的高内聚、低耦合的思想是重要的指导方针之一。
效能：在性能和成本方面取得平衡。通过牺牲一定的存储成本， 达到性能和逻辑的优化。
易用性：模型可理解性高、访问复杂度低。用户能够方便地从模型中找到对应的数据表，并能够方便地查询和分析。
三：历史归档问题
随着业务的发展和时间的推移，纬度表当中的纬度属性也会发生变化（针对这种变化的具体处理非本文重点），假设纬度表处理部分纬度属性变化是采用增量插入的方式，那么数据量就会增长的很快，并且不是最新的数据是没有实际业务意义的，针对这种情况，我们为了有效数据的查询时效，应该要做好历史归档的问题。
一般目前归档数据的方式有如下几种：
1.根据业务系统那边的归档策略来，比如说业务系统那边以怎样的策略让这个商品处于失效状态，那么在数据仓库也是采用同样的策略，但是业务系统那边发生更新，数据仓库也会跟着变化。
2.对接binlog，解析数据，如果有解析到类似于delete，同业务系统那边失效的标志字段，那么就做归档操作。
3:数据仓库这边自定义归档策略，根据业务特点，自定义一套归档策略，单独维护。
