一、前言
上一篇分享博文《数据仓库专题（3）--分布式数据仓库事实表设计思考》后，陆续有各位兄弟参加大讨论，提出了各种问题，关于分布式环境下，维表和事实表设计，进行了比较深入的探讨，在此汇集整理，分享给大家。希望能有更多人参与尽力啊，共同探索分布式数据仓库数据模型的设计。
二、纪要
【活跃】北京-RTB-胖哥(1106110976) 10:21:36
分布式模式下事实表设计思考：
做大做强事实表，做小做弱维表；
【冒泡】杭州-电子病历<[email protected]> 10:23:31
能举例子说明吗？ 您这句话，我似懂非懂，但是确实在临床上又有非常多的问题存在。
【潜水】厦门-BI-锅盖(584249213) 10:25:58
胖哥，我看了你博客，这点确实不太理解。你是指只有唯一值的维度直接合并到事实表吗？
|
【潜水】bomb(4684895) 10:26:45 但是这样做会有个问题，导致事实表变的更大 |
|
【潜水】bomb(4684895) 10:27:20 我觉得比较好的方式是使用列存储数据库，列存储数据库对于聚合计算是有很大优势的 |
|
【冒泡】杭州-电子病历<[email protected]> 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等，用来扩展表的通用性，试图把所有的数据都存储到一张表 中。分布式数据仓库的设计，恰恰相反，因为单表数据规模的问题，如果要满足分析和处理的性能，合理的按照业务进行数据的分表存储。如财务相关事件、账户相关事件，单独成表。更有利于数据的计算和分析。 |
|
【冒泡】南京-电商-凌云<[email protected]> 10:38:34 列存储数据库 只是在平台层面考虑的问题，但是对于海量数据的时候，在模型上面还是要有一定的考量的 |
|
【冒泡】南京-电商-凌云<[email protected]> 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 主要是分布式列式数据库，维表不能大，大了的话，内存消费不起呢。 |
|
【冒泡】南京-电商-凌云<[email protected]> 10:46:26 维表不能太，是不是意味着维表就要做分表策略呢？ |
|
【冒泡】南京-电商-凌云<[email protected]> 10:47:36 那就是维度设计考虑的问题，维度的层次是不是要多一些 |
|
【冒泡】南京-电商-凌云<[email protected]> 10:48:03 （1）以值代键：针对键值唯一的维表，除非必要，否则不引入维表，如IP地址维表，采用IP作为维表的主键，事实表中存储IP值； |
|
【冒泡】南京-电商-凌云<[email protected]> 10:48:35 在这里考虑的主键的作用是什么？ |
|
【冒泡】南京-电商-凌云<[email protected]> 10:54:10 @北京-RTB-胖哥 是数据架构 |
|
【活跃】北京-RTB-胖哥(1106110976) 10:55:59 首先IP不重复，可以承担维表中的主键，其次，IP作为事实表重的维度FK，如果只是针对IP地址的数值统计，可以不引入IP维表 |
|
【活跃】北京-RTB-胖哥(1106110976) 10:56:07 FK值就是IP地址。 |
|
【冒泡】南京-电商-凌云<[email protected]> 10:58:27 但是如果是IP作为一个维表的话，那么主键是不是IP地址 没有关系啊，因为你在事实表中还是要引用IP维表的主键作为FK，同样可以基于IP维表的主键做数量统计的 |
|
【潜水】bomb(4684895) 11:00:19 这样的情况，事实表也就是IP的维度表，自然不再需要IP的维度表 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:00:31 不对 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:01:13 事实表中不仅包括IP，还有其他的维度信息啊 |
|
【潜水】bomb(4684895) 11:01:52 恩，我明白胖哥的意思 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:02:12 对于IP维度来讲的话，他的也是有层次的，比如国内IP，国外IP，不同电信运营商线路的IP |
|
【潜水】bomb(4684895) 11:02:53 这样的情况我认为一般不会出现，就像一个销售记录中有订单号，我们通常不会用订单号做维度 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:03:00 是不是可以把IP地址理解成一种伪度量去考量的 |
|
【潜水】bomb(4684895) 11:06:42 我认为这个时候IP（或订单号）其实就是事实表的主键了，通常这种情况下也不会对IP（或者订单号）做分析，做分析时我们会关系一类IP或者某个地域的一类IP是什么样的情况，而不会关心单个IP是什么样的情况，如果关心单个IP的情况，就是明细查询了，明细查询可以考虑用其他的方式，比如搜索引擎 |
|
【潜水】bomb(4684895) 11:08:14 个人的一点愚见，欢迎拍砖 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:09:05 IP是事实表的主键？能举例吗 |
|
【活跃】北京-RTB-胖哥(1106110976) 11:09:27 先掐着，掐明白了，就明白了。 |
|
【潜水】bomb(4684895) 11:09:40 我觉得胖哥的意思，就像我们常见到的销售订单表 |
|
【潜水】bomb(4684895) 11:09:49 我同意，胖哥 |
|
【潜水】bomb(4684895) 11:10:48 在销售订单表中，每个订单号是唯一的，就可以作为主键，这种情况下，我们通常不会再做一张订单号的维度表 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:11:18 我们在销售单中一般的考量是ID+单号 |
|
【潜水】bomb(4684895) 11:11:25 其实我们原来一个项目中干过这样的实情，结果就呵呵了…… |
|
【潜水】bomb(4684895) 11:12:02 cube处理要很长时间，后来发现用户根本不会用订单号这个维度做分析，所以把这个维度去了，就快多了 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:12:42 这个是你的事实表数据粒度的考虑 |
|
【潜水】bomb(4684895) 11:12:47 一般我在事实表中没有主键（sql server） |
|
【冒泡】南京-电商-凌云<[email protected]> 11:12:57 如果客户要用订单号做分析呢 |
|
【潜水】bomb(4684895) 11:13:07 那就悲催了…… |
|
【冒泡】南京-电商-凌云<[email protected]> 11:14:59 模型设计的时候不应该完全按照现有的数据分析需求考量 |
|
【潜水】bomb(4684895) 11:15:25 这个我同意 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:16:50 带IP或者是订单号的数据一般是粒度比较低的事实数据或者明细数据 |
|
【潜水】bomb(4684895) 11:16:53 但是对订单信息按照每个订单做分析，我认为是没有意义的，数据分析是反映批量数据的状态或趋势，对单条订单的查询是明细查询 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:17:49 对啊，所以说事实表的数据是按照维度的粒度做计算，分层的 |
|
【活跃】北京-RTB-胖哥(1106110976) 11:22:36 最细粒度的数据，有时候需要刻意的反规范设计 |
|
【活跃】北京-RTB-胖哥(1106110976) 11:22:42 也是没办法的事情。 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:27:29 对 |
|
【冒泡】南京-电商-凌云<[email protected]> 11:27:57 反规范做冗余是经常的事情 |
三、未完待续
分布式数据仓库数据存储模型设计进行中，后续会持续更新，请关注QQ群：分布式数据仓库建模 398419457。