stevenzwu commented on code in PR #8555: URL: https://github.com/apache/iceberg/pull/8555#discussion_r1332018527
########## 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: exactly, that's why I think we should stick with one: either just refresh on checkpoint boundary or refresh with time boundary independently by tasks. if we stick with checkpoint boundary, then there is no need for the `Duration` arg for `FlinkSink$Builder#tableRefreshInterval(...)`, a simple boolean is fine. I am also thinking about future implementation from coordinator broadcast. Coordinator can send/broadcast the refreshed table object first, tasks will only apply the switch at next checkpoint boundary. Whether coordinator refresh at time or checkpoint boundary will be same with what we need to decide here. For the scope of `FileIO` or `credentials` refresh, async/non-synchronized switch (time threshold based) would be fine. For schema/partition evolution, is it necessary to switch at the checkpoint/flush boundary across tasks? It may not be necessary. For partition spec evolution, we can enhance the `IcebergFilesCommitter` to group data and delete files by partition specs and commit one transaction per partition spec (during transition/switch periods). For schema evolution, it seems that we don't need to do anything special if writer tasks switched at different time (or checkpoint cycles). It is ok to commit data files with different schemas in one transaction. @pvary @danielcweeks @rdblue what do you think? -- 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]
