Produce and consume messages between Kafka and Pulsar
StreamNative supports three data entry formats,kafka and pulsar. Each format has distinct characteristics:
kafkaformat: This provides the best performance; however, a Pulsar consumer cannot consume it unless a payload processor is employed.pulsarformat: This is the default data entry format on StreamNative cloud which supporting interoperability between Kafka and Pulsar clients, including Kafka client to Kafka client, and Pulsar client to Kafka client interactions, and vice versa. This means data between Apache Kafka and Apache Pulsar are interoperable. It is suitable for most scenarios where performance is not a critical consideration.pulsar_non_batchedformat: It is similar to pulsar entry format, the difference is this entry format will encode the Kafka batch messages to non-batched messages for Pulsar client to consume messages with a key-shared subscription, for Ursa, the behavior will be same as pulsar format.
bin/pulsar-admin topics update-properties. The configuration key is kafkaEntryFormat, and the possible values are kafka or pulsar. The default value is pulsar if not specified.
Interoperability between Pulsar and Kafka clients
With thekafka entry format, Kafka producers can produce and consume messages directly and freely. However, Pulsar producers SHOULD NOT produce messages in these topics because they are unable to encode messages into a format consumable by Kafka clients.
However, since version 2.9 of the Pulsar client, we introduced a message payload processor for Pulsar consumers. This means that messages produced from Kafka producers can now be consumed and decoded by Pulsar consumers.
For the pulsar format, it allows messages to be freely produced and consumed between Kafka and Pulsar clients. The message format conversion is automatically handled by the broker, enabling more flexible use of either Kafka clients or Pulsar clients.
Details for the message format conversion with pulsar format
The conversion is mostly intuitive except for some edge cases. Take the following simple case for example,
- key: the key used for routing the message to a specific partition
- headers: a list of headers, each header is a key-value pair
- key: the same as Kafka’s key
- ordering key: the key used for
Key_Sharedsubscriptions - properties: a list of properties, each property is a key-value pair
byte[] in Kafka, while in Pulsar, the types of key and property value are both String. For keys, each key will be converted to a base64-encoded string as Pulsar’s key. See the following example:
getKeyBytes() or getOrderingKey() to retrieve the original keys of Kafka messages. The anti-intuitive behavior is that the getKey() method will return the base64-encoded string. This behavior is made because the byte array could vary after the bytes -> UTF-8 string -> bytes conversion, for example:
- For a header key, there could be multiple values in a Kafka message but there is only a single property value for a given property key in a Pulsar message.
- There is no way to get the bytes of a Pulsar property value.
- Convert the bytes directly as a UTF-8 string
- If the bytes is not a valid UTF-8 string’s bytes, convert it to a base64 encoded string.
__ksn_internal_header_format will be received by the Pulsar consumer if there is a header value that is a base64-encoded string’s bytes.
Step to Produce msg with Kafka and Consume msg with Pulsar client
Requirements Pulsar Client Version ≥ 2.9 Pulsar Admin Version ≥ 2.10 Step- Create topic with kafka format via Pulsar admin CLI
The kafka format can be following the same step, and using
kafkaEntryFormat=kafka property.-
Install client libraries
-
Kafka Producer and Pulsar Consumer with Kafka format
Step to Produce msg with Pulsar and Consume msg with Kafka client
-
Create topic with pulsar format via Pulsar admin CLI
-
Install client libraries
-
Pulsar Producer and Kafka Consumer with Pulsar format
Step to Produce msg with Kafka client and Consume msg with Pulsar key-shared subscription
-
Create topic with pulsar format via Pulsar admin CLI
-
Install client libraries
-
Kafka Producer and Pulsar Consumer with
pulsar_non_batchedformat
Interoperability between Kafka and Pulsar Transactions
Currently, it is not possible to interoperate Kafka and Pulsar transactions together. You must choose one or the other because they use different mechanisms to store transactional states.Interoperability between Kafka and Pulsar Schema
StreamNative Cloud supports both the Kafka and Pulsar schema registries as central repositories to store registered schema information, which enables producers and consumers to coordinate the schema of a topic’s messages through brokers. However, Kafka schemas and Pulsar schemas cannot be used simultaneously due to their differing API definitions and schema storage locations. We also plan to achieve a unified schema registry, which will support both Kafka and Pulsar schemas. This will allow for the exchangeable production and consumption of messages with schema using both Pulsar and Kafka clients:- Pulsar consumers will be able to consume messages with schema produced by Kafka producers.
- Kafka consumers will be able to consume messages with schema produced by Pulsar producers.
Use Pulsar admin to get KSN producer and consumer stats
After the pulsar version3.3.5.1 or 4.0.1.1, we can use the pulsar-admin CLI to get the KSN’s topic producer and consumer stats.
- Ursa Engine currently only supports namespace level stats.
- If you’re creating a Pulsar subscription on this topic, do not use
__ksn_internal_subscriptionas the subscription name.
{clusterName}-{generatorInstanceId}-{counter}, and the consumer’s name is __KSN__internal_consumer_{remoteAddress}. The subscription name is __ksn_internal_subscription.
The internal producer and consumer will not send or consume messages, nor will they acknowledge messages or affect message retention.
You can use the following command to get the stats:
