数据治理的核心：维度建模下的数仓构建
数据模型在不同领域中，具体所指有很大不同，本章主要想讨论，在数据仓库概念下的数据模型构建。
传统的范式建模主要针对的场景是数据的快速存储与记录，解决解决的问题是数据的创建和更新。而数仓建模的常用的维度建模，主要侧重于分析场景，也就是通过数据发现事物之间的关系，进而可以进行归因分析和业务洞察。也就是我们常说的范式建模用于 OLTP，维度建模侧重于 OLAP。
维度建模
维度建模定义
维度建模是一种逻辑设计技术，该技术试图采用某种直观的标准框架结构来表现数据，并且允许高性能存取。维度模型是用来设计向最终用户交付的数据库的一种快速交付技术。
一句话，就是说维度建模是一种构建数仓数据库的一门技术，构建出来的数据库主要面向分析场景。所以跟传统的范式建模是有不同。
那么数据仓库场景下，如何进行维度建模呢？
维度建模的方法
数据仓库领域的经典著作《维度建模工具箱》中，Kimball 定义了经典的维度建模的四步曲：选定业务过程、声明粒度、确定维度、构建事实。
业务过程：很多数据仓库书籍都给出了业务过程的通用定义，即业务过程是企业活动中的事件，如下单、支付、退款都是业务过程，业务过程是一个不可拆分的行为事件。由多个业务过程构成了企业商业模式的最精简链路。
粒度：粒度是在某一个分析场景下，最小的不可拆分的分析单元，比如在分析营收情况是，订单就是一个粒度。
维度：分析场景下分析事物的一种角度。比如分析营收场景时，可以选择订单维度，也可以选择日历维度等等。
事实：维度建模中，对事实进行了细分，事实包含 2 类属性：维度、度量。维度就是上文所说的各个角度的数据，而度量，则通常是数值型的。总的来说，事实就是描述客观事物所有核心信息的所有数据的集合。
维度建模设计方式（Kimball）
维度建模的核心是基于维度表和事实表两个概念，基于这个两个概念最基础的维度模型就是星型模型。
星型模型
图：星型模型
雪花模型
在星型模型的基础上有两个方向的扩展。
基于星型模型对维表进行规范化设计，也就是大的维度表可以拆成多个子维表，就形成了雪花模型。
图：雪花模型
星座模型
在星型模型的基础上，对事实表的扩展，就形成了星座模型。
图：星座模型
以上三种维度建模方式，星型模型使用最多，在业务发展的后期使用星座模型的较多，而雪花模型由于对维度执行的规范设计，使得分析查询的时候复杂度提高不少，所以这种方式使用的相对较少。
不管是那种维度模型设计，都会涉及到一个问题：缓慢变化维。这个也是实际生产中，业务发展不可避免的事情。一般的处理方法是在维表的设计中除 ID 之外引入 Key 键。如用户维表的设计。
数仓体系三种思路
独立数据集市
这种方式属于比较早期的一种方式，各部门基于自己部门的系统，执行一套完整的 ETL 工作流到数据应用集市。这种方式主要有这几种缺点。
技术上这是一种比较低效的方式，分散的信息，影响了企业全局范围内数据分析的效率。
各组织之间的 ETL 架构相互独立无法复用，也浪费了企业的开发资源。
但是，出于某些公司制度、预算、安全等方面的考虑，有些公司有时也会使用到这种建模体系。
规范化数仓
这种方式统一收口了 ETL 环节，且将数据收口到中心数仓（这里的数仓使用规范的设计），面向各部门构建基于维度建模的数据集市。
各部门的数据开发人员只能访问自己部门的数据集市，不能访问中心数仓。这种方式最大限度的复用了 ETL 环节，且有了一种数仓的分层设计，且业务部门不能直接访问中心仓，也最大限度的利于数据质量的管理。
但缺点也比较明显，即数据集市的设计需要等到基于规范设计的中心数仓完成之后才能进行。
维度建模数据仓库
这种模式将数据集市与数仓进行整合，统一采用维度建模的方式，比较方便的解决了规范化数仓的缺点。这种思路也是不目前行业数据仓库建设的推荐实践。
基于维度建模下数仓的分层划域
从传统的在线交易系统升级到基于主题的数据仓库系统，就涉及到从传统的第三范式设计到维度建模的构建过程，以及数据的抽取、转换、加载的过程，这个过程就是数据仓库的分层设计与主题划分。传统的关系型数据库系统主要遵从于范式建模（满足原子性，唯一性，非主键不冗余），而数据仓库主要是面向分析决策，所以遵从的模式转变为了维度建模。
数仓分层
数据仓库分层架构的目标是什么？是为了实现维度建模，进而支撑决策分析目标。
数据仓库根据不同的业务形态，数据量级等因为，一般划分为 3-5 层不等，但一般包含了 ODS（贴源层），DW（数据仓库层），DIM（维度层），ADM（数据集市）。
其中 ADM 层主要面向部门、特定的分享场景提供业务查询，OLAP 分析，数据分发等。实际的数据仓库分层构建中主要在 DW 会有所变动，将 DW 层又细分为 DWD（Data Warehouse Detail）层、DWM（Data Warehouse Middle）层和 DWS（Data Warehouse Service）层。
图：数仓常见分层示意
数据的分层设计带来了以下的优势：
1、数据结构化更清晰：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解。
2、数据血缘追踪：提供给外界使用的是一张业务表，但是这张业务表可能来源很多张表。如果有一张来源表出问题了，我们可以快速准确的定位到问题，并清楚每张表的作用范围。
3、增强数据复用能力：减少重复开发，通过数据分层规范化，开发一些通用的中间层数据，能够减少重复计算，提高单张业务表的使用率，提升系统的执行效率。
4、简化复杂的问题：把一个复杂的业务分成多个步骤实现，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
5、减少业务的影响：业务可能会经常变化，这样做就不必改一次业务就需要重新接入数据。
6、统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径。
数仓分域
数仓的建设目的主要面向分析型场景，所以域的划分一般先从分析主题的选择开始，然后再在各分析主题下拆解包含的数据域，进一步的拆解数据域所包含的业务过程。不同过业务场景下的具体做法各有不同，可以结合分析主题->数据域->业务过程遮掩的步骤，对数仓进行业务划分。
划分分析主题：主题(Subject) 是在较高层次上将企业信息系统中某一分析对象（重点是分析的对象）的数据进行整合、归类并分析的一种范围，属于一个抽象概念，简单点说每一个主题对应一个宏观分析领域。如用户分析主题，销售分析主题等。
划分数据域：数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。如下关于交易的数据域，关于流量的数据域等，这些都是对业务过程的某一方面抽下个。数据域在进一步抽象就到分析主题层面了。
抽象业务过程：基于维度建模的一般方法论，先梳理业务链路，拆解成不同的业务过程，比如电商场景下的注册，下单，发货等。
简单来讲，就是基础是业务过程，经过一层抽象形成数据域，在数据域的基础之上经一层抽象到分析层。这个过程是自下往上，刚好跟自上而下的分析过程相反。
结合作者经验，比较推荐先按照业务系统划分或者 BU 来划分主题域或者说一级主题，这样的话边界较为清晰，数据仓库开发过程也不会因为模型主题的归属引发扯皮和不同意见。然后根据各个系统中的业务过程抽象整合出主题或者叫二级主题域。
参考：
题图来自 Unsplash，基于 CC0 协议
版权声明: 本文为 InfoQ 作者【Taylor】的原创文章。
原文链接:【http://xie.infoq.cn/article/20585233712d70beacea72d29】。文章转载请联系作者。
基于时空AI的“全息时空”平台架构师 2018.10.20 加入
专注于数据治理、平台建设、数据价值应用（数据科学与AI）领域，可以提供数字化转型，智慧城市领域的咨询与交流。 前4亿全球用户产品APP架构师。
评论