背景

了解数据仓库、数据流架构的搭建原理对于合格的数据分析师或者数据科学家来说是一项必不可少的能力。它不仅能够帮助分析人员更高效的开展分析任务，帮助公司或者业务线搭建一套高效的数据处理架构，更是能够从根本上提升公司的数据驱动能力

同时，对于很多数据方向的初学者来说，网上的资料大部分都是辅导如何使用excel、sql、python做分析，建模的，大部分情况下用来处理的数据已经是csv或者excel格式了。这就会让很多人认为，数据分析的重点就是分析方法和写报告，而忽略了数据生产及存储这个非常重要的环节

在我学习时，发现网上关于大数据背景下的数仓建设相关的入门资料非常少，想要学习时只能去翻又厚又长的《数据仓库》、《数据仓库工具箱》，学习曲线非常陡峭，对于初学者很不友好。于是当时也被迫放弃了，但是后来在工作中又很巧的涉及到了这部分内容，没办法，只能一边工作一边硬着头皮从头学起

所以本篇就希望能够通过最浅显的总结和介绍，让大家对于大数据背景下的数仓建设和数据分层产生一点点研究的兴趣，同时帮助初级的数据人员把数仓建设这个环节补上，形成更完善的数据思维体系，以后工作中少走弯路

文章结构

1. 数据分层处理诞生的背景
2. 以Azure为例，浅析数据分层处理架构
3. 数据分层、大数据处理流程详解
4. ETL详解
5. 维度建模详解

---

一、数据分层处理流诞生背景

大数据时代数据的特点被总结为

• Volume (大量)
• Variety (多样)
• Velocity（高速）
• Value （价值）

传统的基于关系型数据库的数仓建设在面对海量数据、结构化半结构化无结构化等多样的数据格式、实时分析的需求时，逐渐变得无力应对。于是Hadoop、HIve、Spark、Storm、Flume、Sqoop等各种各样的数据处理框架应运而生，同时出现了数据分层的概念

在选择一个技术栈深耕前，我们需要先抬起头来，看看整个大数据流处理架构大概是怎么样的，不同的技术栈在其中分别扮演了什么样的角色，起到了什么样的作用，传统的数仓建设知识在新的大数据架构下是否还能够产生价值

二、Azure数据处理架构

数据处理流可以被抽象成5个步骤。从原始数据的获取开始，在获取到原始数据后进行ingestion，这里可以理解为基础的处理和提取，接下来将处理好的数据录入公司数据库进行存储。存储好的数据便可以用来做数据处理和数据可视化等分析挖掘操作了

看个复杂点的，微软数据平台Azure面向企业级的数据流，其实拆分看也就五个步骤，只不过每个步骤下因为不同的业务需要有了更细致的操作处理

三、数据分层、大数据处理流程详解

就着下面这个框架图，我们来一步一步的看看，大数据背景下的数据从生产到最后声称报告产生业务价值，到底有哪些步骤

STP1. 数据源

数据的一生从读取数据源开始，这里的数据源可能来源于埋点日志、流水日志、业务数据库、爬取到的数据等等

不同数据来源的数据结构和字段名称可能都是不一样的，有的可能是csv格式，有的可能是Json格式，还有的可能是储存成了html格式；同时这些数据还可能存在数据缺失、数据重复、单位不一致、口径不一致等等问题。所以在用这些数据进行分析前，需要对其进行必要的处理

STP2. 数据源 ——> ETL

ETL就是对原数据进行抽取、转换、加载

并不是所有数据源的数据都是我们需要的数据，全部存储会浪费资源，所以第一步就是从各个数据源中抽取出需要的数据。转换的过程则对应着数据清洗，处理缺失数据、处理重复数据、单位转换、口径对齐等操作。清洗完成后传入数据库进行存储

STP3. ETL ——> ODS, 明细层

经过ETL处理的数据通常会直接存入ODS数据库（Operational Data Store，操作数据存储），ODS数据库中的数据最接近原始数据，这里的数据属于公司的公共数据资源

因为ODS层存储的数据量非常大，而不同部门和业务线的实际分析需求可能只会用到其中1/100甚至1/1000的数据。如果不作处理直接使用，会浪费大量的计算资源。所以ODS层的数据需要进行维度建模，通过结构化的存储，以空间换时间，降低后期数据取用的复杂度

• 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段
• 库与表命名：库名 - ods, 表名 - ods_业务名

STP4. ODS ——> DWD, Data Warehouse Detail 或 DWB, Data Warehouse Basis

DWD层中的数据粒度和ODS层中的保持一致，而DWB层是对DWD层的生产数据进行轻度综合和汇总统计（可以把复杂的清洗，处理包含，如根据PV日志生成的会话数据），这一层主要解决一些数据质量问题和数据的完整度问题

轻度综合层与DWD的主要区别在于二者的应用领域不同

• DWD的数据来源于生产型系统，经过维度建模后根据不同的业务过程、事实、维度进行存储沉淀
• DWB轻度汇总层则面向分析型应用进行细粒度的统计和沉淀，目的是降低数据量级和维度，方便快速分析。DWB是对ODS层中的用户的行为做一个初步的汇总，抽象出来一些通用的维度：时间、id等，并根据这些维度做一些统计分析，比如用户在每次登陆中的浏览时长，浏览页面数量等。这里做一层轻度的汇总会让计算更加的高效

DWD和DWS中的数据通常都是基于Kimball的维度建模理论来构建的，并通过一致性维度和数据总线来保证各个子主题的维度一致性

• 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段
• 库与表命名：库名 - dwb, 表名 - dwb_任务名

STP5. DWD, DWB ——> DM, date market或DWS, data warehouse service

数据到这里被称作数据集市或宽表，由轻度汇总层和明细层数据计算生成

储存时一般按照业务划分，如流量、订单、用户等，生成字段比较多的大宽表，用于提供后续的业务查询，OLAP分析，数据分发等

在数据挖掘及算法建模任务时经常都会对数据有特定的格式需求或者特定的特征处理。通常在面对需要每天例行化计算的模型时，为了节省计算时间，在操作时会单独为模型建立一个DM数据集市

• 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段
• 库与表命名：库名 - dm, 表名 - dm_任务名

STP6. DM, DWS ——> APP (应用层)

本部分数据由明细层、轻度汇总层，数据集市层生成，一般要求数据主要来源于集市层

应用层的数据是根据业务需要，由前面三层数据统计而出的结果，可以直接提供查询展现，或导入至Mysql中使用

---

四、ETL详解

抽取extraction、转换transformation、加载load

（1）抽取(Extract)

从数据来源提取指定数据，数据是需要指定的，不是所有的数据都要抽取过来， 某些源数据对于分析而言没有价值，或者其可能产生的价值，远低于储存这些数据所需要的数据仓库的实现和性能上的成本，就不会抽取了

（2）转换(Transform)

将数据转换为指定格式并进行数据清洗保证数据质量

数据转换，如包括编码转换(m/f->男/女)，字段转换(balance->bal)，度量单位的转换(cm->m)，数据粒度的转换。业务系统数据存储非常明细的数据，而数据仓库中数据是用分析的，不需要非常明细，会将业务系统数据按照数据仓库粒度进行聚合

数据清洗，会对不完整数据，错误数据和重复数据等脏数据进行清洗

（3）加载(Load)

将转换过后的数据加载到目标数据仓库，加载可分为两种：

1. 全量加载：一次对全部数据进行加载。
2. 增量加载：一般首次需要全量加载，但是在第二次周期或者第三次周期的时候仍然全量加载的话，耗费了极大的物理和时间资源。有可能部分数据源并未发生变化，而有的数据源可能只是增加了少量的数据。 对数据源中的数据只考虑新修改的记录和新插入的记录就是增量加载。

ETL很可能是数据仓库开发中最耗时最耗资源的一个环节，因为该环节要整理各大业务系统中杂乱无章的数据，并协调元数据上的差别，工作量很大，但也是构建数据仓库的重要环节，对数据仓库的后续环节影响比较大

五、维度建模详解

维度建模的基本概念

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

1、维度

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

2、事实

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

维度建模用到的专业术语

1、 数据域

指面向业务分析，将业务过程活动维度进行抽象的集合。其中，业务过程可以概括为一个个不可分割的行为事件，在业务过程里可以定义指标；维度是指度量的环境，如买家下单事件，买件是维度。为保障整个体系的生命力，数据域是需要抽象提炼并且长期维护更新的，但不轻易变动。在划分数据域时，既要能涵盖所有业务需求，又能在新业务进入时无影响的包含已有的数据还要扩展新的数据域

2、 业务过程

值企业活动事件，如下单、支付、退款都是业务过程。业务过程是一个不可分割的行为事件

3、 时间周期

用来名明确数据统计的时间周期或者时间点，如自然月、最近30天，自然周等

4、 修饰类型

是对抽象词的一种抽象划分。修饰类型从属某个数据域，如日志域的访问终端涵盖无线端，PC端等修饰词

5、 修饰词

指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于某一个修饰类型

6、 度量/原子指标

基于某一业务事件行为下的度量，是业务定义中不可在分割的指标，具有明确的业务含义名词，如支付金额

7、维度

上述已经做了介绍，不必重述

8、 维度属性

维度属性隶属于某一个维度，如地理维度里面的国家名称，国建id，省份名称等

9、 事实

上述已经做了介绍，不必重述

10、派生指标

派生指标=一个原子指标+多个修饰词+时间周期。可以理解为对原子指标业务统计范围的圈定。如原子指标：支付金额，最近一天海外买家支付金额为派生指标（最近一天为时间周期，海外为修饰词，买家为维度）

11、钻取

钻取是改变维的层次，变换分析的粒度。它包括向上钻取（roll up）和向下钻取（drill down）

roll up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；是指自动生成汇总行的分析方法。通过向导的方式，用户可以定义分析因素的汇总行，例如对于各地区各年度的销售情况，可以生成地区与年度的合计行，也可以生成地区或者年度的合计行

而drill down则相反，它从汇总数据深入到细节数据进行观察或增加新维。例如，用户分析“各地区、城市的销售情况”时，可以对某一个城市的销售额细分为各个年度的销售额，对某一年度的销售额，可以继续细分为各个季度的销售额。通过钻取的功能，使用户对数据能更深入了解，更容易发现问题，做出正确的决策

维度建模的三种模式

1、 星形模式

星形模式(Star Schema)是最常用的维度建模方式，下图展示了使用星形模式进行维度建模的关系结构：

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

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

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

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

2、雪花模式

雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表，下图为使用雪花模式进行维度建模的关系结构：

星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重

3、星座模式

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

前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式

4、三种模式对比

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

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

维度表设计

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

维度表基本设计方法

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

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

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

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

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

确定维度属性的几点提示

a、 尽可能生成丰富的维度属性；

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

c、 区分数值型属性和事实；

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

如下图是规范化的商品维度表现形式：

该模式属于雪花模式

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

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

参考

• 《数据仓库》
• 《数据仓库工具箱》

---

点赞评论不走丢，带你看更多，数据干货