数据仓库概念
数据库 vs 数据仓库
从数据来源进行区分
数据库：企业中基础核心的业务数据
数据仓库：数据库中的数据
从数据存储进行区分
数据库：核心作用就是查找业务数据，基本上行式存储(带有索引)，基本上无法存储海量数据(除非分库分表)
数据仓库：核心作用就是统计分析数据，基本上列式存储(没有索引)，存储海量数据
从数据价值进行区分
数据库：保障全企业全业务的正常运行
数据仓库：将数据的统计结果为企业的经营决策提供数据支撑
体系建设
体系建设方法论的核心是：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复建设。
体系架构
规范定义
模范定义指以维度建模作为理论基础，构建总线矩阵，划分和定义数据域、业务过程、维度、度量 / 原子指标、修饰类型、修饰词、时间周期、派生指标。
| 名词术语 | 解释 |
| 数据域 | 指面向业务分析，将业务过程或者维度进行抽象的集合。其中，业务过程可以概括为一个个不可拆分的行为事件，在业务过程之下，可以定义指标；维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。 |
| 业务过程 | 指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程是一个不可拆分的行为事件，通俗地讲，业务过程就是企业活动中的事件。 |
| 时间周期 | 用来明确数据统计的时间范围或者时间节点，如最近30天、自然周、截至当日等。 |
| 修饰类型 | 是对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖无线端、PC端等修饰词。 |
| 修饰词 | 指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于一种修饰类型，如在日志域的访问终端类型下，有修饰词PC端、无线端等。 |
| 度量 / 原子指标 | 原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。 |
| 维度 | 维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度(其中包括国家、地区、省以及城市等级别的内容)、时间维度(其中包括年、季、月、周、日等级别的内容)。 |
| 维度属性 | 维度属性隶属于一个维度，如地理维度里面的国家名称、国家 ID、省份名称等都属于维度属性。 |
| 派生指标 | 派生指标 = 一个原子指标 + 多个修饰词(可选) + 时间周期。可以理解为对原子指标业务统计范围的圈定。派生指标唯一归属一个原子指标，继承原子指标的数据域，与修饰词的数据域无关。如原子指标：支付金额，最近 1 天海外买家支付金额则为派生指标(最近 1 天为时间周期，海外为修饰词，买家作为维度，而不作为修饰词)。 派生指标可以分为三类：事务型指标、存量型指标和复合型指标
|
模型设计基本原则
数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度 和事实。
1、高内聚和低耦合
一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。
2、核心模型与扩展模型分离
建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的字段过度侵入核心模型，以免破坏核心模型的架构简洁性，与可维护性。
3、公共处理逻辑下沉及单一
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。
4、成本与性能平衡
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
5、数据可回滚
处理逻辑不变，在不同时间多次运行数据结果确定不变。
6、一致性
具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。
数仓构建流程
需求分析
在需求分析阶段，您需要沉淀出业务分析或报表中的指标，以及指标的定义和粒度。粒度可以作为维度的输入。建议您思考下列问题，对后续的数据建模将有巨大的帮助：
- 业务数据是根据什么（维度、粒度）汇总的，衡量标准是什么？例如，成交量是维度，订单数是成交量的度量。
- 明细数据层和汇总数据层应该如何设计？公共维度层该如何设计？是否有公共的指标？
- 数据是否需要冗余或沉淀到汇总数据层中？
举例：数据分析师需要了解A公司电商业务中厨具类目的成交金额。当获知这个需求后，您需要分析：根据什么（维度）汇总、汇总什么（度量）以及汇总的范围多大（粒度）。例如，类目是维度，金额是度量，范围是全表。此外，还需要思考明细数据和汇总数据应该如何设计、是否是公共层的报表及数据是否需要沉淀到汇总表中等因素。
需求调研的分析产出通常是记录原子与派生指标的文档。
分析业务过程
业务过程可以概括为一个个不可拆分的行为事件。用户的业务系统中，通过埋点或日常积累，通常已经获取了充足的业务数据。
这是一个非常典型的电商交易业务流程图。在该业务流程图中，有创建订单、买家付款、卖家发货、确认收货四个核心业务步骤。由于确认收货代表交易成功，我们重点分析确认收货（交易成功）步骤即可。
划分数据域
数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念，目的是便于管理和应用数据。
数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。
数据域可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块进行划分。例如A公司电商营销业务板块可以划分为如下数据域，数据域中每一部分都是实际业务过程经过归纳抽象之后得出的。
| 数据域 | 业务过程 |
|---|---|
| 会员店铺域 | 注册、登录、装修、开店、关店 |
| 商品域 | 发布、上架、下架、重发 |
| 日志域 | 曝光、浏览、单击 |
| 交易域 | 下单、支付、发货、确认收货 |
| 服务域 | 商品收藏、拜访、培训、优惠券领用 |
| 采购域 | 商品采购、供应链管理 |
定义维度与构建总线矩阵
定义维度
在划分数据域、构建总线矩阵时，需要结合对业务过程的分析定义维度。以本教程中A电商公司的营销业务板块为例，在交易数据域中，我们重点考察确认收货（交易成功）的业务过程。
在确认收货的业务过程中，主要有商品和收货地点（本教程中，假设收货和购买是同一个地点）两个维度所依赖的业务角度。从商品维度我们可以定义出以下维度的属性：
- 商品ID（主键）
- 商品名称
- 商品交易价格
- 商品新旧程度： 1 全新 2 闲置 3 二手
- 商品类目ID
- 商品类目名称
- 品类ID
- 品类名称
- 买家ID
- 商品状态： 0 正常 1 删除 2 下架 3 从未上架
- 商品所在城市
- 商品所在省份
从地域维度，我们可以定义出以下维度的属性：
- 城市code
- 城市名称
- 省份code
- 省份名称
作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以A公司的商品维度为例，有且只允许有一种维度定义。例如，省份code这个维度，对于任何业务过程所传达的信息都是一致的。（维度设计后面细讲....）
构建总线矩阵
明确每个数据域下有哪些业务过程后，即可构建总线矩阵。您需要明确业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。如下所示是A公司电商板块交易功能的总线矩阵，我们定义了购买省份、购买城市、类目名称、类目ID、品牌名称、品牌ID、商品名称、商品ID、成交金额等维度。
| 数据域/过程 | 一致性维度 | |||||||||
| 购买省份 | 购买城市 | 类目ID | 类目名称 | 品牌ID | 品牌名称 | 商品ID | 商品名称 | 成交金额 | ||
| 交易 | 下单 | Y | Y | Y | Y | Y | Y | Y | Y | N |
| 支付 | Y | Y | Y | Y | Y | Y | Y | Y | N | |
| 发货 | Y | Y | Y | Y | Y | Y | Y | Y | N | |
| 确认收货 | Y | Y | Y | Y | Y | Y | Y | Y | Y | |
明确统计指标
指标定义注意事项
原子指标是明确的统计口径、计算逻辑： 原子指标=业务过程+度量。派生指标即常见的统计指标：派生指标=时间周期+修饰词+原子指标。原子指标的创建需要在业务过程定义后方才可创建。派生指标的创建一般需要在了解具体报表需求之后展开，在新建派生指标前必须新建好原子指标。 注意事项如下：
- 原子指标、修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域。
- 派生指标可以选择多个修饰词，由具体的派生指标语义决定。例如，支付金额为原子指标，则客单价（支付金额除以买家数）为派生指标。
- 派生指标唯一归属一个原子指标，继承原子指标的数据域，与修饰词的数据域无关。
根据业务需求确定指标
本教程中，用户是电商营销部门的营销数据分析师。数据需求为最近一天厨具类目的商品在各省的销售总额、该类目Top10销售额商品名称、各省用户购买力分布（人均消费额）等，用于营销分析。
根据之前的分析，我们确认业务过程为：确认收货（交易成功），而度量为商品的销售金额。因此根据业务需求，我们可以定义出原子指标：商品成功交易金额。
派生指标为：
- 最近一天全省厨具类目各商品销售总额
- 最近一天全省厨具类目人均消费额（消费总额除以人数）
最近一天全省厨具类目各商品销售总额进行降序排序后取前10名的名称，即可得到该类目Top10销售额商品名称。
维度设计
数据仓库分层
ODS 操作数据层
既然数据都是从数据库(MySQL)中获取，那如果直接作为数据仓库的数据源不行吗？
1、业务数据库的数据存储位行式存储，而数据仓库要求列数存储（行式数据转换为列式数据）
2、业务数据库中存储的数据不是海量数据，有可能只是近几年的数据，但是数据仓库要求更多历史数据时，可能不满足要求（数据量不够）
3、数据库不是为了数据仓库服务的（数据仓库在对接数据库时，会对数据库的性能造成影响，从而影响业务正常运行）
所以，需要设计一个自己的数据源，ods层就是数据仓库的数据源
ODS层的基本工作
- 同步：结构化数据增量或者全量同步ODS层中
- 结构化：非结构化（日志）结构化处理并存储到ODS层中
- 累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据
其中尽可能不变
1、存储方式不要变
2、数据格式不要变
3、压缩格式不要变
可以变
1、融合异构数据
2、汇总不同时间的数据
DWD 明细粒度层
明细粒度事实层DWD（Data Warehouse Detail）以业务过程驱动建模，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。您可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。
明细粒度事实层（DWD）通常分为三种：事务事实表、周期快照事实表和累积快照事实表。
- 事务事实表用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为原子事实表。
- 周期快照事实表以具有规律性的、可预见的时间间隔记录事实。
- 累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点。当累积快照事实表随着生命周期不断变化时，记录也会随着过程的变化而被修改。
- 通常，一个明细粒度事实表仅和一个维度关联。
- 尽可能包含所有与业务过程相关的事实 。
- 只选择与业务过程相关的事实。
- 分解不可加性事实为可加的组件。
- 在选择维度和事实之前必须先声明粒度。
- 在同一个事实表中不能有多种不同粒度的事实。
- 事实的单位要保持一致。
- 谨慎处理Null值。
- 使用退化维度提高事实表的易用性。
明细粒度事实表整体设计流程如下图所示。
在一致性度量中已定义好了交易业务过程及其度量。明细事实表注意针对业务过程进行模型设计。明细事实表的设计可以分为四个步骤：选择业务过程、确定粒度、选择维度、确定事实（度量）。粒度主要是在维度未展开的情况下记录业务活动的语义描述。在您建设明细事实表时，需要选择基于现有的表进行明细层数据的开发，清楚所建表记录存储的是什么粒度的数据。
存储方式要变为列式存储
DWS 公共汇总粒度层
公共汇总粒度事实层DWS（Data Warehouse Summary）以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求构建公共粒度的汇总指标事实表。公共汇总层的一个表至少会对应一个派生指标。
聚集是指针对原始明细粒度的数据进行汇总。DWS公共汇总层是面向分析对象的主题聚集建模。在本教程中，最终的分析目标为：最近一天某个类目（例如：厨具）商品在各省的销售总额、该类目Top10销售额商品名称、各省用户购买力分布。因此，我们可以以最终交易成功的商品、类目、买家等角度对最近一天的数据进行汇总。数据聚集的注意事项如下：
- 聚集是不跨越事实的。聚集是针对原始星形模型进行的汇总。为获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨越事实的。
- 聚集会带来查询性能的提升，但聚集也会增加ETL维护的难度。当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。
此外，进行DWS层设计时还需遵循以下原则：
- 数据公用性：需考虑汇总的聚集是否可以提供给第三方使用。您可以思考，基于某个维度的聚集是否经常用于数据分析中。如果答案是肯定的，就有必要把明细数据经过汇总沉淀到聚集表中。
- 不跨数据域：数据域是在较高层次上对数据进行分类聚集的抽象。数据域通常以业务过程进行分类，如交易统一划到交易域下， 商品的新增、修改放到商品域下。
- 区分统计周期：在表的命名上要能说明数据的统计周期，如_1d 表示最近1天， td 表示截至当天，nd 表示最近N天。
DIM 公共维度层
公共维度汇总层DIM（Dimension）基于维度建模理念，建立整个企业的一致性维度。
公共维度汇总层（DIM）主要由维度表（维表）构成。维度是逻辑概念，是衡量和观察业务的角度。维表是根据维度及其属性将数据平台上构建的物理化的表，采用宽表设计的原则。因此，公共维度汇总层（DIM）首先需要定义维度。
完成维度定义后，您可以对维度进行补充，进而生成维表。维表的设计需要注意：
- 建议维表单表信息不超过1000万条。
- 维表与其他表进行Join时，建议您使用Map Join。
- 避免过于频繁的更新维表的数据。
ADS 数据应用层
存放数据产品个性化的统计指标数据，根据DW层与ODS层加工生成。ADS层数据优先使用DW层数据，当公共层没有数据时，需评估是否需要创建公共层数据，当不需要创建公用的公共层时，方可直接使用ODS层数据。
数据仓库建模方法论
1、ER模型 实体关系模型
从全企业的高度，用实体关系模型来描述企业业务，并用规范化的方式表示出来，在范式理论上符合3NF。
对象关系
多对一
多对多
一对多
一对一
2、维度模型
事实表分类
事实表有三种类型：
1、事务事实表：事务型事实表用来记录各业务过程，它保存的是各业务过程的原子操作事件，即最细粒度的操作事件，粒度是指事实表中一行数据所表达的业务细节程度。事务型事实表可用于分析与各业务过程相关的各项统计指标，由于其保存了最细粒度的记录，可以提供最大限度的灵活性，可以支持无法预期的各种细节层次的统计需求。一个业务过程对应一张事务型事实表。
不足：
存量型指标：比如电商中的虚拟货币或者商品库存，增长或者存入商品可能对应一个事实表，减少或者寄出商品对应一个事实表，如果需要计算存量，那么可能需要进行大表join，效率慢。
多事务关联统计：比如现在需要统计最近30天，用户下单到支付的时间间隔的平均值，统计思路应该从下单事务事实表和支付事务事实表找到最近30天的记录，然后根据订单id进行大表join，同样是效率慢。
2、周期快照表：周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型（例如商品库存、账户余额）或者状态型（平均驾驶速度、平均温度）指标。对于存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，避免从历史记录中进行聚合。对于状态型指标，由于它们的值往往是连续的，无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求，而只能定期对其进行采样，构建周期型快照事实表。
3、累积快照表：累积快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。通常具有多个日期字段，每个日期对应业务流程中的一个关键过程。累积型快照事实表重要用于分析业务过程之间的时间间隔等需求，例如用户下单到支付的平均时间间隔，就能避免两个事务型事实表的关联操作。
(晚点再改改。。)
