Class KafkaSinks

java.lang.Object
com.hazelcast.jet.kafka.KafkaSinks

public final class KafkaSinks extends Object
Contains factory methods for Apache Kafka sinks.
Since:
Jet 3.0
  • Method Details

    • kafka

      @Nonnull public static <E, K, V> Sink<E> kafka(@Nonnull Properties properties, @Nonnull FunctionEx<? super E,org.apache.kafka.clients.producer.ProducerRecord<K,V>> toRecordFn)
      Returns a sink that publishes messages to Apache Kafka topic(s). It transforms each received item to a ProducerRecord using the supplied mapping function.

      The sink creates a single KafkaProducer per processor using the supplied properties.

      The behavior depends on the job's processing guarantee:

      • EXACTLY_ONCE: the sink will use Kafka transactions to commit the messages. Transactions are committed after a snapshot is completed. This increases the latency of the messages because they are only visible to consumers after they are committed and slightly reduces the throughput because no messages are sent between the snapshot phases.

        When using transactions pay attention to your transaction.timeout.ms config property. It limits the entire duration of the transaction since it is begun, not just inactivity timeout. It must not be smaller than your snapshot interval, otherwise the Kafka broker will roll the transaction back before Jet is done with it. Also it should be large enough so that Jet has time to restart after a failure: a member can crash just before it's about to commit, and Jet will attempt to commit the transaction after the restart, but the transaction must be still waiting in the broker. The default in Kafka 2.4 is 1 minute.

        Also keep in mind the consumers need to use isolation.level=read_committed, which is not the default. Otherwise the consumers will see duplicate messages.

      • AT_LEAST_ONCE: messages are committed immediately, the sink ensure that all async operations are done at 1st snapshot phase. This ensures that each message is written if the job fails, but might be written again after the job restarts.
      If you want to avoid the overhead of transactions, you can reduce the guarantee just for the sink. To do so, use the builder version and call exactlyOnce(false) on the builder.

      IO failures are generally handled by Kafka producer and do not cause the processor to fail. Refer to Kafka documentation for details.

      The default local parallelism for this processor is 1.

      Type Parameters:
      E - type of stream item
      K - type of the key published to Kafka
      V - type of the value published to Kafka
      Parameters:
      properties - producer properties which should contain broker address and key/value serializers
      toRecordFn - function that extracts the key from the stream item
    • kafka

      @Beta @Nonnull public static <E, K, V> Sink<E> kafka(@Nonnull DataConnectionRef dataConnectionRef, @Nonnull FunctionEx<? super E,org.apache.kafka.clients.producer.ProducerRecord<K,V>> toRecordFn)
      Returns a sink that publishes messages to Apache Kafka topic(s). It transforms each received item to a ProducerRecord using the supplied mapping function.

      The sink uses the supplied DataConnection to obtain a KafkaProducer instance for each Processor. Depending on the DataConnection configuration it may be either a new instance for each processor, or a shared instance. NOTE: Shared instance can't be used with exactly-once.

      The behavior depends on the job's processing guarantee:

      • EXACTLY_ONCE: the sink will use Kafka transactions to commit the messages. Transactions are committed after a snapshot is completed. This increases the latency of the messages because they are only visible to consumers after they are committed and slightly reduces the throughput because no messages are sent between the snapshot phases.

        When using transactions pay attention to your transaction.timeout.ms config property. It limits the entire duration of the transaction since it is begun, not just inactivity timeout. It must not be smaller than your snapshot interval, otherwise the Kafka broker will roll the transaction back before Jet is done with it. Also it should be large enough so that Jet has time to restart after a failure: a member can crash just before it's about to commit, and Jet will attempt to commit the transaction after the restart, but the transaction must be still waiting in the broker. The default in Kafka 2.4 is 1 minute.

        Also keep in mind the consumers need to use isolation.level=read_committed, which is not the default. Otherwise the consumers will see duplicate messages.

      • AT_LEAST_ONCE: messages are committed immediately, the sink ensure that all async operations are done at 1st snapshot phase. This ensures that each message is written if the job fails, but might be written again after the job restarts.

      If you want to avoid the overhead of transactions, you can reduce the guarantee just for the sink. To do so, use the builder version and call exactlyOnce(false) on the builder.

      IO failures are generally handled by Kafka producer and do not cause the processor to fail. Refer to Kafka documentation for details.

      The default local parallelism for this processor is 1.

      Type Parameters:
      E - type of stream item
      K - type of the key published to Kafka
      V - type of the value published to Kafka
      Parameters:
      dataConnectionRef - DataConnection reference to use to obtain the KafkaProducer
      toRecordFn - function that extracts the key from the stream item
      Since:
      5.3
    • kafka

      @Nonnull public static <E, K, V> Sink<E> kafka(@Nonnull Properties properties, @Nonnull String topic, @Nonnull FunctionEx<? super E,K> extractKeyFn, @Nonnull FunctionEx<? super E,V> extractValueFn)
      Convenience for kafka(Properties, FunctionEx) which creates a ProducerRecord using the given topic and the given key and value mapping functions
      Type Parameters:
      E - type of stream item
      K - type of the key published to Kafka
      V - type of the value published to Kafka
      Parameters:
      properties - producer properties which should contain broker address and key/value serializers
      topic - name of the Kafka topic to publish to
      extractKeyFn - function that extracts the key from the stream item
      extractValueFn - function that extracts the value from the stream item
    • kafka

      @Beta @Nonnull public static <E, K, V> Sink<E> kafka(@Nonnull DataConnectionRef dataConnectionRef, @Nonnull String topic, @Nonnull FunctionEx<? super E,K> extractKeyFn, @Nonnull FunctionEx<? super E,V> extractValueFn)
      Convenience for kafka(Properties, FunctionEx) which creates a ProducerRecord using the given topic and the given key and value mapping functions
      Type Parameters:
      E - type of stream item
      K - type of the key published to Kafka
      V - type of the value published to Kafka
      Parameters:
      dataConnectionRef - producer properties which should contain broker address and key/value serializers
      topic - name of the Kafka topic to publish to
      extractKeyFn - function that extracts the key from the stream item
      extractValueFn - function that extracts the value from the stream item
      Since:
      5.3
    • kafka

      @Beta @Nonnull public static <E, K, V> Sink<E> kafka(@Nonnull DataConnectionRef dataConnectionRef, @Nonnull Properties properties, @Nonnull String topic, @Nonnull FunctionEx<? super E,K> extractKeyFn, @Nonnull FunctionEx<? super E,V> extractValueFn)
      Convenience for kafka(Properties, FunctionEx) which creates a ProducerRecord using the given topic and the given key and value mapping functions with additional properties available
      Type Parameters:
      E - type of stream item
      K - type of the key published to Kafka
      V - type of the value published to Kafka
      Parameters:
      dataConnectionRef - producer properties which should contain broker address and key/value serializers
      properties - additional properties
      topic - name of the Kafka topic to publish to
      extractKeyFn - function that extracts the key from the stream item
      extractValueFn - function that extracts the value from the stream item
      Since:
      5.3
    • kafka

      @Nonnull public static <K, V> Sink<Map.Entry<K,V>> kafka(@Nonnull Properties properties, @Nonnull String topic)
      Convenience for kafka(Properties, String, FunctionEx, FunctionEx) which expects Map.Entry<K, V> as input and extracts its key and value parts to be published to Kafka.
      Type Parameters:
      K - type of the key published to Kafka
      V - type of the value published to Kafka
      Parameters:
      properties - producer properties which should contain broker address and key/value serializers
      topic - Kafka topic name to publish to
    • kafka

      @Beta @Nonnull public static <K, V> Sink<Map.Entry<K,V>> kafka(@Nonnull DataConnectionRef dataConnectionRef, @Nonnull String topic)
      Convenience for kafka(DataConnectionRef, String, FunctionEx, FunctionEx) which expects Map.Entry<K, V> as input and extracts its key and value parts to be published to Kafka.
      Type Parameters:
      K - type of the key published to Kafka
      V - type of the value published to Kafka
      Parameters:
      dataConnectionRef - DataConnection reference to use to obtain the KafkaProducer
      topic - Kafka topic name to publish to
      Since:
      5.3
    • kafka

      @Nonnull public static <E> KafkaSinks.Builder<E> kafka(@Nonnull Properties properties)
      Returns a builder object that you can use to create an Apache Kafka pipeline sink.

      The sink creates a single KafkaProducer per processor using the supplied properties.

      The behavior depends on the job's processing guarantee:

      • EXACTLY_ONCE: the sink will use Kafka transactions to commit the messages. This brings some overhead on the broker side, slight throughput reduction (we don't send messages between snapshot phases) and, most importantly, increases the latency of the messages because they are only visible to consumers after they are committed.

        When using transactions pay attention to your transaction.timeout.ms config property. It limits the entire duration of the transaction since it is begun, not just inactivity timeout. It must not be smaller than your snapshot interval, otherwise the Kafka broker will roll the transaction back before Jet is done with it. Also it should be large enough so that Jet has time to restart after a failure: a member can crash just before it's about to commit, and Jet will attempt to commit the transaction after the restart, but the transaction must be still waiting in the broker. The default in Kafka 2.4 is 1 minute.

      • AT_LEAST_ONCE: messages are committed immediately, the sink ensure that all async operations are done at 1st snapshot phase. This ensures that each message is written if the job fails, but might be written again after the job restarts.
      If you want to avoid the overhead of transactions, you can reduce the guarantee just for the sink by calling exactlyOnce(false) on the returned builder.

      IO failures are generally handled by Kafka producer and do not cause the processor to fail. Refer to Kafka documentation for details.

      Default local parallelism for this processor is 1.

      Type Parameters:
      E - type of stream item
      Parameters:
      properties - producer properties which should contain broker address and key/value serializers
    • kafka

      @Beta @Nonnull public static <E> KafkaSinks.Builder<E> kafka(@Nonnull DataConnectionRef dataConnectionRef)
      Returns a builder object that you can use to create an Apache Kafka pipeline sink.

      The sink creates a single KafkaProducer per processor using the supplied properties.

      The behavior depends on the job's processing guarantee:

      • EXACTLY_ONCE: the sink will use Kafka transactions to commit the messages. This brings some overhead on the broker side, slight throughput reduction (we don't send messages between snapshot phases) and, most importantly, increases the latency of the messages because they are only visible to consumers after they are committed.

        When using transactions pay attention to your transaction.timeout.ms config property. It limits the entire duration of the transaction since it is begun, not just inactivity timeout. It must not be smaller than your snapshot interval, otherwise the Kafka broker will roll the transaction back before Jet is done with it. Also it should be large enough so that Jet has time to restart after a failure: a member can crash just before it's about to commit, and Jet will attempt to commit the transaction after the restart, but the transaction must be still waiting in the broker. The default in Kafka 2.4 is 1 minute.

      • AT_LEAST_ONCE: messages are committed immediately, the sink ensure that all async operations are done at 1st snapshot phase. This ensures that each message is written if the job fails, but might be written again after the job restarts.
      If you want to avoid the overhead of transactions, you can reduce the guarantee just for the sink by calling exactlyOnce(false) on the returned builder.

      IO failures are generally handled by Kafka producer and do not cause the processor to fail. Refer to Kafka documentation for details.

      Default local parallelism for this processor is 1.

      Type Parameters:
      E - type of stream item
      Parameters:
      dataConnectionRef - DataConnection reference to use to obtain the KafkaProducer
      Since:
      5.3