精华内容
下载资源
问答
  • 1.基本概念时序数据库(Time Series Database)是用于存储和管理时间序列数据的专业化数据库。时序数据库特别适用于物联网设备监控和互联网业务监控场景。下面介绍下时序数据库的一些基本概念(不同的时序数据库称呼略...

    1.基本概念

    时序数据库(Time Series Database)是用于存储和管理时间序列数据的专业化数据库。时序数据库特别适用于物联网设备监控和互联网业务监控场景。

    下面介绍下时序数据库的一些基本概念(不同的时序数据库称呼略有不同)。

    1.1 度量(metric)

    监测数据的指标,例如风力和温度。相当于关系型数据库中的table。

    1.2 标签(tag)

    指标项监测针对的具体对象,属于指定度量下的数据子类别。一个标签(Tag)由一个标签键(TagKey)和一个对应的标签值(TagValue)组成。

    例如在监测数据的时候,指定度量(Metric)是“气温”,“城市(TagKey)= 杭州(TagValue)”就是一个标签(Tag),则监测的就是杭州市的气温。更多标签示例:机房 = A 、IP = 172.220.110.1。

    1.3 域(field)

    在指定度量下数据的子类别,一般情况下存放的是会随着时间戳的变化而变化的数据。一个metric可支持多个field,如metric为风力,该度量可以有两个field:direction和speed。

    1.4 度量值(value)

    度量对应的数值,如56°C、1000r/s等(实际中不带单位)。如果有多个field,每个field都有相应的value。不同的field支持不同的数据类型写入。对于同一个field,如果写入了某个数据类型的value之后,相同的field不允许写入其他数据类型。

    1.5 时间戳(Timestamp)

    数据(度量值)产生的时间点。

    1.6 数据点 (Data Point)

    针对监测对象的某项指标(由度量和标签定义)按特定时间间隔(连续的时间戳)采集的每个度量值就是一个数据点。1个metric+1个field(可选)+1个timestamp+1个value + n个tag(n>=1)”唯一定义了一个数据点。相当于关系型数据库中的row。

    1.7 时间序列(Time Series)

    1个metric+1个field(可选) +n个tag(n>=1)”定义了一个时间序列。主要是针对某个监测对象的某项指标(由度量和标签定义)的描述。某个时间序列上产生的数据值的增加,不会导致时间序列的增加。

    例1(单域):对温度的时间序列监测值

    温度(temperature)作为一个度量(metric),共4个数据点,每个数据点由如下组成:

    timestamp:时间戳

    三个tag:每个tag都是一个key-value对,tag的key分别是deivceID、floor、room。

    一个field:温度值

    其中4个数据点使用的metric、tag是相同的,所以是同一个时间序列。如图所示:

    3dd62e4963119d79da4d20d8b3bb2888.png

    例2(多域,单一数据源采集):记录一段时间内的某个集群里各机器上各端口的出入流量,每半小时记录一个观测值。

    网络(Network)作为一个度量(metric),总共7个数据点。每个数据点由以下部分组成:

    timestamp:时间戳

    两个tag:host、port,代表每个point归属于哪台机器的哪个端口

    两个field:bytes_in、bytes_out,代表piont的测量值,半小时内出入流量的平均值

    同一个host、同一个port,每半小时产生一个point,随着时间的增长,field(bytes_in、bytes_out)不断变化。

    如host:host4,port:51514,timestamp从02:00 到02:30的时间段内,bytes_in 从 37.937上涨到38.089,bytes_out从2897.26上涨到3009.86,说明这一段时间内该端口服务压力升高。

    becb60b83696d45f58e1184223893bf6.png

    例3(多域,多个数据源采集):监测风力的两个域(speed和direction)的监测数据,监测数据来自不同的传感器

    风力(wind)作为一个度量(metric),总共2个时间序列,8个数据点。每个数据点由以下部分组成:

    3个tag:key分别是sensor、city、province。为了表示在广东省深圳市传感器编号95D8-7913上传风向(direction)数据,可以将这个数据点的tag为标记为sensor=95D8-7913、city=深圳、province=广东。

    两个域:风向(direction)和速度(speed),分别来自不同的传感器。

    如图,当使用的是metric、field和tag是相同的时,是同一个时间序列。

    a687dddca4286feafec91f99a988b409.png

    将数据采用metric+field的方式存储的优势在于,可以在同一个时间序列下联合查询。以上图为例,要查询1467627246000-1467627249000时间内风力(wind)的情况,可以联合查询多个field的值,得到下图的数据。

    b44366fec119f3b291f509df4891d240.png

    1.8 时间精度

    时间线数据的写入时间精度——毫秒、秒、分钟、小时或者其他稳定时间频度。例如,每秒一个温度数据的采集频度,每 5 分钟一个负载数据的采集频度。

    1.9-1 数据组(Data Group)

    可以按标签这些数据分成不同的数据组。用来对比不同监测对象(由标签定义)的同一指标(由度量定义)的数据。

    例如,将温度指标数据按照不同城市进行分组查询,操作类似于该 SQL 语句:select temperature from xxx group by city where city in (shanghai, hangzhou)。

    1.9-2 聚合( Aggregation)

    可以对一段时间的数据点做聚合,如每10分钟的和值、平均值、最大值、最小值等。

    例如,当选定了某个城市某个城区的污染指数时,通常将各个环境监测点的指标数据平均值作为最终区域的指标数据,这个计算过程就是空间聚合。

    2.应用场景

    2.1系统运维和业务实时监控

    在业务服务器上部署各种脚本客户端,实时采集服务器指标数据(IO指标、CPU指标、带宽内存指标等等),业务相关数据(方法调用异常次数、响应延迟、JVM GC相关数据等等)、数据库相关数据(读取延迟、写入延迟等等),很显然,这些数据都是时间序列相关的。客户端采集和实时计算之后会发送给哨兵服务器,哨兵服务器会将这些数据进行存储,并实现实现监控和分析的展现,供用户查询。

    如下图所示,用户可以登录哨兵系统查看某台服务器的负载,负载曲线就是按照时间进行绘制的,带有明显的时序特征:

    9ca16cbeac19c3e8ad597e95fd4f3262.png

    2.2 物联网设备状态监控存储分析

    在可预知的未来3~5年,随着物联网以及工业4.0的到来,所有设备都会携带传感器并联网,传感器收集的时序数据将严重依赖TSDB的实时分析能力、存储能力以及查询统计能力。

    6a524d5554d64554c1b2c3b7dac4ffdc.png

    上图是一个智慧工厂示意图,工厂中所有设备都会携带传感设备,这些传感设备会实时采集设备温度、压力等基本信息,并发送给服务器端进行实时分析、存储以及后期的查询统计。除此之外,比如现在比较流行的各种穿戴设备,以后都可以联网,穿戴设备上采集的心跳信息、血流信息、体感信息等等也都会实时传输给服务器进行实时分析、存储以及查询统计。

    PS:阿里云拥有自主研发的时序数据库产品 TSDB ,此产品在阿里内部磨练多年, 历经多次双十一高严苛场景的功能和性能验证, 在应用监控,服务器资源监控,数据库监控, 智慧园区设备监控,以及盒马新零售边缘设备监控都有丰富的落地使用场景 ,覆盖了阿里集团80%以上的时序监控业务。

    3.基本特点

    时序业务和普通业务在很多方面都有巨大的区别,归纳起来主要有如下几个方面:

    3.1 持续产生海量数据,没有波峰波谷

    举几个简单的例子,比如类似哨兵的监控系统,假如现在系统监控1w台服务器的各类指标,每台服务器每秒采集100种metrics,这样每秒钟将会有100w的TPS。再比如说,现在比较流行的运动手环,假如当前有100w人佩戴,每个手环一秒只采集3种metrcis(心跳、脉搏、步数),这样每秒钟也会产生300w的TPS。

    3.2 数据都是插入操作,基本没有更新删除操作

    时序业务产生的数据很少有更新删除的操作,基于这样的事实,在时序数据库架构设计上会有很大的简化。

    3.3 近期数据关注度更高,未来会更关注流式处理这个环节,时间久远的数据极少被访问,甚至可以丢弃

    这个很容易理解,哨兵系统我们通常最关心最近一小时的数据,最多看看最近3天的数据,很少去看3天以前的数据。随着流式计算的到来,时序数据在以后的发展中必然会更关注即时数据的价值,这部分数据的价值毫无疑问也是最大的。数据产生之后就可以根据某些规则进行报警是一个非常常见并重要的场景,报警时效性越高,对业务越有利。

    3.4 数据存在多个维度的标签,往往需要多维度联合查询以及统计查询。

    时序数据另一个非常重要的功能是多维度聚合统计查询,比如业务需要统计最近一小时广告主google发布在USA地区的广告点击率和总收入分别是多少,这是一个典型的多维度聚合统计查询需求。这个需求通常对实效性要求不高,但对查询聚合性能有比较高的要求。

    4.TSDB核心特性

    总结起来TSDB需要关注的技术点主要有这么几个:

    4.1 高吞吐量写入能力

    这是针对时序业务持续产生海量数据这么一个特点量身定做的,当前要实现系统高吞吐量写入,必须要满足两个基本技术点要求:系统具有水平扩展性和单机LSM体系结构。系统具有水平扩展性很容易理解,单机肯定是扛不住的,系统必须是集群式的,而且要容易加节点扩展,说到底,就是扩容的时候对业务无感知,目前Hadoop生态系统基本上都可以做到这一点;而LSM体系结构是用来保证单台机器的高吞吐量写入,LSM结构下数据写入只需要写入内存以及追加写入日志,这样就不再需要随机将数据写入磁盘,HBase、Kudu以及Druid等对写入性能有要求的系统目前都采用的这种结构。

    4.2 数据分级存储/TTL

    这是针对时序数据冷热性质定制的技术特性。数据分级存储要求能够将最近小时级别的数据放到内存中,将最近天级别的数据放到SSD,更久远的数据放到更加廉价的HDD或者直接使用TTL过期淘汰掉。

    4.3 高压缩率

    提供高压缩率有两个方面的考虑,一方面是节省成本,这很容易理解,将1T数据压缩到100G就可以减少900G的硬盘开销,这对业务来说是有很大的诱惑的。另一个方面是压缩后的数据可以更容易保证存储到内存中,比如最近3小时的数据是1T,我现在只有100G的内存,如果不压缩,就会有900G的数据被迫放到硬盘上,这样的话查询开销会非常之大,而使用压缩会将这1T数据都放入内存,查询性能会非常之好。

    4.4 多维度查询能力

    时序数据通常会有多个维度的标签来刻画一条数据,就是上文中提到的维度列。如何根据随机几个维度进行高效查询就是必须要解决的一个问题,这个问题通常需要考虑位图索引或者倒排索引技术。

    4.5 高效聚合能力

    时序业务一个通用的需求是聚合统计报表查询,比如哨兵系统中需要查看最近一天某个接口出现异常的总次数,或者某个接口执行的最大耗时时间。这样的聚合实际上就是简单的count以及max,问题是如何能高效的在那么大的数据量的基础上将满足条件的原始数据查询出来并聚合,要知道统计的原始值可能因为时间比较久远而不在内存中哈,因此这可能是一个非常耗时的操作。目前业界比较成熟的方案是使用预聚合,就是在数据写进来的时候就完成基本的聚合操作。

    未来技术点:异常实时检测、未来预测等等。

    5.传统关系型数据库存储时序数据的问题

    很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题。但时序数据往往是由百万级甚至千万级终端设备产生的,写入并发量比较高,属于海量数据场景。

    5.1 MySQL在海量的时序数据场景下存在如下问题:

    存储成本大:对于时序数据压缩不佳,需占用大量机器资源;

    维护成本高:单机系统,需要在上层人工的分库分表,维护成本高;

    写入吞吐低:单机写入吞吐低,很难满足时序数据千万级的写入压力;

    查询性能差:适用于交易处理,海量数据的聚合分析性能差。

    5.2 使用Hadoop生态(Hadoop、Spark等)存储时序数据会有以下问题:

    数据延迟高:离线批处理系统,数据从产生到可分析,耗时数小时、甚至天级;

    查询性能差:不能很好的利用索引,依赖MapReduce任务,查询耗时一般在分钟级。

    5.3 时序数据库需要解决以下几个问题:

    时序数据的写入:如何支持每秒钟上千万上亿数据点的写入。

    时序数据的读取:如何支持在秒级对上亿数据的分组聚合运算。

    成本敏感:由海量数据存储带来的是成本问题。如何更低成本的存储这些数据,将成为时序数据库需要解决的重中之重。

    6.时序数据库发展简史与现状

    8be57bb08fa1c6d47994da1309caba23.png

    目前,DB-Engines把时间序列数据库作为独立的目录来分类统计,下图就是2018年业内流行的时序数据库的关注度排名和最近5年的变化趋势。

    aadf558d842fb759c69ee59a802a5427.png

    参考文档:

    展开全文
  • 十分钟看懂时序数据库(I)-存储

    千次阅读 2019-04-19 15:10:14
    2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库;到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了,而早在2016年7月,百度云在其天工物联网平台上发布了国内首个多租户的分布式...

    2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库;到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了,而早在2016年7月,百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB,成为支持其发展制造,交通,能源,智慧城市等产业领域的核心产品,同时也成为百度战略发展产业物联网的标志性事件。时序数据库作为物联网方向一个非常重要的服务,业界的频频发声,正说明各家企业已经迫不及待的拥抱物联网时代的到来。

    本文会从时序数据库的基本概念、使用场景、解决的问题一一展开,最后会从如何解决时序数据存储这一技术问题入手进行深入分析。

    1.背景

    百度无人车在运行时需要监控各种状态,包括坐标,速度,方向,温度,湿度等等,并且需要把每时每刻监控的数据记录下来,用来做大数据分析。每辆车每天就会采集将近8T的数据。如果只是存储下来不查询也还好(虽然已经是不小的成本),但如果需要快速查询“今天下午两点在后厂村路,速度超过60km/h的无人车有哪些”这样的多纬度分组聚合查询,那么时序数据库会是一个很好的选择。

    2.什么是时序数据库

    先来介绍什么是时序数据。时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线,往过去看可以做成多纬度报表,揭示其趋势性、规律性、异常性;往未来看可以做大数据分析,机器学习,实现预测和预警。

    时序数据库就是存放时序数据的数据库,并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。

    对比传统数据库仅仅记录了数据的当前值,时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件。

    时序数据示例

    å¾çæè¿°

    p1-北上广三地2015年气温变化图

    å¾çæè¿°

    p2-北上广三地当前温度实时展现

    下面介绍下时序数据库的一些基本概念(不同的时序数据库称呼略有不同)。

    metric: 度量,相当于关系型数据库中的table。

    data point: 数据点,相当于关系型数据库中的row。

    timestamp:时间戳,代表数据点产生的时间。

    field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个field。一般情况下存放的是会随着时间戳的变化而变化的数据。

    tag: 标签,或者附加信息。一般存放的是并不随着时间戳变化的属性信息。timestamp加上所有的tags可以认为是table的primary key。

    如下图,度量为Wind,每一个数据点都具有一个timestamp,两个field:direction和speed,两个tag:sensor、city。它的第一行和第三行,存放的都是sensor号码为95D8-7913的设备,属性城市是上海。随着时间的变化,风向和风速都发生了改变,风向从23.4变成23.2;而风速从3.4变成了3.3。

    å¾çæè¿°

    p3-时序数据库基本概念图

    3.时序数据库的场景

    所有有时序数据产生,并且需要展现其历史趋势、周期规律、异常性的,进一步对未来做出预测分析的,都是时序数据库适合的场景。

    在工业物联网环境监控方向,百度天工的客户就遇到了这么一个难题,由于工业上面的要求,需要将工况数据存储起来。客户每个厂区具有20000个监测点,500毫秒一个采集周期,一共20个厂区。这样算起来一年将产生惊人的26万亿个数据点。假设每个点50Byte,数据总量将达1P(如果每台服务器10T的硬盘,那么总共需要100多台服务器)。这些数据不只是要实时生成,写入存储;还要支持快速查询,做可视化的展示,帮助管理者分析决策;并且也能够用来做大数据分析,发现深层次的问题,帮助企业节能减排,增加效益。最终客户采用了百度天工的时序数据库方案,帮助他解决了难题。

    在互联网场景中,也有大量的时序数据产生。百度内部有大量服务使用天工物联网平台的时序数据库。举个例子,百度内部服务为了保障用户的使用体验,将用户的每次网络卡顿、网络延迟都会记录到百度天工的时序数据库。由时序数据库直接生成报表以供技术产品做分析,尽早的发现、解决问题,保证用户的使用体验。

    4.时序数据库遇到的挑战

    很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题,但少量数据是展现的纬度有限,细节少,可置信低,更加不能用来做大数据分析。很明显时序数据库是为了解决海量数据场景而设计的。

    可以看到时序数据库需要解决以下几个问题

    时序数据的写入:如何支持每秒钟上千万上亿数据点的写入。
    时序数据的读取:又如何支持在秒级对上亿数据的分组聚合运算。
    成本敏感:由海量数据存储带来的是成本问题。如何更低成本的存储这些数据,将成为时序数据库需要解决的重中之重。
    这些问题不是用一篇文章就能含盖的,同时每个问题都可以从多个角度去优化解决。在这里只从数据存储这个角度来尝试回答如何解决大数据量的写入和读取。

    5.数据的存储

    数据的存储可以分为两个问题,单机上存储和分布式存储。

    单机存储

    如果只是存储起来,直接写成日志就行。但因为后续还要快速的查询,所以需要考虑存储的结构。

    传统数据库存储采用的都是B tree,这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的,一般在10ms左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入B tree会消耗大量的时间在磁盘寻道上,导致速度很慢。我们知道SSD具有更快的寻道时间,但并没有从根本上解决这个问题。

    对于90%以上场景都是写入的时序数据库,B tree很明显是不合适的。

    业界主流都是采用LSM tree替换B tree,比如Hbase, Cassandra等nosql中。这里我们详细介绍一下。

    LSM tree包括内存里的数据结构和磁盘上的文件两部分。分别对应Hbase里的MemStore和HLog;对应Cassandra里的MemTable和sstable。

    LSM tree操作流程如下:

    1.数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到WAL文件中。

    2.内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。

    3.随着磁盘上积累的文件越来越多,会定时的进行合并操作,消除冗余数据,减少文件数量。

    å¾çæè¿°

    p4-Hbase LSM tree结构介绍(注1)

    可以看到LSM tree核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能,避免了随机写入。但同时也牺牲了读取性能,因为同一个key的值可能存在于多个HFile中。为了获取更好的读取性能,可以通过bloom filter和compaction得到,这里限于篇幅就不详细展开。

    分布式存储

    时序数据库面向的是海量数据的写入存储读取,单机是无法解决问题的。所以需要采用多机存储,也就是分布式存储。

    分布式存储首先要考虑的是如何将数据分布到多台机器上面,也就是 分片(sharding)问题。下面我们就时序数据库分片问题展开介绍。分片问题由分片方法的选择和分片的设计组成。

    分片方法

    时序数据库的分片方法和其他分布式系统是相通的。

    哈希分片:这种方法实现简单,均衡性较好,但是集群不易扩展。

    一致性哈希:这种方案均衡性好,集群扩展容易,只是实现复杂。代表有Amazon的DynamoDB和开源的Cassandra。

    范围划分:通常配合全局有序,复杂度在于合并和分裂。代表有Hbase。

    分片设计

    分片设计简单来说就是以什么做分片,这是非常有技巧的,会直接影响写入读取的性能。

    结合时序数据库的特点,根据metric+tags分片是比较好的一种方式,因为往往会按照一个时间范围查询,这样相同metric和tags的数据会分配到一台机器上连续存放,顺序的磁盘读取是很快的。再结合上面讲到的单机存储内容,可以做到快速查询。

    进一步我们考虑时序数据时间范围很长的情况,需要根据时间范围再将分成几段,分别存储到不同的机器上,这样对于大范围时序数据就可以支持并发查询,优化查询速度。

    如下图,第一行和第三行都是同样的tag(sensor=95D8-7913;city=上海),所以分配到同样的分片,而第五行虽然也是同样的tag,但是根据时间范围再分段,被分到了不同的分片。第二、四、六行属于同样的tag(sensor=F3CC-20F3;city=北京)也是一样的道理。

    å¾çæè¿°

    p5-时序数据分片说明

    6.真实案例

    下面我以一批开源时序数据库作为说明。

    InfluxDB:

    非常优秀的时序数据库,但只有单机版是免费开源的,集群版本是要收费的。从单机版本中可以一窥其存储方案:在单机上InfluxDB采取类似于LSM tree的存储结构TSM;而分片的方案InfluxDB先通过+(事实上还要加上retentionPolicy)确定ShardGroup,再通过+的hash code确定到具体的Shard。

    这里timestamp默认情况下是7天对齐,也就是说7天的时序数据会在一个Shard中。 

    å¾çæè¿°
    p6-Influxdb TSM结构图(注2)

    Kairosdb:

    底层使用Cassandra作为分布式存储引擎,如上文提到单机上采用的是LSM tree。 
    Cassandra有两级索引:partition key和clustering key。其中partition key是其分片ID,使用的是一致性哈希;而clustering key在一个partition key中保证有序。

    Kairosdb利用Cassandra的特性,将 ++<数据类型>+作为partition key,数据点时间在timestamp上的偏移作为clustering key,其有序性方便做基于时间范围的查询。

    partition key中的timestamp是3周对齐的,也就是说21天的时序数据会在一个clustering key下。3周的毫秒数是18亿正好小于Cassandra每行列数20亿的限制。

    OpenTsdb:

    底层使用Hbase作为其分布式存储引擎,采用的也是LSM tree。

    Hbase采用范围划分的分片方式。使用row key做分片,保证其全局有序。每个row key下可以有多个column family。每个column family下可以有多个column。 

    å¾çæè¿°

    上图是OpenTsdb的row key组织方式。不同于别的时序数据库,由于Hbase的row key全局有序,所以增加了可选的salt以达到更好的数据分布,避免热点产生。再由与timestamp间的偏移和数据类型组成column qualifier。

    他的timestamp是小时对齐的,也就是说一个row key下最多存储一个小时的数据。并且需要将构成row key的metric和tags都转成对应的uid来减少存储空间,避免Hfile索引太大。下图是真实的row key示例。 

    å¾çæè¿°
    p7-open tsdb的row key示例(注3)

    7.结束语

    可以看到各分布式时序数据库虽然存储方案都略有不同,但本质上是一致的,由于时序数据写多读少的场景,在单机上采用更加适合大吞吐量写入的单机存储结构,而在分布式方案上根据时序数据的特点来精心设计,目标就是设计的分片方案能方便时序数据的写入和读取,同时使数据分布更加均匀,尽量避免热点的产生。

    数据存储是时序数据库设计中很小的一块内容,但也能管中窥豹,看到时序数据库从设计之初就要考虑时序数据的特点。后续我们会从其他的角度进行讨论。

    作者:百度云时序数据库资深工程师

    注1:来源 http://tristartom.github.io/research.html 
    注2:来源 http://blog.fatedier.com/2016/08/05/detailed-in-influxdb-tsm-storage-engine-one/ 
    注3:来源 http://opentsdb.net/docs/build/html/user_guide/backends/hbase.html
    --------------------- 

    转自:https://blog.csdn.net/java060515/article/details/80129387 
     

    展开全文
  • 原文地址:...2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库;到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了,而早在2016年...

    原文地址:https://yq.aliyun.com/articles/202551?spm=5176.10695662.1996646101.searchclickresult.7ce551cb7a7dkx

    2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库;到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了,而早在2016年7月,百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB,成为支持其发展制造,交通,能源,智慧城市等产业领域的核心产品,同时也成为百度战略发展产业物联网的标志性事件。时序数据库作为物联网方向一个非常重要的服务,业界的频频发声,正说明各家企业已经迫不及待的拥抱物联网时代的到来。

    本文会从时序数据库的基本概念、使用场景、解决的问题一一展开,最后会从如何解决时序数据存储这一技术问题入手进行深入分析。

    1. 背景

           百度无人车在运行时需要监控各种状态,包括坐标,速度,方向,温度,湿度等等,并且需要把每时每刻监控的数据记录下来,用来做大数据分析。每辆车每天就会采集将近8T的数据。如果只是存储下来不查询也还好(虽然已经是不小的成本),但如果需要快速查询“今天下午两点在后厂村路,速度超过60km/h的无人车有哪些”这样的多纬度分组聚合查询,那么时序数据库会是一个很好的选择。

    2. 什么是时序数据库

           先来介绍什么是时序数据。时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线,往过去看可以做成多纬度报表,揭示其趋势性、规律性、异常性;往未来看可以做大数据分析,机器学习,实现预测和预警。

    时序数据库就是存放时序数据的数据库,并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。

           对比传统数据库仅仅记录了数据的当前值,时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件。

           时序数据示例

    p1-北上广三地2015年气温变化图

    p2-北上广三地当前温度实时展现

    下面介绍下时序数据库的一些基本概念(不同的时序数据库称呼略有不同)。

    metric: 度量,相当于关系型数据库中的table。

    data point: 数据点,相当于关系型数据库中的row。

    timestamp:时间戳,代表数据点产生的时间。

    field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个field。一般情况下存放的是会随着时间戳的变化而变化的数据。

    tag: 标签,或者附加信息。一般存放的是并不随着时间戳变化的属性信息。timestamp加上所有的tags可以认为是table的primary key。

    如下图,度量为Wind,每一个数据点都具有一个timestamp,两个field:direction和speed,两个tag:sensor、city。它的第一行和第三行,存放的都是sensor号码为95D8-7913的设备,属性城市是上海。随着时间的变化,风向和风速都发生了改变,风向从23.4变成23.2;而风速从3.4变成了3.3。

    p3-时序数据库基本概念图

    3. 时序数据库的场景

    所有有时序数据产生,并且需要展现其历史趋势、周期规律、异常性的,进一步对未来做出预测分析的,都是时序数据库适合的场景。

    在工业物联网环境监控方向,百度天工的客户就遇到了这么一个难题,由于工业上面的要求,需要将工况数据存储起来。客户每个厂区具有20000个监测点,500毫秒一个采集周期,一共20个厂区。这样算起来一年将产生惊人的26万亿个数据点。假设每个点50Byte,数据总量将达1P(如果每台服务器10T的硬盘,那么总共需要100多台服务器)。这些数据不只是要实时生成,写入存储;还要支持快速查询,做可视化的展示,帮助管理者分析决策;并且也能够用来做大数据分析,发现深层次的问题,帮助企业节能减排,增加效益。最终客户采用了百度天工的时序数据库方案,帮助他解决了难题。

    在互联网场景中,也有大量的时序数据产生。百度内部有大量服务使用天工物联网平台的时序数据库。举个例子,百度内部服务为了保障用户的使用体验,将用户的每次网络卡顿、网络延迟都会记录到百度天工的时序数据库。由时序数据库直接生成报表以供技术产品做分析,尽早的发现、解决问题,保证用户的使用体验。

    4. 时序数据库遇到的挑战

           很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题,但少量数据是展现的纬度有限,细节少,可置信低,更加不能用来做大数据分析。很明显时序数据库是为了解决海量数据场景而设计的。

    可以看到时序数据库需要解决以下几个问题

    l   时序数据的写入:如何支持每秒钟上千万上亿数据点的写入。

    l   时序数据的读取:又如何支持在秒级对上亿数据的分组聚合运算。

    l   成本敏感:由海量数据存储带来的是成本问题。如何更低成本的存储这些数据,将成为时序数据库需要解决的重中之重。

           这些问题不是用一篇文章就能含盖的,同时每个问题都可以从多个角度去优化解决。在这里只从数据存储这个角度来尝试回答如何解决大数据量的写入和读取。

    5. 数据的存储

           数据的存储可以分为两个问题,单机上存储和分布式存储。

    单机存储

           如果只是存储起来,直接写成日志就行。但因为后续还要快速的查询,所以需要考虑存储的结构。

           传统数据库存储采用的都是B tree,这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的,一般在10ms左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入B tree会消耗大量的时间在磁盘寻道上,导致速度很慢。我们知道SSD具有更快的寻道时间,但并没有从根本上解决这个问题。

           对于90%以上场景都是写入的时序数据库,B tree很明显是不合适的。

           业界主流都是采用LSM tree替换B tree,比如Hbase, Cassandra等nosql中。这里我们详细介绍一下。

           LSM tree包括内存里的数据结构和磁盘上的文件两部分。分别对应Hbase里的MemStore和HLog;对应Cassandra里的MemTable和sstable。

           LSM tree操作流程如下:

    1.     数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到WAL文件中。

    2.     内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。

    3.     随着磁盘上积累的文件越来越多,会定时的进行合并操作,消除冗余数据,减少文件数量。

     

    p4-Hbase LSM tree结构介绍(注1)

           可以看到LSM tree核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能,避免了随机写入。但同时也牺牲了读取性能,因为同一个key的值可能存在于多个HFile中。为了获取更好的读取性能,可以通过bloom filter和compaction得到,这里限于篇幅就不详细展开。

    分布式存储

           时序数据库面向的是海量数据的写入存储读取,单机是无法解决问题的。所以需要采用多机存储,也就是分布式存储。

           分布式存储首先要考虑的是如何将数据分布到多台机器上面,也就是 分片(sharding)问题。下面我们就时序数据库分片问题展开介绍。分片问题由分片方法的选择和分片的设计组成。

     分片方法

           时序数据库的分片方法和其他分布式系统是相通的。

           哈希分片:这种方法实现简单,均衡性较好,但是集群不易扩展。

           一致性哈希:这种方案均衡性好,集群扩展容易,只是实现复杂。代表有Amazon的DynamoDB和开源的Cassandra。

           范围划分:通常配合全局有序,复杂度在于合并和分裂。代表有Hbase。

     分片设计

           分片设计简单来说就是以什么做分片,这是非常有技巧的,会直接影响写入读取的性能。

           结合时序数据库的特点,根据metric+tags分片是比较好的一种方式,因为往往会按照一个时间范围查询,这样相同metric和tags的数据会分配到一台机器上连续存放,顺序的磁盘读取是很快的。再结合上面讲到的单机存储内容,可以做到快速查询。

           进一步我们考虑时序数据时间范围很长的情况,需要根据时间范围再将分成几段,分别存储到不同的机器上,这样对于大范围时序数据就可以支持并发查询,优化查询速度。

           如下图,第一行和第三行都是同样的tag(sensor=95D8-7913;city=上海),所以分配到同样的分片,而第五行虽然也是同样的tag,但是根据时间范围再分段,被分到了不同的分片。第二、四、六行属于同样的tag(sensor=F3CC-20F3;city=北京)也是一样的道理。

     

    p5-时序数据分片说明

    6.      真实案例

           下面我以一批开源时序数据库作为说明。

    InfluxDB:

           非常优秀的时序数据库,但只有单机版是免费开源的,集群版本是要收费的。从单机版本中可以一窥其存储方案:在单机上InfluxDB采取类似于LSM tree的存储结构TSM;而分片的方案InfluxDB先通过<database>+<timestamp>(事实上还要加上retentionPolicy)确定ShardGroup,再通过<metric>+<tags>的hash code确定到具体的Shard。

           这里timestamp默认情况下是7天对齐,也就是说7天的时序数据会在一个Shard中。

           

    p6-Influxdb TSM结构图(注2)

    Kairosdb:

           底层使用Cassandra作为分布式存储引擎,如上文提到单机上采用的是LSM tree。

           Cassandra有两级索引:partition key和clustering key。其中partition key是其分片ID,使用的是一致性哈希;而clustering key在一个partition key中保证有序。

           Kairosdb利用Cassandra的特性,将 <metric>+<timestamp>+<数据类型>+<tags>作为partition key,数据点时间在timestamp上的偏移作为clustering key,其有序性方便做基于时间范围的查询。

           partition key中的timestamp是3周对齐的,也就是说21天的时序数据会在一个clustering key下。3周的毫秒数是18亿正好小于Cassandra每行列数20亿的限制。

     OpenTsdb:

           底层使用Hbase作为其分布式存储引擎,采用的也是LSM tree。

           Hbase采用范围划分的分片方式。使用row key做分片,保证其全局有序。每个row key下可以有多个column family。每个column family下可以有多个column。

           

           上图是OpenTsdb的row key组织方式。不同于别的时序数据库,由于Hbase的row key全局有序,所以增加了可选的salt以达到更好的数据分布,避免热点产生。再由与timestamp间的偏移和数据类型组成column qualifier。

           他的timestamp是小时对齐的,也就是说一个row key下最多存储一个小时的数据。并且需要将构成row key的metric和tags都转成对应的uid来减少存储空间,避免Hfile索引太大。下图是真实的row key示例。

    p7-open tsdb的row key示例(注3)

    7.      结束语

           可以看到各分布式时序数据库虽然存储方案都略有不同,但本质上是一致的,由于时序数据写多读少的场景,在单机上采用更加适合大吞吐量写入的单机存储结构,而在分布式方案上根据时序数据的特点来精心设计,目标就是设计的分片方案能方便时序数据的写入和读取,同时使数据分布更加均匀,尽量避免热点的产生。

           数据存储是时序数据库设计中很小的一块内容,但也能管中窥豹,看到时序数据库从设计之初就要考虑时序数据的特点。后续我们会从其他的角度进行讨论。

    展开全文
  • 哈希取余 倒排索引 符号表 正则匹配 block合并,主要是合并索引。 通过WAL预写日志的方式,防止数据丢失。 参考: 1 2

    按series存储。
    哈希取余
    倒排索引:方便查询多条series。
    符号表:存储将label排序,然后按序号索引获取,降低了存储开销,并且可以进行正则匹配。
    正则匹配

    block合并,主要是合并索引。
    通过WAL预写日志的方式,防止数据丢失。
    参考:Prometheus时序数据库-内存中的存储结构 - 无毁的湖光-Al - 博客园 (cnblogs.com)
    Prometheus时序数据库-磁盘中的存储结构 - 无毁的湖光-Al - 博客园 (cnblogs.com)
    LSM树 - 知乎 (zhihu.com)
    LSM树原理探究 (juejin.cn)

    展开全文
  • 关于时序数据库

    2018-08-07 23:20:58
    看了一些时序数据库,没有太深入,有一些大概认识,记录下来。  1. 核心 数据存储分为行存储或者列存储,由于列存储的高...当前有很多时序数据库采用了在底层KV存储(Cadssandra, HBase, LevelDB, RocksDB)基础...
  • 时序数据库

    千次阅读 2019-06-06 14:29:43
    时序数据库(Time Series Database)是用于存储和管理时间序列数据的专业化数据库,为时间序列数据提供高性能读写和强计算能力的分布式云端数据库服务。时序数据库特别适用于物联网设备监控和互联网业务监控场景。 ...
  • 时序数据库入门

    2021-01-28 03:54:00
    数据库的模型包含关系型、key-value 型、Document 型等很多种,那么为什么新型的时序数据库成为监控数据存储的新宠呢? 下面就会从为什么需要时序数据库时序数据库的数据结构两个方面来介绍一下时序数据库。1. 为...
  • 时序数据库与传统数据库的优势

    千次阅读 2021-05-14 17:08:36
    传统关系型数据库存储时序数据的问题 有了时序数据后,该存储在哪里呢?首先我们看下传统的关系型数据库解决方案在存储时序数据时会遇到什么问题。 很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序...
  • 目录 时序数据库InfluxDB 性能测试 为什么时序数据库更快 时序数据库场景 TSDB和其他数据库非常不同的属性包括:时间戳、数据存储和压缩、数据生命周期管理、数据汇总、处理大量记录的时间序列相关扫描的能力以及...
  • 时序数据库调研报告

    2021-04-09 18:07:31
    一、时序数据库应用场景简介 时间序列数据库简称时序数据库(Time Series Database),用于处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。 时序数据的几个特点 基本...
  • 时序数据库简介

    2021-02-05 09:27:26
    时间序列数据库简称时序数据库(Time Series Database),用于处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。时序数据的几个特点1. 基本上都是插入,没有更新的需求...
  • 传统数据库存储采用的都是 B tree,这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的,一般在 10ms 左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入 B tree 会消耗...
  • 除了最常用的关系数据库和缓存之外,之前我们已经介绍了在Spring Boot中如何配置和使用MongoDB、LDAP这些存储的案例。接下来,我们继续介绍另一种特殊的数据库:时序数据库Inf...
  • 时序数据库及应用场景介绍

    千次阅读 2020-01-08 23:16:17
    一,时序数据库 时间序列数据库简称时序数据库(Time Series Database),用于处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。 时序数据的几个特点 1. 基本上都是...
  • 时序数据库应用场景与设计

    千次阅读 2019-06-20 14:20:04
    数据特点 时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线,往过去看可以做成多纬度报表,揭示其趋势性、规律性、异常性;...对比传统数据库仅仅记录了数据的当前值,时序数据库则...
  • 浅谈时序数据库TDengine

    千次阅读 2019-07-26 08:23:00
    浅谈时序数据库TDengine 最近TDengine很火,本人也一直很早就有关注,其官方给出的测试性能结果很喜人,所以一开源,本人就进行了相关调研,最终发现还是存在着一定的问题,期待后续的完善吧 写入问题 必须为每个Tag...
  • 随着物联网的发展,时序数据库的需求越来越多,比如水文监控、工厂的设备监控、国家安全相关的数据监控、通讯监控、金融行业指标数据、传感器数据等。 在互联网行业中,也有着非常多的时序数据,例如用户访问网站的...
  • 时序数据库分析

    千次阅读 2017-10-25 09:06:07
    本文会从时序数据库的基本概念、使用场景、解决的问题一一展开,最后会从如何解决时序数据存储这一技术问题入手进行深入分析。 1. 背景 百度无人车在运行时需要监控各种状态,包括坐标,速度,方向,温度,...
  • 目录 Prometheus 与 Graphite ...数据存储 总结 Prometheus 与 InfluxDB 范围 数据模型和存储 体系结构 总结 Prometheus 与 OpenTSDB 范围 数据模型 数据存储 总结 Prometheus 与 Nagios...
  • 时序数据库 InfluxDB介绍

    千次阅读 2019-03-09 15:11:34
    InfluxDB 数据模型 InfluxDB的数据模型和其他时序数据库有些许不同,下图是InfluxDB中的一张示意表: 1. Measurement:从原理上...这和其他很多时序数据库有些不同,其他时序数据库中Measurement可能与Metric等...
  • ​近年来,物联网、车联网、工业互联网和智慧城市快速发展,时序数据库成为数据架构技术栈的标配。据 DB-Engines 数据显示,自2017年以来,每年时序数据库在“过去24个月排名榜”上高居榜首,且远高于其他类型的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,584
精华内容 4,233
关键字:

时序数据库存储日志