一致性维度：
1.很重要
2、在维度设计的时候一定要保证维度的一致性
eg：
两个不同的业务：
1.流量的 item pv uv
2.交易的 item gmv
数据交叉探查：
将不同业务域 的 商品维度的数据 结合到一块 进行展示！！
即：
item pv uv gmv 这是比较常见的
那么一致性维度？
1.商品维度 对应：
1.流量域 ： a b c 三个属性
2.交易域 ：b c e f g h 四个属性
这个时候：
只有b c 可能 两个商品数据 可能不一致的情况 就是说
这两个域 数据可能 不能放在一块来看
2.时间维度：
1.流量域 ： timestamp
2.交易域 ： yyyy-MM-dd
这种 进行数据交叉探查的时候 会导致 不一致
所以维度一致 是很重要的
那么这些问题 该如何解决？？如何保证维度的一致性？？
1.共享维度表 （就是 你不同的域 建自己的维度的时候 要注意 一致性维度）
维度 整合与拆分：
整合：
1. 表名、字段名 命名规范统一
2. 字段类型的统一
3. 业务含义相同的表 进行统计
1.高内聚
2.低耦合
eg：
1.把源端 数据形式 差异较小的表进行整合
2.把源端 数据形式 差异很大的表进行拆分
1.主从表设计：
1.主表：
1.主要业务常用的维度属性
2.从表：
1.业务中不常用的属性
2.直接合并：
eg：
1.垂直合并：
1.eg：
低价区间 这个字段 依据 广告样式 和 价格来定的
就是 不需要 把 低价区间 按照不同的 广告样式 创建不同的字段
合在一个字段里
2.水平合并
就是 上面的 不同广告样式 不同的低价区间字段
会有问题：
会有 null
拆分：
1.水平拆分：
eg：
维度设计可能遇到的问题：
1.某些维表属性的来源表 产出数据的时间比较早
某些维表属性的来源表 产出数据的时间比较晚
2.某些维表 字段 热度比较高
某些维表 字段 热度比较低
3.某些维表 字段 经常会变化
某些维表 字段 不会变化 稳定
这三个场景 有什么好的解决方案呢？？
1.主从表设计
设计原则：
1.扩展性
2.易用性
3.效率
粒度方面也要考虑！ 粒度不一样的字段 就不要放在一张表 ！
数据方面
历史数据的归档：
1.归档策略：
1.通过设置数仓表的生命周期实现
1.ods 3天
2.dwd dws dim 3个月
3.report 历史全部保留
4.增量表 历史全部保留
缓慢渐变维：
1.看下面的图
![在这里插入图片描述]()
1.当帽子 类目发生变化 变成 帽子类
![在这里插入图片描述]()
1.处理方式？
1.重写 维度值
![在这里插入图片描述]()
第二种处理方式：
1.插入新的维度行 （上面的图片 少了 商品key 我就不改了）
![在这里插入图片描述]()
业务需求 ：
eg：
将6月所有的数据 归到老的类目
有什么问题？？
1. 重写维度 方式 做不到 ！！ 因为类目全 变了
2. 插入新的维度 方式 做不到！！！ 实际上可以做到 where 对吧 很麻烦
eg：
你依照 商品ID 去关联 发现 一个商品 id 对应两个 类目
或者 依据 商品key 关联 再where 也可以 (毕竟 商品key 是唯一的)
第三种方式：
1.新增维度列
![在这里插入图片描述]()
好处：
1.数据不会重复
2. 统计方便
想依据什么类目统计 选就可以了
快照维表：
快照：就是 当时的 状态 某个时间点的状态
快照的周期：多久去获取一次数据
eg： 1天、
按天获取快照 该如何获取和构建？？？
1.按天 进行数据抽取即可
注意：
1.抽取的是全量抽取
creattime updatetime
eg：
抽取 20200627 凌晨1点 抽取 到0627 24:点
createtime 小于 20200627 加上 updatetime 小于20200627 的数据
放入 hive dt=20200626
就可以达到按天构建全量表的 策略！
问题：
1.数据量达到一定程度 全量抽取 绝对不行！！这才是1张表 n张表 是不可取的 ！！
2.抽取性能 业务 库压力很大
该如何解决呢？
1.增量抽取 + merge
2.拉链表
