数据仓库——数仓分层

时间:2024-10-03 07:23:23

数仓分层

    • 一.分层的作用
    • 二、ODS (opreational data store)
    • 三、DWD(data warehouse detail)
        • 1.概览
        • 2.步骤
        • 4.具体需要做的事情
        • 5.举例
    • 四、DIM
        • 1.概念
        • 2.举例
    • 五、DWS(data warehouse service)
        • 1.概念
        • 2.举例
    • 六、DM(data market)
        • 1.概念
        • 2.举例
    • 七、APP/ADS
        • 1.概念
        • 2.举例

一.分层的作用

  • 数仓分层的目的是:逐层解耦,减少重复计算,降低烟囱式开发。越到底层,越接近业务发生的记录,越到上层,越接近业务目标。具体如下:
    • 清晰数据结构:每一个数据分层都有它的作用域和职责,在使用表的时候能更方便地定位和理解,实现业务数据解耦
    • 减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算
    • 统一数据口径:通过数据分层,提供统一的数据出口,统一对外输出的数据口径
    • 复杂问题简单化:将一个复杂的任务分解成多个步骤来完成,每一层解决特定的问题

二、ODS (opreational data store)

  • 存放未经过处理的原始数据至数据仓库系统,结构上与源系统保持一致,是数据仓库的数据准备区。
  • 作用
    • ①保持数据原貌不做任何修改,起到备份数据的作用
    • ②数据采用压缩,减少磁盘存储空间(如:原始数据100G,可以压缩到10G左右)
    • ③创建分区表,防止后续的全表扫描

三、DWD(data warehouse detail)

1.概览
  • DWD层是以业务过程为驱动,基于每个具体的业务过程特点,构建最细粒度的明细层事实表。可以结合企业的数据使用特点,将明细事实表的某些重要维度属性字段做适当冗余,即宽表化处理。同时,为了提高数据明细层的易用性,该层会采用一些维度退化手法,将维度退化至事实表中,减少事实表和维表的关联,在该层也会做一部分的数据聚合,将相同主题的数据汇集到一张表中,提高数据的可用性。
2.步骤
  • DWD层需构建维度模型,一般采用星型模型,呈现的状态一般为星座模型。 维度建模一般按照以下四个步骤: 选择业务过程→声明粒度→确认维度→确认事实

  • ① 选择业务过程

    在业务系统中,挑选我们感兴趣的业务线,比如下单业务,支付业务,退款业务,物流业务,一条业务线对应一张事实表。 如果是中小公司,尽量把所有业务过程都选择。 如果是大公司(1000多张表),选择和需求相关的业务线。

  • ② 声明粒度

    数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。 声明粒度意味着精确定义事实表中的一行数据表示什么,应该尽可能选择最小粒度,以此来应各种各样的需求。 典型的粒度声明如下: 订单当中的每个商品项作为下单事实表中的一行,粒度为每次。 每周的订单次数作为一行,粒度为每周。 每月的订单次数作为一行,粒度为每月。 如果在DWD层粒度就是每周或者每月,那么后续就没有办法统计细粒度的指标了。所以建议采用最小粒度

  • ③ 确定维度

    维度的主要作用是描述业务是事实,主要表示的是**“谁,何处,何时”**等信息。 确定维度的原则是:后续需求中是否要分析相关维度的指标。例如,需要统计,什么时间下的订单多,哪个地区下的订单多,哪个用户下的订单多。需要确定的维度就包括:时间维度、地区维度、用户维度。 维度表:需要根据维度建模中的星型模型原则进行维度退化。

  • ④ 确定事实

    此处的“事实”一词,指的是业务中的度量值(次数、个数、件数、金额,可以进行累加),例如订单金额、下单次数等。 在DWD层,以业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。 事实表和维度表的关联比较灵活,但是为了应对更复杂的业务需求,可以将能关联上的表尽量关联上。至此,数据仓库的维度建模已经完毕。

4.具体需要做的事情
  • ①:数据清洗:去除空值、过滤核心字段无意义的数据,(比如订单表中订单id为null,支付表中支付id为空)
  • 维度退化:对业务数据传过来的表进行维度退化和降维。(商品一级二级三级、省市县、年月日)
  • 压缩:snnapy压缩
  • 存储:parquet列式存储
5.举例
  • 1.打车业务订单表dwd_order
    • ①关联表的表:关联订单支付表order_payment,扩展支付相关字段。关联地区维度表,扩展 国家,城市等地区字段。
    • ②重要指标:订单ID,乘客ID,司机ID,起点经度,起点纬度,终点经度,终点纬度,订单持续时间,订单距离,起步价,订单价格,接单时间,订单完成时间,创建时间。
    • ③重要操作: 1.关联少量紧密联系的表,扩充字段。2.修改字段格式: 时间字段统一转为日期格式、id 变成 order_id(即业务线id)。3.轻量的简单计算:计算这一单接驾时长、应答时长、行驶距离,打标签;判断是否接单,是否完单,是否是强派单等等 0 / 1 指标。
  • 2.短视频业务 播放记录表play_table
  • ①关联vid的视频信息,vuid,长短视频、正片非正片
  • ②重要指标: uid,vid, cid,seqnum,ztid,开始播放时间, 结束播放时间,播放时长、是否完播
  • ③重要操作 :join密切相关的表,播放表关联播放详情表; 字段格式统一,修改时间格式,时间转日期; 轻量计算

四、DIM

1.概念
  • 根据维度建模中的星型模型思想,将维度进行退化。例如下图所示:地区表和省份表退化为地区维度表,商品表、品类表、spu表、商品三级分类、商品二级分类、商品一级分类表退化为商品维度表,活动信息表和活动规则表退化为活动维度表。
  • 公共维度层(DIM):基于维度建模理念思想,建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。
  • 公共维度层的表通常也被称为逻辑维度表,维度和维度逻辑表通常一一对应。
2.举例
  • 1.司机表 dim_driver
    • ①关联的表:司机扩展表driver_extend,扩展司机的补充信息。
    • ②重要指标:司机id、手机号、车牌号、姓名、性别、注册时间等等
    • ③重要操作:用自己前两天的数据,关联自己昨天一天新增的的数据,去更新整个司机维度表的数据。因为司机表比较大(尤其是乘客表更大),如果每天全量采集,采集的压力会很大,每天增量采集,然后用前天的数据,关联昨天新增的数据,得到新的全量数据。(这种方式是处理缓慢变化维的每天全量快照)
  • 2.视频信息表
    vid,vidname vid时长、版本号、uid、appid、
    > 缓慢变化维的处理
    第一种处理方式 :重写维度值。采用此种方式,不保留历史数据,始终取最新数据。
    第二种处理方式:插人新的维度行。采用此种方式,保留历史数据,维度值变化前的事实和过去的维度值关联,维度值变化后的事实和当前的维度值关联。(历史拉链存储是指利用维度模型中缓慢变化维的第二种处理方式。这种处理方式是通过新增两个时间戳字段(sta rt_dt end_dt ),将所有以天为粒度的变更数据都记录下来)
    第三种处理方式:添加维度列。采用第二种处理方式不能将变化前后记录的事实归一为变化前的维度或者归一为变化后的维度。针对此问题,采用第三种处理方式,保留历史数据,可以使用任何一个属性列。
    ###############################
    对于选择哪种方式处理缓慢变化维,并没有 个完全正确的答案,可以根据业务需求来进行选择。
    在阿里巴巴数据仓库实践中,处理缓慢变化维的方法是采用快照方式。数据仓库的计算周期一般是每天 次,基于此周期,处理维度变化的方式就是每天保留一份全量快照数据。比如商品维度,每天保留一份全量商品快照数据。任意一天的事实均可以获取到当天的商品信息 ,也可以获取到最新的商品信息,通过限定日期,采用自然键进行关联即可。此方法既有优,也有弊端。
    优点主要有以下两点:1.简单而有效,开发和维护成本低。2.使用方便,理解性好。数据使用方只需要限定日期,即可获取到当天的快照数据。任意一天的事实快照和维度快照通过维度的自然键进行关联即可。
    弊端主要体现在存储的极大浪费上
    --------------------------------------------------------------------------- <<阿里巴巴大数据实践.pdf>> p172

五、DWS(data warehouse service)

1.概念
  • DWS层会在DWD层的数据基础上,对数据做横向的连接,纵向轻度的聚合操作,生成一系列的中间表,提升公共指标的复用性,减少重复加工。统计各个主题对象的当天行为,DWS层的宽表字段,是站在不同维度的视角去看事实表,重点关注事实表的度量值,通过与之关联的事实表,获得不同的事实表的度量值。
  • 构建公共粒度的汇总指标事实表,以宽表化手段物理化模型。构建命名规范、口径一致的统计指标,为上层提供公共指标,建立汇总宽表、明细事实表
2.举例
  • 1.司机表dws_driver
    • ①关联的表: 司机维度表dim_driver,扩展司机维度信息。订单表,拓展司机接单信息。算法司机表,拓展司机派单、接单信息。
    • ②重要的字段: dws是每个司机当天的轻度聚合统计:司机id,城市id,业务线id, 完单时长,在线时长、接单数、推送订单次数、完单数、gmv、首单信息、末单信息等等。
    • ③重要操作:横向的连接,纵向轻度的聚合操作(明细大宽表)
      -2 视频播放表:dws_play
    • ①关联播放维度、曝光的dws表、算法、推荐表,召回信息,推荐信息
    • ②重要字段:dws是每一个视频当天或者当前小时的轻度的聚合:vid,播放时长、播放次数、曝光次数、召唤次数、推荐次数、完播次数、有效爆光次数、有效完播次数

六、DM(data market)

1.概念
  • 数据集市,按照主题进行汇总,按照业务划分,如流量、订单、用户等,生成字段比较多的宽表。以分析的主题对象为建模驱动,基于上层的应用和产品的指标需求,构建主题对象的全量宽表。DM层主题宽表都记录什么字段?每个维度关联的不同事实表度量值以及首次、末次时间、累积至今的度量值、累积某个时间段的度量值
2.举例
  • 1.司机订单表dm_driver
    • ①关联的表:dwm_driver为基础,深度聚合统计。
    • ②重要指标:统计确定维度的当天司机度量值(如业务线product_id,城市city_id等等,也可以cube的全部维度):注册司机数、审核通过司机数、接单司机数、完单司机数、成功被播单司机数、完单时长、司机空闲时长、完单司机在线时长。
      2 - 视频播放表dm_play
    • ① 关联的表: 以dwm_play为基础的深度聚合
    • ② 重要指标: vid推荐总次数、召回总次数、播放总次数、播放总人数、播放总时长

七、APP/ADS

1.概念
  • 数据应用层:针对大主题指标分别进行分析,根据业务具体需求,做对应的统计分析指标。
2.举例
  • 1.app_driver
    • ①重要指标: 根据维度,给出度量值。时间维度不再只能是天,可能是 周 月 年等。度量值也可能不再针对司机主题,可能会有乘客、订单、支付等等主题融合在一起。如:完单司机数、完单司机gmv,应答司机数、人均应答司机数、司机到手收入、订单数、完单数
  • 2.app_play
    • 人均播放时长、ctr、utr、人均播放次数、人均有有效播放次数等等。