lukecwik commented on a change in pull request #11715: URL: https://github.com/apache/beam/pull/11715#discussion_r427431140
########## File path: sdks/java/core/src/main/java/org/apache/beam/sdk/transforms/splittabledofn/GrowableOffsetRangeTracker.java ########## @@ -0,0 +1,115 @@ +/* + * 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.beam.sdk.transforms.splittabledofn; + +import static org.apache.beam.vendor.guava.v26_0_jre.com.google.common.base.Preconditions.checkNotNull; + +import org.apache.beam.sdk.annotations.Experimental; +import org.apache.beam.sdk.annotations.Experimental.Kind; +import org.apache.beam.sdk.io.range.OffsetRange; + +/** + * An {@link OffsetRangeTracker} for tracking a growable offset range. {@code Long.MAX_VALUE} is + * used as end range to indicate the possibility of infinity. + * + * <p>An offset range is considered growable when the end offset could grow (or change) during + * execution time (e.g., Kafka topic partition offset, appended file, ...). + * + * <p>The growable range is marked as done by claiming {@code Long.MAX_VALUE}. + */ +@Experimental(Kind.SPLITTABLE_DO_FN) +public class GrowableOffsetRangeTracker extends OffsetRangeTracker { + /** + * An interface that should be implemented to fetch estimated end offset of the range. + * + * <p>{@code estimateRangeEnd} is called to give the end offset when {@code trySplit} or {@code + * getProgress} is invoked. The end offset is exclusive for the range. The estimated end is not + * necessary to increase monotonically as it will only be taken into computation when the estimate + * end is larger than the current position. When returning {@code Long.MAX_VALUE} as estimate, it + * means the largest possible position for the range is {@code Long.MAX_VALUE - 1}. If there is + * not an estimate yet, {@code Long.MIN_VALUE} should be returned, where estimated end will not + * effect progress and split. + * + * <p>Having a good estimate is important for providing a good signal of progress and splitting at + * a proper position. + * + * <p>If {@code estimate()} is expensive to call, please consider wrapping the implementation with + * {@code Suppliers.memoizeWithExpiration} as an optimization. + */ + @FunctionalInterface + public interface RangeEndEstimator { + long estimate(); + } + + private final RangeEndEstimator rangeEndEstimator; + + public GrowableOffsetRangeTracker(long start, RangeEndEstimator rangeEndEstimator) { + super(new OffsetRange(start, Long.MAX_VALUE)); + this.rangeEndEstimator = checkNotNull(rangeEndEstimator); + } + + @Override + public SplitResult<OffsetRange> trySplit(double fractionOfRemainder) { + // If current tracking range is no longer growable, split it as a normal range. + if (range.getTo() != Long.MAX_VALUE || range.getTo() == range.getFrom()) { + return super.trySplit(fractionOfRemainder); + } + // If current range has been done, there is no more space to split. + if (lastAttemptedOffset != null && lastAttemptedOffset == Long.MAX_VALUE) { + return null; + } + double cur = Review comment: We should only use doubles if there would be an issue with overflow. For really large long values we can have the math be incorrect which can lead to the splitPos being before `from` or after `to` even though with higher precision we would get something that works. For example: ``` long a = 123456789012345677L; long b = 123456789012345679L; long c = 123456789012345680L; double ad = a; double bd = b; double cd = c; System.out.println((long)ad + " " + (long)bd + " " + (long)cd); ``` prints ``` 123456789012345680 123456789012345680 123456789012345680 ``` Worthwhile to have a test which exercises a case where `from = 123456789012345677L` and `to = 123456789012345679L` and we can have a split in between. Also worthwhile to test `from = 123456789012345681L` and `to = 123456789012345683L`. All these values (and the values in between) when converted to double and back to long round to `123456789012345680L`. We can solve this by having two ways to calculate this or using BigDecimal. The two ways to calculate method would use longs when (estimateRangeEnd - cur) won't overflow and doubles otherwise. Using BigDecimal with a MathContext with enough precision wouldn't run into this either and would only require one implemention (I believe `DECIMAL128` should have enough precision to not run into this issue). ---------------------------------------------------------------- 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: us...@infra.apache.org