Hey folks! I'm working on migrating the Delta Lak...
# dev
k
Hey folks! I'm working on migrating the Delta Lake connector from Flink 1.16 to 2.0 and hit an interesting blocker that I'd love some guidance on. Quick context: I've made substantial progress (15 commits, 105+ tests migrated, everything compiles), but there's one missing piece that's blocking integration tests. The Problem: My custom
DeltaSinkInternal
implements
Sink<IN>
and has these methods:
Copy code
public Optional<Committer<T>> createCommitter() throws IOException
public Optional<SimpleVersionedSerializer<T>> getCommittableSerializer()
The framework discovers and invokes
createWriter()
perfectly, but
createCommitter()
is never called. When I tried adding
@Override
, I got a compilation error saying these methods aren't part of the
Sink<IN>
interface. The Question: How does a Sink expose its Committer in Flink 2.0? Is there a marker interface I'm missing? How does
FileSink
do it? I suspect there's a specific pattern or interface (maybe something that replaced
TwoPhaseCommittingSink
from 1.x) that I need to implement, but I can't find documentation about it. Related: • Delta Lake issue: https://github.com/delta-io/delta/issues/5228 • My implementation branch: https://github.com/kdsnunes/delta/tree/flink/add-flink-2.0-support • (I'm also trying to get access to Flink's Jira to create an issue there, but it's pending approval) Any pointers would be super appreciated! Has anyone migrated a connector with Committer support to 2.0? Thanks in advance! 🙏
a
With 2.0 you need to use the SupportXXX interfaces, in particular
SupportsCommitter
👍 1
🎯 1
k
@Arvid Heise Thanks to your guidance on using SupportsCommitter<T>, I've successfully resolved the Committer discovery issue in the Delta Lake connector migration to Flink 2.0
I’m running into an issue with concurrent Delta Log commits. With parallelism=3, three Committer instances try to write to the same _delta_log/00000000000000000001.json, which results in checksum mismatches:
Copy code
Checksum error: delta_log/00000000000000000001.json
exp: -2003856348 got: -1473006609
In Flink 1.x, this was handled by GlobalCommitter (parallelism=1), ensuring atomic commits per checkpoint. Since GlobalCommitter was removed in Flink 2.0, what’s the recommended way to make sure only one Committer performs a coordinated action like writing to a shared transaction log? Should this be done via a new built-in pattern, or do we now need custom coordination logic (e.g. distributed lock or barrier)? Branch: flink/add-flink-2.0-support Original issue: #5228
Given that each Committer instance receives only its own committables, how should we aggregate them for a global coordination action like writing to a shared transaction log? Should we use
TaskInfo.getIndexOfThisSubtask()
to designate one coordinator, or is there a better pattern?
a
Global committer is a bit more hidden in V2:
Copy code
private static class TestSinkV2WithPostCommitTopology<InputT>
            extends TestSinkV2TwoPhaseCommittingSink<InputT>
            implements SupportsPostCommitTopology<String> {
        public TestSinkV2WithPostCommitTopology(
                DefaultSinkWriter<InputT> writer,
                SimpleVersionedSerializer<String> committableSerializer,
                DefaultCommitter committer) {
            super(writer, committableSerializer, committer);
        }

        @Override
        public void addPostCommitTopology(DataStream<CommittableMessage<String>> committables) {
            StandardSinkTopologies.addGlobalCommitter(
                    committables, DefaultCommitter::new, this::getCommittableSerializer);
        }
    }
So you add a post commit topology and can do whatever you want, in particular you can use something that simulates the old global committer.
✅ 1
k
@Arvid Heise Thank you so much for pointing me to
SupportsPostCommitTopology
and
StandardSinkTopologies.addGlobalCommitter
! That was exactly what I needed. I've successfully implemented the pattern and the global coordination is now working correctly - committables from all parallel DeltaCommitter instances are being aggregated and committed atomically to the Delta Log through the post-commit topology. The migration from GlobalCommitter to this new pattern is much clearer now. Really appreciate the help! 🙏
n
@K Nunes you'll be a hero in my books if you get Flink 2 support going 🙂
🙏 1