定义
OpenTSDB是一个分布式、可伸缩的时间序列数据库（TSDB），其数据存储与检索建立在HBase之上[1]。它的官方定位是：为存储、索引并提供计算机系统（网络设备、操作系统、应用程序等）产生的海量指标数据而设计，使这些数据便于访问与绘制成图[4]。严格来说，它本身并不直接存储数据，而是一层面向时序场景的读写服务，数据的物理存放交由HBase完成[5]。
它面向的是数值型、随时间不断变化的监控指标，而非具有复杂结构和关联关系的事务数据[6]。一条时序数据由指标名称、时间戳、数值以及一组标签构成，指标与标签的组合界定了一条独立的时间序列[7]。
原理
OpenTSDB由时间序列守护进程（Time Series Daemon，缩写TSD）和一组命令行工具组成，用户通过运行一个或多个TSD与之交互[1]。每个TSD彼此独立，没有主节点，也不共享状态，因此可以按负载需要启动任意数量的实例，从而实现横向扩展[8]。TSD对外提供Telnet风格协议、HTTP API以及内置的简单图形界面，所有通信走同一端口，TSD依据收到的前几个字节判断客户端使用哪种协议[1]。
数据写入时，OpenTSDB采用推送模型：各被监控主机上的采集器周期性把数据点发往TSD，TSD再经由异步的HBase客户端写入集群[9]。写入过程是幂等且彼此独立的，行按固定时间边界对齐，因此多个TSD可以并发写入而无需互相协调[10]。
存储设计围绕RowKey展开。OpenTSDB为指标名、标签键和标签值分别分配固定长度的UID，并把它们与时间戳拼成RowKey，其顺序为指标UID、时间戳高位、标签键值UID依次排列[11]。时间戳在RowKey中被舍入到整小时，使同一条时间序列在一个小时内的多个采样点落到同一行、以不同列限定符区分，行的宽度由此变宽而行的数量大幅减少[11]。这一编码方式把指标名、标签与UID的双向映射放在独立表中管理，新UID通过HBase的原子自增命令分配，映射一经写入便不再变更[12]。
查询时，OpenTSDB先校验指标与标签是否存在，再据此确定扫描起止RowKey，对HBase发起范围扫描；取回的数据按标签值分组后依次进行降采样、聚合、缺失点插值与速率换算，最终返回结果[5]。标签过滤会被下推到HBase服务端执行，配合连续存储带来的数据局部性，使范围扫描较为高效[9]。
发展历程
OpenTSDB最初由StumbleUpon在2010年开发，动机是替换原有监控体系。该网站早期使用MySQL承载监控数据，随流量增长逐渐不堪重负，改用HBase后，StumbleUpon在HBase之上补足了时序场景所需的读写与聚合能力，并将这部分工作开源回馈社区[13]。该系统的作者为Benoit Sigoure，项目在GitHub上以LGPLv2.1+与GPLv3+双许可发布[14]。
1.0.0版本于2011年12月23日发布[15]。2012年，项目对数据行进行压缩合并，把原本每小时的多行数据合并为更宽的少数行，在降低存储占用的同时提升扫描速度[10]。2.0版本引入了毫秒级时间戳与非数值注释的存储能力[16]。2.4.0版本于2018年12月29日发布[14]。
此后项目进入维护状态，最后一个正式版本2.4.1发布于2021年9月2日，长期没有新的重大版本面世[2]。项目代码中也出现了面向2.5.0的候选版本分支[17]。
应用
OpenTSDB最主要的用途是承载监控系统：采集并保存大规模集群中网络设备、操作系统和应用程序产生的指标，再对其做查询与绘图[7]。它强调不删除、不降采样原始数据，因而适合需要长期保留精细粒度的场景，例如容量规划、故障复盘和SLA度量[15]。开源采集框架tcollector由StumbleUpon编写，可从Linux系统、Apache HTTPd、MySQL、HBase、memcached等来源收集大量指标并推送给TSD[1]。
除基础设施监控外，OpenTSDB也被用于其他具有时间特性的数据。有研究将其应用于地震前兆观测数据的存储，以替代扩展性和并发能力不足的关系数据库方案[18]。物联网传感器的持续读数同样属于其适用范围，相关实践中用它承载设备侧的时序数据并支撑分析[19]。该项目的使用者包括Yahoo、Box、Cloudflare、Salesforce等组织[20]。
部署方面，OpenTSDB依赖HBase，而HBase通常运行在Hadoop集群之上，ZooKeeper需要另行配置，因此整体部署与后续维护相对复杂[3]。多家云厂商在托管HBase产品中直接集成了OpenTSDB组件，以降低使用门槛[21]。
局限
OpenTSDB在存储后端上高度绑定HBase。官方说明中，它被专门针对符合Bigtable数据模型的存储系统设计，因此在相当长时间内不支持更换其他存储后端[16]。这一依赖也把性能与压缩效果的上限交给了底层HBase[3]。
查询能力存在明显边界。聚合计算在单个TSD节点上完成，取回的数据需要全部进入该节点内存后才开始处理，数据量大时既容易造成内存压力，也无法把一个查询拆分到多台TSD上分布式执行[22]。即使只查询短时段数据，扫描也可能覆盖整个小时的数据块[22]。此外，OpenTSDB不支持SQL，也不支持表连接，内置函数相对有限[3]。
标签的基数会显著影响效率。由于标签没有索引，一个指标的多个标签取值会产生组合爆炸，形成数量庞大的时间序列，查询单条序列也可能需要扫描大量数据[22]。为缓解写入热点而引入的预分桶机制，又会把一次查询拆成多个并发请求发往HBase，形成写入压力与查询并发之间的取舍[22]。
在数据模型上，OpenTSDB不提供计数器自增能力，只记录时间戳与数值的配对，需要速率或计数语义时须由采集端自行累加后上报[16]。压缩过程以小时为周期，整点时的读取、合并、重写与删除会产生明显的IO流量波峰，需要预留更多机器资源来承受[22]。默认情况下，TSD会先缓冲约1秒的数据再落盘，若进程异常退出，这一秒内的数据点可能丢失[16]。
参见
参考资料
- OpenTSDB - A Distributed, Scalable Monitoring System [引用日期2026-10-14]
- opentsdb [引用日期2026-10-14]
- 详解 OpenTSDB 的优劣势 - TDengine | 涛思数据 [引用日期2026-10-14]
- socket.dev 上的网页 [引用日期2026-10-14]
- OpenTSDB简介 [引用日期2026-10-14]
- OpenTSDB_组件介绍_产品介绍_MapReduce服务 MRS-华为云 [引用日期2026-10-14]
- OpenTSDB概述 [引用日期2026-10-14]
- OpenTSDB [引用日期2026-10-14]
- OpenTSDB [引用日期2026-10-14]
- Lessons Learned from OpenTSDB [引用日期2026-10-14]
- HBiAsample_ch7(PDF) [引用日期2026-10-14]
- HBase Schema [引用日期2026-10-14]
- StumbleUpon 创建了一个开源框架，用来收集服务器的各种监控指标 [引用日期2026-10-14]
- title: "OpenTSDB" [引用日期2026-10-14]
- OpenTSDB [引用日期2026-10-14]
- FAQ - A Distributed, Scalable Monitoring System [引用日期2026-10-14]
- opentsdb [引用日期2026-10-14]
- 第 35 卷 第 3 期 (558~564) 中国地震 Vol [引用日期2026-10-14]
- 호 연관성 분석은 복잡도가 매우 증가하기 때문에 어 [引用日期2026-10-14]
- OpenTSDB [引用日期2026-10-14]