Hive 在 0.8 之后提供了几个虚拟列,虚拟列在平时作用并不大,
但是对于Hive, 前序ETL中可能由逻辑等产生的清洗异常,还是有很大帮助的,可以快速定位出错的文件!!!
在实际使用中,我遇到了这样的问题,在清洗日志中,由于上层的日志清洗导致数据的某些列过长,
此时需要快速定位出错的文件。这个时候就可以用到虚拟列了。
hive 的虚拟列 主要有以下几个参数
INPUT__FILE__NAME
BLOCK__OFFSET__INSIDE__FILE
ROW__OFFSET__INSIDE__BLOCK (默认不开启,需设置参数)
注意 每个 __ 都是 两个下划线~
这3个字段解释
INPUT__FILE__NAME :
进行划分的输入文件名
BLOCK__OFFSET__INSIDE__FILE :
文件中的块内偏移量
ROW__OFFSET__INSIDE__BLOCK : (默认不开启)
文件的行偏移量
第三个参数需要手动打开:
需要开启 hive.exec.rowoffset 选项。
先进行选项查询,查看参数是否开启:
连接beeline 客户端 beeline -u jdbc:hive2://BIGDATA6:10000 -n cloudera-scm
0: jdbc:hive2://10.180.0.26:10000> set hive.exec.rowoffset;
+----------------------------+--+
| set |
+----------------------------+--+
| hive.exec.rowoffset=false |
+----------------------------+--+
1 row selected (0.084 seconds)
可以看到参数默认没有开启,我们要开启此参数,如下所示:
0: jdbc:hive2://10.180.0.26:10000> set hive.exec.rowoffset=true;
No rows affected (0.006 seconds)
场景实战
已知clickcube_mid表中有一个字段 regioncode , regioncode 描述了 一个ip对应的region信息,这个regioncode 目前使用的是原始值,为日志中直接获取。
某一天,由于regioncode 异常,导致spark 进程中断,查找得知是 regioncode 不合理导致,此时我们需要找到错误的regioncode, 可以进行如下的查询:
SELECT
INPUT__FILE__NAME,
BLOCK__OFFSET__INSIDE__FILE,
ROW__OFFSET__INSIDE__BLOCK,
substr(regioncode,0,20)
FROM clickcube_mid
WHERE length(regioncode) > 100;