互联网行业的数仓建设基本上借鉴传统行业的IBM/TD方法论，只是建模方法在原有的基础上增加了Valut和Anchor。数仓的方法论总结如下：
1.数据仓库模型设计
按模型层次和建模顺序划分为：业务模型、领域模型、逻辑模型和物理模型。
1.1.业务建模
- 划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
- 深入了解各个业务部门的内具体业务流程并将其程序化。
- 提出修改和改进业务部门工作流程的方法并程序化。
- 数据建模的范围界定，整个数据仓库项目的目标和阶段划分。
1.2.领域概念建模
- 抽取关键业务概念，并将之抽象化，一般按照主数据和业务数据梳理。
- 将业务概念分组，按照业务主线聚合类似的分组概念。
- 细化分组概念，理清分组概念内的业务流程并抽象化。
- 理清分组概念之间的关联，形成完整的领域概念模型。
1.3.逻辑建模
- 业务概念实体化，并考虑其具体的属性
- 事件实体化，并考虑其属性内容
- 说明实体化，并考虑其属性内容
- 理清实体和实体的业务关系，创建实体关系图
2.数据仓库建模方法
2.1.ER模型
也称之为范式建模，一般是3NF。根据 Inmon 的观点，数据仓库模型得建设方法和业务系统的企业数据模型类似。在数仓采用范式建模，构建核心业务的基础数据层，保障数据服务的一致性、提高数据质量。但是对建模人员的要求比较高，比如精通业务细节，耗费的时间也比较多。对于核心业务的数据一致性和质量保证是值得的。
2.2.维度建模
Kimball提出的维度化建模方法论，按照事实表，维表来构建数据仓库。维度化模型非常直观，紧紧围绕着业务模型，而且查询效率相对ER模型高。但是，需要进行大量的数据预处理，因此会导致大量的数据处理工作，而且业务的应变较差，数据冗余较大(在大数据领域这点可忽略)。
2.3.实体关系建模
该建模方法一般在业务建模和领域概念建模阶段。
- 实体，主要指领域模型中特定的概念主体，指发生业务关系的对象。
- 事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。
- 说明，主要是针对实体和事件的特殊说明。
2.4.Data Vault
Data Vault模型显式地将结构信息和属性信息分离， 能够还原业务环境的变化。它综合了第三范式（3NF）和星型模型优点的建模方法，包含 Hub、Link、Satellite和Point-In-Time四个组件。不多说，看如下的模型，基本清楚了一二。
这种模型适合场景：适合敏捷或快速迭代、利于审计的业务场景，不影响整体模型稳定性。它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。
Data Vault保留了3NF和维度建模的优点，例如结构灵活易于扩展，加载数据方便可追溯历史等。当然他引入了这些方案的一些缺点，例如因更细化的拆分而增加的对象，对象多也会存在大量的连表性能问题，而且使用Data Vault模型时对建模人员的要求比较高等。
2.4.Anchor
Anchor对Data Vault模型做了进一步规范化处理。其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到6NF，基本变成了k-v结构化模型。
Anchors：类似于Data Vault的Hub，代表业务实体，且只有主键。
Attributes：功能类似于Data Vault的Satellite，但是它更加规范化，将其全部k-v结构化，一个表只有一个Anchors的属性描述。
Ties：就是Anchors之间的关系，单独用表来描述，类似于Data Vault的Link，可以提升整体模型关系的扩展能力。
Knots：代表那些可能会在多个Anchors中公用的属性的提炼，比如性别、状态等这种枚举类型且被公用的属性。
这是阿里巴巴实践的Anchor模型，鄙人 没有实践经验，不是很清楚使用场景和落地实用性，欢迎各位发表见解。