Hive参数深入浅出及Hive企业应用

Hive参数介绍

MapJoin的问题剖析

		## 概念说明
将join的本来应该是reduce进行关联查找的过程，改成由纯map端进行关联查找
		## 特点特征
减少了reduce的处理，全部放到map端进行操作。
减少了数据移动，提升了IO和计算效率。
		## 应用场景
大表join小表的时候，
大数据块join小数据块的时候。

数据倾斜的问题剖析

典型的木桶原理，任务的执行完成时间，取决于最后一个Task的完成时间
## 假倾斜
数据本身没有倾斜，由于编码导致数据倾斜的发生。
## 专业术语：{
uv：独立用户访问个数（Unique Visitor）
pv:曝光次数（页面访问次数）
qps:接口调用次数}
## 真倾斜
数据或是任务本身真的存在客观的倾斜性
解决方法：只能分而治之，将倾斜的数据分类，将正常数据分类，然后进行分别计算。

二次排序的问题剖析

map到reduce的处理过程当中，按照2个字段进行升序排列
## 特点特征
2个字段排序，第1个字段若有比较结果则按第1个字段排序，若相等，则按第2个字段升序排列。
## 应用场景
当单个字段不能够满足排序要求时，均可使用二次排序。
## 代码实现
Hadoopcore之mapreduce实现
重写Map和Reduce之前的输入输出的Key和Value。
HiveSQL实现
Select * from table order by c1,c2 asc

Hive参数使用方式

四种使用方式:
通过配置文件设置,全局性
通过在进入hive cli时指定配置参数
通过shell脚本调用hive -e做参数设置和脚本执行，生产环境采用最多

数据仓库架构设计

数据仓库的主要工作就是ETL，Extract-Transform-Load
用来描述数据从来源端经过装载(load)、抽取(extract)、转换(transform)至目的端的过程。

数据架构

## 架构原则：
				先水平分层，再垂直分主题域
## 数据架构分三层
				源数据落地区(SDF:Source Data File)
				数据仓库层(DW:Data WareHouse)
				数据集市层(DM:Data Market)
## 数据仓库层进一步细分为三层
			源数据层(DWB)
			细节数据层(DWD)
			汇总数据层(DWS)

数据仓库分层介绍(水平划分)

按主题划分（垂直划分）

数据仓库建模

如何构建数据模型

目前的构建方法主要有三种：
范式建模法
维度建模法
实体建模法

范式建模法

大部分采用的是三范式建模法
数据库六大范式说明
第1范式-1NF：无重复的列、列不可再拆分。
第2范式-2NF：属性完全依赖于主键
第3范式-3NF：属性不依赖于其它非主属性，即属于依赖于主键不能出现传递依赖。
巴斯-科德范式（BCNF），第四范式(4NF），第五范式（5NF，又称完美范式）
范式建模优点
从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。
范式建模缺点
其建模方法限定在关系型数据库之上，在有些时候(需要冗余的时候)反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要灵活调整才能达到要求。
使用建议：当不需要冗余设计提高易用性和计算效率时，可以采用这种模式。（常见的即为web项目开发中）

维度建模法

星型模式（Star-schema）和雪花模式（Snowflake-schema）
事实表：发生在某个时间点上的一个事件
维度表：分析视角
星型建模法：:维度表全部直接关联到事实表中

雪花建模法

维度表并非全部关联到事实表中，存在一个或多个表没有直接关联到事实表中时，其形状类似雪花，故称之。

星形和雪花模型进行维度建模的对比说明

星形模型：维度表全部直接关联到事实表中，其形状类似星星，故称之。
雪花模型：维度表并非全部关联到事实表中，存在一个或多个表没有直接关联到事实表中时，其形状类似雪花，故称之。
##相同点
雪花模型属于星形模型的扩展，属于星形模型。
都是围绕事实表、维度表展开模型构建，只是层次设计不尽相同

对比总结说明

数据规范性：雪花胜于星型。
性能：雪花的表关联较多，并行性和计算性能上会低于性能上往往低于星型。
ETL开发:雪花关系多则关联多，代码量较复杂一些。而星型数据较集中，关联少，代码量会少一些。
实际使用，两者应用的均比较多，但星型略胜一筹。

关于维度建模法的总结说明

广泛被使用的原因：在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等，能够极大的提升数据仓库的处理能力。
维度建模优点
由于其可以有必要合理的冗余和其它范式建模的严格限制，相对于针对3NF 的建模方法，星型模式在性能上占据明显的优势。
维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。
维度建模缺点
由于在构建星型模式之前需要进行大量的数据预处理，会带来大量的数据处理工作。
业务发生变化后，往往需要更新维度的预处理。
存储和处理过程中，数据冗余量较大
依靠维度建模的话，其维度必然会且维护成本增大，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
使用建议：在数据架构设计中的细节数据层、汇总数据层、数据集市层等需要提升计算性能的时候，均可以使用，也是建模过程中逻辑建模阶段最常用的方法之一。（常用于数据仓库模型设计）

实体建模法

实体建模法并不是数据仓库建模中常见的一个方法。
源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。