Child pages
  • KIP-149: Enabling key access in ValueTransformer, ValueMapper, and ValueJoiner
Skip to end of metadata
Go to start of metadata

Status

Current state"under discussion"

Discussion threadHERE

JIRAKAFKA-4218, KAFKA-4726, KAFKA-3745

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

The PR can be found here.

Motivation

(taken from JIRA descriptions) 

 

  • Key access to ValueTransformer:  While transforming values via KStream.transformValues and ValueTransformer, the key associated with the value may be needed, even if it is not changed. For instance, it may be used to access stores.

    As of now, the key is not available within these methods and interfaces, leading to the use of KStream.transform and Transformer, and the unnecessary creation of new KeyValue objects.

  • Key access to ValueMapperValueMapper should have read-only access to the key for the value it is mapping. Sometimes the value transformation will depend on the key.

    It is possible to do this with a full blown KeyValueMapper but that loses the promise that you won't change the key – so you might introduce a re-keying phase that is totally unnecessary.

  • Key access to ValueJoiner interface: In working with Kafka Stream joining, it's sometimes the case that a join key is not actually present in the values of the joins themselves (if, for example, a previous transform generated an ephemeral join key.) In such cases, the actual key of the join is not available in the ValueJoiner implementation to be used to construct the final joined value. This can be worked around by explicitly threading the join key into the value if needed, but it seems like extending the interface to pass the join key along as well would be helpful

Public Changes

  • KStream interface:

 

 

 

 

Proposed Changes

 

  • Handling lambdas

For  ValueMapper, ValueJoiner and their "withKey"  interfaces we support lambdas. For ValueTransformer interface we don't need lambdas by the core definition of the class. 

To support lambdas, we separate withKey interface from original ones, meaning we don't inherit or extend from one to another. 

 

  • ValueMapperWithKey

 

 

  • ValueJoinerWithKey

 

  • ValueTransformerWithKeySupplier

 

 

  • Handling withKey interfaces while building the topology

 

In general, we change the constructors of all related backend Processors to be withKey types as we can easily convert regular (withoutKey) interfaces to withKey interfaces.

 

  • ValueMapperWithKey

 

  • ValueJoinerWithKey

 

 

Test Plan

The unit tests are changed accordingly to support the changes in core classes.

 

Rejected Alternatives

 

  • Lambdas are not supported


This document is proposed with ValueMapper example but it can be applied to other interfaces as well. Rich functions are proposed:
public interface RichFunction {
void init(final ProcessorContext context);

void close();
}
public abstract class AbstractRichFunction implements RichFunction {
@Override
  public void init(final ProcessorContext context) {}

@Override
  public void close() {}
}

 

public abstract class RichValueJoiner<K, V1, V2, VR> extends AbstractRichFunction implements ValueJoiner<V1, V2, VR>  {
@Override
  public final VR apply(final V1 value1, final V2 value2) {
return apply(null, value1, value2);
  }

public abstract VR apply(final K key, final V1 value1, final V2 value2);
}

 

Inside processor, we check if the instance (for example ValueMapper instance) is rich (for example RichValueMapper):

 
KStreamFlatMapValues(ValueMapper<? super V, ? extends Iterable<? extends V1>> mapper) {
this.mapper = mapper;
  isRichFunction = mapper instanceof RichValueMapper ? true : false;
}
@Override
public void process(K key, V value) {
Iterable<? extends V1> newValues;
if (isRichFunction) {
newValues = ((RichValueMapper<? super K, ? super V, ? extends Iterable<? extends V1>>) mapper).apply(key, value);
  } else {
newValues = mapper.apply(value);
 }
for (V1 v : newValues) {
context().forward(key, v);
  }
}

 


  • Not backward-compatible

 

We propose adding key information for ValueJoiner,  ValueTransformer, and ValueMapper classes and their apply(...) methods.

As a result, we perform the following public changes (and their overloaded versions)

ClassOldNew
KStream<VR> KStream<K, VR> mapValues(ValueMapper<? super V, ? extends VR> mapper); <VR> KStream<K, VR> mapValues(ValueMapper<? super K, ? super V, ? extends VR> mapper);
KStream<VR> KStream<K, VR> transformValues(final ValueTransformerSupplier<? super V, ? extends VR> valueTransformerSupplier, final String... stateStoreNames);<VR> KStream<K, VR> transformValues(final ValueTransformerSupplier<? super K, ? super V, ? extends VR> valueTransformerSupplier,final String... stateStoreNames);
KStream

<VO, VR> KStream<K, VR> join(final KStream<K, VO> otherStream,

 final ValueJoiner<? super V, ? super VO, ? extends VR> joiner,

final JoinWindows windows);

<VO, VR> KStream<K, VR> join(final KStream<K, VO> otherStream,

final ValueJoiner<? super K, ? super V, ? super VO, ? extends VR> joiner,

final JoinWindows windows);

KTable

<VR> KTable<K, VR> mapValues(final ValueMapper<? super V, ? extends VR> mapper);

<VR> KTable<K, VR> mapValues(final ValueMapper<? super K, ? super V, ? extends VR> mapper);
KTable

<VO, VR> KTable<K, VR> join(final KTable<K, VO> other, final ValueJoiner<? super V, ? super VO, ? extends VR> joiner);

<VO, VR> KTable<K, VR> join(final KTable<K, VO> other, final ValueJoiner<? super K, ? super V, ? super VO, ? extends VR> joiner);

 

 

  • Lacking performance because deep-copy and need for RichFunctions

 

  1. We extend the target interfaces ValueJoiner,  ValueTransformer, and ValueMapper as ValueJoinerWithKey,  ValueTransformerWithKey, and ValueMapperWithKey. In extended abstract classes we have an access to keys.
  2. In Processor we check the actual instance of object:
     
    this.valueTransformer = valueTransformer;
    if (valueTransformer instanceof ValueTransformerWithKey) {
    isTransformerWithKey = true;
    } else {
    isTransformerWithKey = false;
    }

    ..............

    ..............

    @Override
    public void process(K key, V value) {
    if (isTransformerWithKey) {
    K keyCopy = (K) Utils.deepCopy(key);
      context.forward(key, ((ValueTransformerWithKey<K, V, R>) valueTransformer).transform(keyCopy, value));
      } else {
    context.forward(key, valueTransformer.transform(value));
      }
    }

  3. As we can see from the above code snippet, we can guard the key change in Processors by deeply copying the object before calling the apply() method.



  • No labels