OneData 数据仓库建设：阿里大数据治理方法论全面解析
OneData 是阿里巴巴在大数据开发与治理领域长期实践沉淀出的方法论体系，核心理念涵盖 OneModel（统一数据模型）、OneService（统一数据服务）和 OneID（统一数据标识）。这一体系旨在解决数据治理中的典型挑战：
- 数据孤岛：各产品线与业务的数据彼此隔离，难以通过统一的公共标识打通；
- 重复建设：重复的开发、计算和存储导致高昂的数据成本；
- 数据歧义：指标定义口径不一致，引起统计偏差与应用困难。
一、整体实施思想与流程
首先，必须进行深入的业务调研与需求分析，这是所有工作的基础。
其次，进行数据整体架构设计，重点是基于数据域划分数据；按照维度建模理论，构建总线矩阵，抽象出业务过程和维度。
接着，对报表需求进行梳理，提炼出指标体系，利用 OneData 工具完成指标定义规范和模型设计。最后，进行代码研发与运维。
整体实施流程可归纳为：数据调研、架构设计、规范定义以及模型设计。
二、业务与需求全量调研
1. 业务调研
需要明确计划纳入数据仓库的业务领域，以及每个业务领域内的功能模块。以阿里巴巴的业务为例，可以梳理如下矩阵：
2. 需求调研
了解需求方关注哪些核心指标，期望从哪些维度、度量进行分析，数据是否需要沉淀到汇总层等。
三、数据架构关键设计步骤
1. 数据域的划分
数据域是对业务过程或维度进行抽象后的集合。一般而言，数据域与应用系统（功能模块）存在关联，可以考虑将同一功能模块下的业务过程归入一个数据域：
2. 构建总线矩阵
在完成详尽的业务调研和需求调研后，需要构建总线矩阵，主要包含两项任务：
- 明确每个数据域下有哪些具体的业务过程。
- 明确业务过程与哪些维度相关，并通过总线矩阵定义每个数据域下的业务过程和维度关系：
四、指标体系的设计与规范
1. 基本概念
数据域：面向业务分析，将业务过程或维度进行抽象集合而成。
业务过程：指企业业务活动中的事件。
时间周期：用于明确数据统计的时间范围或时间点，例如近 30 天、截至当前等。
修饰类型：对修饰词的一种抽象划分。
修饰词：除统计维度外，指标的业务场景限定抽象。修饰词隶属于某种抽象类型，例如访问终端类型下的 PC、安卓、苹果。
度量/原子指标：有明确业务含义的业务名词。如支付金额。
维度：维度是度量的上下文环境，反映业务的一类属性，这类属性的集合构成一个维度，也可称为实体对象，例如地理维度、时间维度。
维度属性：对维度的描述，隶属于某一维度。例如地理维度下的国家、省份。
派生指标：原子指标 + 多个修饰词（可选）+ 时间周期。
必须清晰定义原子指标、修饰词、时间周期和派生指标的概念。
2. 操作细则
派生指标主要来源于三类指标：事务型指标、存量型指标和复合型指标。
事务型指标：用于衡量业务活动的指标。
存量型指标：对实体对象某些状态的统计。
复合型指标：基于前两种指标复合计算而成。
五、模型设计的分层架构
1. 数据分层
业界对数据仓库分层的看法基本一致，普遍认为分为接入层、中间层和应用层三层，但对中间层的具体理解略有差异。
2. 接入层（ODS）
业务数据通常使用 DataX 或 Sqoop 等工具，按照固定频率同步到数据仓库，构建 ODS 层；
日志数据则通过 Flume 或 Kafka 等实时导入数据仓库。
接入层通常不会对源数据进行任何处理或清洗，以便于后续的数据回溯。
3. 明细层（DWD）
理论上，明细层数据是对 ODS 层数据进行清洗加工，提升 ODS 层数据的可用性。关于 DWD 层是否允许同层引用的观点需要权衡：
- 一般情况下，DWD 层不建议同层引用，这样能减少明细层任务之间的依赖，降低节点深度。
- 但在某些场景中，从 ODS 层到 DWD 层的数据加工逻辑极其复杂，计算开销巨大，此时可以权衡考虑适当复用 DWD 表来构建新的 DWD 表。
4. 汇总层（DWS）
这一层依赖于指标体系，将 DWD 层的数据按各个维度进行聚合计算。
5. 数据集市层（DWM）
当存在跨业务域的聚合统计需求时，数据会放置在这一层。
6. 应用层（APP）
这一层主要针对汇总层，进行相关指标的组合，并生成报表。
六、维度设计的核心方法
维度建模中，度量被称为事实，维度则是分析事实所需的各种环境。维度的作用主要体现在查询、分类汇总以及排序上。
通过报表的约束条件、前期的数据调研以及与业务方的沟通，我们可以获取维度。
维度通过主键与事实表关联，维度表的主键分为代理键和自然键。代理键不具备业务含义，通常用于处理缓慢变化维度；自然键则具有业务含义。
1. 维度设计基本方法
- 选择或新建一个维度。通过总线矩阵的构建，我们能掌握目前数仓架构中包含的维度。
- 确定主维表。这里的主维表通常是 ODS 表，直接与业务系统同步。
- 确定相关维表。数据仓库集成多个业务源系统的数据，不同系统或同一系统内的表存在关联性。根据业务梳理，可以识别出哪些表与主维表有关联，并选择其中某些表用于生成维度属性。
- 确定维度属性。此步骤分为两个阶段：第一阶段从主维表中选择维度属性或生成新的维度属性；第二阶段从相关维表中选择维度属性或生成新的维度属性。
2. 规范化与反规范化
当维度属性具有多个层次，按照第三范式进行规范化后，会形成一系列维度表，而非单一维度表，这种建模方式称为雪花模式。
将维度的多个属性层次合并到单个维度中的操作，称为反规范化。
3. 一致性维度与交叉探查
很多需求需要将不同数据域的业务过程，或者同一数据域的不同业务过程合并观察。例如：在日志数据域统计商品维度近一天的 PV 和 UV；在交易数据域统计商品维度近一天的 GMV。
将不同数据域的商品事实合并在一起进行数据探查，称为交叉探查。
数据仓库能够支持交叉探查的前提是，不同数据域必须拥有一致性维度。
4. 维度整合
由于数据仓库的数据源来自不同的应用系统，各系统相对独立，对同一信息的描述和存储可能存在差异。
这些差异数据进入数仓后需要整合：
- 命名规范的统一。表名、字段名等需要统一。
- 字段类型的统一。相同或相似字段的字段类型需统一。
- 公共代码及代码值的统一。
- 业务含义相同的表的统一。主要依据高内聚、低耦合的理念，将业务关联度高、源系统影响差异小的表进行整合。
表级别的整合主要有两种形式：
垂直整合，即不同来源表包含相同的数据集，但存储的信息不同，可以整合到同一维度模型中。
水平整合，即不同来源表包含不同的数据集，这些子集之间可能无交叉或存在部分交叉；若有交叉则需去重；若无交叉，则考虑不同子集的自然键是否冲突，不冲突的话可以将各子集自然键作为整合后的自然键，或者将各自然键加工成一个超自然键。
5. 拉链表
拉链表，也称为极限存储技术。假设某张表用于存储全量用户信息，通常的做法是用每个分区保存每天全量数据的快照。这种方式的问题在于，若希望保留用户的所有历史状态，可能需要永久保存每一个历史分区。
若使用拉链表，每个分区可以保存每个用户在当天的历史状态，同时历史分区也可以被清理。
这样，虽然单个分区中存储的数据量变大了，但当某些历史分区被清理后，整个表存储的数据总量会减少，因为大量未发生变化的用户信息快照被移除了。
6. 微型维度
微型维度的创建，是通过将一部分不稳定的属性从相对稳定的主维度中剥离出来，放置到拥有自己代理键的新表中来实现的。
7. 递归层次
递归层次是指某维度表中实例值的层次关系。维度的递归层次分为有固定级别数量的均衡层次结构和无固定级别数量的非均衡层次结构。
由于数据仓库通常不支持递归 SQL 来处理这种层次结构，所以需要采用其他方式：
- 层次结构扁平化，适合均衡层次结构维度。
- 层次桥接表，适合非均衡层次结构维度。
8. 多值维度
多值维度指的是事实表中的一条记录，在某个维度表中对应多条记录。
针对多值维度，常见的处理方式有三种：
- 降低事实表的粒度。
- 列扩展。
- 较为通用的方法是采用桥接表。
9. 杂项维度
杂项维度通常由操作型系统中的指示符或标志字段组合而成，一般不属于一致性维度范畴。
如果将这些维度作为事实直接存储在事实表中，会导致事实表占用空间膨胀；如果单独建立维表，则会产生大量零碎的小维表。
此时，常见的解决方案是建立杂项维度，将这些字段统一放入一张维表中，事实表只需保存一个外键即可。杂项维度可以理解为将许多小维表通过行转列的方式存储到一张大维表中的处理技术。
10. 退化维度
退化维度是指直接将维度属性存储到事实表中的维度。
七、事实表设计的策略与类型
事实表中，一条记录所表达的业务细节程度称为粒度。
1. 事实类型
作为度量业务过程的事实，通常具备三种类型：可加性、半可加性和不可加性。
可加性事实：可以按照与事实表关联的任意维度进行汇总。
半可加事实：只能按照特定维度进行汇总，无法对所有维度汇总。
不可加性事实：完全不具备可加性，例如比例型事实。对于不可加性事实，可考虑将其分解为可加的组件来实现聚合。
2. 事实表类型
最常见的事实表有三种：事务事实表、周期快照事实表和累积快照事实表。
事务事实表用于描述业务过程，记录在特定时空点上发生的度量事件，保存的是最原子的数据，也被称为原子事实表。在实际应用中，通常用于明细层，例如下单明细、支付明细等。
周期快照事实表的一行，以规律性的时间间隔记录事实。例如每日库存快照表、每日用户余额快照表。
累积快照事实表用来描述过程从开始到结束之间的关键步骤事件，覆盖过程的全生命周期，通常包含多个日期字段来记录关键时间点。随着过程在生命周期中不断推进，记录也会随之更新。以上述订单为例，可以构建一张涵盖订单下单、推单、抢单、支付等各环节的订单全生命周期快照表。
此外，还有一种无事实的事实表，它仅记录某个动作的发生，其事件的量化不是数字型的，比较典型的例子是访问点击日志。
3. 事实表设计原则
- 尽可能包含所有与业务过程相关的事实。
- 只选择与业务过程相关的事实。
- 将不可加性事实分解为可加的组件。
- 在选择维度和事实之前，必须先声明粒度。
- 同一事实表中不能存在多种不同粒度的事实。
- 事实的单位需要保持一致。
- 对事实的 null 值要进行处理，建议用 0 填充。
- 使用退化维度以提高事实表的易用性。
4. 事实表设计方法
- 选择业务过程并确认事实表类型。
- 声明粒度。
- 确定维度。
- 确定事实。
- 冗余维度。
5. 事实表（单事务与多事务）
单事务事实表：为每个业务过程单独设计一张事实表，这便于对每个业务过程进行独立分析。
多事务事实表：将不同的事实放入同一张事实表中，即同一张事实表包含不同的业务过程。
多事务事实表有两种事实处理方式：
- 不同业务过程的事实使用不同的事实字段存放；若不是当前业务过程的度量，可考虑用 0 值填充。
- 不同业务过程的事实使用同一个事实字段存放，但增加一列作为业务过程标签，记录该笔事务是否在当天完成。
在决定采用哪种处理方式时：
当各业务过程的度量较为相似、差异不大时，可采用第二种多事务事实表设计方式，使用同一字段表示度量数据。但这种方式的不足在于，同一周期内会存在多条记录。
当不同业务过程的度量差异较大时，可选择第一种多事务事实表设计方式，将不同业务过程的度量用不同字段冗余到表中，非当前业务过程的字段则置为 0。这种方式存在的问题是度量字段中 0 值会较多。
究竟使用单事务事实表还是多事务事实表，需要从以下几方面分析：
- 业务过程
多个业务过程能否放入同一张事实表，首先要分析它们之间的相似性和业务源系统。
例如，淘宝交易的下单、支付和成功完结三个业务过程存在相似性，且都来自同一应用系统——交易系统，适合放入同一张事务事实表。
- 粒度和维度
考虑采用单事务表还是多事务表时，一个关键点是粒度和维度。
在确定业务过程后，需要针对不同业务过程确定粒度和维度。当不同业务过程的粒度相同且拥有相似维度时，可考虑采用多事务事实表。如果粒度不同，则必须存储在不同的表中。
- 事实
如果单个业务过程包含较多事实，且不同业务过程的事实又不相同，则建议使用单事务事实表，处理逻辑更清晰；
如果采用多事务事实表，可能导致表内大量事实字段为零值或空值。
- 下游业务使用
单事务事实表对下游用户而言更容易理解——关注哪个业务过程就使用相应的事实表；而多事务事实表包含多个业务过程，用户使用时往往容易混淆。
6. 周期快照事实表
事务事实表能够很好地跟踪一个事件并进行度量分析。
然而，当需要状态度量时，例如账户余额、商品库存、卖家累积交易额等，就需要聚合与之相关的大量事务才能完成计算，这时就需要使用周期快照事实表。
周期快照事实表在确定的时间间隔内对实体的度量进行抽样，以便研究实体的度量值，无需聚合长期的事务历史。
7. 累积快照事实表
对于类似研究事件之间时间间隔的需求，事务事实表的处理逻辑复杂且性能较差，采用累积快照事实表可以很好地解决这类问题。
累积快照事实表中收集到的状态度量都是半可加的，无法根据时间维度获得有意义的汇总结果。
数据仓库在进行维度建模时，通常会将事务事实表和快照事实表成对设计，互为补充，以满足更多下游的统计分析需求，特别是在事务事实表的基础上可以加工出快照事实表。
八、其他开发与管理规范
1. 层次调用约定
- 应用层应优先调用公共层数据。
- 已存在的中间层数据，不允许应用层跨过中间层从 ODS 层重复加工数据。
- 中间层团队应主动了解应用层的数据建设需求，将公用数据沉淀到公共层，为其他团队提供数据服务。
- 应用层团队需积极配合中间层团队完成数据公共层建设的改造和迁移。
- 必须避免过度使用 ODS 层引用，以及不合理的数据复制和子集冗余。
2. 命名规范
表命名规范：<层次><业务域名称><数据域名称><业务过程名称|自定义表名><刷新周期+存储策略>
字段命名规范：
3. 开发规范
- 总原则
- 原则上不能依赖非数据团队节点。
- 未获得节点 owner 许可的情况下，不能擅自修改别人的节点。
- 不能随意变更节点 owner，必须通知接收人并获得同意。