建模流程

业务建模

根据业务部门进行划分，理清部门之间的关系，然后将各个部门的具体业务程序化，与业务部门开会协商出需求的指标、保存年限、维度等等。总体来讲，就是要知道他们需要哪些指标以及他们能提供哪些数据。业务建模的时间最长，而且与公司实际的业务环境息息相关，因此在这里需要根据实际生产环境和业务需求确认好数据仓库使用的工具和平台。

概念建模

将业务模型抽象化，分组合并类似的概念，细化概念，抽象出实体与实体之间的联系，理清各组概念之间的联系。说白了就是画图，把指标需要的哪些数据封装到一个实体里，实体与实体之间的关联等等用ER图表示出来。先画出局部ER图，最后再综合画出全局ER图。

逻辑建模

将概念模型实体化，具体考虑概念对应的属性，事件考虑事实属性，维度考虑维度属性。总体来说就是建表，前面已经画出了关系图，这里只要将表里头有哪些字段考虑出来就可以，如果是事实表就考虑事实字段和业务主键，如果是维度表就考虑维度属性，SCD策略等等。在这里需要确定数据粒度，如果多个指标都用到一个字段，则取粒度最小的指标。如果不确定指标的量度，则取毫秒级作为粒度。

物理建模

综合现实的大数据平台、采集工具、etl工具、数仓组件、性能要求、管理要求等多方面因素，设计出具体的项目代码，完成数仓的搭建。

7.4.2 数据模型

星型模型

数仓（具体说是dwd层）中只有一张包含历史数据且不冗余的事实表和一组附属维度表，每个维度一张。事实表与维度表之间通过外键和主键关联。星型模型的维度表可能存在冗余，因此是反三范式的，这种模型在数据维护上较麻烦，但是性能更高，业界普遍使用星型模型。星型模型的难点在于拉链表的维护，拉链表一般不能有冗余。

雪花模型

针对星型模型的维度表进行扩展的模型，将维度表拆解成维度表+说明表，说明表又可以进一步拆分，最终形成事实表-维度表-说明表的多次连接。雪花模型的表一般遵循三范式，在数据的维护上会很方便，但是多表join影响性能。

星系模型

多个事实表采用星型模型共享维度表，就形成了一个星系。

Data Vault模型

从上述模型中我们不难看出，如果解决了拉链表的维护问题，星型模型的缺陷就已经可以忽略。Data Vault模型由中心表、链接表、附属表、PIT表组成，这里的中心表，事实上就是维度表，链接表就是事实表、附属表是拉链表。Data Vault模型就是通过将拉链表从维度表中分离出来，来达到方便维护的目的。首先，中心表是一组业务生命周期内绝不会变的维度表，打个比方就是java里头的常量，常量再怎么冗余也不会有影响。链接表则是保存流水类数据的事实表，它通过外键与多张中心表连接，但不会连接附属表。附属表则是从维度表中抽出来的可能会发生变化的字段或表，这一部分就采用拉链表的方式创建，中心表则通过外键关联附属表的主键。

从同一维度表拆出来的字段根据变化维度不同可能还要分成多表存储，为了避免时效不一致，所以还会建立一张PIT表，用于维护附属表的变化历史。中心表通过外键与PIT表相连，而PIT表则为每个附属表的主键都准备了一个时间字段保存数据的更新时间。