直播整理 TDengine 技术内幕分享：兼容 OpenTSDB

直播整理 | TDengine 技术内幕分享：兼容 OpenTSDB

整理|尔悦
嘉宾|廖浩均
小T导读：近年来，随着各种新兴技术的发展，物联网、工业互联网等行业获得了快速发展，由此产生的时序数据量也越来越庞大，通用大数据方案越来越难以为继，各种时序数据库产品应运而生，迁移也成为企业面临的重难点操作之一。
相比于TDengine，OpenTSDB算是入场更早一些的“玩家”，基于Hbase的产品模式有利也有弊：为有Hbase基础服务的企业降低了门槛的同时，过度依赖Hbase也为性能、压缩效果加设了一个瓶颈。随着企业业务规模的不断扩大，监控系统的部署成本和运行效率都会呈现增长的态势，随着时间的推移，OpenTSDB的缺陷所带来的负面效应将完全超越正面效果，顺丰科技的业务案例便印证了这一点。
此前，顺丰科技使用OpenTSDB作为全量监控数据存储方案，不仅运维和使用成本很高，性能上也越来越难以满足需求——日常大跨度和高频次查询已经无法满足当前业务发展的需求，查询返回结果甚至需要十几秒。随着用户量的增加，支持较低QPS的OpenTSDB非常容易崩溃，一旦崩溃将导致整个服务都变为不可用状态。随后在调研过市面的时序数据库产品后，顺丰科技便决定向TDengine进行迁移。
为了帮助和顺丰科技一样有迁移需求的企业，我们举办了TDengine技术公开课，本文基于涛思数据联合创始人廖浩均主讲的《TDengine技术内幕分享——兼容OpenTSDB》整理，从具体的操作层面为大家答疑解惑。
在做出迁移决定之前，一些同学可能比较关注的是TDengine对OpenTSDB的兼容度如何？这个问题要从两个维度来看，一是写入协议的全兼容，二是查询功能的全覆盖。前者来看，你无需改变任何一行代码就可以将数据完全写入到TDengine之中，非常简单方便。后者的话，我们提供了OpenTSDB查询功能的完全覆盖，但是有两点需要注意，一是不提供OpenTSDB的查询语法支持，二是不提供等效元数据查询支持。
之所以不提供OpenTSDB的语法支持，原因总结起来主要在于三点：
首先，围绕上图OpenTSDB的一个查询表达式来看，整体语义相对比较复杂，且查询语法表意能力弱，无法使用其映射出完整的查询能力。同时这套语法规则也不太符合使用SQL的习惯，无法满足一些非常复杂的应用查询，比如对于下方的SQL语句的查询：这是一个from词句的非相关查询，通过Json这种方式是没有办法表达出来的。
其次，相比于OpenTSDB，TDengine提供的查询功能、聚合函数更加丰富，还提供如TWA、TRATE、LEASTSQUARES、TOP、BOTTOM、LAST_ROW等，如果要匹配其查询语法的话，就不能够完整地去使用TDengine所提供的所有查询功能了。第三，OpenTSDB还在查询过程中提供了一种特别的插值机制，导致TDengine很难提供完全一致的查询结果。
除了语法层面不兼容外，在数据查询功能上，TDengine对于元数据查询功能和部分其他的功能也并不提供支持，具体原因如下：
除了上述的两点外，还有一个有区别的地方是OpenTSDB提供的“RollupAndPreAggregates”的特殊功能，简单来讲就是一个自动化的数据降采样机制，将写入系统的数据按照预设的时间窗口自动进行聚合，并将结果重新写入系统中，该新写入结果对用户可见。这个机制的提出是为了解决原始数据查询性能问题，帮助用户降低查询处理开销和响应时间。
利用这个功能，用户可以将应用中相当比例的standingquery（为了周期性获得上报信息或监控面板刷新展示而发出的采样或聚合查询）转向查询降采样后的结果，因而能够获得极大的性能提升。因为其将查询转化为数据读取操作。但是一个显而易见的问题是，这种策略对应用具有侵入性，在某些场景下，比如说降采样结果并不满足查询要求的时候，又会要求应用去读取原始数据，再按照需求发出查询请求得到结果。
由此可见，“RollupAndPreAggregates”的缺点是对应用不透明，使应用处理逻辑变得极为复杂且缺乏移植性，是时序数据库无法提供高性能聚合查询情况下的妥协与折中，TDengine在系统功能层面暂不支持这种自动的降采样。
那TDengine的查询性能优化策略又是如何实现的？
TDengine拥有内嵌、对用户（应用）透明的块级别预计算模块（SMA），能够提供很高性能的查询响应，而且让应用查询处理逻辑更加简单。
上图为预计算的一个流程，红色和绿色为两个时间线，数据写入时是两个时间线混在一起进行的，进入到系统之后同一个时间线的数据被归属到了一起，每一个数据块在落盘时都会经过这样一个预计算的过程，这个过程是由落盘的线程负责驱动执行的。预计算的类型很简单，如图所示共有count/max/min/sum这四种，每一个block前面都有一个小的预计算模块，这个结构对用户和应用来说是透明的。
当我们要发出一个查询时，举个例子，查询时间区间从第3秒到第13秒，即上图中红线框住的部分，因为预计算本身是针对数据块级别来建立的，所以在读取预计算结果时，只有中间两块完整的数据块是有意义的，这里只会读取预计算的块，而两侧的红框则需要读取真实的数据，计算引擎才会相应计算出一个结果。
但是真实数据相对于预计算部分来说规模非常大，如果一个数据块中有4000条记录，在读取真实数据时要把这4000条都读出来，而如果有预计算可以使用的话，可能就只需要一个数字，比如说上图中的Max，这种方式可以让I/O性能获得极大的提升，从而可以有效降低查询过程中I/O压力。
TDengine以这种内嵌支持机制保障高效的查询处理性能，而非聚焦在应用层、将复杂性留给用户。总而言之，从OpenTSDB迁移到TDengine，你只需调整应用的读取部分代码和实现逻辑，就能够获得立竿见影的效果和收益，不仅能够使用更多更高效的查询与计算功能、还能获得更快的响应时间和更低的存储资源开销，极大地降低软硬件部署成本。
前文中提到，无需改变任何一行代码就可以将写入OpenTSDB的过程调整为写入到TDengine之中，那这一点是如何做到的呢？这里有两种方式：一种是高级语言直接使用跨语言方案调用C接口写入，一种是直接调用HTTP接口采用RESTful方式写入。
如上图所示，如果你的应用是使用C#、Java、Rust、Python等高级语言编写并写入数据，那你需要通过TDengine提供的库先进行下重新编译，再通过高级语言的连接器（connector）连接TDengine的驱动（driver），将承载的逻辑封装到driver中，接下来通过一个名为taos_schemaless_insert的C语言接口处理所有的OpenTSDB的写入协议，采用结构化的方式将数据直接写入TDengine中。
看到这里可能有一些同学会有疑问，为什么逻辑要封装到driver中，而不是放到高级语言中？原因很简单，所有的高级语言都是直接跨语言调用接口，TDengine并不提供各种高级语言原生的接口，如果在高级语言层面实现了OpenTSDB到TDengine语法的兼容解析以及转换写入的话，那么针对不同的高级语言都需实现如此复杂的一套逻辑。而且考虑到在生产环境下的具体应用场景，多线程的环境使问题变得更加复杂，由此会产生很多边界情况需要处理。
因此我们决定把这个逻辑下沉到C语言端，让所有的高级语言直接去驱动C语言的接口来实现调用，如此一来不仅可以极大地减轻高级语言连接器的复杂程度，更有利于简化整个架构，从而加快演进的速度。
以上就是高级语言采用本地化接口方式写入数据的实现原理。如果你决定要采用RESTful的方式，那就更简单了，你只需要改一下配置文件、端口和IP地址，同时部署一个名为“taosAdapter”的组件。
taosAdapter是我们最近开源的、用Go语言开发的一套HTTP服务，如上图所示，从用户侧角度来讲，当你写入各种OpenTSDB协议之后，可以直接post到taosAdapter开放的端口，taosAdapter再利用底层的driver连接TDengine，直接完成数据写入的操作过程，无需用户再做任何操作。
taosAdapter架构
用户可以通过JDBC-RESTful包来使用taosAdapter提供的服务，也可以直接使用其提供的HTTP接口。具体的结构如上图所示，最底层是驱动层，依次向上是TDengine的goconnector、connectionpool、HTTP模块。
taosAdapter有以下的技术特点：
在介绍这个技术特点前，大家要思考一个问题。我们都知道TDengine本身是提供HTTP服务的，那为什么我们又要开发出taosAdapter这样一个组件来接收OpenTSDB的数据？
首先，在数据写入过程中，耗费CPU资源最多的是数据的解析与转换（SQL→二进制数据）操作，当然你可以使用动态绑定在一定程度上降低CPU的消耗，但是这个程度非常有限。当你使用Native的方式写入时，SQL的解析以及二进制的转换操作在客户端上就完成了，以HTTP的方式去写入则是将一个SQL语句直接post到服务器里去。为了降低服务器的负担，我们想到把这个操作从TDengine服务中分离出来。
这样一来，不仅可以有效地降低服务器的负载压力，还可以按需部署任意多台taosAdapter去写入数据——比如你部署了两台TDengine，采用内嵌方式的话实际上也只能提供两个HTTP服务，但是却能够部署4台乃至5台taosAdapter进行数据写入。结合实际的写入负载，可以不受限于TDengine集群节点的数量，弹性地调整taosAdapter部署的节点数量，以最大程度满足写入的实际需求。
同时，由于taosAdapter本身是一个无状态的协议转换系统，它是把HTTP的服务转换成TDengine内部的一个交换协议，并把数据写入到系统内部的，这种无状态的操作使得它的scaleout非常方便，能够高效率地进行taosAdapter集群弹性部署。此外，还能极大地降低TDengine服务器本身的负载，节约更多的服务资源来支撑更大规模的查询处理。
采用HTTP方式写入，对于写入应用来说是完全透明的，你甚至不需要去做重新编译之类的任何操作，只需要调整一下写入应用的IP:PORT，就可以将数据无缝写入到TDengine。这里提到的IP:PORT是taosAdapter的服务端口，而非TDengine的，TDengine内嵌的HTTP服务不支持OpenTSDB协议，这是很重要的一点，在此跟大家说明一下。
众所周知，OpenTSDB写入过程是没有数据库选择概念的，TDengine需要将数据写入到一个database里，这就延伸出一个问题——应该往哪个库里写，我们提出了一个解决方案，通过taosAdapter支持OpenTSDB数据分库并行写。
图1
图2
具体的操作如上面两张图所示。通过端口映射的方式，taosAdapter让不同的应用将数据写入到不同的数据库。在taosAdapter的配置文件中可以配置多个端口，每个端口映射到不同的TDengine数据库，可以将应用的数据自动写入到不同的数据库中，匹配上读写权限之后就可以有效控制不同的系统数据了。
上述的操作中，数据库需要由管理员预先手动建立（对写入应用透明），同时去调整配置文件，这个过程完成以后就能启动起来了，此时你的应用只需调整设置到正确的IP端口，数据就可以写入到正确的DB中了。
上图为分库并行写的详细流程，首先在taosAdapter中建立好端口到DB的映射配置表：6046:db1、6047:db2。以6046为例，系统先将通过端口6046拿到的数据直接映射到DB1，之后taosAdapter会设置与TDengine的连接，将其所连接的数据库切换到DB1数据库，继而进行数据写入，写入完成之后会对当前连接关联的DB信息清除，即把此连接恢复成没有指定任何DB的状态。写入6047时是同样的原理，只不过数据是自动写入到DB2，这就是分库并行写的具体实现。
以上就是对taosAdapter几个特点的分析。接下来我们看一下TDengine的无模式写入与普通SQL语句写入性能的差异。
下图是我们做的一个简单对比，在1000万数据写入情况下，taosAdapter的写入性能大概是普通SQL写入性能的74.97%，也就是说如果你用普通SQL写入时能达到每秒100万的写入速度，替换成taosAdapter大概能够达到每秒75万这个级别。有这样一个对比的话，大家就能够评估大概部署哪种规模的系统来支撑自身业务吞吐量了。
下面这张图展示的是在写入过程中taosAdapter的负载情况，黄色线条是taosd，绿色线条是taosAdapter。可以看到，taosAdapter的CPU消耗比较高，这主要是由于在做字符串相关的一些数值格式的转换变换所导致的。
taosAdapter当前支持的协议和数据写入格式也很丰富，不仅支持OpenTSDB的Json和telnet协议，同时还支持InfluxDBv1、statsd、collectd、tcollect、Icinga2、nodeexporter。后面我们会继续探索taosAdapter对于其他的exporter的支持。
此外，未来我们还会进一步优化taosAdapter的性能，目前taosAdapter对CPU的消耗还较高，后面将在可行的范围内优化架构设计及性能：首先，通过内部的部分同步接口升级为异步接口调用，以提升服务的性能，支持更高性能处理；其次，进一步优化它的处理逻辑，降低写入流程中的CPU开销。
点击链接查看活动详情，把iPhone13Pro带回家！博客:你写，我“奖”｜TDengine用户故事征集|涛思数据