stevenzwu commented on code in PR #8555: URL: https://github.com/apache/iceberg/pull/8555#discussion_r1332287112
########## 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: > but for schema evolution I think you'd want it on checkpoint boundaries. This is the assumption that I like us to challenge. It was also my initial assumption too. For partition spec evolution, we need to enhance `IcebergFilesCommitter` as a single manifest file is tied to one partition spec. if we have data files from two different partition specs (during transition period), committer can separate them out and commit in separate transactions. For schema evolution, I am not sure if we need to do anything special if data files have 2 different schemas (during transition period). In the future coordinator broadcast approach, it can be more complicated to apply the switch at checkpoint boundary and probably more difficult to guarantee it. We can (1) either add the complexity in the committer operator to enhance the handling of partition spec evolution (2) or add the complexity in the coordinator broadcast implementation. I am wondering if the former is a bit cleaner and easier. -- 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]
