Added support for Hudi

[alexeykudinkin]

Description

This PR adds support for Hudi into BrooklynData benchmarking suite.

How was this patch tested?

Adding Hudi support to BrooklynData benchmarks we run this suite on EMR w/ the same configuration as have been called out in this blog, obtaining following results:

Things to note:

• Hudi by default adds materialized meta-fields (like primary-key, partition-path, etc) to every record which help it subsequently speed up updates (by the ways of being able to leverage Bloom index for ex) as well as powering Hudi's other stand-out features such as Incremental reads (enabling Incremental ETL for ex). Such amendment comes at the expense of slightly slower bulk-insert operation (in CREATE TABLE AS SELECT)
• Hudi's upsert performance (step 2) is dominated by unnecessary conversion to Avro, which is what community currently focusing on rectifying
• Hudi performs better in workloads w/ higher selectivity (step 3, ie reading just a handful of files), since it relies on Bloom index
• Hudi sets lower target file-size limit of 120Mb to balance Query performance against Write amplification problem, which is lower than Delta's default value (of 256Mb) and therefore makes Hudi produce more files and therefore affecting its query performance relative to Delta. We deliberately not tried to tune this setting up for more fair comparison.

Does this PR introduce any user-facing changes?

N/A

[alexeykudinkin]

Following 3 options are actually shouldn't need to be specified explicitly, however in our recent round of testing we've discovered a regression (HUDI-5499) that prompted us to employ these here for a proper comparison

[vinothchandar]

Can we please get a review on this?

[jecolvin]

Sorry for the delay! Approved and merged!