Status

Current state: Under Discussion

Discussion thread:

https://lists.apache.org/thread/4w36oof8dh28b9f593sgtk21o8qh8qx4

https://lists.apache.org/thread/t0bdkx1161rlbnsf06x0kswb05mch164

JIRA: here (<- link to https://issues.apache.org/jira/browse/FLINK-XXXX)

Released: 1.17

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

While restoring from a snapshot, StateBackend will resolve the schema compatibilty to decide where to go.

Currently, if users use a customized serializer to process data, they have to make sure that the schema compatibility in the old serializer (maybe in Flink library) meets the need as users want. Or else they have to modify TypeSerializerSnapshot#resolveSchemaCompatibility(TypeSerializer<T> newSerializer) of the old serializer. There are no ways for users to specify the compatiblity with the old serializer in the new serializer. It also makes scheme evolution not supported in some scenarios.

For exmaple, if users want to implement a customized serializer which is compatible with ValueSerializer, user have to modify the compatibility logic in ValueSerializer.ValueSerializerSnapshot#resolveSchemaCompatibility(TypeSerializer<T> newSerializer). (ValueSerializer is final so that it also could not be extended). 

So reversing the direction of resolving schema compatibility could improve the usability of schema evolution.

Public Interfaces

Add an extra method in TypeSerializerSnapshot.java before removing the deprecated TypeSerializerSnapshot#resolveSchemaCompatibility(TypeSerializer<T> newSerializer).

@PublicEvolving
public interface TypeSerializerSnapshot<T> {
	// Check whether the serializer is compatible with the old one.
    default TypeSerializerSchemaCompatibility<T> resolveSchemaCompatibility(TypeSerializerSnapshot<T> oldSerializerSnapshot) {
		// Use the old logic to resolve.   
		return oldSerializerSnapshot.resolveSchemaCompatibility(restoreSerializer());
}

Mark the old method as deprecated and provide a default implementation.

@PublicEvolving
public interface TypeSerializerSnapshot<T> {
    @Deprecated         
	default TypeSerializerSchemaCompatibility<T> resolveSchemaCompatibility(TypeSerializer<T> newSerializer) {
		// Return INCOMPATIBLE as default before removing the deprecated method.
        return TypeSerializerSchemaCompatibility.incompatible();   
    } 
}

Make the method abstract after removing the deprecated TypeSerializerSnapshot#resolveSchemaCompatibility(TypeSerializer<T> newSerializer).

@PublicEvolving 
public interface TypeSerializerSnapshot<T> {
    // Check whether the serializer is compatible with the old one.
    public abstract TypeSerializerSchemaCompatibility<T> resolveSchemaCompatibility(TypeSerializerSnapshot<T> oldSerializerSnapshot);
}

Proposed Changes

Because Both TypeSerializer and TypeSerializerSnapshot are public interfaces, we have several steps to migrate the logic.

Step 1

Add an extra method in TypeSerializerSnapshot.java as below.

@PublicEvolving
public interface TypeSerializerSnapshot<T> {
	// Check whether the serializer is compatible with the old one.
    default TypeSerializerSchemaCompatibility<T> resolveSchemaCompatibility(TypeSerializerSnapshot<T> oldSerializerSnapshot) {
		// Use the old logic to resolve.   
		return oldSerializerSnapshot.resolveSchemaCompatibility(restoreSerializer());
}

TypeserializeSnapshotr#resolveSchemaCompatibility(TypeSerializerSnapshot<T> oldSerializerSnapshot) will call TypeSerializerSnapshot#resolveSchemaCompatibility(TypeSerializer<T> newSerializer) as default implementation.

All places where use TypeSerializerSnapshot#resolveSchemaCompatibility(TypeSerializer<T> newSerializer) to check the compatibility will call Typeserializer#resolveSchemaCompatibility(TypeSerializerSnapshot<T> oldSerializerSnapshot).

Users could implement their own logic of resolving compatibility in their new serializer and it will be used by flink.

If users haven't implement Typeserializer#resolveSchemaCompatibility(TypeSerializerSnapshot<T> oldSerializerSnapshot), all behaviors are same as before. 

Step 2

It will confuse users there are two similar methods (TypeSerializerSnapshot#resolveSchemaCompatibility(TypeSerializer<T> newSerializer) and Typeserializer#resolveSchemaCompatibility(TypeSerializerSnapshot<T> oldSerializerSnapshot)).

So we propose deprecating TypeSerializerSnapshot#resolveSchemaCompatibility(TypeSerializer<T> newSerializer) for the long run.

In the step 2, we need to

1. Implement the new method in all inner TypeserializerSnapshots
2. Mark TypeSerializerSnapshot#resolveSchemaCompatibility(TypeSerializer<T> newSerializer) as deprecated and provide a default implementation for it as below.

@PublicEvolving
public interface TypeSerializerSnapshot<T> {
    @Deprecated         
	default TypeSerializerSchemaCompatibility<T> resolveSchemaCompatibility(TypeSerializer<T> newSerializer) {
		// Return INCOMPATIBLE as default before removing the deprecated method.
        return TypeSerializerSchemaCompatibility.incompatible();   
    } 
}

Step 3

After several stable version, remove TypeSerializerSnapshot#resolveSchemaCompatibility(TypeSerializer<T> newSerializer) and related implementation.

At the same time, the interface could be abstract:

@PublicEvolving 
public interface TypeSerializerSnapshot<T> {
    // Check whether the serializer is compatible with the old one.
    public abstract TypeSerializerSchemaCompatibility<T> resolveSchemaCompatibility(TypeSerializerSnapshot<T> oldSerializerSnapshot);
}

Compatibility, Deprecation, and Migration Plan

The deprecation and migration plan are listed above.

Test Plan

1. Existing UT of resolving compatibility could verify whether the old behavior could work as before.
2. Add extra UT to verify the correctness of customized serializer.
3. Add ITCase and e2e test case to mock the user behavior.

Rejected Alternatives

None.