HIVE的select语句中磁盘io写重



在hive I中运行查询-

select ret[0],ret[1],ret[2],ret[3],ret[4],ret[5],ret[6] from (select combined1(extra) as ret from log_test1) a ;

其中ret[0], ret[1], ret[2], ...为域名,日期,IP等。这个查询在磁盘上做了大量的写操作。

iostat result on one box in cluster.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.65    0.00    1.82   57.14    0.00   20.39
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
xvdb              0.00     0.00    0.00  535.00     0.00 23428.00    87.58   143.94  269.11    0.00  269.11   1.87 100.00

我的映射器基本上卡在磁盘IO中。我有3个盒子簇。我的yarn配置是

Mapper memory(mapreduce.map.memory.mb)=2GB, 
I/O Sort Memory Buffer=1 GB. 
I/O Sort Spill Percent=0.8

我的工作的计数器是

FILE: Number of bytes read  0 
FILE: Number of bytes written   2568435 
HDFS: Number of bytes read  1359720216 
HDFS: Number of bytes written   19057298627 
Virtual memory (bytes) snapshot     24351916032 
Total committed heap usage (bytes)  728760320 
Physical memory (bytes) snapshot    2039455744 
Map input records   76076426 
Input split bytes   2738 
GC time elapsed (ms)    55602 
Spilled Records     0 

由于mapper最初应该将所有内容写入RAM,并且当RAM满时(I/O Sort Memory Buffer),它应该将数据溢出到磁盘中。但是正如我所看到的,Spilled Records=0和mapper没有使用全内存,仍然有如此繁重的磁盘写入。

即使我在运行query

select combined1(extra) from log_test1;

我有同样重的磁盘写入。

磁盘写量大的原因是什么?如何减少磁盘写量大?在这种情况下,磁盘io将成为映射器的瓶颈。

可能是在第二阶段处理发生之前将子查询写入磁盘。您应该使用Explain来检查执行计划。

您可以尝试将子查询重写为CTE https://cwiki.apache.org/confluence/display/Hive/Common+Table+Expression

相关内容

  • 没有找到相关文章

最新更新