Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Make partitioned parquet reading deterministic #4739

Closed
wants to merge 3 commits into from
Closed

Make partitioned parquet reading deterministic #4739

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
95fe9a1
Make partitioned parquet reading deterministic
devinrsmith Oct 29, 2023
7196669
Merge remote-tracking branch 'upstream/main' into fix-non-determinist…
devinrsmith Nov 6, 2023
81facb6
Extract filter
devinrsmith Nov 6, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions extensions/parquet/table/src/main/java/io/deephaven/parquet/table/ParquetTools.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,7 @@
import java.nio.file.attribute.BasicFileAttributes;
import java.util.*;
import java.util.function.Function;
import java.util.stream.StreamSupport;

import static io.deephaven.parquet.table.ParquetTableWriter.PARQUET_FILE_EXTENSION;
import static io.deephaven.util.type.TypeUtils.getUnboxedTypeIfBoxed;
Expand Down Expand Up @@ -571,11 +572,13 @@ private static Table readTableInternal(
}
final Path firstEntryPath;
try (final DirectoryStream<Path> sourceStream = Files.newDirectoryStream(sourcePath)) {
final Iterator<Path> entryIterator = sourceStream.iterator();
if (!entryIterator.hasNext()) {
// Lexicographical comparison
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things to raise here:

  1. @malhotrashivam take note, this may be a conflict with your PR
  2. @devinrsmith / @malhotrashivam I think we might prefer to take the max, instead of the min. If we think lexicographic order matters, it's often the case that there is a sortable timestamp (e.g. YYYY-MM-DD-blah) in the name. Taking the most recent gives us a better guess at the intended schema.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, the actual inference step is separate from this outer layer (readPartitionedTableInferSchema). My goal here was to make the existing behavior more deterministic; in this case, I think taking the min entry more closely matches the intentions and probable behavior of the existing code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't make anything more deterministic, unless you read the DirectoryStream JavaDocs with no context. Directories have an order on every file system I'm aware of.

firstEntryPath = StreamSupport.stream(sourceStream.spliterator(), false)
.min(Path::compareTo)
.orElse(null);
if (firstEntryPath == null) {
throw new TableDataException("Source directory " + source + " is empty");
}
firstEntryPath = entryIterator.next();
} catch (IOException e) {
throw new TableDataException("Error reading source directory " + source, e);
}
Expand Down
Loading