[HIVE-24001] Don't cache MapWork in tez/ObjectCache during query-based compaction

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 4.0.0-alpha-1
• Labels: pull-request-available
• Assignee: Karen Coppage
• Reporter: Karen Coppage
• Created: 06/Aug/20 15:05
• Updated: 17/Nov/22 08:48
• Resolved: 11/Aug/20 08:39

Description

Query-based major compaction can fail intermittently with the following issue:

Caused by: org.apache.hadoop.hive.ql.metadata.HiveException: One writer is supposed to handle only one bucket. We saw these 2 different buckets: 1 and 6
  at org.apache.hadoop.hive.ql.udf.generic.GenericUDFValidateAcidSortOrder.evaluate(GenericUDFValidateAcidSortOrder.java:77)

This is consistently preceded in the application log with:

 [INFO] [TezChild] |tez.ObjectCache|: Found hive_20200804185133_f04cca69-fa30-4f1b-a5fe-80fc2d749f48_Map 1__MAP_PLAN__ in cache with value: org.apache.hadoop.hive.ql.plan.MapWork@74652101

Alternatively, when MapRecordProcessor doesn't find mapWork in tez/ObjectCache (but instead caches mapWork), major compaction succeeds.

The failure happens because, if MapWork is reused, GenericUDFValidateAcidSortOrder (which is called during compaction) is also reused on splits belonging to two different buckets, which produces an error.

Solution is to avoid storing MapWork in the ObjectCache during query-based compaction.

Issue Links

• links to: GitHub Pull Request #1368