CREATE TABLE instead of CREATE SOURCE and specifying the connection settings and data format.
Syntax
For Avro and Protobuf data, do not specify
schema_definition in the CREATE SOURCE or CREATE TABLE statement. The schema should be provided in a Web location in the option schema.location in ENCODE properties section.Connector parameters
Other parameters
Message acknowledgment
Added in v2.7.0.
subscription.unacked.resend.delay parameter to control when the broker resends unacknowledged messages.
If you need to bound retryable Pulsar client operations on the source side, configure pulsar.operation.retry.max.retries and pulsar.operation.retry.delay. These options control Pulsar client retries in RisingWave and do not change broker-side redelivery behavior.
Example
Read from compacted topics
Pulsar supports topic compaction, which retains only the latest message for each key in a topic. When you enablepulsar.read_compacted, RisingWave reads only the compacted view of the topic, providing the most recent value for each key.
This is useful when you want to read the current state of entities without processing all historical updates.
Example
user_id, only the latest status for each user will be read from the compacted topic.
The
pulsar.read_compacted option cannot be changed after the source or table is created.Read schemas from locations
RisingWave supports reading schemas from a Web location inhttp://..., https://..., or S3://... format for Pulsar data in Avro or Protobuf format.
For Protobuf, if a schema location is specified, the schema file must be a FileDescriptorSet, which can be compiled from a .proto file with a command like this:
CREATE SOURCE statement.
Example
Here is an example of connecting RisingWave to a Pulsar broker to read data from individual topics.- Avro
- JSON
- Protobuf