1.总述
人类从“IT时代”进入“DT时代”。本书介绍了阿里巴巴的大数据系统架构，为了满足不断变化的业务需求，同时实现系统的高扩展性、灵活性以及数据展现的高性能。
数据体系主要包括：数据采集、数据计算、数据服务和数据应用四大层次。
1.数据采集层包括两大体系：Aplus.JS是Web端日志采集技术方案，UserTrack是APP端日志采集技术方案。
2.数据计算层包括两大体系：数据存储及计算云平台（离线计算平台：MaxCompute；实时计算平台：StreamCompute）；数据整合和管理体系（阿里内部称为“OneData”）。数仓的加工链路包括：ods（操作数据层）、dwd（明细数据层）、dws（汇总数据层）、ads（应用数据层）。
3.数据服务层通过接口服务化方式对外提供数据服务，数据服务层架构在多种数据库之上（例如：mysql、Hbase等），数据服务层对外提供服务通过统一的数据服务平台（OneService）。
11.事实表设计
11.1 事实表基础
事实表包括引用的维度和描述具体业务的度量。
事实表中一条记录描述的业务的细节程度称为粒度。粒度可以使用两种方式来表示：（1）维度属性组合（2）所表示的具体业务含义。
事实包括可加性、半可加性和不可加性三种类型：
半可加性：只可以针对特定维度做聚合，例如库存（不能按照日期，可按照仓库聚合）。
可加性：可以按照任意维度聚合。
不可加性：完全不具备可加性。（例如：比率，事实表可以拆分存储分子分母）
维度属性也可以存到事实表中，称为退化维度。
事实表有三种类型：事务事实表、周期快照事实表、累计快照事实表。
事务事实表描述的是业务过程上的原子事务，也称为原子事实表。
周期快照事实表是按照周期性规律的时间间隔记录事实。
累计快照事实表：累计快照事实表用来表示过程开始和结束过程之间的关键步骤事件，覆盖整个生命周期，通常用多个日期字段记录关键时间点，记录会随着时间变化而修改。
事实表设计原则：
原则1： 尽可能包含所有与业务过程相关的事实。
即时存在冗余，也尽可能存储。
原则2：只选择与业务过程相关的事实。
原则3：分解不可加事实为可加的组件。
例如：不存成单率，转而存储成单数和提单数。
原则4：选择维度和事实前，必须先声明粒度。
建议粒度设置的越细越好，这样可以最大限度的提高灵活性。可以通过业务描述或者维度属性组合的方式来定义粒度。
原则5：在同一个事实表中，不应该有不同粒度的事实。
例如：一个事实表中不应该包含某些精确到订单粒度的度量，同时又包含只精确到城市的度量。
原则6：事实的单位一致。
原则7：尽量处理掉事实表中的null值。
SQL中大于，小于的条件不适用与null值，所以尽量用数值替代null，例如0.
原则8：使用退化维度增加事实表的易用性。
在Kimball的维度设计模型中，分拆出单独的维度表，为了节省存储。但是为了减少使用时的关联次数，可以多使用退化维度提供事实表易用性。
事实表设计方法：
1.选择业务过程及确定事实表类型。2. 声明粒度。3.确定维度。4.确定事实。5.冗余维度（设计退化维度）。
11.2 事务事实表
事务事实表，即针对业务过程构建的一类事实表，用来跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细数据。
11.2.1 单事务事实表
单事务事实表，即针对每一个业务过程设计一个事实表，这样可以方便地对每一个业务过程进行分析研究。
11.2.2 多事务事实表
表示同一个事实表包含不同的业务过程。多事务事实表有两种实现方法：（1）使用两个不同的事实字段来保存各自业务过程。（2）使用同一个字段保存，但是增加一个业务过程标签。
下面举例说明，淘宝交易事务事实表同时包含下单、支付和成功完结三个过程，三个过程粒度一致，可以放在一个事实表。下面确定维度和事实，该表中的下单度量、支付度量和成功完结度量信息分别存在不同字段，如果不是当前业务处理，则用0来处理。
当不同业务过程的度量比较相似、差异不大时使用第二种事实表（使用一个字段保存），当不同业务过程的度量差异大时，使用第一种（多字段保存）。
11.2.3 比较
对于单事务事实表和多事务事实表的选择上，可以从以下一些方面来区分：
业务过程、粒度和维度（不同业务过程粒度相同，并且维度相似时，可以选用单事务事实表）、事实、下游业务使用、计算存储成本。电商环境下，有父子订单的概念，店铺多商品各生成一个订单，在一个店铺合成一个父订单。
| 事务事实表类型 | 单事务事实表 | 多事务事实表 |
|---|---|---|
| 业务过程 | 一个 | 多个 |
| 粒度 | 相互不相关 | 相同粒度 |
| 维度 | 相互不相关 | 一致 |
| 事实 | 只取当前业务过程中的事实 | 保留多个事实，非当前业务度量置0 |
| 冗余维度 | 多个业务过程，冗余多次 | 不同业务过程只冗余一次 |
| 理解成本 | 易于理解，不易混淆 | 难以理解，需要通过标签限定 |
| 计算存储成本 | 较多，每个业务过程都需要计算存储一次 | 较少，增加了存储量，存在大量零值数据 |
11.2.4 事实的设计准则
1.事实完整性：事实表包含与其描述的过程有关的所有事实。
2.事实一致性：明确存储每一个事实以确保度量一致性。例如，有下单商品数和商品价格2个事实，同时保存下单金额（价格*商品数）。这样下游使用时，直接取下单金额，而不是再次计算，以保证指标的一致性。
3.事实可加性：为确保下游使用时，指标的可聚合性，尽量保存原始数，而不是计算后的比率指标。
11.3 周期性快照事实表
对于事务度量，事务性事实表可以很好地表征。但是对于一些状态度量，例如买卖家累计交易金额、商品库存、买卖家星级、温度（事务事实表无法聚合得到）等，事务事实表的效率较低或者无法处理。为了解决状态度量问题，引入周期性快照事实表（也称为快照事实表）。
11.3.1 快照事实表特性
1.用快照采样状态：快照事实表以预定的间隔采样状态度量。
2.快照粒度：快照事实表通常总是被多维声明，即快照需要采样的周期以及什么将被采样。
3.密度和稠密性：稠密性是快照事实表的重要特征。事务事实表一般都是稀疏的，只要发生业务才会有相应记录。
4.半可加性：快照事实表的状态度量都是半可加的，例如商品库存，只针对商品维度可加，对日期维度不可加。
设计快照事实表，首先确定快照粒度，然后确定采样的状态度量。下面介绍几个快照事实表实例。
单维度每天快照事实表、混合维度每天快照事实表，这两种快照表都可以从事务事实表汇总得到。另外的一种产出模式是直接使用操作型系统作为数据源来加工，例如淘宝卖家的星级评分是在操作型系统中计算得出的，仓库直接拿来这部分数据加入事实表。全量快照事实表，是特殊类型的周期快照表，例如设计无事实的事实表来记录评论的状态度量。
总结：事务事实表和周期快照表一般都是成对设计，特别是在事务事实表基础上加工周期快照事实表。一般地，快照事实表会有状态比对的需求（和上一个时间周期），所以周期快照表一般也会附加存储上一个时间周期的状态度量（防止多次使用周期快照表）。除历史至今的状态度量，还可能需要自然年、季度、月份至今的状态（例如年初至今的库存量）。
11.4 累计快照事实表
对于研究事件之间的时间间隔需求时，累计快照事实表能较好符合需求。
特点：
1.数据不断更新：例如，在下单、支付和确认收货三个业务过程中，事务事实表会生成3条记录，而累计快照表会不断更新一条记录（不生成新记录）。
2.多业务过程日期：
累计快照表适用于具有较明确起止时间的短生命周期的实体，对于每个实体都经历从诞生到消亡等步骤。
3.存储历史全量数据。
11.5 三种类型事实表的比较
| 事实表类型 | 事务事实表 | 周期快照事实表 | 累积快照事实表 |
|---|---|---|---|
| 时间/时期 | 离散事务时间点 | 以有规律、可预测的时间间隔产生数据 | 用于时间跨度不确定的不断变化的工作流 |
| 日期维度 | 事务日期 | 快照日期 | 相关业务过程涉及的多个日期 |
| 粒度 | 每行代表实体的一个事务 | 每行代表某时间周期的一个实体 | 每行代表一个实体的生命周期 |
| 事实 | 事务事实 | 累积事实 | 相关业务过程事实和时间间隔事实 |
| 事实表加载 | 插入 | 插入 | 插入与更新 |
| 事实表更新 | 不更新 | 不更新 | 业务过程变更时更新 |
11.6 无事实的事实表
1.事件类的，例如浏览日志。
2.条件范围资格类的，例如客户和销售人员的分配情况。
11.7 聚集型事实表
主要是提前聚合，为了增加数据访问的效率（不用再聚合了），减少数据不一致的情况。这类聚集汇总数据，被称为“公共汇总层”。
聚集的基本步骤：1.确定聚集维度。2.确定一致性上钻。3.确定聚集事实。
12.元数据
12.1 元数据概述：
元数据主要记录数据仓库中模型的定义、各层级间映射关系、监控数据仓库的数据状态及ETL任务的运行状态。元数据分为技术元数据和业务元数据。
阿里巴巴技术元数据包括：
数据表、列等信息；ETL作业的信息；数据同步、任务调度、计算任务等信息。数据质量和运维相关元数据。
阿里巴巴业务元数据包括：
维度属性、业务过程、指标等。数据应用元数据，例如数据报表、数据产品等。
元数据价值：
元数据在数据管理方面为集团数据在计算、存储、成本、质量、安全、模型等治理领域上提供数据支持。
14.存储和成本管理
14.1 数据压缩
阿里MaxCompute提供了archive压缩方法，采用了具有更高压缩比压缩算法，将数据以RAID file的形式存储。这样可以节省空间，但是恢复起来也更复杂，所以适用于冷备份的数据。
14.2 数据重分布
MaxCompute基于列存储，通过修改表的数据重分布，避免列热点，将会节省一定存储空间。
14.3 存储治理项优化
存储治理项以元数据为基础，列出例如“62天内未访问的分区”、“数据无更新的任务列表”等等管理项推动ETL优化。形成现状分析、问题诊断、管理优化、效果反馈的存储治理项优化的闭环。
14.4 生命周期管理
生命周期管理的目的是用最少的存储成本来满足最大业务需求，实现数据价值最大化。
1.周期性删除策略：
2.彻底删除策略：主要针对无用表，ETL中间过程表。
3.永久保存策略：
4.极限存储策略：
5.冷数据管理策略：针对重要且访问频率低的数据。
6.增量表merge全量表策略：
14.5 数据成本计量
将一个数据表的成本分为存储成本和计算成本，除此之外，上游表对该表的扫描成本也应该计入。相应的计费分别核算为：计算付费、存储付费和扫描付费。数据资产的成本管理分为数据成本计量和数据使用计费。