数仓建模过程——写指标

1、维度：描述信息
事实：度量值
比如：我早上花了5元买早餐，其中时间地点买了什么等就是描述信息就是维度，具体的金额数字就是事实

2、ods层一般就是原始数据 比如用户行为日志，导入到hdfs中是一条条日志，那么日志的ods层表结构就只有string类型的一条日志
从mysql导入到hdfs的有27张表 那么ods层应该与其对应就是27张表，表结构与mysql中对应

3、dim（维度表）和dwd（事实表）

4、如何确定有哪些表以及字段？

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

（1）选择业务过程

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

（2）声明粒度

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

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

典型的粒度声明如下：

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

（3）确定维度

维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。

（4）确定事实

此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理

   时间	  用户	 地区	  商品	  优惠券	  活动	      度量值

订单 √ √ √ 运费/优惠金额/原始金额/最终金额
订单详情 √ √ √ √ √ √ 件数/优惠金额/原始金额/最终金额
支付 √ √ √ 支付金额
加购 √ √ √ 件数/金额
收藏 √ √ √ 次数
评价 √ √ √ 次数
退单 √ √ √ √ 件数/金额
退款 √ √ √ √ 件数/金额
优惠券 √ √ √ 次数

如上表格，先是确定业务，也就是确定有什么事实表，纵轴 订单、订单详情等就代表业务，也就是一个事实表
横轴是维度，确认业务和维度是否有关系时，需要看在建立业务表时候他们之间的关系
事实表里面的字段是维度外键+度量值
维度表的每行数据就是一个维度对象 比如用户维度就是一个用户 维度表的字段包括所有属性 与其相关表的所有字段

5、dws 和 dwt 提高复用性，避免重复计算
DWS层和DWT层统称宽表层，这两层的设计思想大致相同，通过以下案例进行阐述。
1）问题引出：两个需求，统计每个省份订单的个数、统计每个省份订单的总金额
2）处理办法：都是将省份表和订单表进行join，group by省份，然后计算。同样数据被计算了两次，实际上类似的场景还会更多。
那怎么设计能避免重复计算呢？
针对上述场景，可以设计一张地区宽表，其主键为地区ID，字段包含为：下单次数、下单金额、支付次数、支付金额等。上述所有指标都统一进行计算，并将结果保存在该宽表中，这样就能有效避免数据的重复计算。
宽表中字段：维度ID（主键）+维度模型中跟地区相关的事实表中的度量值的聚合值
3）总结：
（１）需要建哪些宽表：以维度为基准。
（２）宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。
（３）DWS和DWT层的区别：DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等，DWT层存放的是所有主题对象的累积行为，例如每个地区最近７天（１５天、３０天、６０天）的下单次数、下单金额等。

6、ads由需求决定。