数据仓库(基础篇）——基于维度建模思想
大家好，我是不温卜火，是一名计算机学院大数据专业大三的学生，昵称来源于成语—
不温不火，本意是希望自己性情温和。作为一名互联网行业的小白，博主写博客一方面是为了记录自己的学习过程，另一方面是总结自己所犯的错误希望能够帮助到很多和自己一样处于起步阶段的萌新。但由于水平有限，博客中难免会有一些错误出现，有纰漏之处恳请各位大佬不吝赐教！博客主页：https://buwenbuhuo.blog.csdn.net/
目录
前言
本文来源于A94大佬的关于数据仓库分享，如果感兴趣兴趣可以登录B站自行查看，在此给出链接地址：857数据交流技术峰会之数仓篇
在开始本篇文章之前，我们需要先了解什么是数据仓库。
1. 什么是数据仓库
要想全面的来看待数据仓库，首先要回答的是数据仓库搭建的目的：
百度百科解释：数据仓库，英文名称Data Warehouse，数据仓库是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。
笔者个人理解：以数据建模理念为基础，以消除数据孤岛为目的，通过一套标准方法和工具集，解决大数据计算中诸如质量、复用、扩展、 成本等问题，能够驱动业务发展的体系。
第三方解释： 数据仓库是数据管理、存储、计算、建模的方法论，是一种过程处理方法； 它的特点为：面向主题的、集成的、稳定的、反映历史变化； 数据仓库由元数据、数据建模、实现代码、血缘关系、规范准则组成； 数据仓库在整个数据体系中的位置：数据采集->数据接入->数据仓库->数据报表/数据分析/数据挖掘。
2.数据仓库与传统数据库的异同
- | 传统数据库 | 数据仓库 |
|---|---|---|
作用 | 用于记录状态，面向事务 | 用于分析决策，面向主题 |
服务对象 | 服务业务系统，作为数据源 | 服务数据分析师等专业数据人士 |
数据 | 存储最新状态的业务数据 | 存储历史数据，并且不是永久保存 |
冗余对比 | 严格遵循范式，避免冗余 | 引入部分冗余 |
规模对比 | 数据量偏小，多以GB为规模 | 以存储海量数据为目标，多以TB为规模 |
载体 | 一般为mysql、oracle等传统的关系型数据库 | 一般为Hive、Hbase、Spark等技术 |
3. 传统数据库存在的缺点
- 数据资产模糊，数据存储和计算资源评估缺乏必要的信息；
- 计算口径不一致，条件的过滤和规则等的理解差异带来的算法不一致；
- 无中间表或中间表建设的差，开发时间长并且重复建设；
- 底层轻微的改变对上层影响巨大；
- 问题定位难、周期长，上下游依赖混乱，生命周期难以管理；
- 频繁的临时性需求。
4. 大数据环境下数据仓库的优点
- 方便沟通交流；
- 提高排查问题的效率；
- 提高数据开发的效率；
- 生产结果可复用；
- 复杂任务解耦；
- 提高数据质量，避免数据口径不一致等问题；
- 减少存储成本和计算成本。
一、数据仓库起因
1、企业信息化建设带来更多的数据的沉淀
从阿里开始，许多公司都在进行数字化转型，数据化转型是由于企业的信息化的发展，导致信息发展的水平越来越高。在信息化建设的过程 当中，企业会产生非常多的数据，带来了整个企业的数据沉淀。
2、人们对数据更多的依赖与思考
第一点：现在，企业当中的一些经营管理层或者领导，经常会定一些KPI指标。包括我们在医院进行身体检查 ，体检报告上也会有相对应的指标来说明我们的身体状况。同样的，如果我们想知道一个企业的经营状态，我们需要对数据有一定的依赖。 下面为某公司对数据的应用，大体上分为以下几种。
- 描述统计：一个比较基础的应用，大多数公司都具有的技术栈。
- 诊断：比如说在经营管理中，每隔一个月或者一天看一次报表，这样其滞后性就比较严重。如果在实施的过程中进行监控，这样对企业来说可能会更有好处。
第二点：基于历史的一些数据，对于未来做一些预测，比如说一些公司经常做的舆情分析，抓去一些市面上的数据，对于风险点这样的一个把控，导致了人们对于数据更多的依赖于思考。
3、数据使用过程中遇到的一些痛点和难点 比较常见的如数据当中的黑夹子。以某公司为例，从研发到销售到生产整个全链路的传统型企业。在供应链端，如果我们想看一些前端的销售数据，后端的数据，以及售后服务等，这些数据我们是看不到的。因为我们的数据是分散在各个系统当中，这是我们的一个数据痛点，数据孤岛就是这样产生的。我们的信息化建设也是分阶段在不同时间去建立的，如果是传统型的厂商，还会有不同的厂商进行建立，这样的结果是会导致数据结构上的不一致，比如说企业上数据口径上的不一致等等这些问题。
以上的这些大致就是数据仓库的起因，当然此处并非专业定义，仅为个人理解。
二、数据仓库的特点
1.面向主题 数据仓库是OLAP(联机分析处理)面向分析的一个产物，它与传统的业务数据库相比，其是一个事务性的数据库。数据仓库为了让分析更加全面，包括能够快速的响应分析的需求，所以其是面向主题，分门别类的一种管理。
2.集成的 不仅把整个企业的数据存放到一起，还需要把整个企业各个生产过程中不同的系统，不同的业务线，不同的板块进行整合，把其中的数据进行集成与拉通。
举例说明：比如说某公司正在进行售后服务2.0的建设，当前面临的问题是，之前并没有数据仓库或者数据中台这样一个概念。数据分散在各个地方。如果我接到了客服的一个售后的一个客户电话，我想知道这个人买了哪些产品，这个产品当前是在生产还是已经收到过了等等各种情况。我们是否需要知道整个的关注客户的订单的全生命周期，所以说数据仓库的另一个重要特点是集成的。
3.相对稳定的 整个数据仓库是相对稳定的，数据仓库的模型不能随意改变。如果数据仓库的模型不稳定，是不利于公司进行数据分析于数据决策的。
4.反应历史变化的 数据仓库是反应整个历史变化的，业务系统的数据在很多种情况下如果想再次查阅历史数据，其对整个系统的压力以及整个分析的逻辑来说是比较麻烦的，数据仓库相对而言也是为了解决这个痛点。比如说传统的离线数仓是T+1这样一个结构，现在发展成为实时数仓。它都是可以反应我们企业的历史变化的这样一个特点的。
三、数据仓库常见的概念
1.六大概念
分层： 关于分多少层，每个公司都不一样，并没有一个标准的说法。市面上主流的一般分三层。分层是数据架构的产出之一。
主要作用：
- 为了解耦合、分布执行、降低出问题的风险。
- 用空间换时间用多步换取最终使用的数据的高效性。
- 指标或者报表出问题了，可以快速的进行溯源。
分层更多的是一个逻辑上的概念。
分域： 分为主题域和数据域。主题域与数据域严格意义上并没有标准划分。主题域一般是面向分析用的，主题域通常是联 系较为紧密的数据主题的集合， 比如财务主题域、人力主题域、供应链 主题域等。数据域一般指的是一组/ 一串/ 一类业务活动单元的集合， 如日志、交易等。
分类： 严格意义上来说其不属于数据仓库常见的一个概念，其更多的是对应用系统的数据进行一个分类。我们知道数据仓库的上游基本上都来自于业务数据库、日志的信息、爬虫或者其他的第三方的数据。针对这些数据我们需要进行分类。只有分类才能更好的管理与使用，所以我们一般为了更好的管理数据， 会把数据划分为主数据、交易数据、参考数据、元数据等。业务系统数据的一个划分。
维度： 由独立不重叠的数据元素组成的数据集， 所构成的可进行统计的对象。常见的如人、产品、地点。维度通俗来说就是我们观察某一事物的一个角度。
事实： 描述业务过程的度量(最小单体)。
粒度： 事实表中一条记录所表达的业务细节程度。
维度与事务的区分，比如说在sql中，如果能够使用where条件判断的话，那么其就是一个维度。
2. 拓展
业务过程： 业务过程代表一个被管理实体或系统的事实， 是对业务活动 单元/ 事件的定义。常见的如下单、支付。基本上把它划分为最小的一个单元体。
原子指标： 原子指标一般情况下划分为基础指标(原子指标)、复合指标、派生(衍生)指标等等，不同公司会稍有不同。原子指标是对业务事实中度量的统计定义， 与SQL中select内容等价。常见的如支付金额、买家数。
业务限定 ： 业务限定是对业务中圈选的统计范围的定义， 与SQL中where条件等价。常见的如商品品类、已支付。
派生指标： 派生指标即常规的统计指标， 通过原子指标与各种业务限定的组合而生成。如最近一天或者最近一个月买家支付金额。
汇总逻辑表： 描述维度统计信息（ 即派生指标） 及维度属性信息的数据 集合集， 所构成的数据仓库模型。
三、数据仓库建设步骤
1.建设步骤
- 需求调研 数据仓库与业务关系是较为紧密的。一个数仓项目的成败，很大程度上取决于你对整个公司的了解程度。比如说刚刚对各个主题域的划分。如果说你对你们公司的整体的业务都不熟悉，怎么进行划分。如果对业务不熟，你是构建不出来的。
- 数据调研 首先我们需要对整个的业务流程有所了解，业务流程是通过怎样的系统承接下来的。在承接的过程中，我们的数据他是什么样的结构，数据量是多少，数据质量如何等等，这些都是我们需要去了解的。
- 构建总线矩阵 总线矩阵个人认为更多的是为了帮助我们更好的统一规划数据仓库，也是为了更加的标准化。关于总线矩阵是怎么划分的？下面简单的说下，通常为一行代表业务过程。每一列是一个维度。在数仓建设的过程中，对一次性维度、一次性事实是有要求的。前面说过，在整个数仓的过程中，我们需要统一整个公司的数据的指标的口径，包括数据的一些认知等等，所以需要构建数据的总线矩阵。
- 构建CRUD矩阵 我们需要对每一个实体的创建、更新、删除等。比如说在整数仓中，我们选择一个维度，一般面临两个步骤：选择主维表和进行维度的主键的设计。在我们选择主维表的时候，如果你连这个维度在哪个系统创建的，在哪个系统更新的，在哪个系统删除的都不知道的话，如果出现这种情况是不太好的，所以我们需要构建CRUD矩阵。
2. 数仓规划(以下表为例)
数仓的上游统一的称之为数据源。统一生成数据源后，我们会把整个公司的业务进行划分。
比如说对业务线，业务板块进行划分，每一个业务线下可能会有很多业务板块。每个业务板块下面又有许多数据域。
每个数据域下面我们也会进行划分，比如说维度和业务过程。
维度我们设计成维度逻辑表，就是我们刚才所说的，你需要考虑以下三点，一个点就是你的主维表，第二个点就是你的维度的主键的设计，第三个点就是维度属性的选择。我们在做维度逻辑表的时候，我们建议尽量把我们的维度属性设计的丰富一点，因为现在的业务变化有点快，丰富一点对于整个数仓的稳定性和健壮性都是有好处的。
划分业务过程形成事实上的逻辑表，事实逻辑表包括事务性的事实，快照性的事实。更细的划分暂时就不进行细讲了。在此大家知道有这样一个概念就可以了。划分完成过后会形成整个公司的逻辑，包括维度逻辑这样一个表，会形成我们所说的DWD(数仓明细表)。
然后进行一个汇总，汇总我们更多的是根据派生指标包括像时间周期来进行一个指标的汇总，以此来形成汇总逻辑表。
3.数据仓库分层划分
根据上图可以看到数仓一般分为三层。第一层为ods层，我们通常把其叫做原始数据层，或者叫做操作数据层。第二层为中间层，第三层我们面向推荐系统、报表、数据分析等等，划分为ads层。整个数据仓库最重要的设计是中间层的设计，即是从明细层->dws层(数据汇总层)这一块的设计。
具体的分层要根据公司的实际需要来进行分层。
每层的作用： ods层：在此层中不建议进行太多的数据清洗、转换。只需要把业务系统中的数据，日志数据等等原汁原味的采集同步过来即可。
- 这样做的好处： ①降低对业务系统的入侵，减少业务系统的压力。 ②如果指标出错，ods层数据被改掉的话，只能从业务数据库或者日志数据库查找数据，这样是不利于我们进行血缘追溯和出错排查的。
因此所有的操作我们可以放在ods到dwd时进行，包括我们常见的维度退化、过滤、缺省值处理，按照业务过程进行拆分，冗余一些属性。 还可以把事实的粒度降低。
ads层响应整个推荐，包括报表等等响应应用。我们要把更多的一个逻辑划层放在中间层去做。可以保证整个公司的稳定性。
dim层是一个维度的层，维度层是可以各层级调用的，我们可以把部分的维度下沉或者冗余到其他层里面。
在做数仓的时候，我们要尽量减少Join，因为它不利于数据的处理。
数仓遵循的原则：不允许跨层调用，跨层出数。比如说在数据建模之后，我们需要对模型进行考评，模型建立的好不好，有一个指标就是看你跨层的调用率，包括你跨层出数的比率。如果上层应用、基本数据都来自于ads层，少部分来自于dws层，那么相对而言这个数仓的建设是比较不错的。
四、问题与思考
1. 维表的主键选择
自然键（NaturalKey），它是业务系统中已经存在的，通常是具有一定业务含义的一个字符型的标志符，可以唯一地标志维度表中的每一条记录。比如机构的代码、缩写、时间标签等。
另一种是代理键（SurrogateKey），通常是数据库系统赋予的一个数值，是自增型的，按顺序分配，没有内置含义但也可以唯一地标识一条维度信息。
项目经验，推荐采用第二种，即代理键。原因如下：
首先，自然键虽然在逻辑上可以唯一地标识出一条维度信息，但它通常是字符型的，且一般比较长，若用它作为维度表中的主键，那就意味着在事实表中也要加入同样的外键信息，而事实表记录行数往往是巨大的，在多个维度表上重复这样的做法会使事实表由于列宽过于膨胀而导致性能的急剧下降。
其次，代理键可以作为数据仓库与源系统之间的“缓冲”。自然键通常具有一定的业务含义，但日久天长，这些信息是有可能发生变化的，比如身份证号码，由最初的15位变成了现在的18位。如果这种主键一旦发生了变化，由于它同时作为事实表中的外键，必然会对事实表产生影响，因为已有的事实记录已经找不到与之匹配的维度记录，这就带来了很大的麻烦。但若采用代理键作为维度表中的主键，就完全可以把这些变化屏蔽在维度表内，不会对事实表产生任何影响（当然这个还要结合缓慢变化维度的处理）。
最后，从关联效率考虑，数值型的关联要比字符型的关联快很多。
2. 缓慢变化维(SCD)
- 维度保持不变；
- 直接进行维度的替换。如果发生变化，直接采用最新的，但是使用此方法想看到历史是什么样子就看不到了；
- 增加维度行或者维度列，此方法并不是太好。 以纬度行举例：增加纬度行以后，想把某一个事实全部关联成一个维度，这是非常难去处理的，所以其对处理这一块是不好的。 以维度列举例：增加维度列以后，确实是可以解决看历史看现在的问题。但是如果没变化一次就加一列的话，最终会导致表不利于维护，除此之外也不利于后续的数据分析。
- 使用拉链表，不过我们在使用拉链表的时候是需要进行细节考虑的。
- 维度快照，个人认为更方面处理各种情况。我们可以提前生成一个维度快照，等到查看的时候只需通过不同的快照去查就可以了，但是这样做的话，会增加我们的存储，会产生一定的浪费。
个人认为拉链表与维度快照是解决缓慢变化维比较好的方法。
3. 主数据与oneID的关系？
如果是传统型公司的话，可能会有这样一个问题。他们大都可能有这样一个问题：我们的主数据与oneID有什么样的一个关系?我们在建设数仓或者数据中台的时候，要不要先上一个主数据的系统呢？大概就是这样一个问题，如果遇到这种问题，我们应该如何回答呢？
说了oneID，我们就不得不说onedata。现在的数据中台很多都是基于onedata理论构建的。下图为onedata方法论。
OneData体系是阿里数据中台的核心方法论，其包含了三个方面内容：OneModel 即建立企业统一的数据公共层，从设计、开发、部署和使用上保障了数据口径规范和统一，实现数据资产全链路管理，提供标准数据输出。OneID 即建立业务实体要素资产化为核心，实现全域链接、标签萃取、立体画像，其数据服务理念根植于心，强调业务模式。OneService 即数据被整合和计算好之后，需要提供给产品和应用进行数据消费，为了更好的性能和体验，需要构建数据服务层，通过统一的接口服务化方式对外提供数据服务。
由于问题为主数据与oneID的关系。所以此部分简单介绍oneID。
在阿里巴巴数据中台官方宣传资料中，我们看到这样的定义：“OneID是以商业要素资产化为核心，实现全域链接、标签萃取、立体画像，数据应用服务整体解决方案。”这里的商业要素就是消费者、企业、内容、商品、位置等核心业务实体数据，传统上我们称其为主数据。而OneID也叫数据萃取中心，就是通过标签技术、知识图谱技术、画像技术在虚拟的网络世界实现商业要素（主数据）的唯一身份识别，保证企业核心数据的身份唯一性、一致性、完整性、相关性和准确性。所以，OneID可以理解为主数据管理，只是用的技术更先进些罢了。
个人认为：“阿里数据中台的OneID，本质上就是企业主数据管理”。但我相信一定也有人反对这个观点，因为在现行的主数据管理方案中，总体上还是趋于用标准、制度、流程、集成技术等手段解决主数据的问题，标签体系、知识图谱、画像技术、混合云技术等先进的技术目前还没有大规模用在主数据管理领域，但是我相信这终将是主数据发展的趋势！技术推动社会发展，主数据管理又岂能固步自封！
4. 如何进行模型调优？
我们知道数据仓库核心的是业务，那么业务又是怎么通过数仓来体现的，其核心是模型。那么模型如何进行调优和优化就是一个比较重要的问题。 在进行模型调优之前，我们需要先判断数据模型的好坏。具体步骤如下：
①完善度
- 汇总数据能直接满足多少查询需求，即应用层访问汇总层数据的查询比例
- 跨层引用率：ODS 层直接被 DWS/ADS/DM 层引用的表，占所有 ODS 层表比例
- 可以快速响应业务方的需求
比较好的模型，使用方是可以直接从该模型获取所有想要的数据的，如果dws，ads，dm层直接引用ods层的表比例太大，即跨层引用率太高，则该模型不是最优，可以继续优化
②复用度
- 模型引用系数：模型被读取并产出下游模型的平均数量
③规范度
- 主题域归属
- 分层信息
- 脚本及任务命名规范
- 表命名符合规范(清晰、一致，见名知意)
- 字段命名是依赖于词根
④稳定性
- 能否保证日常的sla（时效保障）
⑤扩展性
- 新增加的模型是否和老的模型出现冲突
⑥准确性&一致性
- 输出的指标数据质量能够保证
⑦健壮性
- 业务快速更新迭代的情况下不会太影响底层模型
⑧低成本
- 计算时间成本
- 计算资源成本
- 存储成本
⑨总结
- 完善度，复用度，规范度基本上是需要了解业务，然后根据元数据信息去做统计分析的
- 稳定性，低成本是需要对任务进行优化，比如sql调优等
- 准确性和一致性是需要一套质量管理系统及指标一致性管理方案的，包括数据源，口径和指标管理平台等。
知道判断模型的方法后，下面就可以针对这些方面进行调优。比如说我们创建维表的时候，选择主维表时，要尽量丰富我们的维度属性。我们在做维度设计的时候，一般情况下我们还会进行维表的整合与差分。这样做是为了让模型更加稳定。
五. 对数据仓库的思考
虽然数仓建设能带来诸多的益处，但其是一个庞大复杂耗时的工程，需要一些支持系统的配合，比如说元数据管理系统、调度系统等，而且也并不是所有的业务一开始都要建设数仓，要根据业务发展所处的状态和未来的发展趋势以及分析决策的复杂性等综合评判。
大数据系统，其复杂度之高，是几乎不可能在一开始就完整和完美地进行自上而下定义和设计的，其设计过程必然遵守从需求->设计->迭代->理论的过程。大数据的真正价值在于生命性和生态型，其价值是随着使用场景和方式动态变化的。
数据仓库的业务意义，在于从底层的数据采集、数据处理，到挖掘算法、数据应用服务以及数据产品的全链路、标准化的大数据体系。通过这个体系，超过EB级别的海量数据能够高效融合，并以秒级的响应速度，服务并驱动自身的业务和外部千万用户的发展。
数据仓库的技术意义，在于规避重复建设，统一计算口径，有效降低成本，提升开发效率。
文章内容到这里就结束了，如有不足请指出~
