hive数仓事实表建模

1、dwd事实表

事务型快照事实表,每天一个分区,每天递增,di

周期型快照事实表,每天一个分区,每天全量,df

累积型快照事实表,每天一个分区,每天更新历史数据,每天全量,df

insert overwrite table dwd_fact_coupon_use_df partition(dt)
select
    if(new.id is null,old.id,new.id),
    if(new.coupon_id is null,old.coupon_id,new.coupon_id),
    if(new.user_id is null,old.user_id,new.user_id),
    if(new.order_id is null,old.order_id,new.order_id),
    if(new.coupon_status is null,old.coupon_status,new.coupon_status),
    if(new.get_time is null,old.get_time,new.get_time),
    if(new.using_time is null,old.using_time,new.using_time),
    if(new.used_time is null,old.used_time,new.used_time),
    date_format(if(new.get_time is null,old.get_time,new.get_time),'yyyy-MM-dd')
from
(
    select
        id,
        coupon_id,
        user_id,
        order_id,
        coupon_status,
        get_time,
        using_time,
        used_time
    from dwd_fact_coupon_use_df
    where  dt='2020-03-28'
)old
full outer join
(
    select
        id,
        coupon_id,
        user_id,
        order_id,
        coupon_status,
        get_time,
        using_time,
        used_time
    from ods_coupon_use
    where dt='2020-03-29'
)new
on old.id=new.id;

2、dws事实表

案例一:

 

create external table dws_sku_action_daycount 
(   
    sku_id string comment 'sku_id',
    order_count bigint comment '被下单次数',
    order_num bigint comment '被下单件数',
    order_amount decimal(16,2) comment '被下单金额',
    payment_count bigint  comment '被支付次数',
    payment_num bigint comment '被支付件数',
    payment_amount decimal(16,2) comment '被支付金额',
    refund_count bigint  comment '被退款次数',
    refund_num bigint comment '被退款件数',
    refund_amount  decimal(16,2) comment '被退款金额',
    cart_count bigint comment '被加入购物车次数',
    cart_num bigint comment '被加入购物车件数',
    favor_count bigint comment '被收藏次数',
    appraise_good_count bigint comment '好评数',
    appraise_mid_count bigint comment '中评数',
    appraise_bad_count bigint comment '差评数',
    appraise_default_count bigint comment '默认评价数'
) COMMENT '每日商品行为'
PARTITIONED BY (`dt` string)
stored as parquet
location '/warehouse/gmall/dws/dws_sku_action_daycount/'
tblproperties ("parquet.compression"="lzo");
with 
tmp_order as
(
    select
        sku_id,
        count(*) order_count,
        sum(sku_num) order_num,
        sum(total_amount) order_amount
    from dwd_fact_order_detail
    where dt='2020-03-29'
    group by sku_id
),
tmp_refund as
(
    select
        sku_id,
        count(*) refund_count,
        sum(refund_num) refund_num,
        sum(refund_amount) refund_amount
    from dwd_fact_order_refund_info
    where dt='2020-03-29'
    group by sku_id
),
tmp_cart as
(
    select
        sku_id,
        count(*) cart_count,
        sum(sku_num) cart_num
    from dwd_fact_cart_info
    where dt='2020-03-29'
    and date_format(create_time,'yyyy-MM-dd')='2020-03-29'
    group by sku_id
),
tmp_favor as
(
    select
        sku_id,
        count(*) favor_count
    from dwd_fact_favor_info
    where dt='2020-03-29'
    and date_format(create_time,'yyyy-MM-dd')='2020-03-29'
    group by sku_id
),
tmp_appraise as
(
select
        sku_id,
        sum(if(appraise='1201',1,0)) appraise_good_count,
        sum(if(appraise='1202',1,0)) appraise_mid_count,
        sum(if(appraise='1203',1,0)) appraise_bad_count,
        sum(if(appraise='1204',1,0)) appraise_default_count
from dwd_fact_comment_info
where dt='2020-03-29'
group by sku_id
)

 

案例二:dws表不同视角形成的不同粒度的表

<think>好的,用户问的是在大中,由事实表拼接成的宽应该放在哪一层。首先,我需要回忆一下的分层结构,通常是ODS、DWD、DWS、ADS这几层。 用户提到的是事实表的拼接,也就是做维度退化,形成宽。这一步通常是为了减少查询时的关联操作,提升查询性能。那宽应该放在哪一层呢? 首先,ODS层是原始据,不太可能在这里处理。DWD层是明细据,这里的事实表还是规范化的,可能还没有合并。DWS层是汇总层,通常会进行轻度聚合,但宽的生成可能在这里或者更上层。 不过,宽可能涉及多个维度的关联,比如星型模型转宽,这一步通常在DWS层,因为这里开始做汇总,但有时候也可能在DWT层(主题层),如果分层中有这一层的话。而ADS层是应用层,直接对接报或应用,宽也可能在这里,但需要看具体设计。 另外,Kimball的维度建模中,维度退化是在维度模型中处理,可能对应到DWD层,但实际实践中,宽可能放在DWS或ADS层,因为需要支持上层应用的高效查询。 可能需要考虑不同公司的分层习惯,有的会把宽放在DWS作为公共层,有的则放在ADS作为应用层。需要确认用户的分层结构,是否有DWSADS,以及他们的宽用途是公共汇总还是特定应用。 总结下来,通常宽生成在DWS层,作为公共汇总层,供多个应用使用。但如果是特定应用的宽,可能会放在ADS层。需要进一步确认用户的具体分层定义使用场景。</think>在大分层架构中,事实表与维度拼接生成的**宽**(宽边)通常位于**DWS层**(Data Warehouse Service,据服务层/汇总层),具体原因定位逻辑如下: --- ### 一、分层定位依据 典型的大分层结构为: 1. **ODS层**(操作据存储):存储原始据,不做清洗关联 2. **DWD层**(明细据层):对ODS据清洗、标准化,保持范式化结构 3. **DWS层**(汇总据层):进行轻度聚合、维度退化,生成宽 4. **ADS层**(应用据层):面向业务场景的高度聚合结果 --- ### 二、宽生成的核心逻辑 1. **维度退化(Denormalization)** - 将星型模型中的维度字段冗余到事实表中 - 目的:减少查询时的多JOIN操作,提升查询性能 - 示例:订单事实表 + 用户维度 → 包含用户姓名、地址的订单宽 2. **业务需求驱动** - 宽需满足高频查询的字段覆盖 - 例如:电商场景中用户行为分析宽需包含商品、店铺、用户等多维度信息 --- ### 三、分层选择的典型场景 | 分层 | 是否存放宽 | 说明 | |------|--------------|------| | DWD | ❌ | 需保持范式化结构,避免冗余 | | DWS | ✅ | 主要存放通用宽,服务于多个业务线 | | ADS | △ | 仅存放面向特定业务场景的定制化宽 | --- ### 四、最佳实践建议 1. **DWS层标准化宽** - 建议将公共维度的宽下沉到DWS层 - 优势:避免不同业务线重复开发,保证据一致性 - 示例:用户画像宽、商品信息宽 2. **ADS层特殊场景宽** - 仅在需要极高性能或特殊业务逻辑时使用 - 示例:大促实时监控宽(融合秒级更新的流量交易据) --- ### 五、技术实现示例 ```sql -- DWS层宽生成(Hive示例) CREATE TABLE dws_order_wide AS SELECT f.order_id, f.sale_amount, d1.user_name, d2.product_category, d3.city_name FROM dwd_order_fact f LEFT JOIN dim_user d1 ON f.user_id = d1.user_id LEFT JOIN dim_product d2 ON f.product_id = d2.product_id LEFT JOIN dim_region d3 ON f.region_id = d3.region_id; ``` --- **总结**:宽应优先建设在DWS层,既保证据复用性,又避免过度冗余。只有当业务有特殊性能需求或据使用场景极度垂直时,才考虑在ADS层创建定制化宽
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值