关于数据仓库:数仓建模分层理论

分层建设实践

简略点儿，间接 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 是面向单个主题的，所以它不会从全局思考进行建设，只专一于本人的数据、往往是某个业务线，例如流量主题、社交主题、电商主题等等。