为什么要建模
写sql一直以来其实都不难，关键字一共也就那么些，但是每天PB级的数据最终要处理成一系列的指标准确的给老板做汇报，指导业务做决策，做到数据高效存储、快速产出、含义准确一致，叠加起来可就需要一些技术含量了。
在我看来，数据仓库建模的核心就是设计和组织数据，以便有效地存储、管理和查询，以满足企业的数据分析和报告需求。可别让"建模"这个词吓到你，其实它就是把脑子里那团业务逻辑的线理清楚，然后以一种所有人都能看懂的方式"落地"出来。
建模流程：
大部分企业采用Lambda架构，重要紧急指标使用实时任务先算一套，最终以离线任务的计算结果为准，实时数据与离线口径保持一致，并告知业务方实时数据和离线数据之间的误差波动情况。
实时和离线模型在设计时要同时考虑功能性需求和非功能性需求。功能需求很好理解，就是满足业务需求，必须要产出的数据和指标。模型建设难点其实在于非功能性需求，比如：数据的可靠性、数据产出效率、模型可扩展性、计算和存储资源优化 等等
模型设计基本原则：
高内聚低耦合(最重要)。各主题内数据模型要业务高内聚，避免在一个模型耦合其他业务的指标，造成该模型主题不清晰和性价比低。
模型建设采用Kimball维度建模方法(雪花模型)，按照之前说的经典的四层架构去做模型的分层，维度尽可能的扁平化设计(反范式)，雪花型扩展部分不要超过1层。
不同粒度的模型要分开设计，比如有些模型是user_id粒度，有些模型是user_id + os 粒度。粒度一般用维度(或维度组合)和具体业务含义表示，技术上来说就是表的主键。
公共处理逻辑需要下沉到底层模型中，统一计算好再供上层模型使用，避免上层模型多处地方计算导致数据口径不统一 or 修改不统一。
如果模型依赖到的指标有些产出早，有些产出晚，可以考虑拆分模型以满足业务需求。
模型可以时当冗余以换取查询性能的优化(即大宽表)。
数仓人员遵循统一的开发规范，可以翻一下我之前的文章：《数仓建设需要考虑的一些规范》
维度表设计：高内聚、低耦合，反范式、扁平化、易用性，体现维度的层次结构
保持维度定义的一致性，每个维度有且只有一个定义，且每个直接参与业务过程的关键实体都应设计为单独的关键维度。且维度不应使用半结构化、非结构化数据进行存储（如json，描述类维度除外）
如果两个关键维度存在1:1或从属关系，应将较大的维度主键加入至较小的维度中；如果两个关键维度存在n:n的关系，且关系是客观存在（不依赖事务），则考虑创建关系表保存两个关键维度的关系
业务如果有需要的话，对于缓慢变化维设计成拉链表，需应体现数据的有效期间以及当前是否可用
业务过程产生的业务属性或简单维度(鸡肋信息)，可以设置为杂项维度
事实表设计：高内聚、低耦合，保证事务的完整性、一致性，提高数据使用效率
企业所有的业务过程都可以描绘为事实，事实表的数据粒度应保持一致，不同粒度的数据不应出现在同一事实表中
完全一致或非常相似性业务可放到同一张同一事实表中，如点评转业务，dwd层存储最细粒度事实（每个事务）
数据写入保证一致性：在不回刷的情况下，所有指标数据不要写入第二次。如果指标写入第二次，数据被修改了，下游表问题排查起来就会非常痛苦
事实表会分成下述多种：
1.累积事实表
这种事实表包含了事务型数据的累积值，通常用于记录累积的总量或累积的周期性度量。例如，累积销售事实表记录了累计的销售额、总利润、总销售量等数据。
|------|------|-------|-------|-------|
| 日期ID | 产品ID | 累计销售额 | 累计利润 | 累计销售量 |
| ... | ... | 50000 | 15000 | 1000 |
| ... | ... | 52000 | 16000 | 1050 |
2.快照事实表
这种事实表记录了在特定时间点或时间段内的业务度量值。快照通常定期捕获数据的状态，而不是随着每个业务事件的发生而更新。
|------|------|-------|-------|
| 快照日期 | 产品ID | 当日销售额 | 当日订单数 |
| 日期1 | 产品1 | 1000 | 25 |
| 日期2 | 产品1 | 1200 | 30 |
3.事务事实表
这种事实表记录了每个业务事件的详细事务数据，每一行代表一个独立的事务或事件。它们通常是针对某个特定的业务过程，包含了每次事务的数据。
|------|------|------|------|-----|----|
| 订单ID | 产品ID | 日期ID | 客户ID | 销售额 | 数量 |
| 1001 | 101 | 500 | 200 | 150 | 2 |
| 1002 | 102 | 501 | 201 | 75 | 1 |
4.周期性快照事实表
类似于快照事实表，但记录了经过一定时间间隔的快照数据。这种类型的事实表通常用于分析跨越不同时间段的变化趋势。
|---------|------|------|-------|
| 日期范围 | 产品ID | 月销售额 | 季度销售额 |
| 2023年1月 | 产品1 | 500 | 1500 |
| 2023年2月 | 产品1 | 600 | 1400 |
这些不同类型的事实表在数据仓库中有不同的用途和分析方法，根据业务需求选择合适的事实表类型有助于更有效地进行数据分析和洞察。
参考：
https://developer.aliyun.com/article/901537(维度建模)
https://developer.aliyun.com/article/1532389（维度表和事实表设计原则）
https://developer.aliyun.com/article/1519204（维度表和事实表形象介绍）