看Mars数据库怎么将190M数据压缩进1.9M的

cdy816

已于 2023-06-19 08:31:42 修改

阅读量156

点赞数 1

文章标签：数学建模物联网数据库大数据 c#

于 2023-06-17 17:35:23 首次发布

本文链接：https://blog.csdn.net/cdy816/article/details/131262578

版权

1.项目背景

Mars数据库性能测试参见某新能源车企车端数据存储项目性能测试。将车辆上各种信号定时上传到中心服务器，由于数字信号多，采集频率快，从而数据量大，造成数据上行带宽压力以及流量费用等问题，现需要能够将数据先行进行压缩后，再上传至中心服务器。测试Mars数据库的数据压缩率以及数据录入性能：指标要求1秒能够录入40条数据，同时保持较低资源占用率，数据压缩率至少在10:1。

一部新能源汽车需要需要处理的传感器信号在6000个左右，后期可能会增加1万个左右。这6000个信号中，最快的变量率在1ms,最慢的在1秒；数据量在1秒40万条记录左右，5分钟左右的数据，总量在7000万条。

2.数据准备

甲方给的是一段5分钟的parquet格式的数据量在194M大小的数据文件，同时还有一个数据信号列表数据。这194M parquet格式的数据也是压缩过后的数据，其采用时间、名称、值三列结构的表格式存储。下面先将数据解压、转换能够符合Mars数据库入库的格式的数据。

a. 借助Python脚本，将Parquet格式的数据转换成CSV格式的数据，转换成CSV格式的目的是为了下一步能够较好的读取和使用。转换成CSV格式后，文件大小在3G 左右，如下图：

b. 再以信号名称为单位将CSV格式的数据，主要原因`1是Mars数据库中是以单个信号为单位进行数据组织的。整体转换完成后，6000个二进制存储的数据文件大小在960M左右，如下图：

由此可以看出，在不进行任何压缩的状态，5分钟的数据产生的数据量在960M左右。

通过数据文件分析发现，总共6122个测点，其中模拟量:1534 数字量:4588。数据的再整理：以测点为单位重新组织数据，每个测点一个文件，文件的内容是以二进制格式存储的时间+值的集合。

6122个测点中，其中不同的测点数据变化的频率不一样，具体如下：

采集间隔 <=5ms :30 个

采集间隔 5~10ms :799 个

采集间隔 10~100ms :3471 个

采集间隔 100ms~1s :1607 个

采集间隔 >1s :215 个

采集间隔 100ms~1s :1607 个

采集间隔 >1s :215 个

3.数据库建模

Mars数据库是以变量进行数据组织的，所以根据信号的名称以及类型创建相应的变量。变量之间是松散的关系，对于有关系的变量间可以通过变量的“区域”属性进行关联，同一个区域内的变量，在做数据存储时会进行时间戳优化，能够较好进一步压缩数据；一个区域可以理解关系库中一个表，每个变量对应一列。相较于时序库的列式存储，一个变量可以理解为一列，而具有相关性的列又可以通过区域来组成一个表；相比时序库，Mars数据库既支持表格式存储，也支持松散的单列存储。建模完成后，数据库表配置如下图所示：

4.数据写入

通过针对这次测试专门开发驱动程序，写入数据到Mars数据库中。数据写入同样以变量为单位，将一个变量的5分钟的数据一次写入。

原始数据

入库过程中资源占用情况1

入库过程中资源占用情况2

可见在整个数据写入过程中，CPU资源始终维持在10%左右，而内存在在2.8G附近。写入整个5分钟7000多万条数据总耗时：40秒。压缩以后最终数据：

5.数据校验

这里我们随即抽取几个信号进行校验比对，看看写入数据是否正确。具体如下图：

6.结论

通过此次压缩测试，可见Mars数据对于这种采集频率高、数据变化缓慢的信号具有较高的压缩率。在压缩过程中，软件整体运行稳定CPU占用在10%，内存2.8G。此次测试的经过parquet压缩后数据的190M的数据，经过Mars数据压缩后达到了1.9M，取得了惊人的压缩比：100:1 。究其原因，分析如下：

Parquet 格式的原始数据，没有对信号进行细分处理。只是简单的分成3列：时间、名称、值。导致时间、名称2列中，大量重复的数据，虽然这些数据也得到了压缩，但是依然有损耗。
Mars数据库以变量信号为组织单位，在存储时，名称是不用存储的。结合区域功能，使得不同的信号共享一个时间列值，从而节省了较大的数据空间。
Mars数据库采用工业数据压缩算法，使得对不变的数据，有着极大的压缩率。