数据仓库专题(4)-分布式数据仓库事实表设计思考---讨论精华

简介:

一、前言

  陆续有各位兄弟参加大讨论,提出了各种问题,关于分布式环境下,维表和事实表设计,进行了比较深入的探讨,在此汇集整理,分享给大家。希望能有更多人参与尽力啊,共同探索分布式数据仓库数据模型的设计。

二、纪要

【活跃】北京-RTB-胖哥(1106110976) 10:21:36 
分布式模式下事实表设计思考:
做大做强事实表,做小做弱维表;
【冒泡】杭州-电子病历<ruanjizhou@qq.com> 10:23:31 
能举例子说明吗? 您这句话,我似懂非懂,但是确实在临床上又有非常多的问题存在。
【潜水】厦门-BI-锅盖(584249213) 10:25:58 
胖哥,我看了你博客,这点确实不太理解。你是指只有唯一值的维度直接合并到事实表吗?

 

【潜水】bomb(4684895) 10:26:45

 但是这样做会有个问题,导致事实表变的更大

【潜水】bomb(4684895) 10:27:20

 我觉得比较好的方式是使用列存储数据库,列存储数据库对于聚合计算是有很大优势的

【冒泡】杭州-电子病历<ruanjizhou@qq.com> 10:31:37

 @厦门-BI-锅盖 胖哥的博客,您在哪里看的?方便发博客地址我吗?

【潜水】厦门-BI-锅盖(584249213) 10:32:43

 

现在列存储的厂家就SAP HANA,Oracle Exadata,不多而且比较贵

 

【潜水】厦门-BI-锅盖(584249213) 10:33:06

 

http://www.cnblogs.com/hadoopdev/p/4425715.html

【潜水】厦门-BI-锅盖(584249213) 10:33:26

 

分布式模式-维度建模新原则

(1)以值代键:针对键值唯一的维表,除非必要,否则不引入维表,如IP地址维表,采用IP作为维表的主键,事实表中存储IP值;

      (2)合理分表:传统关系型数据仓库存在多表整合的冲动,如上图Event事实表,各种Acount Ind,Finance Ind等,用来扩展表的通用性,试图把所有的数据都存储到一张表 中。分布式数据仓库的设计,恰恰相反,因为单表数据规模的问题,如果要满足分析和处理的性能,合理的按照业务进行数据的分表存储。如财务相关事件、账户相关事件,单独成表。更有利于数据的计算和分析。 

【冒泡】南京-电商-凌云<hds1999@qq.com> 10:38:34

 

列存储数据库 只是在平台层面考虑的问题,但是对于海量数据的时候,在模型上面还是要有一定的考量的

【冒泡】南京-电商-凌云<hds1999@qq.com> 10:41:29

 

@北京-RTB-胖哥  分布式数据仓库 在架构层面是如何设计的?

【活跃】北京-RTB-胖哥(1106110976) 10:43:13

 

架构,具体知识技术脚骨

【活跃】北京-RTB-胖哥(1106110976) 10:43:20

 架构还是数据架构

【活跃】北京-RTB-胖哥(1106110976) 10:43:24

 是两个不同的问题。

【潜水】bomb(4684895) 10:43:50

 

sql

【潜水】bomb(4684895) 10:44:00

 

sql server 也有列存储了

【活跃】北京-RTB-胖哥(1106110976) 10:44:03

 事实表不变,也大。因为海量数据情况下,单表的容积都是百亿级别的。

【活跃】北京-RTB-胖哥(1106110976) 10:44:38

 

Hive的分表,前提是你分表周期内的数据,都已经达到百亿级别的情况。

【活跃】北京-RTB-胖哥(1106110976) 10:45:13

 

主要是分布式列式数据库,维表不能大,大了的话,内存消费不起呢。

【冒泡】南京-电商-凌云<hds1999@qq.com> 10:46:26

 维表不能太,是不是意味着维表就要做分表策略呢?

【冒泡】南京-电商-凌云<hds1999@qq.com> 10:47:36

那就是维度设计考虑的问题,维度的层次是不是要多一些

【冒泡】南京-电商-凌云<hds1999@qq.com> 10:48:03

 


(1)以值代键:针对键值唯一的维表,除非必要,否则不引入维表,如IP地址维表,采用IP作为维表的主键,事实表中存储IP值;

【冒泡】南京-电商-凌云<hds1999@qq.com> 10:48:35

  在这里考虑的主键的作用是什么?

【冒泡】南京-电商-凌云<hds1999@qq.com> 10:54:10

 @北京-RTB-胖哥  是数据架构

【活跃】北京-RTB-胖哥(1106110976) 10:55:59

 首先IP不重复,可以承担维表中的主键,其次,IP作为事实表重的维度FK,如果只是针对IP地址的数值统计,可以不引入IP维表

【活跃】北京-RTB-胖哥(1106110976) 10:56:07

 FK值就是IP地址。

【冒泡】南京-电商-凌云<hds1999@qq.com> 10:58:27

但是如果是IP作为一个维表的话,那么主键是不是IP地址 没有关系啊,因为你在事实表中还是要引用IP维表的主键作为FK,同样可以基于IP维表的主键做数量统计的

【潜水】bomb(4684895) 11:00:19

 这样的情况,事实表也就是IP的维度表,自然不再需要IP的维度表

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:00:31

 不对

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:01:13

 事实表中不仅包括IP,还有其他的维度信息啊

【潜水】bomb(4684895) 11:01:52

 

恩,我明白胖哥的意思

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:02:12

对于IP维度来讲的话,他的也是有层次的,比如国内IP,国外IP,不同电信运营商线路的IP

【潜水】bomb(4684895) 11:02:53

 

这样的情况我认为一般不会出现,就像一个销售记录中有订单号,我们通常不会用订单号做维度

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:03:00

 是不是可以把IP地址理解成一种伪度量去考量的

【潜水】bomb(4684895) 11:06:42

 我认为这个时候IP(或订单号)其实就是事实表的主键了,通常这种情况下也不会对IP(或者订单号)做分析,做分析时我们会关系一类IP或者某个地域的一类IP是什么样的情况,而不会关心单个IP是什么样的情况,如果关心单个IP的情况,就是明细查询了,明细查询可以考虑用其他的方式,比如搜索引擎

【潜水】bomb(4684895) 11:08:14

个人的一点愚见,欢迎拍砖

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:09:05

 IP是事实表的主键?能举例吗

【活跃】北京-RTB-胖哥(1106110976) 11:09:27

 先掐着,掐明白了,就明白了。

 

【潜水】bomb(4684895) 11:09:40

 

我觉得胖哥的意思,就像我们常见到的销售订单表

【潜水】bomb(4684895) 11:09:49

 我同意,胖哥

【潜水】bomb(4684895) 11:10:48

 

在销售订单表中,每个订单号是唯一的,就可以作为主键,这种情况下,我们通常不会再做一张订单号的维度表

 

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:11:18

 我们在销售单中一般的考量是ID+单号

【潜水】bomb(4684895) 11:11:25

 其实我们原来一个项目中干过这样的实情,结果就呵呵了……

【潜水】bomb(4684895) 11:12:02

 cube处理要很长时间,后来发现用户根本不会用订单号这个维度做分析,所以把这个维度去了,就快多了

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:12:42

 这个是你的事实表数据粒度的考虑

【潜水】bomb(4684895) 11:12:47

 一般我在事实表中没有主键(sql server)

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:12:57

 如果客户要用订单号做分析呢

【潜水】bomb(4684895) 11:13:07

 

那就悲催了……

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:14:59

模型设计的时候不应该完全按照现有的数据分析需求考量

【潜水】bomb(4684895) 11:15:25

 

这个我同意

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:16:50

 带IP或者是订单号的数据一般是粒度比较低的事实数据或者明细数据

【潜水】bomb(4684895) 11:16:53

 但是对订单信息按照每个订单做分析,我认为是没有意义的,数据分析是反映批量数据的状态或趋势,对单条订单的查询是明细查询

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:17:49

对啊,所以说事实表的数据是按照维度的粒度做计算,分层的

【活跃】北京-RTB-胖哥(1106110976) 11:22:36

 最细粒度的数据,有时候需要刻意的反规范设计

【活跃】北京-RTB-胖哥(1106110976) 11:22:42

 也是没办法的事情。

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:27:29

 对

【冒泡】南京-电商-凌云<hds1999@qq.com> 11:27:57

 反规范做冗余是经常的事情

三、未完待续

      分布式数据仓库数据存储模型设计进行中,后续会持续更新,请关注QQ群:分布式数据仓库建模 398419457。

目录
相关文章
|
3月前
|
存储 运维 监控
云原生数据仓库使用问题之怎么创建维度表
阿里云AnalyticDB提供了全面的数据导入、查询分析、数据管理、运维监控等功能,并通过扩展功能支持与AI平台集成、跨地域复制与联邦查询等高级应用场景,为企业构建实时、高效、可扩展的数据仓库解决方案。以下是对AnalyticDB产品使用合集的概述,包括数据导入、查询分析、数据管理、运维监控、扩展功能等方面。
|
3月前
|
消息中间件
分布式篇问题之通过本地消息表实现分布式事务的最终一致性问题如何解决
分布式篇问题之通过本地消息表实现分布式事务的最终一致性问题如何解决
|
5月前
|
Cloud Native 关系型数据库 MySQL
云原生数据仓库产品使用合集之在ADB中,如何将源数据的多表(数据结构一致)汇总到一张表
阿里云AnalyticDB提供了全面的数据导入、查询分析、数据管理、运维监控等功能,并通过扩展功能支持与AI平台集成、跨地域复制与联邦查询等高级应用场景,为企业构建实时、高效、可扩展的数据仓库解决方案。以下是对AnalyticDB产品使用合集的概述,包括数据导入、查询分析、数据管理、运维监控、扩展功能等方面。
|
5月前
|
消息中间件 SQL Kafka
实时计算 Flink版产品使用合集之构建实时数据仓库时,如何操作在几分钟内一直变化的表
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
12月前
|
存储 数据挖掘 关系型数据库
数仓学习---6、数据仓库概述、 数据仓库建模概述、维度建模理论之事实表、维度建模理论之维度表
数仓学习---6、数据仓库概述、 数据仓库建模概述、维度建模理论之事实表、维度建模理论之维度表
|
5月前
|
存储 数据采集 数据挖掘
【软件设计师备考 专题 】数据仓库和分布式数据库基础知识
【软件设计师备考 专题 】数据仓库和分布式数据库基础知识
250 0
|
5月前
|
数据挖掘 数据库
离线数仓6.0--- 数据仓库 ER模型-范式理论,维度模型、维度建模理论之事实表、维度建模理论之维度表
离线数仓6.0--- 数据仓库 ER模型-范式理论,维度模型、维度建模理论之事实表、维度建模理论之维度表
232 0
|
SQL 存储 HIVE
数据仓库系列--维度表技术
数据仓库系列--维度表技术
135 0
|
SQL 存储 分布式计算
「大数据系列」:Apache Hive 分布式数据仓库项目介绍
「大数据系列」:Apache Hive 分布式数据仓库项目介绍
|
数据采集 监控 Android开发
网站流量日志分析--数仓设计--本项目中数据仓库的设计(星型模型)|学习笔记
快速学习网站流量日志分析--数仓设计--本项目中数据仓库的设计(星型模型)
403 0
网站流量日志分析--数仓设计--本项目中数据仓库的设计(星型模型)|学习笔记

热门文章

最新文章

下一篇
无影云桌面