终于有人把数据仓库讲明白了

作者：彭锋 宋文欣 孙浩峰

来源：大数据DT（ID：hzdashuju）

数据仓库是一个面向主题的、集成的、随时间变化但信息本身相对稳定的数据集合，用于支持管理决策过程。数据仓库的主要功能如下：

• 建立公司业务数据模型；

• 整合公司数据源，让清洗和治理之后的数据成为业务数据的唯一事实；

• 支持进行细粒度的、多维的分析，帮助高层管理者或者业务分析人员做出商业战略决策；

• 为更高一层的数据服务、机器学习应用提供主要的历史数据来源。

数据仓库的发展已有近40年的历史，但是它在大数据平台出现之前主要处理的是关系型数据库中的数据（这里称之为传统数据仓库）。在大数据出现之后，数据仓库承担的任务并没有变，但是其建设方式、建设内容和技术架构都发生了很大的变化。本文将对此做个简单介绍。

与ODS一般保存支持业务运营的当前数据不同，数据仓库记录的是业务数据的历史及汇总数据。在很多系统中，ODS对应的持久性数据存储也叫作贴源数据层，其意义都是一样的：从业务系统中采集的不作修改的OLTP操作数据集。ODS除了作为OLTP数据的导入区之外，也可以处理一些分析需求。表10-2对二者进行了简单对比。

▼表10-2 ODS和数据仓库的对比

01 数据建模方式

关于数据仓库中的建模，已经有很多介绍传统数据仓库的书详细介绍过，因此这里只做简单介绍。

数据仓库的模型分为三层：概念模型、逻辑模型和物理模型。

• 概念模型将业务抽象出来，实现对实际业务的数字化描述。

• 逻辑模型将概念模型进行结构化的设计，使其能够用于后续的分析和管理。

• 物理模型将逻辑模型映射到实际的物理存储上，例如数据库、表的设计。

一般数据仓库中的建模工作主要在于逻辑模型层，常见的有实体关系（ER）建模和维度（dimensional）建模两种方式。

实体关系建模使用实体加关系的3NF模型来描述企业业务架构。值得注意的是，业务系统（OLTP）里的3NF模型一般针对某个具体的业务流程，而数据仓库（OLAP）里的3NF模型一般针对企业全局的实体和关系抽象，强调数据的汇聚整合和一致性治理。

被誉为“数据仓库之父”的Bill Inmon比较倡导实体关系建模。例如，Teradata为金融业设计的FS-LDM（Financial Services Logical Data Model）就是一个典型的实体关系模型（见图10-2），它将常见的金融活动抽象和总结为10个主题以及它们之间的关系，这10个主题是当事人、产品、协议、事件、资产、财务、机构、地域、营销和渠道。

▲图10-2 Teradata FS-LDM

实体关系建模的好处是符合3NF，数据冗余少，容易进行数据整合和治理。但是不推荐将这种方式用于基于大数据的数据仓库建模，因为其建设周期长，设计者必须深刻了解企业的全局业务之后才能设计和实施，且其不能很好地支持业务的快速变化。

维度建模由数据仓库和商务智能领域的权威专家Ralph Kimball提出，其核心思想是从业务分析决策的需求出发构建模型。

具体来讲，就是将需要分析的业务流程的基本信息（如一次交易的交易ID、客户ID、门店ID、货物ID、交易时间、交易金额）记录在事实表中，而将与此业务流程相关的通用信息（如客户信息、门店信息、货物信息）记录在维度表中。

与实体关系建模不同，维度建模一般使用星型模型或者雪花模型，会有一定的数据冗余（例如在同一次交易中的多个货物记录中，交易ID、客户ID、门店ID等可能会重复），也不符合3NF，但它是我们在为数据中台建设数据仓库时更推荐的建模方式，因为相比实体关系建模，它具有以下优势：

• 比较直观和便于理解，一条事实表中的记录就可以还原一个业务流程的大部分信息；

• 处理复杂的查询效率较高，无须做大量会占用很多计算资源的join操作；

• 能够快速支持业务的变化和扩展，可以方便地添加新的业务模型及维度，而无须考虑复杂的依赖关系；

• 可以快速实施和见效，可以有针对性地选择业务场景落地然后再逐渐扩展。

02 数据仓库建设的层次

理论上，基于Hadoop的数据仓库建设有多种分层方法：有的体系中没有专门的数据湖，而把ODS归为数据仓库的一部分，有的体系中把数据集市也归为数据仓库的一部分，还有的体系中把维度数据单独算作一层。虽然分层方法不一，但是一般的数据仓库建设过程和思路在原理上都是类似的。

在本文中，我们将数据仓库的建设简单分为数据湖、数据仓库和数据集市三层，其中，数据仓库层可以进一步分为明细数据层（DWD，也称基础数据层）和数据汇总层（DWS，也称通用数据层）。此外，我们使用统一的维度数据表和元数据/主数据管理系统，如图10-3所示。

▲图10-3 数据仓库层次

下面介绍一下数据仓库里各个层次的主要功能、数据模型以及主要数据处理方式。

值得注意的是，很多数据仓库系统都可以根据自己的实际情况来组织这些层次的功能，比如，由于使用专门的原始明细数据层会多占用很多空间，很多实际项目就将数据湖中的ODS稍微扩展一下，而不专门设置原始明细数据层；也有系统干脆就把ODS规划到数据仓库的范畴。

还有，虽然数据集市通常是与数据仓库区分开的，以显示其面向具体业务、直接使用的特征（所以一般称之为应用数据集市），但是数据仓库的建设一般都会包括数据集市。其实这个名称是什么并不重要，关键是要理解每一层承担的工作和设计原则。

1. 原始数据

一般按照业务域组织业务数据的原始明细历史记录。有时这一层直接由ODS承担，如单独设置了这一层，其数据模型基本与ODS一致，再加上一些数据处理需要的统一扩展字段，例如入库时间、更新时间、处理批次等。

有时会在这一层进行名称、代码的标准化，例如表名的统一规范、表名的去重处理，以及一些简单的维度表合并和代码转换等。这些数据既可以按增量组织，根据年、月、日进行分区，也可以进行全量组织，每天存储一个最新的全量快照。

2. 明细数据

将原始明细数据根据业务规则进行各种数据清洗处理，包括ID转换、字段合并、脏数据处理、维度数据标准化、脱敏处理、数据质量检测等。

这一层的数据模型需要将主数据和维度数据模型确定下来，例如用户、产品、交易等主数据及其标准维度，并将原始数据通过ETL执行前期处理，将结果数据存储到相应的清洗明细表里。

一般这一层还负责将一些非结构化数据（日志、埋点数据）解析和治理转换成结构化的明细表，例如将服务器日志解析成用户访问明细表等。绝大部分的数据治理工作都发生在这一层，这一层的工作量也是最大的。

这一层的数据的ID、维度数据值已经标准化和经过验证，将被作为数据分析的主要基础，其清洗和处理的逻辑比较复杂，在处理中出现错误时往往需要重新计算。因此，血缘、版本、变更管理对这一层数据的有效管理是很关键的。

3. 汇总数据

汇总数据是在清洗的明细数据基础上生成的细粒度的汇总聚合结果。这一层的数据模型一般就是根据业务需求按照星型模型或者雪花模型建设的最细粒度的汇总，所以基本上就把数据仓库的分析功能确定了。

例如，如果要按渠道（channel）、用户性别（gender）、年龄（age）、收入水平（income）、产品品类（category）、广告引流（referer）来查询产品的销售情况，那么就要有一个专门的汇总事实表来处理这个查询，其命名类似于sales_by_channel_gender_age_income_category_referer。

这个表名中包含了涉及的每个维度的每一个可能的取值组合，且细化到每天或每小时的销售额。每一个字段里的维度值都是标准的ID，对应到相应维度表中的取值。

数据仓库的建模就主要发生在这一阶段，数据仓库分析的限制就是这里建立的数据模型的能力。

例如，在上面的模型里，我们可以使用细粒度数据的聚合来回答sales_by_channel（上月在淘宝上的销售额）+sales_by_referer（昨天百度广告带来的销售额）这样的聚合查询（roll up），也可以回答“昨天35岁以上高收入男性通过百度广告在淘宝上购买3C产品的销售额”这种下钻查询（drill down）。

但是，如果我们再加一个维度，例如地区（region），这个模型就不能支持了。这时我们需要修改模型，重新计算。

对于这种情况，有一种思路是，可不可以事先把所有的维度都加进去？这种思路的主要问题在于数据条目会随维度组合数目的增加而迅速增长。

如果有50个维度，每个维度有100个可能的取值，那么一条销售记录就可能产生5000条汇总记录，在实际工作场景中可能会更多。除了数据量巨大、ETL任务耗时长之外，这样的方案在做聚合查询的时候效率也很低。

这种高维组合数据一般称为数据立方体（Data Cube），其生成和计算问题有两个传统的解决办法。

• 其一，根据业务需求人工确定最常用的组合，例如，上面的表可以分为sales_by_channel_gender_age_income_referer_region和sales_by_channel_category_referer_region，如果业务部门有其他组合，可以使用即席计算来算一下，但无法做到实时交互了。

• 其二，使用Kylin这样的预计算和动态规划的Cube Planner。

4. 数据集市

这一层一般包含业务部门按照业务域建立的特定主题的汇总表，反映了业务运行的状况。数据集市中的数据主要来源于汇总数据事实表，但是近年来也有不少人通过数据分析或机器学习应用直接从数据湖生成数据集市报表，毕竟汇总明细表受限于事先的设计。

与汇总数据事实表不同，数据集市的数据表包含直接体现业务属性的字段，比如数据集市中的客户订单统计表包含地区名称和商品名称（但不一定包含地区编码和商品编码）。

这是因为数据集市中的数据表往往会被直接输入可视化的BI工具中进行进一步的分析，地区和商品这些维度字段都会直接采用名称来直观表示其业务属性，以省去查询时的join操作。

例如前面的销售汇总表可能会生成一个名为sales_by_channel_referer_region的数据集市报告，供市场部门监测广告在各个渠道和市场中的表现。

数据集市中的数据一般都是数据应用的数据来源，比如我们前面提到的可视化BI工具可以以图表的方式呈现数据集市中的数据，或者以数据立方体（多维数据）的方式对数据集市中的数据进行多维度分析（比如上卷、钻取、切片、切块等操作）。

03 数据仓库中的数据治理

数据仓库中的数据治理以解决实际业务问题为导向，以提升数据资产的管理水平和使用效率为目标，并以元数据为驱动，连接数据标准管理、数据质量管理、数据安全管理各个阶段，形成统一、完善、覆盖数据全生命周期的数据治理体系。数据仓库中的数据治理主要针对以下问题。

• 第一，数据分散、杂乱，无法理解。很多企业业务线众多，数据源分散，且各系统间无法打通，成为信息孤岛；数据收集标准不相同，数据零散地存储在各个业务系统中，难以形成全局数据联动。

• 第二，数据收集渠道单一，模式落后，效率低，成本高。业务增长带来数据增长，传统数据管理模式难以应对大数据增长。从渠道上来说，传统数据收集渠道单一、落后、偏线下化；从方式上来说，很多企业收集信息的手段仍停留在手工收集阶段，效率低、成本高且造成数据不匹配。

• 第三，数据标准不统一，缺乏分析工具，数据难运用。一方面，数据标准不统一导致整合困难，难以进行全局联动；另一方面，缺乏数据分析工具，仅靠数据专业人才难以满足企业需求，且难以看到数据的实时变化及价值。这两方面的因素导致难以真正实现数据驱动业务发展，提升运营管理水平。

• 第四，系统落后，难以满足数据管理需求，存在数据风险隐患。在数据井喷式增长的当下，众多企业未能跟上随数据增长而变化的需求，难以满足监管要求，同时存在数据隐患及风险问题。

为了解决以上问题，数据治理一般需要提供以下功能组件。

• 元数据管理：通过统一的元数据管理满足各类用户的数据资源使用需求，实现数据资产的可视化管理。

• 数据质量管理：通过数据质量控制方法，使得数据的采集、存储和使用符合相关的质量要求。

• 数据安全管理：保证数据不因偶然或恶意的原因而遭到破坏、更改或泄露，还包括数据访问权限控制、数据安全服务、数据访问审计等。

• 数据标准管理：为数据标准提供系统工具支撑，包括标准管理、标准展示、标准监控等功能。

• 元数据管理接口：提供元数据查询、数据加解密、数据资产注册接口和SSO接口。

• 数据管理门户：包括数据资产查询以及数据质量、数据安全、元数据和数据标准集成门户等。

在数据治理的过程中，我们一般需要解决数据采集、数据标准、数据组织和转换、数据使用等问题。这里我们主要介绍数据标准和数据质量的有关工作。

数据标准是指保障数据内外部使用和交换的一致性和准确性的规范性约束。数据标准一般包括三个要素：标准分类、标准信息项（标准内容）和相关公共代码（如国别代码、邮政编码）。

数据标准通常可分为基础类数据标准和指标类数据标准。

• 基础类数据标准一般包括数据维度标准、主数据标准、逻辑数据模型标准、物理数据模型标准、元数据标准、公共代码标准等。

• 指标类数据标准一般分为基础指标标准和计算指标（又称组合指标）标准。基础指标一般不含维度信息，且具有特定业务和经济含义，计算指标通常由两个以上基础指标计算得出。

数据标准管理是指制定和实施数据标准的一系列活动，其中的关键活动有：

• 理解数据标准化需求；

• 构建数据标准体系和规范；

• 规划制定数据标准化的实施路线和方案；

• 制定数据标准管理办法和实施流程要求；

• 建设数据标准管理工具，推动数据标准的执行落地；

• 评估数据标准化工作的开展情况。

数据标准管理的目标是通过制定和发布统一的数据标准，结合制度约束、系统控制等手段，确保企业大数据平台数据的完整性、有效性、一致性、规范性和开放性，为数据资产管理活动提供参考依据。

很多行业监管机构都会组织发布行业数据标准。例如，中国银保监会于2018年5月发布了《银行业金融机构数据治理指引》，绝大部分银行在建设大数据平台或数据中台的时候，必须了解这个数据标准中的内容，并将其融入数据中台的建设中。

那么，怎样才算将数据标准融入数据中台的建设中了呢？

一般来说，就是将数据标准中所描述的数据必须遵守的规则，比如数据取值范围、数据项之间的关系和局限，都用代码表现出来，然后系统持续对需要管理的数据集运行这些检查代码（也有直接修补的代码），如果出问题就报错。这样就保证了数据系统中的数据符合规范。

很多时候，达到这些标准的要求并不需要直接编写代码，而可以使用专门的数据治理工具的DSL来配置数据质量规则。

因为数据标准的编写与行业结合紧密，而且通常有专门的数据治理工具来实施这些数据质量的工作，这里就不展开了。

04 数据清洗

数据治理工作中有一个很重要的步骤是数据清洗。数据清洗有两个目的：一是解决数据质量问题，二是让数据更适合做挖掘。数据清洗的结果是对各种脏数据进行相应的处理，得到标准、干净、连续的数据，供数据统计、数据挖掘等使用。数据的质量问题一般包括下面几种情况。

• 数据不完整，例如患者的属性中缺少性别、籍贯、年龄等。

• 数据不唯一，例如不同来源的数据出现重复的现象。

• 数据不权威，例如同一个指标出现多个来源的数据，且数值不一样。

• 数据不合法，例如获取的数据与常识不符，如年龄大于150岁。

• 数据不一致，例如不同来源的不同指标实际内涵是一样的。

处理数据质量问题一般有以下方法。

• 数据完整性：直接补齐数据。没有办法直接补齐的，通过其他信息补全，例如使用身份证件号码推算性别、籍贯、出生日期、年龄等。还可以通过前后数据补全，例如时间序列缺数据，可以使用前后的均值；如果缺的数据较多，可以使用平滑等处理。

• 数据唯一性：去除重复记录，只保留一条。可以按数据库主键去重，也可以按规则去重。编写一系列规则，对重复情况复杂的数据进行去重，例如对于不同渠道来的客户数据，可以通过相同的关键信息进行匹配，合并去重。

• 数据的权威性：对不同渠道设定权威级别，用最权威的那个渠道的数据。

• 数据的合法性：设定强制合法规则，凡是不在此规则范围内的，强制设为最大值，或者判为无效并剔除。例如，字段类型合法规则中，日期字段格式为year-month-day；字段内容合法规则中，性别属于男、女或未知。

• 数据的一致性：建立数据体系，包含但不限于指标体系（度量）、维度（分组、统计口径）、单位、频度、数据。

让数据更适合做数据挖掘的方法一般有如下几种。

• 降低高维度数据的维度：一般采用主成分分析法和随机森林法。

• 处理低维度数据：通过汇总、平均、加总、取最大值、取最小值、离散化、聚类、自定义分组等方法来抽象。

• 处理无关和冗余信息：剔除无关的和冗余的字段。

• 处理多指标数值：对多指标数值进行归一化，例如取最大/最小值、取均值等。

关于作者：彭锋，智领云科技联合创始人兼CEO。武汉大学计算机系本科及硕士，美国马里兰大学计算机专业博士，主要研究方向是流式半结构化数据的高性能查询引擎，在数据库顶级会议和期刊SIGMOD、ICDE、TODS上发表多篇开创性论文。2011年加入Twitter，任大数据平台主任工程师、公司架构师委员会大数据负责人，负责公司大数据平台及流水线的建设和管理。

宋文欣，智领云科技联合创始人兼CTO。武汉大学计算机系本科及硕士，美国纽约州立大学石溪分校计算机专业博士。曾先后就职于Ask.com和EA（电子艺界）。2016年回国联合创立智领云科技有限公司，组建智领云技术团队，开发了BDOS大数据平台操作系统。

孙浩峰，智领云科技市场总监。前CSDN内容运营副总编，关注云计算、大数据、人工智能、区块链等技术领域，对云计算、网络技术、网络存储有深刻认识。拥有丰富的媒体从业经验和专业的网络安全技术功底，具有超过15年的企业级IT市场传播、推广、宣传和写作经验，撰写过多篇在业界具有一定影响力的文章。

本文摘编自《云原生数据中台：架构、方法论与实践》，经出版方授权发布。

延伸阅读《云原生数据中台：架构、方法论与实践》

点击上图了解及购买

转载请联系微信：DoctorData

推荐语：前Twitter大数据平台主任工程师撰写，融合硅谷与国内经验，全面讲解云原生数据中台架构、选型、方法论、实施路径，国内外专家联袂推荐。

划重点????

干货直达????

• 机器人与人工智能的关系，终于有人讲明白了
  

• Flink的设计与实现：集群资源管理
  

• 10本书，帮你看清未来的科技趋势
  

• 什么是知识图谱？有哪些典型应用？终于有人讲明白了

更多精彩????

在公众号对话框输入以下关键词

查看更多优质内容！

PPT | 读书 | 书单 | 硬核 | 干货 | 讲明白 | 神操作

大数据 | 云计算 | 数据库 | Python | 爬虫 | 可视化

AI | 人工智能 | 机器学习 | 深度学习 | NLP

5G | 中台 | 用户画像 | 1024 | 数学 | 算法 | 数字孪生

据统计，99%的大咖都关注了这个公众号

????