Support sharded Parquet file querying and conversion

[SungJin1212]

This PR supports for querying sharded Parquet files within a bucket store and enables the conversion of sharded Parquet files.

Benchmark Results

Currently, the concurrency is hard-coded as 4.

GOROOT=/usr/local/opt/go/libexec #gosetup
GOPATH=/Users/kakao_ent/go #gosetup
/usr/local/opt/go/libexec/bin/go test -c -tags=slicelabels -o /Users/kakao_ent/Library/Caches/JetBrains/GoLand2026.1/tmp/GoLand/___1BenchmarkParquetBucketStore_MultiShard_in_github_com_cortexproject_cortex_pkg_storegateway.test github.com/cortexproject/cortex/pkg/storegateway #gosetup
/Users/kakao_ent/Library/Caches/JetBrains/GoLand2026.1/tmp/GoLand/___1BenchmarkParquetBucketStore_MultiShard_in_github_com_cortexproject_cortex_pkg_storegateway.test -test.v -test.paniconexit0 -test.bench ^\QBenchmarkParquetBucketStore_MultiShard\E$ -test.run ^$ #gosetup
goos: darwin
goarch: amd64
pkg: github.com/cortexproject/cortex/pkg/storegateway
cpu: VirtualApple @ 2.50GHz
BenchmarkParquetBucketStore_MultiShard
BenchmarkParquetBucketStore_MultiShard/shards=1
BenchmarkParquetBucketStore_MultiShard/shards=1-14         	      72	  15630539 ns/op	36701543 B/op	  282624 allocs/op
BenchmarkParquetBucketStore_MultiShard/shards=2
BenchmarkParquetBucketStore_MultiShard/shards=2-14         	     100	  11494683 ns/op	38358405 B/op	  284007 allocs/op
BenchmarkParquetBucketStore_MultiShard/shards=4
BenchmarkParquetBucketStore_MultiShard/shards=4-14         	     100	  10774228 ns/op	38830028 B/op	  286728 allocs/op
BenchmarkParquetBucketStore_MultiShard/shards=8
BenchmarkParquetBucketStore_MultiShard/shards=8-14         	     100	  11819611 ns/op	38578193 B/op	  291999 allocs/op
PASS

Process finished with the exit code 0

Which issue(s) this PR fixes:
Fixes #7176 #7174

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]
• docs/configuration/v1-guarantees.md updated if this PR introduces experimental flags

[yeya24]

I haven't looked at how this parquet sharding works for quite some time now... The sharding is to shard at columns... So do we really need to open all shards here? Or based on sharding do we know if we can only open 1 file is enough?

[SungJin1212]

We can't tell which shard holds a matching series.. So we need to open all shard files. (the converter mark only stores the shard count, with no per-shard label metadata)

[yeya24]

We should at least try to get some hints? The sharding is based on sorting order. For example if we sort by metric name label, we should be able to get the min and max value for each shard and store them in the convert marker. This way based on metric name in the query we can tell which shard file we need to open.

This doesn't block this PR but I think it is something we should do to optimize the query path

[SungJin1212]

Agree, we can store MinName and MaxName to the ConverterMark and then utilize it when pruning shards since __name__ is always the primary sort key. I'll track it as a follow-up PR.

[yeya24]

We should have an integration test with sharding enabled?

[SungJin1212]

I added an e2e test.