数仓系列之必知基础

概述

数据仓库，简称数仓，是一个面向主题的、集成的、相对稳定的、反应历史变化的数据集合，用于支持管理决策。

面向主题：传统的数据库是面向事务处理的，而数仓是面向某一领域而组织的数据集合，主题是指用户关心的某一联系紧密的集合
集成：数仓中数据来源于各个离散的业务系统数据库、外部数据、非结构化数据的集合
相对稳定：数仓中的数据不应该支持DML操作，而是通过批处理方式进行数据的处理
反应历史：数仓保存数据的历史各个版本

OLAP

联机分析处理，Online Analytical Processing，有时也叫DSS决策支持系统。与此相对的是OLTP（on-line transaction processing）联机事务处理系统。

OLAP概念最早是由关系数据库之父E.F.Codd于1993年提出，OLAP作为一类产品同OLTP明显区分开，Codd认为OLTP已不能满足终端用户对数据库查询分析的要求，SQL对大数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，Codd提出多维数据库和多维分析的概念，即OLAP。

OLAP委员会对OLAP的定义：

从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业多维特性的数据称为信息数据，使分析人员、管理人员或执行人员能够从多种角度对信息数据进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或多维环境特定的查询和报表需求，它的技术核心是"维"这个概念，因此OLAP也可以说是多维数据分析工具的集合。

E.F.Codd提出关于OLAP的12条准则：

OLAP模型必须提供多维概念视图
透明性准则
存取能力准则
稳定的报表能力
客户/服务器体系结构
维的等同性准则
动态的稀疏矩阵处理准则
多用户支持能力准则
非受限的跨维操作
直观的数据操纵
灵活的报表生成
不受限的维与聚集层次

缓慢变化维

slowly changing dimensions，SCD，缓慢变化维的提出是因为现实世界中，维度的属性并不是静态的，它会随时间的流失发生缓慢的变化。常见的SCD处理方式：

直接覆盖：不记录历史数据，薪数据覆盖旧数据
新加一行数据（纵向扩展）：使用代理主键+生效失效时间或者是代理主键+生效失效标识（保存多条记录，直接新添一条记录，同时保留原有记录，并用单独的专用字段保存）
新加两个字段（横向扩展）：一个是previous，一个是current，每次更新只更新这两个值，但是这样职能保留最近两次的变化（添加历史列，用不同的字段保存变化痕迹，因为只保存两次变化记录，使用与变化不超过两次的维度）

主题

主题是在较高层次上将数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域，在逻辑意义上，他是对企业中某一宏观分析领域所涉及的分析对象。
面向主题的数据组织方式，就是在较高层次上对分析对象的数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。
主题域通常是联系较为机密的数据主题的集合，可以根据业务的关注度，将这些数据主题划分到不同的主题域（也就是说对某个主题进行分析后确定的主题的边界）。
关于主题域的划分，可以考虑几方面：

按照业务或者业务过程划分：比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题；
根据需求方划分：比如需求方为财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题；
按照功能或者应用划分：：比如微信中的朋友圈数据域、群聊数据域等，而朋友圈数据域可能就会有用户动态信息主题、广告主题等；
按照部门划分：比如可能会有运营域、技术域等，运营域中可能会有工资支出分析、活动宣传效果分析等主题；

总而言之，切入的出发点逻辑不一样，就可以存在不同的划分逻辑。在建设过程中可采用迭代方式，不纠结于一次完成所有主题的抽象，可先从明确定义的主题开始，后续逐步归纳总结成自身行业的标准模型。

数仓架构

数仓三层架构

数据访问层：主要是对非原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据库的操作，而不是数据，具体为业务逻辑层或表示层提供数据服务。
业务逻辑层：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。
界面层：主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以表现成：aspx，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。

为什么要分层？

分层可以清晰数据结构，使用时更好的定位和理解
方便追踪数据的血缘关系
规范数据分层，可以开发一些通用的中间层数据，能够极大地减少重复计算
复杂问题简单化
屏蔽原始数据的异常，下游任务没有感知异常

主要包括贴源层（原始数据层，ODS，Operation Data Store）、明细数据层（DWD，Data Warehouse Detail）、汇总层（DWS，Data Warehouse Service，数据服务层）、集市层（dm，）、报表层（数据应用层，ADS，Application Data Store）、维度层（）：

贴源层：采集的各个业务系统数据首先存储在贴源层中，这里需要注意的是采集业务源数据的方法，增量采集还是全量采集，好的业务系统设计应该支持增量采集（这里留一个问题作为思考：增量采集数据应该满足哪些要求），这样的好处减少了采集数据对仓库资源和业务系统资源的消耗
明细层：该层采用规范化方式存储数据，处理数据主要来自于贴源层，实现的目的主要包括面向主题设计存储结构、集成不同业务源数据、统一编码规范、保留历史数据（拉链表主要在这一层中进行设计实现）等仓库基本要处理的
汇总层：对于明细层整合的数据，针对需要汇总的指标按照业务口径进行计算并且初步反规范化设计实现连接明细层的规范化数据成小宽表，目的方便下一步处理使用
集市层：面向不同需求方，按照维度建模方法，进行星型模型设计，这一层设计完成后的目的要达到可以方便出具报表和日常提数任务。这里有些仓库设计人员还会用另一个思路，即集市层不采用星型模型设计方法，而是设计大宽表，采用这种方式的设计人员主要理由是这种方式方便人们使用
报表层：根据各个部门不同需求出具报表
维度层：统一存储数仓维表相关数据

离线数仓与实时数仓

Lambda架构

Kappa架构

数仓核心

数据集成和数据质量

企业的数据通常存储在多个异构数据库中，要进行分析，必须对数据进行一致性整合，整合后才能对数据进行分析挖掘出潜在的价值；
数据质量必须有保障

设计

目前数仓设计主要有两个阵营：

Bill Inmon推崇自上而下的方式，一个企业建立唯一的数据中心，数据是经过整合、清洗、去掉脏数据、标准的、能够提供统一的视图。要从整个企业的环境入手，建立数据仓库，要做很全面的设计。偏数据驱动
Ralph Kimball推崇自下而上的方式，认为数仓应该按照实际的应用需求，架子啊需要的数据，不需要的数据不要加载到数仓中。建设周期短，用户能很快看到结果。偏业务驱动

一般建议结合两种架构的优点进行数仓设计（即三范式简历数仓明细层，集市层采用星型模型设计方法），合理结合两种思路优点可以有效的避免业务驱动方式带来的烦杂工作以及需求驱动所带来的后期维护及扩展性问题。

模型

概念模型、逻辑模型、物理模型

概念模型CDM：概念模型是最终用户对数据存储的看法，反映最终用户综合性的信息需求，以数据类的方式描述企业级的数据需求
概念模型的内容包括重要的实体与实体之间的关系，在概念模型中不包含实体的属性，也不包含定义实体的主键
概念模型的目的是统一业务概念，作为业务人员和技术人员之间的沟通桥梁，确定不同实体之间的最高层次的关系
逻辑模型LDM：逻辑模型反映的是系统分析人员对数据存储的观点，是对概念模型的进一步分解和细化，逻辑模型是根据业务规则确定的，关于业务对象，业务对象的数据项以及业务对象之间关系的基本蓝图
逻辑模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理
逻辑模型的目标是尽可能详细的描述数据，并不考虑物理上如何实现
物理模型PDM：物理模型是在逻辑模型的基础上，考虑各种具体的技术实现因素，进行数据体系结构设计，真正实现数据在数据仓库中的存放物理模型的内容包括确定所有的表和列，定义外键用确认表之间的关系，基于用户的需求可能要进行反范式化等内容

建模重要性

数仓建模需要按照一定的数据模型，对整个企业的数据进行采集，整理，提供跨部门、完全一致的报表数据。
合适的数据模型，对于大数据处理来讲，可以获得得更好的性能、成本、效率和质量。良好的模型可以帮助我们快速查询数据，减少不必要的数据冗余，提高用户的使用效率。
数据建模进行全方面的业务梳理，改进业务流程，消灭信息孤岛，更好的推进数仓系统的建设。

建模方法

维度模型
维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。
Kimball维度建模四个步骤：
选择业务处理过程 > 定义粒度 > 选择维度 > 确定事实

星型模型
星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。
雪花模型
雪花模型，在星型模型的基础上，维度表上又关联其他维度表。维护成本高，性能方面也较差，一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。
星型模型可以理解为，一个事实表关联多个维度表，雪花模型可以理解为一个事实表关联多个维度表，维度表再关联维度表。
星座模型
星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。星座模型是很多数仓的常态，因为很多数仓都是多个事实表的。所以星座模型只反映是否有多个事实表，他们之间是否共享一些维度表。

范式模型
即实体关系（ER）模型，数仓之父Immon提出的，从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF。此建模方法，对建模人员的能力要求非常高。
特点：设计思路自上而下，适合上游基础数据存储，同一份数据只存储一份，没有数据冗余，方便解耦，易维护，缺点是开发周期一般比较长，维护成本高。
Data Vault模型
DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性）三部分组成，是Dan Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。
Anchor模型
高度可扩展的模型，所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成K-V结构模型。企业很少使用。

建模步骤

大致分为四个阶段：

业务建模，主要包含以下几个部分：

划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系
深入了解各个业务部门的内具体业务流程并将其程序化
提出修改和改进业务部门工作流程的方法并程序化
数据建模的范围界定，整个数据仓库项目的目标和阶段划分

领域概念建模，主要包含以下几个部分：

抽取关键业务概念，并将之抽象化
将业务概念分组，按照业务主线聚合类似的分组概念
细化分组概念，理清分组概念内的业务流程并抽象化
理清分组概念之间的关联，形成完整的领域概念模型
概念模型具体要求如下：

逻辑建模，主要包含以下几个部分：

业务概念实体化，并考虑其具体的属性
事件实体化，即事实，并考虑其属性内容
说明实体化，即维度，并考虑其属性内容
逻辑模型具体要求如下：

物理建模，主要包含以下几个部分：

针对特定物理化平台，做出相应的技术调整
针对模型的性能考虑，对特定平台作出相应的调整
针对管理的需要，结合特定的平台，做出相应的调整
生成最后的执行脚本，并完善之
物理模型具体要求如下：

对比

数仓和数据库

从目标、用途、设计来说

数据库是面向事务处理的，数据是由日常的业务产生的，并且是频繁更新的；数仓是面向主题的，数据来源多样化，经过一定的规则转换得到的，用于分析和决策
数据库一般用来存储当前事务性数据，如交易数据；数仓一般存储的是历史数据
数据库设计一般符合三范式，有最大的精确度和最小的冗余度，有利于数据的插入；数仓设计一般不符合三范式，有利于查询

OLTP和OLAP

OLTP系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作，强调事务性；

OLAP系统则强调数据分析，强调SQL执行时长，强调磁盘I/O，强调分区。

数据中台、数仓、大数据平台、数据湖

基础能力上的区别
数据平台：提供的是计算和存储能力
数据仓库：利用数据平台提供的计算和存储能力，在一套方法论的指导下建设的一整套的数据表
数据中台：包含了数据平台和数据仓库的所有内容，将其打包，并且以更加整合以及更加产品化的方式对外提供服务和价值
数据湖：一个存储企业各种各样原始数据的大型仓库，包括结构化和非结构化数据，其中湖里的数据可供存取、处理、分析和传输
业务能力上的区别
数据平台：为业务提供数据主要方式是提供数据集
数据仓库：相对具体的功能概念是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表
数据中台：企业级的逻辑概念，体现企业数据产生价值的能力，为业务提供服务的主要方式是数据API
数据湖：数据仓库的数据来源

总的来说，数据中台距离业务更近，数据复用能力更强，能为业务提供速度更快的服务，数据中台在数据仓库和数据平台的基础上，将数据生产为一个个数据API服务，以更高效的方式提供给业务。数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

数仓的8个问题

调用原则

禁止逆向调用
避免同层调用
优先使用公共层
避免跨层调用

外围建设

调度系统
元数据管理系统
离线实时计算
数据质量监控

元数据管理

参考数仓系列之元数据及其管理

数据质量管理

参考数仓之数据质量及Apache Griffin简介

表类型

据不完全统计，数仓中的表涉及：全量表，增量表，拉链表，流水表，快照表。
需要先有所了解的概念：流量，存量，增量：

存量：系统在某一时点时的所保有的数量；
流量：是指在某一段时间内流入/出系统的数量
增量：则是指在某一段时间内系统中保有数量的变化
增量=流入量-流出量
本期期末存量=上期期末存量+本期内增量

全量表

每天的所有的最新状态的数据：

全量表，有无变化，都要报
每次上报的数据都是所有的数据（变化的 + 没有变化的）

增量表

新增数据，增量数据是上次导出之后的新数据：

记录每次增加的量，而不是总量；
流量是指在一定时间内的增量；
流量一般设计成增量表（日报-常用、月报）；
流量和存量区别：流量是增量；存量是总量；
增量表，只报变化量，无变化不用报

拉链表

需求来源：解决保存大量的历史数据的问题

在数仓的数据模型设计过程中，经常会遇到这样的需求：

表中的数据字段会被update，如：用户的地址，产品的描述信息，订单的状态等
需要查找某一个时间点或者时间段得历史快照信息，列如：
查看某一个订单再某一个时间点的状态
查看某一个用户在过去某一段时间内，更新过几次等
变化的比例和频率不是很大，如：
总共有1000万的会员，每天新增和发生变化的有10万左右
如果对这边每天都保留一份全量，则每次全量中会保存很多不便的信息，存储压力大

解决方案

快照每一天的数据到数仓中，存在的问题：全量备份，记录重复，存储压力
设计成拉链表来保存历史纪录

特点：

记录一个事物从开始，一直到当前状态的所有变化的信息；
拉链表每次上报的都是历史记录的最终状态，是记录在当前时刻的历史总量；
当前记录存的是当前时间之前的所有历史记录的最后变化量（总量）；
存量是在某一时刻的总量；
存量一般设计成拉链表（月报-常用、日报）；
流量和存量的区别：流量是增量；存量是总量；
封链时间可以是2999，3000，9999等等比较大的年份；拉链表到期数据要报0；
拉链表和增量表的共同点：表结构基本一样。

在有些情况下，为了保持历史的一些状态，需要用拉链表来做，这样做目的在可以保留所有状态的情况下可以节省空间。

拉链表适用于情况：数据量有点大，表中某些字段有变化，但变化频率不是很高，业务需要统计这种变化状态，每天全量一份呢，有点不太现实，不仅浪费存储空间，有时可能业务统计也有点麻烦，拉链表既节省空间，又满足需求。

使用拉链历史表，既能满足反映数据的历史状态，又可最大程度的节省存储；拉链历史表在原有订单表的基础上，添加额外的两列：

开始时间 dw_begin_date
结束时间 dw_end_date

因为每天记录的状态都有可能被更新，一旦该记录被更新，这个记录就会成为过去。

流水表

对于表的每一个修改都会记录，可以用于反映实际记录的变更。区别于拉链表：

拉链表通常是对账户信息的历史变动进行处理保留的结果，流水表是每天的交易形成的历史；
流水表用于统计业务相关情况，拉链表用于统计账户及客户的情况

快照表

其实有的公司是这样定义的：

数仓系列之必知基础_数据挖掘

按照每天存放的数据以及是否按天分区可以分为增量表，全量表和快照表

类型	全量表	增量表	快照表
数据	包含到前一天的全量数据	前一天的增量数据	包含到前一天的全量数据
分区	不分区	按照每一天分区	按照每一天分区

另外，还有如下几种表：
实体表：一般是指现实存在的业务对象
维度表：码表，一般是指对应一些业务状态
事务型事实表：一般指随着业务发生不断产生数据，特点是一旦发生不会再变化
周期型事实表：一般指随着业务发生不断产生变化（更新，新增）的数据，如订单

同步策略

全量表：存储完整的数据
增量表：存储新增加的数据
新增及变化表：存储新增加的数据和变化的数据
拉链表：对新增及变化表做定期合并

实体表（用户，商品，商家）：每日全量
维度表（订单状态，审批状态，商品分类）：每日全量
事务型实时表（交易流水，操作日志，出库入库记录）：数据量大且不变，每日增量表，每日创建一个分区存储
周期型事实表（订单，请假等）：用每日新增和变化表，制作一张拉链表

参考

数据仓库基础
离线数仓—拉链表
数仓中的全量表，增量表，拉链表，流水表，快照表
数据仓库保存历史数据方法之拉链表
利用Hive实现数据仓库中的拉链表
你需要的不是实时数仓，而是一款强大的OLAP数据库

关于拉链表设计的案例：

标签：数仓,系列,拉链,必知,模型,业务,维度,数据
From： https://blog.51cto.com/u_15851118/5835011

概述