6数据仓库

warehouse面向主题的、集成的、非易失的、随时间变化的。

what

面向主题

数据是按照一定主题域进行组织。
主题是抽象的概念，是指用户使用数据仓据进行决策时所关心的重点方面。
例如：
银行的数据仓库主题：客户
客户数据来源：银行储蓄数据库、信用卡数据库等进行整合，操作型数据库的数据组织相向事务处理任务，各个业务系统之间各自分离。

集成

数据库之间互相独立，往往异构，数据仓库的数据对原有分散的数据库数据抽取、清理的基础上，加工整合得到，必须消除数据的不一致性，保证全局一致性。
从面向应用到面向主题。

非易失 相对稳定

数据进入数据仓库后，一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载和刷新。
包含了大量的历史数据。
数据经过集成进入数据仓库后是极少或根本不更新的。

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

把信息加以整理归纳和重组，并及时提供给相应的管理决策人员。

主要作用

支持数据提取

支持报表系统

支持数据分析BI

商业智能是一种解决方案

支持数据挖掘

也称数据库知识发现（Knowledge Discovery in Database，KDD）

支持数据应用

电信基于位置数据的旅游客流分析及人群画像
电信基于位置数据的人流监控和预警
银行基于用户交易数据的金融画像应用
电商根据用户浏览和购买行为的用户标签体系及推荐系统
征信机构根据用户信用记录的信用评估

数据仓库的架构设计

游戏行业背景介绍

所有大数据平台都是一样的功能设计，虽然组件和模块各有不同，但是主要流程有三个版块，数据采集、数据存储和计算、数据产出与展示。

采集方式

实时采集：
常见的flume+kafka+流计算框架
离线采集：
不能实时获取数据

游戏日志采集架构

游戏数据分析数据的采集一般是采集日志，就是每个玩家的行为日志，包括注册、登录等信息。存在不同区服的不同服务器和数据库中。
日志数据一般存放在mysql中，做主从备份，一般采用分表的形式来存储，一般一个月一个表。

数仓分层设计

数仓分层：

ODS层Operation Data Store 原始数据层：原始数据层，存放原始数据，直接加载原始日志，数据不做处理。
DWD层data warehouse detail明细数据层：结构和粒度与原始表保持一致，对ODS层数据进行清洗，去除空值，脏数据，超过极限范围的数据。
DWS层data warehouse service服务数据层：以DWD层为基础，进行轻度汇总。
ADS层 、application data store数据应用层：为各种统计报表提供数据。

why

把复杂问题简单化
减少重复开发
隔离原始数据

总的来说分为三层：
ODS层（原始数据层）
DW层（明细数据层）
RES层（数据应用层）

规范

比如日志数据的属性key尽量复用。

dw：中间层，存放数据仓库明细层的数据，这一层主要用于对数据进行整合和ETL处理之后存放的，可以在各个业务场景下共用。
hive中性能消耗最大的两个地方。
1.大表查询：需要提前每天做一次规约聚合操作，将数据按照相应的维度进行一次细粒度的聚合，减少数据量。
2.多表关联：多表之间的关联式性能消耗最厉害的地方。因此我们要在做一个大表的聚合关联，这个时段给予这个聚合任务的大量资源来完成，这样后续结果集查询的数据就会很简单，少去很多关联，直接查询这个大表即可，提高查询效率。

hive中的数据压缩

数据质量

数据跨系统连接

数据仓库架构

维度建模

要建设数据仓库，不得不提到数仓建模。
Inmon和Kimball最常见

Inmon

Inmon自上而下的架构，将数据仓库定义为整个企业级的集中存储。数据仓库存放着最低的详细级别的原子数据，维度数据集市只在数据仓库完成后才创建，因此数据仓库式企业信息工厂CIF的中心，为交付商业智能提供逻辑框架。
不同的OLTP数据集中到面向主题、集成的、不易失的和时间变化的结构中，用于以后的分析。
数据可以通过下钻到最细层，或者上卷到汇总层。数据集市应该是数据仓库的子集，每个数据集市式针对独立部门特殊设计的。

Kimball

自下而上的架构，数据仓库是一系列数据集市的集合。认为数据仓库是一系列数据集市的集合，首先建立最重要的业务单元或部门的数据集市。
一份针对查询和分析做特别结构化的事物数据拷贝。

Inmon模式适合开发进度慢，实施成本高，适合对设计科学性和规范性较高的企业，在业务模式较固定的行业应用较好，比如金融和电信等行业。
Kimball 模式适合快速迭代，实施成本低，能够较快交付任务。这种模式非常适应互联网行业的高速发展，也适合中小型企业。

事实表、维度表、实体表

事实表：实质是通过各种维度和一些指标值组合来确定一个事实的。
维度表：对事实的各个方面描述，比如时间。
实体表：实际对象的表，客观存在的事物数据。

如果属性值是离散的，用于过滤和标记的，就放到维度表里；如果是属性值是连续取值，可用于计算的，就放到事实表中。

模型

维度建模的基础上又分为三种模型：
星型模型
雪花模型
星座模型

范式

由Inmon提倡
主要运行于传统数仓之中，一般建立在关系型数据库上，不是大数据平台下。看一看，也需要了解，对数据之间的血缘关系的梳理由比较清晰的思路。
三范式建模法：
1NF

2NF

3NF

将数据抽象为实体、属性、关系来表示数据关联和事物描述。关系通过主键进行关联，关联的时候会产生1对1，1对多，多对多的关系。

注意：多对多关系要产生笛卡尔积（两个数据量向乘），计算量会增加很多倍，降低计算性能，主键分布不均还会产生数据倾斜。尽量避免使用。

ETL

extraction
transformation
loading
中文名称：数据抽取、转换、加载

数据抽取工作分为抽取、清洗、转换、装载

中间层设计原则

根据Inmon和Kimball架构的思想，采用三层架构来处理分层。
原始层、中间层、结果层。
中间层是根据主题域来区分的比较大的集合，每一个中间层的表都是比较大的表。
有了这个中间层可以一次性的将原始数据中的脏数据、错误数据都补足进来，后面所有的查询都变得简单，表关联很多，性能消耗最大。

OSM模型

objective strategy measurement业务目标、业务策略、业务度量。
指标分类

基础指标
复合指标
派生指标
标准信息

用户画像

根据用户属性、生活习惯、消费行为抽象出的标签化的用户模型。

社会属性
生活习惯
消费行为

人口属性
社会属性
行为习惯
兴趣偏好
心理属性

三个步骤：
数据收集
给用户打标签
构建画像

缓慢变化维度

slowly changing dimension，SCD
数据仓库维度表中，那些随时间变化比较不明显，但是仍然会发生变化的维度。
缓慢变化维总共有7中：
变化类型1：改写属性值
变化类型2：添加维度行
变化类型3：增加维度列
变化类型4：添加历史表
变化类型5：混合模式之可预见的多重变化
变化类型6：非常规混合模型
附加类型7：混合模式之不可预见的单重变化

元数据管理

meta data
主要记录数据仓库中模型的定义、各层级的映射关系、监控数据仓库的数据状态以及ETL的任务运行状态。
技术元数据
业务元数据
管理过程元数据

数据集市

数据集市data market是满足特定的部门或者用户的需求，按照多维的方式进行存储，包括定义维度、需要计算的指标、维度的层次等，生成面向决策分析需求的数据立方体。
在我们的数据仓库里面，就是结果层的数据，通过sqoop等数据同步工具向业务数据库的那一层，作为我们的数据集市。

拉链表

记录历史，记录一个事物从开始到当前状态的所有变化的信息。

MPP大规模并行处理

Massively Parallel Processing 大规模并行处理
每个节点都有独立的磁盘存储系统和内存系统。MPP将任务并行的分散到多个服务器和节点上，每个节点上计算完成后，将各自部分的结果汇总到一起得到最终的结果。

特征
任务并行执行
数据分布式存储
私有资源
横向扩展
shared nothing 架构

常见的mpp架构的数据库
Greenplum
elasticsearch
presto
clickhouse

mpp和hadoop的区别

clickhouse

是俄罗斯的yandex于2016年开源的列式存储数据库管理系统（DBMS：Database Management System），简称CK。
主要用于在线分析处理查询（OLAP:Online Analytical Processing）
能够使用SQL查询实时生成分析数据报表。
优点
真正的面向列的DBMS
数据压缩
磁盘存储的数据
多核并行处理
多个服务器上分布式处理
SQL支持
向量化引擎
实时数据更新
索引
支持在线查询
支持近似计算
数据复制和对数据完整性的支持
缺点
没有完整的事务支持
 缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量修改或删除数据
稀疏索引使得clickhouse不适合通过其键检索单行的点查询

OLAP场景关键特征：
大多数是读请求
数据总是以相当大的批(> 1000 rows)进行写入
不修改已添加的数据
每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列
宽表，即每个表包含着大量的列
较少的查询(通常每台服务器每秒数百个查询或更少)
对于简单查询，允许延迟大约50毫秒
列中的数据相对较小： 数字和短字符串(例如，每个UR60个字节)
处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）
事务不是必须的
对数据一致性要求低
每一个查询除了一个大表外都很小
查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中
应用场景：
用于结构良好清晰且不可变的事件或日志流分析。
不适合的场景：
事务性工作(OLTP)，高请求率的键值访问，低延迟的修改或删除已存在数据，Blob或文档存储，超标准化数据。