1 数仓的分层及建模理论

1.1 数据仓库的用途

• 整合公司所有业务数据，建立统一的数据中心
• 产生业务报表，用于作出决策
• 为网站运营提供运营上的数据支持
• 可以作为各个业务的数据源，形成业务数据互相反馈的良性循环
• 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果
• 开发数据产品，直接或间接地为公司盈利

1.2 数仓运行架构图

1.3 数据集市与数仓的区别

数据集市（Data Market）：是一种微型的数据仓库，它通常有更少的数据，更少的主题区域，以及更少的历史数据，因此是部门级的，一般只能为某个局部范围内的管理人员服务。

数据仓库（Data Warehouse）：数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段。

1.4 数仓分层

1.4.1 分层原因

• 把复杂问题简单化：将复杂的任务分解成多层来完成，每一层只处理简单任务，方便定位问题。
• 减少重复开发：规范数据分层，通过中间层数据，能够减少大量的重复计算，增加一次计算结果的复用性。
• 隔离原始数据：不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。

1.4.2 基本分层模型

ODS（数据源层，原始数据） – ETL --> DWD（数据明细层） – hive sql --> DWS（数据汇总） – sqoop --> ADS（数据应用：报表、用户画像）

1.5 数据仓库分层

1.5.1 数仓分层概述

在阿里巴巴的数据体系中，建议将数据仓库分为三层，自下而上为：

数据引入层ODS（Operation Data Store）：存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到MaxCompute的职责，同时记录基础数据的历史变化。

数据公共层CDM（Common Data Model，又称通用数据模型层）:包括DIM维度表、DWD和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标，根据目前业务特点，暂时只建立DWD层

• 明细粒度事实层（DWD）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。

• 数据中间层：DWM（Data WareHouse Middle）该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。

• 公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。

• 公共维度层（DIM）：基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。

• 数据应用层ADS（Application Data Service）：存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。

中英文及简写：

数据引入层（ODS，Operation Data Store）

数据公共层（CDM，Common Data Model）

公共维度层（DIM，Dimension）

数仓明细层（DWD，Data Warehouse Detail）

数据汇总层（DWS，Data Warehouse Service）

数据应用层（ADS，Application Data Service）

1.5.2 各层级用途

**1) 数据引入层（ODS，Operation Data Store）：**将原始数据几乎无处理的存放在数据仓库系统，结构上与源系统基本保持一致，是数据仓库的数据准备区。原始数据，主要是埋点数据（日志数据）和业务操作数据（binlong），数据源主要是 Mysql、HDFS、Kafka 等

2) 数据公共层（CDM，Common Data Model，又称通用数据模型层），包括 DIM 维度表、DWD 和 DWS，由ODS 层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。这一层里又包括三层：

• 公共维度层（DIM）：

1. 基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
2. 主要使用 MySQL、Hbase、Redis 三种存储引擎，对于维表数据比较少的情况可以使用 MySQL，对于单条数据大小比较小，查询 QPS 比较高的情况，可以使用 Redis 存储，降低机器内存资源占用，对于数据量比较大，对维表数据变化不是特别敏感的场景，可以使用 HBase 存储。

• 数仓明细层（DWD）：

1. ODS 层经过清洗，落地这一层，一般是最细粒度。
2. 以业务过程作为建模驱动，**基于每个具体的业务过程特点，构建最细粒度的明细层事实表。**可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。

• 数据汇总层（DWS）：

1. 对 DWD 层的轻微聚合，对一些可累加的指标进行聚合，增加复用性。
2. 以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。

3) 数据应用层（ADS，Application Data Service）：存放数据产品个性化的统计指标数据。根据 CDM 与 ODS 层加工生成。

1.6 开发规范

1.6.1 命名规则

1) ods 层

增量数据： {project_name}.ods_{数据来源}_{源系统表名}_delta
全量数据： {project_name}.ods_{数据来源}_{源系统表名}
 
数据来源说明：
01 -> hdfs 数据
02 -> mysql 数据
03 -> redis 数据
04 -> mongodb 数据
05 -> tidb 数据
 
举例如下：
行为日志表： ods_01_action_log
用户表： ods_02_user

2) dim 层

公共区域维表： {project_name}.dim_pub_{自定义命名标签}
具体业务维表： {project_name}.dim_{业务缩写}_{自定义命名标签}
 
举例如下：
公共区域维表： dim_pub_area
公共时间维表： dim_pub_date
A公司电商板块的商品全量表： dim_asale_itm

3) dwd 层

多个业务公共表： {project_name}.dwd_pub_{自定义命名标签}
具体业务数据增量表： {project_name}.dwd_{业务缩写}_{自定义命名标签}_di
具体业务数据全量表： {project_name}.dwd_{业务缩写}_{自定义命名标签}_df
 
举例如下：
交易会员信息事实表：ods_asale_trd_mbr_di
交易商品信息事实表：dwd_asale_trd_itm_di
交易订单信息事实表：dwd_asale_trd_ord_di

4) dws 层

多个业务公共表： {project_name}.dws_pub_{自定义命名标签}
具体业务最近一天汇总事实表： {project_name}.dws_{业务缩写}_{自定义命名标签}_1d
具体业务最近N天汇总事实表： {project_name}.dws_{业务缩写}_{自定义命名标签}_nd
具体业务历史截至当天汇总表： {project_name}.dws_{业务缩写}_{自定义命名标签}_td
具体业务小时汇总表： {project_name}.dws_{业务缩写}_{自定义命名标签}_hh
 
举例如下：
dws_asale_trd_byr_subpay_1d（A电商公司买家粒度交易分阶段付款一日汇总事实表）
dws_asale_trd_byr_subpay_td（A电商公司买家粒度分阶段付款截至当日汇总表）
dws_asale_trd_byr_cod_nd（A电商公司买家粒度货到付款交易汇总事实表）
dws_asale_itm_slr_td（A电商公司卖家粒度商品截至当日存量汇总表）
dws_asale_itm_slr_hh（A电商公司卖家粒度商品小时汇总表）---维度为小时
dws_asale_itm_slr_mm（A电商公司卖家粒度商品分钟汇总表）---维度为分钟

5) ads 层

{project_name}.ads_{业务缩写}_{自定义命名标签}
 
举例如下：
订单统计表： ads_nshop_order_form
订单支付统计： ads_nshop_orderpay_form

1.7 分层的误区

数仓层内部的划分不是为了分层而分层，分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题。

业界较为通行的做法将整个数仓层（DW）又划分成了 dwd、dwb、dws、dim、mid 等等很多层。然而我们却始终说不清楚这几层之间清晰的界限是什么，或者说我们能说清楚它们之间的界限，复杂的业务场景却令我们无法真正落地执行。

所以数据分层这块一般来说 ODS、DWD、DWS 这三层是最基础的：

至于DW层如何进行切分，是根据具体的业务需求和公司场景自己去定义，一般来说需要：

• 分层是解决数据流向和快速支撑业务的目的；
• 必须按照主题域和业务域进行贯穿；
• 层级之间不可逆向依赖。
• 如果依赖ODS层数据可以完成数据支撑，那么业务方直接使用落地层这也有利于快速、低成本地进行一些数据方面的探索和尝试。
• 确定分层规范后，后续最好都遵循这个架构，约定成俗即可；
• 血缘关系、数据依赖、数据字典、数据命名规范等配套先行；

DW 内的分层没有最正确的，只有最适合你的。

1.8 宽表的误区

在数仓层开始引入了宽表。所谓宽表，迄今为止并没有一个明确的定义。通常做法是把很多的维度、事实上卷（roll-up）或者下钻（drill-down）之后关联到某一个事实表中，形成一张既包含了大量维度又包含了相关事实的表。

宽表的使用，有其一定的便利性。使用方不需要再去考虑跟维度表的关联，也不需要了解维度表和事实表是什么东西。
但是随着业务的增长，我们始终无法预见性地设计和定义宽表究竟该冗余多少维度，也无法清晰地定义出宽表冗余维度的底线在哪里。

一个可能存在的情况是，为了满足使用上的需求，要不断地将维表中已经存在的列增加到宽表中。这直接导致了宽表的表结构频繁发生变动。

目前我们所采用的做法是：

• 根据主题域和业务域，将某个业务的所有节点梳理清楚；
• 将关键节点的数据作为事实表依据，然后横向扩充其他事实表上卷数据（包含一些统计指标），同时纵向的添加该节点上一些主键对应的维度；
• 宽表的涉及不依赖具体的业务需求而是根据整体业务线相匹配；
• 尽量用维度建模代替宽表；

为什么说尽量用维度建模代替宽表，就算字段和数据会冗余，维度建模的方式也会表全量数据的宽表模式较好，原因：

• 维度建模是以某一个既定的事实为依据，既然是事实表，那么这块的业务如果不变动的情况下，事实表的粒度基本不会改变；
• 事实表和维度表解耦，维度表的变更事实表基本不会影响，结果表也只需要回刷一下数据流程即可；
• 新增维度完全可以按照星型模型或者雪花模型动态添加新维度；
• 维度模型可以作为宽表的基础，一旦确定全部的数据流程，可以通过维度模型再生成对应宽表进行快速的业务支撑；

2 维度表和事实表

• Hive_维度表和事实表

2.1 维度表

维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等。

维表的特征：

• 维表的范围很宽（具有多个属性、列比较多）
• 跟事实表相比，行数相对较小：通常< 10万条
• 内容相对固定：编码表

时间维度表：

日期ID	day of week	day of year	季度	节假日
2020-01-01	2	1	1	元旦
2020-01-02	3	2	1	无
2020-01-03	4	3	1	无
2020-01-04	5	4	1	无
2020-01-05	6	5	1	无

2.2 事实表

事实表：每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据，如现金登记事务所产生的数据，事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索引，该索引包含作为外键的相关性纬度表的主键，而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息，也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。

包含在事实数据表中的“度量值”有两中：一种是可以累计的度量值，另一种是非累计的度量值。最有用的度量值是可累计的度量值，其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息，例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表，单汇总结果一般是没有意义的，例如，在一座大厦的不同位置测量温度时，如果将大厦中所有不同位置的温度累加是没有意义的，但是求平均值是有意义的。

一般来说，一个事实数据表都要和一个或多个纬度表相关联，用户在利用事实数据表创建多维数据集时，可以使用一个或多个维度表。

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等），例如，2020年5月21日，宋宋老师在京东花了250块钱买了一瓶海狗人参丸。维度表：时间、用户、商品、商家。事实表：250块钱、一瓶

每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键，通常具有两个和两个以上的外键。

事实表的特征：

• 非常的大
• 内容相对的窄：列数较少（主要是外键id和度量值）
• 经常发生变化，每天会新增加很多。

1）事务型事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

2）周期型快照事实表

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。

例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。

3）累积型快照事实表

累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

订单id	用户id	下单时间	打包时间	发货时间	签收时间	订单金额
		3-8	3-8	3-9	3-10

3 数仓建模规划

3.1 ODS层

针对HDFS上的用户行为数据和业务数据，我们如何规划处理？

（1）保持数据原貌不做任何修改，起到备份数据的作用。

（2）数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）

（3）创建分区表，防止后续的全表扫描

3.2 DIM层和DWD层

DIM层DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

维度建模一般按照以下四个步骤：

选择业务过程→声明粒度→确认维度→确认事实

（1）选择业务过程

在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。

（2）声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。

声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。

典型的粒度声明如下：

订单事实表中一行数据表示的是一个订单中的一个商品项。

支付事实表中一行数据表示的是一个支付记录。

（3）确定维度

维度的主要作用是描述业务事实，主要表示的是“谁，何处，何时”等信息。

确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。

（4）确定事实

此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。

在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。

	时间	用户	地区	商品	优惠券	活动	度量值
订单	√	√	√				运费/优惠金额/原始金额/最终金额
订单详情	√	√	√	√	√	√	件数/优惠金额/原始金额/最终金额
支付	√	√	√				支付金额
加购	√	√		√			件数/金额
收藏	√	√		√			次数
评价	√	√		√			次数
退单	√	√	√	√			件数/金额
退款	√	√	√	√			件数/金额
优惠券领用	√	√			√		次数

至此，数据仓库的维度建模已经完毕，DWD层是以业务过程为驱动。

DWS层、DWT层和ADS层都是以需求为驱动，和维度建模已经没有关系了。

DWS和DWT都是建宽表，按照主题去建表。主题相当于观察问题的角度。对应着维度表。

3.3 DWS层与DWT层

DWS层和DWT层统称宽表层，这两层的设计思想大致相同，通过以下案例进行阐述。

1）问题引出：两个需求，统计每个省份订单的个数、统计每个省份订单的总金额

2）处理办法：都是将省份表和订单表进行join，group by省份，然后计算。同样数据被计算了两次，实际上类似的场景还会更多。

那怎么设计能避免重复计算呢？

针对上述场景，可以设计一张地区宽表，其主键为地区ID，字段包含为：下单次数、下单金额、支付次数、支付金额等。上述所有指标都统一进行计算，并将结果保存在该宽表中，这样就能有效避免数据的重复计算。

3）总结：

（１）需要建哪些宽表：以维度为基准。

（２）宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。

（３）DWS和DWT层的区别：DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等，DWT层存放的是所有主题对象的累积行为，例如每个地区最近７天（１５天、３０天、６０天）的下单次数、下单金额等。

3.4 ADS层

对电商系统各大主题指标分别进行分析。

4 Hive数仓实战

1 ODS层的构建

1.1 ODS层功能与职责

1）保持数据原貌不做任何修改，起到备份数据的作用。

2）数据采用LZO压缩，减少磁盘存储空间。100G数据可以压缩到10G以内。

3）创建分区表，防止后续的全表扫描，在企业开发中大量使用分区表。

4）创建外部表。在企业开发中，除了自己用的临时表，创建内部表外，绝大多数场景都是创建外部表。

1.2 ODS层搭建–数据导入–全量覆盖

不需要分区，每次同步都是先删后写，直接覆盖。

适用于数据不会有任何新增和变化的情况。

比如区域字典表、时间、性别等维度数据，不会变更或很少会有变更，可以只保留最新值。

这里以t_district区域字典表为例，进行讲解。

DROP TABLE if exists yp_ods.t_district;
CREATE TABLE yp_ods.t_district
(
    `id` string COMMENT '主键ID',
    `code` string COMMENT '区域编码',
    `name` string COMMENT '区域名称',
    `pid`  int COMMENT '父级ID',
    `alias` string COMMENT '别名'
)
comment '区域字典表'
row format delimited fields terminated by '\t' 
stored as orc tblproperties ('orc.compress'='ZLIB');

sqoop数据同步

因为表采用了ORC格式存储，因此使用sqoop导入数据的时候需要使用HCatalog API。

-- Sqoop导入之前可以先原表的数据进行清空
truncate table yp_ods.t_district;

方式1-使用1个maptask进行导入
sqoop import  \
--connect 'jdbc:mysql://192.168.88.80:3306/yipin?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true' \
--username root \
--password 123456 \
--query "select * from t_district where \$CONDITIONS" \
--hcatalog-database yp_ods \
--hcatalog-table t_district \
--m 1

1.3 ODS层搭建–数据导入–增量同步

每天新增一个日期分区，同步并存储当天的新增数据。

比如登录日志表、访问日志表、交易记录表、商品评价表，订单评价表等。

这里以t_user_login登录日志表为例，进行讲解。

DROP TABLE if exists yp_ods.t_user_login;
CREATE TABLE if not exists yp_ods.t_user_login(
   id string,
   login_user string,
   login_type string COMMENT '登录类型（登陆时使用）',
   client_id string COMMENT '推送标示id(登录、第三方登录、注册、支付回调、给用户推送消息时使用)',
   login_time string,
   login_ip string,
   logout_time string
) 
COMMENT '用户登录记录表'
partitioned by (dt string)
row format delimited fields terminated by '\t'
stored as orc tblproperties ('orc.compress' = 'ZLIB');

sqoop数据同步

• 首次(全量)

1、不管什么模式，首次都是全量同步；再次循环同步的时候，可以自己通过where条件来控制同步数据的范围；

2、${TD_DATE}表示分区日期，正常来说应该是今天的前一天，因为正常情况下，都是过夜里12点，干前一天活，那么数据的分区字段应该属于前一天。

3、这里为了演示，${TD_DATE}先写死。

sqoop import "-Dorg.apache.sqoop.splitter.allow_text_splitter=true" \
--connect 'jdbc:mysql://192.168.88.80:3306/yipin?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true' \
--username root \
--password 123456 \
--query "select *,'2022-11-18' as dt from t_user_login where  \$CONDITIONS" \
--hcatalog-database yp_ods \
--hcatalog-table t_user_login \
--m 1

• 循环（增量同步）

#!/bin/bash
date -s '2022-11-20'  #模拟导入增量19号的数据

#你认为现在是2022-11-20，昨天是2022-11-19
TD_DATE=`date -d '1 days ago' "+%Y-%m-%d"`
/usr/bin/sqoop import "-Dorg.apache.sqoop.splitter.allow_text_splitter=true" \
--connect 'jdbc:mysql://192.168.88.80:3306/yipin?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true' \
--username root \
--password 123456 \
--query "select *, '${TD_DATE}' as dt from t_user_login where 1=1 and (login_time between '${TD_DATE} 00:00:00' and 
'${TD_DATE} 23:59:59') and  \$CONDITIONS" \
--hcatalog-database yp_ods \
--hcatalog-table t_user_login \
-m 1

1.4 ODS层搭建–数据导入–新增和更新同步

每天新增一个日期分区，同步并存储当天的新增和更新数据。

适用于既有新增又有更新的数据，比如用户表、订单表、商品表等。

这里以t_store店铺表为例，进行讲解。

drop table if exists yp_ods.t_store;
CREATE TABLE yp_ods.t_store
(
    `id`                 string COMMENT '主键',
    `user_id`            string,
    `store_avatar`       string COMMENT '店铺头像',
    `address_info`       string COMMENT '店铺详细地址',
    `name`               string COMMENT '店铺名称',
    `store_phone`        string COMMENT '联系电话',
    `province_id`        INT COMMENT '店铺所在省份ID',
    `city_id`            INT COMMENT '店铺所在城市ID',
    `area_id`            INT COMMENT '店铺所在县ID',
    `mb_title_img`       string COMMENT '手机店铺 页头背景图',
    `store_description` string COMMENT '店铺描述',
    `notice`             string COMMENT '店铺公告',
    `is_pay_bond`        TINYINT COMMENT '是否有交过保证金 1：是0：否',
    `trade_area_id`      string COMMENT '归属商圈ID',
    `delivery_method`    TINYINT COMMENT '配送方式  1 ：自提 ；3 ：自提加配送均可; 2 : 商家配送',
    `origin_price`       DECIMAL,
    `free_price`         DECIMAL,
    `store_type`         INT COMMENT '店铺类型 22天街网店 23实体店 24直营店铺 33会员专区店',
    `store_label`        string COMMENT '店铺logo',
    `search_key`         string COMMENT '店铺搜索关键字',
    `end_time`           string COMMENT '营业结束时间',
    `start_time`         string COMMENT '营业开始时间',
    `operating_status`   TINYINT COMMENT '营业状态  0 ：未营业 ；1 ：正在营业',
    `create_user`        string,
    `create_time`        string,
    `update_user`        string,
    `update_time`        string,
    `is_valid`           TINYINT COMMENT '0关闭，1开启，3店铺申请中',
    `state`              string COMMENT '可使用的支付类型:MONEY金钱支付;CASHCOUPON现金券支付',
    `idCard`             string COMMENT '身份证',
    `deposit_amount`     DECIMAL(11,2) COMMENT '商圈认购费用总额',
    `delivery_config_id` string COMMENT '配送配置表关联ID',
    `aip_user_id`        string COMMENT '通联支付标识ID',
    `search_name`        string COMMENT '模糊搜索名称字段:名称_+真实名称',
    `automatic_order`    TINYINT COMMENT '是否开启自动接单功能 1：是  0 ：否',
    `is_primary`         TINYINT COMMENT '是否是总店 1: 是 2: 不是',
    `parent_store_id`    string COMMENT '父级店铺的id，只有当is_primary类型为2时有效'
)
comment '店铺表'
partitioned by (dt string) 
row format delimited fields terminated by '\t' 
stored as orc tblproperties ('orc.compress'='ZLIB');

sqoop数据同步

实现新增及更新同步的关键是，表中有两个跟时间相关的字段：

create_time 创建时间 一旦生成 不再修改

update_time 更新时间 数据变化时间修改

自己通过where条件来控制同步数据的范围。

• 首次

sqoop import "-Dorg.apache.sqoop.splitter.allow_text_splitter=true" \
--connect 'jdbc:mysql://192.168.88.80:3306/yipin?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true' \
--username root \
--password 123456 \
--query "select *,'2022-11-18' as dt  from t_store where 1=1 and \$CONDITIONS" \
--hcatalog-database yp_ods \
--hcatalog-table t_store \
-m 1

• 循环

#!/bin/bash
date -s '2022-11-20'
TD_DATE=`date -d '1 days ago' "+%Y-%m-%d"`
/usr/bin/sqoop import "-Dorg.apache.sqoop.splitter.allow_text_splitter=true" \
--connect 'jdbc:mysql://192.168.88.80:3306/yipin?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true' \
--username root \
--password 123456 \
--query "select *, '${TD_DATE}' as dt from t_store where 1=1 and ((create_time between '${TD_DATE} 00:00:00' and '${TD_DATE} 23:59:59') or (update_time between '${TD_DATE} 00:00:00' and '${TD_DATE} 23:59:59')) and  \$CONDITIONS" \
--hcatalog-database yp_ods \
--hcatalog-table t_store \
-m 1

最终所有从MySql导入的的ODS层表格

1.5 总结

这里介绍了HIve数仓新零售项目ODS层的构建，主要三种方式.

1. 全量覆盖
2. 增量同步
3. 新增和更新同步

2 DWD层的构建

2.1 DWD层功能与职责

针对ods层表中的数据进行清洗，参考数据清洗规则，按照实际情况对数据进行清洗。

注意：如果清洗规则使用SQL可以实现，那么就使用SQL实现数据清洗，如果清洗的规则使用SQL实现起来非常麻烦，或者使用SQL压根无法实现，此时就可以考虑需要使用MapReduce代码或者Spark代码对数据进行清洗了。

• dwd层中文叫做明细数据层。

• 主要功能：

  • 数据清洗转换、提供质量保证；
  • 区分事实、维度。

• 表名规范

  dwd.fact_xxxxxx

  订单主副表、订单结算、订单组、订单退款、订单商品快照、购物车、店铺收藏等

  dwd.dim_yyyyyy

  用户、区域、时间、店铺、商圈、地址信息、商品、商品分类、品牌等

2.2 DWD层搭建–地域维度表–全量覆盖导入

DROP TABLE if EXISTS yp_dwd.dim_district;
CREATE TABLE yp_dwd.dim_district(
  id string COMMENT '主键ID', 
  code string COMMENT '区域编码', 
  name string COMMENT '区域名称', 
  pid string COMMENT '父级ID', 
  alias string COMMENT '别名')
COMMENT '区域字典表'
row format delimited fields terminated by '\t'
stored as orc 
tblproperties ('orc.compress' = 'SNAPPY');

全量覆盖操作

INSERT overwrite TABLE yp_dwd.dim_district
select * from yp_ods.t_district
WHERE code IS NOT NULL AND name IS NOT NULL;

2.3 DWD层搭建–订单评价表–增量导入

#解释：每一次增量的数据都创建一个分区进行报错
DROP TABLE if EXISTS yp_dwd.fact_goods_evaluation;
CREATE TABLE yp_dwd.fact_goods_evaluation(
  id string, 
  user_id string COMMENT '评论人id', 
  store_id string COMMENT '店铺id', 
  order_id string COMMENT '订单id', 
  geval_scores int COMMENT '综合评分', 
  geval_scores_speed int COMMENT '送货速度评分0-5分(配送评分)', 
  geval_scores_service int COMMENT '服务评分0-5分', 
  geval_isanony tinyint COMMENT '0-匿名评价，1-非匿名', 
  create_user string, 
  create_time string, 
  update_user string, 
  update_time string, 
  is_valid tinyint COMMENT '0 ：失效，1 ：开启')
COMMENT '订单评价表'
partitioned by (dt string)
row format delimited fields terminated by '\t'
stored as orc 
tblproperties ('orc.compress' = 'SNAPPY');

• 第一次导入（全量）

-- 从ods层进行加载
INSERT overwrite TABLE yp_dwd.fact_goods_evaluation PARTITION(dt)
select 
   id,
   user_id,
   store_id,
   order_id,
   geval_scores,
   geval_scores_speed,
   geval_scores_service,
   geval_isanony,
   create_user,
   create_time,
   update_user,
   update_time,
   is_valid,
   substr(create_time, 1, 10) as dt  
from yp_ods.t_goods_evaluation;

• 增量导入操作

INSERT into TABLE yp_dwd.fact_goods_evaluation PARTITION(dt)
select 
   id,
   user_id,
   store_id,
   order_id,
   geval_scores,
   geval_scores_speed,
   geval_scores_service,
   geval_isanony,
   create_user,
   create_time,
   update_user,
   update_time,
   is_valid,
   substr(create_time, 1, 10) as dt
from yp_ods.t_goods_evaluation
where dt='2022-11-19';

2.4 DWD层搭建–订单事实表–循环与拉链导入

拉链表是面试重点，如果面数仓相关岗位，面试官特别爱问。

DROP TABLE if EXISTS yp_dwd.fact_shop_order;
CREATE TABLE if not exists yp_dwd.fact_shop_order(  -- 拉链表
  id string COMMENT '根据一定规则生成的订单编号',
  order_num string COMMENT '订单序号',
  buyer_id string COMMENT '买家的userId',
  store_id string COMMENT '店铺的id',
  order_from string COMMENT '此字段可以转换 1.安卓\; 2.ios\; 3.小程序H5 \; 4.PC',
  order_state int COMMENT '订单状态:1.已下单\; 2.已付款, 3. 已确认 \;4.配送\; 5.已完成\; 6.退款\;7.已取消',
  create_date string COMMENT '下单时间',
  finnshed_time timestamp COMMENT '订单完成时间,当配送员点击确认送达时,进行更新订单完成时间,后期需要根据订单完成时间,进行自动收货以及自动评价',
  is_settlement tinyint COMMENT '是否结算\;0.待结算订单\; 1.已结算订单\;',
  is_delete tinyint COMMENT '订单评价的状态:0.未删除\;  1.已删除\;(默认0)',
  evaluation_state tinyint COMMENT '订单评价的状态:0.未评价\;  1.已评价\;(默认0)',
  way string COMMENT '取货方式:SELF自提\;SHOP店铺负责配送',
  is_stock_up int COMMENT '是否需要备货 0：不需要    1：需要    2:平台确认备货  3:已完成备货 4平台已经将货物送至店铺 ',
  create_user string,
  create_time string,
  update_user string,
  update_time string,
  is_valid tinyint COMMENT '是否有效  0: false\; 1: true\;   订单是否有效的标志',
  end_date string COMMENT '拉链结束日期'
) COMMENT '订单表'
partitioned by (start_date string)
row format delimited fields terminated by '\t'
stored as orc tblproperties ('orc.compress' = 'SNAPPY');

• 首次导入
• 如果是动态分区插入，别忘了相关参数
• 如果ods层中表的字段有枚举类型，可以在ETL到dwd的过程中使用case when语句转换。

INSERT overwrite TABLE yp_dwd.fact_shop_order PARTITION (start_date)
SELECT 
   id,
   order_num,
   buyer_id,
   store_id,
   case order_from 
      when 1
      then 'android'
      when 2
      then 'ios'
      when 3
      then 'miniapp'
      when 4
      then 'pcweb'
      else 'other'
      end
      as order_from,
   order_state,
   create_date,
   finnshed_time,
   is_settlement,
   is_delete,
   evaluation_state,
   way,
   is_stock_up,
   create_user,
   create_time,
   update_user,
   update_time,
   is_valid,
   '9999-99-99' end_date,
    dt as start_date
FROM yp_ods.t_shop_order;

• 拉链操作

insert overwrite table yp_dwd.fact_shop_order partition (start_date)
select *
from (
   --1、ods表的新分区数据(有新增和更新的数据)
         select id,
                order_num,
                buyer_id,
                store_id,
                case order_from
                    when 1
                        then 'android'
                    when 2
                        then 'ios'
                    when 3
                        then 'miniapp'
                    when 4
                        then 'pcweb'
                    else 'other'
                    end
                    as order_from,
                order_state,
                create_date,
                finnshed_time,
                is_settlement,
                is_delete,
                evaluation_state,
                way,
                is_stock_up,
                create_user,
                create_time,
                update_user,
                update_time,
                is_valid,
                '9999-99-99' end_date,
               '2022-11-19' as start_date
         from yp_ods.t_shop_order
         where dt='2022-11-19'

         union all

    -- 2、历史拉链表数据，并根据up_id判断更新end_time有效期
         select
             fso.id,
             fso.order_num,
             fso.buyer_id,
             fso.store_id,
             fso.order_from,
             fso.order_state,
             fso.create_date,
             fso.finnshed_time,
             fso.is_settlement,
             fso.is_delete,
             fso.evaluation_state,
             fso.way,
             fso.is_stock_up,
             fso.create_user,
             fso.create_time,
             fso.update_user,
             fso.update_time,
             fso.is_valid,
             --3、更新end_time：如果没有匹配到变更数据，或者当前已经是无效的历史数据，则保留原始end_time过期时间；否则变更end_time时间为前天（昨天之前有效）
             if (tso.id is not null and fso.end_date='9999-99-99',date_add(tso.dt, -1), fso.end_date) end_time,
             fso.start_date
         from yp_dwd.fact_shop_order fso left join (select * from yp_ods.t_shop_order where dt='2022-11-19') tso
         on fso.id=tso.id
     ) his
order by his.id, start_date;

---

2.5 总结

这里介绍了HIve数仓新零售项目DWD层的构建，主要三种方式：

1. 全量覆盖导入
2. 增量导入
3. 循环与拉链导入

3 DWS层的构建

• HIve数仓新零售项目DWS层的构建(Grouping sets)模型_陈万君Allen的博客-CSDN博客
• HIve数仓新零售项目DWS层的构建(Full join)模型_陈万君Allen的博客-CSDN博客

3.1 DWS层功能与职责

DWS层: 基于主题统计分析, 此层一般是用于最细粒度的统计操作

3.1.1 维度组合:

• 日期

• 日期+城市

• 日期+城市+商圈

• 日期+城市+商圈+店铺

• 日期+品牌

• 日期+大类

• 日期+大类+中类

• 日期+大类+中列+小类

3.1.2 指标:

销售收入、平台收入、配送成交额、小程序成交额、安卓APP成交额、苹果APP成交额、PC商城成交额、订单量、参 评单量、差评单量、配送单量、退款单量、小程序订单量、安卓APP订单量、苹果APP订单量、PC商城订单量。

3.2 销售主题统计宽表

最终要求通过group_type来判断指标来自哪个维度的聚合

3.3 总结

(Grouping sets)模型，Grouping sets模型适合于多维度，多指标的稀疏宽表的构建，可以把不同的维度放在同一张宽表中，方便以后查询。同时在建立聚合字段的时候，可以根据每个维度进行定制聚合的操作。比较灵活。

(Full join)模型，主要针对低维度，多指标的情况。Full join模型的主要思路为

1. 用with语句将dwb_order_detail表关键字段提取
2. 先统计6张结果小表数据
3. 将6张结果小表数据进行full join
4. 从full join的结果表中进行数据的抽取
5. 去重，将日期和goods_id重复的数据去掉