Hive 产生大量的临时文件(转载)

  • Hive 产生大量的临时文件

    背景

    收到磁盘告警后,第一时间查看hdfs容量趋势变化,下图中红色圈起来的部分,因为事情发生在昨天:

    如上,当时看到hdfs的整体容量是突增起来的,而不是主键增长起来的,然后和业务确定了近期的插入量并不大后,就基本可以确定应该是hadoop本身出问题了,而不是确实有那么大的量产生,于是查看下到底是什么占用了这么大的空间:

    如上,我发现 /tmp 目录占了很大的空间,继续深入查看:

    如上,是hive的临时目录占了很多空间,那么里面存的都是什么呢 ?

    如上,存的都是一些编码格式的文件,小的几十K,大的几个G,经网上查阅后发现,在application 运行过程中会产生一些中间表(HIVE默认就存放在 /tmp 目录下,如果是CDH,则就是 /tmp/hive/hive),如果某些application在运行过程中由于某些原因失败了,则这些临时表不会被回收删除。 我们可以设置  hive.exec.compress.intermediate 参数来使得这部分中间结果压缩。

    或者是可以删除那些时间比较久的文件,可以下面的脚本方式修改进行:

    如上,我们在删除的时候用了 -skipTrash 参数,此参数这里稍作解释一下:

    HDFS 会为每一个用户目录下创建一个回收站目录,即:/user/username/.Trash。比如hive用户:

    每一个被执行删除的文件和目录,都会有一个回收周期(fs.trash.interval)。在这个回收周期内,文件不会立即删除,而是被移动到这个回收站目录下面,如果用户发现误删除,可以进行恢复,直接mv回去就可以。当回收周期到达时,HDFS就会将这个文件/目录彻底删除。

    CDH下的默认相关配置如下:

    在HDFS内部的具体实现就是在NameNode中开启了一个后台线程 Emptier,这个线程专门管理和监控系统回收站下面的所有文件/目录,对于已经超过生命周期的文件/目录,这个线程就会自动的删除它们,不过这个管理的粒度很大。Emptier每隔 fs.trash.interval 分钟就清空一次用户回收站。即先检查每个用户回收站目录,然后删除寿命超过 fs.trash.interval 的目录,最后将当前存放删除的目录 /user/用户名/.Trash/current 重命名为一个 /user/用户名/.Trash/yyMMddHHmm。

    如下,current 是当前使用的,每到删除时间,删除超时的最老目录,将当前的currnt重命名为日期时间名,然后新建一个current:

    如果想删除的时候避免回收站这一步,可以在删除的时候指定  -skipTrash 参数。

     

     

你可能感兴趣的:(hive)