数仓|该如何理解数据仓库的建设

什么是数据仓库

数据仓库,最早由比尔·恩门（Bill Inmon）于1990年提出,主要功能是将组织或企业里面的联机事务处理(OLTP)所累积的大量数据，透过数据仓库理论所特有的储存架构，进行系统的分析整理，以利于各种分析方法如联机分析处理(OLAP)、数据挖掘(Data Mining)的进行，并进而支持如决策支持系统(DSS)、主管信息系统(EIS)的创建, 帮助决策者能快速有效的从大量数据中分析出有价值的信息。

目前, 被广泛接受的数据仓库的定义是由Bill Inmon在1991年出版的 "Building the Data Warehouse"一书中所提出的，其定义如下: 数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、反映历史变化(Time Variant)、相对稳定的(Non-Volatile)的数据集合，用于支持管理决策(Decision Making Support)。

其实，在大数据时代，随着机器学习和人工智能的兴起，这个定义需要做一些补充：数据仓库不只是用于构建支持管理决策的商业智能BI的基础, 也是大量的机器学习和人工智能算法的底层基础之一。

那么该如何理解上面的抽象定义呢？主要包括以下几个关键词：

• 面向主题

数据仓库是用来分析特定的主题域的，比如用户、交易、流量等等，主题域的划分也是构建数仓总线矩阵的基础。关于主题的划分，是建立在深入理解业务的基础之上的，并没有一个统一的标准，一个基本的原则是：主题域要尽量涵盖所有的表。可以将主题理解为业务的归纳，属于一个大的分类，有了明确的主题划分，数仓的建设才不至于混乱。

• 集成

我们知道，数据仓库之所以称之为仓库，是因为其集成了多种OLTP的数据源，将不同的数据源汇总至数仓的过程就是集成，数据源A和数据源B可能是识别某个产品的不同的方向，但是在数据仓库中，仅有一个方式来识别某个产品, 对于同一产品中分散在不同的数据源中的不同信息，数据仓库需要进行数据抽取、清洗、整合;对于分散在不同的数据源中的同一冗余信息则需要消除不同数据源的不一致性，以保证数据仓库内的信息是关于整个企业/业务/主题的一致的全局信息。

• 反应历史变化

这一点很好理解，简单讲就是包含历史的所有数据。这点是相对数据库而言, 因为后者通常保持是是最近一段时间的数据。例如:我们可以从数据仓库中获取3个月, 6个月，12个月甚至10年的订单数据; 而数据库里可能只能获取最近3年的订单数据。

• 相对稳定

一个数据一旦进入数据仓库，则不可改变。数据仓库的历史数据是不应该被更新的。这里需要强调的是：一是历史一旦形成，不可更改。几乎所有的数据仓库产品都不支持更新修改操作，但是是支持重载操作，所以是相对的，而非绝对不可更改。

数据仓库不是什么

初学者对于数据仓库最常见的误解：

• 是一个产品

与很多产品提供商所声称的相反，你不能直接买到一个数据仓库，数据仓库包含了数据集成，数据ETL，维度模型、元数据管理、数据质量管理、数据的可视化等等，没有一个单一的产品能完成数据仓库的全部过程。另外，数仓的构建是强依赖与业务的，对于不同的业务而言，其数仓的形态也是不尽相同的。值得注意的是，数仓是随着业务的变化而不断迭代的，所以没有毕其功于一役的方法，这也注定了数仓是在不断的变化中趋于完善的。

• 一个项目

成功的企业级数据仓库通常是以可管理的数据集市开始的，每个数据集市都可看成是单独的项目，带有自己的项目周期和预算。关键因 素在于每个数据集市带有一致的维度和标准的事实表，这样便于将单个的数据集市集成到一个紧密的单元——企业级数据仓库中。随着各个数据集市项目的完成，企业级数据仓库将最终发展起来。因此，思考数据仓库更好的方法是将它看成一个过程，而非一个项目。

• 一个数据模型

简单讲，数仓是由一堆数据模型和数据构成的，数据模型是数仓的基础。但是数仓是多个过程的集合，并不单单指数据模型，还包括上面提到的各个环节。

• oltp系统的一套备份

这是一个很常见的误解，认为将业务系统的数据备份一份并在此基础之上建立报表系统就算是构建了数仓，其实不然，只完成数据迁移过程而不重构数据模型也不能构成数据仓库。

数据仓库系统体系结构

数据源->ETL->数据仓库存储与管理->OLAP->BI工具。

• 数据源：通常包括各种业务系统数据、日志数据、外部数据；

• ETL（extract/transformation/load）:整合数据并将它们装入数据仓库的过程。将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将分散、零乱、标准不统一的数据整合到一起，为决策提供分析的依据；

• 数据的存储与管理：数据的存储和管理是整个数据仓库的关键。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库（通常称为数据集市）；

• OLAP（On-Line Analysis Processing）:从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取。OLAP系统按照数据存储格式可以分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型；

• 前端工具:查询工具、数据分析工具、数据挖掘工具、种报表工具等。

数仓的必要性

• 数据孤岛

因为每个人基于自己的业务场景建设数据，竖起了一根根的烟囱，相互之间数据不互通，导致不论是中间数据还是结果数据，可能只能被自己使用。也不知道别的场景有哪些数据，有的数据是否适合自己的场景。

• 解决问题范围有限

因为数据不互通，对一个系统或业务的理解有限，无法最大化应用数据的价值。

• 效率不足

烟囱数据每次都穿透使用贴源数据，没有公共数据沉淀，无法高效复用。每次都要重复开发，费时费力。

• 成本不可控

因为大量重复建设，在计算和存储方面都有大量浪费。尤其在海量的监控数据，因为没有沉淀，不知道存储周期设定多久合适，“那就存越久越好，万一以后要用到呢”。价值发挥有限，反而花费大量实际成本。

数仓建模

维度建模5步骤

维度建模从分析决策的需求出发构建模型，为分析需求服务，因此 它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复 杂查询的响应性能。其典型的代表是星形模型，以及在一些特殊场景下 使用的雪花模型。其设计分为以下几个步骤。

• 选择需要进行分析决策的业务过程。

  业务过程可以是单个业务事件，比如交易的支付、退款等;也可以是某个事件的状态，比如当前的账户余额等;还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态， 或是事件流转效率。

• 选择粒度。

  在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的 一个组合。值得注意的是，在一个事实表中不要混用多种不同的粒度。

• 识别维表。

  选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。从who、what、when、where、why、how等方面描述。

• 选择事实。确定分析需要衡量的指标 。比如子订单商品的数量、金额等等。

• 冗余维度

维度设计基础

维度基本概念

• 维度

维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实” ， 将环境描述为“维度”，维度是用于分析事实所需要的多样环境。例如， 在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易 发生的环境。

• 维度属性

维度所包含的表示维度的列，称为维度属性。维度属性是查询约束 条件、分组和报表标签生成的基本来源，是数据易用性的关键。例如， 在查询请求中，获取某类目的商品、正常状态的商品等，是通过约束商品类目属性和商品状态属性来实现的，那么类目和商品状态就是维度属性。

• 如何获取

维度的作用一般是查询约束、分类汇总以及排序等。如何获取维度或维度属性?如上面所提到的，一方面，可以在报表 中获取;另一方面，可以在和业务人员的交谈中发现维度或维度属性。因为它们经常出现在查询或报表请求中的“按照”( by)语句内。例如， 用户要“按照”月份和产品来查看销售情况，那么用来描述其业务的自 然方法应该作为维度或维度属性包括在维度模型中。

• 总线矩阵

用于设计并与企业数仓总线架构交互的基本工具，矩阵的行代表业务过程、矩阵的列代表维度，点表示维度于给定的业务过程是否存在关系。

维度建模的基本设计方法

方法

维度的设计过程就是确定维度属性的过程，如何生成维度属性，以 及所生成的维度属性的优劣，决定了维度使用的方便性，成为数据仓库 易用性的关键。正如 Kimball 所说的，数据仓库的能力直接与维度属性 的质量和深度成正比。

• 第一步:选择维度或新建维度。作为维度建模的核心，在企业级数 据仓库中必须保证维度的唯一性

• 第二步:确定主维表。此处的主维表一般是 ODS 表，直接与业务 系统同步。

• 第三步:确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同 一业务系统中的表之间存在 关联性。

• 第四步 :确定维度属性 。本步骤主要 包括两个阶段，其中第 一 个阶 段是从主维表 中选择维度属性或生成新的维度属性;第 二个阶段是从相 关维表中选择维度属性或生成新 的维度属性。

注意点

• 尽可能生成丰富的维度属性

• 尽可能多地给出包括一些富有意义的文字性描述，一般是编码和文字同时存在，比如商品维度中的商品 ID 和商品标题、 类目 ID 和 类目名称等。ID 一 般用于不同表之间的关联，而名称一般用 于报表标签。

• 区分数值型属性和事实

  数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性;如果通常 用于参与度量的计算， 则是作为事实

• 尽量沉淀出通用的维度属性

  有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表 的不同宇段混合处理得到，或者通过对单表 的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进行沉淀。

事实表

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设 计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度 和与业务过程有关的度量。

事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可 以通过两种方式来表述:一种是维度属性组合所表示的细节程度:一种 是所表示的具体业务含义。

事实表有三种类型 : 事务事实表、周期 快照事实表和累积快照事实表。

数据模型设计

模型目标

• 口径一致

• 避免重复计算

• 易于数据服务

• 充分支持业务

数据模型涉及的几个方面

• 数仓分层

• 业务主题

• 维表/事实表

• 命名规范

如何规划数仓

良好的模型抽象和清晰的层次划分能保障支持各种复杂的数据业务接入并较好的支撑数据业务，这是大部分规划数仓时会重点关注的问题。其实，不同时期来考衡标准是不一样的，初期可能主要考虑的把业务支撑好，中后期可能主要重心在模型和数据治理上，通过不同阶段将数据业务价值最大化同时保障数据建设健康发展。

初期

• 管理方便性：0

• 模型通用性：0.1

• 数据治理：0.1

• 安全保障：0.1

• 业务支持：0.7

中后期

• 管理方便性：0.1

• 模型通用性：0.2

• 数据治理：0.3

• 安全保障：0.2

• 业务支持：0.2

在数据仓库建设初期，由于仓库数据沉淀少，大量的业务数据需要处理，是暂缓业务数据需求开发待仓库建设好全力支撑业务？还是全力保障业务支持逐步来建设数据仓库建设？这两个问题可能也困扰着很多人，个人觉得还是先run起来，先解决一些业务问题，即先产出一些价值，这样会更容易推进后面的工作。如果一上来就大而全，一方面产出价值少被老板挑战，另一方面实施周期长，很容易成为一个较大的成本中心。在快速发展的互联网行业像这种建设方式显然不太合适，通过数据支持保障业务快速发展是我们首要考虑的问题。值得注意的是：先run起来并不是意味着不遵从任何的规范，只不过首要的问题的支持业务。等到数仓建设到中后期，这个时候就需要考虑数据治理的问题，而不是一味的去满足需求，比如考虑主题数据的中间层数据资产沉淀、模型优化、任务优化、存储与计算成本优化等等，从而使得数仓逐渐趋于完善。

如何评价数仓

• 需求响应敏捷 数据仓库建设不是需求驱动的，但是数据仓库的根本目的还是面向决策的。在现实中，数据仓库团队承担着很多数据查询分析的职责，经常会收到业务方的数据需求。一个好的数据仓库模型，能预知业务方的数据需求，足够灵活扩展。能做到这一点，首先需要建立元数据管理工具，从而可以方便快速查找数据的基本信息。其次，还需要有大量的数据中间层，有预先算好的数据指标。此外，数据自助提取工具也是快速响应数据需求的必备工具。

• 数据质量可靠 在数据开发过程中，很多人可能会遇到这种情况，开发时间只用了1周，数据测试和校验用了2周甚至更长时间。测试校验时间长，往往不是由于计算逻辑复杂，而是上游数据不规范，不可靠，不可信，需要花很大的代价自己做校验和数据探查，这在一定层面上也反映出模型的设计有问题。

• 可扩展 数据仓库经常会面对业务的变化，比如业务方拿到一个结果后，经常会与更多的维度交叉分析，或者粒度上做上卷或下钻，还有对统计口径做特别的限定。数据仓库在要能覆盖这些不可预知的变化的需求。更麻烦的是，业务规则会发生变化。良好的数据仓库设计要能兼容这些变化，否则以前积累的数据都将变成垃圾。

• 稳定性 数据仓库还要稳定地保障数据的产出，服务于业务系统，不要经常掉链子。造成不稳定的因素往往是机器网络等硬件因素，但是良好的数据仓库设计能在硬件故障后快速恢复数据，不会造成连锁的灾难。

原文