实验目的

1. 读一个TsFile的磁盘IO代价和CPU代价的大小比较
2. 了解CPU代价里有没有突出的耗时瓶颈操作

实验设计

分析TsFile文件结构，然后把读取TsFile的耗时步骤进行分解和分类，最后进行实验测量统计。

TsFile结构

TsFile读耗时步骤分解与分类

回答实验目的1：分析A、B、C、D-1、D-2类操作耗时占比，对比B类操作（磁盘IO代价所在）和D类操作（CPU代价主要所在）耗时

回答实验目的2：分析D-1操作内部各子步骤耗时占比、D-2操作内部各子步骤耗时占比

实验结论

1. 本次实验使用的人工数据集不具有代表性：其时间戳从1开始以步长1递增，值在[0,100)随机取整数，导致时间戳的编码压缩效率过高、值列的编码压缩效率过低。甚至对于值列来说，和其它编码方式相比，采用PLAIN编码的空间大小是最小的。
2. 在中车ZT11529数据集上的实验结果来看：
   
   • 真实数据集的压缩率高、磁盘数据量相对小，此时【从磁盘加载Chunk数据的耗时】小于【解压缩和解码Page数据的耗时】，即整体耗时瓶颈不是磁盘IO。
   • D-1步骤内部的耗时瓶颈就是子步骤7_2_data_decompress_PageDataByteArray。注意：人工数据实验里发现另一个子步骤7_1_data_ByteBuffer_to_ByteArray(us)的占比也高，分析是因为人工数据压缩率很低，子步骤7_2_data_decompress_PageDataByteArray(us)耗时相对少，从而7_1_data_ByteBuffer_to_ByteArray(us)耗时占比相对偏高。
   • D-2类操作内部没有某一个子步骤是突出的耗时瓶颈。
   • 相对其它压缩方法，GZIP的压缩率最高，但磁盘加载IO代价和解压缩代价之间有tradeoff，GZIP压缩下的整体读耗时并不是最小的。
3. 后续
   1. 可以增大真实数据集的数据量之后再实验看看，目前使用的中车数据量级是一千万点。
   2. D-1解压缩和D-2解码的空间压缩关系和耗时关系还有待探索
   3. 写数据的耗时可以也测量一下
   4. 注意RLE编码对于浮点数是有损的

实验设置

IoTDB版本

• v0.13.1

实验环境

• FIT楼166.111.130.101 / 192.168.130.31
• CPU：Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz，(6核12线程)
• L1 cache 284KB, L2 cache 1536KB, L3 cache 12MB
• 内存：16G
• 硬盘：1.8T HDD /dev/sdb1 mounted on /disk
• 操作系统：Ubuntu 16.04.7 LTS
• 工作文件夹：/disk/rl/tsfileReadExp/

数据集

（1）人工数据：时间戳从1开始以步长1递增，值在[0,100)随机取整数。

（2）中车数据：/disk/rl/zc_data/ZT11529.csv，这条传感器时间序列数据共12,780,287个点，其部分数据作图和csv部分截图如下所示。

实验工具

• 可执行jar包和脚本：https://github.com/LeiRui/exp0913.git

• 实验源码：https://github.com/LeiRui/iotdb/blob/cost2/tsfile/src/main/java/org/apache/iotdb/tsfile/read/RLTsFileReadCostBench.java

RLTsFileReadCostBench用法

(1) 用人工数据写TsFile

java -jar RLTsFileReadCostBench-0.13.1-jar-with-dependencies.jar WRITE_SYN [pagePointNum] [numOfPagesInChunk] [chunksWritten] [timeEncoding] [valueDataType] [valueEncoding] [compressionType]

• WRITE_SYN：用来标识是“写人工数据/写真实数据/读数据”中的“写人工数据”

• pagePointNum(ppn)：一个page内的点数

• numOfPagesInChunk(pic)：一个chunk内的pages数

• chunksWritten(cw)：写的chunks总数

• timeEncoding(te)：时间戳列编码方式

• valueDataType(vt)：值列数据类型

• valueEncoding(ve)：值列编码方式

• compressionType(co)：压缩方式

(2) 用真实数据集写TsFile

java -jar RLTsFileReadCostBench-0.13.1-jar-with-dependencies.jar WRITE_REAL [path_of_real_data_csv_to_write] [pagePointNum] [numOfPagesInChunk] [timeEncoding] [valueDataType] [valueEncoding] [compressionType]

• WRITE_REAL：用来标识是“写人工数据/写真实数据/读数据”中的“写真实数据”

• path_of_real_data_csv_to_write：用来写TsFile的真实数据集csv地址

• pagePointNum(ppn)：一个page内的点数

• numOfPagesInChunk(pic)：一个chunk内的pages数

• timeEncoding(te)：时间戳列编码方式

• valueDataType(vt)：值列数据类型

• valueEncoding(ve)：值列编码方式

• compressionType(co)：压缩方式

(3) 读实验

java -jar RLTsFileReadCostBench-0.13.1-jar-with-dependencies.jar READ [path_of_tsfile_to_read] [decomposeMeasureTime] [D_decompose_each_step] (timeEncoding)

• WRITE_REAL：用来标识是“写人工数据/写真实数据/读数据”中的“读数据”

• path_of_tsfile_to_read：要读取的TsFile地址

• decomposeMeasureTime：FALSE to measure the read process as a whole, in which case D_decompose_each_step is useless. TRUE to measure the decomposed read process, and the decomposition granularity is controlled by D_decompose_each_step.

• D_decompose_each_step：When decomposeMeasureTime is TRUE, D_decompose_each_step=FALSE to measure the "(D_1)decompress_pageData" and "(D_2)decode_pageData" steps without further deomposition, D_decompose_each_step=TRUE to break down these two steps further and measure substeps inside.

• timeEncoding(te)：If timeEncoding is not specified, TS_2DIFF will be used by default. timeEncoding should be the same with that used to write the TsFile.

自动化脚本

(1) RLUnitSynExp.sh：用人工数据写TsFile，清空系统缓存，然后进行一次读TsFile实验。

• 输入：见RLTsFileReadCostBench的写数据参数和读数据参数
• 输出：一个TsFile文件、一个TsFile空间统计结果文件（ *writeResult.csv）、一个读TsFile耗时结果csv文件（ *readResult-T*csv）

(2) RLUnitRealExp.sh：用真实数据写TsFile，清空系统缓存，然后进行一次读TsFile实验。

• 输入：见RLTsFileReadCostBench的写数据参数和读数据参数

• 输出：一个TsFile文件、一个TsFile空间统计结果文件（ *writeResult.csv）、一个读TsFile耗时结果csv文件（ *readResult-T*csv）

(3) RLReadExpScripts.sh：重复若干次读实验，把读实验结果进行汇总，把写文件的空间结果和读文件的耗时结果汇总到一起，最后对读实验结果进行平均值和百分比统计计算。

• 输入：

  • WRITE_READ_JAR_PATH：RLTsFileReadCostBench-0.13.1-jar-with-dependencies.jar的地址

  • Calculator_JAR_PATH：把若干次重复读实验结果进行平均值和百分比计算的RLRepeatReadResultAvgPercCalculator-0.13.1-jar-with-dependencies.jar的地址

  • FILE_NAME：要读取的TsFile的地址

  • decomposeMeasureTime：见RLTsFileReadCostBench读数据参数

  • D_decompose_each_step：见RLTsFileReadCostBench读数据参数

  • te：：见RLTsFileReadCostBench读数据参数

  • REPEAT：读实验重复次数

• 输出：

  • REPEAT个读TsFile耗时结果csv文件 *readResult-T*csv

  • 一个把重复读实验结果横向拼接起来的csv文件 *readResult-combined.csv

  • 一个把写结果和读结果拼接起来的csv文件 *allResult-combined.csv

  • 一个把读结果取平均值并且按照不同粒度统计百分比的csv文件 *allResult-combined-processed.csv

(4) RLCompressionExpScripts.sh：在不同的压缩方式参数下（UNCOMPRESSED, SNAPPY, GZIP, LZ4），写TsFile，清空系统缓存，然后进行若干次重复读TsFile实验，把读实验结果进行汇总，把写文件的空间结果和读文件的耗时结果汇总到一起，最后对读实验结果进行平均值和百分比统计计算。

• 输入：

  • 工具地址：

    • WRITE_READ_JAR_PATH：RLTsFileReadCostBench-0.13.1-jar-with-dependencies.jar的地址

    • Calculator_JAR_PATH：把若干次重复读实验结果进行平均值和百分比统计计算的RLRepeatReadResultAvgPercCalculator-0.13.1-jar-with-dependencies.jar的地址

    • TOOL_PATH：用于替换脚本中变量值的自动脚本工具RLtool.sh的地址

    • READ_SCRIPT_PATH：RLReadExpScripts.sh的地址

  • 写数据参数：见RLTsFileReadCostBench写数据参数

  • 读数据参数：见RLTsFileReadCostBench读数据参数

  • REPEAT：读实验重复次数

• 输出：不同压缩方式下的一个TsFile文件、一个TsFile空间统计结果文件（ *writeResult.csv）、REPEAT个读TsFile耗时结果csv文件（ *readResult-T*csv）、一个把重复读实验结果横向拼接起来的csv文件（*readResult-combined.csv）、一个把写结果和读结果拼接起来的csv文件（*allResult-combined.csv）、一个把读结果取平均值并且按照不同粒度统计百分比的csv文件（ *allResult-combined-processed.csv）

其它类似，不再赘述。

实验具体结果

中车数据实验结果

改变压缩方式

RLCompressionRealExpScripts.sh

补充实验

时间戳和值都使用PLAIN编码，然后改变压缩。

RLCompressionRealExpScripts.sh

• 可以看到，当时间戳列和值列都使用PLAIN编码之后，压缩负责了全部的压缩率，此时D-1操作和耗时占比有了明显提高；但是也可以看到，即便如此，除了GZIP之外的压缩方式的D-1耗时占比也没有增大到60%以上，D-2解码操作仍然有不小的基础耗时

改变值列编码方式

RLValueEncodingRealExpScripts.sh

人工数据实验结果

改变压缩方式

RLCompressionSynExpScripts.sh

• B类操作耗时超过D类操作耗时，分析原因：使用的人工数据数值是INT64类型的随机取整的数，且PLAIN编码，且四种压缩方式此时的压缩率都不高，所以磁盘数据量偏大。
• D-1类操作内部7_1_data_ByteBuffer_to_ByteArray占比偏大，分析原因：人工数据压缩率低，解压缩7_2_data_decompress_PageDataByteArray耗时相对少，从而7_1_data_ByteBuffer_to_ByteArray相对占比变大。

改变值列编码方式

RLValueEncodingSynExpScripts.sh