GH-48218: [C++][Parquet] Fix Util & Level Conversion logic on big-endian

[Vishwanatha-HD]

Rationale for this change

This PR is intended to enable Parquet DB support on Big-endian (s390x) systems. The fix in this PR fixes the "util & level_conversion" logic.

What changes are included in this PR?

The fix includes changes to following files:
cpp/src/parquet/level_conversion_inc.h
cpp/src/parquet/test_util.h

Are these changes tested?

Yes. The changes are tested on s390x arch to make sure things are working fine. The fix is also tested on x86 arch, to make sure there is no new regression introduced.

Are there any user-facing changes?

No.

GitHub main Issue link: #48151

• GitHub Issue: [C++][Parquet] Fix Util & Level Conversion logic to enable Parquet DB support on Big-Endian (s390x) systems #48218

[github-actions]

⚠️ GitHub issue #48218 has been automatically assigned in GitHub to PR creator.

[k8ika0s]

@Vishwanatha-HD

Something I’ve bumped into on s390x is that the swap decision sometimes needs to follow the encoded byte-order marker more closely than the compile-time ARROW_LITTLE_ENDIAN macro. A couple of the downstream readers (especially in geospatial stats) assume “LE on disk” is its own concept, even if the host is BE. So I’m curious how this change behaves when the host is big-endian but the consuming path is trying to normalize everything toward a canonical LE interpretation.

On the level-bitmap side, I’ve occasionally seen the bitmap comparison logic behave differently depending on whether the input originated on a BE machine or came directly from Arrow buffers that were already LE-canonical. Wrapping GreaterThanBitmap with a swap might be exactly what’s needed here — I’m mostly wondering how consistently the upstream paths feed this comparison LE vs. host-order data.

Not flagging this as wrong; just passing along some of the odd little behaviors I’ve seen on the BE side of things. Happy to help run this through a few combinations on actual s390x hardware if that would be useful.

[pitrou]

LGTM, thank you

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 2 benchmarking runs that have been run so far on merge-commit 1044022.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details.