什么是维度
简单的来说维度就是用于分析数据仓库中的事实的描述（关于事实下文讲解）.举个例子在数据库中有两张表，订单明细表和商品表
订单明细表ID_ ORDER_ID PRODUCT_ID_ quantity 1 1 1 10 商品表
ID_ PRODUCT_NAME 1 华为手机 这两张表中订单明细表使用商品表中的id与之关联，订单明细表为事实表记录了订单明细的事实，商品表就为维度表，因为商品表描述了订单明细表，
我们通过商品表中的维度信息去分析订单明细表中的数据，用需求文字来描述就是我想查购买了华为手机的所有订单明细，转换成SQL语句为1
select * from 订单表 t1 inner join 商品表 t2 on t1.PRODUCT_ID_=t2.ID_ where t2.PRODUCT_NAME='华为手机'
什么是事实
- 事实一般只是一些单纯的数字，如上文订单表中的数量，它仅仅是订单中的一个度量，没有什么文字描述，文字描述都存在维度表中,通过维度表去分析事实表。
什么是粒度
- 事实表中的存储数据都要有相同的粒度,粒度用于确定某一事实表中的行表示什么,例如上文订单明细表中的粒度是到商品,不是订单，因为表中有一个产品id，如果该表去掉PRODUCT_ID_和quantity那么该事实表中的粒度就为订单（一个订单中可能包含很多商品）,所有的事实表中的数据都应该有相同的粒度，同样维度表中的关联也需要和事实表中的粒度做对应，就好比上文的订单明细表中最好不要出现订单的维度，比如订单类型等信息.
设计维度的过程
选择业务过程
业务过程一般存储在业务系统的关系型数据库中，我们必须根据需求选取对应业务表中的数据，如我需要建立订单为主题的数据集市，则我需要抽取业务系统中关于订单的数据
声明粒度
最好要包行最低粒度，如上文中建立一张订单明细表，而不是只建立订单表，因为细粒度可以根据维度上卷得到粗粒度的数据，反之则不能。
描述维度
维度提供业务的描述，比如谁，什么，何处，何时等。维度表为数据仓库中的灵魂，是数据仓库中最重要的部分，维度描述越丰富，则数据仓库
中所挖掘的信息越多。确认事实
事实涉及业务过程事件的度量,基本上都是以数量值表示，一个事实表中的所有粒度需要保持一致。
数据仓库的分层
- 目前项目中采用了4层架构分别为
- ods贴源层，ods层中存放了业务表中原封不动的数据
- dwd数据清洗层,dwd为了清理ods层中的数据
- dws主题层,此层获取dwd中的数据根据不同的主题组成不同粒度的事实表和维度供业务方调用
- ads层，此层一般为一些汇总数据供前端展示时调用
- 不同数据集市间的数据划分
可以考虑在同一个数据实例中根据表名建立各个数据集市中的4个不同的层，根据表名区分不同数据集市中的表，也可以根据不同数据集市建立不同的数据库实例来存储上文4个层的表，目前由于建立的数据集市较少为了方便才用同一个数据库实例。
数据的仓库架构
总线型架构
Kimball总线架构为，在项目开始时，由架构师设计通用维度，这个维度称为总线，设计完成总线后，将总线维度分发给各个数据集市的开发人员同步去开发，比如订单数据集市，库存数据集市。各个集市中的维度根据总线去做扩展，各个数据集市的数据再ads层之前是不做交互的，如果要跨域多个数据集市去分析数据，那么就用通用维度（总线）去连接各个数据集市中的不同事实表去分析数据。
维度表设计
现在维度表的设计一般分为星型结构和雪花型结构
星型结构，采用宽表和冗余的形式存储维度，维度的父子关系都在一张表中关联，不通过外键关联，如下面时间表:
id 年 月 日 20190101 2019 01 01 20190102 2019 01 02 那么如果我想查询实时表中id为20190101的数据对应的月份是几月，那么我们可以使用id去时间维度去查找对应的月份
雪花结构,雪花结构的设计更多的用于关系型数据库，上图的时间维度用雪花型表示为
年表id 年 2019 2019 2018 2018 月表
id 月份 1 01 2 02 年月关系表
id year_id month_id 1 2019 1 2 2019 2 两种设计的优缺
星型结构：对查找的效率和难度来说更加高效简单，但是存储了大量冗余数据，而且不够灵活不方便修改，如果存在大量描述字段的话，那么冗余结构相比雪花结构使用更大的存储空间
雪花结构：数据更加灵活，比如更改维度表的信息不需要更改整个维度的信息，比如上文我要更改月份里面的字段我只需要更改月表中的信息即可，不需要更改整张维度表，但是查询更加麻烦和慢。
其实归根到底就是范式设计和非范式设计，在数仓中大多数情况下应该使用星型结构，因为数仓关注的是查询，用存储空间换取查询数据的方便是值得的，至于对于星型结构存在维度变更的问题，我们将在另一篇文章，维度缓慢变化中说明
