rdsr commented on a change in pull request #315: [WIP] Incremental processing prototype URL: https://github.com/apache/incubator-iceberg/pull/315#discussion_r364880807
########## File path: core/src/main/java/org/apache/iceberg/IncrementalDataScan.java ########## @@ -0,0 +1,118 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +package org.apache.iceberg; + +import com.google.common.base.Preconditions; +import com.google.common.base.Predicate; +import com.google.common.collect.ImmutableMap; +import com.google.common.collect.Iterables; +import com.google.common.collect.Lists; +import java.util.Collection; +import java.util.List; +import org.apache.iceberg.expressions.Expression; +import org.apache.iceberg.io.CloseableIterable; +import org.apache.iceberg.util.SnapshotUtil; + +class IncrementalDataScan extends DataTableScan implements TableScan { + private final TableOperations ops; + private final Table table; + private boolean colStats; + private long fromSnapshotId; + private long toSnapshotId; + + IncrementalDataScan(TableOperations ops, Table table, long fromSnapshotId, long toSnapshotId) { + super(ops, table); + this.ops = ops; + this.table = table; + this.fromSnapshotId = fromSnapshotId; + this.toSnapshotId = toSnapshotId; + } + + private IncrementalDataScan(TableOperations ops, Table table, Long snapshotId, Schema schema, + Expression rowFilter, boolean caseSensitive, boolean colStats, + Collection<String> selectedColumns, ImmutableMap<String, String> options, + Long fromSnapshotId, Long toSnapshotId) { + super(ops, table, snapshotId, schema, rowFilter, caseSensitive, colStats, selectedColumns, options); + this.ops = ops; + this.table = table; + this.colStats = colStats; + this.fromSnapshotId = fromSnapshotId; + this.toSnapshotId = toSnapshotId; + } + + @Override + public TableScan asOfTime(long timestampMillis) { + throw new UnsupportedOperationException("asOfTime() is not supported in IncrementalScan"); + } + + @Override + public TableScan useSnapshot(long scanSnapshotId) { + throw new UnsupportedOperationException("useSnapshot() is not supported in IncrementalScan"); + } + + @Override + public CloseableIterable<FileScanTask> planFiles() { + //TODO publish an incremental appends scan event + List<Snapshot> snapshots = snapshotsWithin(table, fromSnapshotId, toSnapshotId); + final Iterable<CloseableIterable<FileScanTask>> files = Iterables.transform(snapshots, this::planFiles); + return CloseableIterable.concat(files); + } + + private CloseableIterable<FileScanTask> planFiles(Snapshot snapshot) { + Predicate<ManifestFile> matchingManifests = manifest -> manifest.snapshotId() == snapshot.snapshotId(); + + Predicate<ManifestEntry> matchingManifestEntries = + manifestEntry -> + manifestEntry.snapshotId() == snapshot.snapshotId() && + manifestEntry.status() == ManifestEntry.Status.ADDED; + + return planFiles(ops, snapshot, filter(), isCaseSensitive(), colStats, matchingManifests, matchingManifestEntries); Review comment: @rdblue I've switched over to using `ManifestGroup`, though now there's a lot of duplication and refactoring that can be improved. I didn't wanted to do all that in this PR . I'm listing below some things that can be improved and also some questions. 1. In FilteredManifest` who do `liveEntries()` and `allEntries()` do not project `stats_column`. This behavior is different from `FilteredManifest.iterator<DataFile>` which always projects `stats_columns` and then transforms to drop them if they were not initially projected. Shouldn't this behavior be also present for both `liveEntries()` and `allEntries()` ? I see that there's benefit in having consistent behavior across all these three methods [`liveEntries()` , `allEntries()` and `Iterator<DataFile>`]. Since, then the duplicate code can be removed and these methods can be built on top of one another. Also, seems like stats_columns maybe required in `liveEntries()` as I see `FindFiles` is calling `liveEntries(). 1. FilteredManifest[`liveEntries()`, `allEntries()`, `Iterator()`] can possibly share a lot of code. 2. It seems `ManifestGroup` can possibly benefit from a builder instead of using the constructor pattern to pass in optional args. 3. `entries()` and `tasks()` in ManifestGroup can share a lot of underlying code when `FilteredManifest` is refactored as mentioned above. Let me know if these changes are OK with you . I can open a separate PR for this. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
