大维度表的处理策略与迷你维度的应用
1. 大维度表的挑战
在数据仓库中,大量的维度属性赋予了强大的分析能力,这使得数据仓库极具价值。维度表包含超过 100 个属性的情况并不罕见,每个业务往往有两到三个主要维度会收集大量信息,这些宽维度通常围绕产品和客户的各种变体,例如公司、人员、文档、账户、合同、学生、法律、法规、地点等。
然而,大维度表也带来了一些问题:
- 数据库管理方面 :过宽的维度行可能会影响数据库管理员分配空间或指定块大小的方式。
- ETL 开发方面 :当表中有大量的类型 2 属性时,对维度的增量更新可能会成为巨大的处理瓶颈。而且,大维度表可能涉及众多缓慢变化的维度,这让开发者开始质疑“缓慢”的含义。
为了解决这些问题,许多设计师的第一反应是将大维度一分为二,让两个结果表共享相同的代理键。这种方法虽然可以限制行大小,但存在一些缺点,它不一定能解决处理瓶颈或不受控制的增长问题,可能还需要一些变通方法。
2. 随意拆分维度表
当维度行的长度让数据库管理员难以接受时,就需要重新思考维度设计了。一种常见的解决方案是将属性简单地分离到两个表中,这两个表使用相同的代理键值,并且它们之间存在一对一的关系。这样,过长的行长度就被分散到两个表中,使行大小回到数据库管理员可接受的范围。
例如,将客户表分为 customer_part1 和 customer_part2 两部分。对于任何给定的代理键,一些维度属性存储在 customer_part1 中,其余的存储在 customer_part2 中,两个表中的行一一对应。
超级会员免费看
订阅专栏 解锁全文
13

被折叠的 条评论
为什么被折叠?



