看数据模型界两大长老的神仙打架

有关SQL

共 3085字,需浏览 7分钟

 ·

2020-07-28 16:49

点击蓝色“有关SQL”关注我哟

加个“星标”,天天与10000人一起快乐成长

如果有人问起,“L,对于编程,你最后悔的一件事情是什么?”我只能回答:“数据结构”。

故事,要从我最初学编程的动机,开始说起。

踏入编程这个行当,我是从Visual FoxPro 开始的。

上大学那会,本科学农,农学是养花养草的专业,和计算机一点儿关系没有。但学校是有规定,大一大二要通过计算机二级。被教育了12年,别的本事没有,要说证书这事,那是相当热衷。所以早早就把 VFP 学好了,自然考试也轻松通过。

通过也就通过了,也没留下特别的情感。转机出现在大二,那年学统计,其中有各种公式,各种参数,纷繁复杂,作业题不难,但很多推演特别麻烦。那天做完统计学作业,正在图书馆发呆,过了2,4,6级,发现人生有些空虚,接下来还有2年半的时间要挥霍,不禁要焦虑,接下来该做什么,才能证明自己?

人生的苦恼,逃不过三大问题,我是谁,我从哪里来,要到哪里去

眼瞅着瞅着,就瞄到了作业题上去。这些可恶的参数,每次都要手写,一写就是一个长本,跟写舞台剧台词一样。那有没有好一点的方法来求解最终的答案呢?

就跟棒球突然击中村上春树文艺细胞一般,慵懒的午觉,加上一口激爽的冰咖,瞬间蛰醒了已充分回血的大脑。忽然就想到了VFP中的表单,想到了类里面的变量,这些变量不就是参数嘛,表单不就是每次作业题的草稿嘛。至于公式,那就是方法嘛。我把公式,参数,建成类,最终结果就让计算机程序去算。为什么我要用笔去推算呢?

慢慢的思路磨就出来,于是,说干就干,到机房,插上1.44MB的磁盘,一个下午,把指数平滑公式给写好了。接下来的作业,只要输入表单对应参数值,按下计算按钮,结果就出来了。

从此,作业变成了分析需求,编程成了我真正的作业

你们看,我开始编程时,就在解决一些实际问题,将作业计算中的定量模型,抽象出K-V的数据模型,而计算公式则抽象出函数。

现在回首,我依然对广义的数据结构和算法抱着极高的敬畏。同时,我也庆幸,我掌握了解决信息领域的数据结构与算法,即关系型数据库的数据模型

如果说,广义的数据结构,比如链表,平衡树和图等,是一切编程的基础,那么理解RDBMS的“数据结构”,比如范式,星型,雪花型,大宽表等,就是叱咤信息领域的基础。无论你如何努力,都不会精通,却可以解决无数实用的问题,带来极大的心理成就感和满足。

为方便大家直观地感受数据模型,在这儿出道题,比如对比双11,双12等前后价格波动,引起的销量变化。分享下,你会如何涉及表结构,来满足分析的需求。

要做好这类数据分析的建模工作,离不开讨论 Kimball 与 Inmon 的数据模型。两种截然不同的模型,带给项目的便利与挑战,也是大不同。

当然还有诸如 Data Vault 与 Anchor 模型等等

首先从架构说起


上图,是 Inmon 的集线器架构图。数据仓库,并不是 Inmon 理论的交付产品,它只是一个集企业所有关键实体、业务流程数据于一体的存储。面对各个部门自己的分析需求,数据仓库最终还会继续分流出各个业务需要的数据集市,所有单独的业务都从分配到的数据集市中抽取数据。

从这个架构图,很容易看出,数据仓库只是负责收集数据,类似集线器,最终还是要把数据分流出去。

Kimball 的架构就不一样了。如下图所示,他也有一个大的数据仓库,但少了数据集市的概念。

 

在Kimball的理论模型中,数据集市从来不是正规的交付物,而是ETL过程中自然产生的副产品。即ETL将业务数据集中抽到 Staging 时,会将数据按照实体,业务流程打包成一个ODS层(Operational Data Store),任何单个业务部门,完全可以从ODS中查询数据。功能上类似于 Inmon 的数据集市。

最终数据汇总到数据仓库时,天然就带有企业全局属性。只见树木不见森林的尴尬,就被化解了。好比,面临企业利润的下滑,我们就能从成本,订单量,单价上来做多维度分析,而不再是仅仅盯着订单量一个维度去看。

所以,Kimball 的理论,更多是数据从局部流向整体的策略,最终交付物,数据仓库就像是企业数据流总线,谁要谁取,不必切换多个数据库。

再对比数据模型的落地

曾经有位同事问我,为什么我们的表,设计了很多冗余字段,而不是严格按照三范式设计呢?其实答案就是 Kimball 的维度模型使然。在 Kimball 总线架构图中,我特意用星型模型标注了数据仓库的 schema.

很好看懂,中间一颗星,周围直联其他星星,有且只有一级联系。这就是 Kimball 数据模型的精髓所在。与 Inmon 最大的区别,也就在这里。Inmon 的数据模型都是ER模型,范式用到了极致。

我们来看 Kimball 的星型模型维度建模:


很直观,围绕着SalesOrder(销售订单)业务,假设有三个维度(即影响订单的三个因素,实际上远不止3个,300个都有,互联网甚至还有3000个)Employee, Time, Components,即人,货,时。

人的维度,还包括了人所在的部门,地址和职级;时间维度,算简单的一个,实际应用中,会有多个记账周期,时间略有复杂;货的维度,就是商品,有厂家,地址,厂长和商品本身的属性,大小,颜色等等。

这就是很多入门的同学迷糊的地方,为什么在一个表里,会有很多看似冗余的数据,为什么不按照三范式拆出来呢?这里有个特别重要的原理,那就是空间换时间。

当所有的属性都拿来做维度分析时,为了节省Join的时间,通常把这些维度属性预先计算好。即时查询分析,用GroupBy去随机分组统计数据,假如没有合适的索引,会非常慢。为了提高效率,我们只能把这些组合的统计与聚合,预先计算好,存起来。大部分的 OLAP 引擎,都是基础这个原理,比如SQL Server Cube, Kylin等。

Kimball 给这种数据模型,起了个名字,“星型模型”。作为最终的交付产品,是数据仓库的灵魂。

Kimball 理论也没有放弃数据集市,只不过他将数据集市放在ETL阶段实现了,用的是另外一种模型,叫做“雪花模型”。功能与 Inmon 的数据集市类似,实际上,数据模型也一致,就是标准的ER模型,即三范式结构。


人的维度上,只保留人本身的属性,比如性别,身高,年龄等,其他附属属性,比如地址,部门,职级,都分别存在不同的子表里面。其他两个维度也一样,自留属性与附加属性都分别存储。这样一个坏处,就是Join比较多,而且容易造成性能缓慢。

那么现实中,我们该用哪种理论来设计数据仓库的架构呢,用哪种数据模型来建模呢

现实世界没有银弹,一切取决于所在业务的复杂度。Kimball 理论显然更适合BI套件,但留下冗余数据处理的复杂;Inmon 解决了数据一致性问题,但性能又是老大难的问题。

顺便说下,阿里巴巴的大数据实践,在第三阶段,也采用了 Kimball 数据模型方法论。可见,即便是在互联网应用,数仓的众多模型也是通用的。具体参考这本书《大数据之路-阿里巴巴大数据实践》



--完--





往期精彩:


本号精华合集(二)

如何写好 5000 行的 SQL 代码

如何提高阅读 SQL 源代码的快感

我在面试数据库工程师候选人时,常问的一些题

零基础 SQL 数据库小白,从入门到精通的学习路线与书单









浏览 37
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报