Repository navigation
Core: Add Eager fetch to parquet read path #17284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
75e0048
c6b6861
4d33a4e
812d748
bcfe1d5
2cce30c
b700403
3257b1d
8bd13b6
b17b679
5eb2cbc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -92,11 +92,12 @@ | |
| import org.apache.iceberg.encryption.NativeEncryptionOutputFile; | ||
| import org.apache.iceberg.exceptions.RuntimeIOException; | ||
| import org.apache.iceberg.expressions.Expression; | ||
| import org.apache.iceberg.hadoop.HadoopInputFile; | ||
| import org.apache.iceberg.hadoop.HadoopConfigurable; | ||
| import org.apache.iceberg.hadoop.HadoopOutputFile; | ||
| import org.apache.iceberg.io.CloseableIterable; | ||
| import org.apache.iceberg.io.DataWriter; | ||
| import org.apache.iceberg.io.DeleteSchemaUtil; | ||
| import org.apache.iceberg.io.EagerInputFile; | ||
| import org.apache.iceberg.io.FileAppender; | ||
| import org.apache.iceberg.io.InputFile; | ||
| import org.apache.iceberg.io.OutputFile; | ||
|
|
@@ -144,6 +145,9 @@ private Parquet() {} | |
| "parquet.read.support.class", | ||
| "parquet.crypto.factory.class"); | ||
|
|
||
| // Size threshold (bytes) at or below which a Parquet file is fetched eagerly on the first read. | ||
| private static final long EAGER_FETCH_THRESHOLD_BYTES = 1024 * 1024; | ||
|
|
||
| public static WriteBuilder write(OutputFile file) { | ||
| if (file instanceof EncryptedOutputFile) { | ||
| return write((EncryptedOutputFile) file); | ||
|
|
@@ -1352,7 +1356,12 @@ public ReaderFunction withSchema(Schema expectedSchema) { | |
| } | ||
|
|
||
| private ReadBuilder(InputFile file) { | ||
| this.file = file; | ||
| long fileLength = file.getLength(); | ||
| this.file = canEagerFetch(fileLength) ? EagerInputFile.of(file, fileLength) : file; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Codex helped me flag this issue. In summary, S3/GCS/ADLS already accepts and use the (potentially staled) length. Hadoop was using DetailsFor small Hadoop-backed Parquet reads, HadoopInputFile.fromStatus(hfile.getStat(), hfile.getConf());See This PR wraps files up to 1 MiB using the reported length: long fileLength = file.getLength();
this.file = canEagerFetch(fileLength) ? EagerInputFile.of(file, fileLength) : file;The eager reader then reads exactly that many bytes: byte[] bytes = new byte[(int) length];
IOUtil.readFully(src, bytes, 0, bytes.length);If the recorded length is smaller than the physical file, the buffer excludes the real Parquet footer and trailing If the recorded length is larger, #16910 corrects new complete rewrites, but it does not repair existing affected manifest-list entries and still preserves source lengths for manifests carried over by incremental rewrites. This PR therefore removes Hadoop's existing protection against stale lengths by wrapping Please preserve the physical Hadoop
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hadoop should not be protecting against this :) Honestly I think this is a misfeature. It exists to cover for bad implementations which store the wrong length, but leads to even weirder situations where HadoopFileIO would work reading a file via S3A that would fail through S3FileIO
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since all the other FileIO implementations already trust the supplied length, I think its reasonable for HadoopFileIO to do this. I think its worth calling that out, perhaps in the PR description. And perhaps with a unit test
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also to note, this doesn't apply to manfiest-lists written for any currently valid tables since they are all using Avro for manifest list and manifests which do not break on the wrong length regardless
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. updated PR description to include this change for Hadoop and mentioned the trusting length part |
||
| } | ||
|
|
||
| private static boolean canEagerFetch(long fileLength) { | ||
| return fileLength > 0 && fileLength <= EAGER_FETCH_THRESHOLD_BYTES; | ||
| } | ||
|
|
||
| /** | ||
|
|
@@ -1545,9 +1554,9 @@ public <D> CloseableIterable<D> build() { | |
| || batchedReaderFuncWithSchema != null | ||
| || readerFunction != null) { | ||
| ParquetReadOptions.Builder optionsBuilder; | ||
| if (file instanceof HadoopInputFile) { | ||
| if (file instanceof HadoopConfigurable) { | ||
| // remove read properties already set that may conflict with this read | ||
| Configuration conf = new Configuration(((HadoopInputFile) file).getConf()); | ||
| Configuration conf = new Configuration(((HadoopConfigurable) file).getConf()); | ||
| for (String property : READ_PROPERTIES_TO_REMOVE) { | ||
| conf.unset(property); | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.