HIVE-29389: HiveProtoLoggingHook populates duplicate entries in Table…

[tanishq-chugh]

…sRead metrics for tables with multiple partitions

What changes were proposed in this pull request?

Fix HiveProtoLoggingHook to ensure no duplicate entries are populated for TablesRead metrics in case of tables with multiple partitions

Why are the changes needed?

Currently, When a SELECT * query is executed on a table with multiple partitions, the TablesRead metric is populated with duplicate entries of the same table - one for each partition accessed.

As a result, the TablesReadCount metric also reports an incorrect value.

Does this PR introduce any user-facing change?

Yes, in generated proto files. Currently, incorrect value is produced for TablesRead metric when a SELECT * is run on a table with multiple partitions. For example, when the following queries are run:

CREATE TABLE tbl_test_part(a int) partitioned by (b int) stored as orc tblproperties("transactional"="true");
INSERT INTO tbl_test_part PARTITION (b=1) VALUES (11);
INSERT INTO tbl_test_part PARTITION (b=2) VALUES (22);
INSERT INTO tbl_test_part PARTITION (b=3) VALUES (33);

SELECT * FROM tbl_test_part;

With the current behaviour, in the proto file generated for the last SELECT query, TablesRead metric / list will contain 4 duplicate entries of default.tbl_test_part . (Correspondingly, the TablesReadCount metric is 4)

After this fix, it will contain only one entry of default.tbl_test_part . (Correspondingly, the TablesReadCount metric is 1)

How was this patch tested?

Manually tested

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Aggarwal-Raghav]

LGTM +1 (non-binding)
I was able to repro the issue

@tanishq-chugh , for select query, there are 4 entry (1 table, 3 partitions )instead of 3 as mentioned in the PR description. Please update the PR description.

Just thinking out loud 🤔, if there is any benefit of keeping entity.getType() == PARTITION as table name will always be present in a SQL query and partition alone can't exist.

[tanishq-chugh]

@Aggarwal-Raghav
my bad, yes its 4, Thanks for catching this, changing it.

For the second part, entity.getType() == PARTITION, it was to fix - HIVE-26646, without this the TablesWritten field won't get populated for the INSERT query attached in description : INSERT INTO tbl_test_part PARTITION (b=1) VALUES (11);