维度表技术常见：增加列，维度子集，角色扮演维度，层次维度，退化维度，杂项维度，维度合并，分段维度等基本维度表技术。
一．增加列
事实表和维度表上增加列。
Hive上增加列，慎用alter table。原因老版本的hive对ORC格式表的模式修改，尤其是增加列的支持存在很多问题。
JIRA上说2.0.0修复了ORC表模式修改问题。
空值处理：<=>
二．维度子集
有些需求不需要最细节的数据。此时事实数据需要关联特定的维度，这些特定维度包含在从细节维度选择的行中，所以叫维度子集。
细节维度和维度子集具有相同的属性或内容，具有一致性。
1.建立包含属性子集的子维度
比如需要上钻到子维度。
2.建立包含行子集的子维度
当两个维度处于同一细节粒度，但是其中一个仅仅是行的子集，会产生另外一种一致性维度构造子集。
某些版本的Hive中，对ORC表使用overwrite会出错，为保持兼用性，使用truncate 。
3.使用视图实现维度子集
实现维度子集，这种方式两个主要问题：一需要额外的存储空间，因为新创建的子维度是物理表；二是存在数据不一致的潜在风险。
为解决上述问题，常用做法是在基本维度上建立视图生成子维度。
优点：实现简单，不需要修改原来脚本的逻辑；不占用存储空间，因为视图不真正存储数据；消除数据不一致的可能。
缺点：当基本维度和子维度表数据量相差悬殊，性能比物理表差很多；如果定义视图查询，并且视图很多，可能对元数据存储系统造成压力，严重影响查询性能。
三．角色扮演维度
单个物理维度可以被事实表多次引用，每次引用连接逻辑上存在差异的角色维度。例如，事实表可以有多个日期，每个日期通过外键引用不同的日期维度，原则上每个外键表示不同维度视图，这样引用具有不同的含义。这些不同的维度视图具有唯一的代理键列名，被称为角色，相关维度被称为角色扮演维度。
Hive中的order by，sort by ,distribute by,cluster by子句都用于对查询结果进行排序，处理方式不一样。
Hive中order by跟传统的SQL语言的order by作用一样的，会对查询的结果做一次全局排序，如果使用order by ，所有数据都会发送到同一个reduce进行处理。不管多少map,也不管文件有多少block只会起动一个reduce,因为多个reducer无法保证全局有序。对于大量数据这将会消耗很长时间去执行。
Sort by 在每个reducer端都会排序，也就保证了局部有序。
Ditribute by 控制map输出reducer中是如何规划。
假设有一张名为store 的商店表，mid是这个商店所属的商户，money是这个商户的盈利，name商店名称
语句：select mid,money.name from store distribute by mid sort by mid asc,money asc;
所有mid相同数据都会被送到同一个reducer处理，这是因为指定了distribute by mid,这样话就可以统计每个商户中各个商店盈利排序。肯定全局有序。因为相同的商户会放到同一个reducer去处理。
Cluster by 是distribute by和sort by相结合，但是排序只能是升序（至少hive 1.1.0是这样）
四．层次维度
经常使用grouping__id 二进制序列，rollup,collect_set,concat_ws等函数。
层次关系方法：固定深度层次进行分组和钻取查询，递归层次结构数据装载、展开与平面化，多路径层次和参差不齐处理
五．退化维度
除了业务主键外没有其他内容的维度表。
六．杂项维度
包含数据具有很少可能值的维度。有时与其为每个标志或属性定义不同的维度，不如建立单独的讲不同维度合并到一起的杂项维度。
七．维度合并
如果几个相关维度的基数都很小，或者具有多个公共属性时，可以考虑合并。
八．分段维度
包含连续的分段度量值，通常用作客户维度的行为标记时间序列，分析客户行为。
参考《Hadoop构建数据仓库实践》
