目录
点外卖引发的思考
背景
First Blood
double kill
Triple kill
为什么要模型
建模方法论哪家强
Inmon
Kimball
总结
点外卖引发的思考
背景
作为一名宅男，放假在家最开心的时候是什么？当然是点外卖了。打开外卖app的一瞬间，所有吃的都是我的，可以任意挑选，像北京的呷哺呷哺火锅啊，杭州的鲁员外地锅鸡都是不错的选择，在家吃真的太爽了。
额，咳咳~说到吃的一时间有点把持不住了，我点个外卖先。
看上面三个图，有木有想立马下单的冲动。忍住，毕竟今天我们要聊的不是怎么吃，而是怎么建模。那我就先开吃了~.~
大家都知道，外卖的核心业务过程是访问首页-进店-商品详情页-下单，那么如果我们想做外卖的数据建模，我们该如何下手呢？
First Blood
大家还记得业务库的ER建模吗？如果没有做过java web，直接做数仓的同学可能比较陌生，但其实了解了ER建模，才能做好数仓建模，而了解ER建模的第一步就是了解业务，其实这个和我们现在常说的业务过程是一致的。
那么点外卖这个过程都有哪些角色的参与？这些角色都做了什么？产生了什么样的结果呢？
角色
消费者，就是点外卖的我们，也可以尊称为妄图通过各种优惠券薅平台羊毛的小韭菜；
商家，妄图通过平台的流量薅消费者羊毛的卖家；
平台，庄家，通吃。
行为
商家申请入住平台；
消费者在平台逛街；
消费者进店下单。
结果
商家开店产生了供应链和商品的动销；
用户浏览产生了用户行为日志；
用户下单产生了订单；
下单之后产生了配送，以及咨询等等。
double kill
上面的角色、行为、结果就形成了一些ER模型，举例如下：
消费者购买商品的ER模型
对应数据库设计如下（一般订单表会存在两个）
Triple kill
业务系统构建的ER模型目的是什么？当然是为了实现业务功能。
他关心数据的统计分析吗？他不关心。
那我们作为面向分析的数据建模可以完全使用ER建模吗？必须不行啊。
那数据建模怎么jian？我们可以借鉴ER模型啊。
为什么要模型
业务库的ER建模是为了实现业务功能而产生的一种设计方式，那么我们数据建模是为了什么？还记得数据仓库的特征吗？
数据仓库特征
so what？我们来挨个分析一下子
面向主题，主题是数据的分析边界。啥是数据的分析边界？就是根据行业特性总结出来的一套数据的划分。好像懂了，但是并没有完全懂。不懂没关系，咱们就先认为这个就是通过一种数据分类，让统计分析更加的方便。
数据是集成的。这个好理解，把所有的东西都放在一起就是集成。没毛病，也就是说，数仓就像一个数据中心，是可以接受所有的业务数据，除了非结构化数据。哦。我明白了，怪不得说数仓是面向企业级别的，如果再看第一条的话，那是不是这个主题域是不分业务系统的？完全正确。
数据仓库中的数据反映历史变化。怎么才能反应历史变化呢？我记得业务系统都是一直update的，除非数仓能把所有的历史数据都保存下来。
数据仓库中的数据是稳定的（或称不可修改的）。这个不太好理解，啥叫稳定的。大家查询业务系统的时候是不是只能看到最新状态的数据，如果想看已经被覆盖或者更新的操作记录是不是就看不到了，那这怎么办，我们做数据分析的时候，如果一个指标口径算错了，想重新计算一下某个时间点的值，业务系统算的出来吗？他算不出来，数仓可以算出来吗？必须可以啊。
也就是说我们数据建模的目的是为了更好的实现企业数据统计分析的能力。
建模方法论哪家强
说起数据建模，那首先想到的就是鼻祖Inmon啊，为啥？数据仓库的概念就是老人家提出来的啊，但是现在大家身边用Inmon建模的多吗？几乎没有了，这是为啥？为什么Kimball变成了后起之秀。听我给大家辩解。
Inmon
Inmon模型是Bill Inmon老爷子提出来的，他的设计思路是：自上向下的（数据流向），也就是从数据源->数仓->数据集市，设计步骤如下：
业务系统数据通过ETL过程入仓；
数仓满足第三范式的；
数据集市按照主题划分。
我们可以看到，Inmon的数据仓库是通过将所有业务数据入仓并且构建满足第三范式的数据模型，也就是说他和ER模型比较接近，是规范化的，那么为什么规范化的数仓最终没有被普遍使用呢？
其次，Inmon的数据集市是独立与数据仓库以外的，所以需要把分主题的数据再通过一次ETL过程导入到数据集市中。
我们再接着看一看Kimball是个啥
Kimball
Kimball是Ralph Kimbal大神提出的，也被称为维度建模。维度建模的模型是自底向上的，即从数据集市-> 数据仓库 -> 数据源。设计步骤如下
分析最终任务，将数据按照目标拆分出不同的表需求，形成数据集市层；
为了得到实现最终任务的结果表，需要构建数据仓库层，由事实表和维度表构成；
将需要的数据通过ETL工具入仓。
维度建模是通过结果来构建数仓的，所以并不需要将所有业务数据入仓，上手难度较低，这个大家最喜欢了；
数据仓库层用了一种新的划分方式：维度、事实，这俩是什么东西？
数据集市没有了？其实数据集市合并到了数据仓库里面。
总结
我们从生活中的一次点外卖，一步一步的分析业务系统的ER模型设计，再到数据建模的Inmon和Kimball。我们可以看的出来，业务系统建模是针对业务功能的，而数据建模是为了针对数据的统计分析的。
Inmon和Kimball各有各自的特点，但是之所以Kimball被众多互联网公司选择，最重要的原因是他的设计比较简单，Kimball完全是结果驱动，可以快速拿到结果，但是Inmon因为需要构建一个完整的企业级数据仓库，前期需要花费大量的时间和经历来设计，有这个时间，说不定业务都没了，谁还看你的统计结果。
但是Inmon的设计里面把数据集市独立于数仓之外的设计被借鉴了下来，我们现有的数据仓库架构中，大部分都是用一个或者多个olap作为数据集市，不过多个olap虽然解决了不同应用场景，但是形成了数据孤岛，所以大势所趋是统一数据集市的存储。
其次，Kimball的设计因为是结果导向，并且本身维度建模就会出现数据冗余，所以会出现大量的数据质量问题和烟囱式开发的问题，导致当下大家能看到漫天飞的数据治理场景，这就是选择使用Kimball的后遗症。
那么之后的Onedata在Kimball的基础上做了哪些优化呢？维度建模如何落地呢？事实、维度又是是什么东西呢？建模过程的大宽表、分层又是如何做的呢？且听村长下回分解。
关注博主不迷路~
