Hive之数仓的分层及建模理论（3）

开发规范

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

2 数据来源介绍

1) 业务数据

业务数据往往产生于事务型过程处理，所以一般存储在关系型数据库中，如 mysql、oracle。

业务数据源： 用户基本信息、商品分类信息、商品信息、店铺信息、订单数据、订单支付信息、活动信息、物流信息等

2) 埋点日志

埋点日志相对业务数据是用于数据分析、挖掘需求，一般以日志形式存储于日志文件中，随后通过采集落地分布式存储介质中如 hdfs、hbase。

用户行为日志： 用户浏览、用户点评、用户关注、用户搜索、用户投诉、用户咨询

3) 外部数据

当前一般公司都会通过线上广告来进行获客，与三方公司合作更多的提取相关数据来进行深度刻画用户及用户群体，另外爬取公共公开数据也是分析运营的常用方式。

外部数据源： 广告投放数据、爬虫数据、三方接口数据

2. 分层的误区

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

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

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

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

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

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

3. 宽表的误区

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

宽表的使用，有其一定的便利性。使用方不需要再去考虑跟维度表的关联，也不需要了解维度表和事实表是什么东西。

但是随着业务的增长，我们始终无法预见性地设计和定义宽表究竟该冗余多少维度，也无法清晰地定义出宽表冗余维度的底线在哪里。

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

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

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

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

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