大数据最新数据仓库(基础篇）——基于维度建模思想_数据仓库维度穷举举例，2024年最新大数据开发基础视频教程_数仓规划

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

---

前言

本文来源于A94大佬的关于数据仓库分享，如果感兴趣兴趣可以登录B站自行查看，在此给出链接地址：857数据交流技术峰会之数仓篇

在开始本篇文章之前，我们需要先了解什么是数据仓库。

1. 什么是数据仓库

要想全面的来看待数据仓库，首先要回答的是数据仓库搭建的目的：

百度百科解释：数据仓库，英文名称Data Warehouse，数据仓库是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。

笔者个人理解：以数据建模理念为基础，以消除数据孤岛为目的，通过一套标准方法和工具集，解决大数据计算中诸如质量、复用、扩展、
成本等问题，能够驱动业务发展的体系。

第三方解释：
数据仓库是数据管理、存储、计算、建模的方法论，是一种过程处理方法；
它的特点为：面向主题的、集成的、稳定的、反映历史变化；
数据仓库由元数据、数据建模、实现代码、血缘关系、规范准则组成；
数据仓库在整个数据体系中的位置：数据采集->数据接入->数据仓库->数据报表/数据分析/数据挖掘。

2.数据仓库与传统数据库的异同

3. 传统数据库存在的缺点

• 数据资产模糊，数据存储和计算资源评估缺乏必要的信息；
• 计算口径不一致，条件的过滤和规则等的理解差异带来的算法不一致；
• 无中间表或中间表建设的差，开发时间长并且重复建设；
• 底层轻微的改变对上层影响巨大；
• 问题定位难、周期长，上下游依赖混乱，生命周期难以管理；
• 频繁的临时性需求。

4. 大数据环境下数据仓库的优点

• 方便沟通交流；
• 提高排查问题的效率；
• 提高数据开发的效率；
• 生产结果可复用；
• 复杂任务解耦；
• 提高数据质量，避免数据口径不一致等问题；
• 减少存储成本和计算成本。

一、数据仓库起因

1、企业信息化建设带来更多的数据的沉淀

从阿里开始，许多公司都在进行数字化转型，数据化转型是由于企业的信息化的发展，导致信息发展的水平越来越高。在信息化建设的过程
当中，企业会产生非常多的数据，带来了整个企业的数据沉淀。

2、人们对数据更多的依赖与思考

第一点：现在，企业当中的一些经营管理层或者领导，经常会定一些KPI指标。包括我们在医院进行身体检查 ，体检报告上也会有相对应的指标来说明我们的身体状况。同样的，如果我们想知道一个企业的经营状态，我们需要对数据有一定的依赖。
下面为某公司对数据的应用，大体上分为以下几种。

1. 描述统计：一个比较基础的应用，大多数公司都具有的技术栈。
2. 诊断：比如说在经营管理中，每隔一个月或者一天看一次报表，这样其滞后性就比较严重。如果在实施的过程中进行监控，这样对企业来说可能会更有好处。

第二点：基于历史的一些数据，对于未来做一些预测，比如说一些公司经常做的舆情分析，抓去一些市面上的数据，对于风险点这样的一个把控，导致了人们对于数据更多的依赖于思考。

3、数据使用过程中遇到的一些痛点和难点
比较常见的如数据当中的黑夹子。以某公司为例，从研发到销售到生产整个全链路的传统型企业。在供应链端，如果我们想看一些前端的销售数据，后端的数据，以及售后服务等，这些数据我们是看不到的。因为我们的数据是分散在各个系统当中，这是我们的一个数据痛点，数据孤岛就是这样产生的。我们的信息化建设也是分阶段在不同时间去建立的，如果是传统型的厂商，还会有不同的厂商进行建立，这样的结果是会导致数据结构上的不一致，比如说企业上数据口径上的不一致等等这些问题。

以上的这些大致就是数据仓库的起因，当然此处并非专业定义，仅为个人理解。

二、数据仓库的特点

1.面向主题
数据仓库是OLAP(联机分析处理)面向分析的一个产物，它与传统的业务数据库相比，其是一个事务性的数据库。数据仓库为了让分析更加全面，包括能够快速的响应分析的需求，所以其是面向主题，分门别类的一种管理。

2.集成的
不仅把整个企业的数据存放到一起，还需要把整个企业各个生产过程中不同的系统，不同的业务线，不同的板块进行整合，把其中的数据进行集成与拉通。

举例说明：比如说某公司正在进行售后服务2.0的建设，当前面临的问题是，之前并没有数据仓库或者数据中台这样一个概念。数据分散在各个地方。如果我接到了客服的一个售后的一个客户电话，我想知道这个人买了哪些产品，这个产品当前是在生产还是已经收到过了等等各种情况。我们是否需要知道整个的关注客户的订单的全生命周期，所以说数据仓库的另一个重要特点是集成的。

3.相对稳定的
整个数据仓库是相对稳定的，数据仓库的模型不能随意改变。如果数据仓库的模型不稳定，是不利于公司进行数据分析于数据决策的。

4.反应历史变化的
数据仓库是反应整个历史变化的，业务系统的数据在很多种情况下如果想再次查阅历史数据，其对整个系统的压力以及整个分析的逻辑来说是比较麻烦的，数据仓库相对而言也是为了解决这个痛点。比如说传统的离线数仓是T+1这样一个结构，现在发展成为实时数仓。它都是可以反应我们企业的历史变化的这样一个特点的。

三、数据仓库常见的概念

1.六大概念

分层： 关于分多少层，每个公司都不一样，并没有一个标准的说法。市面上主流的一般分三层。分层是数据架构的产出之一。

主要作用：

1. 为了解耦合、分布执行、降低出问题的风险。
2. 用空间换时间用多步换取最终使用的数据的高效性。
3. 指标或者报表出问题了，可以快速的进行溯源。

分层更多的是一个逻辑上的概念。

分域： 分为主题域和数据域。主题域与数据域严格意义上并没有标准划分。主题域一般是面向分析用的，主题域通常是联 系较为紧密的数据主题的集合， 比如财务主题域、人力主题域、供应链 主题域等。数据域一般指的是一组/ 一串/ 一类业务活动单元的集合， 如日志、交易等。

分类： 严格意义上来说其不属于数据仓库常见的一个概念，其更多的是对应用系统的数据进行一个分类。我们知道数据仓库的上游基本上都来自于业务数据库、日志的信息、爬虫或者其他的第三方的数据。针对这些数据我们需要进行分类。只有分类才能更好的管理与使用，所以我们一般为了更好的管理数据， 会把数据划分为主数据、交易数据、参考数据、元数据等。业务系统数据的一个划分。

维度： 由独立不重叠的数据元素组成的数据集， 所构成的可进行统计的对象。常见的如人、产品、地点。维度通俗来说就是我们观察某一事物的一个角度。

事实： 描述业务过程的度量(最小单体)。

粒度： 事实表中一条记录所表达的业务细节程度。

维度与事务的区分，比如说在sql中，如果能够使用where条件判断的话，那么其就是一个维度。

2. 拓展

业务过程： 业务过程代表一个被管理实体或系统的事实， 是对业务活动 单元/ 事件的定义。常见的如下单、支付。基本上把它划分为最小的一个单元体。

原子指标： 原子指标一般情况下划分为基础指标(原子指标)、复合指标、派生(衍生)指标等等，不同公司会稍有不同。原子指标是对业务事实中度量的统计定义， 与SQL中select内容等价。常见的如支付金额、买家数。

业务限定 ： 业务限定是对业务中圈选的统计范围的定义， 与SQL中where条件等价。常见的如商品品类、已支付。

派生指标： 派生指标即常规的统计指标， 通过原子指标与各种业务限定的组合而生成。如最近一天或者最近一个月买家支付金额。

汇总逻辑表： 描述维度统计信息（ 即派生指标） 及维度属性信息的数据 集合集， 所构成的数据仓库模型。

三、数据仓库建设步骤

1.建设步骤

1. 需求调研
   数据仓库与业务关系是较为紧密的。一个数仓项目的成败，很大程度上取决于你对整个公司的了解程度。比如说刚刚对各个主题域的划分。如果说你对你们公司的整体的业务都不熟悉，怎么进行划分。如果对业务不熟，你是构建不出来的。
2. 数据调研
   首先我们需要对整个的业务流程有所了解，业务流程是通过怎样的系统承接下来的。在承接的过程中，我们的数据他是什么样的结构，数据量是多少，数据质量如何等等，这些都是我们需要去了解的。
3. 构建总线矩阵
   总线矩阵个人认为更多的是为了帮助我们更好的统一规划数据仓库，也是为了更加的标准化。关于总线矩阵是怎么划分的？下面简单的说下，通常为一行代表业务过程。每一列是一个维度。在数仓建设的过程中，对一次性维度、一次性事实是有要求的。前面说过，在整个数仓的过程中，我们需要统一整个公司的数据的指标的口径，包括数据的一些认知等等，所以需要构建数据的总线矩阵。
4. 构建CRUD矩阵
   我们需要对每一个实体的创建、更新、删除等。比如说在整数仓中，我们选择一个维度，一般面临两个步骤：选择主维表和进行维度的主键的设计。在我们选择主维表的时候，如果你连这个维度在哪个系统创建的，在哪个系统更新的，在哪个系统删除的都不知道的话，如果出现这种情况是不太好的，所以我们需要构建CRUD矩阵。

2. 数仓规划(以下表为例)

数仓的上游统一的称之为数据源。统一生成数据源后，我们会把整个公司的业务进行划分。

比如说对业务线，业务板块进行划分，每一个业务线下可能会有很多业务板块。每个业务板块下面又有许多数据域。

每个数据域下面我们也会进行划分，比如说维度和业务过程。

维度我们设计成维度逻辑表，就是我们刚才所说的，你需要考虑以下三点，一个点就是你的主维表，第二个点就是你的维度的主键的设计，第三个点就是维度属性的选择。我们在做维度逻辑表的时候，我们建议尽量把我们的维度属性设计的丰富一点，因为现在的业务变化有点快，丰富一点对于整个数仓的稳定性和健壮性都是有好处的。

划分业务过程形成事实上的逻辑表，事实逻辑表包括事务性的事实，快照性的事实。更细的划分暂时就不进行细讲了。在此大家知道有这样一个概念就可以了。划分完成过后会形成整个公司的逻辑，包括维度逻辑这样一个表，会形成我们所说的DWD(数仓明细表)。

然后进行一个汇总，汇总我们更多的是根据派生指标包括像时间周期来进行一个指标的汇总，以此来形成汇总逻辑表。

3.数据仓库分层划分

根据上图可以看到数仓一般分为三层。第一层为ods层，我们通常把其叫做原始数据层，或者叫做操作数据层。第二层为中间层，第三层我们面向推荐系统、报表、数据分析等等，划分为ads层。整个数据仓库最重要的设计是中间层的设计，即是从明细层->dws层(数据汇总层)这一块的设计。

具体的分层要根据公司的实际需要来进行分层。

每层的作用：
ods层：在此层中不建议进行太多的数据清洗、转换。只需要把业务系统中的数据，日志数据等等原汁原味的采集同步过来即可。

• 这样做的好处：
  ①降低对业务系统的入侵，减少业务系统的压力。
  ②如果指标出错，ods层数据被改掉的话，只能从业务数据库或者日志数据库查找数据，这样是不利于我们进行血缘追溯和出错排查的。

因此所有的操作我们可以放在ods到dwd时进行，包括我们常见的维度退化、过滤、缺省值处理，按照业务过程进行拆分，冗余一些属性。
还可以把事实的粒度降低。

ads层响应整个推荐，包括报表等等响应应用。我们要把更多的一个逻辑划层放在中间层去做。可以保证整个公司的稳定性。

dim层是一个维度的层，维度层是可以各层级调用的，我们可以把部分的维度下沉或者冗余到其他层里面。

在做数仓的时候，我们要尽量减少Join，因为它不利于数据的处理。

数仓遵循的原则：不允许跨层调用，跨层出数。比如说在数据建模之后，我们需要对模型进行考评，模型建立的好不好，有一个指标就是看你跨层的调用率，包括你跨层出数的比率。如果上层应用、基本数据都来自于ads层，少部分来自于dws层，那么相对而言这个数仓的建设是比较不错的。

四、问题与思考

1. 维表的主键选择

自然键（NaturalKey），它是业务系统中已经存在的，通常是具有一定业务含义的一个字符型的标志符，可以唯一地标志维度表中的每一条记录。比如机构的代码、缩写、时间标签等。

另一种是代理键（SurrogateKey），通常是数据库系统赋予的一个数值，是自增型的，按顺序分配，没有内置含义但也可以唯一地标识一条维度信息。​

项目经验，推荐采用第二种，即代理键。原因如下：​

首先，自然键虽然在逻辑上可以唯一地标识出一条维度信息，但它通常是字符型的，且一般比较长，若用它作为维度表中的主键，那就意味着在事实表中也要加入同样的外键信息，而事实表记录行数往往是巨大的，在多个维度表上重复这样的做法会使事实表由于列宽过于膨胀而导致性能的急剧下降。​

其次，代理键可以作为数据仓库与源系统之间的“缓冲”。自然键通常具有一定的业务含义，但日久天长，这些信息是有可能发生变化的，比如身份证号码，由最初的15位变成了现在的18位。如果这种主键一旦发生了变化，由于它同时作为事实表中的外键，必然会对事实表产生影响，因为已有的事实记录已经找不到与之匹配的维度记录，这就带来了很大的麻烦。但若采用代理键作为维度表中的主键，就完全可以把这些变化屏蔽在维度表内，不会对事实表产生任何影响（当然这个还要结合缓慢变化维度的处理）。​

最后，从关联效率考虑，数值型的关联要比字符型的关联快很多。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

7hzGZL-1715450814514)]
[外链图片转存中…(img-bR0eZHob-1715450814514)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取