> 小 T 導讀：TDengine Kafka Connector 在 TDengine 的官方文件上放出來已經有一段時間了，我們也收到了一些開發者的反饋。文件中的教程使用 Confluent 平臺（整合了 Kafka）演示瞭如何使用 Source Connector 和 Sink Connector，但是很多開發者在生產環境中並沒有使用 Confluent，所以為方便大家，本文將使用獨立部署的 Kafka 來演示。

本文包含以下內容：

1. 如何使用 TDengine Sink Connector， 把資料從 Kafka 同步到 TDengine。
2. TDengine Sink Connector 的實現原理。
3. 一個簡單的測試指令碼，幫助你在自己的環境中快速測試。透過更改生成測試資料的程式和配置引數，你可以模擬自己的使用場景。
4. 測試同步同一個 topic，使用不同分割槽數和不同 Sink 任務數對效能的影響。

**背景知識**

如果你對文章開頭出現的術語並不陌生，那麼可以跳過這一部分。

**· 什麼是 Kafka？**
Kafka 的核心是一個通用的、分散式的、可重複消費的訊息佇列。

與之相比，作為一款時序資料庫（Time-Series Database），TDengine 也可看作針對結構化的時序資料的訊息佇列。

**· 什麼是 Kafka Connect? 為什麼使用 Kafka Connect？**
Kafka Connect 是 Kafka 的一個元件，簡化了 Kafka 與其它資料來源的整合。使用者透過 Kafka Connect 讀寫 Kafka；透過 Kafka Connect 外掛（也稱 Kafka Connector）來讀寫各種資料來源。

為方便整合，Kafka 已經提供了生產者和消費者 API 以及客戶端庫，那為什麼還需要 Kafka Connect 呢？因為一個好的 Kafka 客戶端程式，不是單單生產或消費資料，還需要考慮容錯、重啟、日誌、彈性伸縮、序列化以及反序列化等。當開發者自己完成了這一切，就相當於開發了一個和 Kafka Connect 類似的東西。

與 Kafka 整合是 Kafka Connect 已經解決的問題，使用者不需要重複造輪子，只有少數邊緣場景才需要定製化的整合方案。

**TDengine Sink Connector 的實現原理**

TDengine Sink Connector 用於將 Kafka 中指定 topic 的資料（批次或實時）同步到 TDengine 的 database 中。

啟動 Sink Connector 需要一個 properties 配置檔案。詳細配置見官方文件的配置參考。

Sink Connector 內部的實現非常簡單，整體工作流程分為以下幾個步驟：
1. Connect 框架根據配置啟動 N 個消費者執行緒。
2. N 個消費者同時訂閱資料，並用配置檔案中指定的 key.converter 和 value.converter 做反序列化。
3. Connect 框架把反序列化後的資料傳遞給 N 個 SinkTask 的例項。
4. SinkTask 使用 TDengine 提供的 schemaless 寫入介面來寫入資料。

上述 4 個步驟，只有最後一步寫資料是 Sink Connector 需要關心的，其它都是 Connect 框架自動實現的。

下面重點討論幾個問題。
**· 支援的資料格式**
因為使用了 schemaless 寫入介面，因此 TDengine Sink Connector 只支援三種格式的資料：InfluxDB 行協議格式、 OpenTSDB Telnet 協議格式 和 OpenTSDB JSON 協議格式。使用配置項 db.schemaless 來指定寫入時使用的資料格式。例如：
```cpp
db.schemaless=line
```
如果 Kafka 中的資料已經是這三種格式之一，那麼配置檔案中的 value.converer，只需指定為 Connnect 內建的 org.apache.kafka.connect.storage.StringConverter。
```cpp
value.converter=org.apache.kafka.connect.storage.StringConverter
```
如果 Kafka 中已有的資料不是上述三種之一，則需要實現自己的 Converter 類， 將其轉換為三種格式之一，[這個連結]( https://docs.confluent.io/platform/current/connect/concepts.html#converters"這個連結")也許能幫到你。
**· 如何指定 Consumer 的引數？**
既然 Connect 框架已經幫我們做了 Consumer 要做的事，那麼我們怎麼來控制 Consumer 的行為呢？比如如何控制 Consumer 訂閱的主題？如何控制 Consumer 每次 poll 的訊息數和時間間隔？
對於訂閱哪些主題，可以用配置項 topics 來指定。
如果想覆蓋 Consumer 的其它預設配置，可以直接在 Sink Connector 的配置檔案中編寫，但是要加字首 “consumer.override.”，比如想把每次 poll 的最大訊息數改為 3000， 可以這樣配置：
```cpp
consumer.override.max.poll.records=3000
```
**· 如何控制寫入執行緒數？**
對於 Kafka Connect Sink，task 本質上就是消費者執行緒，接收從 topic 的分割槽讀出來的資料。用配置引數 tasks.max 來控制最大任務數，一個任務一個執行緒。實際啟動的任務數還與 topic 的分割槽數有關。如果你有 10 個分割槽，並且 tasks.max 設定為 5， 那麼每個 task 會收到 2 個分割槽的資料，並跟蹤 2 個分割槽的 offsets。如果你配置的 tasks.max 比 partition 數大， Connect 會啟動的 task 數與 topic 的 partition 數相同。如果你訂閱了 5 個 topic，每個 topic 都是 1 個分割槽， 並且設定 tasks.max = 5, 那麼實際會啟動多少個任務呢？答案是 1 個， 任務數與 topic 數量沒有關係。

**TDengine Sink Connector 使用示例**

這一部分我們在一臺 Linux 伺服器上搭建測試環境，並執行簡單的示例程式。示例中將 Kafka 部署到了個人的 home 目錄。操作時請注意把路徑中的使用者名稱（bding）替換為自己的使用者名稱。

**· 環境準備**
1. Java 1.8
2. Maven
3. 安裝並啟動了 TDengine 相關服務程式：taosd 和 taosAdapter。

**第一步：安裝 Kafka**
```cpp
wget https://dlcdn.apache.org/kafka/3.2.0/kafka_2.13-3.2.0.tgz
tar -xzf kafka_2.13-3.2.0.tgz
```

編輯 .bash_profile， 加入：
```cpp
export KAFKA_HOME=/home/bding/kafka_2.13-3.2.0
export PATH=$PATH:$KAFKA_HOME/bin
```

```cpp
source .bash_profile
```

**第二步：配置 Kafka**
配置 Kafka Connect 載入外掛的路徑。
```cpp
cd kafka_2.13-3.2.0/config/
vi connect-standalone.properties
```
追加
```cpp
plugin.path=/home/bding/connectors
```
修改 Connector 外掛的日誌級別。這一步非常重要，我們將透過外掛的日誌統計同步資料花費的時間。
```cpp
vi connect-log4j.properties
```
追加
```cpp
log4j.logger.com.taosdata.kafka.connect.sink=DEBUG
```

**第三步：編譯並安裝外掛**
```cpp
git clone git@github.com:taosdata/kafka-connect-tdengine.git
cd kafka-connect-tdengine
mvn clean package
unzip -d ~/connectors target/components/packages/taosdata-kafka-connect-tdengine-*.zip
```

**第四步：啟動 ZooKeeper Server 和 Kafka Server**
```cpp
zookeeper-server-start.sh -daemon $KAFKA_HOME/config/zookeeper.properties
kafka-server-start.sh -daemon $KAFKA_HOME/config/server.properties
```

**第五步：建立 topic**
```cpp
kafka-topics.sh --create --topic meters --partitions 1 --bootstrap-server localhost:9092
```

**第六步：生成測試資料**
將下列指令碼儲存為 gen-data.py：
```cpp
#!/usr/bin/python3
import random
import sys
topic = sys.argv[1]
count = int(sys.argv[2])
start_ts = 1648432611249000000
location = ["SanFrancisco", "LosAngeles", "SanDiego"]
for i in range(count):
    ts = start_ts + i
    row = f"{topic},location={location[i % 3]},groupid=2 current={random.random() * 10},voltage={random.randint(100, 300)},phase={random.random()} {ts}"
    print(row)
```
然後執行：
```cpp
python3 gen-data.py meters 10000  | kafka-console-producer.sh --broker-list localhost:9092 --topic meters
```
生成 10000 條 InfluxDB 行協議格式的資料到 topic meters。每條資料又包含 2 個標籤欄位和 3 個資料欄位。

**第七步：啟動 Kafka Connect**
將下列配置儲存為 sink-test.properties。
```cpp
name=TDengineSinkConnector
connector.class=com.taosdata.kafka.connect.sink.TDengineSinkConnector
tasks.max=1
topics=meters
connection.url=jdbc:TAOS://127.0.0.1:6030
connection.user=root
connection.password=taosdata
connection.database=power
db.schemaless=line
key.converter=org.apache.kafka.connect.storage.StringConverter
value.converter=org.apache.kafka.connect.storage.StringConverter
```
然後執行：
```cpp
connect-standalone.sh -daemon $KAFKA_HOME/config/connect-standalone.properties sink-test.properties
```

**第八步：檢查 TDengine 中的資料**
使用 TDengine CLI 查詢 power 資料庫 meters 表，檢查是否正好包含 10000 條資料。
```cpp
[bding@vm95 test]$ taos
 
Welcome to the TDengine shell from Linux, Client Version:2.6.0.4
Copyright (c) 2022 by TAOS Data, Inc. All rights reserved.
taos> select count(*) from power.meters;
       count(*)        |
========================
                 10000 |
```

**TDengine Sink Connector 效能測試**

**· 測試流程**
這一部分，我們將上面示例步驟中的第四步到第七步封裝成可重複執行的 shell 指令碼，並做以下修改：

將 topic 的分割槽數作為指令碼的第 1 個引數， 同時配置 tasks.max，使其等於分割槽數。這樣我們可以控制每次測試使用的寫入執行緒數。
將生成測試資料的條數作為指令碼的第 2 個引數，用來控制每次測試同步的資料量。
啟動測試前清空所有資料，測試結束後停止 Connect、Kafka 和 ZooKeeper。
每次測試都先寫資料到 Kafka，然後再啟動 Connect 同步資料到 TDengine，這樣做可以把同步資料的壓力全部集中到 Sink 外掛這邊。我們統計 Sink Connector 從接收到第一批資料到接收到最後一批資料之間的時間，作為同步資料的總耗時。

完整指令碼如下：
```cpp
#!/bin/bash
if [ $# -lt 2 ];then
        echo  "Usage: ./run-test.sh <num_of_partitions>  <total_records>"
        exit 0
fi
echo "---------------------------TEST STARTED---------------------------------------"
echo clean data and logs
taos -s "DROP DATABASE IF EXISTS power"
rm -rf /tmp/kafka-logs /tmp/zookeeper
rm -f $KAFKA_HOME/logs/connect.log
np=$1     # number of partitions
total=$2  # number of records
echo number of partitions is $np, number of recordes is $total.
echo start zookeeper
zookeeper-server-start.sh -daemon $KAFKA_HOME/config/zookeeper.properties
echo start kafka
sleep 3
kafka-server-start.sh -daemon $KAFKA_HOME/config/server.properties
sleep 5
echo create topic
kafka-topics.sh --create --topic meters --partitions $np --bootstrap-server localhost:9092
kafka-topics.sh --describe --topic meters --bootstrap-server localhost:9092
echo generate test data
python3 gen-data.py meters $total  | kafka-console-producer.sh --broker-list localhost:9092 --topic meters
 
echo alter connector configuration setting tasks.max=$np
sed -i  "s/tasks.max=.*/tasks.max=${np}/"  sink-test.properties
echo start kafka connect
connect-standalone.sh -daemon $KAFKA_HOME/config/connect-standalone.properties sink-test.properties
 
echo -e "\e[1;31m open another console to monitor connect.log. press enter when no more data received.\e[0m"
read
 
echo stop connect
jps | grep ConnectStandalone | awk '{print $1}' | xargs kill
echo stop kafka server
kafka-server-stop.sh
echo stop zookeeper
zookeeper-server-stop.sh
# extract timestamps of receiving the first batch of data and the last batch of data
grep "records" $KAFKA_HOME/logs/connect.log  | grep meters- > tmp.log
start_time=`cat tmp.log | grep -Eo "[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]{3}" | head -1`
stop_time=`cat tmp.log | grep -Eo "[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]{3}" | tail -1`
 
echo "--------------------------TEST FINISHED------------------------------------"
echo "| records | partitions | start time | stop time |"
echo "|---------|------------|------------|-----------|"
echo "| $total | $np | $start_time | $stop_time |"
```
如果要測試使用 1 個分割槽，共 100 萬條資料的效能，可以這樣執行：
```cpp
./run-test.sh 1 1000000
```
執行過程的截圖如下：
![](http://img.blog.itpub.net/blog/2022/07/27/ca5ebab1897a0ba8.png?x-oss-process=style/bb)

注意中間有一個互動過程。因為指令碼無法確定資料是否同步完，需要使用者監控 connect.log 來確定是否已經消費完了所有資料，例如：
```cpp
[bding@vm95 ~]$ cd kafka_2.13-3.2.0/logs/
[bding@vm95 logs]$ tail -f connect.log
[2022-06-21 17:39:00,176] DEBUG [TDengineSinkConnector|task-0] Received 500 records. First record kafka coordinates:(meters-0-314496). Writing them to the database... (com.taosdata.kafka.connect.sink.TDengineSinkTask:101)
[2022-06-21 17:39:00,180] DEBUG [TDengineSinkConnector|task-0] Received 500 records. First record kafka coordinates:(meters-0-314996). Writing them to the database... (com.taosdata.kafka.connect.sink.TDengineSinkTask:101)
```
當日志不再滾動，就說明已經消費完了

**· 測試結果**
寫入速度與資料量和執行緒數的關係表
![](http://img.blog.itpub.net/blog/2022/07/27/3224040c79ca81d2.jpeg?x-oss-process=style/bb)

上表第 1 列為總資料量，第 1 行為消費者執行緒數，也是寫入執行緒數。中間為平均每秒寫入記錄數。

寫入速度與資料量和執行緒數的關係圖
![](http://img.blog.itpub.net/blog/2022/07/27/872df76a62c65e57.png?x-oss-process=style/bb)

**結果分析**
從上圖可以看出，相同資料量，執行緒越多寫入速度越快。當使用單執行緒寫入時，每秒能寫入大概 10 萬以上。當使用 5 個執行緒寫入時，每秒寫入大概 35 萬左右。當使用10 個執行緒時，每秒能寫入55 萬左右。

寫入速度比較平穩，與總資料量關係不大。

同時也發現執行緒增加越多，執行緒增加帶來的速度提升越少。執行緒數從 1 變到 10，速度只從 10 萬變到 50 萬。可能的原因是資料在各個分割槽分佈不均勻。有的 task 執行時間長，有的 task 執行時間短，資料量越大，資料傾斜越大。比如 1000 萬資料，10個分割槽的時候，各分割槽的資料量：
```cpp
[bding@vm95 kafka-logs]$ du -h ./ -d 1
125M    ./meters-8
149M    ./meters-7
119M    ./meters-9
138M    ./meters-4
110M    ./meters-3
158M    ./meters-6
131M    ./meters-5
105M    ./meters-0
113M    ./meters-2
99M     ./meters-1
```
另一個影響多執行緒寫入速度的是資料的亂序程度。本測試場景中，多條時間線的資料隨機分配到了不同分割槽，當單執行緒寫入時（即 1 個分割槽時），資料是嚴格有序的，寫入速度最快。執行緒越多亂序程度越大。

所以在實際應用場景中，建議將同一個子表的資料，放在 Kafka 同一個分割槽中。

**附錄
· 測試程式**
本文中用到的所有程式碼和原始測試結果資料都已上傳到 GitHub 倉庫。

**· 測試環境**
![](http://img.blog.itpub.net/blog/2022/07/27/243305448b92d5f5.jpeg?x-oss-process=style/bb)</total_records></num_of_partitions>

如何使用 TDengine Sink Connector？

相關文章