在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