[Opt](orc)Optimize the merge io when orc reader read multiple tiny stripes. (#42004)

[hubgeter]

bp #42004

What problem does this PR solve?

When reading orc files, we may encounter a scenario where the stripe byte size is very small but the number of stripes is very large.

This pr introduces three session variables
orc_tiny_stripe_threshold_bytes, orc_once_max_read_bytes, and orc_max_merge_distance_bytes to optimize io reading for the above scenarios.

If a stripe byte size is less than orc_tiny_stripe_threshold_bytes, we will consider it as a tiny stripe. For multiple tiny stripes, we will perform IO merge reading according to the orc_once_max_read_bytes and orc_max_merge_distance_bytes parameters. Among them, orc_once_max_read_bytes indicates the maximum size of the merged IO. You should not set orc_once_max_read_bytes less than orc_tiny_stripe_threshold_bytes, although we will not force an error. When using tiny stripe reading optimization, since tiny stripes are not necessarily continuous, when the distance between two tiny stripes is greater than orc_max_merge_distance_bytes, we will not merge them into one IO.

If you don't want to use this optimization, you can set orc_tiny_stripe_threshold_bytes = 0.

Default parameters:

orc_tiny_stripe_threshold_bytes = 8388608 (8M)
orc_once_max_read_bytes = 8388608 (8M)
orc_max_merge_distance_bytes = 1048576 (1M)

We also add relevant profiles for this purpose so that parameters can be adjusted to optimize reading.
RangeCacheFileReader:

1. CacheRefreshCount: how many IOs are merged
2. ReadToCacheBytes: how much data is actually read after merging
3. ReadToCacheTime: how long it takes to read data after merging
4. RequestBytes: how many bytes does the apache-orc library actually need to read the orc file
5. RequestIO: how many times the apache-orc library calls this read interface
6. RequestTime: how long it takes the apache-orc library to call this read interface

It should be noted that RangeCacheFileReader is a wrapper of the reader that actually reads data, such as the hdfs reader, so strictly speaking, CacheRefreshCount is not equal to how many IOs are initiated to hdfs, because each time the hdfs reader is requested, the hdfs reader may not be able to read all the data at once.

This pr also involves changes to the apache-orc third-party library: apache/doris-thirdparty#244. Reference implementation:
https://github.com/trinodb/trino/blob/master/lib/trino-orc/src/main/java/io/trino/orc/OrcDataSourceUtils.java#L36

Summary:

set orc_tiny_stripe_threshold_bytes = xxx;
set orc_once_max_read_bytes = xxx;
set orc_max_merge_distance_bytes = xxx;

# xxx is the size in bytes

Release note

Introduces three session variables orc_tiny_stripe_threshold_bytes, orc_once_max_read_bytes, and orc_max_merge_distance_bytes to optimize io reading of scenarios where the orc stripe byte size is very small but the number of stripes is very large.

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[doris-robot]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[hubgeter]

run buildall

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[hubgeter]

run buildall

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[hubgeter]

run buildall

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[hubgeter]

run buildall

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[doris-robot]

TeamCity be ut coverage result:
Function Coverage: 36.47% (9532/26135)
Line Coverage: 27.94% (78417/280615)
Region Coverage: 26.60% (40226/151202)
Branch Coverage: 23.40% (20420/87274)
Coverage Report: http://coverage.selectdb-in.cc/coverage/a5485961767d0cd8833dc57d8d4620be06dc3692_a5485961767d0cd8833dc57d8d4620be06dc3692/report/index.html