通过SQL即可让监控分析更简单更高效

1.前言

阿里时序时空数据库TSDB最新推出TSQL&＃xff0c;支持标准SQL的语法和函数。用户使用熟悉的SQL&＃xff0c;不仅仅查询更简单易用&＃xff0c;用户还可以利用SQL强大的功能&＃xff0c;实现更加复杂的计算分析。

2. 为什么需要用SQL做时序查询&＃xff1f;

2.1 SQL拥有广泛用户基础

SQL作为一个诞生于上世纪70年代的编程语言已经存在几十年了。这是一个相对而言较“古老”的编程语言&＃xff0c;但又是一个有着广泛用户基础的语言。
在跟踪主要编程语言的流行程度的TIOBE index[1]中&＃xff0c;SQL在2019年4月份的排名是第8。而如果把排名列在11-20之间的SQL的两个“兄弟”PL/SQL, Transact-SQL也合并进来的话&＃xff0c;SQL的流行度应该更高。

根据stackoverflow网站的调查 [2]&＃xff0c;SQL在最流行的编程语言榜上排在第4位。

无论TIOBE index还是stackoverflow的编程语言排行榜&＃xff0c;都从一个侧面反映了SQL的广泛用户基础。作为一个查询语言&＃xff0c;SQL是用户和数据库系统交互的(直接或间接)主要方式。支持一个拥有广泛用户基础的查询语言&＃xff0c;对于推广数据库系统来说&＃xff0c;是非常重要的。

2.2 用户学习成本

最近几年出现的几个主要面向时序场景的数据库&＃xff0c;除了TimescaleDB是在Postgres基础上所以支持PG生态包括SQL语言支持&＃xff0c;其他几个比如InfluxDB, OpenTSDB, Prometheus都有各自不同的查询语言和接口&＃xff1a;InfluxDB有InfluxQL&＃xff0c;OpenTSDB有自己的Restful API, 而Prometheus有PromQL。每一个系统都可以声称自己的语言是独一无二的&＃xff0c;更适合时序查询这样的场景&＃xff1b;但不可否认的事实是用户需要去花时间去学习一种新的语言&＃xff0c;并且如果这个语言为了功能完善&＃xff0c;还在不断演进中&＃xff0c;这样的学习成本对用户来说&＃xff0c;尤其显得高了。
举个例子&＃xff0c;InfluxDB的InfluxQL并不支持Join&＃xff0c;Subqueries, 以及SQL中很常见的UDF等功能&＃xff0c;这意味着用户并不能在不同数据之间进行关联分析计算&＃xff0c;也不能在系统函数基础上进行扩展开发。InfluxDB设计者在听到社区的意见后&＃xff0c;做了一个很有“创意”的事情&＃xff1a;在新版本里支持Join&＃xff0c;UDF等功能&＃xff0c;但并不是让InfluxQL变得更加接近于SQL&＃xff0c;而是在一个全新的Flux(一个新的functional scripting language)里支持 [3]。用户想要做InfluxQL不能做的事情&＃xff0c;那就再来学习一个新语言吧。
一个很有意思的事情&＃xff0c;10多年前开始出现的NoSQL系统&＃xff0c;比如MapReduce/Hadoop, BigTable,Casandra&＃xff0c;HBase等&＃xff0c;一开始也是以各自不同的查询语言出现的。在经历了多年用户推广之后&＃xff0c;NoSQL开始拥抱SQL&＃xff0c;变成了NotOnlySQL或者NewSQL。时序数据库这样一个新兴的数据库领域&＃xff0c;也有可能重复这样的历史。原因很简单&＃xff0c;用户学习一个新语言的成本越高&＃xff0c;越会阻碍一个系统被推广到大众接受的程度。

2.3 BI工具生态支持

时序数据库提供SQL的查询支持&＃xff0c;一个很重要的原因是将时序数据库的应用场景扩展到商业分析(BI/Business Analysis)&＃xff0c;商业决策这样高附加值领域。
当前几个主要的时序数据库&＃xff0c;包括InfluxDB, OpenTSDB和Prometheus&＃xff0c;主要侧重于基础性能监控这样的场景&＃xff0c;利用Grafana这样的可视化工具&＃xff0c;实现监控报警这一类基本功能。另一方面&＃xff0c;监控报警还没有充分利用挖掘时序数据的商业价值。进一步的功能&＃xff0c;需要充分利用现有SQL生态系统中的商业分析工具&＃xff0c;比如Tableau, Qlik&＃xff0c;Oracle BI, IBM Cognos等。这些BI工具&＃xff0c;往往是以SQL的方式同后端数据库交互。从这个角度来说&＃xff0c;时序数据库的SQL支持对于对接BI生态系统中的各种工具&＃xff0c;尤为重要。

2.4 TSQL面向的用户群

在阿里时序数据库TSDB支持的兼容OpenTSDB查询协议之上推出的TSQL查询引擎&＃xff0c;主要是面向以下两类用户&＃xff1a;

**- 时序数据库TSDB的新应用开发者 
**&＃xff1a;这类用户往往以前使用关系数据库&＃xff0c;因为关系数据库本身处理时序数据的性能和可扩展性的局限&＃xff0c;而转而使用TSDB。这些新应用开发者&＃xff0c;希望TSDB在提供比关系数据库更好的时序性能和扩展性的同时&＃xff0c;能够用他们以前熟悉的查询语言进行应用开发&＃xff0c;而不是去学习一个新的查询语言。
**- 数据分析师&＃xff1a;
**这类用户并不开发应用&＃xff0c;他们的工作是利用已有的商业分析工具&＃xff0c;对时序数据进行进一步的查询分析。他们本身并不直接使用SQL&＃xff0c; 但所使用的工具以SQL作为和时序数据库TSDB交互的查询语言。

3. 现有时序数据库系统SQL查询能力比较

这里简单对比时序数据库系统中提供SQL查询&＃xff0c;或SQL-like查询能力的InfluxDB, TimescaleDB, 阿里云TSDB。

4. TSQL系统架构

上图是TSQL的总体架构以及和TSDB引擎和存储之间的协调工作关系。简单来讲&＃xff0c;TSQL是一个典型的MPP的SQL分析引擎&＃xff0c;通过Connector同TSDB引擎和存储进行数据交换。Connector支持MetaAPI和DataAPI。

TSQL是在两个Apache开源项目基础上演进开发的&＃xff1a;

• Apache Calcite作为SQL的解析器和计划生成和优化器。
• Apache Drill提供分布式的SQL执行层。
  Apache Calcite作为一个扩展性好&＃xff0c;支持标准SQL语法和语义的SQL计划生成器&＃xff0c;已经被很多数据处理相关的开源项目使用[6]&＃xff0c;包括大数据ETL的Apache Hive, HBase上的SQL解决方案Apache Phoenix, 也有流数据处理框架Apache Fink (阿里的Blink)和Apache Beam等。 TSQL使用Calcite作为SQL计划生成器&＃xff0c;可以在兼容标准SQL方面&＃xff0c;充分利用开源社区已有的成果。

4.1 时序数据Schema管理

InfluxDB, OpenTSDB和Prometheus都采用的是一种Schema-on-write的方式&＃xff0c;也就是用户并不需要明确定义metric的schema, 而是将schema的信息隐藏在数据中&＃xff0c;在数据写入的时候&＃xff0c;同时管理着schema。这样做的好处是更高的灵活性&＃xff1a;

• 在写入数据的时候&＃xff0c;用户不需要事先必须用Create Table DDL来创建table&＃xff1b;
• 在时序数据tag set出现变化的时候&＃xff0c;用户不需要事先用Alter Table来修改table的schema。

TimeScaleDB从PG上扩展而来&＃xff0c;所以是采用的是严格的Schema的管理方式。在使用灵活性方面&＃xff0c;不如上面其他3个时序数据库。

Calcite作为一个SQL计划生成器&＃xff0c;很适合时序数据库这样的比较松散的Schema管理方式。 Calcite的Schema Adapter&＃xff0c;可以支持

1. 动态的Schema 发现&＃xff0c;
2. 任意一个数据集&＃xff0c;只要实现Schema管理中的接口API, 就可以在计划解析生成阶段被当成一个Table来处理。

TSQL在Calcite的Schema Adapter基础上&＃xff0c;利用TSDB引擎中新增加的MetaAPI&＃xff0c;来完成SQL计划解析和生成。这免去了用户必须事先在一个集中式的catalog中预先定义Table DDL等繁琐工作&＃xff0c;给用户带来了很多的灵活性。

4.2 时序数据查询执行

TSQL的执行层&＃xff0c;利用了Apache Drill的runtime execution。Drill的runtime execution&＃xff0c;具备以下特点

• 利用off-heap内存作为计算内存&＃xff0c;减少Java heap内存GC所带来的延迟问题
• 基于Columnar格式的ValueVector (Apache Arrow的前身)&＃xff0c;提升查询执行效率
• 动态代码生成和编译
  UDF支持

5. TSQL时序查询功能

我们以一个基础性能监控场景来举例说明TSQL能完成的时序查询功能。利用一个时序数据库业界公开的时序性能Benchmark[5] 生成的模拟数据&＃xff0c;按照DevOps这样的场景&＃xff0c;产生了cpu相关的10不同的metric。每个metric对应了机房(datecenter)&＃xff0c;主机(hostname)&＃xff0c;rack等标签下所采集的服务器cpu相关的指标数据。

5.1 元数据查询

可以用下面的方式查询TSDB中所有的metric/table

SHOW TABLES FROM tsdb

如果我们希望列出所有以cpu为前缀的metric/table&＃xff0c;可以在上面的查询基础之上添加附带过滤条件.

show TABLES from tsdb where TABLE_NAME like &＃39;cpu%&＃39;

下图给出了命令的部分输出:

在获得metric/table 名字后&＃xff0c;我们可以进一步用SQL中的&＃39;DESCRIBE&＃39;命令来查询这个metric/table的schema信息

describe tsdb.&＃96;cpu.usage_user&＃96;

下图显示了上面的&＃39;describe&＃39;命令的部分结果&＃xff1a;

5.2 时序数据简单查询

用下面的SQL查询可以获得指定时间段内的&＃39;cpu.usage_user&＃39;的指标值&＃xff0c;时间戳&＃xff0c;以及对应的标签值。

select *
from tsdb.&＃96;cpu.usage_user&＃96;
where &＃96;timestamp&＃96; between &＃39;2019-05-01 16:00:00&＃39; and &＃39;2019-05-01 18:00:00&＃39;

这里&＃xff0c; 将被转换成 metric/table下所有的列&＃xff0c;包括指标值&＃xff0c;时间戳&＃xff0c;所有的标签列。可以以具体的列名的一个列表来代替。
作为对比&＃xff0c;如果把上面的查询转化成OpenTSDB协议来查询&＃xff0c;相对应的查询如下&＃xff1a;

{"start": "1556726400000","end": "1556733600000","queries": [{"aggregator": "none","metric": "cpu.usage_user","rate": null,"downsample": null,"filters": []}]
}

可以在时间戳的过滤条件基础上&＃xff0c;增加指标列上的条件。下面的查询&＃xff0c;列出指定时间段内&＃xff0c;3台主机上的指标值&＃xff0c;并且使用limit, 把查询结果限制在100行。

select *
from tsdb.&＃96;cpu.usage_user&＃96;
where &＃96;timestamp&＃96; between &＃39;2019-05-01 16:00:00&＃39; and &＃39;2019-05-01 18:00:00&＃39; and hostname in (&＃39;host_1&＃39;, &＃39;host_5&＃39;, &＃39;host_10&＃39;)
limit 100

可以在查询中使用标准SQL中丰富的数值计算函数&＃xff0c;字符串函数或时间戳函数。下面的SQL&＃xff0c;我们分别使用了数值运算函数sqrt, 时间戳函数extract 和字符串lower。

5.3 时序降精度&＃xff0c;聚合运算

如果我们要计算两小时之内&＃xff0c;每台主机上每5分钟的指标cpu.usage_user的最大值&＃xff0c;最小值&＃xff0c;以及数据采样点的个数。这样的查询&＃xff0c;代表了在时间维度上的降精度&＃xff0c;并且在标签hostname上进行的聚合运算。用TSQL来表示这样的查询&＃xff1a;

selecthostname,tumble(&＃96;timestamp&＃96;, interval &＃39;5&＃39; minute) ts,max(&＃96;value&＃96;) maxV,min(&＃96;value&＃96;) minV,count(&＃96;value&＃96;) cntfrom tsdb.&＃96;cpu.usage_user&＃96;where &＃96;timestamp&＃96; between 1556726400000 and 1556733600000 and hostname in (&＃39;host_8&＃39;,&＃39;host_5&＃39;,&＃39;host_6&＃39;)
group by hostname, ts

如果用OpenTSDB的协议来查询:

{"start": "1556726400000","end": "1556733600000","queries": [{"aggregator": "max","metric": "cpu.usage_user","downsample": "5m-max","tags":{"hostname":"host_8|host_5|host_6"}},{"aggregator": "min","metric": "cpu.usage_user","downsample": "5m-min","tags":{"hostname":"host_8|host_5|host_6"}},{"aggregator": "sum","metric": "cpu.usage_user","rate": null,"downsample": "5m-count","tags":{"hostname":"host_8|host_5|host_6"}}]
}

可以看到&＃xff0c;相比较原来Restful API的查询&＃xff0c;TSQL能够用更简洁的方式来表示相同的查询语义&＃xff1b;并且&＃xff0c;如果用户本来就熟悉SQL的使用方法&＃xff0c;节省用户去学习Restfule API里JSON各个字段的含义。从降低用户学习成本&＃xff0c;增加易用性这个角度&＃xff0c;TSQL带来了较明显的价值。

TSQL不仅仅带来查询简洁&＃xff0c;用户易用的优点&＃xff0c;并且&＃xff0c;更重要的是&＃xff0c;用TSQL能够表达Restful API里不能直接表达的查询语义。在TSDB引入TSQL之前&＃xff0c;如果用户需要进行这样的查询计算&＃xff0c;则用户必须通过自己的应用程序&＃xff0c;在Restful API获得数据后&＃xff0c;再进行后计算&＃xff0c;来满足业务需要。在自己的应用程序中进行后计算&＃xff0c;往往需要付出很大的应用开发代价。

5.4 聚合后计算&＃xff0c;过滤&＃xff0c;排序

下面的例子&＃xff0c;计算2个小时内&＃xff0c;3台机器上每5分钟内&＃xff0c;cpu.usage_user指标值的最大值和最小值的差异超过10.0的时段和hostname, 并按照差异值从大到小排序&＃xff1a;
在上面的例子中个&＃xff0c;在获得最大值和最小值后&＃xff0c;进一步计算两者的差异值&＃xff0c;并根据差异值进行过滤和排序。这样的聚合后计算处理&＃xff0c;无法用OpenTSDB的查询协议表示&＃xff1b;用户如果要表达这样的语义&＃xff0c;就必须在应用程序中计算。

selecthostname,tumble(&＃96;timestamp&＃96;, interval &＃39;5&＃39; minute) ts,max(&＃96;value&＃96;) - min(&＃96;value&＃96;) as diffVfrom tsdb.&＃96;cpu.usage_user&＃96;where &＃96;timestamp&＃96; between &＃39;2019-05-01 16:00:00&＃39; and &＃39;2019-05-01 18:00:00&＃39; and hostname in (&＃39;host_1&＃39;, &＃39;host_5&＃39;, &＃39;host_10&＃39;)
group by hostname, ts
HAVING diffV > 10.0
order by diffV DESC

5.5 任意复杂的条件表达式

TSDB的Restful API对于只提供有限的几种filter, 而并不支持任意filter通过AND/OR的组合。比如下面的例子&＃xff0c;是一个TSQL业务中使用的查询。其中WHERE条件部分是并不能用Restful API来表示的&＃xff0c;因为Restful下的filters是只有AND, 而OR只有在相同tag上通过&＃39;value1|value2|vale3&＃39;这样的形式来表达。

where((obj_id&＃61;&＃39;ems30_NA62_183249003&＃39; and obj_type&＃61;&＃39;ems30_NA62_20204&＃39; and room&＃61;&＃39;ems30_NA62_C-T01.NA62&＃39; and building&＃61;&＃39;ems30_NA62_C&＃39;) or(obj_id&＃61;&＃39;ems30_NA62_183249746&＃39; and obj_type&＃61;&＃39;ems30_NA62_20204&＃39; and room&＃61;&＃39;ems30_NA62_C-T01.NA62&＃39; and building&＃61;&＃39;ems30_NA62_C&＃39;) or(obj_id&＃61;&＃39;ems30_NA62_183246962&＃39; and obj_type&＃61;&＃39;ems30_NA62_20204&＃39; and room&＃61;&＃39;ems30_NA62_C-T01.NA62&＃39; and building&＃61;&＃39;ems30_NA62_C&＃39;) or(obj_id&＃61;&＃39;ems30_NA62_183248143&＃39; and obj_type&＃61;&＃39;ems30_NA62_20204&＃39; and room&＃61;&＃39;ems30_NA62_C-T01.NA62&＃39; and building&＃61;&＃39;ems30_NA62_C&＃39;) or(obj_id&＃61;&＃39;ems30_NA62_183249191&＃39; and obj_type&＃61;&＃39;ems30_NA62_20204&＃39; and room&＃61;&＃39;ems30_NA62_C-T01.NA62&＃39; and building&＃61;&＃39;ems30_NA62_C&＃39;) or(obj_id&＃61;&＃39;ems30_NA62_183249964&＃39; and obj_type&＃61;&＃39;ems30_NA62_20204&＃39; and room&＃61;&＃39;ems30_NA62_C-T01.NA62&＃39; and building&＃61;&＃39;ems30_NA62_C&＃39;) or(obj_id&＃61;&＃39;ems30_NA62_183247148&＃39; and obj_type&＃61;&＃39;ems30_NA62_20204&＃39; and room&＃61;&＃39;ems30_NA62_C-T01.NA62&＃39; and building&＃61;&＃39;ems30_NA62_C&＃39;)) and &＃96;timestamp&＃96; between &＃39;2019-04-25 18:20:21&＃39; and &＃39;2019-04-25 18:20:31&＃39;...

支持任意组合的AND/OR的条件表达式&＃xff0c;对于应用开发是很有意义的。在集团基础监控业务(raptor-pro)中&＃xff0c;一个突出的亮点是“定制化监控报警”&＃xff1a;允许业务方的用户来定制查询条件&＃xff0c;并且查询条件可以是任意的AND/OR组合。TSQL为"定制化监控报警"的功能实现&＃xff0c;提供了有力的技术保障。

5.6 多个metric之间join

这个查询&＃xff0c;把cpu.usage_system和cpu.usage_idle在hostname和timestamp上做等值join, 然后计算每5分钟两个度量值之和的sum。

select t1.hostname, tumble(t1.&＃96;timestamp&＃96;, interval &＃39;5&＃39; minute ) ts, sum(t1.&＃96;value&＃96; &＃43; t2.&＃96;value&＃96;) as sumV
from tsdb.&＃96;cpu.usage_system&＃96; t1, tsdb.&＃96;cpu.usage_idle&＃96; t2
where t1.&＃96;timestamp&＃96; >&＃61;&＃39;2019-05-01&＃39; and t1.&＃96;timestamp&＃96; <&＃61; &＃39;2019-05-01 01:00:00&＃39; and t1.hostname &＃61; t2.hostnameand t1.&＃96;timestamp&＃96;&＃61; t2.&＃96;timestamp&＃96;
group by t1.hostname, ts

上面的查询&＃xff0c;如果我们采用TSDB的多值模型&＃xff0c;把cpu.usage_system和cpu.usage_idle处理成一个metric的不同的field, 则不需要join就可以完成。但如果我们需要在分组聚合后的结果上再做join, 多值模型也无法解决问题。

5.7 分组聚合后join计算

下面的查询&＃xff0c;分别对cpu.usage_system和cpu.usage_idel按照5分钟计算聚合函数sum(), 再通过join, 对齐&＃xff0c;计算相对应的比例。并且&＃xff0c;每个子查询的Where条件&＃xff0c;除了包括在tag上和时间戳上的条件&＃xff0c;还包括值上的过滤条件。
类似这样的查询&＃xff0c;是无法直接在TSDB的RestAPI来实现的&＃xff1b;用户只能在自己的应用程序中实现&＃xff0c;增加了应用开发成本。

select f0.hostname, f0.ts, f0.sumV / f1.sumV as resultValue
from (select hostname,tumble(&＃96;timestamp&＃96;, interval &＃39;5&＃39; minute) ts, sum(&＃96;value&＃96;) as sumVfrom tsdb.&＃96;cpu.usage_system&＃96;wherehostname in (&＃39;host_0&＃39;, &＃39;host_5&＃39;, &＃39;host_10&＃39;) and&＃96;timestamp&＃96; between &＃39;2019-05-01 00:00:00&＃39; and &＃39;2019-05-01 01:00:00&＃39; and &＃96;value&＃96;<&＃61;50group by hostname, ts) as f1
join (select hostname,tumble(&＃96;timestamp&＃96;, interval &＃39;5&＃39; minute ) ts, sum(&＃96;value&＃96;) as sumVfrom tsdb.&＃96;cpu.usage_idle&＃96;wherehostname in (&＃39;host_0&＃39;, &＃39;host_5&＃39;, &＃39;host_10&＃39;) and&＃96;timestamp&＃96; between &＃39;2019-05-01 00:00:00&＃39; and &＃39;2019-05-01 01:00:00&＃39; and &＃96;value&＃96;<&＃61;30group by hostname, ts) as f0
on f1.hostname &＃61; f0.hostname and f1.ts &＃61; f0.ts

5.8 UDF扩展功能

使用UDF来扩展功能&＃xff0c;对于时序数据库这样聚焦特定领域的数据库来说&＃xff0c;是非常必要的&＃xff0c;因为往往SQL标准中定义的函数&＃xff0c;并不能完全满足需要。TSQL有一个完善的UDF的体系&＃xff0c;用户只要按照约定的接口&＃xff0c;用Java语义就可以实现扩展。比如&＃xff0c;我们在TSQL中引入的把时间戳分割成不重合的窗口的函数tumble&＃xff0c;其实现就是由下面不到15行代码完成。
用户可以用Java实现不同的scalar UDF或者aggregate UDF, 并把编译后的jar加入到TSQL的系统类库目录&＃xff0c;就可以自行扩展TSQL的查询计算功能了。

&＃64;FunctionTemplate(name &＃61; "tumble", scope &＃61; FunctionTemplate.FunctionScope.SIMPLE, nulls &＃61; FunctionTemplate.NullHandling.NULL_IF_NULL)public static class Tumble implements DrillSimpleFunc {&＃64;Param TimeStampHolder timeStamp;&＃64;Param IntervalDayHolder interval;&＃64;Output TimeStampHolder out;&＃64;Overridepublic void setup() {}&＃64;Overridepublic void eval() {long intervalMs &＃61; interval.days * org.apache.drill.exec.vector.DateUtilities.daysToStandardMillis &＃43; interval.milliseconds;out.value &＃61; timeStamp.value - timeStamp.value % intervalMs;}}

6.TSQL可视化查询

阿里云TSDB已经提供了TSQL可视化交互式开发功能&＃xff0c;通过web页面可以方便的进行TSQL的测试和开发&＃xff0c;如下图Demo所示。

原文链接
本文为云栖社区原创内容&＃xff0c;未经允许不得转载。