大佬教程收集整理的这篇文章主要介绍了数仓分层架构,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
把复杂问题简单化 将复杂的任务分解成多层来完成,每层只处理一个简单的任务,方便定位问题
减少重复开发 规范数据分层,通过中间层数据,能够减少极大的重复计算,增加以此计算结果的复用性
隔离原始数据 不论是数据的异常还是数据的敏感性,使真实的数据与统计数据解耦开
ods层也叫贴源层 针对HDFS上的用户行为数据和业务数据,我们如何规划处理? (1)保持数据原貌不做任何修改,起到备份数据的作用。 (2)数据采用压缩,减少磁盘存储空间(例如:原始数据100G,可以压缩到10G左右) (3)创建分区表,防止后续的全表扫描
dwd层(轻度汇总) 对ODS层数据进行清洗(去除空值,脏数据,超过极限范围的数据)、脱敏等。 DWD 层需构建维度模型,一般采用星型模型,呈现的状态一般为星座模型 维度建模一般按照以下四个步骤: 选择业务过程 → 声明粒度 → 确认维度 → 确认事实 (1)选择业务过程 在业务系统中,挑选我们感兴趣的业务线,比如下单业务,支付业务,退款业务,物流 业务,一条业务线对应一张事实表。 如果是中小公司,尽量把所有业务过程都选择。 (2)声明粒度 数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。 声明粒度意味着精确定义事实表中的一行数据表示什么,应该尽可能选择最小粒度,以 此来应各种各样的需求。 典型的粒度声明如下: 订单事实表中一行数据表示的是一个订单中的一个商品项。 支付事实表中一行数据表示的是一个支付记录。 (3)确定维度 维度的主要作用是描述业务是事实,主要表示的是“谁,何处,何时”等信息。 确定维度的原则是:后续需求中是否要分析相关维度的指标。例如,需要统计,什么时 间下的订单多,哪个地区下的订单多,哪个用户下的订单多。需要确定的维度就包括:时间 维度、地区维度、用户维度。 (4)确定事实 此处的“事实”一词,指的是业务中的度量值(次数、个数、件数、金额,可以进行累 加),例如订单金额、下单次数等。 在 DWD 层,以业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的 明细层事实表。事实表可做适当的宽表化处理。 事实表和维度表的关联比较灵活,但是为了应对更复杂的业务需求,可以将能关联上的 表尽量关联上。如何判断是否能够关联上呢?在业务表关系图中,只要两张表能通过中间表 能够关联上,就说明能关联上。
时间 | 用户 | 地区 | 商品 | 优惠券 | 活动 | 编码 | 度量值 |
---|---|---|---|---|---|---|---|
订单 | √ | √ | √ | √ | 件数/金额 | ||
订单详情 | √ | √ | √ | √ | 件数/金额 | ||
支付 | √ | √ | √ | 金额 | |||
加购 | √ | √ | √ | 件数/金额 | |||
收藏 | √ | √ | √ | 个数 | |||
评价 | √ | √ | √ | 个数 | |||
退款 | √ | √ | √ | 件数/金额 | |||
优惠券领用 | √ | √ | √ | 个数 |