Hive大数据开发
Posted 爱是与世界平行
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Hive大数据开发相关的知识，希望对你有一定的参考价值。
1 Hive基本概念
1.1 Hive简介
1.1.1 什么是Hive
Hive由Facebook实现并开源，基于Hadoop的一个数据仓库工具，可以将结构化的数据映射为一张数据库表，并提供**HQL(Hive SQL)**查询功能，底层数据是存储在HDFS上。Hive的本质是将SQL语句转换为 MapReduce任务运行，使不熟悉MapReduce的用户很方便地利用HQL处理和计算HDFS上的结构化的数据，适用于离线的批量数据计算。
主要用途：用来做离线数据分析，比直接用 MapReduce 开发效率更高，Hive依赖于HDFS存储数据，Hive将HQL转换成MapReduce执行。
所以说Hive是基于hadoop的一个数据仓库工具，实质就是一款基于HDFS的MapReduce计算框架
1.1.2 为什么使用Hive
直接使用MapReduce所面临的问题：
-
人员学习成本太高
-
项目周期要求太短
-
MapReduce实现复杂查询逻辑开发难度太大
为什么要使用Hive：
-
更友好的接口：操作接口采用类SQL的语法，提供快速开发的能力
-
更低的学习成本：避免了写MapReduce，减少开发人员的学习成本
-
更好的扩展性：可自由扩展集群规模而无需重启服务，还支持用户自定义函数
1.1.3 Hive特点
优点：
1、可扩展性,横向扩展，Hive可以自由的扩展集群的规模，一般情况下不需要重启服务
横向扩展：通过分担压力的方式扩展集群的规模
纵向扩展：一台服务器cpu i7-6700k 4核心8线程，8核心16线程，内存64G => 128G
2、延展性，Hive支持自定义函数，用户可以根据自己的需求来实现自己的函数
3、良好的容错性，可以保障即使有节点出现问题，SQL语句仍可完成执行
缺点：
1、hive不支持记录级别的增删改操作，但是用户可以通过查询生成新表或者将查询结果导入到文件中（当前选择的hive-1.2.1的版本支持记录级别的插入操作）
2、Hive的查询延时很严重，因为MapReduce Job的启动过程消耗很长时间，所以不能用在交互查询系统中。
3、hive不支持事务（因为不没有增删改，所以主要用来做OLAP（联机分析处理），而不是OLTP（联机事务处理），这就是数据处理的两大级别）。
1.2 Hive的体系架构
基本组成
用户接口：
-
CLI，Shell终端命令行，最常用（学习，调试，生产）
-
JDBC/ODBC，是Hive的基于JDBC操作提供的客户端，用户（开发员，运维人员）通过这连接至Hive server
-
Web UI，通过浏览器访问Hive
元数据存储：
- 元数据，通俗的讲，就是存储在Hive中的数据的描述信息。
Hive中的元数据通常包括：表的名字，表的列和分区及其属性，表的属性（内部表和外部表），表的数据所在目录
Metastore默认存在自带的Derby数据库中。缺点就是不适合多用户操作，并且数据存储目录不固定。数据库跟着Hive走，极度不方便管理
解决方案：通常存我们自己创建的mysql库（本地 或 远程）
解释器，编译器，优化器，执行器
这四大组件完成HQL查询语句从词法分析，语法分析，编译，优化，以及生成查询计划的生成。生成的查询计划存储在HDFS中，并随后由MapReduce调用执行
执行流程
HiveQL通过命令行或者客户端提交，经过Compiler编译器，运用Metastore中的元数据进行类型检测和语法分析，生成一个逻辑方案(logical plan)，然后通过的优化处理，产生一个MapReduce任务。
1.3 Hive和RDBMS的对比
| 对比项 | Hive | RDBMS |
|---|---|---|
| 查询语言 | HQL | SQL |
| 数据存储 | HDFS | Raw Device or Local FS |
| 执行器 | MapReduce | Executor |
| 数据插入 | 支持批量导入/单条插入 | 支持单条或者批量导入 |
| 数据操作 | 覆盖追加 | 行级更新删除 |
| 处理数据规模 | 大 | 小 |
| 执行延迟 | 高 | 低 |
| 分区 | 支持 | 支持 |
| 索引 | 0.8版本之后加入简单索 | 支持复杂的索引 |
| 扩展性 | 高（好） | 有限（差） |
| 数据加载模式 | 读时模式（快） | 写时模式（慢） |
| 应用场景 | 海量数据查询 | 实时查询 |
总结：Hive具有SQL数据库的外表，但应用场景完全不同，Hive只适合用来做海量离线数据统计分析，也就是数据仓库。
1.4 Hive的数据存储
1、Hive的存储结构包括数据库、表、视图、分区和表数据等。数据库，表，分区等等都对应HDFS上的一个目录。表数据对应HDFS对应目录下的文件。
2、Hive中所有的数据都存储在 HDFS 中，没有专门的数据存储格式（可支持TextFile，SequenceFile，RCFILE或者自定义格式等）
3、 只需要在创建表的时候告诉 Hive 数据中的列分隔符和行分隔符，Hive 就可以解析数据
4、Hive中包含以下数据模型：
database：在hdfs中表现为$hive.metastore.warehouse.dir目录下一个文件夹
table：在hdfs中表现所属database目录下一个文件夹
external table：与table类似，不过其数据存放位置可以指定任意HDFS目录路径
partition：在hdfs中表现为table目录下的子目录
bucket：在hdfs中表现为同一个表目录或者分区目录下根据hash散列之后的多个文件
view：与传统数据库类似，只读，基于基本表创建
5、Hive的元数据存储在RDBMS中，除元数据外的其它所有数据都基于HDFS存储。默认情况下，Hive 元数据保存在内嵌的 Derby 数据库中，只能允许一个会话连接，只适合简单的测试。实际生产环境中不适用，为了支持多用户会话，则需要一个独立的元数据库，使用 MySQL 作为元数据库，Hive 内部对 MySQL 提供了很好的支持。
6、Hive中的表分为内部表、外部表、分区表和Bucket。
2 Hive基本使用
1、 创建库：create database mydb;
2、 查看库：show databases;
3、 切换数据库：use mydb;
4、 创建表：create table t_user(id string, name string)
或create table t_user2 (id string, name string) row format delimited fields terminated by ‘,’;
5、 插入数据：insert into table t_user values(‘001’,‘mazhonghua’);
6、 查询数据：select * from t_user;
7、 导入数据（后面会说动静态分区）：
a) 导入HDFS数据： load data inpath ‘/mingxing.txt’ into table t_user1;
b) 导入本地数据：load data local inpath ‘/root/mingxing.txt’ into table t_user1;
小技能补充：
1、 进入到用户的主目录，使用命令cat /home/hadoop/.hivehistory可以查看到hive执行的历史命令
2、 执行查询时若想显示表头信息时，请执行命令：
Hive> set hive.cli.print.header=true;
3、 hive的执行日志的存储目录在 j a v a . i o . t m p d i r / java.io.tmpdir/ java.io.tmpdir/user.name/hive.log中，假如使用hadoop用户操作的hive，那么日志文件的存储路径为：/temp/hadoop/hive.log
2.1 Hive存储格式
- hive的存储格式分为行式存储和列式存储
- hive的默认存储方式是行式存储中的TextFile，除此之外，还有SequenceFile
- 列式存储也有两个：ORC和PARQUET
以下是行式存储和列式存储的示意图
当我们选择使用行式存储，查询所有字段的时候，查询效率最高，如：
SELECT * FROM TABLE_NAME [WHERE CONDITION]
但是，如果查询具体某几个字段时，查询效率就比较低，但对于列式存储来说，效率却能得到很大提升。一般项目中，我们使用的是列式存储，一般使用的是ORC存储
- 建表时指定存储格式
这过程中，使用ORC列式存储方式的数据会进行压缩，使数据的摆放方式更加合理。
orc内部默认采用的压缩算法是zlib
-- 建表（默认）
create table test_text (
id int,
name string
)
row format delimited fields terminated by '\\t';
-- 加载数据到test_text
load data inpath '/hive/text.log' into test_text;
-- 建表（orc）
create table test_orc (
id int,
name string
)
row format delimited fields terminated by '\\t'
stored as orc;
-- 加载数据，查询并插入（执行MapReduce）
insert into test_orc select * from test_text;
- 建表时指定存储格式的压缩算法
上面说到ORC的默认压缩算法为zlib，我们也可以通过设置去指定其压缩算法
create table test_orc_snappy(
id int,
name string
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\\t'
STORED AS orc tblproperties ("orc.compress"="SNAPPY");
所以，结合压缩算法，我们对hive的分层中，可以通过存储格式和压缩方式进行结合，达到我们对每个分层的优化效果
| 层级 | 压缩方式 | 存储格式 | 原因 |
|---|---|---|---|
| ODS层 | zlib、gz、bz2 | ORC | 省空间 |
| DW层 | snappy | ORC | 速度快 |
| DA层 | snappy | ORC | 速度快 |
2.2 Hive中的数据模型
Hive 中所有的数据都存储在 HDFS 中Hive 中包含以下数据模型：
- 表(Table)
- 外部表(External Table)
- 分区(Partition)
- 桶(Bucket)
3 Hive应用
3.1 Hive内置函数
| 关系运算 | 数学运算 | 逻辑运算 | 复合类型构造函数 | 复合类型操作符 | 数值计算函数 | 集合操作函数 | 类型转换函数 | 日期函数 | 汇总统计函数（UDAF） |
|---|---|---|---|---|---|---|---|---|---|
| 等值比较: = | 加法操作: + | 逻辑与操作: AND 、&& | map结构 | 获取array中的元素 | 取整函数: round | map类型大小：size | 二进制转换：binary | UNIX时间戳转日期函数: from_unixtime | 个数统计函数: count |
| 等值比较:<=> | 减法操作: – | 逻辑或操作: OR 、|| | struct结构 | 获取map中的元素 | 指定精度取整函数: round | array类型大小：size | 基础类型之间强制转换：cast | 获取当前UNIX时间戳函数: unix_timestamp | 总和统计函数: sum |
| 不等值比较: <>和!= | 乘法操作: * | 逻辑非操作: NOT、! | named_struct结构 | 获取struct中的元素 | 向下取整函数: floor | 判断元素数组是否包含元素：array_contains | 日期转UNIX时间戳函数: unix_timestamp | 平均值统计函数: avg | |
| 小于比较: < | 除法操作: / | array结构 | 向上取整函数: ceil | 获取map中所有value集合 | 指定格式日期转UNIX时间戳函数: unix_timestamp | 最小值统计函数: min | |||
| 小于等于比较: <= | 取余操作: % | create_union | 向上取整函数: ceiling | 获取map中所有key集合 | 日期时间转日期函数: to_date | 最大值统计函数: max | |||
| 大于比较: > | 位与操作: & | 取随机数函数: rand | 数组排序 | 日期转年函数: year | 非空集合总体变量函数: var_pop | ||||
| 大于等于比较: >= | 位或操作: | 自然指数函数: exp | 日期转月函数: month | 非空集合样本变量函数: var_samp | |||||
| 区间比较 | 位异或操作: ^ | 以10为底对数函数: log10 | 日期转天函数: day | 总体标准偏离函数: stddev_pop | |||||
| 空值判断: IS NULL | 位取反操作: ~ | 以2为底对数函数: log2 | 日期转小时函数: hour | 样本标准偏离函数: stddev_samp | |||||
| 非空判断: IS NOT NULL | 对数函数: log | 日期转分钟函数: minute | 中位数函数: percentile | ||||||
| LIKE比较: LIKE | 幂运算函数: pow | 日期转秒函数: second | 近似中位数函数: percentile_approx | ||||||
| JAVA的LIKE操作: RLIKE | 幂运算函数: power | 日期比较函数: datediff | 直方图: histogram_numeric | ||||||
| REGEXP操作: REGEXP | 开平方函数: sqrt | 日期增加函数: date_add | 集合去重数：collect_set |
3.2 SQL介绍与Hive应用场景
3.2.1 数据库操作和表操作
| 作用 | HiveQL |
|---|---|
| 查看所有数据库 | SHOW DATABASES; |
| 使用指定的数据库 | USE database_name; |
| 创建指定名称的数据库 | CREATE DATABASE database_name; |
| 删除数据库 | DROP DATABASE database_name; |
| 创建表 | CREATE TABLE pokes (foo INT, bar STRING) |
| 查看所有的表 | SHOW TABLES |
| 支持模糊查询 | SHOW TABLES ‘TMP’ |
| 查看表有哪些分区 | SHOW PARTITIONS TMP_TABLE |
| 查看表结构 | DESCRIBE TMP_TABLE |
| 创建表并创建索引ds | CREATE TABLE invites (foo INT, bar STRING) PARTITIONED BY (ds STRING) |
| 复制一个空表 | CREATE TABLE empty_key_value_store LIKE key_value_store |
| 表添加一列 | ALTER TABLE pokes ADD COLUMNS (new_col INT) |
| 更改表名 | ALTER TABLE events RENAME TO 3koobecaf |
3.2.2 查询语句
| 作用 | HiveQL |
|---|---|
| 检索信息 | SELECT from_columns FROM table WHERE conditions; |
| 选择所有的数据 | SELECT * FROM table; |
| 行筛选 | SELECT * FROM table WHERE rec_name = “value”; |
| 多个限制条件 | SELECT * FROM TABLE WHERE rec1 = “value1” AND rec2 = “value2”; |
| 选择多个特定的列 | SELECT column_name FROM table; |
| 检索unique输出记录 | SELECT DISTINCT column_name FROM table; |
| 排序 | SELECT col1, col2 FROM table ORDER BY col2; |
| 逆序 | SELECT col1, col2 FROM table ORDER BY col2 DESC; |
| 统计行数 | SELECT COUNT(*) FROM table; |
| 分组统计 | SELECT owner, COUNT(*) FROM table GROUP BY owner; |
| 求某一列最大值 | SELECT MAX(col_name) AS label FROM table; |
| 从多个表中检索信息 | SELECT pet.name, comment FROM pet JOIN event ON (pet.name = event.name); |
4 HIVE数据的压缩与存储格式
4.1 压缩
4.1.1 压缩概述
压缩技术能够有效减少底层存储系统（HDFS）读写字节数。压缩提高了网络带宽和磁盘空间的效率。在运行MR程序时，I/O操作、网络数据传输、 Shuffle和Merge要花大量的时间，尤其是数据规模很大和工作负载密集的情况下，因此，使用数据压缩显得非常重要。
鉴于磁盘I/O和网络带宽是Hadoop的宝贵资源，数据压缩对于节省资源、最小化磁盘I/O和网络传输非常有帮助。可以在任意MapReduce阶段启用压缩。不过，尽管压缩与解压操作的CPU开销不高，其性能的提升和资源的节省并非没有代价。
4.1.2 压缩策略与原则
压缩是提高Hadoop运行效率的一种优化策略。通过对Mapper、Reducer运行过程的数据进行压缩，以减少磁盘IO，
提高MR程序运行速度。
注意：采用压缩技术减少了磁盘IO，但同时增加了CPU运算负担。所以，压缩特性运用得当能提高性能，但运用不当也可能降低性能。
压缩基本原则：
- 运算密集型的job，少用压缩
- IO密集型的job，多用压缩
4.2 Hadoop压缩配置
4.2.1 MR支持的压缩编码
| 压缩格式 | 算法 | 文件扩展名 | 是否可切分 |
|---|---|---|---|
| DEFLATE | DEFLATE | .deflate | 否 |
| Gzip | DEFLATE | .gz | 否 |
| bzip2 | bzip2 | .bz2 | 是 |
| LZO | LZO | .lzo | 是 |
| Snappy | Snappy | .snappy | 否 |
为了支持多种压缩/解压缩算法，Hadoop引入了编码/解码器，如下表所示：
| 压缩格式 | 对应的编码/解码器 |
|---|---|
| DEFLATE | org.apache.hadoop.io.compress.DefaultCodec |
| gzip | org.apache.hadoop.io.compress.GzipCodec |
| bzip2 | org.apache.hadoop.io.compress.BZip2Codec |
| LZO | com.hadoop.compression.lzo.LzopCodec |
| Snappy | org.apache.hadoop.io.compress.SnappyCodec |
压缩性能的比较：
| 压缩算法 | 原始文件大小 | 压缩文件大小 | 压缩速度 | 解压速度 |
|---|---|---|---|---|
| gzip | 8.3GB | 1.8GB | 17.5MB/s | 58MB/s |
| bzip2 | 8.3GB | 1.1GB | 2.4MB/s | 9.5MB/s |
| LZO | 8.3GB | 2.9GB | 49.3MB/s | 74.6MB/s |
按照Hive对数据的分层，我们可以在对应层使用这样的压缩方式：
| 层级 | 压缩方式 | 原因 |
|---|---|---|
| ODS层 | zlib、gz、bz2 | 省空间 |
| DW层 | snappy | 速度快 |
| DA层 | snappy | 速度快 |
- 相关参数设置
-- 开启Map端压缩
set hive.exec.compress.intermediate=true;
set mapreduce.map.output.compress=true;
set mapreduce.map.output.compress.codec= org.apache.hadoop.io.compress.SnappyCodec;
-- 开启hive最终输出数据压缩功能
set hive.exec.compress.output=true;
-- 开启mapreduce最终输出数据压缩
set mapreduce.output.fileoutputformat.compress=true;
-- 设置mapreduce最终数据输出压缩方式
set mapreduce.output.fileoutputformat.compress.codec = org.apache.hadoop.io.compress.SnappyCodec;
-- 设置mapreduce最终数据输出压缩为块压缩
set mapreduce.output.fileoutputformat.compress.type=BLOCK;
4.2.2 压缩方式选择
4.2.2.1 Gzip压缩
优点：压缩率比较高，而且压缩/解压速度也比较快；Hadoop本身支持，在应用中处理Gzip格式的文件就和直接处理文本一样；大部分Linux系统都自带Gzip命令，使用方便。
缺点：不支持Split。
应用场景：当每个文件压缩之后在130M以内的（1个块大小内），都可以考虑用Gzip压缩格式。例如说一天或者一个小时的日志压缩成一个Gzip文件。
4.2.2.2 Bzip2压缩
优点：支持Split；具有很高的压缩率，比Gzip压缩率都高；Hadoop本身自带，使用方便。
缺点：压缩/解压速度慢。
应用场景：适合对速度要求不高，但需要较高的压缩率的时候；或者输出之后的数据比较大，处理之后的数据需要压缩存档减少磁盘空间并且以后数据用得比较少的情况；或者对单个很大的文本文件想压缩减少存储空间，同时又需要支持Split，而且兼容之前的应用程序的情况。
4.2.2.3 Lzo压缩
优点：压缩/解压速度也比较快，合理的压缩率；支持Split，是Hadoop中最流行的压缩格式；可以在Linux系统下安装lzop命令，使用方便。
缺点：压缩率比Gzip要低一些；Hadoop本身不支持，需要安装；在应用中对Lzo格式的文件需要做一些特殊处理（为了支持Split需要建索引，还需要指定InputFormat为Lzo格式）。
应用场景：一个很大的文本文件，压缩之后还大于200M以上的可以考虑，而且单个文件越大，Lzo优点越越明显。
4.2.2.4 Snappy压缩
优点：高速压缩速度和合理的压缩率。
缺点：不支持Split；压缩率比Gzip要低；Hadoop本身不支持，需要安装。
应用场景：当MapReduce作业的Map输出的数据比较大的时候，作为Map到Reduce的中间数据的压缩格式；或者作为一个MapReduce作业的输出和另外一个MapReduce作业的输入。
4.2.3 压缩参数配置
要在Hadoop中启用压缩，可以配置如下参数（mapred-site.xml文件中）：
| 参数 | 默认值 | 阶段 | 建议 |
|---|---|---|---|
| io.compression.codecs （在core-site.xml中配置） | org.apache.hadoop.io.compress.DefaultCodec, org.apache.hadoop.io.compress.GzipCodec, org.apache.hadoop.io.compress.BZip2Codec, org.apache.hadoop.io.compress.Lz4Codec | 输入压缩 | Hadoop使用文件扩展名判断是否支持某种编解码器 |
| mapreduce.map.output.compress | false | mapper输出 | 这个参数设为true启用压缩 |
| mapreduce.map.output.compress.codec | org.apache.hadoop.io.compress.DefaultCodec | mapper输出 | 使用LZO、LZ4或snappy编解码器在此阶段压缩数据 |
| mapreduce.output.fileoutputformat.compress | false | reducer输出 | 这个参数设为true启用压缩 |
| mapreduce.output.fileoutputformat.compress.codec | org.apache.hadoop.io.compress. DefaultCodec | reducer输出 | 使用标准工具或者编解码器，如gzip和bzip2 |
| mapreduce.output.fileoutputformat.compress.type | RECORD | reducer输出 | SequenceFile输出使用的压缩类型：NONE和BLOCK |
4.3 开启Map输出阶段压缩
开启map输出阶段压缩可以减少job中map和Reduce task间数据传输量。具体配置如下：
- 开启hive中间传输数据压缩功能
hive (default)>set hive.exec.compress.intermediate=true;
- 开启mapreduce中map输出压缩功能
hive (default)>set mapreduce.map.output.compress=true;
- 设置mapreduce中map输出数据的压缩方式
hive (default)>set mapreduce.map.output.compress.codec=
org.apache.hadoop.io.compress.SnappyCodec;
- 执行查询语句
hive (default)> select count(ename) name from emp;
4.4 开启Reduce输出阶段压缩
当Hive将输出写入到表中时，输出内容同样可以进行压缩。属性hive.exec.compress.output控制着这个功能。用户可能需要保持默认设置文件中的默认值false，这样默认的输出就是非压缩的纯文本文件了。用户可以通过在查询语句或执行脚本中设置这个值为true，来开启输出结果压缩功能。
-
开启hive最终输出数据压缩功能
hive (default)>set hive.exec.compress.output=true; -
开启mapreduce最终输出数据压缩
hive (default)>set mapreduce.output.fileoutputformat.compress=true; -
设置mapreduce最终数据输出压缩方式
hive (default)> set mapreduce.output.fileoutputformat.compress.codec = org.apache.hadoop.io.compress.SnappyCodec; -
设置mapreduce最终数据输出压缩为块压缩
hive (default)> set mapreduce.output.fileoutputformat.compress.type=BLOCK; -
测试一下输出结果是否是压缩文件
hive (default)> insert overwrite local directory '/opt/module/hive/datas/distribute-result' select * from emp distribute by deptno sort by empno desc;
4.5 文件存储格式
Hive支持的存储数据的格式主要有：TEXTFILE 、SEQUENCEFILE、ORC、PARQUET。（前两个行存，后两个列存）
4.5.1 列式存储和行式存储
如图所示，左边为逻辑表，右边是底层存储格式，其中第一个为行式存储，第二个为列式存储。
-
行存储的特点
查询满足条件的一整行数据的时候，列存储则需要去每个聚集的字段找到对应的每个列的值，行存储只需要找到其中一个值，其余的值都在相邻地方，所以此时行存储查询的速度更快。
-
列存储的特点
因为每个字段的数据聚集存储，在查询只需要少数几个字段的时候，能大大减少读取的数据量；每个字段的数据类型一定是相同的，列式存储可以针对性的设计更好的设计压缩算法。
4.5.2 TextFile格式
默认格式，数据不做压缩，磁盘开销大，数据解析开销大。可结合Gzip、Bzip2使用，但使用Gzip这种方式，hive不会对数据进行切分，从而无法对数据进行并行操作。
4.5.3 Orc格式
Orc (Optimized Row Columnar)是Hive 0.11版里引入的新的存储格式。
如下图所示可以看到每个Orc文件由1个或多个stripe组成，每个stripe一般为HDFS的块大小，每一个stripe包含多条记录，这些记录按照列进行独立存储，对应到Parquet中的row group的概念。每个Stripe里有三部分组成，分别是Index Data，Row Data，Stripe Footer：
- Index Data：一个轻量级的index，默认是每隔1W行做一个索引。这里做的索引应该只是记录某行的各字段在Row Data中的offset。
- Row Data：存的是具体的数据，先取部分行，然后对这些行按列进行存储。对每个列进行了编码，分成多个Stream来存储。
- Stripe Footer：存的是各个Stream的类型，长度等信息。
每个文件有一个File Footer，这里面存的是每个Stripe的行数，每个Column的数据类型信息等；每个文件的尾部是一个PostScript，这里面记录了整个文件的压缩类型以及FileFooter的长度信息等。在读取文件时，会seek到文件尾部读PostScript，从里面解析到FileFooter长度，再读FileFooter，从里面解析到各个Stripe信息，再读各个Stripe，即从后往前读。
4.5.4 Parquet格式
Parquet文件是以二进制方式存储的，所以是不可以直接读取的，文件中包括该文件的数据和元数据，因此Parquet格式文件是自解析的。
- 行组(Row Group)：每一个行组包含一定的行数，在一个HDFS文件中至少存储一个行组，类似于orc的stripe的概念。
- 列块(Column Chunk)：在一个行组中每一列保存在一个列块中，行组中的所有列连续的存储在这个行组文件中。一个列块中的值都是相同类型的，不同的列块可能使用不同的算法进行压缩。
- 页(Page)：每一个列块划分为多个页，一个页是最小的编码的单位，在同一个列块的不同页可能使用不同的编码方式。
通常情况下，在存储Parquet数据的时候会按照Block大小设置行组的大小，由于一般情况下每一个Mapper任务处理数据的最小单位是一个Block，这样可以把每一个行组由一个Mapper任务处理，增大任务执行并行度。Parquet文件的格式。
上图展示了一个Parquet文件的内容，一个文件中可以存储多个行组，文件的首位都是该文件的Magic Code，用于校验它是否是一个Parquet文件，Footer length记录了文件元数据的大小，通过该值和文件长度可以计算出元数据的偏移量，文件的元数据中包括每一个行组的元数据信息和该文件存储数据的Schema信息。除了文件中每一个行组的元数据，每一页的开始都会存储该页的元数据，在Parquet中，有三种类型的页：数据页、字典页和索引页。数据页用于存储当前行组中该列的值，字典页存储该列值的编码字典，每一个列块中最多包含一个字典页，索引页用来存储当前行组下该列的索引，目前Parquet中还不支持索引页。
4.5.5 主流文件存储格式对比实验
log.data文件下载
链接：https://pan.baidu.com/s/1fvnZ29iMZqRtrdzy5JoAQg
提取码：9wi0
- TextFile
-- 创建表，存储数据格式为TEXTFILE
create table log_text (
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
)
row format delimited fields terminated by '\\t'
stored as textfile;
-- 向表中加载数据
hive (default)> load data local inpath '/opt/module/hive/datas/log.data' into table log_text ;
-- 查看表中数据大小
hive (default)> dfs -du -h /user/hive/warehouse/log_text;
- ORC
-- 创建表，存储数据格式为ORC
create table log_orc(
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
)
row format delimited fields terminated by '\\t'
stored as orc
tblproperties("orc.compress"="NONE"); -- 设置orc存储不使用压缩
-- 向表中加载数据（直接load会报编码格式不匹配的错误）
hive (default)> insert into table log_orc select * from log_text ;
-- 查看表中数据大小
hive (default)> dfs -du -h /user/hive/warehouse/log_orc/ ;
- Parquet
-- 创建表，存储数据格式为parquet
create table log_parquet(
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
)
row format delimited fields terminated by '\\t'
stored as parquet ;
-- 向表中加载数据
hive (default)> insert into table log_parquet select * from log_text;
-- 查看表中数据大小
hive (default)> dfs -du -h /user/hive/warehouse/log_parquet/;
TextFile：18.13 MB->18.13 MB，time: 0.504 s
ORC：18.13 MB->7.69 MB，time: 4.698 s
Parquet：18.13MB->13.09 MB，time: 5.506 s
4.5.6 存储和压缩结合
- ZLIB压缩的ORC存储方式
-- 建表
create table log_orc_zlib(
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
)
row format delimited fields terminated by '\\t'
stored as orc
tblproperties("orc.compress"="ZLIB");
-- 导数据
insert into log_orc_zlib select * from log_text;
- 创建一个SNAPPY压缩的ORC存储方式
-- 建表
create table log_orc_snappy(
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
)
row format delimited fields terminated by '\\t'
stored as orc
tblproperties("orc.compress"="SNAPPY");
-- 导数据
insert into log_orc_snappy select * from log_text;
- 创建一个SNAPPY压缩的parquet存储方式
-- 建表
create table log_parquet_snappy(
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
)
row format delimited fields terminated by '\\t'
stored as parquet
tblproperties("parquet.compression"="SNAPPY");
-- 导数据
insert into log_parquet_snappy select * from log_text;
ORC_ZLIB：18.13 MB->2.78 MB，time: 4.949 s
ORC_SNAPPY：18.13 MB->3.75 MB，time: 3.87 s
Parquet_SNAPPY：18.13MB->6.07 MB，time: 3.877 s
5 Hive和HBase区别
5.1 Hive
1.Hive是hadoop数据仓库管理工具，严格来说，不是数据库，本身是不存储数据和处理数据的，其依赖于HDFS存储数据，依赖于MapReducer进行数据处理。
2.Hive的优点是学习成本低，可以通过类SQL语句（HSQL）快速实现简单的MR任务，不必开发专门的MR程序。
3.由于Hive是依赖于MapReducer处理数据的，因此有很高的延迟性，不适用于实时数据处理（数据查询，数据插入，数据分析），适用于离线数据的批处理。
5.2 HBase
1.HBase是一种分布式、可扩展、支持海量数据存储的NOSQL数据库
2.HBase主要适用于海量数据的实时数据处理（随机读写）
3.由于HDFS不支持随机读写，而HBase正是为此而诞生的，弥补了HDFS的不可随机读写。
5.3 共同点
hbase与hive都是架构在hadoop之上的。都是用HDFS作为底层存储。
Hbase主要解决实时数据查询问题，Hive主要解决数据处理和计算问题，一般是配合使用。
5.4 区别
-
Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统，HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。总的来说，hive是适用于离线数据的批处理，hbase是适用于实时数据的处理。
-
Hive本身不存储和计算数据，它完全依赖于HDFS存储数据和MapReduce处理数据，Hive中的表纯逻辑。
-
Hive：Hive是Hadoop数据仓库，严格来说，不是数据库，主要是让开发人员能够通过SQL来计算和处理HDFS上的结构化数据，适用于离线的批量数据计算。
- 通过元数据来描述Hdfs上的结构化文本数据，通俗点来说，就是定义一张表来描述HDFS上的结构化文本，包括各列数据名称，数据类型是什么等，方便我们处理数据，当前很多SQL ON Hadoop的计算引擎均用的是hive的元数据，如Spark SQL、Impala等；
- 基于第一点，通过SQL来处理和计算HDFS的数据，Hive会将SQL翻译为Mapreduce来处理数据；
-
hbase是物理表，不是逻辑表，提供一个超大的内存hash表，搜索引擎通过它来存储索引，方便查询操作。
-
Hbase：Hadoop database 的简称，也就是基于Hadoop数据库，是一种NoSQL数据库，主要适用于海量明细数据（十亿、百亿）的随机实时查询，如日志明细、交易清单、轨迹行为等。
-
.由于HDFS的不可随机读写，hive是不支持随机写操作，而hbase支持随机写入操作。
-
HBase只支持简单的键查询，不支持复杂的条件查询
5.5 关系说明一
在大数据架构中，Hive和HBase是协作关系，这里就举例一种常用的协作关系，具体流程如下图：
流程：
1.Hive创建一张外部表与HBase表关联，因此只需对Hive表进行查询即可，Hive表会自动从关联的HBase表中获取数据
2.采集的数据保存到HBase表，因为HBase表支持随机写操作，这个可以根据业务需求决定
3.Hive通过HSQ语句创建MR任务去处理分析数据
3.MR将分析的结果最终存储到常用的数据库（Mysql数据库）
4.web端从数据库获取数据进行可视化
5.6 关系说明二
在大数据架构中，Hive和HBase是协作关系，数据流一般如下图：
- 通过ETL工具将数据源抽取到HDFS存储；
- 通过Hive清洗、处理和计算原始数据；
- HIve清洗处理后的结果，如果是面向海量数据随机查询场景的可存入Hbase
- 数据应用从HBase查询数据；
6 Hive优化
6.1 Hive优化缘由
首先，我们来看看Hadoop的计算框架特性，在此特性下会衍生哪些问题？
- 数据量大不是问题，数据倾斜是个问题。
- jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，耗时很长。原因是map reduce作业初始化的时间是比较长的。
- sum,count,max,min等UDAF，不怕数据倾斜问题,hadoop在map端的汇总合并优化，使数据倾斜不成问题。
- count(distinct ),在数据量大的情况下，效率较低，如果是多count(distinct )效率更低，因为count(distinct)是按group by 字段分组，按distinct字段排序，一般这种分布方式是很倾斜的。举个例子：比如男uv,女uv，像淘宝一天30亿的pv，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。
面对这些问题，我们能有哪些有效的优化手段呢？下面列出一些在工作有效可行的优化手段：
- 好的模型设计事半功倍。
- 解决数据倾斜问题。
- 减少job数。
- 设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。
- 了解数据分布，自己动手解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据倾斜问题。
- 数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题。
- 对小文件进行合并，是行至有效的提高调度效率的方法，假如所有的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的正向影响。
- 优化时把握整体，单个作业最优不如整体最优。
而接下来，我们心中应该会有一些疑问，影响性能的根源是什么？
6.2 性能低下的根源
hive性能优化时，把HiveQL当做M/R程序来读，即从M/R的运行角度来考虑优化性能，从更底层思考如何优化运算性能，而不仅仅局限于逻辑代码的替换层面。
RAC（Real Application Cluster）真正应用集群就像一辆机动灵活的小货车，响应快；Hadoop就像吞吐量巨大的轮船，启动开销大，如果每次只做小数量的输入输出，利用率将会很低。所
以上是关于Hive大数据开发的主要内容，如果未能解决你的问题，请参考以下文章