数仓建模和业务建模对比总结

数仓建模和业务建模对比总结

1. 背景

1. 在大数据开发中，整个流程是数据采集，数据存储，数据传输，数据计算，数据展示。在这个过程中数据存储和数据计算是最关键2个环节。
2. 数据存储整体最关键就是各个数据库和表关系设计，这一点和业务数据库设计是一样，需要考虑数据读写方便，后续扩展方便，还需要保证性能可以满足现在以及未来一段时间的需求。
3. 本文就是讲述关于数仓建模的一些理解和实践经验分享。从大到小进行设计。

2. 整体建模思路

1. 在学术界，数仓整体建模思路有2大类，一种是Bill Inmon的自上而下。另外一种是Ralph Kimball的自下而上。
2. 自上而下，需要从企业整体先入手，梳理整个公司以及各个项目的流程，分析其中概念，应该有什么样数据，最后拼接到一起，完成整体设计。这样考虑点会非常全面，但会相对耗时，并且不保证一定可以完成企业需求。
3. 自下而上，则是根据企业需求来，只针对此前和当前需求进行设计，需要的数据就放入数仓中，不需要的则不放入。这类方式建设周期短，可以解决当前的业务问题。但可能会需要进行频繁迭代，因为企业需求是变化很快的，此前架构设计可能很快就无法满足需求。
4. 实际从个人经历来说，刚好经历过一个大的项目重构，刚好请教学习了一些大佬的思路。对于有经验的架构师来说，实际开发时，整体数仓架构设计，既有自上而下，也有自下而上，结合使用。因为对于经验丰富架构师来说，多年经验结合对公司业务理解，可以直接自上而下对业务做梳理，然后以此为基础做架构设计。同时结合企业需求变化，自下而上做调整。这样整体工期有所保证，能够切合企业需求，又能有较好的扩展和适应性，能够满足企业未来一段时间的需求。
   从个人角度来说，理论知识用来指导实践开发，但没必要照搬，尽信书不如无书。时间才是检验真理唯一标准
   PS：
   如一个电商业务系统，有订单模块，用户模块，营销和广告模块，物流模块，商品模块，支付模块，商家模块等等。
   当这些模块和产品经理的流程设计出来后，就可以进一步进行数据和表的设计了。

3. 数据库和表关系

1. 在数仓模型中，数据库表之间关系有星型模型，雪花模型，星座（星系）模型。
2. 星型模型，就是一个事实表以及关联的0到多个维度表，注意只会关联一层。也就是说针对这个事实表的数据查询，可以控制在这个事实表以及其关联的一层维度表内，查询速度相对较快，因为需要join的层级只有0或者1层。
3. 雪花模型，一个事实表关联了多个维度表，但这些维度表还关联其他维度表，像是一个雪花一样不断分散。这时候的维度表就是遵循了业务建表范式的维度表。
4. 星座（星系）模型，就是2个事实表通过一个共同维度表关联起来。这种关联在数仓中比较少见，因为为了方便数据分析，一般直接使用大宽表较多，也就是直接将维度表join到事实表中。
   PS：

1. 从上可以看出，数仓中星型模型表关系较多，因为数据都在一个大宽表中，数据查询更加便利。海量数据下进行表join成本是比较高的。这也是大小表join需要使用分布式缓存或者广播变量的原因。
2. 从上可以看出，业务建表会遵循一，二，三甚至四，五范式。这时候表之间的关系出现星座模型反而会多一些。为了确保第一范式的所有列都是原子性，第二范式的所有非主键列都需要依赖主键，第三范式的所有非主键列之间不能有依赖。整体这样下来，数据会被拆分为多个小的维度表，这时候事实表通过维度表关联起来反而会概率高一些。
3. 在数仓建模中，星型模型因为数据最多一层join就可以拿到所有数据，数据计算相对最方便。所以雪花模型可以通过提前将维度表join转为星型模型。星座模型，也是一样的思路。这也是OLAP引擎clickhouse对大宽表支持非常好甚至鼓励使用大宽表的原因并针对此做了很多优化。

注意，理论指导实际，但实际开发并不是照搬。例如实际经历过的，订单表很多时候为了相关页面信息展示更快，会保存一些并不需要进行同步更新的维度信息，如订单相匹配的地址，用户信息等数据，这样一定的数据冗余反而可以很好提升业务数据查询速度，实际反馈也比之前按照范式接口快30%以上。

4. 表设计

1. 第一范式，每一列都是不可分割原子数据项，也就是说每一列的数据都需要是不可分割，不能和其他列数据混合在一起。
2. 第二范式，在第一范式基础上，非主键属性必须完全依赖于主键属性。
3. 第三范式，在第二范式基础上，非主键属性之间不能互相依赖。

注意，主键并不是表里面的主键id，而是确定表一行数据唯一性的数据。如学生成绩，学生id和科目决定了一行数据的唯一性
这其实是很多时候实际开发约定俗称的规范，一般也都会这么践行，但理论从实际中抽象提炼出规律
上述三个范式内容总结一下，就是每一列的数据需要分割独立，并且非主键列数据必须依赖于主键来确定，同时非主键之间不能有依赖传递，必须都直接依赖于主键属性。

其实上述范式都遵守之后，就会发现建立好的表会拆分为多个维度表，因为满足上述要求后，原本一个表的数据需要拆分到不同表中，然后通过外键关联起来。这样才能很好剥离非主键属性之间的依赖关系，同时方便数据增加删除和修改。

5. 数仓建模步骤

1. 确定主题

1. 在数据开发中，数据指标一般都是按照主题划分，大的主题如留存，新增，日活，漏斗，GMV等等
2. 不管什么开发，先确定大的需求方向和类型最重要。

2. 确定度量

1. 顾名思义，就是需要哪些度量数据，如销售额，活跃用户数，留存用户数等等

3. 确定事实数据粒度

1. 顾名思义，就是需要确定数据在不同维度下的汇总情况，很多时候就是按照天，还是按照一周，半个月，一个月等等维度聚合。
2. 实际企业开发中，很多时候为了应对类似需求变化，一般选择一个最小粒度做开发，这样就算需要更高层次聚合，也可以应对。这是有经验面对无经验产品经理的踩坑教训！！！！

4. 确定维度

1. 确定维度，其实就是数据分析的角度，例如是按照人，按照地区，按照订单金额等等区分。

5. 创建事实表

1. 上述步骤处理之后，就可以建立事实表了。
2. 注意，数仓建表，和业务建表不同，数仓建表更鼓励使用大宽表，如果需要保留一定维度信息灵活性方便信息修改和一致性，降低数据冗余，可以使用事实表和一个层级维度表。也就是星型模型比较合适

注意，在数仓开发中，很多公司都有自己的规范。一般按照规范进行开发，很多理论规则其实包含在这些规范中了。当需要自行架构一个体系或者一个模块时，就可以结合自己经验和理论，从更高层级去做设计，这样实际结合理论，效果更佳。