1年sql数据库经验，却说数据模型一文不值？你还没懂数据仓库

平时在工作中，一般都会遇到拿着 Excel 直接分析，给报表的场景，或者更近一些互联网的分析工作，会用 SQL 取数，再用 Excel 分析。

那说到分析，就必然离不开BI、数据仓库、数据建模等了，spark，hadoop等大数据平台，也是搞这行的人得懂的知识。

可是，相比于那些架构、算法，更让我头疼的是数据结构和模型。

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

如果说，广义的数据结构，比如链表，平衡树和图等，是一切编程的基础，那么理解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 解决了数据一致性问题，但性能又是老大难的问题。

很显然在目前的信息时代，借助类似于FineBI的这些工具，可以让企业加速融入企业数据分析的趋势。备受市场认可的软件其实有很多，选择时必须要结合实际的情况。一般的情况下，都建议选择市面上较主流的产品，比较容易达到好的效果，目前企业数据分析BI软件市场占有率前列的，就是帆软BI软件——FineBI。