企业官网建设流程全解析

面对千亿级时序数据，KES如何实现存储压缩与快速写入？

最近这几年，搞工业互联网的同行越来越多了。大家坐下来一聊天，都在吐槽同一个事。那就是设备监测的数据、电力采集的数据，还有生产线上那些指标数据，这个量涨得太猛了。这种时序数据，只要你设备开着，它就源源不断地冒出来。

对于那种要长期跑的业务系统来说，时序数据库要干的活可不轻。你得让数据能实时写进去。还得让数据能查出来。但这还不是最要命的。最要命的是，这些海量的历史数据你要存很久。存久了，怎么把这些历史数据快速加载出来，怎么高效管理它们，这就成了大麻烦。

工业场景下的时序数据，特点非常鲜明。规模大，增长快，而且还得保存很长周期。针对这些个情况，金仓时序数据库（也就是KES时序版）在存储压缩、历史数据快速插入，还有时序数据组织优化上，下了很大功夫。今天我就跟大家好好拆解一下，看看它是怎么帮企业层级里的业务实现低成本存储和高效率处理的。

一、时序数据到底是个啥头疼问题

在讲技术之前，咱们先得把痛点摸清楚。不搞清楚痛点，你就不知道KES为啥要这么设计。

1.1 数据量太大存不起

时序数据这东西，通常来说都是按固定的周期一直采样的。比如一个温度传感器，每秒钟给你报一次数。一天就是86400条。如果你有上万个传感器，一天的数据量就吓死人了。

相邻时间点的数据，其实规律性很强。比如室温，这一秒是25度，下一秒大概率也是25度，或者25.1度。如果你用传统数据库那种存法，每一条都原样存下来。那这些重复的信息就会占满你的硬盘。数据存着存着，硬盘就不够用了。存储成本一直往上涨，老板肯定不乐意。

1.2 历史数据搬进去太慢

还有个场景也很常见。就是系统升级，或者你要建个新的数据平台。这时候，你往往需要把好几年积累的历史数据，搬到新的库里去。

这个数据量通常是TB级别的，甚至更大。如果你用传统的数据导入方式，通常来说会很慢。为啥呢？因为传统写入它要校验，要建索引，要写日志。一遇到大规模数据迁移，写入效率就顶不住。数据准备的时间拉得很长，业务想赶紧上线，只能干瞪眼。

二、KES是怎么把数据压扁的

存不起的问题出现了，这是一个大问题。那为什么会这样呢？原因就在于传统方式没利用好时序数据的规律。KES的做法就是针对这个下手的。

2.1 时序数据有啥规律可循

刚才我说了，时序数据相邻的数据点变化不大。这其实就是它最大的规律。KES的存储引擎，就是专门针对这个规律做了优化。它不是像传统数据库那样，有啥存啥。它是在存之前，先对数据进行一番处理。

2.2 几个关键的压缩招数

KES里面用了好几个压缩算法。我给大家用大白话解释一下。

第一个是Delta-of-Delta差值编码。这名字听着挺唬人。其实也就是算差值。比如时间戳是1, 2, 3, 4。你存1234要占不少空间。但如果你存1, 1, 1, 1（后一个减前一个），是不是就简单了？如果再减一次，就变成了1, 0, 0, 0。存0多省空间啊。

第二个是Gorilla XOR压缩。这个是专门对付浮点数的。时序数据里像温度、压力这种带小数点的数特别多。XOR就是异或运算。相邻的两个浮点数，其实大部分位都是一样的。异或运算之后，结果里会有很多0。然后它就只存那些不是0的部分。这样一下就把浮点数给压小了。

第三个是字典编码。有些标签值，比如设备状态“运行”、“停止”、“故障”。它就那么几个固定的词。KES就建个小字典，把“运行”变成数字1，“停止”变成数字2。存数字肯定比存汉字省地方。

第四个是列式存储优化。时序数据按列存，比按行存好压缩多了。因为一列里的数据类型完全一样，规律性更强。压起来效果自然好。

2.3 实际压缩效果咋样

说这么多理论没用，得看实操。我之前接触过某省智能电表的项目。那个场景是真的变态。有500万个观测点。跑了一年，总共有1956亿行数据。这个数你想一下，存在传统库里得多少硬盘。

当时就是用的KES时序数据库。实测出来的压缩比高达45：1。也就是说，本来你要买45块硬盘的量，现在1块就够了。这个压缩比，是约业界的3.6倍。光硬盘钱就省了一大笔，这就很能说明问题了。

三、KES如何搞定历史数据快速写入

压缩的事搞定了，接着说说写入的事。历史数据要迁移，写入速度如果上不去，那工程周期就没法看。

3.1 传统导入为啥慢

大家如果用过传统关系库的COPY命令或者INSERT批量插入，应该有体会。数据一多，它就慢了。那为什么会慢呢？原因在于它一边写，一边还要去更新索引，还要记WAL日志，还要检查约束。这就好比你在记账，旁边一个人不停问你这笔对不对，那个数加没加对。你肯定快不了。

3.2 面向时序的写入路径优化是啥意思

KES针对时序场景，把写入路径给改了。它一看你是历史数据批量导入，它就知道这些数据是过去的，不需要像实时数据那样严格的逐条校验。它会把写入操作在内存里先攒一大波。攒够了，然后一次性顺序地写到磁盘里。顺序写磁盘速度是极快的。这样就躲开了那些零碎的随机写操作。同时，它对索引的构建也做了延迟处理。等数据全落盘了，再统一建索引。这就快多了。

3.3 实测写入速度

还是刚才那个1956亿行数据的案例。在分布式部署的环境下测试，KES把1956亿行数据全写完，仅仅只耗时701分钟。你算算这个速度。平均写入速度达到了465万行/每秒。这个速度，约为业界2.3倍以上。以前要跑好几天的活，现在半天多就搞定了。对业务上线来说，这太关键了。

四、时序超表这个大杀器

数据写进去了，也存好了。日常管理的时候，你怎么管？这又是个事。KES在这里用了一个叫时序超表的机制。这玩意儿很好用，我单独拿出来讲一讲。

4.1 普通分区表不好使的情况

工业场景里，设备多，采样频率高，时间跨度长。通常来说，大家都会想到用分区表来管。按天分区，或者按月分区。但是普通分区表有个毛病。就是分区多了之后，数据库规划器在选分区的时候会犯迷糊。查一次数据，它要扫一大堆分区元数据。这就导致处理效率直线下降。而且插入的时候，它也要去算该往哪个分区塞，也有开销。

4.2 时序超表机制是咋工作的

KES的时序超表，其实也就是一种更聪明的分区管理方式。你在建表的时候，只要告诉它这是时序超表，并且指定按哪个时间列切分。底层那些复杂的分区逻辑，它全帮你包圆了。你操作起来，就像操作一个普通大表一样简单。但是底层它自动就把数据按时间分好片了。而且它的优化器对时序超表做了专门适配。查数据的时候，如果带上了时间条件，它直接定位到那几个对应的分片，别的分片看都不看。这就叫时间维度上的快速裁剪。

下面我画个简单的流程图，大家一看就明白KES处理时序数据的一个整体逻辑。

大家看这个图。数据进来先分是实时的还是历史的。走不同的写入优化。然后落盘。落盘后压起来。最后存着等查。一气呵成。

4.3 性能对比实锤

光说不练假把式。我们在同样的数据规模，还有一样的表结构下，做了对比测试。

实时插入场景：同样的数据量，往时序超表里插，耗时404秒。往普通分区表里插，耗时549秒。时序超表明显更快。因为它省去了很多算分区的开销。

曲线查询场景：这个差距就更离谱了。我们要查一条设备运行曲线，带时间范围的。时序超表耗时253毫秒就出结果了。普通分区表呢？耗时4834毫秒。时序超表性能提升19.1倍。为啥差这么多？因为普通分区表扫了太多无用的分区。时序超表直接通过时间条件把无关分区给砍了。这性能，妥妥的。

五、总结一下

现在企业层级里的数字化建设越搞越深。时序数据已经成了支撑业务分析、设备运维还有智能决策的重要资产。数据规模只会越来越大，不会变小。

面对这种持续增长的数据规模，大家要清醒一点。你需要的不只是一个能把数据快速写进去的库。你更需要一个能长期扛住海量数据、能高效管理历史数据的基础设施。

金仓时序数据库KES，通过高效压缩把存储成本打下来了。通过历史数据快速插入把迁移时间缩短了。再通过时序超表把管理效率提上去了。这几个能力一组合，就让持续增长的时序数据，能够更加高效地服务业务。而不是变成一个越来越沉重的包袱。如果在座各位正在选型，或者被时序数据搞得头大，不妨试试KES这套组合拳。