大数据篇：一文读懂@数据仓库(PPT文字版)

大数据篇：一文读懂@数据仓库

1 网络词汇总结

1.1 数据中台

1. 数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。

2. 数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。

3. 数据中台连接数据前台和后台，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。

4. 数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。

5. 数据中台，包括平台、工具、数据、组织、流程、规范等一切与企业数据资产如何用起来所相关的。

可以看出，数据中台是解决如何用好数据的问题，目前还缺乏一个标准，而说到数据中台一定会提及大数据，而大数据又是由数据仓库发展起来的。

1.1.1 数据仓库（Data WareHouse）

1. 数据仓库，按照传统的定义，数据仓库是一个面向主题的、集成的、非易失的、反映历史变化（随时间变化），用来支持管理人员决策的数据集合。

为企业所有决策制定过程，提供所有系统数据支持的战略集合

• 面向主题

操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织。

主题是一个抽象的概念，是数据归类的标准，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。每一个主题基本对应一个宏观的分析领域。

例如，银行的数据仓库的主题：客户

客户数据来源：从银行储蓄数据库、信用卡数据库、贷款数据库等几个数据库中抽取的数据整理而成。这些客户信息有可能是一致的，也可能是不一致的，这些信息需要统一整合才能完整体现客户。

• 集成

面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

具体如下：

1：数据进入数据仓库后、使用之前，必须经过加工与集成。

2：对不同的数据来源进行统一数据结构和编码。统一原始数 据中的所有矛盾之处，如字段的同名异义，异名同义，单位不统一，字长不一致等。

3：将原始数据结构做一个从面向应用到面向主题的大转变。

• 非易失即相对稳定的

操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

数据仓库中包括了大量的历史数据。

数据经集成进入数据仓库后是极少或根本不更新的。

• 随时间变化即反映历史变化

操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程

数据仓库内的数据时限一般在５-１０年以上，甚至永不删除，这些数据的键码都包含时间项，标明数据的历史时期，方便做时间趋势分析。

2. 数据仓库，并不是数据最终目的地，而是为数据最终的目的地做好准备：清洗、转义、分类、重组、合并、拆分、统计等等

通过对数据仓库中数据的分析，可以帮助企业，改进业务流程、控制、成本、提高产品质量等

3. 主要解决问题：数据报表，数据沉淀，数据计算Join过多，数据查询过慢等问题。

防止烟囱式开发，减少重复开发，开发通用中间层数据，减少重复计算；

将复杂问题简单化，将复杂任务的多个步骤分解到各个层次中，每一层只处理较少的步骤，使单个任务更容易理解；

可进行数据血缘追踪，便于快速定位问题；

整个数据层次清晰，每个层次的数据都有职责定位，便于使用和理解。

4. 主要价值体现：企业数据模型，这些模型随着前端业务系统的发展变化，不断变革，不断追加，不断丰富和完善，即使系统不再了，也可以在短期内快速重建起来，这也是大数据产品能够快速迭代起来的一个重要原因

• 数仓硬件架构图

• 数仓功能架构图

• 数仓流程架构图1

• 数仓流程架构图2

• 实时数仓流程架构图

总结：数据仓库，即为企业数据的模型沉淀，为了能更快的发展大数据应用，提供可靠的模型来快速迭代。本文也主要为了讲解数据仓库

• 拓展：血缘图

• 拓展:BI层

• 拓展：BI图

1.1.2 大数据平台（DATA Platform）

1. 大数据平台则是指以处理海量数据存储、计算及流数据实时计算等场景为主的一套基础设施，包括了统一的数据采集中心、数据计算和存储中心、数据治理中心、运维管控中心、开放共享中心和应用中心。

2. 大数据平台的建设出发点是节约投资降低成本，但实际上无论从硬件投资还是从软件开发上都远远超过数据仓库的建设，大量的硬件和各种开源技术的组合，增加了研发的难度、调测部署的周期、运维的复杂度，人力上的投入已是最初的几倍；还有很多技术上的困难也非一朝一夕能够突破。

3. 首先是数据的应用问题，无论是数据仓库还是大数据平台，里面包含了接口层数据、存储层数据、轻度汇总层、重度汇总层、模型层数据、报表层数据等等，各种各样的表有成千上万，这些表有的是中间处理过程，有些是一次性的报表，不同表之间的数据一致性和口径也会不同，而且不同的表不同的字段对数据安全要求级别也不同。

4. 此外还要考虑多租户的资源安全管理，如何让内部开发者快速获取所需的数据资产目录，如何阅读相关数据的来龙去脉，如何快速的实现开发，这些在大数据平台建设初期没有考虑周全。

5. 另外一个问题是对外应用，随着大数据平台的应用建设，每一个对外应用都采用单一的数据库加单一应用建设模式，独立考虑网络安全、数据安全、共享安全，逐渐又走向了烟囱似的开发道路。

• 平台数据流向图

• 平台流程架构图

总结：大数据平台，即为数据一站式服务，提供可视化的数据展示，提取，计算任务安排，资源管理，数据治理，安全措施，共享应用等等。

1.1.3 数据中台（Data Middle Platform）

1. 数据中台要解决什么？数据如何安全的、快速的、最小权限的、且能够溯源的被探测和快速应用的问题。
2. 数据中台不应该被过度的承载平台的计算、存储、加工任务，而是应该放在解决企业逻辑模型的搭建和存储、数据标准的建立、数据目录的梳理、数据安全的界定、数据资产的开放，知识图谱的构建。
3. 通过一系列工具、组织、流程、规范，实现数据前台和后台的连接，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。

• 中台架构图

• 阿里数据中台架构图

总结：厚平台，大中台，小前台；没有基础厚实笨重的大数据平台，是不可能构建数据能力强大、功能强大的数据中台的；没有大数据中台，要迅速搭建小快灵的小前台也只是理想化的。

2 数据仓库的演进

• 实时数仓架构图

• 离线数仓架构图

3 数据仓库主要用途

大家应该已经意识到这个问题：既然分析型数据库中的操作都是查询，因此也就不需要严格满足完整性/参照性约束以及范式设计要求，而这些却正是分析型数据库精华所在。这样的情况下再将它归为数据库会很容易引起大家混淆，毕竟在绝大多数人心里数据库是可以关系型数据库画上等号的。

• 数据提取图：规整数据源

• 报表系统图：用于分析企业指标

• 数据分析图：用于分析周期数据

• 数据挖掘图：让数据更有价值

• 画像系统指标图:

• 数据大屏图

4 数据集市&数据分层

4.1 数据集市

4.2 数据分层

6.5.1 ODS层

• 保持数据原貌不做任何修改，起到备份数据的作用。
• 数据采用压缩，减少磁盘存储空间（例如：原始数据 100G，可以压缩到 10G 左 右）
• 创建分区表，防止后续的全表扫描

6.5.2 DWD层

• DWD 层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

事实/维度	时间	用户	地区	商品	优惠卷	活动	编码	度量
订单	√	√	√			√		件数/金额
订单详情	√		√	√				件数/金额
支付	√		√					次数/金额
加入购物车	√	√		√				件数/金额
收藏	√	√		√				个数
评价	√	√		√				个数
退款	√	√		√				件数/金额
优惠卷领用	√	√			√			个数

6.5.3 DWS层

• 统计各个主题对象的当天行为，服务于 DWT 层的主题宽表，以及一些业务明细数据， 应对特殊需求（例如，购买行为，统计商品复购率）。

6.5.4 DWT层

• 以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建主题对象的全量宽表。（按照维度来决定分析者的角度，如用户->什么时间->下了什么单，支付了什么，加入购物车了什么）

6.5.5 ADS层

对系统各大主题指标分别进行分析。

5 数据库的"分家"

5.1 OLAP 和 OLTP简介

数据处理大致可以分成两大类：

联机事务处理OLTP（on-line transaction processing）：是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作。

联机分析处理OLAP（On-Line Analytical Processing）：是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

5.2 定义差别

对比内容	操作型数据库(OLTP)	分析型数据库(OLAP)
数据内容	当前值	历史的、存档的、归纳的、计算的数据
数据目标	面向业务操作程序，重复处理	面向主题域，分析应用，支持决策
数据特性	动态变化，按字段更新	静态、不能直接更新，只能定时添加、刷新
数据结构	高度结构化、复杂，适合操作计算	简单，适合分析
使用频率	高	中到低
数据访问量	每个事务只访问少量记录	有的事务可能需要访问大量记录
对响应时间的要求	以秒为单位计算	以秒、分钟、甚至小时为计算单位

5.3 定位差别

对比属性	OLTP	OLAP
代表	Mysql	Hive
读特性	每次查询只返回少量数据	对大量数据进行汇总
写特性	随机、低延迟写入用户的操作	批量导入
用户	操作人员	决策人员
DB设计	面向应用	面向主题
数据	当前的，最新的细节，二维表	历史的，聚集的，多维表
工作单位	事务性保证	复杂查询
用户数	上千个	上百万个
DB大小	100MB-GB	100GB-TB以上
时间要求	具有实时性	对时间的要求不严格
主要应用	数据库：WEB项目	数据仓库：分析师，挖掘师

5.4 组成差别

对比内容	操作型数据库(OLTP)	分析型数据库(OLAP)
数据时间范围差别	只会存放一定天数的数据	存放的则是数年内的数据
数据细节层次差别	存放的主要是细节数据 也有汇总需求，但汇总数据本身不存储而只存储其生成公式。 这是因为操作型数据是动态变化的，因此汇总数据会在每次查询时动态生成。	存放的既有细节数据，又有汇总数据，对于用户来说，重点关注的是汇总数据部分。 因为汇总数据比较稳定不会发生改变，而且其计算量也比较大(因为时间跨度大)，因此它的汇总数据可考虑事先计算好，以避免重复计算。
数据时间表示差别	通常反映的是现实世界的当前状态	既有当前状态，还有过去各时刻的快照。 可以综合所有快照对各个历史阶段进行统计分析

5.5 技术差别

对比内容	操作型数据库(OLTP)	分析型数据库(OLAP)
数据更新差别	允许用户进行增，删，改，查	规范是只能进行查询
数据冗余差别	减少数据冗余，避免更新异常	没有更新操作。因此，减少数据冗余也就没那么重要了

5.6 功能差别

对比内容	操作型数据库(OLTP)	分析型数据库(OLAP)
数据读者差别	使用者是业务环境内的各个角色，如用户，商家，进货商等	只被少量用户(高级管理者)用来做综合性决策
数据定位差别	是为了支撑具体业务创建的，因此也被称为"面向应用型数据库"	是针对各特定业务主题域的分析任务创建的，因此也被称为"面向主题型数据库"

5.7 OLTP数据库三范式介绍

5.8 OLAP典型架构

OLAP有多种实现方法，根据存储数据的方式不同可以分为ROLAP、MOLAP、HOLAP

名称	描述	细节数据存储位置	聚合后的数据存储位置
ROLAP(Relational OLAP)	基于关系数据库的OLAP实现	关系型数据库	关系型数据库
MOLAP(Multidimensional OLAP)	基于多维数据组织的OLAP实现	数据立方体	数据立方体
HOLAP(Hybrid OLAP)	基于混合数据组织的OLAP实现	关系型数据库	数据立方体

5.9 OLAP数据立方体(Data Cube)

6 数据建模

6.1 关系建模(适用于OLTP)

6.2 维度建模(适用于OLAP)

6.3 常用词解释

6.3.1 维度表

1. 一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等。
2. 常用于一个客观世界的维度描述。（具有多个属性、列比较多）
3. 审视数据的角度。(如用户，商品)
4. 行数相对较小：通常< 10 万条。(对比事实表)
5. 静态表示的，名词性质的表。(如地理，时间，状态)
6. 变化较慢。（新增修改操作较少）

• 维表的特征：
  • 维表的范围很宽（具有多个属性、列比较多）
  • 跟事实表相比，行数相对较小：通常< 10 万条
  • 静态表示的，名词性质的表

6.3.2 事实表

1. 事实表用于正确的记录既定的已经发生的事实，常用于存储ID和度量值，各种维度外键

2. 事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这 个术语表示的是业务事件的度量值（可统计次数、个数、件数、金额等），例如，订单事件中的下单金额。

3. 每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具 有两个和两个以上的外键、外键之间表示维表之间多对多的关系。

4. 行数相对较多。(对比维度表)

5. 列数较少。（不是绝对）

6. 变化较快。（新增修改操作较多）

7. 动态表示的，动词性质的表。（如下单，优惠卷领用）

8. 事实表导入策略一般有三种划分：事务型事实表，周期型快照事实表，累积型快照事实表

划分/比较点	事务情况	导入策略
事务型事实表	以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为 事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进 行更改，其更新方式为增量更新	每天导入新增
周期型快照事实表	周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如 每天或者每月的销售额，或每月的账户余额等	每日全量
累积型快照事实表	累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积 或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务 阶段的时间点数据来跟踪 订单声明周期的进展情况。当这个业务过程进行时 ，事实表的记录也要不断更新	每天导入新增及变化

6.4 建模的三种模式

6.5 维度建模四个步骤