Kafka Consumer

Description

The Kafka Consumer transform pulls streaming data from Kafka. It runs a sub-pipeline that executes according to message batch size or duration, letting you process a continuous stream of records in near-real-time.

This sub-pipeline must start with an Injector transform.

You can define the number of messages to accept for processing, as well as the specific data formats to stream activity data and system metrics.

You can set up this step to collect monitored events, track user consumption of data streams, and monitor alerts.

Kafka records are stored within topics, and consist of a category to which the records are published. Topics are divided into a set of logs known as partitions.

Kafka scales topic consumption by distributing partitions among a consumer group.

A consumer group is a set of consumers sharing a common group identifier.

Since the Kafka Consumer transform continuously ingests streaming data, you may want to use the Abort transform in your parent or sub-pipeline to stop consuming records from Kafka for specific workflows.

For example, you can run the parent pipeline on a timed schedule, or abort the sub-pipeline if sensor data exceeds a preset range.

Options

General

Setup

Batch

Use this tab to determine how many messages to consume before processing. You can specify message count and/or a specific amount of time.

Fields

Result fields

Return fields from a transform in the sub pipeline for further processing in this pipeline.

Options

Use this tab to configure the property formats of the Kafka consumer broker sources. A few of the most common property formats have been included for your convenience. You can enter any desired Kafka property. For further information on these input names, see the Apache Kafka documentation site: https://kafka.apache.org/documentation/.

The options that are included by default are:

Error handling

The Kafka consumer supports error handling but this is limited to the case of Batch Size equal to 1 (records from the Kafka queue are processed one by one). In this case, whenever a record coming from the Kafka queue generates an error in the called sub pipeline, that record will be sent along to the error path for further processing. The record that enter the error path is committed in Kafka and next records in the queue can be processed without any problem. Apart the errors fields inserted by error handling, the layout of the record flowing into the error path will be the layout specified in Field tab.

This feature is very useful in any case where we have a record in the Kafka queue that is stopping processing of further records (because it generates an error during processing) and we want to “remove it” from the queue so that we can process the remaining records in the queue. The failing record can be saved somewhere (for example saved to a file or to a DB table) for further investigation.

Avro and Schema registry

Here are some options you need to consume Avro Record values from a Kafka server. The schema of Avro values are not sent to Kafka but to a schema registry. As such you need to have one available. Here are some options you need to set to make this work on a Confluent Cloud Kafka instance. There are various parts of the software stack that need authentication, hence the bit of redundancy. We recommend that you put these options in variables in your environment configuration file.