一篇压箱底多年的数仓设计原理，今天我拿出来分享了。满满的干货，记得收藏哦

前言
大家好，我是DJ丶小哪吒，我又来跟你们分享知识了。最近小编接到粉丝的留言说，“小编，你的博客怎么写的跟新闻日报似的”，后来小编就回去看了看以前的博客，发现还真是。内容又臭又长。后来小编下定决心，以后的博客要考虑到观众的体验。以后的博客写起来要尽量去简单易懂。因为小编一开始的目的只是为了做笔记，方便自己以后查阅。所以才养成了一种不好的习惯。后来，久而久之，当我有了一定的粉丝之后。我才发现，写博客不能仅仅只为自己着想，我也要为那么多支持我的人着想。直到后来我的博客也是在一点一点改善。但是这次我的粉丝跟我反馈之后，我才知道我的博客还有待提升。我会根据粉丝的建议，我也会一点一点，慢慢的改进自己的博客。希望能与更多的人分享知识。也能帮助更多的人。同时也希望大家给予支持。由于水平有限，博客中难免会有一些错误，有纰漏之处恳请各位大佬不吝赐教！
小编博客主页：https://blog.csdn.net/Mr_Yang888
尽管当前水平可能不及各位大佬，但我还是希望自己能够做得更好。因为我相信，努力就会有希望。如果你的内在一直成长，那么你早晚会破土而出

今天小编要为大家分享的是，企业中的数仓设计模型。满满的一篇干货，一般人我都不告诉他哦。
码字不易，先赞再看，养成习惯~~~

一、构建数据仓库的基础 (前提)

1.稳定：数据的生产稳定、有保障；
假如数据仓库底层有三个系统（a\b\c），保证ABC能够稳定生产数据。
2.高质量：数据质量要足够高；
尽量保证数据是高质量的。在确定100%没有意义的数据的情况下，将数据剔除掉。
3.覆盖广：数据涵盖的业务面要尽可能多；
以解决业务问题为目标：企业需要提供解决业务问题所需要的所有数据。【理想】
实际上企业内：已有数据能够解决哪些问题就优先解决哪些问题。能支撑是什么业务就做着什么业务。
4.透明：数据的构成流程要透明，用户使用放心。

二、为什么基于大数据平台构建数据仓库？[数仓与大数据的结合点]

1、存储计算能力强，分布式存储，存储空间大，使空间换时间成为可能，使扁平化数据处理流程成为可能（简化计算过程，计算难度）

• 数仓会使计算流程变多，但是每一步和计算的难度都会降低。

2、组件多，编程接口丰富，增加了数据处理的方式方法。

• 大数据平台组件众多，每个组件都有自己的特点和用法。
• 同一个问题可以有多种方式方法解决。（数据同步：自己写代码/sqoop/kettle。数据预计算：MR/hive/spark。实时计算：sparkStreanig/structStreaming/
  flink/storm）

3、多种数据采集，能够实现实时数据、离线数据，非结构化数据和半结构化数据的采集；

• 得益于大数据内的组件众多，实时数据，离线数据都能够同步都能够计算。
• 结构化数据（结合数据库），非结构化数据采集(flume)

三、仓库架构设计原则

1、自下而上与自上而下相结合

• 自下而上：数据的清洗、过滤、填充、汇总、计算自下而上分步骤计算。
• 自上而下：数据的查询、异常追踪，数据价值密度自上而下。

2、高容错性
高容错性，构建数仓的任何一个系统出现故障，都会对数仓服务产生一定的影响，所以在构建数仓时，需保证数仓具备高容错性。（hive-mysql-kettle-kylin）
3、数据质量监控
数据质量监控：数仓最终的结果直接受数据质量的影响。生产中数据质量管理需要贯穿整个数据处理流程。
4、空间换时间
空间换时间，数仓需充分利用大空间优势提高查询的效率和降低数据计算难度。

四、数仓构建步骤

1、模型设计
建模方式:维度莫建模或实体关系建模

• 维度建模相对实施比较简单，便于事实数据分析，适用于业务分析报表和BI；
• 实体关系建模结构相对较复杂，它便于主体与主体之间的数据打通，比较适合复杂数据的深入分析。

模型分类:星型模型和雪花模型—星座模型

• 两种模型没必要绝对分开，事实上应该是并存的。星型也属于雪花模型。
• 星型模型结构相对简单，有利于计算，所以若表结构为雪花型可以在将雪花模型转换成星型模型，以达到降低计算难度的目的。

2、数据分层
数据分层可以使数据构建体系更加清晰，便于数据使用者快速对数据进行定位；同时数据分层也可以简化数据加工处理流程，降低计算复杂度。
常用的分层为：集市层（ADS）、中间层(DW)、基础数据层(ODS)，上下三层结构。
数据基础层(ODS)

• 数据采集：把多种数据源的数据统一采集到一个平台上；
• 数据归类：按照来源系统和业务域进行分类（目录）；
• 数据规范化：包括规范维度标识、统一计量单位等规范化操作。
• 数据清洗：删除不符合要求的数据，避免脏数据参与后续数据计算（也可在DW层）；
• 数据结构化：对于半结构化和非结构化的数据，进行结构化【目前还不在数仓中实现】；
  数据中间层（DW）
  目标就是把 同一实体(主题)不同来源（不同数据表）的数据打通(拉宽到一个表)。方便后续计算业务数据的使用。
  用户行为数据可以抽象出来一些有用的数据，例如兴趣、偏好、习惯等。这些数据可以支撑上层的部分应用（推荐）。
  当有一个实事数据和两个主题相关时
  
  需将该数据放在两个主题库中（冗余两份或多分）这样能保证主题的完整性和提高数据的易用性，两个主题之间相互不影响（单表数据的复用性比较低）。了提高单数据表的复用性和减少计算关联，会在事实表中冗余部分维度信息。

数据集市层（ADS）

数据集市由需求场景驱动建设，方便需求快速查询，快速计算。

五、数据架构

数据架构包括数据整合、数据体系、数据服务三部分。
1.数据整合
数据类型可分为结构化、半结构化、非结构化三类。
数据整合可分为全量数据、增量数据、实时数据三类。

半结构化数据/非结构化数据需要经过结构化计算后才能使用。
例如：
微博 - - 博主，时间、状态、评论数。
图片 - - 文件名、大小、创建时间、格式。
语音 - - 文件名、时常、大小、格式，创建时间。
视频 - - 文件名、时长、分类等。
目前数仓架构体系中并不包含非结构化数据特征提取操作（其他系统提取好后才寄过来）。

2.数据体系
即数据的计算从入库开始到写入数据集市的全部过程。

3.数据服务化
数据服务化包括统计服务、分析服务、标签服务：
ADS数据集市包含统计服务、分析服务、标签服务。
**统计服务（用户）：**主要是偏传统的报表服务，将计算后的结果存储到关系型数据库中，供前端的报表系统或业务系统查询。
分析服务（分析师）：
用来提供明细数据的即席查询(即席查询【想怎么查就怎么查】:操作人员可以自主灵活的进行各种维度的交叉组合查询)。分析服务的能力类似于传统cube提供的内容。

一个查询有10个维度。（group by 后面的字段有1-10个）
10个维度任意组合的可能性有多少？？ 2的十次方-1个可能（1023）
用户的所有查询可能都在这1023种情况内

标签服务（推荐）：
在大数据的应用中，经常会对主体进行特征刻画。例如：客户的年龄段、消费性别、消费能力、兴趣习惯等。这些数据通过打标签转换成KV的数据服务，用于前端应用查询。

经验分享
1、采用强制分区，在所有的表都上都加上时间分区。通过分区，保证每个任务都能够独立重跑，而不产生数据质量问题，降低了数据修复成本；此外通过分区裁剪，还可以降低计算成本。
2、应用计算框架完成日志结构化、同类数据计算过程等操作，减轻了开发人员的负担，同时更容易维护。
3、优化关键路径。优化关键路径中耗时最长的任务是最有效的保障数据产出时间的手段。

六、数据治理（数据质量管理）

计算量很大，生产中数据质量管理所需要的资源需要与数仓的计算资源对顶或相匹配。
数据治理贯穿在数仓架构内部和数据处理的流程之中。
保障数据质量，可以从事前、事中、事后入手。

• 事前，可以通过制定每份数据的数据质量监控规则，越重要的数据对应的监控规则应该越多。
• 事中，通过监控和影响数据生产过程，对不符合质量要求的数据进行干预（删除/填充/归0等），使其不影响下流数据的质量。
• 事后，通过对数据质量情况进行分析和打分，将一些不足和改进反馈数据监控体系，推动整体的数据质量提升。

例如：数据进入ODS层之前数据量是多少条，根据规则删除掉多少条，剩余多少条。进入之前=删除的+剩余的

数据进入DW层之前多少条，出DW多少条。进入的-输出的是否是未join上的数据。
编写质量检测程序，逐一检查数据是否符合规则。统计出符合的有多少条，不符合的有多少条（符合的+不符合的=所有的）。

七、数据生命周期管理

虽然大数据集群空间大，但不要过量使用空间。出于成本等因素的考虑，在大数据平台上依然需要对数据生命周期进行管理。
根据使用频率将数据分为冰、冷、温、热四类。保证数据的生命周期尽量合理（证温热数据占整个数据体系大部分）
对于数据中间计算过程数据，在保障满足绝大部分应用访问历史数据需要的前提下，缩短数据保留周期，有助于降低存储成本。

• 热（近1-7天）：存储在kylin的cube (hbase+预计算)或redis或mysql
• 温（近8-14天）：存贮在mysql或oracle或MongoDB
• 冷（近15-45天）：存储在hive表(SSD硬盘中)
• 冰（45+）：冰数据存储在HDFS的机械硬盘中

好了，以上内容就到这里了。你学会了吗。 欢迎路过的朋友关注小编哦。各位朋友关注点赞是小编坚持下去的动力。小编会继续为大家分享更多的知识哦~~~。

我是DJ丶小哪吒。是一名互联网行业的工具人，小编的座右铭：“我不生产代码，我只做代码的搬运工”…哈哈哈，我们下期见哦，Bye~

不要因为希望去坚持，要坚持的看到希望。