作者：原上野

设计：Abby

编辑：AI君

互联网行业，除了数据量大之外，业务时效性要求也很高，甚至很多是要求实时的，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线。

本文主要从目前互联网行业数据的采集，存储，同步以及任务调度与监控方面阐述了大数据数据仓库建设的相关技术，还专门针对数据仓库的维度建模技术做了详细的介绍。

我们从大数据数据仓库建设的整体架构说起。

下图就是数据仓库的逻辑分层架构：

想看懂数据仓库的逻辑分层架构，必须弄懂以下四大概念。

数据源：数据的来源，互联网公司的数据来源随着公司的规模扩张而呈递增趋势，同时自不同的业务源，比如埋点采集，客户上报等。

ODS层：数据仓库源头系统的数据表通常会原封不动地存储一份，这称为ODS(Operation Data Store)层, ODS层也经常会被称为准备区(Staging area)。

DW层：数据仓库明细层(Data Warehouse Detail ， DWD)和数据仓库汇总层(Data Warehouse Summary, DWS)是数据仓库的主题内容。

DWS层：应用层汇总层，主要是将DWD和DWS的明细数据在hadoop平台进行汇总，然后将产生的结果同步到DWS数据库，提供给各个应用。

1

数据采集

数据采集的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。

比较常见的就是用户行为数据的采集。

先做sdk埋点，通过kafka实时采集到用户的访问数据，再用spark做简单的清洗，存入hdfs作为数据仓库的数据源之一。

2

数据存储

随着公司的规模不断扩张，产生的数据也越来越到，像一些大公司每天产生的数据量都在PB级别，传统的数据库已经不能满足存储要求，目前hdfs是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。

在离线计算方面，也就是对实时性要求不高的部分，Hive还是首当其冲的选择，丰富的数据类型、内置函数;压缩比非常高的ORC/PARQUET文件存储格式;非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码;而在实时计算方面，flink是最优的选择，不过目前仅支持java跟scala开发。

3

数据同步

数据同步是指不同数据存储系统之间要进行数据迁移，比如在hdfs上，大多业务和应用因为效率的原因不可以直接从HDFS上获取数据，因此需要将hdfs上汇总后的数据同步至其他的存储系统。

比如mysql;sqoop可以做到这一点，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库;阿里开源的dataX是一个很好的解决方案。

4

维度建模

维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。这里牵扯到两个基本的名词：维度，事实。

1、维度

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

2、事实

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。事实表中一条记录所表达的业务细节被称之为粒度。通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度;一种是所表示的具体业务含义。

维度建模用到的11大专业术语：

数据域、业务过程、时间周期、修饰类型、修饰词、度量/原子指标、维度、维度属性、 事实、派生指标、钻取。

本文不做赘述，如需解释可在公众号后台回复关键词，如“派生指标”，即可获取相应释义。

维度建模的三种模式

1.星形模式 ⬆

可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：

a. 维表只和事实表关联，维表之间没有关联;

b. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码;

c. 以事实表为核心，维表围绕核心呈星形分布;

2、雪花模式⬇

雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。

下图为使用雪花模式进行维度建模的关系结构：

星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。

然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。

3、星座模式⬇

星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式：

前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。

在业务发展后期，绝大部分维度建模都采用的是星座模式。

4、三种模式对比

归纳一下，星形模式/雪花模式/星座模式的关系如下图所示：

雪花模式是将星型模式的维表进一步划分，使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。

维度表设计

维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成维度属性的优劣，决定了维度是用的方便性，成为数据仓库易用性的关键。

数据仓库的能力直接与维度属性的质量和深度成正比。

维度表基本设计方法

以商品维度为例对维度设计放发进行详细说明。

第一步：选择维度或者新建维度。

作为维度建模的核心，在企业级数据仓库中，必须保证维度的唯一性。以商品维度为例，有且只有一个维度定义。

第二步：确定主维表。

此处的主维表一般是ODS表，直接与业务系统同步。

第三步：确定相关维表。

数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性，根据业务系统的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以商品维度为例，根据业务逻辑的梳理，可以得到商品与类目、sku、买家、卖家、店铺等维度存在的关联关系。

第四步：确定维度属性。

本步骤主要包括两个阶段，其中一个阶段是从主维表中选择维度属性或生成新的维度属性;第二个阶段是从相关维表中选择维度属性或者生成新的维度属性。以商品维度为例，从主维表和类目、sku、卖家、店铺等相关维表中选择维度属性或者生成新的维度属性。

确定维度属性的几点提示：

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

尽可能多的给出包括一些富有意义的文字描述;

区分数值型属性和事实;

尽可能沉淀出通用的维度属性。

​

该模式属于雪花模式。

注意：采用雪花模式，用户在统计分析的过程中需要大量的关联操作，是用复杂度高，同时查询性能很差，如果数据量巨大，那就更差了;因此需要将维度的属性层次合并到单个维度中，该操作称之为反规范化，采用反规范化处理，方便，易用且性能好。

对于商品维度，如果采用反规范化，将表现为下图所示的形式：

采用雪花模式，除了可以节约一部分存储之外，对于OLAP系统来说没有其他的效用。而现阶段存储的成本非常低。出于易用性和性能的考虑，维表一般设计成不规范化的。在实际应用中，几乎总是使用维表的空间来换取简明性和查询性能。

缓慢变化维

数据仓库的特征之一就是反应历史变化，所以如何处理维度的变化是设计的工作之一。缓慢变化维的提出是因为在现实世界中，维度的属性不是静态的，它会随着时间的流逝缓慢的变化，与数据增长较快的事实表相比，维度变化相对缓慢。

以下介绍几种处理这种情况的三种方式：

第一种方式：重写维度值。

采用此种方式，不保留历史数据(简单来说就是更新相关的维度字段)。比如商品所属类目与2019年5月20日由类目1变成类目2，采用第一种处理方式，变化记录的前后如下图所示：

第二种方式：插入新的维度行。

采用此种方式，保留历史数据，维度值变化前后的事实和过去的维度关联，纬度值变化前后的事实和当前的维度值关联。

第三种方式：添加维度列。

采用第二种方式不能将变化前后记录的事实归一为变化前的维度或者归一为变化后的维度。比如根据业务需求，需要将5月份的交易金额全部统计到类目2上，采用第二种方式无法实现。针对此问题，采用第三种处理方式，保留历史数据，可以使用任何一个属性列。

对于采用哪种方式解决缓慢变化维，只能根据业务需求去选择。

事实表设计

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

相对维表来说，事实表要细长的多，行的增加速度也比维表快很多。事实表分为三种类型：事务事实表，周期快照事实表，累计快照事实表。

本文主要讨论事务事实表，其他的两种会在以后的文章中说明。

本文不做词义赘述，如需解释可在公众号后台回复关键词，如“周期快照事实表”，即可获取相应释义

事实表设计原则及基本设计方法

尽可能包括所有业务过程相关的事实

只选择与业务过程相关的事实

分解不可加事实为可加的组件

选择维度和事实之前必须先声明粒度

在同一个事实表中不可以有多重不同粒度的事实

事实的单位要保持一致

对事实的null值要处理

使用退化维提高事实表的易用性

任何类型的事件都可以被理解成一种事务。比如交易过程中的创建订单，买家付款，物流中的发货，签收，付款等。事务事实表针对这些过程创建的一种事实表。

下面店铺交易事务为例，阐述事务事实表的一般设计过程。

1.选择业务过程：

交易的过程分为：创建订单、买家付款、卖家发货、买家确认收货，即下单、支付、发货和成功完结四个业务过程。

Kimball维度建模理论认为，为了便于进行独立的分析研究，应该为每一个业务过程建立一个事实表。

2.确定粒度：

业务过程选定之后，就要对每个业务过程确定一个粒度，即确定事实表每一行所表达的细节层次。需要为四个业务过程确定粒度，其中下单、支付和成功完结选择交易子订单粒度，即每个子订单为事实表的一行，买家收货的粒度为物流单。

3.确定维度：

选定好业务过程并且确定粒度后，就可以确定维度信息了。在店铺交易事实表设计过程中，按照经常用于统计分析的场景，确定维度包含：买家、卖家、商品、商品类目、发货地区、收货地址、父订单维度以及杂项维度。

4.确定事实：

作为过程度量的核心，事实表应该包含与其描述过程有关的所有事实。以店铺交易事实表为例，选定三个业务过程:下单、支付、成功完结，不同的业务过程有不同的事实。比如在下单业务过程中，需要包含下单金额、下单数量、下单分摊金额;

经过以上四步店铺交易事务事实表已成型，如下图所示：

在确定维度时，包含了买卖家维度，商品维度，类目维度，收发货等。Kimball维度建模理论建议在事实表中只保留这个维度表的外键，但是在实际的应用中，可以将店铺名称、商品类型、商品属性、类目属性冗余到事实表中，提高对事实表的过滤查询，减少表之间的关联次数，加快查询速度，该操作称之为退化维。

经过以上的操作，基本完成了店铺交易事务事实表的设计工作。

5

元数据管理

元数据通常定义为”关于数据的数据”,在数据仓库中是定义和描述DW/BI系统的结构，操作和内容的所有信息。

元数据贯穿了数据仓库的整个生命周期，使用元数据驱动数据仓库的开发，使数据仓库自动化，可视化。

按照不同的用途将元数据分为两类：技术元数据和业务元数据。

技术元数据指描述系统中技术细节相关的概念、关系和规则的数据，包括对数据结构、数据处理方面的描述，以及数据仓库、ETL、前端展现等技术细节方面的信息。常见的技术元数据有：

1、分布式计算存储元数据，如表、列、分区等信息。记录表的表名、分区信息、责任人信息、文件大小、表类型、生命周期、列的字段、字段类型、字段备注等。

2、分布式计算系统运行元数据，集群上所有任务的运行信息;类似hive的运行日志，包括作业类型、实例名称、输入输出、运行参数、运行时间等。

3、调度任务中的调度信息，包括输入输出字段、依赖类型、依赖关系等。

4、数据质量跟运维相关元数据，如任务监控、运维报警、数据质量、故障等。

业务元数据指从业务角度描述业务领域相关的概念、关系和规则的数据，包括业务术语和业务规则等信息。常用的技术元数据有：

如维度和属性、业务过程、指标等规范化定义，用于更好的管理和使用数据。数据应用元数据，数据报表、数据产品等配置和运行元数据。

6

任务调度与监控

在数据仓库建设中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据清洗任务、数据分析任务等;这些任务除了定时调度，还存在非常复杂的任务依赖关系。

比如：数据分析任务必须等相应的数据采集任务完成后才能开始;数据同步任务需要等数据分析任务完成后才能开始;这就需要一个非常完善的任务调度与监控系统，它作为数据仓库的中枢，负责调度和监控所有任务的分配与运行。

目前有能力的公司都是自己开发调度工具，如中国平安(linkdu);银行行业用的较多是Control-M;一些互联网公司可能会选择airflow作为自己的调度工具。

具体采用哪种工具，可以根据自己公司的本身现状去做定夺。

作者总结

在我看来，数据仓库建设是一个综合性技术，而且当企业业务复杂的时候，这部分工作更是需要专门团队与业务方共同合作来完成。

因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。

另外，架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。