The Tablestore sink connector polls Kafka for messages from subscribed topics, parses the message records, and batch imports the data into a Tablestore data table.
Prerequisites
-
Kafka is installed, and both ZooKeeper and Kafka are running. For more information, see the official Kafka documentation.
-
Activate the Tablestore service, and then create an instance and a data table. For more information, see Quick Start for wide table models.
NoteYou can also use the Tablestore sink connector to automatically create the destination data table. To do this, set the `auto.create` parameter to `true`.
-
Obtain an AccessKey. For more information, see Create an AccessKey.
Step 1: Deploy the Tablestore Sink Connector
-
You can obtain the Tablestore sink connector in one of the following ways.
-
Download and compile the source code from GitHub. The source code is available at Tablestore Sink Connector source code.
-
Run the following command to download the Tablestore sink connector source code.
git clone https://github.com/aliyun/kafka-connect-tablestore.git -
Go to the downloaded source code directory and run the following command to package the code using Maven.
mvn clean package -DskipTestsAfter the compilation is complete, the generated package, such as kafka-connect-tablestore-1.0.jar, is stored in the target directory.
-
-
Download the compiled kafka-connect-tablestore package.
-
-
Copy the package to the $KAFKA_HOME/libs directory on each node.
Step 2: Start the Tablestore Sink Connector
The Tablestore sink connector supports two running modes: standalone and distributed. You can choose a mode based on your requirements.
Standalone mode
-
Modify the worker configuration file connect-standalone.properties and the connector configuration file connect-tablestore-sink-quickstart.properties as needed.
-
Example of the worker configuration file connect-standalone.properties
The worker configuration includes parameters such as Kafka connection settings, serialization format, and offset commit frequency. This example is based on the official Kafka documentation. For more information, see Kafka Connect.
# Licensed to the Apache Software Foundation (ASF) under one or more # contributor license agreements. See the NOTICE file distributed with # this work for additional information regarding copyright ownership. # The ASF licenses this file to You under the Apache License, Version 2.0 # (the "License"); you may not use this file except in compliance with # the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # These are defaults. This file just demonstrates how to override some settings. bootstrap.servers=localhost:9092 # The converters specify the format of data in Kafka and how to translate it into Connect data. Every Connect user will # need to configure these based on the format they want their data in when loaded from or stored into Kafka key.converter=org.apache.kafka.connect.json.JsonConverter value.converter=org.apache.kafka.connect.json.JsonConverter # Converter-specific settings can be passed in by prefixing the Converter's setting with the converter we want to apply # it to key.converter.schemas.enable=true value.converter.schemas.enable=true offset.storage.file.filename=/tmp/connect.offsets # Flush much faster than normal, which is useful for testing/debugging offset.flush.interval.ms=10000 # Set to a list of filesystem paths separated by commas (,) to enable class loading isolation for plugins # (connectors, converters, transformations). The list should consist of top level directories that include # any combination of: # a) directories immediately containing jars with plugins and their dependencies # b) uber-jars with plugins and their dependencies # c) directories immediately containing the package directory structure of classes of plugins and their dependencies # Note: symlinks will be followed to discover dependencies or plugins. # Examples: # plugin.path=/usr/local/share/java,/usr/local/share/kafka/plugins,/opt/connectors, #plugin.path= -
Sample connector configuration file: connect-tablestore-sink-quickstart.properties
The connector configuration includes parameters such as the connector class, Tablestore connection, and data mapping. For more information, see Configuration.
# Set the connector name. name=tablestore-sink # Specify the connector class. connector.class=TableStoreSinkConnector # Set the maximum number of tasks. tasks.max=1 # Specify the list of Kafka topics from which to export data. topics=test # The following are the Tablestore connection parameter settings. # The endpoint of the Tablestore instance. tablestore.endpoint=https://xxx.xxx.ots.aliyuncs.com # Your AccessKey ID and AccessKey secret. tablestore.access.key.id =xxx tablestore.access.key.secret=xxx # The Tablestore instance name. tablestore.instance.name=xxx # A format string for the destination Tablestore table name. <topic> is a placeholder for the original topic name. The default value is <topic>. # Examples: # table.name.format=kafka_<topic>, message records from the 'test' topic will be written to the 'kafka_test' data table. # table.name.format= # The primary key mode. The default value is kafka. # The primary key of the Tablestore data table will be composed of <topic>_<partition> (the Kafka topic and partition, separated by "_") and <offset> (the offset of the message record in the partition). # primarykey.mode= # Automatically create the destination table. The default value is false. auto.create=true
-
-
Go to the $KAFKA_HOME directory and run the following command to start the connector in standalone mode.
bin/connect-standalone.sh config/connect-standalone.properties config/connect-tablestore-sink-quickstart.properties
Distributed mode
-
Modify the worker configuration file connect-distributed.properties as needed.
The worker configuration includes parameters such as Kafka connection settings, serialization format, and offset commit frequency. It also specifies the topics that store information for each connector. You must create these topics in advance. This example is based on the official Kafka documentation. For more information, see Kafka Connect.
-
offset.storage.topic: A compact topic used to store the offsets for each connector.
-
config.storage.topic: A compact topic used to store connector and task configurations. The number of partitions for this topic must be set to 1.
-
status.storage.topic: A compact topic used to store Kafka Connect status information.
## # Licensed to the Apache Software Foundation (ASF) under one or more # contributor license agreements. See the NOTICE file distributed with # this work for additional information regarding copyright ownership. # The ASF licenses this file to You under the Apache License, Version 2.0 # (the "License"); you may not use this file except in compliance with # the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ## # This file contains some of the configurations for the Kafka Connect distributed worker. This file is intended # to be used with the examples, and some settings may differ from those used in a production system, especially # the `bootstrap.servers` and those specifying replication factors. # A list of host/port pairs to use for establishing the initial connection to the Kafka cluster. bootstrap.servers=localhost:9092 # unique name for the cluster, used in forming the Connect cluster group. Note that this must not conflict with consumer group IDs group.id=connect-cluster # The converters specify the format of data in Kafka and how to translate it into Connect data. Every Connect user will # need to configure these based on the format they want their data in when loaded from or stored into Kafka key.converter=org.apache.kafka.connect.json.JsonConverter value.converter=org.apache.kafka.connect.json.JsonConverter # Converter-specific settings can be passed in by prefixing the Converter's setting with the converter we want to apply # it to key.converter.schemas.enable=true value.converter.schemas.enable=true # Topic to use for storing offsets. This topic should have many partitions and be replicated and compacted. # Kafka Connect will attempt to create the topic automatically when needed, but you can always manually create # the topic before starting Kafka Connect if a specific topic configuration is needed. # Most users will want to use the built-in default replication factor of 3 or in some cases even specify a larger value. # Since this means there must be at least as many brokers as the maximum replication factor used, we'd like to be able # to run this example on a single-broker cluster and so here we instead set the replication factor to 1. offset.storage.topic=connect-offsets offset.storage.replication.factor=1 #offset.storage.partitions=25 # Topic to use for storing connector and task configurations; note that this should be a single partition, highly replicated, # and compacted topic. Kafka Connect will attempt to create the topic automatically when needed, but you can always manually create # the topic before starting Kafka Connect if a specific topic configuration is needed. # Most users will want to use the built-in default replication factor of 3 or in some cases even specify a larger value. # Since this means there must be at least as many brokers as the maximum replication factor used, we'd like to be able # to run this example on a single-broker cluster and so here we instead set the replication factor to 1. config.storage.topic=connect-configs config.storage.replication.factor=1 # Topic to use for storing statuses. This topic can have multiple partitions and should be replicated and compacted. # Kafka Connect will attempt to create the topic automatically when needed, but you can always manually create # the topic before starting Kafka Connect if a specific topic configuration is needed. # Most users will want to use the built-in default replication factor of 3 or in some cases even specify a larger value. # Since this means there must be at least as many brokers as the maximum replication factor used, we'd like to be able # to run this example on a single-broker cluster and so here we instead set the replication factor to 1. status.storage.topic=connect-status status.storage.replication.factor=1 #status.storage.partitions=5 # Flush much faster than normal, which is useful for testing/debugging offset.flush.interval.ms=10000 # These are provided to inform the user about the presence of the REST host and port configs # Hostname & Port for the REST API to listen on. If this is set, it will bind to the interface used to listen to requests. #rest.host.name= #rest.port=8083 # The Hostname & Port that will be given out to other workers to connect to i.e. URLs that are routable from other servers. #rest.advertised.host.name= #rest.advertised.port= # Set to a list of filesystem paths separated by commas (,) to enable class loading isolation for plugins # (connectors, converters, transformations). The list should consist of top level directories that include # any combination of: # a) directories immediately containing jars with plugins and their dependencies # b) uber-jars with plugins and their dependencies # c) directories immediately containing the package directory structure of classes of plugins and their dependencies # Examples: # plugin.path=/usr/local/share/java,/usr/local/share/kafka/plugins,/opt/connectors, #plugin.path= -
-
Go to the $KAFKA_HOME directory and run the following command to start the connector in distributed mode.
ImportantStart the worker process on each node.
bin/connect-distributed.sh config/connect-distributed.properties -
You can manage connectors using the REST API. For more information, see REST API.
-
Create the connect-tablestore-sink-quickstart.json file in the config path and add the following example content.
The connector configuration file specifies parameters as key-value pairs in the JSON format. These parameters include the connector class, Tablestore connection settings, and data mapping. For more information, see Configuration.
{ "name": "tablestore-sink", "config": { "connector.class":"TableStoreSinkConnector", "tasks.max":"1", "topics":"test", "tablestore.endpoint":"https://xxx.xxx.ots.aliyuncs.com", "tablestore.access.key.id":"xxx", "tablestore.access.key.secret":"xxx", "tablestore.instance.name":"xxx", "table.name.format":"<topic>", "primarykey.mode":"kafka", "auto.create":"true" } } -
Run the following command to start the Tablestore sink connector.
curl -i -k -H "Content-type: application/json" -X POST -d @config/connect-tablestore-sink-quickstart.json http://localhost:8083/connectorshttp://localhost:8083/connectorsis the address of the Kafka REST service. Modify this address as needed.
-
Step 3: Produce new records
-
Go to the $KAFKA_HOME directory and run the following command to start a console producer.
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic testFor a description of the parameters, see the following table.
Configuration Item
Example
Description
--broker-list
localhost:9092
The address and port of the Kafka cluster broker.
--topic
test
The topic name. The topic is automatically created by default when the Tablestore Sink Connector starts. You can also create the topic manually.
-
Write messages to the test topic.
-
Struct-type message
{ "schema":{ "type":"struct", "fields":[ { "type":"int32", "optional":false, "field":"id" }, { "type":"string", "optional":false, "field":"product" }, { "type":"int64", "optional":false, "field":"quantity" }, { "type":"double", "optional":false, "field":"price" } ], "optional":false, "name":"record" }, "payload":{ "id":1, "product":"foo", "quantity":100, "price":50 } } -
Map-type message
{ "schema":{ "type":"map", "keys":{ "type":"string", "optional":false }, "values":{ "type":"int32", "optional":false }, "optional":false }, "payload":{ "id":1 } }
-
-
Log on to the Tablestore console to view the data.
A data table named test is automatically created in the Tablestore instance. The query result table contains the following columns: topic_partition (primary key), offset (primary key), id, price, product, and quantity. In the sample data, the first record has topic_partition=
test_3, offset=0, id=AAAAAQ==, and other fields are empty. The second record has topic_partition=test_34, offset=0, id=1, price=50.0, product=foo, and quantity=100.