加入收藏 | 设为首页 | 会员中心 | 我要投稿 | RSS
您当前的位置:首页 > 大数据 > 大数据培训

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

时间:2017-11-06 17:55:12  来源:互联网  作者:光环大数据

  维度建模已死?

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

为什么需要为数据建模?

有一个常见的误区,数据建模的目的是用ER图来设计物理数据库,实际上远不仅如此。数据建模代表了企业业务流程的复杂度,记录了重要的业务规则和概念,并有助于规范企业的关键术语。它清晰地阐述、协助企业揭示商业过程中模糊的想法和歧义。此外,可以使用数据模型与其他利益相关者进行有效沟通。没有蓝图,不可能建造一个房子或桥梁。所以,没有数据模型这样一个蓝图,为什么要建立一个数据应用,比如数据仓库呢?

为什么需要维度建模?

维度建模是数据建模的一种特殊方法。维度建模有两个同义词,数据集市和星型结构。星型结构是为了更好地进行数据分析,参考下面图示的维度模型,可以有一个很直观的理解。通过它可以立即知道如何通过客户、产品、时间对订单进行分割,如何通过度量的聚集和比较对订单业务过程进行绩效评估。

维度建模最关键的一点,是要定义事务性业务过程中的最低粒度是什么。如果切割或钻入数据,到叶级就不能再往下钻取。从另一个角度看,星型结构中的最低粒度,即事实和维度之间没有进行任何聚集的关联。

数据建模和维度建模

标准数据建模的任务,是消除重复和冗余的数据。当数据发生变化时,我们只需在一个地方修改它,这有助于保证数据的质量,避免了不同地方的数据不同步。参考下面图示的模型,它包含了代表地理概念的几张表。在规范化模型中,每个实体有一个独立的表,数据建模只有一张表:geography。在这张表中,city会重复出现很多次。而对于每个city,如果country改变了名字,就不得不在很多地方进行更新。

只读结构的误解

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

再谈反规范化和物理模型

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

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

可参与领英上相关的讨论。

彻底反规范化

为什么不把反规范化做到彻底?去掉所有的表关联只保留一张表?的确,这样做可以不需要对任何表进行关联,但是可以想象到,它会带来一些负面影响。首先,它需要更多的存储,因为要存储大量的冗余数据。随着数据分析的列式存储格式的出现,这一点现在不那么令人担忧了。反规范化最大的问题是,每次属性值发生变化,就不得不在很多地方进行更新,可能是几千甚至几百万次更新。一个解决办法是在晚上对模型进行全量重载,通常这比增量更新要更快、更容易。列式数据库通常采用这种方法,首先将要做的更新存储在内存中,然后异步地写入磁盘。

来顶一下
返回首页
返回首页
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
在线客服
推荐资讯
相关文章
    无相关信息
栏目更新