这是一篇流水账总结，在维度设计上有困惑的可以看看，完全不了解的也请忽略。
维度的设计过程就是确定维度属性的过程，维度属性的优劣，决定了维度使用的方便性，成为数据仓库易用性的关键。正如Kimball所说的，数据仓库的能力直接与维度属性的质量和深度成正比。
维度的基本概念
在维度建模中，将度量称为“事实”，将环境描述称为“维度”，维度是用于分析事实所需要的多样环境。
维度包含的维度列，称为维度属性，维度属性是查询约束条件、分组和报表标签的基本来源，是数据易用性的关键。
维度的作用一般是查询约束、分类汇总以及排序。
维度和维度属性的来源
现有报表中获取
和业务人员访谈
业务系统设计文档
维度使用主键标识，确保与之相连的任何事实表的引用完整性
使用代理主键或者自然主键
数据规模较小，使用代理主键
数据规模大，生成和维护代理主键开销大，用自然主键代替，例如商品ID作为维表主键
维度设计的目标
尽可能生成丰富的维度属性，为下游的数据统计、分析、探查提供良好的基础
尽可能多底给出包括一些富有意义的文字性描述
区分数值型属性和事实
尽量沉淀出通用的维度属性，构建企业范围内一致性维度来构建总线架构
易用性： 模型可理解性高、访问复杂度低。用户能够方便地从模型中找到对应的数据表，并能够方便的查询和分析
维度的基本设计方法
第一步：选择维度和新建维度，保证维度唯一
第二步：确定主维表，例如商品是主维度
第三步：确定相关维表，和商品相关的类目、品牌、卖家、店铺是相关联维度
第四步：确定维度属性
维度的层次结构
层次结构是指属性以层次方式或者一对多的方式相互关联，商品属于类目、类目属于行业是一对多的关联，类目分3-5层是典型的多级层次结构
典型的层次结构：地址、时间、商品类目
层次结构用户数据钻取
层次扁平化
降低递归层次，每个类目保存一条记录，并将其所属的各类目层次属性化
低级类目没有值时用上一级代替，将类目向下虚拟，这样根据某一级查询数据时不会因为缺少值而漏数据
维度整合与拆分
整合
为什么整合
不同应用在编码、命名习惯、度量单位存在很大差异
应用处于性能和扩展性考虑，或者架构演变，采用不同的物理实现，关系型或者NoSQL数据库或者分表
整合内容
命名规范的统一，表名、字段名统一
字段类型统一，相同和相似字段类型一致
公共代码及代码值的统一
业务含义相同的表统一
表整合方式
垂直整合
垂直整合是扩充字段
不同来源的数据集相同，只是存储的信息不同用垂直整合，例如：会员基础信息表和会员扩展信息表
水平整合
不同的来源包含了不同的数据集，不同业务线的会员表整合
需要确定是否有交叉、自然键是否冲突
水平拆分
维度可以按照类别和类型进行细分，复杂业务场景会用到，例如阿里的飞猪的商品维和天猫的商品维
为什么拆分
除了基础属性外，属性差异很大
拆分依据
依据不同类型维度的属性差异情况，差异大拆分成两个维度
依据业务相关程度。两个业务相关性较低的业务，耦合在一起弊大于利。例如淘系商品和1688商品构建两个维度，分别在两个数据集市，业务各自发展，一般不会交叉分析
垂直拆分
为什么拆分
维度属性来源表产出时间早晚不一，复杂属性计算好是长
某些维度属性热度稿、使用频繁，而某些维度热度低、使用少
有些稳定有些经常变化
设计主从维度
主维表存放稳定、产出时间早、热度高的属性
从维表存放变化较快、产出时间晚、热度低的属性
维度变化
缓慢变化维
目的：反映维度的历史变化
处理方式
一： 重写维度值，适合不需要历史数据、始终取最新数据情况
二：插入新的维度行，维度变化前的事实和旧的维度值关联，维度变化后的事实和当前的维度值关联； 不能讲变化前后的记录事实归一为变化前的维度或者变化后的维度
三：插入维度列，例如：维表有两个类目字段 所属新类目、所属旧类目
快照维表
采用周期快照方式保存缓慢变化维，例如： 每天保留一份全量商品快照数据，任一天的事实快照都可以关联当天
优点： 简单有效、开发维护成本低； 使用方便、理解性好
缺点： 存储极大浪费
历史拉链存储
优化存储空间
在缓慢变化维第二种方式基础上增加两个时间戳，通过时间戳取特定日期的历史维度
分月做历史拉链，减少分区数量
不把变化频繁的维度加入，避免维度过快增长，例如会员积分，积分可以放入从维表
特殊维度
行为维表
和用户行为所产生的事实相关的维度，或者是从事实衍生的维度，称为行为维度，特点是量大、变化快； 例如买家从年初截至当前的淘宝交易金额、信用分等级等
行为维度分类
另一个维度的过去行为，如买家最近一次访问淘宝的时间、买家最近一次发生淘宝交易的时间
快照事实行为维度，一段时间的事实累计值，如买家从年初截至当前的淘宝交易金额、买家信用分值
分组事实行为维度，将数值型事实转换为枚举值。如买家信用分值按分数划分的等级（等级难道没有在业务系统中加工好么？）
复杂逻辑事实行为维度，通过复杂算法加工或者事实综合加工得到，有点像标签计算。例如： 商品热度根据访问、收藏、加入购物车、交易情况计算得到。
处理方式
冗余至现有维表
加工成单独维表
选择处理方式的原则
避免维度行过快增长，比如对商品表进行了极限存储，如果将商品热度加入现有的商品维表，则可能会使每日商品变更占比过高，导致极限存储效果较差
避免耦合度过高，如卖家主营类目，加工逻辑异常复杂，如果融合进现有的卖家维表中，那么过多的业务耦合导致卖家维表刷新逻辑复杂、维护性差、产出延迟
多值维表
事实表中的一条记录在某维表中有多条记录与之对应，比如一个订单中有多个商品
三种处理方式
降低事实表的粒度，把父订单拆成子订单，每个订单只包含一种商品
采用多字段
采用桥接表
多值属性
维表中的某个属性字段同时存在多个值，例如商品SKU、商品标签
处理方式
保持维度主键不变，多值属性放在维度的一个属性字段中
主键不变，多值属性放在多个属性字段中，扩展性比较差
维度主键发生变化，一个维度值存放多条记录。比如商品SKU维表，每个商品有多少SKU就有多少记录，主键是商品的ID和SKU的ID
杂项维度
一些维度单独建表不值当，加入事实表又占用空间，则可以统一放入杂项里
维度设计平衡的技术因素
反规范化
反规范化把维度的属性层次合并到单个维度中的操作，避免大量关联操作，方便分析且性能好
实际应用中，使用维表的空间来换取简明性和查询性能
存储与计算
以存储换计算时间，但存储空间也不是无限
退化维度
常用维度属性退化至事实表中，方便使用，但不是所有商品维度都退化，例如商品维只退化商品标题、商品类型、商品属性，类目维退化一级类目和二级类目
扩展性
当原系统、业务逻辑变化时，能通过较少的成本快速扩展模型，保持核心模型的稳定性
效能
在性能和成本方面取得平衡
历史文章
数据产品
数据可视化
数据可视化系列 | 占比类图表饼图、环图、复合饼图、条形图、百分比堆积面积图
数据可视化系列 | 比较关系的漏斗图、雷达图、花瓣图、堆积面积图
用户画像
其它
Hadoop、Spark、Hive、HBase都是干什么的，看完此文让你从此不再迷惑
作者：百川，微信公众号：修炼大数据（studybigdata）
