stevenzwu commented on code in PR #8555: URL: https://github.com/apache/iceberg/pull/8555#discussion_r1333167322
########## flink/v1.17/flink/src/main/java/org/apache/iceberg/flink/sink/CachingTableSupplier.java: ########## @@ -0,0 +1,84 @@ +/* + * 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.flink.sink; + +import java.time.Duration; +import org.apache.flink.util.Preconditions; +import org.apache.iceberg.Table; +import org.apache.iceberg.flink.TableLoader; +import org.apache.iceberg.util.DateTimeUtil; +import org.apache.iceberg.util.SerializableSupplier; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +/** + * A table loader that will only reload a table after a certain interval has passed. WARNING: This + * table loader should be used carefully when used with writer tasks. It could result in heavy load + * on a catalog for jobs with many writers. + */ +class CachingTableSupplier implements SerializableSupplier<Table> { + + private static final Logger LOG = LoggerFactory.getLogger(CachingTableSupplier.class); + + private final Table initialTable; + private final TableLoader tableLoader; + private final Duration tableRefreshInterval; + private long nextReloadTimeMs; + private transient Table table; + + CachingTableSupplier(Table initialTable, TableLoader tableLoader, Duration tableRefreshInterval) { + Preconditions.checkArgument(initialTable != null, "initialTable cannot be null"); + Preconditions.checkArgument(tableLoader != null, "tableLoader cannot be null"); + Preconditions.checkArgument( + tableRefreshInterval != null, "tableRefreshInterval cannot be null"); + this.initialTable = initialTable; + this.table = initialTable; + this.tableLoader = tableLoader; + this.tableRefreshInterval = tableRefreshInterval; + this.nextReloadTimeMs = System.currentTimeMillis() + tableRefreshInterval.toMillis(); + } + + @Override + public Table get() { + if (table == null) { + this.table = initialTable; + } + return table; + } + + public void refresh() { Review Comment: > That said, I think if we agree that we are flexible about this part of the change, then we should not block this PR for this decision. I was hoping to get some consensus on this topic/design (not implementation), because it affects the how we should expose this PR in the new public config `duration` vs `boolean. if we always want to tie the switch at checkpoint boundary, the later boolean version seems more natural because interval is not needed at all. this seems like the only open item left. internal implementation is easy to change. public API/config needs to be more careful. @pvary do you see any fundamental problems if tasks make independent timing on switching to new schema (without checkpoint boundary alignment)? I am concerned about checkpoint boundary in the future implementation of coordinator broadcast. what if some broadcast msg came before the checkpoint barrier and some come after? is it really possible for us to fully align all writer tasks perfectly? I felt it is very challenging. the alternative approach is not to rely on it. let the write tasks switch independently. we just enhance the committer to handle potentially multiple partition specs. -- 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]
