马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?立即注册
x
5.9 数仓开发之DIM层
DIM层设计要点:
(1)DIM层的设计依据是维度建模理论,该层存储维度模子的维度表。
(2)DIM层的数据存储格式为orc列式存储+snappy压缩。
(3)DIM层表名的命名规范为dim_表名_全量表大概拉链表标识(full/zip)。
- -- 数仓开发之DIM层
- -- DIM层设计要点:
- -- (1)DIM层的设计依据是维度建模理论,该层存储维度模型的维度表。
- -- (2)DIM层的数据存储格式为orc列式存储+snappy压缩。
- -- (3)DIM层表名的命名规范为dim_表名_全量表或者拉链表标识(full/zip)。
- -- DIM层
- -- Dimension:维度
- /*
- 所谓维度就是分析数据的角度,维度层保存的表其实就是分析数据的角度表
- - 性别
- - 年龄
- - 品牌
- - 品类
- - 地区
- - 省份
- 维度层保存维度表,建模理论应该遵循维度建模理论:
- 维度层中的维度表,主要用于统计分析,数据存储方式应该选择列式存储:orc(hive)
- 数据的压缩效率应该越高越好(时间短),选择:snappy
- 维度表的数据源:
- ODS层的数据为整个数据仓库做准备(MySQL业务数据库的数据,日志服务器的日志文件按照同构的方式存放到ods层),
- 但是ods层的数据比较杂乱无章,遵循的是ER模型,ER模型的表很多,没有中心点,数据表很多,在统计分析的时候就需要关联很多表,
- 需要对杂乱无章的数据进行加工,让其方便用于分析计算。
- 维度层的表有同样的问题,需要将ODS层的数据进行加工处理。
- 维度表命名规范:
- 分层标记(dim_)_维度名称_全量(full)/拉链(zip)
- 全量:维度的全部数据 -- 状态数据为了避免数据出现问题,最好的方法是每年都保存一份全部数据。
- 绝大多数的维度表都是全量表,特殊情况采用拉链表。
- 为什么要保留全量数据?-- 案例:去年双11各个品牌的销量排名前10名
- select
- b.tm,
- sum(a.amount) amount
- from t_order a
- join t_sku b on a.skuid=b.id
- where dt = '2022-11-11'
- group by b.tm
- order by amount desc limit 10;
- 这里存在一个问题,在t_sku 商品信息表中,不会保存已经下架的商品,t_sku 只会存储当前已有的商品信息,
- 假设刚好去年销量很好的商品今年已经下架了,这个时候在t_sku 表中是查不出来的。因此sku有状态的数据每天存一份。
- 建模理论:
- - ER模型
- - 维度模型
- 维度(状态)表
- 事实(行为)表
- 维度表:
- 表:维度(表),一个维度就是一张表。
- -- 从实践来讲,一般会将有关联性的维度设置为一张表,不同的维度就是这张表的(维度)字段。
- -- 比如:t_order,t_sex,t_age
- 三表join才能从性别和年龄维度分析订单,三表join的效率会比较低,所以不能这样设计表。
- 性别和年龄有关联可以在一张表中:
- t_order,t_user(sex, age) 这样只需要两表关联就可以实现上述需求。
- t_order,t_sku(tm, category) 订单和商品表关联,可以从品牌和品类去分析订单。
- -- 维度表的维度字段,关键就看维度之间有没有关联,有关联的放在一张表,没关联的分开建表。
- -- 如果维度特别简单,特别独立,只在特殊场合使用,
- 比如payment_type(支付方式)只有在支付场景使用,
- 这个表就可以不用创建,可以在事实表中直接使用而不用单独创建维度表(维度退化)
- 字段(维度属性):只要能
复制代码 免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |