Impala scanners internally have a RowBatch queue that allows Impala to decouple I/O from CPU processing. The I/O threads read data into RowBatches and put them into a queue, CPU threads asynchronously fetch data from the queue and process them. RowBatchQueueGetWaitTime is the amount of time CPU threads wait on data to arrive into the queue. Essentially, it means the CPU threads were waiting a long time for the I/O threads to read the data. ... View more

Yes, unfortunately this was an oversight, and will be corrected in a future release. For now you can either do the workaround you suggested (manually underallocating for the others, then manually configuring Kudu's memory limit).   Or, if you want to roll up your sleeves a bit: ssh to the CM server machine. For each file named KUDU*.jar (in /usr/share/cmf/common_jars, I believe): Extract the JAR file using the 'jar' utility. Modify descriptor/service.sdl by finding the memory_limit_hard_bytes entry, adding a comma after "default" :  4294967296, and adding a new line with the contents "autoConfigShare" : 100 Recreate the JAR around the extracted files (including the modified service.sdl) Overwrite the existing KUDU*.jar files with the new ones you created in step #5. Restart the CM server. You should now see an entry in he static service pools UI for Kudu's Tablet Server Hard Memory Limit. ... View more

Hi mauricio,   Impala currently does not support graceful node decommissioning. We're tracking work on this feature in IMPALA-1760, but we currently are not targeting it for a particular release. Unfortunately that only leaves the option of killing the daemon.   Cheers, Lars ... View more