[离线数仓] 总结三、Hive数仓DIM层开发

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（支付方式）只有在支付场景使用，
            这个表就可以不用创建，可以在事实表中直接使用而不用单独创建维度表（维度退化）
    字段（维度属性）：只要能