数据仓库分层4层模型？数据仓库

今天给各位分享数据仓库分层4层模型的知识，其中也会对数据仓库进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

浅析数据仓库的构建方法

浅析数据仓库的构建方法

随着不同的管理信息系统（MIS）在企业不同部门的大规模应用及企业对数据管理不断提出新的要求，不仅要求能实现传统的联机事务处理，而且越来越多的要求是各种应用系统能够在企业不断积累的以及从企业外部获取的丰富信息资源的基础上，把这些分散的、不一致的、凌乱的信息资源加以利用，即更多地参与数据分析和决策支持，由此出现了一种用于数据分析处理和决策支持的数据存储和组织技术，即数据仓库技术。

1、什么是数据仓库

数据仓库是面向主题的、集成的、具有时间特征的、稳定的数据集合，用以支持经营管理中的决策制定过程。数据仓库提供用户用于决策支持的当前和历史数据，这些数据在传统的操作型数据库中很难或不能得到。

面向主题是指数据仓库中的数据是按照一定的主题域进行组织。主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。集成的是指数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

数据仓库的体系结构分数据源、数据转换、数据仓库、数据集市和用户几部分。数据源，包括企业内部的业务数据、遗留数据、其它业务系统数据及相关WEB数据等；数据转换是数据仓库构建的重要环节，主要是对各种复杂的数据源进行抽取、转换、装载及其他处理，同时要实现数据质量跟踪监控以及元数据抽取与创建等工作；数据仓库主要实现对各种数据的组织、存储及管理等；数据集市是为不同业务而单独设计的数据仓库系统，即开发者为企业内部的不同用户群定制特殊的数据仓库子系统。用户部分，即具体面向使用者的应用部分，主要是指数据仓库存取与检索为用户提供了访问数据仓库或数据集市的功能，其中分析与报告为用户使用数据仓库提供了一组工具，用于帮助用户对数据仓库或数据集市进行联机分析或数据挖掘等。

2、数据仓库构建方法

2.1普通数据仓库构建方法。对于普通数据仓库的构建，企业在对整个系统的建设综合各种因素的基础上，将整个项目的实施分阶段、分步骤实施，可以在每一阶段建设的基础上分阶段纳入不同的业务系统，逐步建立起一个综合的、专题较为完善的、适合部门、子单位使用的完整的数据仓库系统，从而才能使投资尽快获得收益。

在数据仓库的构建过程中，利用模糊数学可实现数据仓库内数据的语义表示，丰富数据加工的手段，提高分析处理的能力。数据仓库的构建，一般采取先构建数据集市，最后将各个数据集市整合在一起形成数据仓库的渐进模式；通过概念层、逻辑层、物理层建模，确定相关主题域的数据集市并对其进行联机分析处理。构建数据仓库模型一般采用以下几种：

2.1.1星型模型：星型模型是最常用的数据仓库设计结构的实现模式。使数据仓库形成了一个集成系统，为用户提供分析服务对象。该模型的核心是事实表，围绕事实表的是维度表。通过事实表将各种不同的维度表连接起来，各个维度表都连接到中央事实表。[page] 2.1.2星系模型（也称雪花模型）：雪花模型对星型模型的维度表进一步标准化，对星型模型中的维度表进行了规范化处理。同时也是对星型模型的扩展，每一个维度都可以向外连接到多个详细类别表。在实际应用中，用户的需求多种多样，数据来源可能为多个事实表，故可采用多个事实表共存，之间通过公用的维表相关联的星系模型，也称为事实星座。

2.1.3原子级数据模型和汇总级数据模型并存：坚持原子级数据模型和汇总级数据模型并存，而且要尽可能地细化原子级数据。

2.1.4设立代理键：代理键是维表中一些没有业务含义的字段，只是一个由数据仓库加载程序时建立的数字。

2.2空间数据仓库构建方法。随着GIS（地理信息系统）在各行业的广泛应用，最初面向事务处理为主的空间数据库信息系统已不能满足需要，信息系统开始从管理转向决策处理，空间数据仓库就是为满足这种新的需求而提出的空间信息集成系统。尤其是地理信息决策支持系统中，空间数据仓库系统显得尤为重要。

空间数据仓库具有普通数据仓库的普遍特征，但其本身有一些特殊性。并且空间数据仓也并不是空间数据库的简单集合。与空间数据库比，空间数据仓除支持数据库外，还支持数据文件、文本文件、应用程序等众多数据源；另外空间数据仓库中的数据有时间数据、空间数据、属性数据及异构数据等多种数据；其次空间数据仓库中还包括了数据处理规则、算法等；再次空间数据仓库的数据是对原始数据进行加工、处理、集成等转换，是对数据的增值和统一；空间数据库还引入了时间纵的概念，它是以时间为基准来管理数据，可以截取不同时间尺度上的信息，从瞬态到区段时间直到全体，空间数据仓库是依赖于时间维的数据结构，它可以根据不同的需要划分不同的时间粒度等级，以便进行各种复杂的趋势分析。当然，不言而喻，它还包含了空间维的方位数据。正因为空间数据仓库与普通数据仓库的不同，并且它以空间数据仓库完全不是相同的概念，一般空间数据仓库以如下体系结构分为四大功能模块，分别是源数据、数据变换工具、空间数据仓库、客户端分析工具。源数据它不仅指那些常见的空间数据库，还包括文件、网页、知识库、遗留系统等各种数据源。数据变换工具与具有普通数据仓库数据变换相同的提取转换功能，但它还包括了特有的空间变换等。空间数据仓库以立体、多维的方式来组织和显示数据。但最基本的空间维和时间维是其反映客观世界动态变化的基础，空间数据仓库技术最关键要点也就是时间维和空间维数据组织方式。目前空间数据仓库已成为国、内外GIS（地理信息系统）研究的热点并取得了较大进展。要把空间信息融合进企业现有的数据仓库中，在原有系统不作较大改动的前提下，一般采用三种模式构建企业空间数据仓库：（1）把空间信息作为多维模型中的空间维引入；（2）把空间信息作为研究主题引入；（3）在维和度量中都包含空间信息。因此，计算并存储所有空间度量是不现实的。一般使用空间索引树（如R-tree）在最细空间粒度上构建分组层次，作为空间维的分层，每个空间维需要建立一棵空间索引树。

3、结束语

总之，数据仓库构建是数据仓库技术的关键，数据仓库技术是一项基于数据管理和利用的综合性技术和解决方案，尤其是现在空间数据仓库在GIS中的广泛应用，它成为数据库市场的新一轮增长点，同时也成为下一代信息系统的重要组成部分。

数仓建模分层理论

这篇文章较为完整、清晰的讲述了数仓建模分层理论，要点如下：

1、分层的意义：清晰结构体系、数据血缘跟踪、减少重复开发、复杂问题简单化及统一数据口径

2、ODS：用作缓冲，可以存一周左右，跟DWD大多重复，留存的目的还在于保持跟源端一致，方便追溯

3、DWD：针对ODS做数据的清洗和整合，在DWD层会根据维度模型，设计事实表和维度表，DWD层是一个非常规范的、高质量的、可信的数据明细层

4、DWS：基于DWD层形成某一主题的轻度汇总表或分析宽表，DWS形成大量维度退化的事实表以提高易用性，DWS层应覆盖80%的应用场景

5、TDM：标签层，通过统一的ID-Mapping把各个业务板块，各个业务过程中同一对象的数据打通，形成对象的全域数据标签体系，方便深度分析、挖掘、应用，大家注意，这个ID不仅仅指客户或用户ID，也包括其它的主数据ID，其是全流程分析的基础

6、ADS：数据应用层ApplicationDataService面向业务定制的应用数据，主要提供给数据产品和数据分析使用的数据，一般会放在ES，MYSQL，Redis等前端系统供线上系统使用，也可以放在Hive中供数据分析和数据挖掘使用

7、DM：主要是提供数据产品和数据分析的数据，主要解决部门用户报表和分析需求而建立数据库，数据集市就代表数据仓库的主题域。DM是面向单个主题的，所以它不会从全局考虑进行建设。

强烈推荐阅读！

正文开始

简单点儿，直接ODS+DM就可以了，将所有数据同步过来，然后直接开发些应用层的报表，这是最简单的了；当DM层的内容多了以后，想要重用，就会再拆分一个公共层出来，变成3层架构,这个过程有点类似代码重构，就是在实践中不断的进行抽象、总结。

数仓的建模或者分层，其实都是为了更好的去组织、管理、维护数据,所以当你站在更高的维度去看的话，所有的划分都是为了更好的管理。小到JVM内存区域的划分，JVM中堆空间的划分(年轻代、老年代、方法区等)，大到国家的省市区的划分，无一例外的都是为了更好的组织管理。

所以数仓分层是数据仓库设计中十分重要的一个环节，优秀的分层设计能够让整个数据体系更容易理解和使用。

这一节，我们主要是从整体上出发进行分析和介绍，就和上一节数仓建模方法论一样，进度对比分析，更多细节的东西我们后面会单独拆分出来，用案例进行演示，例如维度建模，维度表的设计，事实表的设计、以及如何设计标签、如何管理标签等等。

每一个数据分层都有它的作用域，这样在使用表的时候能更方便的定位和理解。

由于最终给业务呈现的是一个能直接使用的业务表，但是表的数据来源有很多，如果有一张来源表出问题了，我们希望能够快速准确的定位到问题，并清楚它的影响范围，从而及时给到业务方反馈，从而将损失降到最低。

将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

过数据分层提供统一的数据出口，统一对外输出的数据口径，这往往就是我们说的数据应用层。

前面我们说到分层其实是为了更好更快更准的组织管理，但是这个是从宏观上来说的，接下来我们从微观上也来看一下分层。

越靠上的层次，对应用越友好,比如ADS层，基本是完全为应用设计,从数据聚合程度来讲，越上层的聚合程度越高，当然聚合程度越高可理解程度就越低。

数仓层内部的划分不是为了分层而分层，分层是为了解决 ETL任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题，当然我们常说的分层也是面向行业而言的，也是我们常用分层方法，但是你需要注意的是分层仅仅是手段而已。

ODS全称是 OperationalDataStore，操作数据层存储的是面向业务系统的数据，也是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL之后，装入本层。

本层的数据，总体上大多是按照源头业务系统的分类方式而分类的，前面我们说到为什么在数仓主要用维度建模的情况下，我们依然要学习范式建模呢，因为我们的数据源是范式建模的，所以学习范式建模可以帮助我们更好的理解业务系统，理解业务数据，所以你可以认为我们的ODS层其实就是用的实范式建模。

这里的数据处理，并不涉及业务逻辑，仅仅是针对数据完整性以及重复值和空值的处理，其实就是做的是数据规约，数据清洗，但是为了考虑后续可能追溯数据源问题，因此对这一层不建议做过多的数据清洗工作，原封不动接入源数据即可，至于数据的去噪，去重，异常值处理等过程可以放在后面的DW层

表名的设计 ODS_业务系统_表名_标记，这样的设计可以保持与业务表名一致，又可以有清晰的层次，还可以区分来源。标记一般指的是其他数仓特有的属性，例如表是天级的还是小时的，是全量的还是增量的。

ods的设计可以保证所有的数据按照统一的规范进行存储。

DW是数据仓库的核心，从ODS层中获得的数据按照主题建立各种数据模型。DW又细分数据明细层DWD和轻度汇总层DWS

这一层和维度建模会有比较深的联系，业务数据是按照业务流程方便操作的角度来组织数据的，而统一数仓层是按照业务易理解的角度或者是业务分析的角度进行数据组织的，定义了一致的指标、维度，各业务板块、数据域都是按照统一的规范来建设，从而形成统一规范的标准业务数据体系，它们通常都是基于Kimball的维度建模理论来构建的，并通过一致性维度和数据总线来保证各个子主题的维度一致性。

公共层的维度表中相同维度属性在不同物理表中的字段名称、数据类型、数据内容必须保持一致，因为这样可以降低我们在使用过程中犯错误的概率，例如使用了不正确的字段，或者因为数据类型的原因导致了一些奇怪的错误

将维度所描述业务相关性强的字段在一个物理维表实现。相关性强是指经常需要一起查询或进行报表展现、两个维度属性间是否存在天然的关系等。例如，商品基本属性和所属品牌。

公告明细数据层，可以说是我们数仓建设的核心了。

DWD层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。然后加工成面向数仓的基础明细表，这个时候可以加工一些面向分析的大宽表。

DWD层应该是覆盖所有系统的、完整的、干净的、具有一致性的数据层。在DWD层会根据维度模型，设计事实表和维度表，也就是说DWD层是一个非常规范的、高质量的、可信的数据明细层。

DWS层为公共汇总层，这一层会进行轻度汇总，粒度比明细数据稍粗，基于DWD层上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是也是面向分析宽表或者是面向某个注意的汇总表。DWS层应覆盖80%的应用场景，这样我们才能快速响应数据需求，否则的话，如果很多需求都要从ods开始做的话，那说明我们的数仓建设是不完善的。

例如按照业务划分，例如流量，订单，用户等，生成字段比较多的宽表，用于后续的业务查询，OLAP分析，数据分析等。

一般采用维度模型方法作为理论基础，更多的采用一些维度退化手法，将维度退化至事实表中，减少维度表与事实表的关联，提高明细数据表的易用性；同时在汇总数据层要加强指标的维度退化，采用更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。

维表层，所以其实维度层就是大量维表构成的，为了统一管理这些维度表，所以我们就建设维度层，维度表本身也有很多类型，例如稳定维度维表，渐变维度维表。

维度指的是观察事物的角度，提供某一业务过程事件涉及用什么过滤和分类的描述属性，"谁、什么时候、什么地点、为什么、如何"干了什么，维度表示维度建模的基础和灵魂。

所以可以看出，维度表包含了业务过程记录的业务过程度量的上下文和环境。维度表都包含单一的主键列，维度表设计的核心是确定维度字段，维度字段是查询约束条件(where)、分组条件(group)、排序(order)，与报表标签的基本来源。

维度表一般为单一主键，在ER模型中，实体为客观存在的事务，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。维度建模的核心是数据可以抽象为事实和维度，维度即观察事物的角度，事实某一粒度下的度量词，维度一定是针对实体而言的。

每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。例如customer（客户表）、goods(商品表)、d_time(时间表)这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。

维度表通常比较宽，包含多个属性、是扁平的规范表，实际应用中包含几十个或者上百个属性的维度并不少见，所以维度表应该包括一些有意义的描述，方便下游使用。

维度表的维度属性，应该尽可能的丰富，所以维度表中，经常出现一些反范式的设计，把其他维度属性并到主维度属性中，达到易用少关联的效果。

维度表的设计包括维度选择，主维表的确定，梳理关联维度，定义维度属性的过程。

维度的选择一般从报表需求和从业务人员的交谈中发现，主要用于过滤、分组、排序，主维度表一般从业务库直接同步，比如用户表，但是数仓的本身也会有自己的维度，这是因为数仓是面向分析的，所以会有很多从分析的角度出发的维度。

关联维度主要是不同业务系统或者同一业务系统的表之间存在关联性(范式建模)，根据对业务表的梳理，确定哪些表和主维度表之间存在关联关系，并选择其中的某些表用于生成维度属性。

随着互联网的普及，获客成本越来越高，这也使得公司对用户运营提出了更高的要求，不仅需要精细化更需要个性化。解决这一问题的办法之一就是建立相对完备的标签系统，而数仓的标签层对于标签系统而言就像数据仓库对于数据系统一样，有着举足轻重的地位，这样的标签系统需要与业务进行紧密结合，从业务中获取养分—用户标签，同时也要服务于业务—给用户提供更加精准和个性的服务。

底层的标签系统就像一个索引，层层展示大千世界，而用户就从这大千世界中不断选择一些东西表明自己的身份和喜好，也不断反哺，使得这个大千世界更加丰富多彩。其实到最后用户就是一些标签的集合。

对跨业务板块、跨数据域的特定对象进行数据整合，通过统一的ID-Mapping把各个业务板块，各个业务过程中同一对象的数据打通，形成对象的全域数据标签体系，方便深度分析、挖掘、应用。ID-Mapping可以认为是通过对象的标识对不同数据体系下相同对象进行关联和识别。对象的标识可以标识一个对象，一般是对象的ID,比如手机号，身份证，登录账号

完成对象的ID打通需要给对象设置一个超级ID,需要根据对象当前业务体系的ID和获取得到或者计算得到超级ID,进而完成所有业务标识的ID打通一般来说ID打通是建设标签体系的前提，如果没有ID打通就无法收集到一个对象的全面信息，也就无法对这个对象进行全面的标签刻画。

传统的计算方法要有 ID-ID之间的两两关系，例如邮箱和手机号可以打通，手机号和身份证号可以打通，那么邮箱就和身份证号可以打通，但是当数据量非常大，且业务板块非常多的时候，例如有上一个对象，每个对象有数十种ID,这个时候打通就需要非常漫长的计算

那么什么是标签呢，利用原始数据，通过一定的逻辑加工产出直接能被业务所直接使用的、可阅读的，有价值的数据。标签类目，是标签的分类组织方式，是标签信息的一种结构化描述，目的是管理、查找，一般采用多级类目，一般当一个对象的标签个数超过50个的时候，业务人员查找标签就会变得非常麻烦，这个时候我们往往会通过标签类目进行组织管理

标签按照产生和计算方式的不同可分为属性标签，统计标签，算法标签，关联标签。

对象本身的性质就是属性标签，例如用户画像的时候打到用户身上的标签。

对象在业务过程中产生的原子指标，通过不同的计算方法可以生成统计标签。

对象在多个业务过程中的特征规律通过一定的算法产出的标签。

对象在特定的业务过程会和其他对象关联，关联对象的标签也可以打在主对象上。

我们的标签一定是针对用户的，而不是一些虚假、高大上、无用的标签，一定要真实反映用户行为喜好的，所以我们不能只依赖人工智能算法的分析，来完成对一个用户标签的建立与定期维护，我们需要走出去和用户交互，引导用户使用，要抓住用户痛点，及时获取用户反馈，形成闭环。

如何引导使用呢？这个方式有很多我们就不再这里介绍了，后面我们会专门介绍这一层的建设细节。

数据应用层ApplicationDataService面向业务定制的应用数据，主要提供给数据产品和数据分析使用的数据，一般会放在ES，MYSQL，Redis等系统供线上系统使用，也可以放在Hive中供数据分析和数据挖掘使用，或者使用一下其他的大数据工具进行存储和使用。

数仓层，DIM层，TDM层是相对稳定的，所以无法满足灵活多变业务需求，所以这和数仓层的规范和划分相矛盾，所以我们在此基础上建立了另外一个层，这就是ADS层，解决了规划稳定和灵活多变之间的矛盾。其实到这里你也就慢慢的看明白了，分层和分类其实没多大差别，其实就是相似的放在一起，有点代码重构的意味啊。

数据应用层，按照业务的需要，然后从统一数仓层和DIM进行取数，并面向业务的特殊需求对数据进行加工,以满足业务和性能的需求。ADS层因为面向的实众多的需求，所以这一层没有太多的规范，只需要按照命名规范来进行就可以了。

前面也说了，ADS层因为面向的实众多的需求，所以这一层没有太多的规范，但是ADS层的建设是强业务推动的，业务部门需要参与到ADS的建设中来，至少我们得了解用户的痛点才能对症施药啊。

理清需求，了解业务方对数据内容、使用方式(怎么交互的，报表、接口、即席查询、在线查询、指标查询、搜索)、性能的要求。

盘点现有的数仓表是否可以支持，看以前有没有类似的需求，有没有可以复用的接口、报表什么的。

代码实现，选择合适的存储引擎和查询引擎，配置线上监控然后交付。

主要是提供数据产品和数据分析的数据，一般会存放在ES、Mysql、也可能直接存储在hive中或者druid供数据分析和数据挖掘使用。主要解决部门用户报表和分析需求而建立数据库，数据集市就代表数据仓库的主题域。

DM是面向单个主题的，所以它不会从全局考虑进行建设，只专注于自己的数据、往往是某个业务线，例如流量主题、社交主题、电商主题等等。

最全面的数仓分层剖析,一文搞定企业数仓分层

最全面的数仓分层剖析数仓分层核心思想：分层的核心思想就是解耦，再解耦，把复杂的问题简单化。

一、数仓分层意义

通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，每一层的处理逻辑都相对简单和容易理解，从而达到解耦的目的，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，方便问题排查和追溯定位。

数据分层的好处包括：

清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解。减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径。复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题。二、一种通用的分层架构

一种较为常见且适用性较广的四层分层架构如下：

数据公共层CDM（Common Data Model）或者企业级数据仓库EDW（Enterprise Data Warehouse）：主要用于存放明细事实数据、维表数据及公共指标汇总数据。其中明细事实数据、维表数据一般根据ODS层数据加工生成；公共指标汇总数据一般根据维表数据和明细事实数据加工生成。本层采用维度模型作为建模方法的理论基础，更多的是通过采用一些维度退化手段，将维度退化至事实表中，减少维表和事实表的关联，提高数据易用性。三、一些不同的分层思路（大厂数仓分层案例）

爱奇艺数仓分层架构

爱奇艺的架构中，最底层是统一数仓，将原始数据层、统一明细数据层和统一聚合数据层进行了整合。明细层负责对接下层所有的原始数据，百分之百还原所有业务域和业务过程的数据，同时屏蔽底层原始数据变动对上层造成的影响，是整个数仓的底层基础。聚合层负责对通用的指标进行沉淀，向上提供统一口径的计算指标，同时避免重复计算。业务集市主要以业务诉求为主，建设满足业务分析的各种数据集合。主题数仓以公司范围内公共的主题域/主题角度，以一致性维度为基础，跨各业务做数据的整合分析和相关建设。应用层包括业务报表、内容分析、用户运营等数据应用产品。

SaaS收银运营数仓分层架构

这个分层架构大概是五层，虽然从名称上看着和通用分层架构差异比较大，但实际具体功能上，只是增加了一个DWT主题宽表层。DWT层主题宽表层，其实是对DWD各层的信息进行join整合，基于主题，将业务过程相关的数据冗余处理，从而方便上层DWS汇总数据使用。

美团数仓分层架构

美团数仓分层架构和通用分层架构也是差异较大，但是异曲同工，只不过是将数据分的更细，做更多的解耦。其中IDL数据集成层，整合多数据源的一致性建模，完成数据维度、事实组合；CDL数据组件层，用来完成聚合汇总，进一步按照粒度划分，完成年月日级的聚合；MDL数据集市层，按照业务单元做数据集市；最终的ADL应用层，主要是选型，针对业务数据应用选择数据库技术、分析引擎技术，还有报表计算等。

网易严选数仓分层架构

网易严选数仓分层架构和通用数仓分层架构差别不大。其中ods是操作数据层，保留最原始的数据；dw包含dwd和dws层，这两层共同组成中间层；dm是应用层，基于dw层做汇总加工，满足各产品、分析师和业务方的需求。

网易云音乐数仓分层架构

网易云音乐数仓分层架构不同之处在于增加了stg缓冲层，用于存储每天的增量数据和变更数据，配合ODS对数据进行沉淀，减少了抽取的复杂性。

四、如何设计数仓分层架构

数据仓库分层没有绝对的规范，适合的就是最好的。至于分几层，建议按照目前的业务和建设现状，进行合理解构和分层设计，一般刚开始做，建议3、4层，规划1-1.5年的架构，然后不断的建设、优化。

针对一些场景的分层想法：

场景一：时间紧任务重，急于看结果。这种场景，直接连各个业务数据库，抽取数据到大数据平台，根据需求组合join或者汇总count、sum就行，不要分层。场景二：公司业务简单，且相对比较固定，数据来源不多，结构也很清晰，需求也不多。直接使用通用的数仓架构，ODS起到解耦业务数据库+异构数据源的问题，DWD解决数据脏乱差的问题，DWS服用的指标计算，ADS直接面向前台业务需求。场景三：公司业务复杂，业务变化较快。那就多一层DWT层做汇总，多一层解耦，业务变化的时候，我们只改DWS层就好了，最多穿透到DWT层。场景四：公司业务较为复杂，集团性公司，下辖多个部门bu事业线，bu间业务内容交叉不大。可以在数仓通用分层架构上，增加一层DM层，也就是数据集市层，各个数据集市层单独供数，甚至有单独的计算资源。五、一个好的数仓模型分层应具备的要素

一个好的数仓模型分层，应该具备数据模型可复用、完善且规范的特点。

从完善度上来讲，主要衡量DWD层和汇总层两块的完善度，DWD层完善度主要是希望DWD等尽可能被汇总层引用，ODS层被除了DWD层外的尽可能少的引用，最好是没有。

从复用度上来讲，希望80%需求由20%的表来支持，即大部分需求都用DWS的表来支持。

从规范度上来讲，主要从表名、字段名来看，一个规范的表名应该包括层级、主题域、分区规则、抽取类型等信息；字段规范应该是和词根一致，同字段同名。

六、总结

数据仓库分层的核心逻辑是解耦，在有限时间、资源等条件下满足业务需求，同时又要兼顾业务的快速变化。所以我们作为数据架构师，需要兼顾业务的复杂变化以及开发的复杂度和可维护性，在两者之间做一个平衡和取舍，选择合适的分层架构。另外分层架构是需要不断的优化调整的，不能超前太多，也不能脱离业务。

如果你还想了解更多这方面的信息，记得收藏关注本站。