Reading multi-source compressed JSONL files

[shrshi]

Description

Fixes #17068
Fixes #12299

This PR introduces a new datasource for compressed inputs which enables batching and byte range reading of multi-source JSONL files using the reallocate-and-retry policy. Moreover. instead of using a 4:1 compression ratio heuristic, the device buffer size is estimated accurately for GZIP, ZIP, and SNAPPY compression types. For remaining types, the files are first decompressed then batched.

TODO: Reuse existing JSON tests but with an additional compression parameter to verify correctness.
Handled by #17219, which implements compressed JSON writer required for the above test.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[vuule]

I love the approach!
Some suggestions, main one is the "memoization" in the new source type.

[shrshi]

Status update: Implementing benchmark for compressed JSONL files in #17219

[shrshi]

Plot of throughput of read_json for GZIP-compressed JSONL inputs against uncompressed input size generated using the benchmark from #17219

Benchmark raw output:

<style> </style>

compression_type	io	data_size	Samples	CPU Time	Noise	GPU Time	Noise	bytes_per_second	peak_memory_usage	encoded_file_size
------------------	----------	------------------	---------	------------	-------	------------	-------	------------------	-------------------	-------------------
GZIP	FILEPATH	2^20 = 1048576	768x	18.205 ms	1.88%	18.196 ms	1.88%	2.95E+10	13.458 MiB	386.724 KiB
GZIP	FILEPATH	2^21 = 2097152	617x	24.215 ms	3.04%	24.206 ms	3.04%	2.22E+10	26.707 MiB	768.517 KiB
GZIP	FILEPATH	2^22 = 4194304	418x	35.741 ms	2.15%	35.732 ms	2.15%	1.5E+10	53.015 MiB	1.492 MiB
GZIP	FILEPATH	2^23 = 8388608	251x	59.739 ms	1.60%	59.731 ms	1.60%	8.99E+09	106.061 MiB	2.984 MiB
GZIP	FILEPATH	2^24 = 16777216	120x	125.038 ms	0.96%	125.029 ms	0.96%	4.29E+09	212.568 MiB	5.981 MiB
GZIP	FILEPATH	2^25 = 33554432	5x	244.733 ms	0.37%	244.726 ms	0.37%	2.19E+09	425.201 MiB	11.965 MiB
GZIP	FILEPATH	2^26 = 67108864	5x	481.785 ms	0.39%	481.781 ms	0.39%	1.11E+09	849.693 MiB	23.925 MiB
GZIP	FILEPATH	2^27 = 134217728	5x	939.229 ms	0.23%	939.231 ms	0.23%	5.72E+08	1.658 GiB	47.797 MiB
GZIP	FILEPATH	2^28 = 268435456	5x	1.923 s	0.28%	1.923 s	0.28%	2.79E+08	3.318 GiB	95.642 MiB
GZIP	FILEPATH	2^29 = 536870912	4x	3.885 s	inf%	3.885 s	inf%	1.38E+08	6.638 GiB	191.359 MiB

Without the custom data source for compressed inputs, the parser errors out for all of the above data sizes. I suspect that the heuristic for compressed inputs in the previous implementation falls short without the retry policy, but some more investigation is required to understand the failure, especially for the smaller data sizes.

[shrshi]

On profiling the benchmark using nsys, we see that total runtime is dominated by the host-side compression and decompression (in get_record_range_raw_input in read_json).

nsys profile for data sizes 2^27, 2^28 and 2^29

[vuule]

Haven't reviewed the new decompress_snappy as I'm not sure its needed. Otherwise looks good.