数仓建模分层理论

分层建设理论

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

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

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

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

分层的意义

清晰数据结构体系

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

数据血缘追踪

因为最终给业务呈现的是一个能直接使用的业务表，可是表的数据来源有不少，若是有一张来源表出问题了，咱们但愿可以快速准确的定位到问题，并清楚它的影响范围，从而及时给到业务方反馈，从而将损失降到最低。

减小重复开发和资源浪费

• 规范数据分层，开发一些通用的中间层数据，可以减小极大的重复计算；
• 清晰明了的结构使得开发、维护的成本下降；
• 减小重复计算和存储的资源浪费；

复杂问题简单化

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

在实际的建设过程当中，因为业务使用数据很是紧急以及统一数仓层建设跟不上业务的须要，因此DIM和ADS层可能直接使用ODS层进行快速的业务响应，可是这种不规范的操做可能致使数据口径不一致， 因此待数仓建设完毕，要切换到统一数仓层和DIM层。

统一数据口径

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

关于分层的一点思考

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

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

数仓层内部的划分不是为了分层而分层，分层是为了解决 ETL 任务及工做流的组织、数据的流向、读写权限的控制、不一样需求的知足等各种问题，固然咱们常说的分层也是面向行业而言的，也是咱们经常使用分层方法，可是你须要注意的是分层仅仅是手段而已。

数仓的分层

ods 操做数据层

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

其实这里说ETL 有点不合适了，其实更准确的是ELT,你能够细细品品

本层的数据，整体上大可能是按照源头业务系统的分类方式而分类的，前面咱们说到为何在数仓主要用维度建模的状况下，咱们依然要学习范式建模呢，由于咱们的数据源是范式建模的，因此学习范式建模能够帮助咱们更好的理解业务系统，理解业务数据，因此你能够认为咱们的ODS 层其实就是用的实范式建模。

可是，这一层面的数据却不等同于原始数据。在源数据装入这一层时，要进行诸如 去噪(例若有一条数据中人的年龄是300岁，这种属于异常数据，就须要提早作一些处理)、去重(例如在我的资料表中，同一ID却有两条重复数据，在接入的时候须要作一步去重)、字段命名规范等一系列操做。

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

其实关于这一层，不少人的理解不太同样，那就是是否要进行数据清洗，其实仍是取决于公司的使用习惯，其实有不少公司在这一层以前也会造成一个层，名字千奇百怪，可是它的目的是数据缓冲，而后进行清洗，清洗以后的数据存入ODS ,而这个时候缓冲层数据存放通常为一周左右，几乎不会超过一个月；而ODS则永久存放。

设计原则

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

• ods 层不作字段名归一和字段类型统一的操做，若是须要则使用兼容的数据类型
• 对于增量表，须要设计增量表(ODS_业务系统_表名_delta)和全量表,而后将增量表合并成全量表数据；
• 对于半结构化数据须要设计解析；
• 因为业务数据库（OLTP）基本按照维度模型建模，所以ODS层中的建模方式也是维度模型；

ods 的设计能够保证全部的数据按照统一的规范进行存储。

DW 统一数仓层

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

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

若是 ods 层的数据就很是规整，基本能知足咱们绝大部分的需求，这固然是好的，这时候dwd层其实就简单了不少，可是现实中接触的状况是 ods 层的数据很难保证质量，毕竟数据的来源多种多样，推送方也会有本身的推送逻辑，在这种状况下，咱们就须要经过额外的一层 dwd 来屏蔽一些底层的差别。有没有很像JVM。

设计原则

一致性维度规范

公共层的维度表中相同维度属性在不一样物理表中的字段名称、数据类型、数据内容必须保持一致，由于这样能够下降咱们在使用过程当中犯错误的几率，例如使用了不正确的字段，或者由于数据类型的缘由致使了一些奇怪的错误

维度的组合与拆分

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

DWD 明细数据层

公告明细数据层，能够说是咱们数仓建设的核心了。

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

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

DWS 轻度汇总层

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

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

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

DIM 维度层

维表层，因此其实维度层就是大量维表构成的，为了统一管理这些维度表，因此咱们就建设维度层，维度表自己也有不少类型，例如稳定维度维表，渐变维度维表。

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

好比，"小王早上在小卖部花费5元钱购买了包子"，时间维度——早上，地点维度——小卖部，商品维度——包子 那么事实表呢？

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

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

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

设计原则

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

维度表的维度属性，应该尽量的丰富，因此维度表中，常常出现一些反范式的设计，把其余维度属性并到主维度属性中，达到易用少关联的效果。

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

维度的选择通常从报表需求和从业务人员的交谈中发现，主要用于过滤、分组、排序，主维度表通常从业务库直接同步，好比用户表，可是数仓的自己也会有本身的维度，这是由于数仓是面向分析的，因此会有不少从分析的角度出发的维度。

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

TDM 标签数据层

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

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

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

一个天然人他有身份证号码进行惟一标识，可是在医保的时候他使用的实医保帐号，缴纳水电费的时候又是不一样的帐号，使用手机的时候又是设备帐号，上网的时候是网商帐号。在确认对象后，因为同一对象在不一样的业务体系中的对象标识是不同的，所以须要将同一对象上的不一样ID 标识打通，以便全部的业务数据都可以在该对象上打通。这就是ID-Mapping。

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

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

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

标签的分类

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

属性标签

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

统计标签

对象在业务过程当中产生的原子指标，经过不一样的计算方法能够生成统计标签。

算法标签

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

关联标签

对象在特定的业务过程会和其余对象关联，关联对象的标签也能够打在主对象上。

设计原则

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

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

ADS 层

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

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

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

设计原则

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

实现流程

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

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

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

使用场景与性能

• 针对业务方的使用场景，咱们须要设计出高效，知足要求的ADS 层表
• 若是是多维分析，为了减小链接，提高性能，咱们通常采用大宽表设计，使用高性能引擎支撑
• 若是是特定指标查询，通常采用KV的形式组织
• 若是是搜索场景，通常采用搜索引擎

DM 数据集市层

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

DM 是面向单个主题的，因此它不会从全局考虑进行建设，只专一于本身的数据、每每是某个业务线，例如流量主题、社交主题、电商主题等等。