扫码关注我，回复【JAVAPDF】 可以获得一份长达200页的面试攻略~

来源:https://www.jianshu.com/u/4383d3901562作者:乌拉乌拉儿

大数据技术与架构

点击右侧关注，大数据开发领域最强公众号！

By 大数据技术与架构

场景描述：这是之前乌拉儿同学简书上发表的一篇文章，现在进行完善，博主是一名来自爱奇艺的数据开发同学，欢迎大家关注他，连接在最上方。本文已经征得作者同意进行转载。

关键词：数据仓库

第一篇：漫谈数仓

什么是数据仓库？以下是百度百科的定义：

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。数据仓库的特征在于面向主题、集成性、稳定性和时变性。

从传统数仓到互联网数仓，有很多相似点也有很多不同点，互联网数仓的发展比较有代表性的就是阿里爸爸了，以下是《阿里大数据之路》中的数据体系架构图。

从上面的阿里体系架构图中可以看出，数仓建模的主要工作在数据计算层，经过计算和整合后的数据才有价值，这个是数仓工作中的主要部分。对数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致性，保证数据的规范性，让数据发挥它的价值。

在数据仓库技术出现前，有很多数据分析的先驱者已经发现，简单的“直接访问”方式很难良好工作，这样做的失败案例数不胜数。下面列举一些直接访问业务系统无法工作的原因：

• 某些业务数据由于安全或其他因素不能直接访问。
• 业务系统的版本变更很频繁，每次变更都需要重写分析系统并重新测试。
• 很难建立和维护汇总数据来源于多个业务系统版本的报表。
• 业务系统的列名通常是硬编码，有时仅仅是无意义的字符串，这让编写分析系统更加困难。
• 业务系统的数据格式，如日期、数字的格式不统一。
• 业务系统的表结构为事务处理性能而优化，有时并不适合查询与分析。
• 没有适当的方式将有价值的数据合并进特定应用的数据库。
• 没有适当的位置存储元数据。
• 用户需要看到的显示数据字段，有时在数据库中并不存在。
• 通常事务处理的优先级比分析系统高，所以如果分析系统和事务处理运行在同一硬件之上，分析系统往往性能很差
• 有误用业务数据的风险。
• 极有可能影响业务系统的性能

数仓的特性：

1.面向主题的，按照一定的主题进行组织，主题是指用户使用数据仓库进行决策时所关心的重点方面，后面会重点举例说明。
2.数据仓库是集成的，数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出来，进行加工和集成之后，进入数据仓库。
3.数据仓库是不可更新的，数据仓库主要是为决策分析供数据，所涉及的操作主要是数据的查询。
4.数据仓库是随时间而变化的，传统的关系型数据库系统比较适合处理格式化的数据，能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存，且不随时间改变。
5.汇总的。操作性数据映射成决策可用的格式。
6.大容量。时间序列数据集合通常都非常大。
7.非规范化的。Dw数据可以是而且经常是冗余的。
8.元数据。将描述数据的数据保存起来。
9.数据源。数据来自内部的和外部的非集成操作系统。

数仓的存在性：

1.相比操作型系统保存数据，dw使用数据，操作型系统反映最新数据状态，dw需收集海量历史数据进行分析;
2.dw可以让业务人员方便的获得数据，有很强的数据服务能力;
3.dw将多个数据源集成到单一数据存储，因此可以使用单一数据查询引擎展示数据，统一口径，以一致的形式展现信息，避免出现指标正确性的争论;
4.dw有良好的扩展性，业务发生变化，需要与历史数据进行完美融合;
5.dw是提高决策制定能力的权威和可信的基础，数据质量是生命线，有质量的数据才有说服力

数仓为什么要分层建模

随着DT时代的到来，数据爆发性增长，如何将数据进行有序、结构化的分类组织和存储是面临的很大的一个挑战。多而杂的数据，会让取数效率低下、口径不一、质量无保障等问题，所以数仓的建模主要解决以下几个问题：
1.性能：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的I/O吞吐。
2.成本：良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果的复用，极大地降低大数据系统中的存储和计算成本。
3.效率：良好的数据模型能极大的改善用户使用数据的体验，提高使用数据的效率。
4.质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。
这四个方面在真正构思模型时还需考虑权衡，可能不能全都达到极致，需利弊对比，采用最合理的方案。

第二篇：数仓方法论

三范式（3NF）：

第一范式（1NF）无重复的列。也叫属性不可分,像学生信息表里学生id,学生姓名，学院id，不能出现学院列，学院列又分为学院文、学院理。
第二范式（2NF）非主属性部分依赖于主关键字。学生信息表中的所有属性都依赖于学生id。
第三范式（3NF）属性不依赖于其它非主属性。学生信息表只能有学院的id(这个是其他主属性)，通过这个学院的id可以和学院的信息表关联，而不能把每个人的学院的所有信息全加上.

OLTP系统数据的主要用的建模方式就是三范式，从而在事务处理中解决数据的冗余和一致性问题。

ER模型（Inmon模型）和维度模型（Kimball模型）

Inmon 模型

Inmon就是数仓之父，他提出的建模方法是从全企业的高度设计一个3NF模型，但是数仓的3NF和OLTP中的3NF的区别在于，它是站在企业的角度面向主题的抽象，而不针对具体业务过程。

他推崇自上而下的建模方式，即从数据源到数据仓库再到数据集市的（先有数据仓库再有数据市场）一种瀑布流开发方法。

Inmon模型以数据源头为导向。首先，需要探索性地去获取尽量符合预期的数据，尝试将数据按照预期划分为不同的表需求。其次，明确数据的清洗规则后将各个任务通过ETL由Stage层转化到DW层，这里DW层通常涉及到较多的UDF开发，将数据抽象为实体-关系模型。接着，在完成DW的数据治理之后，可以将数据输出到数据集市中做基本的数据组合。最后，将数据集市中的数据输出到BI系统中去辅助具体业务。

建模主要步骤：

1.高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况；
2.中层模型：在高层模型的基础上，细化主题的数据项；
3.物理模型：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。

Kimball 模型

Kimball 模型推崇自底向上的设计模式，即从数据集市到数据仓库再到数据源(先有数据集市再有数据仓库)的一种敏捷开发方法。Kimball都是以最终任务为导向。首先，在得到数据后需要先做数据的探索，尝试将数据按照目标先拆分出不同的表需求。其次，在明确数据依赖后将各个任务再通过ETL由Stage层转化到DM层。这里DM层数据则由若干个事实表和维度表组成。接着，在完成DM层的事实表维度表拆分后，数据集市一方面可以直接向BI环节输出数据了，另一方面可以先DW层输出数据，方便后续的多维分析。

Kimball典型的代表是星型模型与雪花模型，后面会在详细的聊一下。

建模主要步骤：

1.选择业务过程，业务过程可能是交易的支付、下单等，也可能是当前用户余额等。
2.选择粒度，粒度是维度的组合，类比：国家粒度、城市粒度。
3.识别维表，通过选择的粒度从而设计好维表。
4.选择事实，确定分析需要的指标。

Inmon模型从数据本身出发构造模型，对数据规范的要求更高，设计性也要更好，在多变的互联网里是很难出结果的，但是Kimball模型从业务需求出发设计模式，更加适合互联网数仓。

第三篇：事实表与维度表

事实表，发生在现实世界中操作型时间，其产生的可度量数值，存储在事实表中，例如交易订单表。一般有以下几种事实特性：

1.可加、半可加、不可加事实 。可加，例如pv(点击量) ；半可加，例如数值差额，uv(用户量)；不可加，例如比率。

2.NULL值处理。可以存在空值度量，但是外键不能存在空值，须用默认行而不是空值外键表示未知的或无法应用的条件。

3.事实一致性。不同事实表中的事实，应保证事实的定义是相同的，且具有相同的命名，如果不兼容，则须用不同命名方式，便于应用

4.周期事实。某天、某周等周期性，周期内未发生过程，也会有null或0等事实；

5.累计事实，开始与结束之间可预测步骤内的度量事件；

6.无事实的事实，比如：某天学生参加课程的事件；

7.聚集事实，聚合，提高查询性能；

8.合并事实，同粒度表进行合并；

维度表，对于物体属性描述的表，例如商品信息表，城市信息表，时间维度表等。有一些概念需了解下

1.维度下钻：例子：如果我知道上海市的数据，但是我想查看各区的数据，维度级别变细，称为下钻，相反称为上卷。

2.退化维度：维度除了主键外无其他内容，例如订单号，发票号

3.非规范化扁平维度：将多张范式表 合并成统一的扁平的非规范化的维度，能够实现维度建模的双重目标：简化与速度，比如将一张商品表，和一张商品分类信息表合并成一张表

4.维度层次：比如 年月日， 国家 省份 城市 等

5.维度表空值属性，当给定维度行没有被全部填充时，或者当存在属性没有被应用到所有维度行时，将产生空值维度属性。可以用描述性的字符串替代空值，例如Unknown等，应避免维度属性使用空值，因为不同的数据库系统在处理分组和约束时，针对空值的处理方法不一致，与事实表关联时也可能关联不上

6.文档属性的标识与指示器， Magic 的缩写或数字的维度字段，应有对应的中文解释字段，比如city_id,city_name

7.日期维度，能够对事实表，按照日期，节日等进行数据导航。

第四篇：事实表与维度表

星型模型与雪花模型，应该是数仓面试者最喜欢提的问题，也是比较容易理解的概念。

星型模型是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，例图如下：

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 “层次 “ 区域，这些被分解的表都连接到主维度表而不是事实表。如下图，将地域维表又分解为国家，省份，城市等维表。它的优点是 :通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

在建模时选择星型模型还是雪花模型还是需要斟酌些，目前在很多公司很推崇星型模型，但是在我目前工作中遇到需要雪花模型的使用，看是否利大于弊，择优选择模型，不能认真的倔强。

第五篇：数仓建模

从业中，数仓建模是一个数仓工程师需要的必备的能力，优秀的分层设计能够让整个数据体系更易理解和使用。所以想入行数仓数仓分层是需要补一补的，才能知道分层的意义。

很多人都不理解为什么分层，分层的意义是什么，分层有这么重要吗？是的就是这么重要，说一下我的理解：

1.理清业务数据：随着数据量和业务数据表的不断扩张，需要我们理清数据作用域，就是做什么的，可以清晰的找到数据来源。

2.避免重复计算：为了避免多次计算，多次关联多张表，分层可以保存中间结果，减小开发成本。

3.增加数据使用便捷性：仓库层的设计，让数据能分析，好分析，能支持大部分的数据需求。

4.避免数据分歧：统一数据口径，保证数据质量，避免出现统一指标多种概念。

比较通用的简单的维度建模分层，分为三层：

一、ODS层，操作数据层

把操作系统的数据几乎无处理的存放在数仓中，主要有以下工作：

1.将业务结构化数据增量或全量的同步进来；

2.将日志等非结构化的数据结构化处理后落地到数仓中；

3.累计历史数据，根据数据业务需求、审计等要求保存历史数据、清洗数据，保留的数据快照也便于回溯问题。

二、CDM层，公共维度模型层

存放明细事实数据、维度数据及公共指标汇总数据，统一口径，保持数据一致性，减少数据重复计算，CDM层分为DWD层和DWS层。

1.DWD层,明细数据层

dwd层对业务数据进行清洗、规范化，例如去除作弊数据，对数据字段进行规范命名从而避免歧义化等，另外可采用维度退化手段，将维度退化到事实表中，减少事实表与维度表的关联，提高明细表的易用性。

2.DWS层,汇总数据层

dws层，加强指标的维度退化，采用更多的宽表化的手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。

三、ADS层，应用数据层

ads层存放数据进行个性化的指标计算，不共用性、复杂性（指数型、比值型、排名型）等，会基于应用数据组装，像大宽表集市、横标转纵表、趋势指标串等，另外由于ADS某些指标具有个性化的特点，尽量不对外提供服务。

1.ods层会将各种日志数据及业务库中数据或者其他一些数据，进行数据落地。

2.dwd层，像用户登录表，会做以下一些操作

2.1去除爬虫等异常数据，保持数据质量

2.2规范统一数据字段

2.3拆解需拆解的字段

2.4融合各端数据

3.dws层，像用户主题表，会做以下一些操作

3.1统计操作轨迹用户数数据

3.2统计用户购买商品数，登录次数，订单数，退货数，

3.3增加用户维度，时间维度

4.ads层，像用户转化漏斗，可以利用dws层数据进行维度分析，分析漏斗，为产品做决策

建模的基本原则

简单讲建模的一些原则，在建模的考虑中需要加以考虑，避免后续遇到大坑措手不及，而不要简单的为了建模而建模。

1.高内聚&&低耦合

主要从数据业务特性和访问特性两个角度来考虑:

将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型；

将高概率同时访问的数据放一起 ，将低概率同时访问的数据分开存储。

2.核心模型与扩展模型分离

核心模型包括的宇段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不要让扩展模型包括的字段过多的入侵核心模型，破坏核心模型的性能及简洁等

3.存储成本与计算性能均衡

在很多时候，设计可能清晰，但存储成本很高，或存储成本很小但计算逻辑复杂，性能差，都需要做一个比较，做到均衡，而非执意孤行。

4.公共逻辑下沉及统一

避免重复计算，需将公共逻辑在底层实现并统一口径

5.幂等性

处理逻辑不变，多次执行结果需保持一致。

6.规范性

相同含义字段需在多表中命名一致，表命名需清晰规范，便于查询及使用，后续将统一讲数仓规范。

第六篇：数仓规范

数仓规范，看似是无关紧要，实则是数仓实施最重要要素，也是衡量数仓标准的重要条件，有了规范，才能尽可能避免一些坑。

1.模型分层

参考【数仓建模】

2.表命名规范

ods层：数据引入层

日志类非结构化表：ods_[数据域]_ [自定义内容]_ [刷新频率]

业务库结构化同步表：ods_[数据域]_ [业务库名]_ [表名]_[刷新频率]

dwd层：明细数据层

dwd_[数据域] _[自定义内容] _[粒度] _[刷新频率]

dws层：公共汇总层

dws_{数据域}_[主题域] _[自定义内容] _[粒度] _[刷新频率]

ads层： 数据应用层

ads_{数据域}_ [自定义内容]_ [粒度]_[刷新频率]

组合标记标记含义ma按月分区全量更新mi按月分区增量更新da按天分区全量更新di按天分区增量更新ha按小时分区全量更新hi按小时分区增量更新

3.字段规范

3.1命名

• 小写
• 下划线分割
• 可读性优于长度
• 数量字段后缀 _cnt等标识...
• 金额字段后缀 _price 标识
• 禁止使用sql关键字

3.2字段格式

• 浮点数使用decimal(28,6)控制精度等

3.3 NULL字段处理

• 对于维度字段，需设置为-1
• 对于指标字段，需设置为0

4.外部表规范

• 使用hive外部表，避免误操作行为
• 压缩方式，使用orc、parquet文件格式 gz压缩 等

5.口径规范

保证主题域内，指标口径一致，无歧义

欢迎点赞+收藏+转发朋友圈素质三连

文章不错？点个【在看】吧！