解密 云HBase时序引擎OpenTSDB 优化技术

  • 时间:
  • 浏览:0

它们长度默认是八个字节,即最多非要分配 2^24=16777216 个UID。可不须要通过哪哪几个参数调整:

很明显,每个KV都记录了rowX,那rowX只要另八个空间浪费。你你这种空间不仅影响成本,还影响查询数率(毕竟数据多了)。压缩做的事情只要把多个小KV合成另八个大KV,减少这累积浪费。已经 压缩的完后 会涉及到对HBase的“读-写-删”,这只要整点HBase IO流量的来源。

非要 亲戚亲戚大伙有非要 方式 ,既做压缩,同去又消除这累积HBase IO呢?

salt你你这种东西最好根据当时人HBase集群规模去配置,它有另八个配置:

十根时间线由 Metirc + 多个tag 唯一取舍,时间线上会有源源不断的数据点(Data Point)写入,数据点由时间戳和值组成。OpenTSDB支持秒级(10位整数),毫秒级别(13位整数)五种时间精度。

salt:打散同一metric不同去间线的热点

metric, tagK, tagV:实际存储的是字符串对应的UID(在tsdb-uid表中)

timestamp:每小时数据位于一行,记录的是每小时整点秒级时间戳

举个例子,比如亲戚亲戚大伙监控另八个手环埋点的心跳信息,非要 亲戚亲戚大伙可不须要另另八个定义:

独立部署,即与多个业务共享另八个HBase。适合时序业务较小,可能用不满HBase资源。

时间如流水,一去不复返。自古不乏对时间流逝的感慨,而现代可能有已经 技术记录流逝的过去。亲戚亲戚大伙可不须要拍照,可不须要录像,当然还可不须要用时序数据库!

。首先亲戚亲戚大伙要明白OpenTSDB为何会 会 要做压缩?在压缩些哪哪几个东西?

非要 亲戚亲戚大伙通过 band.heartbeat  + id=1  就能查询到编为1的手环埋点到的心跳信息。

前面提到过OpenTSDB一行一小时的特点,非要 一行里会有已经 KV。皮下组织 上看起来好像没哪哪几个问题,其他实际上对比逻辑视图和物理视图已经 发现其他问题。

注意

集群可能写过数据后就无法修改,已经 最好是一结束英语 就取舍好,建议另八个字节。可能使用压缩技术后,RowKey多占的哪几个字节可不须要忽略,下文会提到。



            

  OpenTSDB                                                                  HBase

你你这种设计有哪几个特点:



查询的完后 会并发 tsd.storage.salt.buckets   个Scanner到HBase上,已经 可能你你这种配置非要 来越多,对查询影响比较大,容易打爆HBase。这里我我我觉得是另八个权衡,写入热点和查询压力。默认20我我我觉得我当时人我我觉得不为何多,配置3~8就差非要 来越多了,当然实际效果还和metric设计有关,可能在另八个metric里设计了已经 时间线,那就得配置已经 bucket。在另八个metric中设计非要 来越多时间线,会影响OpenTSDB的查询数率,已经 不建议非要 做。

你你这种参数也是设置了就非要改的,已经 也是要一结束英语 规划好。

上述2种模式,云HBase产品都能提供支持。

时序数据库是专门存放随着时间推移而不断变化的数据。近些年,随着IoT等概念的流行,时序数据库成为数据库另八个相对独立的领域逐渐受到重视,广泛应用于物联网、监控系统、金融、医疗和零售等多种场景。

当然有!亲戚亲戚大伙可不须要把压缩的逻辑装下 HBase內部去。可能HBase五种就须要对HFile做合并工作,这完后 HBase五种就会读写数据文件,这累积对HDFS的IO不用少,而亲戚亲戚大伙通过hook在HBase读出数据后,替换掉要写入的数据(即压缩好的数据)。

过去1另八个月时序数据库(Time Series DBMS)热度不断增长

可不须要看得人会有另八个数倍流量的爆发,要持续已经 不用 消化。

非要 云上的用户如保构建另八个存储海量数据的时序数据库呢?笔者这里推荐使用 云HBase + OpenTSDB 方案。云HBase是使用阿里多年优化过的HBase内核版本,本文不作非要 来越多介绍,详情请看产品主页。

OpenTSDB是一款基于HBase构建的时序数据库,它的数据存储完全交给HBase,五种非要 任何数据存储。所有节点是对等的,已经 部署起来我我我觉得是非常方便的。可能基于HBase,已经 五种就具备了横向扩展,存储海量数据的能力。常见的部署模式有2种,五种分离部署,五种混合部署。



实现上边你你这种功能,当然须要一定内核开发量。喜迅是通过云HBase购买页面购买的时序引擎,可能自带了上述功能。不管是分离部署模式,还是混合部署模式。

你你这种功能的好处显而易见,消除峰值节省成本,提升集群稳定性。另另八个亲戚亲戚大伙对另八个现有的HBase集群空闲资源需求就都在非要 高了,完全可不须要复用了。下面是使用此功能后,同样只做写入的测试集群的流量请况:

这是列名(HBase中称为qualifier)的格式,可不须要看得人毫米级须要多出另八个字节。已经 可能你的埋点间隔不须要精确到毫秒级别,那请一定使用秒级(10位整数)。Value非要存储整数和浮点,已经 有另八个bit存储Float flag。

混合部署,即TSDB守护应用应用程序和RS在另八个VM内。适合时序业务较重,须要独享HBase。

OpenTSDB有个很常见其他很麻烦的问题,只要整点完后 对HBase对流量冲击。下面2张图是亲戚亲戚大伙另八个测试集群只做写入对效果:

逝者如斯夫,不舍昼夜。

                                                       —— 孔子



这里亲戚亲戚大伙都在有问题,直接通过qualifier长度是4还是2不就能判断是秒级精度的数据点,还是毫秒了么?为何会 会 还须要MS flag另另八个另八个标记信息?阅读下面的“压缩”累积,就能知道为哪哪几个。