维度建模已逝世?

在答复这个问题之前，让我们回头来看看什么是所谓的维度数据建模。

Hadoop 平台的供给商并没有忽视这些 Hadoop 的限制，例如 Hive 就供给了知足 ACID 的事务和可更新的表。根据大年夜量的重要公开问题以及小我经验，这个特点还没有完美到可以安排临盆情况。Cloudera 采取了别的一个手段，应用 Kudu 建立了一个新的可变革存储格局，它并没有基于 HDFS，而是基于本地 OS 操作体系。它完全摆脱了 Hadoop 的限制，类似于列式 MPP 的传统存储层。平日来说，在 Impala + Kudu 如许一个 MPP 上运行 BI 和 Dashboard 的任何应用处景，会比 Hadoop 更好。不得不说，当它涉及到弹性、并发性和扩大性时，有本身的局限。当碰到这些限制时，Hadoop 和它的近亲 Spark 是解决 BI 工作负载的浩揭捉?择。

有一个常见的误区，数据建模的目标是用 ER 图来设计物理数据库，实际上远不仅如斯。数据建模代表了企业营业流程的复杂度，记录了重要的营业规矩和概念，并有助于规范企业的关键术语。它清楚地阐述、协助企业揭示贸易过程中模糊的设法主意和歧义。此外，可以应用数据模型与其他好处相干者进行有效沟通。没有蓝图，弗成能建造一个房子或桥梁。所以，没稀有据模型如许一个蓝图，为什么要建立一个数据应用，比如数据仓库呢?

为什么须要维度建模?

维度建模是数据建模的一种特别办法。维度建模有两个同义词，数据集市和星型构造。星型构造是为了更好地进行数据分析，参考下面图示的维度模型，可以有一个很直不雅的懂得。经由过程它可以急速知道若何经由过程客户、产品、时光对订单进行瓜分，若何经由过程度量的集合和比较对订单营业过程进行绩效评估。

维度建模最关键的一点，是要定义事务性营业过程中的最低粒度是什么。如不雅切割或钻入数据，到叶级就不克不及再往下钻取。大年夜另一个角度看，星型构造中的最低粒度，即事实和维度之间没有进行任何集合的接洽关系。

数据建模和维度建模

标准数据建模的义务，是清除反复和冗余的数据。当数据产生变更时，我们只需在一个处所修改它，这有助于包管数据的质量，避免了不合处所的数据不合步。参考下面图示的模型，它包含了代表地舆概念的几张表。在规范化模型中，每个实体有一个自力的表，数据建模只有一张表：geography。在这张表中，city 会反复竽暌箍现很多次。而对于每个 city，如不雅 country 改变了名字，就不得不在很多处所进行更新。

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

标准的数据建模，本身并不是为了贸易智能的工作负载而设计的。太多的表会导致过多的接洽关系，而表接洽关系会导致机能降低，在数据分析中我们要尽力去避免这种情况产生。数据建模过程中，经由过程反规范化把多个相干表归并成一个表，例如前面例子里的多个表被预归并成一个 geography 表。

那么为何部分人认为维度建模已逝世?

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

“数据仓库之逝世”

为什么不把反规范化做到彻底?去掉落所有的表接洽关系只保存一张表?切实其实，如许做可以不须要对任何表进行接洽关系，然则可以想象到，它会带来一些负面影响。起首，它须要更多的存储，因为要存储大年夜量的冗余数据。跟着数据分析的列式存储格局的出现，这一点如今不那么令人担心了。反规范化最大年夜的问题是，每次属性值产生变更，就不得不在很多处所进行更新，可能是几千甚至几百万次更新。一个解决办法是在晚上对模型进行全量重载，平日这比增量更新要更快、更轻易。列式数据库平日采取这种办法，起首将要做的更新存储在内存中，然后异步地写入磁盘。

起首，一些人混淆了维度建模和数据仓库。他们认为数据仓库已逝世，于是得出结论：维度建模也可以被丢进汗青的垃圾箱。这种论点在逻辑上是连贯的，然则，数据仓库的概念远没有过时。我们老是须要集成的、靠得住的数据来产生贸易智能仪表盘(BI Dashboards)。

只读构造的误会

第二个常听见的┞幅论，比如“我们遵守只读方法的构造(Schema)，所以不须要对数据再进行建模了”。依我看来，这是数据分析过程中最大年夜的误会之一。我赞成起先仅转储原始数据，这时不过多推敲构造是有意义的。然则，这不该该成为纰谬数据进行建模的饰辞。只读方法的构造只是降低了下流体系的才能和义务，一些人不得不咬牙去定义数据类型。拜访无模式数据转储的每一个过程都须要本身弄清跋扈产生了什么，而这美满是多余的。经由过程定义数据类型和精确的构造，可以很轻易地避免这些工作。

再谈反规范化和物理模型

是否那些宣传维度建模的不雅点实际上已过时了?切实其实有些不雅点比膳绫擎列出的两条更好，要懂得它们须要对物理建模和 Hadoop 的工作方法有一些懂得。

前面简单提到采取维度建模的原因之一，和数据的物理存储方法有关。标准数据建模中每个真实世界里的实体，有一个本身的表。我们如许做，是为了避免数据冗余和质量问题在数据中伸展。越多的表，就须要越多的接洽关系，这是标准建模的缺点。表接洽关系的价值是昂贵的，特别是接洽关系数据集中接洽关系大年夜量记录的时刻尤其凸起。当我们推敲维度建模时，会把多个表归并起来，这就是所谓的预接洽关系或者说数据反规范化。最后的结不雅是，获得更少的表、更少的接洽关系、更低的延迟和更好的萌芽机能。

　　推荐阅读

　　MySQL order by原理以及优化？这篇来给你逐步解析

沙龙晃荡 | 去哪儿、陌陌、ThoughtWorks在主动化运维中的实践！10.28不见不散！ 一 简介偏向于营业的 (MySQL)DBA 或者营业的开辟者来说，order by 排序是一个常见的营业功能，将结不雅根据>>>详细阅读

本文标题：大数据和Hadoop时代的维度建模和Kimball数据集市

地址：http://www.17bianji.com/lsqh/38203.html

 1/2    1