大数据篇：一文读懂@数据仓库
大数据篇：一文读懂@数据仓库
1 网络词汇总结
人工智能层的：智慧地球、智慧城市、智慧社会
企业层面的：数字互联网，数字经济、数字平台、数字城市、数字政府；
平台层面的：物联网，云计算，大数据，5G，人工智能，机器智能，深度学习，知识图谱
技术层面的：数据仓库、数据集市、大数据平台、数据湖、数据中台、业务中台、技术中台等等
挑重点简介
1.1 数据中台
数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。
数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。
数据中台连接数据前台和后台，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。
数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。
数据中台，包括平台、工具、数据、组织、流程、规范等一切与企业数据资产如何用起来所相关的。
可以看出，数据中台是解决如何用好数据的问题，目前还缺乏一个标准，而说到数据中台一定会提及大数据，而大数据又是由数据仓库发展起来的。
1.1.1 数据仓库（Data WareHouse）
数据仓库，按照传统的定义，数据仓库是一个面向主题的、集成的、非易失的、反映历史变化（随时间变化），用来支持管理人员决策的数据集合。
为企业所有决策制定过程，提供所有系统数据支持的战略集合
面向主题
操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织。
主题是一个抽象的概念，是数据归类的标准，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。每一个主题基本对应一个宏观的分析领域。
例如，银行的数据仓库的主题：客户
客户数据来源：从银行储蓄数据库、信用卡数据库、贷款数据库等几个数据库中抽取的数据整理而成。这些客户信息有可能是一致的，也可能是不一致的，这些信息需要统一整合才能完整体现客户。
集成
面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
具体如下：
1：数据进入数据仓库后、使用之前，必须经过加工与集成。
2：对不同的数据来源进行统一数据结构和编码。统一原始数 据中的所有矛盾之处，如字段的同名异义，异名同义，单位不统一，字长不一致等。
3：将原始数据结构做一个从面向应用到面向主题的大转变。
非易失即相对稳定的
操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
数据仓库中包括了大量的历史数据。
数据经集成进入数据仓库后是极少或根本不更新的。
随时间变化即反映历史变化
操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程
数据仓库内的数据时限一般在５-１０年以上，甚至永不删除，这些数据的键码都包含时间项，标明数据的历史时期，方便做时间趋势分析。
数据仓库，并不是数据最终目的地，而是为数据最终的目的地做好准备：清洗、转义、分类、重组、合并、拆分、统计等等
通过对数据仓库中数据的分析，可以帮助企业，改进业务流程、控制、成本、提高产品质量等
主要解决问题：数据报表，数据沉淀，数据计算Join过多，数据查询过慢等问题。
防止烟囱式开发，减少重复开发，开发通用中间层数据，减少重复计算；
将复杂问题简单化，将复杂任务的多个步骤分解到各个层次中，每一层只处理较少的步骤，使单个任务更容易理解；
可进行数据血缘追踪，便于快速定位问题；
整个数据层次清晰，每个层次的数据都有职责定位，便于使用和理解。
主要价值体现：企业数据模型，这些模型随着前端业务系统的发展变化，不断变革，不断追加，不断丰富和完善，即使系统不再了，也可以在短期内快速重建起来，这也是大数据产品能够快速迭代起来的一个重要原因
总结：数据仓库，即为企业数据的模型沉淀，为了能更快的发展大数据应用，提供可靠的模型来快速迭代。本文也主要为了讲解数据仓库
数仓硬件架构图
数仓功能架构图
数仓流程架构图1
数仓流程架构图2
实时数仓流程架构图
1.1.2 大数据平台（DATA Platform）
大数据平台则是指以处理海量数据存储、计算及流数据实时计算等场景为主的一套基础设施，包括了统一的数据采集中心、数据计算和存储中心、数据治理中心、运维管控中心、开放共享中心和应用中心。
大数据平台的建设出发点是节约投资降低成本，但实际上无论从硬件投资还是从软件开发上都远远超过数据仓库的建设，大量的硬件和各种开源技术的组合，增加了研发的难度、调测部署的周期、运维的复杂度，人力上的投入已是最初的几倍；还有很多技术上的困难也非一朝一夕能够突破。
首先是数据的应用问题，无论是数据仓库还是大数据平台，里面包含了接口层数据、存储层数据、轻度汇总层、重度汇总层、模型层数据、报表层数据等等，各种各样的表有成千上万，这些表有的是中间处理过程，有些是一次性的报表，不同表之间的数据一致性和口径也会不同，而且不同的表不同的字段对数据安全要求级别也不同。
此外还要考虑多租户的资源安全管理，如何让内部开发者快速获取所需的数据资产目录，如何阅读相关数据的来龙去脉，如何快速的实现开发，这些在大数据平台建设初期没有考虑周全。
另外一个问题是对外应用，随着大数据平台的应用建设，每一个对外应用都采用单一的数据库加单一应用建设模式，独立考虑网络安全、数据安全、共享安全，逐渐又走向了烟囱似的开发道路。
总结：大数据平台，即为数据一站式服务，提供可视化的数据展示，提取，计算任务安排，资源管理，数据治理，安全措施，共享应用等等。
平台数据流向图
平台流程架构图
1.1.3 数据中台（Data Middle Platform）
数据中台要解决什么？数据如何安全的、快速的、最小权限的、且能够溯源的被探测和快速应用的问题。
数据中台不应该被过度的承载平台的计算、存储、加工任务，而是应该放在解决企业逻辑模型的搭建和存储、数据标准的建立、数据目录的梳理、数据安全的界定、数据资产的开放，知识图谱的构建。
通过一系列工具、组织、流程、规范，实现数据前台和后台的连接，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。
总结：厚平台，大中台，小前台；没有基础厚实笨重的大数据平台，是不可能构建数据能力强大、功能强大的数据中台的；没有大数据中台，要迅速搭建小快灵的小前台也只是理想化的。
中台架构图
阿里数据中台架构图
2 数据库的"分家"
随着关系数据库理论的提出，诞生了一系列经典的RDBMS，如Oracle，MySQL，SQL Server等。这些RDBMS被成功推向市场，并为社会信息化的发展做出的重大贡献。然而随着数据库使用范围的不断扩大，它被逐步划分为两大基本类型：
操作型数据库（OLTP）
主要用于业务支撑。一个公司往往会使用并维护若干个数据库，这些数据库保存着公司的日常操作数据，比如商品购买、酒店预订、打车下单、外卖订购等；
分析型数据库（OLAP）
主要用于历史数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析；
总结
那么为什么要"分家"？在一起不合适吗？能不能构建一个同样适用于操作和分析的统一数据库？
答案是NO。一个显然的原因是它们会"打架"......如果操作型任务和分析型任务抢资源怎么办呢？再者，它们有太多不同，以致于早已"貌合神离"。接下来看看它们到底有哪些不同吧。
因为主导功能的不同(面向操作/面向分析)，两类数据库就产生了很多细节上的差异。就好像玩LOL一个中单一个ADC，肯定有很多行为/观念上的不同
2.1 OLAP 和 OLTP简介
数据处理大致可以分成两大类：
联机事务处理OLTP（on-line transaction processing）：是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作。
联机分析处理OLAP（On-Line Analytical Processing）：是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。
2.2 定义差别
| 对比内容 | 操作型数据库(OLTP) | 分析型数据库(OLAP) |
|---|---|---|
| 数据内容 | 当前值 | 历史的、存档的、归纳的、计算的数据 |
| 数据目标 | 面向业务操作程序，重复处理 | 面向主题域，分析应用，支持决策 |
| 数据特性 | 动态变化，按字段更新 | 静态、不能直接更新，只能定时添加、刷新 |
| 数据结构 | 高度结构化、复杂，适合操作计算 | 简单，适合分析 |
| 使用频率 | 高 | 中到低 |
| 数据访问量 | 每个事务只访问少量记录 | 有的事务可能需要访问大量记录 |
| 对响应时间的要求 | 以秒为单位计算 | 以秒、分钟、甚至小时为计算单位 |
2.3 定位差别
| 对比属性 | OLTP | OLAP |
|---|---|---|
| 代表 | Mysql | Hive |
| 读特性 | 每次查询只返回少量数据 | 对大量数据进行汇总 |
| 写特性 | 随机、低延迟写入用户的操作 | 批量导入 |
| 用户 | 操作人员 | 决策人员 |
| DB设计 | 面向应用 | 面向主题 |
| 数据 | 当前的，最新的细节，二维表 | 历史的，聚集的，多维表 |
| 工作单位 | 事务性保证 | 复杂查询 |
| 用户数 | 上千个 | 上百万个 |
| DB大小 | 100MB-GB | 100GB-TB以上 |
| 时间要求 | 具有实时性 | 对时间的要求不严格 |
| 主要应用 | 数据库：WEB项目 | 数据仓库：分析师，挖掘师 |
2.4 组成差别
| 对比内容 | 操作型数据库(OLTP) | 分析型数据库(OLAP) |
|---|---|---|
| 数据时间范围差别 | 只会存放一定天数的数据 | 存放的则是数年内的数据 |
| 数据细节层次差别 | 存放的主要是细节数据 也有汇总需求，但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的，因此汇总数据会在每次查询时动态生成。 | 存放的既有细节数据，又有汇总数据，对于用户来说，重点关注的是汇总数据部分。因为汇总数据比较稳定不会发生改变，而且其计算量也比较大(因为时间跨度大)，因此它的汇总数据可考虑事先计算好，以避免重复计算。 |
| 数据时间表示差别 | 通常反映的是现实世界的当前状态 | 既有当前状态，还有过去各时刻的快照。可以综合所有快照对各个历史阶段进行统计分析 |
2.5 技术差别
| 对比内容 | 操作型数据库(OLTP) | 分析型数据库(OLAP) |
|---|---|---|
| 数据更新差别 | 允许用户进行增，删，改，查 | 规范是只能进行查询 |
| 数据冗余差别 | 减少数据冗余，避免更新异常 | 没有更新操作。因此，减少数据冗余也就没那么重要了 |
2.6 功能差别
| 对比内容 | 操作型数据库(OLTP) | 分析型数据库(OLAP) |
|---|---|---|
| 数据读者差别 | 使用者是业务环境内的各个角色，如用户，商家，进货商等 | 只被少量用户(高级管理者)用来做综合性决策 |
| 数据定位差别 | 是为了支撑具体业务创建的，因此也被称为"面向应用型数据库" | 是针对各特定业务主题域的分析任务创建的，因此也被称为"面向主题型数据库" |
2.7 OLTP数据库三范式介绍
定义：范式可以理解为设计一张数据表的表结构，符合的标准级别。规范和要求
优点：关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性。
十几年前，磁盘很贵，为了减少磁盘存储。
以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的
一次修改，需要修改多个表，很难保证数据一致性
缺点：范式的缺点是获取数据时，需要通过 Join 拼接出最后的数据。
目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式 (BCNF)、第四范式(4NF)、第五范式(5NF)。
2.7.1 函数依赖
| 学号 | 姓名 | 系名 | 班主任 | 课名 | 分数 |
|---|---|---|---|---|---|
| 001 | 张三 | 古文系 | 李白 | 文言文 | 89 |
| 001 | 张三 | 古文系 | 李白 | 古诗词 | 78 |
| 001 | 张三 | 古文系 | 李白 | 现代汉语 | 65 |
| 002 | 李四 | 古文系 | 李白 | 文言文 | 45 |
| 002 | 李四 | 古文系 | 李白 | 古诗词 | 78 |
| 002 | 李四 | 古文系 | 李白 | 甲骨文 | 98 |
| 003 | 王五 | 数学系 | 牛顿 | 高等数学 | 88 |
| 003 | 王五 | 数学系 | 牛顿 | 数学基础 | 88 |
完全函数依赖：
通过 AB 能推出 C，但是 AB 单独得不到 C，那么可以说：C 完全依赖于 AB
（学号，课名）推出 分数，但是 单独用学号 推不出 分数，那么可以说：分数 完全依赖于（学号，课名）
部分函数依赖：
通过 AB 能推出 C，通过 单独的A 或者 单独的B 也能推出 C，那么可以说：C 部分依赖于 AB
（学号，课名）推出 姓名，而还可以通过 学号 直接推出 姓名，那么可以说：姓名 部分依赖于（学号，课名）
传递函数依赖：
通过 A 得到 B，通过 B 得到 C，但是通过 C 不能得到 A，那么可以说：C 传递依赖于 A
通过 学号 推出 系名，系名 推出 系主任，但是 系主任 不能推出 学号，那么可以说：系主任 专递依赖于 学号
2.7.2 三范式区分
2.7.2.1 第一范式：属性不可切割
不符合第一范式表设计
| ID | 商品 | 商家ID | 用户ID |
|---|---|---|---|
| 001 | 5台电脑 | 小米_001 | 00001 |
如上表格不符合第一范式，商品列中的数据不是原子数据项，是可以进行分割的。
符合第一范式表设计
| ID | 商品 | 数量 | 商家ID | 用户ID |
|---|---|---|---|---|
| 001 | 电脑 | 5 | 小米_001 | 00001 |
1NF是所有关系数据库的最基本要求
2.7.2.2 第二范式：不能存在"部分函数依赖"
不符合第二范式表设计
| 学号 | 姓名 | 系名 | 班主任 | 课名 | 分数 |
|---|---|---|---|---|---|
| 001 | 张三 | 古文系 | 李白 | 文言文 | 89 |
| 001 | 张三 | 古文系 | 李白 | 古诗词 | 78 |
| 001 | 张三 | 古文系 | 李白 | 现代汉语 | 65 |
| 002 | 李四 | 古文系 | 李白 | 文言文 | 45 |
| 002 | 李四 | 古文系 | 李白 | 古诗词 | 78 |
| 002 | 李四 | 古文系 | 李白 | 甲骨文 | 98 |
| 003 | 王五 | 数学系 | 牛顿 | 高等数学 | 88 |
| 003 | 王五 | 数学系 | 牛顿 | 数学基础 | 88 |
如上表格不符合第二范式，比如：这张表主键（学号，课名），分数完全依赖于（学号和课名），但是姓名并不完全依赖于（学号和课名）
符合第二范式表设计
| 学号 | 课名 | 分数 |
|---|---|---|
| 001 | 文言文 | 89 |
| 001 | 古诗词 | 78 |
| 001 | 现代汉语 | 65 |
| 002 | 文言文 | 45 |
| 002 | 古诗词 | 78 |
| 002 | 甲骨文 | 98 |
| 003 | 高等数学 | 88 |
| 003 | 数学基础 | 88 |
| 学号 | 姓名 | 系名 | 班主任 |
|---|---|---|---|
| 001 | 张三 | 古文系 | 李白 |
| 002 | 李四 | 古文系 | 李白 |
| 003 | 王五 | 数学系 | 牛顿 |
2.7.2.3 第三范式：不能存在"传递函数依赖"
不符合第三范式表设计
| 学号 | 姓名 | 系名 | 班主任 |
|---|---|---|---|
| 001 | 张三 | 古文系 | 李白 |
| 002 | 李四 | 古文系 | 李白 |
| 003 | 王五 | 数学系 | 牛顿 |
如上表格不符合第三范式，比如：学号-->系名-->系主任，但是系主任推不出学号
符合第三范式表设计
| 学号 | 姓名 | 系名 |
|---|---|---|
| 001 | 张三 | 古文系 |
| 002 | 李四 | 古文系 |
| 003 | 王五 | 数学系 |
| 系名 | 班主任 |
|---|---|
| 古文系 | 李白 |
| 古文系 | 李白 |
| 数学系 | 牛顿 |
2.8 OLAP典型架构
OLAP有多种实现方法，根据存储数据的方式不同可以分为ROLAP、MOLAP、HOLAP
| 名称 | 描述 | 细节数据存储位置 | 聚合后的数据存储位置 |
|---|---|---|---|
| ROLAP(Relational OLAP) | 基于关系数据库的OLAP实现 | 关系型数据库 | 关系型数据库 |
| MOLAP(Multidimensional OLAP) | 基于多维数据组织的OLAP实现 | 数据立方体 | 数据立方体 |
| HOLAP(Hybrid OLAP) | 基于混合数据组织的OLAP实现 | 关系型数据库 | 数据立方体 |
ROLAP(Relational Online Analytical Processing)
ROLAP架构并不会生成实际的多维数据集，而是使用雪花模式以及多个关系表对数据立方体进行模拟，它的OLAP引擎就是将用户的OLAP操作，如上钻下钻过滤合并等，转换成SQL语句提交到数据库中执行，并且提供聚集导航功能，根据用户操作的维度和度量将SQL查询定位到最粗粒度的事实表上去
这种架构下的查询没有MOLAP快速。因为ROLAP中，所有的查询都是被转换为SQL语句执行的。而这些SQL语句的执行会涉及到多个表之间的JOIN操作，没有MOLAP速度快，往往都是通过内存计算实现。(内存的昂贵大家是知道的)
MOLAP(Multidimensional Online Analytical Processing)
MOLAP架构会生成一个新的多维数据集，也可以说是构建了一个实际数据立方体。事先将汇总数据计算好，存放在自己特定的多维数据库中，用户的OLAP操作可以直接映射到多维数据库的访问，不通过SQL访问。(空间换时间，典型代表Kylin)
HOLAP(Hybrid Online Analytical Processing)
这种架构综合参考MOLAP和ROLAP而采用一种混合解决方案，将某些需要特别提速的查询放到MOLAP引擎，其他查询则调用ROLAP引擎。上述MOLAP和ROLAP的结合。它提供了更大的灵活度，MOLAP提供提供了更加快速的响应速度。但是带来的问题是，数据装载的效率非常低，因为其实就是将多维的数据预先填好，但是随着数据量过大维度成本越高，容易引起“数据爆炸”。
2.9 OLAP数据立方体(Data Cube)
OLAP（online analytical processing）是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。从各方面观察信息，也就是从不同的维度分析数据，因此OLAP也称为多维分析。
很多年前，当我们要手工从一堆数据中提取信息时，我们会分析一堆数据报告。通常这些数据报告采用二维表示，是行与列组成的二维表格。但在真实世界里我们分析数据的角度很可能有多个，数据立方体可以理解为就是维度扩展后的二维表格。下图展示了一个三维数据立方体：
更多时候数据立方体是N维的。它的实现有两种方式。其中星形模式就是其中一种，该模式其实是一种连接关系表与数据立方体的桥梁。但对于大多数纯OLAP使用者来讲，数据分析的对象就是这个逻辑概念上的数据立方体，其具体实现不用深究。对于这些OLAP工具的使用者来讲，基本用法是首先配置好维表、事实表，然后在每次查询的时候告诉OLAP需要展示的维度和事实字段和操作类型即可。
最常见的五大操作：切片，切块，旋转，上卷，下钻。
2.9.1 切片和切块(Slice and Dice)
在数据立方体的某一维度上选定一个维成员的操作叫切片，而对两个或多个维执行选择则叫做切块。下图逻辑上展示了切片和切块操作：
2.9.2 旋转(Pivot)
旋转就是指改变报表或页面的展示方向。对于使用者来说，就是个视图操作，而从SQL模拟语句的角度来说，就是改变SELECT后面字段的顺序而已。下图逻辑上展示了旋转操作：
2.9.3 上卷和下钻(Rol-up and Drill-down)
上卷可以理解为"无视"某些维度；下钻则是指将某些维度进行细分。下图逻辑上展示了上卷和下钻操作：
2.9.4 Cube 和 Cuboid
Cube（或 Data Cube），即数据立方体，是一种常用于数据分析与索引的技术；它可以对原始数据建立多维度索引。通过 Cube 对数据进行分析，可以大大加快数据的查询效率。
Cuboid 特指在某一种维度组合下所计算的数据。给定一个数据模型，我们可以对其上的所有维度进行组合。对于 N 个维度来说，组合的所有可能性共有 2 的 N 次方种。对于每一种维度的组合，将度量做 聚合运算，然后将运算的结果保存为一个物化视图，称为 Cuboid。
所有维度组合的 Cuboid 作为一个整体，被称为 Cube。所以简单来说，一个 Cube 就是许多按维度聚合的物化视图的集合。
下面来列举一个具体的例子：
假定有一个电商的销售数据集，其中维度包括 时间（Time）、商品（Item）、地点（Location）和供应商（Supplier），度量为销售额（GMV）。
那么所有维度的组合就有 2 的 4 次方 =16 种
一维度（1D） 的组合有[Time]、[Item]、[Location]、[Supplier]4 种
二维度（2D）的组合 有[Time，Item]、[Time，Location]、[Time、Supplier]、[Item，Location]、 [Item，Supplier]、[Location，Supplier]6 种
三维度（3D）的组合也有 4 种
零维度（0D）的组合有 1 种
四维度（4D）的组合有 1 种
3 数据仓库的演进
4 数据仓库主要用途
大家应该已经意识到这个问题：既然分析型数据库中的操作都是查询，因此也就不需要严格满足完整性/参照性约束以及范式设计要求，而这些却正是分析型数据库精华所在。这样的情况下再将它归为数据库会很容易引起大家混淆，毕竟在绝大多数人心里数据库是可以关系型数据库画上等号的。
那么为什么不干脆叫"面向分析的存储系统"呢？
这就是关于数据仓库最贴切的定义了。事实上数据仓库不应让传统关系数据库来实现，因为关系数据库最少也要求满足第1范式，而数据仓库里的关系表可以不满足第1范式。也就是说，同样的记录在一个关系表里可以出现N次。但由于大多数数据仓库内的表的统计分析还是用SQL，因此很多人把它和关系数据库搞混了。
4.1 支持数据提取
数据提取可以支撑来自企业各业务部门的数据需求。
由之前的不同业务部门给不同业务系统提需求转变为不同业务系统统一给数据仓库提需求，避免烟囱式开发
4.2 支持报表系统
基于企业的数据仓库，向上支撑企业的各部门的统计报表需求，辅助支撑企业日常运营决策。
4.3 支持数据分析
从许多来自不同的企业业务系统的数据中提取出有用的数据并进行清理，以保证数据的正确性，然后经过抽取、转换和装载,即ETL过程，合并到一个企业级的数据仓库里，从而得到企业数据的一个全局视图；
在此基础上利用合适的查询和分析工具、数据挖掘工具、OLAP工具等对其进行分析和处理（这时信息变为辅助决策的知识）；
最后将知识呈现给管理者，为管理者的决策过程提供支持 。
4.4 支持数据挖掘
数据挖掘也称为数据库知识发现（Knowledge Discovery in Databases, KDD），就是将高级智能计算技术应用于大量数据中，让计算机在有人或无人指导的情况下从海量数据中发现潜在的，有用的模式（也叫知识）。
Jiawei Han在《数据挖掘概念与技术》一书中对数据挖掘的定义：数据挖掘是从大量数据中挖掘有趣模式和知识的过程，数据源包括数据库、数据仓库、Web、其他信息存储库或动态地流入系统的数据。
4.5 支持数据应用
物联网基于位置数据的旅游客流分析及人群画像
通信基于位置数据的人流监控和预警
银行基于用户交易数据的金融画像应用
电商根据用户浏览和购买行为的用户标签体系及推荐系统
征信机构根据用户信用记录的信用评估
出行基于位置数据的车流量分析，调度预测
5 数据集市
数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。
数据集市可以分为两种，一种是独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；另一种是非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的"子集"。
简单理解：
数据集市：部门级别的数据仓库，能为某个局部范围内的管理人员提供服务。
数据仓库：企业级别的数据仓库，能为企业各个部门的运行提供决策支持。
6 建模的基本概念
6.1 关系建模
上图为web应用中的一个建模片段，遵循三范式建模，可以看出，较为松散、零碎， 物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地 被应用，功能性较强。关系模型主要应用与 OLTP 系统中，为了保证数据的一致性以及避免 冗余，所以大部分业务系统的表都是遵循第三范式的。
6.2 维度建模
维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法
上图为维度模型建模片段，主要应用于 OLAP 系统中，通常以某一个事实表为中心进行表的 组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。
关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种
6.3 维度建模的三种模式
星形模式
星形模式(Star Schema)是最常用的维度建模方式
可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
维表只和事实表关联，维表之间没有关联；
每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的逻辑外键；
以事实表为核心，维表围绕核心呈星形分布；
雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。(三范式代表作)
星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。
星座模式
星座模式(Fact Constellations Schema)也是星型模式的扩展。
前面两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，星座模式将作为最主要的维度建模。
6.4 维度表和事实表
维度表(dimension)
表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。
事实表(fact table)
表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的逻辑外键，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。
事实维度举例
昨天我去菜市场买了一只蝙蝠，然后我就被隔离了。
事实：订单==>买蝙蝠这个事
维度：
时间==>昨天
用户==>我
商品==>蝙蝠
地理==>菜市场
6.4.1 维度表
维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。例如：用户、商品、日期、地区等。
常用于一个客观世界的维度描述，往往列比较多。
审视数据的角度
维表的特征：
维表的范围很宽（具有多个属性、列比较多）
跟事实表相比，行数相对较小：通常< 10 万条
静态表示的，名词性质的表
6.4.2 事实表
事实表用于正确的记录既定的已经发生的事实，常用于存储ID和度量值，各种维度外键
事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这 个术语表示的是业务事件的度量值（可统计次数、个数、件数、金额等），例如，订单事件中的下单金额。
每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具 有两个和两个以上的外键、外键之间表示维表之间多对多的关系。
事实表的特征：
非常的大
内容相对的窄：列数较少
经常发生变化，每天会新增加很多
动态表示的，动词性质的表
事务型事实表(每天导入新增)
以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的 一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量 更新
周期型快照事实表(每日全量)
周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者 每月的销售额，或每月的账户余额等
累积型快照事实表(每天导入新增及变化)
累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储 订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪 订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
6.5 数据分层
为什么分层：
简单化：把复杂的任务分解为多层来完成，每层处理各自的任务，方便定位问题。
减少重复开发：规范数据分层，通过中间层数据，能够极大的减少重复计算，增加结果复用性。
隔离数据：不论是数据异常还是数据敏感性，使真实数据和统计数据解耦。
下面列举常见电商表的分层结构
6.5.1 ODS层
保持数据原貌不做任何修改，起到备份数据的作用。
数据采用压缩，减少磁盘存储空间（例如：原始数据 100G，可以压缩到 10G 左 右）
创建分区表，防止后续的全表扫描
6.5.2 DWD层
DWD 层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。
维度建模一般按照四个步骤：选择业务过程→声明粒度→确认维度→确认事实
选择业务过程
在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流 业务，一条业务线对应一张事实表。
声明粒度
订单中，每个商品项作为下单事实表中的一行，粒度为每次下单
每周的订单次数作为一行，粒度就是每周下单。
每月的订单次数作为一行，粒度就是每月下单
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以 此来应各种各样的需求。
典型的粒度声明如下：
确定维度
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
确定事实
此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。
在 DWD 层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的 明细层事实表。事实表可做适当的宽表化处理。
| 事实/维度 | 时间 | 用户 | 地区 | 商品 | 优惠卷 | 活动 | 编码 | 度量 |
|---|---|---|---|---|---|---|---|---|
| 订单 | √ | √ | √ | √ | 件数/金额 | |||
| 订单详情 | √ | √ | √ | 件数/金额 | ||||
| 支付 | √ | √ | 次数/金额 | |||||
| 加入购物车 | √ | √ | √ | 件数/金额 | ||||
| 收藏 | √ | √ | √ | 个数 | ||||
| 评价 | √ | √ | √ | 个数 | ||||
| 退款 | √ | √ | √ | 件数/金额 | ||||
| 优惠卷领用 | √ | √ | √ | 个数 |
6.5.3 DWS层
统计各个主题对象的当天行为，服务于 DWT 层的主题宽表，以及一些业务明细数据， 应对特殊需求（例如，购买行为，统计商品复购率）。
6.5.4 DWT层
以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建主题对象的全 量宽表。（就是按照维度来决定分析者的角度，如用户->什么时间->下了什么单，支付了什么，加入购物车了什么）
6.5.5 ADS层
对系统各大主题指标分别进行分析。