Ralph Kimball在90年代发布了维度建模思想，并于1996年发布了The Data Warehouse Toolkit，并通过它向世界介绍了维度数据建模。
在本文中介绍维度数据建模，探讨为什么这种方法如此占主导地位，然后我们应该将其中的哪些部分引入现代云数据仓库时代。
一 Kimball的维度建模思想
数据建模有很多方法。我们之所以选择关注Kimball的思想是因为他的观点是最广泛的，因此也最能引起数据专业人士的共鸣。如果您现在雇佣一个数据分析师，他们很可能熟悉多维数据建模的思想。因此，你需要掌握有效地与他们合作的方法。
但是，我们应该注意到，还有另一种数据建模方法经常被提到。这种方法被称为Inmon数据建模，以数据仓库先驱Bill Inmon的名字命名。Inmon的方法发表于1990年，比Kimball早了6年。它关注的是规范化模式，而不是Kimball的更非规范化的方法。
第三种数据建模方法名为Data Vault，于21世纪初发布。我们认为这些方法中有许多是有价值的，但是由于数据仓库技术的快速发展，所有这些方法都需要更新。
二 星型模型
为了理解Kimball的数据建模方法，我们应该从讨论星型模型开始。星型模型是为了分析目的而组织数据的一种特殊方式。它由两种类型的表组成:
•事实表，它充当模行的主表。事实表包含业务流程的主要度量、指标或“事实”。
•与事实表相关联的多个维度表。每个维度表都包含“维度”——即事实表的描述性属性。
这些维度表被称为“环绕”事实表，这就是“星型模型”的由来。
这些都有点抽象，让我们通过一个例子来具体看一看。
假设您正在开一家连锁商店，您想对来自销售点系统的数据进行建模。一种简单的方法是使用订单事务数据作为事实表。然后在订单表周围建立几个维度表，最明显的是产品和促销活动。这三个表通过外键连接，也就是说，每个订单可能引用存储在各自表中的几个产品或促销活动。
因此，这个基本的星型模型看起来是这样的:
注意我们的事实表是如何随着时间的推移迅速增长的，因为我们每天可能会看到数百个订单。相比之下，我们的产品表和促销表包含的条目会少得多，更新频率也会比事实表低得多。
三Kimball的四步流程
星型模型非常有用，因为它为我们提供了一种标准化的、经过时间考验的方式来考虑如何为分析目的塑造数据。
星型模型的好处如下:
•灵活性-它允许你的数据很容易被分割成任何你的业务用户想要的方式。
•可扩展—您可以根据业务变化来演化您的星型模式。
•高性能——Kimball的维度建模的方法是当大部分分析系统开发运行在关系数据库管理系统。星型模式在关系数据库上的性能特别好，因为大多数查询最终都是使用“星型连接”执行的，这是所有维度表的笛卡尔积。
但是星型模型只有在公司内易于应用时才有用。那么，你如何为你的特定业务建立一个星型模型呢?
Kimball对此的回答是维度数据建模的四步过程。这四个步骤如下:
•选择要建模的业务流程。Kimball的方法从业务流程开始，因为业务用户最终会想要询问有关流程的问题。这与早期的建模方法(如Bill Inmon的方法)形成了鲜明的对比，后者首先考虑业务实体(如客户模型、产品模型等)。
•决定颗粒度。这里的粒度指的是要存储为主要事实表的数据级别。它应该是最可能的原子级，即不能进一步分割的数据级别。例如，在前面的Point of Sales示例中，颗粒实际上应该是每个订单中的行项目，而不是订单本身。这是因为在未来，企业用户可能想问这样的问题:“我们商店里白天卖得最好的产品是什么?”为了有效地查询这个问题，你需要降到行-项目级别。在Kimball的时代，如果您在订单级别对数据建模，那么这样的问题将花费大量的工作来获取数据，因为您将在缓慢的数据库系统上运行查询。如果数据目前不在仓库中以可查询的形式存在，您甚至可能需要再次执行ETL !因此，最好从一开始就尽可能在最低水平上建模。
选择应用于每个事实表的维度。如果你选择了正确的颗粒度，这通常是很容易回答的问题。维度不属于“业务人员如何描述业务流程产生的数据”这个问题。您将使用一组表示所有可能描述的稳定的维度来表示事实表。
•确定每个事实表行的数字事实。事实表中的数字数据不属于“我们要回答什么?”这个问题。业务人员会问一些明显的业务问题(例如，每个产品类别的平均利润率是多少?)，因此您需要决定哪些是要存储在事实表层的最重要的数字度量，以便稍后重新组合以回答他们的查询。事实应该是真实的颗粒度在步骤2中定义;如果一个事实属于不同的层次，那么它应该存在于一个单独的事实表中。
在零售POS的情况下，如果我们按照上面的四个步骤对行项目进行建模，并最终得到如下的结果:
请注意维度表是如何围绕事实表向外排列的。此外，事实表如何由维度表的外键组成，以及“数字事实”(出于业务度量目的可以聚合的字段)如何在行项目事实表中仔细选择。
注意，我们还有一个日期维度:
为什么要用日期维度呢?答案是让业务用户更容易查询。企业用户可能希望查询财政年度、特殊假日或像双十一和圣诞节这样的销售季节。因为这些概念没有在RDBMS系统的日期字段中捕获，所以我们需要将日期建模为一个显式的维度。
这抓住了Kimball方法的一个核心理念，即现在做困难的工作，以后查询起来更容易。
这个简短的例子展示了维度数据建模的特色。我们可以看到:
1.事实表和维度表为我们提供了一种标准化的方式来考虑如何塑造分析数据。这使得您作为数据分析师的工作更容易，因为您是由特定的结构来指导的。2.Kimball的四个步骤可以应用于任何业务流程。
3.由此产生的星型模式带来了灵活性、可扩展性和高性能。
4.考虑到Kimball所处理的性能约束，星型模式工作得很好。在Kimball时代，内存是相对昂贵的，并且分析查询要么运行再RDBMS之上，要么导出到OLAP多维数据集中。这两种方法都受益于结构良好的多维数据模型。
四Kimball的数据建模方法的必要性
在讨论这些技术是否适用于今天之前，我们必须问:为什么首先引入这些数据建模技术?回答这个问题有助于考虑现在可以评估潜在的原因是否已经改变。维度数据建模方法在90年代首次引入时获得了关注，原因如下:
•它给我们带来了商业价值。在过去，数据仓库项目是昂贵的事务，需要尽快显示业务价值。在Kimball时代之前，数据仓库设计者通常会提出标准化的模式。这使得查询的编写非常复杂，并且使得业务智能团队难以快速、可靠地向业务交付价值。Kimball是第一个正式意识到非规格化数据比规格化数据更适合分析工作负载的人。他的星型模式概念将他的方法转变为可重复且易于应用的过程。
•性能的原因。正如我们前面提到的，在Kimball的时代，大多数分析工作负载仍然运行在RDBMS上(正如Kimball在《数据仓库工具箱》中声称的那样)。贯穿本书始终的是您需要记住的性能考虑因素，甚至在扩展模式设计的变体时也是如此——其中最主要的是星型模式允许RDBMS执行高效的“星型连接”。简而言之:维度建模在运行业务分析时具有非常实际的好处，以至于您无法忽略它。当人们将数据从数据仓库导出以运行在更高效的数据结构(如OLAP多维数据集)中时，这些好处中的许多也同样适用。
我们认为Kimball的观点非常有用，非常有影响力，如果我们今天忽视它们是不明智的。但是，既然我们已经研究了它最初崛起的原因，我们必须问:这些想法在云优先、功能强大得令人难以置信的数据仓库时代有多重要?
五 Kimball数据建模的过去和现在
今天最大的变化是数据劳动力和数据基础设施之间的成本差异。
Kimball数据建模要求:
•提前设计方案
•构建和维护数据管道来执行这样的模式(大多数情况下使用ETL工具)
•建立接受过Kimball方法培训的专门团队，以便您可以评估、扩展和修改现有的星型模式，以响应业务流程更改。
在数据基础设施功能不足且价格昂贵的时候，这项投资是有意义的。今天，云数据仓库的功能比旧的数据仓库强大很多倍，而且成本只是旧数据仓库的一小部分。
也许我们可以把它说得更具体一些。在数据仓库工具包中，Kimball用如下插图描述了一个典型的数据仓库实现项目:
一个典型的项目是这样的:您将编写ETL来整合来自不同源系统的数据源，将数据存储到数据暂存区，然后使用ETL工具将数据建模到数据表示区域。这个数据表示区域由多个数据集市组成。反过来，这些“集市”可以在RDBMS或OLAP多维数据集之上实现，但重点是，这些集市必须包含维度建模的数据，而且数据必须在整个数据仓库项目中一致。
最后，数据展现工具使用这些数据集市。
您将注意到，这种设置比我们的方法复杂得多。为什么会这样?
同样，答案在于当时可用的技术。数据库很慢，计算机存储昂贵，BI工具需要在OLAP多维数据集上运行才能快速。这要求数据仓库项目由许多独立的数据处理步骤组成。
今天，情况好多了。我们的方法假设您可以去掉Kimball方法中的许多元素。我们先举两个例子，然后归纳出一些原则，可以把它们应用到实践中去。
示例1:库存管理
在《数据仓库工具箱》中，Ralph Kimball描述了对许多类型的企业来说，跟踪库存移动是一种常见的业务活动。他还指出，一个包含每一个库存变动的事实表太大了，无法进行良好的分析。
因此，他用了整整一章来讨论解决这个问题的各种技术。Kimball提出的主要解决方案是使用ETL工具来创建“快照”事实表，这些事实表基本上是在一定时间内聚集的库存移动。这个快照操作应该定期进行。
然后，Kimball演示了可以使用聚合快照表进行数据分析，并且只对少数查询使用库存事实表进行分析。这对业务用户有帮助，因为在完整的库存表上运行这样的查询通常是一场性能噩梦。
今天，现代云数据仓库有很多特性，可以让这种“快照”变得不那么困难:
•现代云数据仓库通常由列状数据体系结构支持。这些列状数据存储能够在几秒钟内处理数百万行。这里的结果是，您可以扔掉关于快照技术的整个章节，仍然可以得到相对较好的结果。
•几乎所有现代云数据仓库都运行在大规模并行处理(MPP)架构上，这意味着数据仓库可以根据运行查询所需的服务器动态地启动或关闭任意数量的服务器。•云数据仓库按使用情况收费，因此您只需支付较低的前期成本，并且只为所使用的内容付费。
这三个需求意味着，雇佣、培训和保留数据工程团队来维护这种复杂的快照工作流程的成本往往更高。因此，在现代列状数据仓库中的库存数据上直接运行所有这些流程通常是一个更好的选择。
例2:缓慢改变的维度
如果维度表中的维度随时间变化，会发生什么?例如，假设你在教育部门有一个产品:
你想把IntelliKidz 1.0的部门改为“战略部门”。
您可能采用的最简单的策略是Kimball所称的“类型1”响应:您天真地更新维度。这就是上面所发生的事情。好消息是这个响应很简单。坏消息是，以这种方式更新维度表会弄乱旧的报表。
例如，如果管理层要再次运行旧的收入报告，用于计算归入教育部门的收入的相同查询现在将返回不同的结果——因为IntelliKidz 1.0现在注册在一个不同的部门下!因此，问题就变成了:如何在一个或多个维度中注册更改，同时仍然保留报表数据?
这就是所谓的缓慢变化维度的问题,或处理SCD。
Kimball提出了三种解决方案:
第一个“类型1”是简单地更新维度列。正如我们刚才看到的，这种方法存在问题。
第二，“类型2”，在产品表中添加一个新的行，并使用一个新的产品键。这看起来如下:
使用这种方法，事实表中的所有新订单都将引用产品密钥25984，而不是12345。这允许旧报告返回相同的数字。
最后一种方法“Type 3”是向维度表添加一个新列，以捕获以前的部门。这种设置支持查看相同数据的“另一个现实”的能力。设置如下:
Kimball的三种方法在执行时需要付出一些努力，但是这些方法使得查询和编写报告变得相当复杂。
那么现在是如何处理SCD的
Lyft高级数据工程师Maxime Beauchemin描述了一种目前在Facebook、Airbnb和Lyft中使用的方法。
这种方法很简单:许多现代数据仓库都支持表分区特性。Beauchemin的想法是使用ETL工具创建和复制新的表分区，作为所有维度数据的“快照”，每天或每周。
这种方法有很多好处:正如Beauchemin所说:“计算是便宜的。存储是便宜。工程时间是昂贵的。”这种方法纯粹是在计算资源和工程时间之间进行权衡。与事实数据相比，维度数据既小又简单。这意味着，即使是几十年前的几千行快照，对于现代数据仓库来说也只是沧海一粟。最后，快照为分析人员提供了一个易于推理的心理模型，这可能不得不为Type 2或Type 3响应编写的查询相比。
作为第三个好处的例子，Beauchemin提供了一个示例查询来演示这种方法所需的心理模型的简单性:
这里的关键观点是，现在的存储真的很便宜。当存储成本较低时，您可以做一些“愚蠢”的事情，比如每天对每个维度表进行分区，以便获得缓慢变化的维度的完整历史。
正如Beauchemin在演讲结尾所提到的:“下次有人与你谈论SCD时，你可以向他们展示这种方法，并告诉他们这已经解决了。”
六 Kimbal维度建模在当今数据基础设施中的应用
那么，我们如何将传统的Kimbal维度建模与现代技术相结合呢?我们认为这种方法是有价值的。以下是我们实践中的一些想法，我们认为这些想法可以普遍应用到你的分析工作中:
Kimball-style维度建模是有效的，Kimball关于星型模式的思想，使用非规范化数据的方法，以及维和事实表的概念，这些都是强大的、经过时间考验的方法，可以为分析工作负载建模数据。
我们认为这个问题不是:‘Kimbal维度建模在今天有意义吗?他说，很明显，这种方法仍然有用。我们认为值得问的问题是:“在没有与之相关的所有繁忙工作的情况下，是否可能获得维度建模的好处?””我们认为答案是肯定的。
什么时候数据建模
我们认为，如今拥有惊人数量的原始计算能力的最大好处是，这种能力允许我们增加建模实践的灵活性。我们的意思是，你应该在必要的时候建模。
首先从源系统的原始数据表生成报告，特别是如果报告创建起来不是很困难，或者查询编写起来也不是很困难的话。如果是，则对表进行建模，以匹配对用户最重要的业务指标，无需过多考虑未来的灵活性。
然后，当报告需求变得难以满足时且只有当它们变得难以满足时，您可能会以更正式的维度建模方式重做模型。
为什么这种方法有效?这是因为在相同的数据仓库中进行转换比较容易。当您将所有内容存储在现代数据仓库中时，您就可以根据需要更改建模方法。Kimbal在编写数据仓库工具包时，为了改变数据模型的形状，必须创建新的ETL管道。这是昂贵和耗时的。但我们的方法并非如此:因为我们建议您首先将原始数据集中在一个数据仓库中，您可以使用该数据仓库的强大功能将它们转换为同一个数据仓库中的新表。
当与为这种模式设计的工具结合使用时，这就更容易了。这些工具有哪些?比如Holistics、Dbt和Looker这样的工具。这些工具的共同特征是，它们在创建、更新和维护新数据模型时提供了有用的结构和管理帮助。例如，使用Holistics，可以可视化模型的谱系。使用Dbt和Looker，可以跟踪模型随时间的变化。这个部分中的大多数工具都允许对模型进行增量更新。
然后，这些工具生成创建新数据模型所需的SQL，并将它们持久化到同一个数据仓库中的新表中。注意，不需要请求数据工程来建立和维护外部转换管道。所有的事情都在一个工具中发生，利用底层数据仓库的功能。
尽可能使用技术代替劳动力
一个更普遍的原则是尽可能使用技术来取代劳动力。
我已经给出了两个这样的例子:库存建模和处理缓慢变化的维度。在这两种方法中，Kimball的方法都需要一定程度的手工工程。当代的方法是简单地依赖现代数据基础设施的力量，使这些手工活动变得无关紧要。
对于库存建模，我们认为MPP列状数据仓库的强大功能使得跳过聚合表成为可能……除非它们是绝对必要的。您的使用应该驱动您的建模需求，而不是反过来。
对于SCD，我们提出了一种已被一些大型科技公司采用的方法:即，认识到现在的存储非常便宜，并使用表分区对维度数据进行快照。这就避免了实现Kimball在他的方法中详细描述的三个响应之一的需要。
在这两种情况下，我们应该批判性地评估计算成本和人工成本之间的平衡。如果可以使用现代云数据仓库功能找到某种方法来回避Kimball的许多技术，那么就不应该采用这些技术。
七 小结
全面地考虑数据基础设施，利用大数据的力量来提高现有人员的决策能力，并选择雇佣数据分析师创建可重用模型，而不是数据工程师创建额外的基础设施。你也应该考虑这么做。
