sririshindra commented on code in PR #12824:
URL: https://github.com/apache/iceberg/pull/12824#discussion_r2067473289
##########
spark/v3.5/spark/src/main/java/org/apache/iceberg/spark/actions/RewriteDataFilesSparkAction.java:
##########
@@ -407,15 +409,49 @@ private Builder doExecuteWithPartialProgress(
Stream<RewriteFileGroup> toGroupStream(
RewriteExecutionContext ctx, Map<StructLike, List<List<FileScanTask>>>
groupsByPartition) {
- return groupsByPartition.entrySet().stream()
+ if (maxFilesToRewrite == null) {
+ return groupsByPartition.entrySet().stream()
+ .filter(e -> !e.getValue().isEmpty())
+ .flatMap(
+ e -> {
+ StructLike partition = e.getKey();
+ List<List<FileScanTask>> scanGroups = e.getValue();
+ return scanGroups.stream().map(tasks -> newRewriteGroup(ctx,
partition, tasks));
+ })
+ .sorted(RewriteFileGroup.comparator(rewriteJobOrder));
+ }
+
+ LOG.info(
+ "Max files rewrite options provided for table {} with max file
re-write value : {}",
+ table.name(),
+ maxFilesToRewrite);
+
+ List<RewriteFileGroup> selectedFileGroups = Lists.newArrayList();
+ AtomicInteger fileCountRunner = new AtomicInteger(0);
+
+ groupsByPartition.entrySet().stream()
+ .parallel()
.filter(e -> !e.getValue().isEmpty())
- .flatMap(
- e -> {
- StructLike partition = e.getKey();
- List<List<FileScanTask>> scanGroups = e.getValue();
- return scanGroups.stream().map(tasks -> newRewriteGroup(ctx,
partition, tasks));
- })
- .sorted(RewriteFileGroup.comparator(rewriteJobOrder));
+ .forEach(
+ entry -> {
+ StructLike partition = entry.getKey();
+ entry
+ .getValue()
+ .forEach(
+ fileScanTasks -> {
+ if (fileCountRunner.get() < maxFilesToRewrite) {
+ int remainingSize = maxFilesToRewrite -
fileCountRunner.get();
Review Comment:
@RussellSpitzer
Hey Russell,
Thinking more about this, I'm not sure the comparator really solves the
problem I was getting at. My understanding is that the comparator kicks in
*after* the `selectedFileGroups` list is already built. It seems like it helps
sort the files that *will* be compacted, but it doesn't actually influence
*which* files get picked for compaction in the first place.
You said, "If files are being added faster than they can be compacted I'm
not sure it matters which files are ignored." I see your point, but I think it
*can* matter, especially for this reason:
Folks might write data initially in a format (like Avro) that's not the best
for reading. They could be counting on compaction to rewrite those files into
something better (like Parquet). If new files are constantly coming in faster
than we can compact, and the system doesn't prioritize older files for
compaction, some of those older Avro files might just get left behind
indefinitely. That could definitely cause headaches for users trying to query
that older data efficiently.
Maybe it would make sense to have a separate comparator to compare or
prioritize `FileScanTask`s right when we're deciding which files to compact? We
could default it to something like "oldest file first" to make sure nothing
gets completely starved out. It might be overthinking it, I'm not totally sure,
and I'd trust your call on whether that's necessary.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
