1. Hive建表中ORC格式的使用
refer:https://blog.csdn.net/longshenlmj/article/details/51702343
#Hive建外部External表（外部表external table）：
#
#添加分区并加载分区数据：
alter table table_name add partition (proc_date='${hivevar:pdate}') location '...'（不改变源数据存储位置）
alter table table_name add if not exsit partition (proc_date='${hivevar:pdate}') location 'hdfs://hdfscluster/'
load data inpath '...' into table table_name partition(proc_date='${hivevar:pdate}');（会将源数据切到hive表指定的路径下）
#删除分区： alter table table_name drop if exists partition(proc_date='${hivevar:pdate}');
#TBLPROPERTIES
实际上就是table properties,TBLPROPERTIES允许开发者定义一些自己的键值对信息。可以对TBLPROPERTIES进行查看和修改（部分可修改）。在TBLPROPERTIES中有一些预定义信息，比如last_modified_user和last_modified_time，其他的一些预定义信息包括：
#tplproperties属性参考
（1）comment:可以用来定义表的描述信息。
（2）hbase.table.name：hive通过 storage handler（暂放）将hive与各种工具联系起来，这是是使用hive接入hbase时，设置的属性（暂放）。
（3）immutable：顾名思义‘不可变的’，当表的这个属性为true时，若表中无数据时可以insert数据，但是当表已经有数据时，insert操作会失败。不可变表用来防止意外更新，避免因脚本错误导致的多次更新，而没有报错。本人实际中还没用到这个属性。
（4）orc.compress：这是orc存储格式表的一个属性，用来指定orc存储的压缩方式（暂放）。
（5） transactional，NO_AUTO_COMPACTION，compactor.maprece.map.memory.mb，compactorthreshold.hive.compactor.delta.num.threshold，compactorthreshold.hive.compactor.delta.pct.threshold：这5个属性与hive的事务支持有关，先不做了解。
（6）auto.purge：当设置为ture时，删除或者覆盖的数据会不经过回收站，直接被删除。配置了此属性会影响到这些操作： Drop Table, Drop Partitions, Truncate Table,Insert Overwrite。
（7）EXTERNAL：通过修改此属性可以实现内部表和外部表的转化。
#
2. 5种让Hive查询变快的方法
在过去几年中，主要受到围绕Stinger计划的Hive社区创新的推动，Hive查询时间得到了显着改善，使Hive能够以速度和规模支持批量和交互式工作负载。
但是，许多使用者仍然不熟悉以最快速度运行Hive查询的基本技术和最佳实践。本文中，将重点介绍一些常使用的简单技术，以提高HIVE查询的性能。
Hive可以使用Apache Tez执行引擎而不是Map-rece引擎。不会详细介绍这里提到的使用Tez的许多好处; 相反，提出一个简单的建议：如果在您的环境中默认情况下没有打开它，请在Hive查询的开头使用Tez设置为“true”
Hive支持ORCfile，这是一种新的表存储格式，通过谓词下推，压缩等技术实现极佳的速度提升。
对每个HIVE表使用ORCFile应该是一个明智的选择，对于获得HIVE查询的快速响应时间非常有益。
作为一个例子，考虑两个大表A和B（存储为文本文件，这里没有指定一些列），以及一个简单的查询 :
此查询可能需要很长时间才能执行，因为表A和B都存储为TEXT。将这些表转换为ORCFile格式通常会显着缩短查询时间：
ORC支持压缩存储（使用ZLIB或如上所示使用SNAPPY），但也支持未压缩存储。
将基表转换为ORC通常是取决于所在团队获取数据的职责，由于其他优先级，可能需要一些时间来更改完整的获取数据过程。ORCFile的好处是如此明显，以至于推荐如上所示的自助式方法 - 将A转换为A_ORC，将B转换为B_ORC并以此方式进行连接，以便立即从更快的查询中受益，而不依赖于其他团队。
矢量化查询执行通过一次批量执行1024行而不是每行一行来提高扫描，聚合，过滤器和连接等操作的性能。
这个功能在Hive 0.13中引入，显着缩短了查询执行时间，并且可以通过两个参数设置轻松启用：
在提交最终执行之前，Hive会优化每个查询的逻辑和物理执行计划。这些优化不是基于查询的成本 - 也就是说，直到运行时。
最近添加到Hive，基于成本的优化，基于查询成本执行进一步优化，从而导致可能不同的决策：如何订购联接，执行哪种类型的联接，并行度等。
要使用基于成本的优化（也称为CBO），请在查询开头设置以下参数
然后，通过运行Hive的“analyze”命令为CBO准备数据，以收集我们想要使用CBO的表的各种统计信息。
例如，在tweet数据表中，希望收集有关该表的统计信息以及大约2列：“sender”和“topic”：
使用HIVE 0.14（在HDP 2.2上），analyze命令的工作速度要快得多，而且您不需要指定每一列，因此只需如下：
现在使用此表执行查询应该会导致不同的执行计划由于成本计算和Hive创建的不同执行计划而更快。
SQL是一种强大的声明性语言。与其他声明性语言一样，编写SQL语句的方法不止一种。尽管每个语句的功能都相同，但它可能具有截然不同的性能特征
每条记录代表一次点击事件，希望找到每个sessionID的最新网址。
有人使用如下方式：
在上面的查询中，构建一个子查询来收集每个会话中最新事件的时间戳，然后使用内部联接来过滤掉其余的事件。
虽然查询是一个合理的解决方案 - 从功能的角度来看 - 事实证明，有一种更好的方法来重写这个查询，如下所示
在这里，使用Hive的OLAP功能（OVER和RANK）来实现相同的功能，但没有使用表连接。
显然，删除不必要的连接几乎总能带来更好的性能，而且当使用大数据时，这比以往任何时候都更重要。在很多情况下查询不是最优的 - 所以仔细查看每个查询并考虑重写是否可以使它更好更快。
更多内容信息 https://blue-shadow.top
3. hive查询时间复杂度
1、使用Tez引擎
Apache Tez Engine是一个可扩展的框架，用于构建高性能批处理和交互式数据处理。它由YARN在Hadoop中 调度。Tez通过提高处理速度和保持MapRece扩展到数PB数据的能力来改进MapRece job。
通过设置hive.execution.engine 为tez：可以在环境中启用Tez引擎：
set hive.execution.engine=tez;
2、使用向量化
向量化通过在单个操作中获取 1024 行而不是 每次只获取单行来改善 scans, aggregations, filters 和 join 这类操作的性能。
我们可以通过执行以下命令在环境中启用向量化：
set hive.vectorized.execution.enabled=true;
set hive.vectorized.execution.rece.enabled=true;
3、使用ORCFile
Hive 支持 ORCfile，这是一种新的表存储格式，在读取，写入和处理数据时，ORCFile格式优于Hive文件格式，它通过 predicate push-down, compression 等技术来提高查询速度。
在 HIVE 表中使用 ORCFile，将有益于获得 HIVE 快速响应的查询。
ORCFile 格式通过对原始数据存储量压缩75％，提供了高效的存储 Hive 数据的方法。
举例，考虑两个大表 A 和 B（存储为 TextFIle，这里没有指定一些列），使用一个简单的查询，如：
SELECT A.customerID,
A.name,
A.age,
A.address
JOIN B.role,
B.department,
B.salary ON A.customerID=B.customerID;
由于表 A 和表 B 都存储为 TextFile，因此执行此查询可能需要很长时间。
将这些表存储格式转换为 ORCFile 格式通常会明显减少查询时间：
CREATE TABLE A_ORC (
customerID int,
name string,
age int,
address string
) STORED AS ORC tblproperties (“orc.compress" = “SNAPPY”)
;
INSERT INTO TABLE A_ORC
SELECT *
FROM A
;
CREATE TABLE B_ORC (
customerID int,
ROLE string,
salary float,
department string
) STORED AS ORC tblproperties (“orc.compress" = “SNAPPY”)
;
INSERT INTO TABLE B_ORC
SELECT *
FROM B
;
SELECT A_ORC.customerID,
A_ORC.name,
A_ORC.age,
A_ORC.address
JOIN B_ORC.role,
B_ORC.department,
B_ORC.salary ON A_ORC.customerID=B_ORC.customerID
;
ORC 支持压缩存储（使用 ZLIB 或如上所示使用 SNAPPY），但也支持不压缩存储。
4、使用分区
通过分区，数据存储在 HDFS 上的单独单个文件夹中。Hive 将查询分区数据集，而不是 扫描表的所有数据集。
创建临时表并将数据加载到临时表中
CREATE TABLE Employee_Temp(
EmloyeeID int,
EmployeeName Varchar(100),
Address Varchar(100),
STATE Varchar(100),
City Varchar(100),
Zipcode Varchar(100)
) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE;
LOAD DATA INPATH '/home/hadoop/hive' INTO TABLE Employee_Temp;
创建分区表
Create Table Employee_Part(
EmloyeeID int,
EmployeeName Varchar(100),
Address Varchar(100),
State Varchar(100),
Zipcode Varchar(100))
PARTITIONED BY (City Varchar(100))
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
STORED AS TEXTFILE;
启用动态分区的命令
SET hive.exec.dynamic.partition = true;
SET hive.exec.dynamic.partition.mode = nonstrict;
从临时表导入数据到分区表
INSERT Overwrite TABLE Employee_Part Partition(City)
SELECT EmployeeID,
EmployeeName,
Address,
STATE,
City,
Zipcode
FROM Emloyee_Temp;
5、使用 分桶
桶表介绍：https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL+BucketedTables
举例：https://blog.csdn.net/m0_37534613/article/details/55258928
Hive 表被划分为多个分区，称为 Hive分区。Hive分区进一步细分为集群或桶，称为 bucket 或 Cluster。
Create Table Employee_Part(
EmloyeeID int,
EmployeeName Varchar(100),
Address Varchar(100),
State Varchar(100),
Zipcode Varchar(100))
PARTITIONED BY (City Varchar(100))
Clustered By (EmployeeID) into 20 Buckets
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
STORED AS TEXTFILE;
6、CBO 查询优化器
Hive CBO 是使用 Apache calcite 来处理的。
早期的 Hive 版本中（Hive-0.14 之前），在提交最终执行之前，Hive 会优化每个查询的逻辑和物理执行计划。 这些优化不是基于查询的成本优化(Cost-based Optimizer) 。
直到 Hive-0.14 时才添加了 Cost-based optimization ，这时已经根据查询的成本进行优化（例如要执行的连接类型，如何排序连接，并行度等）。
要使用基于成本的优化，需要在查询开头设置以下参数
set hive.cbo.enable=true;
set hive.compute.query.using.stats=true;
set hive.stats.fetch.column.stats=true;
set hive.stats.fetch.partition.stats=true;
如果要收集表信息，请使用 Analyze 命令。
7、写好的 SQL
SQL是一种强大的声明性语言。 与其他声明性语言一样，编写SQL语句的方法不止一种。
尽管每个语句的功能都相同，但它可能具有截然不同的性能特征。
我们来看一个例子。 考虑点击流事件表：
CREATE TABLE clicks (
timestamp date, sessionID string, url string, source_ip string
) STORED as ORC tblproperties (“orc.compress” = “SNAPPY”);
每条记录代表一次点击事件，我们希望找到每个sessionID的最新网址。
有人可能会考虑以下方法：
SELECT clicks.* FROM clicks inner join
(select sessionID, max(timestamp) as max_ts from clicks
group by sessionID) latest
ON clicks.sessionID = latest.sessionID and
clicks.timestamp = latest.max_ts;
在上面的查询中，我们构建一个子查询来收集每个会话中最新事件的时间戳，然后使用 内联接 来过滤掉其余的事件。
虽然查询是一个合理的解决方案， 但是从功能的角度来看 ，有一种更好的方法来重写这个查询，如下所示：
SELECT * FROM
(SELECT *, RANK() over (partition by sessionID,
order by timestamp desc) as rank
FROM clicks) ranked_clicks
WHERE ranked_clicks.rank=1;
在这里，我们使用 Hive 的 OLAP 窗口功能（OVER 和 RANK）来实现相同的功能。
显然，删除不必要的连接几乎总能带来更好的性能，而且当使用大数据时，这比以往任何时候都更重要。
我发现很多情况下查询不是最优的 - 所以仔细查看每个查询并考虑重写是否可以使它更好更快。
————————————————
版权声明：本文为CSDN博主“highfei2011”的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/high2011/article/details/96271903
4. ORC文件格式
一、ORC文件格式
ORC文件也是以二进制方式存储的，所以是不可以直接读取，ORC文件也是自解析的，它包含许多的元数据，这些元数据都是同构ProtoBuffer进行序列化的。ORC的文件结构如下图
在ORC文件中保存了三个层级的统计信息，分别为 文件级别、stripe级别和row group 级别的，他们都可以用来根据Search ARGuments（ 谓词下推条件 ）判断是否可以跳过某些数据，在统计信息中都包含成员数和是否有null值，并且对于不同类型的数据设置一些特定的统计信息。
（1）file level
在ORC文件的末尾会记录文件级别的统计信息，会记录整个文件中columns的统计信息。这些信息主要用于查询的优化，也可以为一些简单的聚合查询比如max, min, sum输出结果。
（2）stripe level
ORC文件会保存每个字段stripe级别的统计信息，ORC reader使用这些统计信息来确定对于一个查询语句来说，需要读入哪些stripe中的记录。比如说某个stripe的字段max(a)=10，min(a)=3，那么当where条件为a >10或者a <3时，那么这个stripe中的所有记录在查询语句执行时不会被读入。
（3）row level
为了进一步的避免读入不必要的数据，在逻辑上将一个 column的index以一个给定的值(默认为10000，可由参数配置)分割为多个index组（也就是对每一列的分组数据建立索引，这样能近一步减少不必要的查询） 。以10000条记录为一个组，对数据进行统计（比如min,max等）。Hive查询引擎会将where条件中的约束传递给ORC reader，这些reader根据组级别的统计信息，过滤掉不必要的数据。如果该值设置的太小，就会保存更多的统计信息，用户需要根据自己数据的特点权衡一个合理的值
详细参考：https://www.cnblogs.com/ittangtang/p/7677912.html
5. Hive数据的序列化格式
1. TextFile
Hive数据表的默认格式，存储方式：行存储。
可使用Gzip,Bzip2等压缩算法压缩,压缩后的文件不支持split。
但在反序列化过程中，必须逐个字符判断是不是分隔符和行结束符，因此反序列化开销会比SequenceFile高几十倍。
2. SequenceFile
Hadoop API提供的一种二进制文件，以的形式序列化到文件中，存储方式：行存储。
支持三种压缩选择：NONE，RECORD，BLOCK。
Record压缩率低，一般建议使用BLOCK压缩。
优势是文件和hadoop api中的MapFile是相互兼容的。
3. RCFile
存储方式：数据按行分块，每块按列存储。结合了行存储和列存储的优点：
首先，RCFile 保证同一行的数据位于同一节点，因此元组重构的开销很低；
其次，像列存储一样，RCFile 能够利用列维度的数据压缩，并且能跳过不必要的列读取；
RCFile的一个行组包括三个部分：
第一部分是行组头部的【同步标识】，主要用于分隔 hdfs 块中的两个连续行组
第二部分是行组的【元数据头部】，用于存储行组单元的信息，包括行组中的记录数、每个列的字节数、列中每个域的字节数
第三部分是【表格数据段】，即实际的列存储数据。在该部分中，同一列的所有域顺序存储。
从图可以看出，首先存储了列 A 的所有域，然后存储列 B 的所有域等。
数据追加：RCFile 不支持任意方式的数据写操作，仅提供一种追加接口，这是因为底层的 HDFS当前仅仅支持数据追加写文件尾部。
行组大小：行组变大有助于提高数据压缩的效率，但是可能会损害数据的读取性能，因为这样增加了 Lazy 解压性能的消耗。而且行组变大会占用更多的内存，这会影响并发执行的其他MR作业。 考虑到存储空间和查询效率两个方面，Facebook 选择 4MB 作为默认的行组大小，当然也允许用户自行选择参数进行配置。
4. ORCFile
存储方式：数据按行分块 每块按照列存储
压缩快 快速列存取
效率比rcfile高,是rcfile的改良版本
5. 自定义格式
用户可以通过实现inputformat和 outputformat来自定义输入输出格式。
6. 总结：
数据仓库的特点：一次写入、多次读取，因此，整体来看， ORCFile 相比其他格式具有较明显的优势。
TextFile 默认格式，加载速度最快，可以采用Gzip、bzip2等进行压缩，压缩后的文件无法split，即并行处理
SequenceFile 压缩率最低，查询速度一般，三种压缩格式NONE，RECORD，BLOCK
RCfile 压缩率最高，查询速度最快，数据加载最慢。
#
6. 为什么大数据存储都喜欢使用 ORC 格式，因为快，小
ORC File，它的全名是Optimized Row Columnar (ORC) file，其实就是对RCFile做了一些优化。据官方文档介绍，这种文件格式可以提供一种高效的方法来存储Hive数据。它的设计目标是来克服Hive其他格式的缺陷。运用ORC File可以提高Hive的读、写以及处理数据的性能。
在工作中，用的最多的地方是在 Hive 中。我们的数据存储格式使用的 ORC 。
存储数据除了考虑安全性， 所占空间 以及 查询效率 是直接关系到我们的业务的。数据量不压缩，对于大数据团队来说，集群的磁盘很容易不够用。数据存进去，我们是要用的，业务方提了一个小需求，你的任务跑了大半个小时，显然也是不合理的。
这些问题都可以解决掉，但并不是完全解决。
如果我的文章对您有帮助，欢迎关注、转发。您的支持就是我更新的最大动力。
7. Hive insert 字段表错位踩坑
往 Hive 表 insert 数据后，查询时出现个别行字段错位，插入语句如下：
首先测试源表数据查询：
查询来的数据没发现有什么异常；照理说逐字段查出来没问题，再逐字段插入应该不会错位。实际上 hive 的 insert 跟想象中传统的 insert 不太一样。
由于不是全表错位，而是个别行错位，首先根据关键字查询 hive 错位那行数据，导出文本到本地。肉眼查看发现有部分"乱码"(异常字符: ^M ，如果经验丰富一眼就能看出这个是 \001 ，vim 下可以通过组合键 ctrl + a 输出），怀疑是异常字符导致，通过 linux od 命令查看 16 进制编码，如图所示：有好几个 \001 ，多么眼熟的数字啊 - 这是 hive 默认字段分隔符。
一般 insert A from select B 我们没有关注 A 表的字段分隔符，看到 \001 直觉跟 A 表的字段分隔符有关：
查看 A 的表结构，字段分隔符默认的 \001 。存储类型： textfile 。
进一步分析：textfile 是 hive 默认的存储结构，行存储，存储的实际数据结构跟表逻辑结构一致。导入数据时会直接把数据文件拷贝到 hdfs上不进行处理。源文件可以直接通过hadoop fs -cat 查看； 例如 text 字段分隔符: \001 , 换行符: \n，表在 hdfs 实际存储的格式为：
v1\001v2\001v3\n
v4\001v5\001v5
猜测字段值缺失错位的根源在于：文本中的不可见字符 \001 插入到表中，而表以 \001 作为字段分隔符，导致查询字段错位。
再来看这条 SQL：
我们可以还原这条 SQL 从插入到查询异常的全流程:
第一种方式可行且更加合理；
第二种方式可行，一种补救方案，但是 orc 等格式不支持 load 操作
第三种方式临时解决问题，不能根本上解决问题；
对 hive 的基础知识了解不足，导致问题出现排查速度较慢。
数据源头进行必要的数据 ETL 清洗，对字段分隔符的处理必须谨慎。
Hive 表尽可能使用 orc parquet 这类存储方式，空间占用，查询效率相对 textfile 有大幅提升，同时可以规避字段分隔符，错位等问题。
更深入一步 了解 hive orc 这类存储方式实现原理。
8. hive的几种文件格式
hive文件存储格式包括以下几类：
1、TEXTFILE
2、SEQUENCEFILE
3、RCFILE
4、ORCFILE(0.11以后出现)
其中TEXTFILE为默认格式，建表时不指定默认为这个格式，导入数据时会直接把数据文件拷贝到hdfs上不进行处理；
SEQUENCEFILE，RCFILE，ORCFILE格式的表不能直接从本地文件导入数据，数据要先导入到textfile格式的表中， 然后再从表中用insert导入SequenceFile,RCFile,ORCFile表中。
前提创建环境：
hive 0.8
创建一张testfile_table表，格式为textfile。
create table if not exists testfile_table( site string, url string, pv bigint, label string) row format delimited fields terminated by ' ' stored as textfile;
load data local inpath '/app/weibo.txt' overwrite into table textfile_table;
一、TEXTFILE
默认格式，数据不做压缩，磁盘开销大，数据解析开销大。
可结合Gzip、Bzip2使用(系统自动检查，执行查询时自动解压)，但使用这种方式，hive不会对数据进行切分，
从而无法对数据进行并行操作。
示例：
总结:
相比TEXTFILE和SEQUENCEFILE，RCFILE由于列式存储方式，数据加载时性能消耗较大，但是具有较好的压缩比和查询响应。数据仓库的特点是一次写入、多次读取，因此，整体来看，RCFILE相比其余两种格式具有较明显的优势。
9. Hive优化之Hive的配置参数优化
Hive是大数据领域常用的组件之一，主要用于大数据离线数仓的运算，关于Hive的性能调优在日常工作和面试中是经常涉及的一个点，因此掌握一些Hive调优是必不可少的一项技能。影响Hive效率的主要因素有数据倾斜、数据冗余、job的IO以及不同底层引擎配置情况和Hive本身参数和HiveSQL的执行等。本文主要从建表配置参数方面对Hive优化进行讲解。
1. 创建一个普通表
table test_user1(id int, name string,code string,code_id string ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',';
2. 查看这张表的信息
DESCRIBE FORMATTED test_user1;
我们从该表的描述信息介绍建表时的一些可优化点。
2.1 表的文件数
numFiles表示表中含有的文件数，当文件数过多时可能意味着该表的小文件过多，这时候我们可以针对小文件的问题进行一些优化，HDFS本身提供了解决方案：
（1）Hadoop Archive/HAR：将小文件打包成大文件。
（2）SEQUENCEFILE格式：将大量小文件压缩成一个SEQUENCEFILE文件。
（3）CombineFileInputFormat：在map和rece处理之前组合小文件。
（4）HDFS Federation：HDFS联盟，使用多个namenode节点管理文件。
除此之外，我们还可以通过设置hive的参数来合并小文件。
（1）输入阶段合并
需要更改Hive的输入文件格式，即参数hive.input.format，默认值是org.apache.hadoop.hive.ql.io.HiveInputFormat，我们改成org.apache.hadoop.hive.ql.io.CombineHiveInputFormat。这样比起上面对mapper数的调整，会多出两个参数，分别是mapred.min.split.size.per.node和mapred.min.split.size.per.rack，含义是单节点和单机架上的最小split大小。如果发现有split大小小于这两个值（默认都是100MB），则会进行合并。具体逻辑可以参看Hive源码中的对应类。
（2）输出阶段合并
直接将hive.merge.mapfiles和hive.merge.mapredfiles都设为true即可，前者表示将map-only任务的输出合并，后者表示将map-rece任务的输出合并，Hive会额外启动一个mr作业将输出的小文件合并成大文件。另外，hive.merge.size.per.task可以指定每个task输出后合并文件大小的期望值，hive.merge.size.smallfiles.avgsize可以指定所有输出文件大小的均值阈值，默认值都是1GB。如果平均大小不足的话，就会另外启动一个任务来进行合并。
2.2 表的存储格式
通过InputFormat和OutputFormat可以看出表的存储格式是TEXT类型，Hive支持TEXTFILE, SEQUENCEFILE, AVRO, RCFILE, ORC,以及PARQUET文件格式，可以通过两种方式指定表的文件格式：
（1）CREATE TABLE ... STORE AS <file_format>:在建表时指定文件格式，默认是TEXTFILE
（2）ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT <file_format>:修改具体表的文件格式
如果要改变创建表的默认文件格式，可以使用set
hive.default.fileformat=<file_format>进行配置，适用于所有表。同时也可以使用set
hive.default.fileformat.managed = <file_format>进行配置，仅适用于内部表或外部表。
扩展：不同存储方式的情况
TEXT,
SEQUENCE和
AVRO文件是面向行的文件存储格式，不是最佳的文件格式，因为即便只查询一列数据，使用这些存储格式的表也需要读取完整的一行数据。另一方面，面向列的存储格式(RCFILE,
ORC, PARQUET)可以很好地解决上面的问题。关于每种文件格式的说明，如下：
（1）TEXTFILE
创建表时的默认文件格式，数据被存储成文本格式。文本文件可以被分割和并行处理，也可以使用压缩，比如GZip、LZO或者Snappy。然而大部分的压缩文件不支持分割和并行处理，会造成一个作业只有一个mapper去处理数据，使用压缩的文本文件要确保文件不要过大，一般接近两个HDFS块的大小。
（2）SEQUENCEFILE
key/value对的二进制存储格式，sequence文件的优势是比文本格式更好压缩，sequence文件可以被压缩成块级别的记录，块级别的压缩是一个很好的压缩比例。如果使用块压缩，需要使用下面的配置：set
hive.exec.compress.output=true; set io.seqfile.compression.type=BLOCK
（3）AVRO
二进制格式文件，除此之外，avro也是一个序列化和反序列化的框架。avro提供了具体的数据schema。
（4）RCFILE
全称是Record Columnar File，首先将表分为几个行组，对每个行组内的数据进行按列存储，每一列的数据都是分开存储，即先水平划分，再垂直划分。
（5）ORC
全称是Optimized Row Columnar，从hive0.11版本开始支持，ORC格式是RCFILE格式的一种优化的格式，提供了更大的默认块(256M)
（6）PARQUET
另外一种列式存储的文件格式，与ORC非常类似，与ORC相比，Parquet格式支持的生态更广，比如低版本的impala不支持ORC格式。
配置同样数据同样字段的两张表，以常见的TEXT行存储和ORC列存储两种存储方式为例，对比执行速度。
TEXT存储方式
总结： 从上图中可以看出列存储在对指定列进行查询时，速度更快， 建议在建表时设置列存储的存储方式 。
2.3 表的压缩
对Hive表进行压缩是常见的优化手段，一些存储方式自带压缩选择，比如SEQUENCEFILE支持三种压缩选择：NONE，RECORD，BLOCK。Record压缩率低，一般建议使用BLOCK压缩；
ORC支持三种压缩选择：NONE，ZLIB，SNAPPY。我们以TEXT存储方式和ORC存储方式为例，查看表的压缩情况。
配置同样数据同样字段的四张表，一张TEXT存储方式，另外三张分别是默认压缩方式的ORC存储、SNAPPY压缩方式的ORC存储和NONE压缩方式的ORC存储，查看在hdfs上的存储情况：
TEXT存储方式
默认压缩ORC存储方式
SNAPPY压缩的ORC存储方式
NONE压缩的ORC存储方式
总结 ：可以看到ORC存储方式将数据存放为两个block，默认压缩大小加起来134.69M，SNAPPY压缩大小加起来196.67M，NONE压缩大小加起来247.55M，TEXT存储方式的文件大小为366.58M，且默认block两种存储方式分别为256M和128M，ORC默认的压缩方式比SNAPPY压缩得到的文件还小，原因是ORZ默认的ZLIB压缩方式采用的是deflate压缩算法，比Snappy压缩算法得到的压缩比高，压缩的文件更小。 ORC不同压缩方式之间的执行速度，经过多次测试发现三种压缩方式的执行速度差不多，所以建议采用ORC默认的存储方式进行存储数据。
2.4 分桶分区
Num Buckets表示桶的数量，我们可以通过分桶和分区操作对Hive表进行优化：
对于一张较大的表，可以将它设计成分区表，如果不设置成分区表，数据是全盘扫描的，设置成分区表后，查询时只在指定的分区中进行数据扫描，提升查询效率。要注意尽量避免多级分区，一般二级分区足够使用。常见的分区字段：
（1）日期或者时间，比如year、month、day或者hour，当表中存在时间或者日期字段时，可以使用些字段。
（2）地理位置，比如国家、省份、城市等
（3）业务逻辑，比如部门、销售区域、客户等等
与分区表类似，分桶表的组织方式是将HDFS上的一张大表文件分割成多个文件。分桶是相对分区进行更细粒度的划分，分桶将整个数据内容按照分桶字段属性值得hash值进行区分，分桶可以加快数据采样，也可以提升join的性能(join的字段是分桶字段)，因为分桶可以确保某个key对应的数据在一个特定的桶内(文件)，所以巧妙地选择分桶字段可以大幅度提升join的性能。通常情况下，分桶字段可以选择经常用在过滤操作或者join操作的字段。
创建分桶表
create
table test_user_bucket(id int, name string,code string,code_id string )
clustered by(id) into 3 buckets ROW FORMAT DELIMITED FIELDS TERMINATED
BY ',';
查看描述信息
DESCRIBE FORMATTED test_user_bucket
多出了如下信息
查看该表的hdfs
同样的数据查看普通表和分桶表查询效率
普通表
分桶表
普通表是全表扫描，分桶表在按照分桶字段的hash值分桶后，根据join字段或者where过滤字段在特定的桶中进行扫描，效率提升。
本文首发于： 数栈研习社
数栈是云原生—站式数据中台PaaS，我们在github上有一个有趣的开源项目： FlinkX
FlinkX是一个基于Flink的批流统一的数据同步工具，既可以采集静态的数据，比如MySQL，HDFS等，也可以采集实时变化的数据，比如MySQL
binlog，Kafka等，是全域、异构、批流一体的数据同步引擎，大家如果有兴趣，欢迎来github社区找我们玩~
10. Hive支持的数据类型
#整型
TINYINT — 微整型，只占用1个字节，只能存储0-255的整数。
SMALLINT– 小整型，占用2个字节，存储范围–32768 到 32767。
INT– 整型，占用4个字节，存储范围-2147483648到2147483647。
BIGINT– 长整型，占用8个字节，存储范围-2^63到2^63-1。
#布尔型
BOOLEAN — TRUE/FALSE
#浮点型
FLOAT– 单精度浮点数。
DOUBLE– 双精度浮点数。
#字符串型
STRING– 不设定长度。
Structs：一组由任意数据类型组成的结构。比如，定义一个字段C的类型为STRUCT {a INT; b STRING}，则可以使用a和C.b来获取其中的元素值；
Maps：和Java中的Map相同，即存储K-V对的；
Arrays：数组；
复杂数据类型的声明必须使用尖括号指明其中数据字段的类型。定义三列，每列对应一种复杂的数据类型，如下所示。
TEXTFILE //文本，默认值
SEQUENCEFILE // 二进制序列文件
RCFILE //列式存储格式文件 Hive0.6以后开始支持
ORC //列式存储格式文件，比RCFILE有更高的压缩比和读写效率，Hive0.11以后开始支持
PARQUET //列出存储格式文件，Hive0.13以后开始支持
#参考博客：
http://lxw1234.com/archives/2015/06/238.htm
http://www.cnblogs.com/zlslch/p/5659714.html
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types
#