GH-3327: Bug fix incorrect compressed size reported by DataPageV1

[ArnavBalyan]

Rationale for this change

• Currently ColumnChunkPageReadStore sets decompressed bytes when creating datapagev1.
• However DataPageV1 assumes this to be compressed bytes and sets the wrong value via PageReadStore.
• This causes wrong byte value to be set on the datapagev1. Downstream gets actually uncompressed bytes instead of compressed bytes upon doing page.getCompressedSize()
• This also affects CLI where today ShowPagesCommand actually reports wrong compressedSize.
• Fix the same by adding a constructor which can accept both compressed/uncompressed sizes and intelligently set it for the internal Page.
• Closes: ShowPagesCommand shows wrong information for compressedSize #3327

Are these changes tested?

• Yes (Added test which was failing before the change)

Are there any user-facing changes?

• Yes

[ArnavBalyan]

cc @gszadovszky could you PTAL :)

[gszadovszky]

@ArnavBalyan, I have a feeling that this change breaks the contract of Page. In ColumnChunkPageReadStore we actually decompress (and decrypt) the data, so the fact that the compressed and decompressed page sizes are equal are deliberate. BTW, based on the code it seems that the same problem described in this issue also stands for V2 pages.

Since in parquet-cli we only want to show page statistics, I would suggest implementing a separate code path that would only read the page headers to provide the required values instead of decompressing (and decrypting) the pages for no reason.

[ArnavBalyan]

@ArnavBalyan, I have a feeling that this change breaks the contract of Page. In ColumnChunkPageReadStore we actually decompress (and decrypt) the data, so the fact that the compressed and decompressed page sizes are equal are deliberate. BTW, based on the code it seems that the same problem described in this issue also stands for V2 pages.

Since in parquet-cli we only want to show page statistics, I would suggest implementing a separate code path that would only read the page headers to provide the required values instead of decompressing (and decrypting) the pages for no reason.

Updated thanks, the CLI directly reads the page header to provide the bytes. The overhead of the header read should be negligible especially for the CLI only usecase

[gszadovszky]

Thanks, @ArnavBalyan. LGTM