大数据和Hadoop时代的维度建模

正文

请到「今天看啥」查看全文

注：标准数据模型总是遵守 3NF 模式。

标准的数据建模，本身并不是为了商业智能的工作负载而设计的。太多的表会导致过多的关联，而表关联会导致性能下降，在数据分析中我们要尽力去避免这种情形发生。数据建模过程中，通过反规范化把多个相关表合并成一个表，例如前面例子里的多个表被预合并成一个 geography 表。

那么为何部分人认为维度建模已死？

一般人都认可数据建模的方式，而把维度建模当成特殊处理方式，它们都是有价值的。那为什么在大数据和 Hadoop 的时代，部分人会认为维度建模没用了？

“数据仓库之死”

首先，一些人混淆了维度建模和数据仓库。他们认为数据仓库已死，于是得出结论：维度建模也可以被丢进历史的垃圾箱。这种论点在逻辑上是连贯的，但是，数据仓库的概念远没有过时。我们总是需要集成的、可靠的数据来产生商业智能仪表盘（BI Dashboards）。

只读结构的误解

第二个常听见的争论，比如“我们遵循只读方式的结构（Schema），所以不需要对数据再进行建模了”。依我看来，这是数据分析过程中最大的误解之一。我同意起初仅转储原始数据，这时不过多考虑结构是有意义的。但是，这不应该成为不对数据进行建模的借口。只读方式的结构只是降低了下游系统的能力和责任，一些人不得不咬牙去定义数据类型。访问无模式数据转储的每一个进程都需要自己弄清楚发生了什么，而这完全是多余的。通过定义数据类型和正确的结构，可以很容易地避免这些工作。

再谈反规范化和物理模型

是否那些宣传维度建模的观点实际上已过时了? 的确有些观点比上面列出的两条更好，要理解它们需要对物理建模和 Hadoop 的工作方式有一些了解。

前面简单提到采用维度建模的原因之一，和数据的物理存储方式有关。标准数据建模中每个真实世界里的实体，有一个自己的表。我们这样做，是为了避免数据冗余和质量问题在数据中蔓延。越多的表，就需要越多的关联，这是标准建模的缺点。表关联的代价是昂贵的，特别是关联数据集中关联大量记录的时候尤其突出。当我们考虑维度建模时，会把多个表合并起来，这就是所谓的预关联或者说数据反规范化。最后的结果是，得到更少的表、更少的关联、更低的延迟和更好的查询性能。

请到「今天看啥」查看全文