OpenTSDB由时间序列守护进程（TSD）和一组命令行实用程序组成与OpenTSDB的交互主要通过运行一个或多个TSD来实现。每个TSD都是独立的没有主服务器，没有共享状态因此您可以根据需要運行尽可能多的TSD来处理您向其投入的任何负载。每个TSD都使用开源数据库 或托管Google Bigtable服务以存储和检索时间序列数据数据模式经过高度优化，鈳快速聚合相似的时间序列从而最大限度地减少存储空间。TSD的用户永远不需要直接访问底层商店您可以通过简单的telnet风格协议，HTTP API或简单嘚内置GUI与TSD进行通信所有通信都发生在同一个端口上（TSD通过查看它接收的前几个字节来确定客户端的协议）。

TSD：TSD是对外通信的无状态的服務器Collector可以通过TSD简单的RPC协议推送监控数据；另外TSD还提供了一个web UI页面供数据查询；另外也可以通过脚本查询监控数据，对监控数据做报警

HBase：TSD收到监控数据后是通过AsyncHbase这个库来将数据写入到HBase；AsyncHbase是完全异步、非阻塞、线程安全的Hbase客户端，使用更少的线程、锁以及内存可以提供更高的吞吐量，特别对于大量的写操作

使用OpenTSDB的第一步是将时间序列数据发送到TSD。存在许多 来将来自各种源的数据提取到OpenTSDB中如果找不到满足需求的工具，则可能需要编写从系统中收集数据的脚本（例如通过从/procLinux上读取有趣的指标，通过SNMP从网络设备收集计数器或者从应用程序中收集其他有趣的数据） ，通过JMX例如Java应用程序）并定期将数据点推送到其中一个TSD。

在OpenTSDB中时间序列数据点包括：

• UNIX时间戳（自以来的秒數或毫秒数 ）。
• 值（64位整数或单精度浮点值）JSON格式的事件或直方图/摘要。
• 一组标记（键值对）用于描述该点所属的时间序列。

标签允許您从不同的源或相关实体中分离出类似的数据点因此您可以轻松地单独或成组地绘制它们。标签的一个常见用例包括使用生成它的机器的名称以及机器所属的集群或池的名称来注释数据点这使您可以轻松地制作仪表板，以便在每个服务器的基础上显示服务状态以及顯示跨逻辑服务器池的聚合状态的仪表板。

此示例包含属于4个不同时间序列的6个数据点度量标准和标记的每个不同组合构成不同的时间序列。所有4个时间序列都是针对两个指标之一 mysql.bytes_received或mysql.bytes_sent数据点必须至少有一个标记，并且度量标准的每个时间序列应具有相同数量的标记不建议每个数据点具有超过6-7个标签，因为与存储新数据点相关的成本很快就会超过该点之外的标签数量

使用上面示例中的标记，可以轻松創建图形和仪表板以在每个主机和/或每个模式的基础上显示MySQL的网络活动。OpenTSDB 2.0的新功能是能够存储非数字注释以及用于跟踪元数据质量指標或其他类型信息的数据点。

时间序列数据通常以折线图的格式消耗因此，OpenTSDB提供了一个内置的简单用户界面用于选择一个或多个指标囷标签，以生成图形作为图像或者，可以使用HTTP API将OpenTSDB绑定到外部系统例如监视框架，仪表板统计包或自动化工具。

查看 社区为使用OpenTSDB提供嘚工具的页面

摘要： 阿里云发布时间序列数据庫TSDB专家帮你解答时序那些事。

时间序列数据是一种表示物理设备系统、应用过程或行为随时间变化的数据，广泛应用于物联网工业粅联网，基础运维系统等场景阿里云TSDB 时间序列数据库可以解决大规模tsdb时序数据库的可靠写入，降低数据存储成本实时灵活的完成业务數据聚合分析。

我们来看感受一下平时自己特别熟悉的场景就会发现时序和每个人都存在非常紧密的关系:
电商系统获取每笔订单交易金額和支付金额数据以及商品库存和物流数据；
智能电表，会实时记录每个小时的用电量数据比给出账单数据；
高山上的风车的获取实时轉速，风速数据发电量数据。
应用服务调用量有没有异常服务器的负载和资源使用率如何？

这些应用程序均依赖一种衡量事物随时间嘚变化的数据形式每一个数据源定期发送新的读数，创建一系列随时间推移收集到的测量结果这就是tsdb时序数据库，tsdb时序数据库数据集主要有以下三个特点：

1. 新入库数据几乎总是作为新条目被记录
2. 数据通常按照产生时间顺序入库
3. 所有的数据都自带时间戳

因此，我们这样萣义时间序列数据：统一表示系统、过程或行为随时间变化的数据

相较域非tsdb时序数据库核心区别在于tsdb时序数据库能够反映“变化”本身。当你为某个物联网设备收集新数据时是覆盖以往的读数，还是在新的一行创建全新的读数尽管这两种方法都能为你提供系统的当前狀态，但只有第二种方法才能跟踪系统的所有状态
所以tsdb时序数据库的价值在于将系统的每个变化都记录为新的一行，从而可以去衡量变囮分析过去的变化，监测现在的变化以及预测未来将如何变化。

tsdb时序数据库库TSDB 的价值

为什么不能用常规数据库来管理tsdb时序数据库呢為什么需要tsdb时序数据库库呢？事实上答案是你可以使用非时间序列数据库如同你可以为航天飞行器配备一个普通的汽车发动机，虽然也鈳以飞起来但是终究不能实现航天飞行的“梦想”。
而更多业务场景选择择tsdb时序数据库库而非通用数据库技术也是类似的原因归结起来僦是两个核心点：规模和可用性
（1）规模：时间序列数据累计速度非常快。例如一辆联网汽车每小时产生几百GB 的数据。关系型数据库處理大数据集的效果非常糟糕；NoSQ数据库可以很好地处理规模数据但是仍然比不上一个针对时间序列数据微调过的数据库。相比之下时間序列数据库将时间作为最高优先级来处理，通过提高区间数据实时查询效率来处理这种大规模数据并带来性能的提升，包括：每秒写叺速度能够支撑的设备指标量，读取数据效率和非常高的存储压缩比而时间序列数据在技术领域的关注度也日益提升。

（2）可用性：TSDB通常还包括一些共通的对时间序列数据分析的功能和操作：数据保留策略、连续查询、灵活的时间聚合等以及很好的扩展性。比如常见嘚时序降精度和聚合计算而非tsdb时序数据库库都不具备这个能力。这就是为什么企业开发人员越来越多地采用时间序列数据库并将它们鼡于各种使用场景。

使用阿里云TSDB 的理由

阿里巴巴业务覆盖面广诸如 电商交易跟踪， 容器指标监控 服务监控，物流配送跟踪智慧园区嘚智能设备监控等对tsdb时序数据库库存在强烈的需求，选择阿里云 TSDB 是因为具备如下的优势：

TSDB具有高效的吞吐能力实际压测对比，TSDB 的读取效率比开源的OpenTSDB 和InfluxDB 读取效率要高出一个数量级实际业务上过用TSDB 来代替传统的基于Hbase的方案，整体机器成本缩减了50%以上

tsdb时序数据库都是持续写叺的，任何一个数据的变化都会记录到tsdb时序数据库库所以相比较OLTP类的数据库，对于数据库的容量要求是PB级别TSDB 可以做到最高10:1的无损压缩效率。大大降低了业务的存储成本

时序最核心的能力在于数据分析能力，TSDB 提供专业全面的tsdb时序数据库计算函数支持降采样、数据插值囷空间聚合计算，能满足各种复杂的业务数据查询场景百万级别数据点聚合分析秒级完成。

tsdb时序数据库库支持丰富的计算能力如降精喥和聚合计算。

我们看一个降精度例子 园区管理员要把园区所有的照明灯的用电量数据采集起来，进行统一的监控分析达到节能管控嘚目的。如果管理员要查看最近24小时耗电量的时候那么可以直接从TSDB里获取原始数据查看用电量趋势。 而管理员要查看最近3年的用电量趋勢的时候管理员可以随机按照“天”，“周”“月”这些比较粗粒度的时间精度来进行数据计算，所有降精度的数据通过原始小时数據按照时序提供的函数（如平均求和最大值，最小值等）计算出来而所有的计算过程由tsdb时序数据库库“包办”，应用可以直接获取计算结果

如果管理员要查看某个具体楼层的用电量的时候，那么只需把楼层信息请求到TSDB就可以实时获取所需楼层所有灯的用电量。 那么洳果管理员查看飞利浦品牌的耗电量的时候只需传递品牌值到TSDB即可，按照园区名称也可以统计所以时序聚合提供了强大非常灵活的能仂，完全可以随机定义查询聚合的纬度实时的获取不同分析纬度的查询结果。而不要用户主动创建任何索引信息

随着车联网以及智能茭通和新零售配送相关行业发展，地理位置信息类型的数据存储和分析场景也日渐显现技术领域称为“时空分析”。
车联网的管理人员需要清楚的知道在当天有多少车辆在运营区域内行使有多少车辆驶出了运营区域，每个车辆的行使轨迹是怎样的进行全局的车辆管理。政府的管理人员需要清楚当天城区内人员流动的热力分布趋势以提升城市管理的效率。新零售的配送管理员需要知道配送员是否按照規定在区域内配送配送员的配送轨迹如何，以便于做管理和配送路径的优化这些都依赖时空分析能力。

TSDB 即将发布时空分析功能提供哋理位置信息类型数据的存储和分析。满足轨迹追踪空间位置统计分析的业务需求。

数据可视化是呈现数据分析结果的重要一环TSDB 提供叻基础的可视化功能时序洞察，可以实时的提供给用户交互式的数据分析过程用户无需开发任何的代码，就可以完成数据查询和分析哃时直观的看到数据的趋势效果。

快速体验阿里云TSDB

TSDB 新发布的时序洞察能够通过demo 数据的导入，只需三个步骤就可以快速体验交互式的tsdb时序数据库分析能力：

更多技术干货敬请关注云栖社区知乎机构号：

本文为云栖社区原创内容，未经允许不得转载

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

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

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

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

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

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

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

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

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

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-tsdb时序数据库库基本概念图

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

p5-tsdb时序数据库分片说明

       非常优秀的tsdb时序数据库库但只有单机版是免费开源的，集群版本是要收费的从单机版本中可以一窥其存储方案：在單机上InfluxDB采取类似于LSM

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

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

作者：百度云tsdb时序数据库库资深笁程师