数仓--DW--Hadoop数仓实践Case-10-维度合并

维度合并概述

在多维数据仓库建模时，如果维度属性中的两个组存在多对多关系时，应该将它们建模为不同的维度，并在事实表中构建针对这些维度的不同外键。另一种处理多对多关系的方法是，使用桥接表，将一个多对多关系转化为两个一对多关系。事实表通过引用桥接表的一个代理键，同时关联到多个维度值。这样做的目的是消除数据冗余，保证数据一致性。
多对多关系的常见示例包括：每个学生登记了许多课程，每个课程有许多学生；一名医生有许多患者，每个患者有许多医生；一个产品或服务属于多个类别，每个类别包含多个产品或服务等。从结构上来说，创建多对多维度关系的方式类似于在关系数据模型中创建多对多关系。
然而，有时会遇到一些情况，更适合将两个维度合并到单一维度中，而不是在事实表中引用两个不同维度的外键，或使用桥接表。例如，在一个飞行服务数据分析系统中，业务用户希望分析乘客购买机票的服务级别。此外，用户还希望方便地按照是否发生服务的升级或降级情况过滤并构建报表。最初的想法可能是建立两个角色扮演维度，一个表示最初购买的机票服务等级，另外一个表示实际乘机时的服务级别。可能还希望建立第三个维度表示升降级情况，否则BI应用需要包括用于区分众多升降级情况的逻辑，例如经济舱升级到商务舱，经济舱升级到头等舱，商务舱升级到头等舱等。但是，面对这个特殊场景，在维度表中只有用于区分头等舱、商务舱、经济舱的三行记录。同样，升降级标准维度表也仅包含三行，分别对应升级、降级、无变化。因为维度的基数太小，而且不会进行更新，所以可以选择将这些维度合并成单一服务级别变动维度，如下图所示：

服务级别维度变动.PNG
不同维度的笛卡尔积将产生9行的维度表。在合并维度中还可以包含描述购买服务级别和乘坐服务级别之间的关系，例如表中的服务等级变动标识。应该将此类服务级别变动维度当成杂项维度。在此案例研究中，属性是紧密关联的。其他的航空事实表，例如，有效座位或机票购买，不可避免地需要引用包含3行的一致性机票等级维度表。

维度合并的另一种情况

还有一种合并维度的情况，就是本来属性相同的维度，因为某种原因被设计成重复的维度属性。例如，在销售订单示例中，随着数据仓库中维度的增加，我们会发现有些通用的数据存在于多个维度中。例如，客户维度的客户地址相关信息、送货地址相关信息里都有邮编、城市和省份。下面说明如何把客户维度里的两个邮编相关信息合并到一个新的维度中。

修改数据仓库模式

为了合并维度，需要改变数据仓库模式。下图显示了修改后的模式。新增了一个source.source_zip_code_dim邮编信息维度表， dw.sale_order_fact事实表的结构也做了相应的修改。注意图中只显示了与邮编维度相关的表。

维度合并.PNG
source.source_zip_code_dim维度表与销售订单事实表相关联。这个关系替换了事实表与客户维度的关系。 dw.sale_order_fact表需要两个关系，一个关联到客户地址邮编；另一个关联到送货地址邮编，相应地增加了两个外键字段。再次强调，这里所说的外键是逻辑上的， Hive没有物理外键约束。
修改脚本

-- 创建source.source_zip_code_dim
create table 
    source.source_zip_code_dim
(
    zip_code_key int comment 'zip_code_key'
    zip_code int comment 'zip_code',
    zip_city varchar(50) comment 'zip_city',
    zip_province varchar(50) comment 'zip_province',
    zip_valid_from date comment 'zip_valid_from',
    zip_valid_to date comment 'zip_valid_to',
    zip_indicator string comment 'zip_indicator',
    zip_version int comment 'zip_version'
) comment 'source_zip_code_dim'
clustered by (zip_code_key) into 8 buckets
stored as 
orc tblproperties ('transactional'='true');

-- 将source.source_consumer_dim中的邮编信息导入到source.source_zip_code_dim中
insert into table
    source.source_zip_code_dim
select 
    row_number() over(order by t1.consumer_zip_code),
    consumer_zip_code,
    consumer_city,
    consumer_province,
    '1900-01-01',
    '9999-12-31',
    'Current',
    1
from
    (select 
        distinct consumer_zip_code,consumer_city, consumer_province
    from 
        source.source_consumer_dim
    where 
        consumer_zip_code is not null
    union
    select 
        distinct consumer_shipping_zip_code as consumer_zip_code ,consumer_shipping_city as consumer_city ,consumer_shipping_province as consumer_province
    from 
        source.source_consumer_dim
    where
        consumer_zip_code is not null
    ) t1;

语句说明：执行上面的语句初始装载邮编相关数据。初始数据是从客户维度表中来的，这只是为了演示数据装载的过程。客户的邮编信息很可能覆盖不到所有邮编，所以更好的方法是装载一个完整的邮编信息表。由于客户地址和送货地址可能存在交叉的情况，因此使用union联合两个查询。注意这里不能使用union all，因为需要去除重复的数据。送货地址的三个字段是在"维度表技术-列增加"节后加的，在此之前数据的送货地址为空，邮编维度表中不能含有NULL值，所以要加上where shipping_zip_code is not null过滤条件去除邮编信息为NULL的数据行。

source_zip_code角色扮演

基于邮编维度表创建客户邮编和送货邮编视图，分别用作两个地理信息的角色扮演维度
脚本如下：

create view 
    consumer_zip_code_dim
(
    consumer_zip_code_key,consumer_zip_code,consumer_city,consumer_province,consumer_valid_from,consumer_valid_to,consumer_indicator,consumer_version
)
as select
    zip_code_key,
    zip_code,
    zip_city,
    zip_province,
    zip_valid_from,
    zip_valid_to,
    zip_indicator,
    zip_version
from
    source.source_zip_code_dim
;
create view 
    shipping_zip_code_dim
(
    shipping_zip_code_key,shipping_zip_code,shipping_city,shipping_province,shipping_valid_from,shipping_valid_to,shipping_indicator,shipping_version
)
as select
    zip_code_key,
    zip_code,
    zip_city,
    zip_province,
    zip_valid_from,
    zip_valid_to,
    zip_indicator,
    zip_version
from
    source.source_zip_code_dim
;

修改销售订单事实表

数据迁移

-- 修改订单事实表
alter table dw.sale_order_fact rename to dw.sale_order_fact_old;
-- 创建数仓模型修改后的表
-- 创建新表
create table 
    dw.sale_order_fact
(
    order_number int comment 'order_number',
    customer_sk int comment 'customer surrogate key',
    customer_zip_code_sk int comment 'customer zip surrogate key',
    shipping_zip_code_sk int comment 'shipping zip surrogate key',
    product_sk int comment 'product surrogate key',
    sale_order_atrribute_sk int comment 'sale_order_atrribute_sk',
    order_date_sk string comment 'date surrogate key',
    request_delivery_date_sk int comment 'request_delivery_date_sk',
    order_amount decimal (10 , 2 ) comment'order amount',
    order_quantity int comment 'order_quantity'
)
clustered by (order_number)
into 8 buckets
stored as orc tblproperties('transactional'='true');

以上语句先将销售订单表改名以保存现有数据，然后新建一个销售订单事实表，增加客户邮编代理键和送货邮编代理键，引用两个邮编信息角色扮演维度。
将数据插入新建的结构表中

-- 将数据插入到新的结构表，并引入代理键
insert into 
    dw.sale_order_fact
select 
    t1.order_number，
    t1.customer_sk,
    t2.customer_zip_code_sk,
    t3.shipping_zip_code_sk,
    t1.product_sk,
    t1.sale_order_atrribute_sk,
    t1.order_date_sk,
    t1.request_delivery_date_sk,
    t1.order_amount,
    t1.order_quantity
from 
    dw.sale_order_fact_old t1
left join
    (
    select 
        a.order_number as order_number,
        c.consumer_zip_code_key  as customer_zip_code_sk
    from
        dw.sale_order_fact_old a,
        source.source_consumer_dim b,
        consumer_zip_code_dim c
    where
        a.customer_sk=b.consumer_key
    and
        b.consumer_zip_code = c.consumer_zip_code
    ) t2
on
    t1.order_number=t2.order_number
left join
    (
    select 
        a.order_number as order_number,
        c.shipping_zip_code_key  as shipping_zip_code_sk
    from
        dw.sale_order_fact_old a,
        source.source_consumer_dim b,
        shipping_zip_code_dim c
    where
        a.customer_sk=b.consumer_key
    and
        b.shipping_zip_code = c.shipping_zip_code
    ) t3
on
    t1.order_number=t3.order_number;

语句说明：上面这条语句有些复杂。它是把数据备份表dw.sale_order_fact_old中的数据装载回销售订单事实表，同时需要关联两个邮编角色维度视图，查询出两个代理键，装载到事实表中。注意老的事实表与新的邮编维度表是通过客户维度表关联起来的，所以在子查询中需要三表连接，然后用两个左外连接查询出所有原事实表数据，装载到新的增加了邮编维度代理键的事实表中。

修改source_consumer_dim

"腾笼换鸟"策略

-- 修改source.source_consumer_dim表
alter table source.source_consumer_dim rename to source.source_consumer_dim_old;
-- 创建新表
create table if not exists source.source_consumer_dim(
consumer_key int  comment "代理键",
consumer_number varchar(50) comment "顾客编号",
consumer_name varchar(50) comment "顾客名称",
consumer_street_address varchar(50) comment "顾客地址",
consumer_shipping_address varchar(50) comment '顾客送货地址',
consumer_valid_from date comment "有效期开始日期",
consumer_valid_to date comment "有效期结束日期",
consumer_indicator varchar(50) comment "状态指示器",
consumer_version int comment "顾客变化版本号"
)comment "客户维度表"
clustered by (consumer_key) into
8 buckets
stored as
orc tblproperties ('transactional'='true')
;
-- 插入数据
insert into 
    source.source_consumer_dim
select 
    consumer_key,
    consumer_number,
    consumer_name,
    consumer_street_address,
    consumer_shipping_address,
    consumer_valid_from,
    consumer_valid_to,
    consumer_version
from 
    source.source_consumer_dim_old 
;
-- 删除旧结构表
drop table source.source_consumer_dim_old;

修改定期脚本

定期装载脚本有三个地方的修改：
（1）删除客户维度装载里所有邮编信息相关的列，因为客户维度里不再有客户邮编和送货邮编相关信息。
（2）在事实表中引用客户邮编视图和送货邮编视图中的代理键。
（3）修改pa_customer_dim(维度子集)装载，因为需要从销售订单事实表的customer_zip_code_sk获取客户邮编。
脚本略。按照前面的套路进行修改即可。

脚本需要注意两个地方。装载事实表数据时，除了关联两个邮编维度视图外，还要关联过渡区的ods.ods_customer表。这是因为要取得邮编维度代理键，必须连接邮编代码字段，而邮编代码已经从客户维度表中删除，只有在源数据的客户表中保留。第二个改变是PA子维度的装载。州代码已经从客户维度表删除，被放到了新的邮编维度表中，而客户维度和邮编维度并没有直接关系，它们是通过事实表的客户代理键和邮编代理键产生联系的，因此必须关联事实表、客户维度表、邮编维度表三个表才能取出PA子维度数据。这也就是把PA子维度的装载放到了事实表装载之后的原因。

数仓--DW--Hadoop数仓实践Case-10-维度合并

维度合并概述

维度合并的另一种情况

修改数据仓库模式

source_zip_code角色扮演

修改销售订单事实表

修改source_consumer_dim

修改定期脚本

你可能感兴趣的:(数仓--DW--Hadoop数仓实践Case-10-维度合并)