Ⅰ 大数据开发工程师Hive(Hive如何进行优化)
1数据存储及压缩优化
针对hive中表的存储格式通常有textfile和orc，压缩格式一般使用snappy。相比于 textfile格式存储，orc占有更少的存储。因为hive底层使用MR计算架构，数据流是hdfs到磁盘再到hdfs，而且会有很多次IO读写操作，所以使用orc数据格式和snappy压缩策略可以降低IO读写，还能降低网络传输量，这样在一定程度上可以节省存储空间，还能提升hql的执行效率；
2 Hive Job优化
①调节Jvm参数，重用Jvm；
②合理设置Map个数；
③合理设置Rece个数；
3 Sql语法优化
① 建表优化 ：
1) Hive创建表的时候，可以建分区表，分桶表；
2) Hive创建表的时候，可以指定数据存储格式：TextFile、SequenceFile、RCfile 、ORCfile；
② 查询时优化 ：
1) 列裁剪，在查询时只读取需要的列，避免全列扫描，不要使用select * from table；
2) 分区裁剪：在查询时只读取需要分区的数据，避免全表扫描；
3) 开启谓词下推：set hive.optimize.ppd = true，默认是true：
a. 将Sql语句中的where谓词逻辑都尽可能提前执行，减少下游处理的数据量；
4) 大表join小表：
a. 开启MapJoin：set hive.auto.convert.join=true：
b. MapJoin是将Join双方比较小的那个表直接分发到各个Map进程的内存中，在 Map进程中进行Join操作， 这样就不用进行Rece步骤 ，从而提高了速度( 大表left join小表才有效 ，小表left join大表会失效)；
5) 大表join大表：
a. SMB Join ：Sort Merge Bucket Join(数据不仅分桶了，而且每个桶数据是排好序了)；
b. 开启SMB Join之后，底层是根据两个表join字段进行分桶存储，这样的话，两张表就变为了基于桶之间join关联查询，而不是基于整张表的join，减少了笛卡尔积；
6) 少用in，用left semi join替代in：
a. 原始写法：select a.id, a.name from a where a.id in (select b.id from b)；
b. 用join改写：select a.id, a.name from a join b on a.id = b.id；
c. left semi join改写：select a.id, a.name from a left semi join b on a.id = b.id；
7) 用union all代替union，因为union all不需要去重，也不需要排序，效率高于union；
(每天1小题，进步1点点)
Ⅱ 数据仓库-Hive基础（七） Hive 的压缩优化
一般用orc或者parquet
orc
结尾加上 STORED AS orc ，同理，用Parquet模式我们加上 STORED AS PARQUET ;
一般SNAPPY压缩和解压缩比比较高，所以一般如果压缩就用snappy，结尾加上 tblproperties ("orc.compress"="SNAPPY"); 即可
在实际的项目开发当中，hive表的数据存储格式一般选择：orc或parquet。压缩方式一般选 择snappy。
Ⅲ 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
#
Ⅳ hive的数据存储
首先，Hive 没有专门的数据存储格式，也没有为数据建立索引，用户可以非常自由的组织 Hive 中的表，只需要在创建表的时候告诉 Hive 数据中的列分隔符和行分隔符，Hive 就可以解析数据。
其次，Hive 中所有的数据都存储在 HDFS 中，Hive 中包含以下数据模型：表(Table)，外部表(External Table)，分区(Partition)，桶(Bucket)。
Hive 中的 Table 和数据库中的 Table 在概念上是类似的，每一个 Table 在 Hive 中都有一个相应的目录存储数据。例如，一个表 pvs，它在 HDFS 中的路径为：/wh/pvs，其中，wh 是在 hive-site.xml 中由 ${hive.metastore.warehouse.dir} 指定的数据仓库的目录，所有的 Table 数据（不包括 External Table）都保存在这个目录中。
Partition 对应于数据库中的 Partition 列的密集索引，但是 Hive 中 Partition 的组织方式和数据库中的很不相同。在 Hive 中，表中的一个 Partition 对应于表下的一个目录，所有的 Partition 的数据都存储在对应的目录中。例如：pvs 表中包含 ds 和 city 两个 Partition，则对应于 ds = 20090801, ctry = US 的 HDFS 子目录为：/wh/pvs/ds=20090801/ctry=US；对应于 ds = 20090801, ctry = CA 的 HDFS 子目录为；/wh/pvs/ds=20090801/ctry=CA
Buckets 对指定列计算 hash，根据 hash 值切分数据，目的是为了并行，每一个 Bucket 对应一个文件。将 user 列分散至 32 个 bucket，首先对 user 列的值计算 hash，对应 hash 值为 0 的 HDFS 目录为：/wh/pvs/ds=20090801/ctry=US/part-00000；hash 值为 20 的 HDFS 目录为：/wh/pvs/ds=20090801/ctry=US/part-00020
External Table 指向已经在 HDFS 中存在的数据，可以创建 Partition。它和 Table 在元数据的组织上是相同的，而实际数据的存储则有较大的差异。
Table 的创建过程和数据加载过程（这两个过程可以在同一个语句中完成），在加载数据的过程中，实际数据会被移动到数据仓库目录中；之后对数据对访问将会直接在数据仓库目录中完成。删除表时，表中的数据和元数据将会被同时删除。 External Table 只有一个过程，加载数据和创建表同时完成（CREATE EXTERNAL TABLE ……LOCATION），实际数据是存储在 LOCATION 后面指定的 HDFS 路径中，并不会移动到数据仓库目录中。当删除一个 External Table 时，仅删除元数据，表中的数据不会真正被删除。
Ⅳ 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 这类存储方式实现原理。
Ⅵ 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相比其余两种格式具有较明显的优势。
Ⅶ hive分桶表的储存格式是什么固定的还是可以随意指定
对于每一个表或者是分区，Hive可以进一步组织成桶，也就是说桶是更为细粒度的数据范围划分。Hive是针对某一列进行分桶。Hive采用对列值哈希，然后除以桶的个数求余的方式决定该条记录存放在哪个桶中。分桶的好处是可以获得更高的查询处理效率。使取样更高效
hive表数据是在hdfs中储存的并没有固定的储存格式，hive只保存管理表元数据。
桶就是将数据表由一个文件存储分为多个文件存储
分桶语法:
create table t_buck(id string,name string)
clustered by (id) into 4 buckets;
指定了根据id分成4个桶,最好的导入数据方式是insert into table.
要开启模式开关
set hive.enforce.bucketing = true;
set maprece.job.reces=4;
查询时cluster by指定的字段就是partition时分区的key
Ⅷ 【大数据-数仓】HIVE下的文件存储遇到的一个问题（TEXTFILE、RCFILE）
问题：
Failed with exception Wrong file format. Please check the file's format.
FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.MoveTask
解决：
当遇到这个问题时，可以肯定一点的是，文件的格式和建表时指定的存储格式是不一致的。
由此可以定位到问题出在哪里了。
1.确定数据源的格式：
一般都是txt/csv文件
2.确定建表时指定的存储格式
show create table table_name;
然后查看：
STORED AS INPUTFORMAT #指定的存储格式
3.重新建表并修改指定的存储格式
Ⅸ “Hive进阶篇”详解存储格式及压缩方式
hive优化除了有hql语句逻辑优化，hql参数调优等等，还有一个不起眼的细节容易被忽视掉， 那便是hive数仓模型表的存储格式和压缩方式 ，hive底层数据是依托在hadoop，以HDFS文件存储在集群上的， hive数仓模型表选择一个合适的存储格式和压缩方式也是hive优化的一点 。
本篇就来聊一聊这块知识点吧。😄
hive主要有textfile、sequencefile、orc、parquet 这四种存储格式，其中sequencefile很少使用，常见的主要就是orc和parquet这两种，往往也搭配着压缩方式合理使用。
建表声明语句是： stored as textfile/orc/parquet
行式存储，这是hive表的默认存储格式，默认不做数据压缩，磁盘开销大，数据解析开销大，数据不支持分片（即代表着会带来无法对数据进行并行操作）
行列式存储，将数据按行分块，每个块按列存储，其中每个块都存储着一个索引，支持none和zlib和snappy这3种压缩方式，默认采用zlib压缩方式，不支持切片，orc存储格式能提高hive表的读取写入和处理的性能。
列式存储，是一个面向列的二进制文件格式（不可直接读取），文件中包含数据和元数据，所以该存储格式是自解析的，在大型查询时效率很快高效，parquet主要用在存储多层嵌套式数据上提供良好的性能支持，默认采用uncompressed不压缩方式。
行存储引擎 ：同一条数据的不同字段都在相邻位置，所以当要查找某一条记录所有数据时行存储查询速度比较快
列存储引擎 ：以列来聚集数据，相同字段的值聚集在一起，所以当查询某一个指定列的所有数据时，列存储查询速度比较快
hive主要支持gzip、zlib、snappy、lzo 这四种压缩方式。
压缩不会改变元数据的分割性，即压缩后原来的值不变。
建表声明语句是： tblproperties("orc.compress"="SNAPPY")
压缩方式的评判标准主要有以下几点：
针对压缩方式做一个小结对比：