The following step below should help you: take a phyciscal backup of the master you are going to take down (in case something is going wrong with the migration). stop doing any DDL to the masters to prevent data loss.  take down the master you chosen on step 1. follow the doc Recovering from a Dead Kudu Master in a Multi-Master Deployment. ... View more

When you said you were using 'new Date()', is it java.util.Date? If so, can you try 'SimpleDateFormat' where you can set time zone by 'setTimeZone', example can be found here.    I also notice the Impala doc stating that 'The conversion between the Impala 96-bit representation and the Kudu 64-bit representation introduces some performance overhead when reading or writing TIMESTAMP columns. You can minimize the overhead during writes by performing inserts through the Kudu API. Because the overhead during reads applies to each query, you might continue to use a BIGINT column to represent date/time values in performance-critical applications.' So I guess that is why you are seeing insert performance difference. And if you care about query performance as well, the other option is to use 'BIGINT' column.   ... View more

Hi huaj,   It looks like you are hitting KUDU-1400, which before the fix Kudu cmpacts rowsets based on overlap and not based on other criteria like on-disk size.   Unfortunately, there is no way to fix the small rowsets have been flushed. On the other hand, You can rebuild the affected tables, create new tables from this existing tables and see if that helps. Before doing that, please check this doc to see which patten usage pattern caused you to hit this issue and try to prevent that by following the recommendations.   FYI, this fix for KUDU-1400 should land in the next release CDH6.2.     ... View more