深入浅出时序数据库之压缩篇

物联网邻域近期如火如荼,互联网和传统公司争相布局物联网。作为物联网邻域数据存储的首选时序数据库也越来越多进入人们的视野,而早在 2016 年 7 月,百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品 TSDB,成为支持其发展制造,交通,能源,智慧城市等产业领域的核心产品,同时也成为百度战略发展产业物联网的标志性事件。

压缩对于时序数据库是至关重要的。因为时序数据库面对的物联网场景每天都会产生上亿条数据。众所周知,在大数据时代的今天数据的重要性是不言而喻的,数据就是公司的未来。但如果无法对这些时序数据进行很好的管理和压缩,那将给客户带来非常高的成本压力。

如前文提到的,工业物联网环境监控方向的客户,一年产生 1P 的数据,如果每台服务器 10T 的硬盘,那么总共需要 100 多台。按照每台服务器 3 万来算,一年就需要 300 万的支出,这还不包括维护人员的成本。

压缩是个非常大的话题,本文希望能够先从大的宏观角度给出一个轮廓,讲述压缩的本质,压缩的可计算性问题。再从时序数据压缩这一个垂直领域,给出无损压缩和有损压缩各一个例子进行说明,希望能够抛砖引玉。

压缩的故事

先来讲个有关压缩的故事,外星人拜访地球,看中了大英百科全书,想要把这套书带回去。但这套书太大,飞船放不下。于是外星人根据飞船的长度,在飞船上画了一个点。这样外星人心满意足的返回了自己的星球,因为这个点就存储了整个大英百科全书。

这个并不是很严谨的故事,却道出了压缩的本质:用计算时间换取存储空间。外星人在飞船上画的点非常有技术含量,可以说是黑科技,代表一个位数非常长的不循环小数。而这串数字正代表了整个大英百科全书的内容。

压缩的两个问题

再来回答两个宏观的问题,帮助我们认识在压缩这件事上哪些是我们能做的,哪些是不能做的。

第一个问题:是否存在一个通用的压缩算法(Universal Compression),也就是说某个压缩算法能够压缩任意的数据。答案是否定的,并不存在这样的通用压缩算法。

用反证法可以做个快速的证明。假设存在通用的压缩算法,也就是说有个压缩算法,对于长度为 n 的字符串,总能压缩到长度小于 n 的字符串。总共有 2^n 个长度为 n 的不同字符串;但却只有 2^n-1 个长度小于 n 的字符串。那么必定存在两个长度为 n 的字符串 A,B,经过压缩得到同一个字符串。这样解压缩算法没有办法正确的解压。所以假设错误,并不存在通用的压缩算法。

第二个问题:是否能写出一个函数,输入字符串,可以得到这个字符串最短表示的长度。答案也是否定的,也就是说我们无法证明某个算法是最好的算法。柯尔莫哥洛夫复杂性的不可计算性解释的就是这个问题。用的也是反证法,有兴趣的朋友可以自行百度了解(注 1)。

这两个问题的答案,告诉我们三件事情,

  1. 压缩算法的选择需要具体情况具体分析,不可压缩的字符串总是存在。
  2. 不要妄图获得最好的压缩算法,它是不可计算的。因为总有你想不到的压缩算法存在。举个例子,[一百万个 0 的字符串,以“foo”作为 key,经过 AES 加密算法的 CBC 模式得到的字符串]。这串字符串看起来完全是随机的,不可压缩的。但我却用 43 个中文(中括号之间的内容)就表示了出来。
  3. 压缩是件很难很有技术含量的事情,需要不断的挖掘,才能将他做到更好。

时序数据压缩

针对不同的数据,会有不同的压缩,大致压缩的对象可以分为文档、音频、视频等。如果直接采用文档的压缩算法用于时序数据,效果并不理想。下图是一些常用的压缩算法的 benchmark,可以看到压缩率那一栏最高也只能够达到 3 左右的压缩率(压缩率 = 原始数据大小 / 压缩后的数据大小)。更多压缩算法可以查看注 2。

如果要得到更好的压缩率,我们需要采取更加适合时序数据的压缩算法。时序数据的压缩可以分为无损压缩和有损压缩。

无损压缩

无损压缩是说被压缩的数据和解压后的数据完全一样,不存在精度的损失。对数据的压缩说到底是对数据规律性的总结。时序数据的规律可以总结为两点:1、timestamp 稳定递增、2、数值有规律性,变化稳定。下面来举个例子。

上图是一组时序数据,如果我们一行一行的看感觉压缩有点困难,但如果我们一列一列的看,压缩方案就呼之欲出了。

先看 timestamp 那一列是等差递增数列,可以用 [1467627245000,1000,4] 来表示。1467627245000 代表了第一个时间,1000 代表后一个时间比前一个时间的大 1000,4 代表了这样的规律出现了 4 次。如果一共有 100 个这样规律的 timestamp,那就意味着,我们用 3 个 Long 型就可以表示出来。timestamp 压缩率高达 33。

再进一步观察看 value 那一列,如果取差值,可以得到(6,-5,2,-5),全部都加 5 得到(11,0,7,0),这些数值都可以用 4bit 来表示。也就是用 [23,5,4,0xb0700000] 来表示(23,22,24,25,24)。其中的 4 代表后续一共有 4 个数。如果这样的规律一直维持到 100 个 Int 的 value,就可以用 16 个 Int 来代表,压缩率高达 6.3。

具体的情景会复杂很多,在此只是简单举个例子。InfluxDB 无损压缩算法在其页面上有完整的阐述(注 3),可以配合开源源码进行更加深入的理解。针对于浮点数类型,Facebook 在 Gorilla 论文中(注 4)提到的非常高效的无损压缩算法,已经有很多文章进行分析。InfluxDB 对于浮点型也采用这个算法。

有损压缩

有损压缩的意思是说解压后的数据和被压缩的数据在精度上有损失,主要针对于浮点数。通常都会设置一个压缩精度,控制精度损失。时序数据的有损压缩的思路是拟合。也就是用一条线尽可能的匹配到这些点,可以是直线,也可以是曲线。

最有名的时序数据有损压缩是 SOIsoft 公司的 SDA 算法,中文称为旋转门压缩算法。

在上图中,红色的点是上一个记录的点,空心的点是被丢掉的点,绿色的点是当前的点,黑色的点是当前要记录的点。

可以看到图左边,当前点和上一个记录点以及压缩精度的偏差值形成的矩形可以包含中间的点,所以这些点都是可以丢掉的。

再看图右边,当前点和上一个记录点形成的矩形无法包含中间的点,所以把上一个点记录下来。如此进行下去,可以看到,大部分的数据点都会被丢掉。查询的时候需要根据记录的点把丢掉的点在插值找回来。

有损压缩除了可以大幅减少存储成本。如果结合设备端的能力,甚至可以减少数据的写入,降低网络带宽。

总结

虽然判断压缩算法最优是不可计算的,但是设计好的压缩算法仍然是可计算的问题。可以看到,前面提到的时序数据的无损压缩有损压缩算法都会基于时序数据的特征采取方案,达到更好的压缩率。现在 deep learning 非常的火,让人很好奇它是不是可以给数据压缩带来新的方案。

本文作者:佚名

来源:51CTO

时间: 2024-09-20 20:23:36

深入浅出时序数据库之压缩篇的相关文章

HiTSDB 时序数据库技术架构和产品解析

8月24日阿里云数据库技术峰会上,来自阿里数据库事业部高级专家钟宇带来HiTSDB 时序数据库方面的演讲.本文主要从时序数据开始介绍,包括时序序列数据的特点,接着介绍了时序数据业务场景,以及OpenTSDB在HBase上的优化,最后分享了HiTSDB的优化和提高.   时序数据介绍 时序数据就是在时间上分布的一系列数值,时间和数值是两个关键字,时序数据一般指指标型数据,比如股票价格.广告数据.气温变化.网站的PV/UV.个人健康数据.工业传感器数据,还有关于应用程序的性能监控,像服务器系统监控数

时序数据库分析 - TimescaleDB时序数据库介绍

标签 PostgreSQL , TimescaleDB , 时间序列 , 物联网 , IoT 背景 随着物联网的发展,时序数据库的需求越来越多,比如水文监控.工厂的设备监控.国家安全相关的数据监控.通讯监控.金融行业指标数据.传感器数据等. 在互联网行业中,也有着非常多的时序数据,例如用户访问网站的行为轨迹,应用程序产生的日志数据等等. 时序数据有几个特点 1. 基本上都是插入,没有更新的需求. 2. 数据基本上都有时间属性,随着时间的推移不断产生新的数据,旧的数据不需要保存太久. 业务方对时序

时间序列数据的存储和计算 - 开源时序数据库解析(一)

开源时序数据库   如图是17年6月在db-engines上时序数据库的排名,我会挑选开源的.分布式的时序数据库做详细的解析.前十的排名中,RRD是一个老牌的单机存储引擎,Graphite底层是Whisper,可以认为是一个优化的更强大的RRD数据库.kdb+.eXtremeDB和Axibase都未开源,不做解析.InfluxDB开源版和Prometheus的底层都是基于levelDB自研的单机的存储引擎,InfluxDB的商业版支持分布式,Prometheus的roadmap上也规划了分布式存

[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)

原文:[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇) .NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇) 前言:这个系列有段时间没有动了.主要是针对大家的反馈在修改代码.在修改的过程中,也有了一些新的体会,这里和大家分享一下,同时也发布一下业务框架的第一个版本.在本篇文章中,学习到的不是仅仅只是代码,而是设计的思想和实现这种思想的方法.在写本篇时有个感触:把一个东西彻底的讲清楚,不容易.希望大家 多提意见.而且在写本篇的时候,我个人也是很兴

HiTSDB时序数据库技术架构和产品解析

8月24日阿里云数据库技术峰会上,来自阿里数据库事业部高级专家钟宇带来HiTSDB 时序数据库方面的演讲.本文主要从时序数据开始介绍,包括时序序列数据的特点,接着介绍了时序数据业务场景,以及OpenTSDB在HBase上的优化,最后分享了HiTSDB的优化和提高. 时序数据介绍 时序数据就是在时间上分布的一系列数值,时间和数值是两个关键字,时序数据一般指指标型数据,比如股票价格.广告数据.气温变化.网站的PV/UV.个人健康数据.工业传感器数据,还有关于应用程序的性能监控,像服务器系统监控数据,

面向万物互联的时序数据库HiTSDB

现在填写调查问卷,将优先获得公测资格 当前物联网的浪潮席卷全球,甚至于人们还没有真正意识到物联网的存在,但它已经无处不在 .个人智能手环,家庭里使用的智能空调,空气净化器,电饭煲,到社会化共享经济的共享单车,共享汽车,再到汽车制造车间生产线,IT机房的网络设备和服务器,交通监控和信号设备,甚至于全球气候的监测设备等等,这一切都通过物联网进行连接,设备和设备之间,人和设备之间万物互联. 透过现象看本质,物联网的本质是数据的采集和价值利用,而物联网领域最广泛和典型的数据类型就是时间序列数据.时间序列

【玩转ElasticSearch】降维打击!使用ElasticSearch作为时序数据库

本篇分享最近把ElasticSearch当作时序数据库来用的心得. • 需求 需求是这样的:提供一个后台,选用户画像标签(多选),点确认后弹出"选出了xxx个用户",再继续点就把用户dump出来.推送消息.现在要做这个后台的数据仓库层. 详细分析一下需求: 1. 我们的用户画像走流式计算,每秒大量更新,所以对插入/更新性能要求很高. 2. 查询条件翻译成SQL就是类似 select count(*) from `table` where (`tags` like '%tag1%') a

高性能时序数据库 HiTSDB 启动公测,为物联网而生的数据库!

HiTSDB 是一种高性能.低成本.稳定可靠的在线时序数据库服务:提供高效读写,高压缩比存储.时序数据插值及聚合计算.是物联网(IoT)设备监控系统 ,企业能源管理系统(EMS),生产安全监控系统,电力检测系统等行业领域的专业数据库. 查看产品发布详情,申请公测 HiTSDB 打造物联网智慧园区 HiTSDB 已经在阿里巴巴内部孵化多年,在阿里巴巴集团已经支持了20多个核心业务场景,比如阿里智慧园区的物联网(IoT)建设. 智慧园区主要解决办公园区的设备的管理和智能控制.设备管理主要是将设备接入

阿里云高性能时序数据库 HiTSDB 启动公测,为物联网而生的数据库!

摘要:2017云栖大会·上海峰会上,阿里云发布了面向物联网场景的高性能时间序列数据库 (High-Performance Time Series Database , 简称 HiTSDB) .HiTSDB 可支持每秒1000万时序数据点写入:具备PB级别的数据存储能力,提供高效压缩算法,整体存储成本降低90%:提供时序数据插值计算,降精度计算,时间纬度聚合计算,空间纬度聚合计算的能力. HiTSDB 是一种高性能.低成本.稳定可靠的在线时序数据库服务:提供高效读写,高压缩比存储.时序数据插值及聚