电商系统数据库 mysql 电商平台数据库

电商数据仓库理论

• 数据仓库分层

• 为什么要分层
• 数据集市与数据仓库概念
• 数仓命名规范

• 表命名
• 脚本命名规范
• 表字段类型

• 数仓理论

• 范式理论

• 范式概念
• 函数依赖
• 三范式区分

• 关系建模和维度建模

• 关系建模
• 维度建模
• 维度表和事实表

• 数据仓库建模

数据仓库分层

为什么要分层

• ODS（Operation Data Store）
  原始数据层。存放原始数据，直接加载原始日志、数据，数据保持原貌不作处理
• DWD（Data Warehouse Detail）
  明细数据层。对ODS层数据进行清洗（去除空值，脏数据，超过极限范围的数据）、维度退化、脱敏等。
• DWS（Data Warehouse Service）
  以DWD为基础，按天进行轻度汇总
• DWT（Data Warehouse Topic）
  以DWS为基础，按主题进行汇总
• ADS（Application Data Store）
  ADS层，为各种统计报表提供数据

？ 数据分层的原因

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

数据集市与数据仓库概念

数据集市（Data Market），现在在市面上的公司和数据对数据集市有不同的概念。
数据集市则是一种微型的数据仓库，它通常有更少的数据，更少的主题区域，以及更少的历史数据，因此是部门级别的。一般只能为某个局部范围内的管理人员服务。
数据仓库是企业级的，能为整个企业各个部门裕兴提供决策的支持手段。

数仓命名规范

表命名

• ODS层命名为ods_表名
• DWD层命名为dwd_dim/fact_表名
• DWS层命名为dws_表名
• DWT层命名为dwt_购物车
• ADS层命名为ads_表名
• 临时表命名为xxx_tmp
• 用户行为表，以log为后缀

脚本命名规范

• 数据源_to_目标_db/log.sh
• 用户行为脚本以log为后缀；业务数据脚本以db为后缀。

表字段类型

• 数量类型为bigint
• 金额类型为decimal(16,2)
• 字符串(名字，描述信息等)类型为string
• 主键外键类型为string
• 时间戳类型为bigint

数仓理论

范式理论

范式概念

定义：范式可以理解为设计一张数据表的表结构，符合的标准级别。 规范和要求

优点

关系型数据设计时，遵照一定的规范要求，目的在于降低数据的冗余性。

？ 为什么要降低数据冗余性？

• 十几年前，磁盘很贵，为了减少磁盘存储。
• 以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的
• 一次修改，需要修改过个表，很难保证数据一致性

缺点

范式的缺点是获取数据时，需要通过Join拼接出最后的数据。

分类

目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

函数依赖

完全函数依赖

设X，Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。

即：通过AB能得出C，但是AB单独得不出C，那么说C完全依赖于AB。

部分函数依赖

假如 Y函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，

即：通过AB能得出C，通过A也能得出C，或者通过B也能得出C，那么说C部分依赖于AB。

传递函数依赖

传递函数依赖：设X，Y，Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。

即：通过A得到B，通过B得到C，但是C得不到A，那么说C传递依赖于A。

三范式区分

第一范式1NF核心原则：属性不可切割

第二范式2NF核心原则：不能存在部分函数依赖，即非主键字段不能部分依赖于主键字段。

第三范式3NF核心原则：不能存在传递函数依赖，即非主键字段不能传递依赖于主键字段。

关系建模和维度建模

当前的数据处理大致可分为两大类：联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。二者主要区别对比如下。

对比属性	OLTP	OLAP
读特性	每次查询只返回少量记录	对大量数据进行汇总
写特性	随机、低延时写入用户的输入	批量导入
使用场景	用户，JavaEE项目	内部分析师，为决策提供支持
数据表征	最新数据状态	随时间变化的历史状态
数据规模	GB	TB到PB

关系建模

关系模型如图所示，严格遵循第三范式（3NF），从图中可以看出，较为松散、零碎，物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。

维度模型如图所示，主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。维度模型中的表分为两种：维度表和事务表，通常情况下，一个事实表会有多个ID来关联多个维度表；除此之外，还会一个重要属性——度量值。度量值是要在后期进行统计分析的数值，一般是数字类型，而且大部分具有可加性。

维度模型优势：表结构清晰；查询性能高；方便进行多维分析。

关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。

维度建模

在维度建模的基础上有分为三种模型：星型模型、雪花模型、星座模型。

雪花模型与星型模型的区别主要在于维度的层级，标准的星型模型维度只有一层，而雪花模型可能会涉及多级。

星座模型与前两种情况的区别是事实表的数量，星座模型是基于多个事实表。基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座不星座只反映是否有多个事实表，他们之间是否共享一些维度表。所以星座模型并不和前两个模型冲突。

模型选择

首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不用选择。星型还是雪花，取决于性能优先，还是灵活更优先。
目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少Join就是减少Shuffle，性能差距很大。（关系型数据可以依靠强大的主键索引）

维度表和事实表

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

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

2. 事实表
   事实表：每行数据代表一个业务事件(下单、支付、退款、评价等)。“事实”这个属于表示的是业务事件的度量值(可统计次数，个数，金额等)，
   每个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键。通常具有两个和两个以上的外键、外键之间表示维表之间多对多关系。
   事实表特征：

• 非常的大
• 内容相对较窄
• 经常发生变化，每天会新增加很多

事实表分类

1. 事务性事实表
   以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
2. 周期性快照事实表
   周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。
3. 累积型快照事实表
   累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

数据仓库建模

1. ODS层

1. 保持数据原貌不做任何修改，起到备份数据的作用。
2. 数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
3. 创建分区表，防止后续的全表扫描

2. DWD层
   DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。
   维度建模一般按照以下四个步骤：
   选择业务过程→声明粒度→确认维度→确认事实

1. 选择业务
   在业务系统中，挑选我们需要统计分析的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
2. 声明粒度
   数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。数据细化程度越高，粒度级就越小。即：每条数据描述的范围越小，粒度越高。外键也可描述订单粒度。
   声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择****最小粒度****，以此来应各种各样的需求。
3. 确定维度
   维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
4. 确定事实
   此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。

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

	时间	地区	用户	商品	优惠券	活动	度量字段
订单明细表	✔	✔	✔	✔	✔	✔	个数/金额
订单信息表	✔	✔	✔		✔	✔	金额/运费
支付	✔	✔	✔				金额
加购	✔	✔	✔	✔			个数/金额
收藏	✔		✔	✔			次数
退款	✔		✔	✔			金额/个数
评论	✔		✔	✔			次数
优惠券领用	✔		✔		✔		次数

1. DWS层
   统计各个主题对象的当天行为（表对应着维度，字段对应着事实表的度量值），服务于DWT层的主题宽表，以及一些业务明细数据，应对特殊需求（例如，购买行为，统计商品复购率）。
2. DWT层
   以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建主题对象的全量宽表（统计同DWS层）———累积行为。
3. ADS层
   对电商系统各大主题指标分别进行分析。