作为数据开发从业人员，对于hive必然是不陌生的。Hive作为Hadoop的数据仓库工具，提供SQL查询功能，然后将其转换为MapReduce任务，从而进行分布式运算。当然，涉及大数据量的时候，这中间的操作花费的时间少不了。作为一名入坑大数据没多久的IT民工，接下来讲一讲Hive当中需要注意的点，避免踩坑~

1、 load本地文件到hive表

有时候需要将本地的一些文件上传到hive表中，首先需要准备好本地文件，存为txt格式，同时需要注意编码格式必须为UTF-8，不然之后会出现乱码。接下来就是将TXT文件上传到HDFS中。同时在hive中建好表。下面是一个简单的示例，仅包含两个字段。

create table temp
(id int, name string)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\t'
STORED AS TEXTFILE;

需要注意的是，建表的时候需要指出字段间的间隔符，比如TXT文件中使用\t来分割的，建表语句中就需要指定相应的符号。建好表之后，直接使用load语句就OK了。path中的路径按照具体情况填写即可。

load data local inpath 'temp.txt' overwrite into table temp;

2、lateral view explode的使用

在处理hive表的时候，经常会遇到行转多列的需要，这时候lateral view explode就派上用场了。但是使用的时候要注意避免踩坑。这条语句仅限跟在表名之后，如果有where条件那就只能再搞个子查询了。

首先，explode（）函数的参数必须为array类型。所以需要注意hive表字段的类型。很多情况下，也可以采用split函数的结果作为explode的输入。

其次，在某个字段上使用这个函数的时候，需要注意该字段是否存在null值。如果该字段为null值，这个explode操作之后整条记录会丢失。如果不小心的话，最后会莫名其妙发现源表中部分记录最后没了。如果需要保证不丢失，那么lateral view outer explode就是最好的选择了，相应的字段会用null值填充。

3、join操作

join的使用频率在hive中应该是极高的。join的操作详细来分的话，有很多种，比如left join、inner join、full join等等。这里面也有很多需要注意的地方。

对于 a left join b的情况，需要注意表b中参与join的字段是否存在重复。left join的结果记录条数应当和左表的条数一样多，但是当右表关联的字段存在重复的时候，会使得结果表记录条数变多，因为重复的字段会多次join。

对于outer join，不要把右表的where条件写在on语句中。有时候为了方便on语句中除了join必须的关联字段相等条件外，还会把左右表的过滤条件写在一起。遇到outer join时，可能结果就会出现各种对不上的情况。所以不要偷懒，多写个子查询吧~

还要注意的一点是join的字段不要存在null值。这点很重要。如果在job的监控上发现reduce阶段有一个特别慢，除了数据倾斜等原因外，需要查看数据是否存在null值。

当然，join里面的学问有很多，比如常见的大小表join时，小表在前，大表在后，设置hive.auto.convert.join=true等。比如两张都很大的表join时，可以采用SMB（sort merge bucket）方式。这些都是hive优化方面的东东了。

4、UDF的使用

写UDF也是数据开发中很常见的操作啦。一般比较简单的UDF就可以完成大部分需求了。只要extends UDF然后重写evaluate方法即可。这里面要稍加注意的是evaluate方法的返回类型。UDF操作和返回的最终都是hive中的表，所以返回类型必须是hive能够支持的可序列化的数据类型。比如Int、String、Text、Double等。如果数据类型不支持，一般会报ObjectInspector的相关错误提示，所以看见这个报错，就去修改返回数据类型吧。

如果想返回Struct，Map和Array类型的结果，上面那个简单的UDF就满足不了我们的需求了，此时需要继承GenericUDF。这个就比上面的UDF要麻烦一点了。

Hive的学问有很多，跑任务的时候多看看MapReduce的执行情况，往往能从他们的个数和执行时间来推测是否语句或者数据是否存在问题。比如第一个job起了几百个map却只有一个reduce，就得回头看看hive是不是写的有问题了~

大数据小菜鸟一枚，记录的都是平时工作中遇到的问题和坑，有问题请大家多指教啦~