本文翻译自《dimensionalmodelingandkimballdatamartsintheageofbigdataandhadoop》，并获得原作者Uli Bethke的许可。 Uli Bethke是Sonra公司的首席执行官，是爱尔兰硬盘用户组的主席，也是甲骨文的宏基。
维度建模死了吗？
在回答这个问题之前，让我们回顾一下什么是维度数据建模。
为什么需要对数据建模？
有一般的误解。 数据建模的目的是使用ER地图设计物理数据库，但实际上不仅仅如此。 数据建模表示企业业务流程的复杂性，有助于记录关键业务规则和概念，规范企业关键术语。 明确阐述并帮助企业在业务过程中阐明模糊的想法和模糊性。 另外，可以使用数据模型与其他利益相关者有效地交流。 没有蓝图，就不能盖房子和桥。 所以，既然没有数据模型那样的蓝图，为什么要制作数据仓库那样的数据APP呢？
为什么需要维度建模？
维度建模是数据建模的一种特殊方法。 维度建模有两个同义词：数据集市和星形结构。 为了更好地进行数据分析，星形结构可以参考以下维度模型直观地理解。 这使您可以快速了解如何在客户、产品和时间上拆分订单，以及如何通过测量聚合和比较来评估订单业务流程的性能。
维建模的最重要的一点是定义事务业务流程中的最低粒度。 剪切和钻取数据后，无法向下钻取到叶级别。 换句话说，星型结构中最小的粒度，即事实和维度之间没有任何聚集的关联。
数据建模和维度建模
标准数据建模的任务是消除重复和冗馀的数据。 如果数据发生更改，只需在一个位置进行更改。 这有助于保证数据质量，避免不同位置的数据同步。 请参考下图中的模型。 包含表示地理概念的几个表。 在规范化模型中，每个实体都有一个独立的表，而数据建模只有一个名为geography的表。 在此表中，city重复多次。 对于每个city，如果country重命名，则必须在很多地方进行更新。
注意：标准数据模型始终符合3NF模式。
的标准数据建模本身并不是为业务智能工作负载而设计的。 表太多会导致关联太多，而表关联会降低性能。 数据分析将尽最大努力避免这种情况。 在数据建模中，多个相关表通过反规范化合并为一个表。 例如，前面示例中的多个表预联接到一个geography表中。
那为什么有些人认为维度建模死了？
一般人都认同数据建模的方式，但维度建模作为一种特殊的处理方式很有价值。 那么为什么在大数据和Hadoop时代，一些人觉得维度建模没有用了呢？
“数据仓库死亡”
首先，一些人把维度建模和数据仓库混淆了。 他们认为数据仓库死了，得出了维度建模也将被扔进历史垃圾箱的结论。 这种论点在逻辑上是一致的，但数据仓库的概念并未过时。 始终需要集成可靠的数据才能生成业务智能仪表板(BI Dashboards )。
只读结构误解
第二个常见的争论，例如“我们遵循只读方式的结构(架构)，所以不需要对数据重新建模”。 依我看，这是数据分析过程中最大的误解之一。 一开始我同意只转储原始数据，但此时考虑结构是有意义的。 但是，这不应该成为不对数据建模的借口。 只读方式的结构只是降低了下游系统的能力和责任，一些人不得不咬紧牙关定义数据类型。 所有访问无模式数据转储的进程都需要自己知道发生了什么，这完全是多余的。 通过定义数据类型和正确的结构，可以很容易地避免这些工作。
谈谈逆归一化和物理模型
这些宣传维度建模的观点实际上过时了吗？ 确实，也有比上述两个更好的观点。 要了解这些，您需要了解物理建模和Hadoop的工作原理。
采用上述维度建模的原因之一与数据的物理存储方法有关。 在标准数据建模中，所有真实世界实体都有自己的表。 这是为了防止数据冗馀和质量问题蔓延到数据中。 表格越多，就需要越多的关联。 这是标准建模的缺点。 表关联是昂贵的。 特别是在相关数据集上有大量记录相关联的情况下，这一点尤为明显。 在考虑维建模时，联接多个表。 这就是所谓的预关联或数据逆规范化。 因此，表数减少，相关关系减少，延迟减少，查询性能提高。
可以参加领英上的相关讨论。
彻底反规范化
为什么不贯彻反规范化？ 是否要取消所有表的关联而只保留一个表？ 确实，这样做虽然不需要关联表，但可以想象会带来负面影响。 首先，需要更多的存储来存储大量冗馀数据。 随着用于数据分析的列存储格式的出现，这一点现在已经不那么令人担忧了。 逆正规化的最大问题是属性值每次变化都要在很多地方更新，可能是几千次到几百万次的更新。 解决办法之一是晚上完全重装模型。 通常，这比增量更新更快，更简单。 基于列的数据库通常采用这种方法，首先进行的更新存储在内存中，然后异步写入磁盘。
分布式关系数据库(MPP )上的数量
据分布在 Hadoop，例如 Hive、SparkSQL 上建立维度模型，要很好地理解一个技术上的核心特征，就是它和分布式关系型数据库(MPP)上的建立方式是不一样的。在 MPP 中的节点上分布数据，可以控制每条数据记录的位置。基于分区策略，例如 Hash、List、Range 等，可以在同一个节点上跨表同定位(co-located)各个记录的键值。由于数据的局部性得到保证，关联速度会非常快，因为不需要在网络上发送任何数据。参考下面图示的例子，在 ORDER 和 ORDER_ITEM 表中有相同 ORDER_ID 的记录存储在同一节点上：
ORDER 和 ORDER_ITEM 表中 ORDER_ID 对应的键值，在相同的节点做到同定位。
Hadoop上的数据分布
数据分布在基于 Hadoop 的系统中是非常不同的，我们将数据分割成大型的块(chunks)，并在 Hadoop 分布式文件系统(HDFS)的各个节点进行分发和复制。这种数据分发策略不能保证数据的一致性。参考下面图示的例子，记录 ORDER_ID 的键被存储在不同的节点：
为了关联它们，需要在网络上发送数据，这样做会影响性能。
处理这个问题的一个策略，是在集群的所有节点上复制要关联的表，该策略被称为广播式关联(broadcast join)。如果对 MPP 使用相同的策略，可以想象，只能用在较小的 lookup 或维度表中。
那么当关联一个大的事实表和一个大的维度表，比如客户或产品，甚至关联两个大型事实表时，我们该怎么办?
Hadoop上的维度建模
为了解决性能问题，可以利用反规范化将大的维度表放进事实表，以保证数据是同定位的(co-located)，而对较小的维度表可以在所有节点上广播(broadcast)。
关联两个大型事实表时，可以把低粒度的表嵌套到更高粒度的表中，例如把 ORDER_ITEM 表嵌套到 ORDER 表中。高级的查询引擎，比如 Impala 或 Drill 可以让数据扁平化(flatten out)：
嵌套数据的策略很有用，类似于 Kimball 概念中用桥接表来表示维度模型中的 M:N 关系。
Hadoop和缓慢变化维
Hadoop 文件系统中的存储是不可变的，换句话说，只能插入和追加记录，不能修改数据。如果你熟悉的是关系型数据仓库，这看起来可能有点奇怪。但是从内部机制看，数据库是以类似的机制工作，在一个进程异步地更新数据文件中的数据之前，将所有变更保存在一个不可变的预写式日志(WAL- write-ahead log，Oracle中称为redo log)中。
不可变性(immutability)对维度模型有什么影响?你也许还记得维度建模课程中渐变维的概念(Slowly Changing Dimensions - SCDS)。SCDS 有选择地保存属性值变更的历史，于是可以在某个时间点上对属性值进行度量。但这不是默认的处理方式，默认情况下会用最新的值来更新维度表。那么在 Hadoop 上如何选择呢?记住!我们不能更新数据。我们可以简单地为 SCD 选择默认方式并对每一个变化进行审核(audit)。如果想运行基于当前值的报表，可以在 SCD 之上创建一个视图，让它仅仅检索到最新值，利用 Windows 函数可以很容易做到这一点。或者，可以运行一个所谓合并(Compaction)的服务，用最新的值物理地创建维度表的一个单独版本。
Hadoop的存储演化
Hadoop 平台的供应商并没有忽视这些 Hadoop 的限制，例如 Hive 就提供了满足 ACID 的事务和可更新的表。根据大量的主要公开问题以及个人经验，这个特性还没有完善到可以部署生产环境。Cloudera 采取了另外一个手段，利用 Kudu 建立了一个新的可变更存储格式，它并没有基于 HDFS，而是基于本地 OS 操作系统。它完全摆脱了 Hadoop 的限制，类似于列式 MPP 的传统存储层。通常来说，在 Impala + Kudu 这样一个 MPP 上运行 BI 和 Dashboard 的任何使用场景，会比 Hadoop 更好。不得不说，当它涉及到弹性、并发性和扩展性时，有自己的局限。当遇到这些限制时，Hadoop 和它的近亲 Spark 是解决 BI 工作负载的好选择。
判决：维度模型和星型模式过时了吗?
我们都知道，Ralph Kimball 已经退休了，但他设计原则的思想和观念仍然是有效的，也将会继续存在。即使我们不得不让它们适应新的技术和存储类型，它们仍然能够带来巨大的价值。