Apache IoTDB 系列教程-8：文件同步工具

在官网用户手册的系统工具（System Tools）一栏，有一个同步工具（Sync Tool），有很多人问这个东西怎么用，延迟是多少，今天就介绍一下这个工具的使用场景、基本原理和测试技巧。

正文 2439 字，预计阅读时间 7 分钟。

使用场景

某公司有多个电厂，每个电厂内部署了一个 IoTDB，负责监控电厂内多个设备的运行状态。各个电厂间数据不互通。这个时候公司想建一个云平台，汇总所有电厂的数据进行分析（这里有一个前提，云平台的数据分析主要针对长期历史数据，对数据的实时性要求不高）。这时候就可以用这个文件同步工具了。

文件同步工具的定位：将一个 IoTDB 的 Schema 和数据文件（TsFile）同步至另一个 IoTDB 中，同步过程会有一定延迟，具体延迟取决于负载和配置。

基本原理

通过名字应该能看出来，这个工具的同步粒度是数据文件，而不是每一个数据点。这也就导致同步的长延迟是一个数据文件的生成耗时（从创建文件到封口）。因为发送端必须等一个文件生成好才会同步，否则传过去半个文件也没法解析。传文件类似 scp，相对同步每条数据的好处就是避免了数据的解析和重新导入。

我们把文件同步涉及到的两个 IoTDB 称为发送端、接收端。

写入流程

为了更好的理解数据文件的生成耗时，需要简单介绍一下写入流程。

IoTDB 采用了 LSM 结构，数据先写到内存缓冲区 memtable 中，memtable 达到一定大小会落盘，多个 memtable 会对应一个数据文件。

举个例子，某个存储组有 1 个时间序列，写入频率为 1 秒，每个数据点是 16 字节。一个 memtable 大小为 160 字节，TsFile 文件大小为 200 字节。存储组刚开始有一个空的 TsFile 可供写入。

（1）memtable 次存满 10 个数据点时，提交一个异步刷盘任务（追加到当前正在写入的 TsFile 中），同时检查 TsFile 大小，这个时候还是 0 字节，先不关文件。

（2）异步的刷盘任务开始执行，刷完之后 TsFile 变成了 200 字节。


（3）memtable 第二次存满 10 个数据点时，提交一个异步刷盘任务，同时检查 TsFile 大小，发现到了 200 字节，于是就标记关文件。

（4）异步刷盘任务开始执行，刷完之后把当前 TsFile 关掉。

在这个例子里，写满 2 个 memtable （20条数据） 关闭一次文件，写入频率为 1 秒，文件的生成耗时是 20 秒左右。

同步流程

发送端定时检查本地有没有新创建的 Schema 和新生成的完整的数据文件，如果存在，就发给接收端。同步的延迟基本就是 max(同步检查间隔，文件生成耗时)。

在 iotdb-sync-client.properties 配置文件中，有一个参数sync_period_in_second，这个控制发送端检查的频率。假如配置 60 秒，那同步的长延迟就是 60秒，如果配置 10秒，那延迟就是 20秒（一个文件的生成耗时）。可以看到，同步延迟跟配置有关系，跟写入频率也有关系。

配置文件里的 sync_period_in_second 可以配的比较小，没啥大问题。主要问题是 TsFile 的生成间隔，这个由 memtable_size_threshold 和 tsfile_size_threshold 控制，这两个参数，尤其是 memtable 越大，历史数据查询越快。因此，同步能达到的低延迟和查询性能之间需要平衡。

一个比较简单的查看自己系统里文件的生成速率，可以到数据目录 data/data/存储组{/分区} 看 .resource 文件的后修改时间间隔。

测试同步

在一个机器测试同步，示例脚本为 linux 环境，版本 0.10.1。先下载二进制包，解压缩两遍重命名，一个 sender，一个 receiver。

启动接收端

cd receiver
## 配置
conf/iotdb-engine.properties 中的 is_sync_enable=true
## 启动接收端 IoTDB
nohup ./sbin/start-server.sh >/dev/null 2>&1 &
## 启动接收端 CLI，默认用 root 用户连本地 6667 端口
./sbin/start-cli.sh
启动发送端，准备数据

cd sender
## 配置
conf/iotdb-engine.properties 中的 rpc_port=6668
conf/iotdb-sync-client.properties 中的 sync_period_in_second=10
## 启动 iotdb
nohup ./sbin/start-server.sh >/dev/null 2>&1 &
## 启动发送进程
nohup ./tools/start-sync-client.sh >/dev/null 2>&1 &
## 启动发送端 CLI，注意，改到 6668 端口了
./sbin/start-cli.sh -h 127.0.0.1 -p 6668 -u root -pw root
## 输入
insert into root.turbine1.d1(timestamp,s1,s3) values(2,1,3);
flush （这个是精髓，强制把 memtable 刷盘，文件封口）
接收端验证数据

## 在接收端 CLI 中输入
select * from root
如果想自己配置，需要先把 enable_parameter_adapter 置为 false，不然系统会自动调 memtable 和 tsfile 大小。

具体可参考用户手册，也可点阅读原文跳过去。

http://iotdb.apache.org/zh/UserGuide/V0.10.x/System%20Tools/Sync%20Tool.html

总结

文件同步适合对实时性要求没那么高的数据汇总，备份。秒级或分钟级的同步就需要换方案了。在实验中遇到数据没同步过去的，要么是同步的定时检查间隔设置的过长了，要么是文件没关闭，现在还没有定时关文件的机制，需要手动调用 flush。对了，提示一个东西，start-cli.sh 脚本也可以连远端的 iotdb，加上 -h -p -u -pw 参数就行了。
————————————————
版权声明：本文为CSDN博主「铁头乔」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qiaojialin/article/details/107873047