PARQUET-1644: Clean up some benchmark code and docs.

[RyanSkraba]

Make sure you have checked all steps below.

Jira

• My PR addresses the following Parquet Jira issues and references them in the PR title. For example, "PARQUET-1234: My Parquet PR"
  • https://issues.apache.org/jira/browse/PARQUET-1644
  • In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

Tests

• My PR adds the following unit tests OR does not need testing for this extremely good reason: The benchmarking module is used for test purposes

Commits

• My commits all reference Jira issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":
  1. Subject is separated from body by a blank line
  2. Subject is limited to 50 characters (not including Jira issue reference)
  3. Subject does not end with a period
  4. Subject uses the imperative mood ("add", not "adding")
  5. Body wraps at 72 characters
  6. Body explains "what" and "why", not "how"

Documentation

• In case of new functionality, my PR adds documentation that describes how to use it.
  • All the public functions and the classes in the PR contain Javadoc that explain what it does

[nandorKollar]

With this change, NestedNullWritingBenchmarks won't be executed in this benchmark suite, but I think that's fine. @gszadovszky do you agree?

[gszadovszky]

I agree. When this script was created only ReadBenchmarks and WriteBenchmarks were exist. However, it might make sense to have a more descriptive name (e.g. runReadWrite.sh).

[RyanSkraba]

I combined the two existing run scripts into one with some very limited functionality to run predefined "suites" by keyword, but also to run all benchmarks.

What do you think?

[RyanSkraba]

Thanks for taking a look! I'm going to make the run.sh script a bit more descriptive to run "feature sets" so that there's a standard way to run all or some benchmarks. I don't want to go crazy with bash, but I think there's some value to have one entry point to running benchmarks in a standard way.

JMH isn't behaving as I would like for setting up and cleaning resources... I have a couple more fixes to make and I'll push.

[RyanSkraba]

For info, I made a change around general benchmarks setup/cleanup.

Before, the read files for ReadBenchmark were generated and handled differently than the read files for PageChecksumReadBenchmarks. I tried to make them consistent across benchmarks using the following logic:

• When reading, ensure that any necessary file exists during @Setup but don't do any cleanup during the benchmark run.
• When writing, ensure that the output file doesn't exist during @Setup
• All cleanup needs to be done outside of the process running the benchmark.

As far as I can tell, this is the preferred way to use JMH when running "macro-benchmarks".

I didn't observe any actual functional differences after changing the setup strategy -- the total user time to run the PageChecksumReadBenchmarks went down, for example, but the measured operation time stayed the same.

[gszadovszky]

Thanks for working on this. I have some minor issues, but like it overall.

[nandorKollar]

LGTM, please address Gabor's comments.

[RyanSkraba]

Hello! I git merged master into the PR instead of rebasing -- If I understand correctly, these'll be squashed at merge time.

Thanks for the review, and my apologies for the late fixes!