docs:数仓专栏更新

Author: Java-Edge

docs/.vuepress/config.js

@@ -505,12 +505,13 @@ module.exports = {
                             collapsable: false,
                             sidebarDepth: 0,
                             children: [
+                                "维度建模理论之事实表",
+                                "数仓逻辑模型",
                                 "数仓业务调研",
                                 "数仓分层和数仓建模",
                                 "轻松驾驭Hive数仓",
                                 "数仓开发之ODS层",
                                 "数仓开发之DIM层",
-
                             ]
                         },
 

docs/md/bigdata/数仓逻辑模型.md

@@ -0,0 +1,58 @@
+# 数仓逻辑模型
+
+## 0 前言
+
+数据仓库的逻辑模型指的是描述数据仓库中数据如何组织、存储和相互关联的高层次抽象模型。它不涉及数据在物理层面上的实现细节（例如具体的数据库表结构），而是关注于数据模型的设计与规划，以便于支持业务决策和数据分析工作。
+
+以下是数据仓库逻辑模型的两种常见设计方法：
+
+## 1 星型模式（Star Schema）
+
+星型模式是一种数据模型，其中包含一个或多个事实表和多个维度表。事实表存储量化的业务数据（事实），例如销售总额、交易次数等，并且通常包含大量记录。维度表用于存储描述性数据来提供上下文信息，例如时间、地点、产品信息等。这种模式的名称来源于其看上去像一个星星的形状——中心的事实表被各个维度表围绕。
+
+当表关系可视化时，事实表在中间，被一系列维度表包围；与这些表的连接就像星星光芒。
+
+```plaintext
+          [时间维度表]
+                  |
+    [产品维度表] - [事实表] - [店铺维度表]
+                  |
+          [顾客维度表]
+```
+
+该模板的变体为
+
+## 2 雪花模式（Snowflake Schema）
+
+雪花模式是星型模式的变体，其中维度表可以有它们自己的维度表（被称为子维度表或归一化维度表）。在雪花模式中，数据库的结构更复杂，维度数据经过了进一步的归一化，它可以减少数据冗余，但可能会使得查询变得复杂，因为需要多个连接操作。
+
+```plaintext
+              [时间维度表]
+                      |
+        [产品类型] - [产品维度表] 
+                      |           - [事实表] - [店铺类型] - [店铺维度表]
+                      |
+            [顾客国家] - [顾客维度表]
+```
+
+其中维度被进一步分解为子维度。如品牌和产品类别可能有单独表格，且`dim_product` 表格中的每行都能再次将品牌和类别作为外键，而不是将它们作为字符串直接存储在 `dim_product` 表。雪花模式比星形模式更规范化，但星形模式是首选，因为对于分析师，它更简单。
+
+典型数仓中，表格很宽：
+
+- 事实表通常超100列，甚至数百列
+- 维度表也可能宽，因为它们包括可能与分析相关的所有元数据。如`dim_store` 表可能包括在每个商店提供哪些服务的细节，是否具有店内面包房，店面面积，商店开张日期，最后一次装修时间，距离最近的高速公路有多远
+
+## 3 核心原则
+
+- **支持业务需求**：
+  逻辑模型应确保可以满足所有当前和预期的业务分析需求。
+- **可扩展性**：
+  数据模型应方便未来的调整和扩展，以容纳新的数据源和新的业务需求。
+- **性能优化**：
+  模型应经优化以支持高效的数00-数仓逻辑模型据访问和查询性能。
+- **易用性**：
+  数据模型应容易理解和使用，尤其对于业务用户而言应显得直观。
+- **数据质量与一致性**：
+  逻辑模型应保证数据的准确性、完整性和一致性。
+
+在构建数据仓库的逻辑模型时，将考虑如何将不同的数据源整合到一致的框架中，以及如何结构化这些数据以便于报告和数据分析。逻辑模型是数据仓库概念和物理实现之间的桥梁。

docs/md/bigdata/维度建模理论之事实表.md

@@ -0,0 +1,136 @@
+# 维度建模理论之事实表
+
+## 1 概述
+
+事实表，作为数仓维度建模的核心，紧紧围绕业务过程来设计。其包含：
+
+- 与该业务过程有关的维度引用（维度表外键）
+- 该业务过程的度量（通常是可累加的数字类型字段）
+
+### 1.1 特点
+
+事实表通常较“细长”，即列较少，但行较多，且行的增速快。说明尽量使用维度外键，而不要 join 过来。
+
+事实表是用来记录业务事件（如销售交易、点击事件等），这些记录的属性大多是数值（代表度量指标），如金额、数量、时间等，它们与维度表中的描述性信息相关联。
+
+标准星型模式中，事实表包含维度表的外键，这些外键指向各维度表的唯一关键字，该设计是为提高查询性能：
+
+1. **避免数据冗余**：
+   - 通过仅在事实表中存储维度外键，而不是维度表中的详细描述性信息，可以减少数据冗余和表的大小。
+2. **查询性能**：
+   - 由于事实表一般很大并且查询频繁，保持它们“瘦而长”有助于减少在执行查询时要扫描的数据量，从而提高查询性能。
+3. **灵活度**：
+   - 对维度数据的任何更改（如修改维度属性）只需在维度表中进行一次，而不需要更新事实表中的数据。这提高了数据仓库的灵活性和维护性。
+4. **简洁的查询**：
+   - 通过使用外键与维度表连接，SQL查询通常更加简洁，易于编写和理解。
+
+通常设计和查询数据仓库时，应尽量避免在事实表中直接包含来自维度表的详细信息。当需要详细的描述性信息时，可以在查询中通过JOIN操作，将事实表与相应的维度表结合起来，以获取所需的上下文信息。
+
+如要查询特定时间段内按产品分类的销售总额：
+
+```sql
+SELECT
+    p.category,
+    SUM(f.sales_amount) # 事实表，包含了销售金额和产品ID（维度外键）
+FROM
+    fact_sales f
+JOIN
+		# dim_product 是维度表，存储了产品的详细分类信息
+    dim_product p ON f.product_id = p.product_id
+WHERE
+    f.sale_date BETWEEN '2021-01-01' AND '2021-12-31'
+GROUP BY
+    p.category;
+```
+
+通过使用产品ID将这两个表连接起来，可轻松得到按类别划分的销售总额。
+
+综上，事实表的设计应该侧重于度量性能和减少存储占用，并通过在查询时与维度表的关联来提供分析所需的详细上下文。这样的设计有利于数据仓库系统的扩展性和查询性能。
+
+### 1.2 分类
+
+事实表有三种类型：
+
+- 事务事实表
+- 周期快照事实表
+- 累积快照事实表
+
+## 2 事务型事实表
+
+### 2.1 概述
+
+事务事实表用来记录各业务过程，它保存的是各业务过程的原子操作事件，即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度。
+
+事务型事实表可用于分析与各业务过程相关的各项统计指标，由于其保存了最细粒度的记录，可以提供最大限度的灵活性，可以支持无法预期的各种细节层次的统计需求。
+
+### 2.2 设计流程
+
+一般遵循步骤：
+
+#### 2.2.1 选择业务过程
+
+在业务系统中，挑选我们感兴趣的业务过程，业务过程可以概括为一个个不可拆分的行为事件，例如在线教育交易中的下单，付款，加购等，都是业务过程。通常情况下，一个业务过程对应一张事务型事实表。
+
+#### 2.2.2 声明粒度
+
+业务过程确定后，需要为每个业务过程声明粒度，即精确定义每张事务型事实表的每行数据表示啥，应尽可能选择最细粒度，以应对各种细节程度需求。
+
+典型的粒度声明：
+
+订单事实表中的一行数据表示：一个订单中的一门课程。
+
+#### 2.2.3 确定维度
+
+确定维度具体是指，确定与每张事务型事实表相关的维度有哪些。
+
+确定维度时应尽量多的选择与业务过程相关的环境信息。因为维度的丰富程度就决定了维度模型能够支持的指标丰富程度。
+
+#### 2.2.4 确定事实
+
+“事实”指每个业务过程的度量值（通常是可累加的数字类型的值，如次数、个数、件数、金额等）。
+
+经过上述四个步骤，事务型事实表就基本设计完成了。第一步选择业务过程可以确定有哪些事务型事实表，第二步可以确定每张事务型事实表的每行数据是什么，第三步可以确定每张事务型事实表的维度外键，第四步可以确定每张事务型事实表的度量值字段。
+
+### 2.3 不足
+
+事务型事实表可以保存所有业务过程的最细粒度的操作事件，故理论上其可以支撑与各业务过程相关的各种统计粒度的需求。但对于某些特定类型的需求，其逻辑可能会比较复杂，或者效率会比较低下。如：
+
+#### 1 存量型指标
+
+例如购物车存量，账户余额等。此处以在线教育中的加购业务为例，加购业务包含的业务过程主要包括加购物车和减购物车，两个业务过程各自对应一张事务型事实表，一张存储所有加购物车的原子操作事件，另一张存储所有减购物车的原子操作事件。
+
+假定现有一个需求，要求统计截至当日的各用户各科目的购物车存量。由于加购物车和减购物车操作均会影响到购物车存量，故需要对两张事务型事实表进行聚合，且需要区分两者对购物车存量的影响（加或减），另外需要对两张表的全表数据聚合才能得到统计结果。
+
+可以看到，不论是从逻辑上还是效率上考虑，这都不是一个好的方案。
+
+#### 2 多事务关联统计
+
+例如，现需要统计最近30天，用户下单到支付的时间间隔的平均值。统计思路应该是找到下单事务事实表和支付事务事实表，过滤出最近30天的记录，然后按照订单id对两张事实表进行关联，之后用支付时间减去下单时间，然后再求平均值。
+
+逻辑上虽然并不复杂，但是其效率较低，因为下单事务事实表和支付事务事实表均为大表，大表join大表的操作应尽量避免。
+
+可以看到，在上述两种场景下事务型事实表的表现并不理想。下面要介绍的另外两种类型的事实表就是为了弥补事务型事实表的不足的。
+
+## 3 周期型快照事实表
+
+### 3.1 概述
+
+周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型（例如购物车存量，账户余额）或者状态型（空气温度，行驶速度）指标。
+
+对于购物车存量、账户余额这些存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合了。
+
+对于空气温度、行驶速度这些状态型指标，由于它们的值往往是连续的，我们无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样，构建周期型快照事实表。
+
+## 4 累积型快照事实表
+
+### 4.1 概述
+
+累积型快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的试听、下单、支付等业务过程。
+
+累积型快照事实表通常具有多个日期字段，每个日期对应业务流程中的一个关键业务过程（里程碑）。
+
+| **课程id** | **用户id** | ***\*试听日期\**** | ***\*下单日期\**** | ***\*支付日期\**** | **订单分摊金额** | **支付分摊金额** |
+| ---------- | ---------- | ------------------ | ------------------ | ------------------ | ---------------- | ---------------- |
+| 1001       | 1234       | 2022-02-19         | 2022-02-20         | 2022-02-21         | 1000             | 1000             |
+
+累积型快照事实表主要用于分析业务过程（里程碑）之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。