大数据篇：一文读懂@数据仓库(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 维度建模四个步骤