hive数据仓库表设计之（矮宽表+高窄表）

昨天面对某客户域做表关联的时候发现了。

有两张相同内容的主表。但是表的设计结构并不相同：

（每个领域都有主表，每次往这个领域（库）添加新表的时候一般都会join 主表，从而有唯一的主键id）

这两个表提供了这个领域的主键（id）.

在这个

+------------+------------+----------+--+
| col_name | data_type | comment |
+------------+------------+----------+--+
| id 　　　　 | int | |
| name　　 | string | |
| phone　　 | string | |
| gender　　 | string | |
| cardno　　| string | |
| age　　　　| string | |
| school　　 | string | |
| quora　　　 | int | |

..

...

..

目测有60个字段这是一张宽表.
+------------+------------+----------+--+

+------------+------------+----------+--+
| col_name | data_type | comment |
+------------+------------+----------+--+
| id 　　　　 | int | |
| value1　　| string | |
| type1　　| string | |
| value2　　| string | |
| type2　　| string | |
| age　　　　| string | |
| school　　 | string | |
| quora　　　 | int | |

目测有不到10个字段
+------------+------------+----------+--+

这是一张窄表

select type1,type2 from thistable group by type1,typ2;

发现类型数据有14种类左右

这样就相当于把第一个宽表的数据（可能剔除了不重要的字段）然后完全放开，行数暴增。

==============================================================================

我讲一下怎么用设计性能原理还要留给大家去分析：

每次都要从其他表抽取数据关联这个表id(唯一主键)，比如这个第三方表名字叫第三方客户信息 没有id这列（毕竟id列是我们在自己的系统自己生成的），

只有用户名和手机号+（第三方提供的字段（比如一周洗几次澡）），我们用name+ phone去作为join on的条件关联主表窄表，得到新的有主键的表。

select id ,max(a.字段) from 第三方表 a

join

(select id,value1 as phone,value2 as name from 主表窄表 where type1=‘MOBILE_PHONE’  and type2='NAME' group by id,value1,value2) b

on a.phone=b.phone and a.name=b.name

group by id.

note:上面的group by 的作用主要是为了去重。

但是为什么这样设计？这又是对内存和计算效率（时间）之间的权衡

应该是减少对内存的需求。因为join关联必定要生成一个中间表。如果是宽表内存太大，但是窄表牺牲了关联效率。毕竟行数倍增原来十多倍。关于join的原理请看我另一份博客。

年前和项目老大聊了一会。他设计这个报表。感觉大佬的想法很nice。