通过SQL即可让监控分析更简单更高效
1.前言
阿里時(shí)序時(shí)空數(shù)據(jù)庫TSDB最新推出TSQL，支持標(biāo)準(zhǔn)SQL的語法和函數(shù)。用戶使用熟悉的SQL，不僅僅查詢更簡單易用，用戶還可以利用SQL強(qiáng)大的功能，實(shí)現(xiàn)更加復(fù)雜的計(jì)算分析。
2. 為什么需要用SQL做時(shí)序查詢？
2.1 SQL擁有廣泛用戶基礎(chǔ)
SQL作為一個(gè)誕生于上世紀(jì)70年代的編程語言已經(jīng)存在幾十年了。這是一個(gè)相對(duì)而言較“古老”的編程語言，但又是一個(gè)有著廣泛用戶基礎(chǔ)的語言。
在跟蹤主要編程語言的流行程度的TIOBE index[1]中，SQL在2019年4月份的排名是第8。而如果把排名列在11-20之間的SQL的兩個(gè)“兄弟”PL/SQL, Transact-SQL也合并進(jìn)來的話，SQL的流行度應(yīng)該更高。
?
根據(jù)stackoverflow網(wǎng)站的調(diào)查 [2]，SQL在最流行的編程語言榜上排在第4位。
?
無論TIOBE index還是stackoverflow的編程語言排行榜，都從一個(gè)側(cè)面反映了SQL的廣泛用戶基礎(chǔ)。作為一個(gè)查詢語言，SQL是用戶和數(shù)據(jù)庫系統(tǒng)交互的(直接或間接)主要方式。支持一個(gè)擁有廣泛用戶基礎(chǔ)的查詢語言，對(duì)于推廣數(shù)據(jù)庫系統(tǒng)來說，是非常重要的。
2.2 用戶學(xué)習(xí)成本
最近幾年出現(xiàn)的幾個(gè)主要面向時(shí)序場(chǎng)景的數(shù)據(jù)庫，除了TimescaleDB是在Postgres基礎(chǔ)上所以支持PG生態(tài)包括SQL語言支持，其他幾個(gè)比如InfluxDB, OpenTSDB, Prometheus都有各自不同的查詢語言和接口：InfluxDB有InfluxQL，OpenTSDB有自己的Restful API, 而Prometheus有PromQL。每一個(gè)系統(tǒng)都可以聲稱自己的語言是獨(dú)一無二的，更適合時(shí)序查詢這樣的場(chǎng)景；但不可否認(rèn)的事實(shí)是用戶需要去花時(shí)間去學(xué)習(xí)一種新的語言，并且如果這個(gè)語言為了功能完善，還在不斷演進(jìn)中，這樣的學(xué)習(xí)成本對(duì)用戶來說，尤其顯得高了。
舉個(gè)例子，InfluxDB的InfluxQL并不支持Join，Subqueries, 以及SQL中很常見的UDF等功能，這意味著用戶并不能在不同數(shù)據(jù)之間進(jìn)行關(guān)聯(lián)分析計(jì)算，也不能在系統(tǒng)函數(shù)基礎(chǔ)上進(jìn)行擴(kuò)展開發(fā)。InfluxDB設(shè)計(jì)者在聽到社區(qū)的意見后，做了一個(gè)很有“創(chuàng)意”的事情：在新版本里支持Join，UDF等功能，但并不是讓InfluxQL變得更加接近于SQL，而是在一個(gè)全新的Flux(一個(gè)新的functional scripting language)里支持 [3]。用戶想要做InfluxQL不能做的事情，那就再來學(xué)習(xí)一個(gè)新語言吧。
一個(gè)很有意思的事情，10多年前開始出現(xiàn)的NoSQL系統(tǒng)，比如MapReduce/Hadoop, BigTable,Casandra，HBase等，一開始也是以各自不同的查詢語言出現(xiàn)的。在經(jīng)歷了多年用戶推廣之后，NoSQL開始擁抱SQL，變成了NotOnlySQL或者NewSQL。時(shí)序數(shù)據(jù)庫這樣一個(gè)新興的數(shù)據(jù)庫領(lǐng)域，也有可能重復(fù)這樣的歷史。原因很簡單，用戶學(xué)習(xí)一個(gè)新語言的成本越高，越會(huì)阻礙一個(gè)系統(tǒng)被推廣到大眾接受的程度。
2.3 BI工具生態(tài)支持
時(shí)序數(shù)據(jù)庫提供SQL的查詢支持，一個(gè)很重要的原因是將時(shí)序數(shù)據(jù)庫的應(yīng)用場(chǎng)景擴(kuò)展到商業(yè)分析(BI/Business Analysis)，商業(yè)決策這樣高附加值領(lǐng)域。
當(dāng)前幾個(gè)主要的時(shí)序數(shù)據(jù)庫，包括InfluxDB, OpenTSDB和Prometheus，主要側(cè)重于基礎(chǔ)性能監(jiān)控這樣的場(chǎng)景，利用Grafana這樣的可視化工具，實(shí)現(xiàn)監(jiān)控報(bào)警這一類基本功能。另一方面，監(jiān)控報(bào)警還沒有充分利用挖掘時(shí)序數(shù)據(jù)的商業(yè)價(jià)值。進(jìn)一步的功能，需要充分利用現(xiàn)有SQL生態(tài)系統(tǒng)中的商業(yè)分析工具，比如Tableau, Qlik，Oracle BI, IBM Cognos等。這些BI工具，往往是以SQL的方式同后端數(shù)據(jù)庫交互。從這個(gè)角度來說，時(shí)序數(shù)據(jù)庫的SQL支持對(duì)于對(duì)接BI生態(tài)系統(tǒng)中的各種工具，尤為重要。
2.4 TSQL面向的用戶群
在阿里時(shí)序數(shù)據(jù)庫TSDB支持的兼容OpenTSDB查詢協(xié)議之上推出的TSQL查詢引擎，主要是面向以下兩類用戶：
**- 時(shí)序數(shù)據(jù)庫TSDB的新應(yīng)用開發(fā)者?
**：這類用戶往往以前使用關(guān)系數(shù)據(jù)庫，因?yàn)殛P(guān)系數(shù)據(jù)庫本身處理時(shí)序數(shù)據(jù)的性能和可擴(kuò)展性的局限，而轉(zhuǎn)而使用TSDB。這些新應(yīng)用開發(fā)者，希望TSDB在提供比關(guān)系數(shù)據(jù)庫更好的時(shí)序性能和擴(kuò)展性的同時(shí)，能夠用他們以前熟悉的查詢語言進(jìn)行應(yīng)用開發(fā)，而不是去學(xué)習(xí)一個(gè)新的查詢語言。
**- 數(shù)據(jù)分析師：
**這類用戶并不開發(fā)應(yīng)用，他們的工作是利用已有的商業(yè)分析工具，對(duì)時(shí)序數(shù)據(jù)進(jìn)行進(jìn)一步的查詢分析。他們本身并不直接使用SQL， 但所使用的工具以SQL作為和時(shí)序數(shù)據(jù)庫TSDB交互的查詢語言。
3. 現(xiàn)有時(shí)序數(shù)據(jù)庫系統(tǒng)SQL查詢能力比較
這里簡單對(duì)比時(shí)序數(shù)據(jù)庫系統(tǒng)中提供SQL查詢，或SQL-like查詢能力的InfluxDB, TimescaleDB, 阿里云TSDB。
?
4. TSQL系統(tǒng)架構(gòu)
?
上圖是TSQL的總體架構(gòu)以及和TSDB引擎和存儲(chǔ)之間的協(xié)調(diào)工作關(guān)系。簡單來講，TSQL是一個(gè)典型的MPP的SQL分析引擎，通過Connector同TSDB引擎和存儲(chǔ)進(jìn)行數(shù)據(jù)交換。Connector支持MetaAPI和DataAPI。
TSQL是在兩個(gè)Apache開源項(xiàng)目基礎(chǔ)上演進(jìn)開發(fā)的：
- Apache Calcite作為SQL的解析器和計(jì)劃生成和優(yōu)化器。
- Apache Drill提供分布式的SQL執(zhí)行層。
Apache Calcite作為一個(gè)擴(kuò)展性好，支持標(biāo)準(zhǔn)SQL語法和語義的SQL計(jì)劃生成器，已經(jīng)被很多數(shù)據(jù)處理相關(guān)的開源項(xiàng)目使用[6]，包括大數(shù)據(jù)ETL的Apache Hive, HBase上的SQL解決方案Apache Phoenix, 也有流數(shù)據(jù)處理框架Apache Fink (阿里的Blink)和Apache Beam等。 TSQL使用Calcite作為SQL計(jì)劃生成器，可以在兼容標(biāo)準(zhǔn)SQL方面，充分利用開源社區(qū)已有的成果。
4.1 時(shí)序數(shù)據(jù)Schema管理
InfluxDB, OpenTSDB和Prometheus都采用的是一種Schema-on-write的方式，也就是用戶并不需要明確定義metric的schema, 而是將schema的信息隱藏在數(shù)據(jù)中，在數(shù)據(jù)寫入的時(shí)候，同時(shí)管理著schema。這樣做的好處是更高的靈活性：
- 在寫入數(shù)據(jù)的時(shí)候，用戶不需要事先必須用Create Table DDL來創(chuàng)建table；
- 在時(shí)序數(shù)據(jù)tag set出現(xiàn)變化的時(shí)候，用戶不需要事先用Alter Table來修改table的schema。
TimeScaleDB從PG上擴(kuò)展而來，所以是采用的是嚴(yán)格的Schema的管理方式。在使用靈活性方面，不如上面其他3個(gè)時(shí)序數(shù)據(jù)庫。
Calcite作為一個(gè)SQL計(jì)劃生成器，很適合時(shí)序數(shù)據(jù)庫這樣的比較松散的Schema管理方式。 Calcite的Schema Adapter，可以支持
TSQL在Calcite的Schema Adapter基礎(chǔ)上，利用TSDB引擎中新增加的MetaAPI，來完成SQL計(jì)劃解析和生成。這免去了用戶必須事先在一個(gè)集中式的catalog中預(yù)先定義Table DDL等繁瑣工作，給用戶帶來了很多的靈活性。
4.2 時(shí)序數(shù)據(jù)查詢執(zhí)行
TSQL的執(zhí)行層，利用了Apache Drill的runtime execution。Drill的runtime execution，具備以下特點(diǎn)
- 利用off-heap內(nèi)存作為計(jì)算內(nèi)存，減少Java heap內(nèi)存GC所帶來的延遲問題
- 基于Columnar格式的ValueVector (Apache Arrow的前身)，提升查詢執(zhí)行效率
- 動(dòng)態(tài)代碼生成和編譯
UDF支持
5. TSQL時(shí)序查詢功能
我們以一個(gè)基礎(chǔ)性能監(jiān)控場(chǎng)景來舉例說明TSQL能完成的時(shí)序查詢功能。利用一個(gè)時(shí)序數(shù)據(jù)庫業(yè)界公開的時(shí)序性能Benchmark[5] 生成的模擬數(shù)據(jù)，按照DevOps這樣的場(chǎng)景，產(chǎn)生了cpu相關(guān)的10不同的metric。每個(gè)metric對(duì)應(yīng)了機(jī)房(datecenter)，主機(jī)(hostname)，rack等標(biāo)簽下所采集的服務(wù)器cpu相關(guān)的指標(biāo)數(shù)據(jù)。
5.1 元數(shù)據(jù)查詢
可以用下面的方式查詢TSDB中所有的metric/table
SHOW TABLES FROM tsdb如果我們希望列出所有以cpu為前綴的metric/table，可以在上面的查詢基礎(chǔ)之上添加附帶過濾條件.
show TABLES from tsdb where TABLE_NAME like 'cpu%'下圖給出了命令的部分輸出:
?
在獲得metric/table 名字后，我們可以進(jìn)一步用SQL中的'DESCRIBE'命令來查詢這個(gè)metric/table的schema信息
describe tsdb.`cpu.usage_user`下圖顯示了上面的'describe'命令的部分結(jié)果：
?
5.2 時(shí)序數(shù)據(jù)簡單查詢
用下面的SQL查詢可以獲得指定時(shí)間段內(nèi)的'cpu.usage_user'的指標(biāo)值，時(shí)間戳，以及對(duì)應(yīng)的標(biāo)簽值。
select * from tsdb.`cpu.usage_user` where `timestamp` between '2019-05-01 16:00:00' and '2019-05-01 18:00:00'這里， 將被轉(zhuǎn)換成 metric/table下所有的列，包括指標(biāo)值，時(shí)間戳，所有的標(biāo)簽列。可以以具體的列名的一個(gè)列表來代替。
作為對(duì)比，如果把上面的查詢轉(zhuǎn)化成OpenTSDB協(xié)議來查詢，相對(duì)應(yīng)的查詢?nèi)缦?#xff1a;
可以在時(shí)間戳的過濾條件基礎(chǔ)上，增加指標(biāo)列上的條件。下面的查詢，列出指定時(shí)間段內(nèi)，3臺(tái)主機(jī)上的指標(biāo)值，并且使用limit, 把查詢結(jié)果限制在100行。
select * from tsdb.`cpu.usage_user` where `timestamp` between '2019-05-01 16:00:00' and '2019-05-01 18:00:00' and hostname in ('host_1', 'host_5', 'host_10') limit 100可以在查詢中使用標(biāo)準(zhǔn)SQL中豐富的數(shù)值計(jì)算函數(shù)，字符串函數(shù)或時(shí)間戳函數(shù)。下面的SQL，我們分別使用了數(shù)值運(yùn)算函數(shù)sqrt, 時(shí)間戳函數(shù)extract 和字符串lower。
5.3 時(shí)序降精度，聚合運(yùn)算
如果我們要計(jì)算兩小時(shí)之內(nèi)，每臺(tái)主機(jī)上每5分鐘的指標(biāo)cpu.usage_user的最大值，最小值，以及數(shù)據(jù)采樣點(diǎn)的個(gè)數(shù)。這樣的查詢，代表了在時(shí)間維度上的降精度，并且在標(biāo)簽hostname上進(jìn)行的聚合運(yùn)算。用TSQL來表示這樣的查詢：
selecthostname,tumble(`timestamp`, interval '5' minute) ts,max(`value`) maxV,min(`value`) minV,count(`value`) cntfrom tsdb.`cpu.usage_user`where `timestamp` between 1556726400000 and 1556733600000 and hostname in ('host_8','host_5','host_6') group by hostname, ts如果用OpenTSDB的協(xié)議來查詢:
{"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"}}] }可以看到，相比較原來Restful API的查詢，TSQL能夠用更簡潔的方式來表示相同的查詢語義；并且，如果用戶本來就熟悉SQL的使用方法，節(jié)省用戶去學(xué)習(xí)Restfule API里JSON各個(gè)字段的含義。從降低用戶學(xué)習(xí)成本，增加易用性這個(gè)角度，TSQL帶來了較明顯的價(jià)值。
TSQL不僅僅帶來查詢簡潔，用戶易用的優(yōu)點(diǎn)，并且，更重要的是，用TSQL能夠表達(dá)Restful API里不能直接表達(dá)的查詢語義。在TSDB引入TSQL之前，如果用戶需要進(jìn)行這樣的查詢計(jì)算，則用戶必須通過自己的應(yīng)用程序，在Restful API獲得數(shù)據(jù)后，再進(jìn)行后計(jì)算，來滿足業(yè)務(wù)需要。在自己的應(yīng)用程序中進(jìn)行后計(jì)算，往往需要付出很大的應(yīng)用開發(fā)代價(jià)。
5.4 聚合后計(jì)算，過濾，排序
下面的例子，計(jì)算2個(gè)小時(shí)內(nèi)，3臺(tái)機(jī)器上每5分鐘內(nèi)，cpu.usage_user指標(biāo)值的最大值和最小值的差異超過10.0的時(shí)段和hostname, 并按照差異值從大到小排序：
在上面的例子中個(gè)，在獲得最大值和最小值后，進(jìn)一步計(jì)算兩者的差異值，并根據(jù)差異值進(jìn)行過濾和排序。這樣的聚合后計(jì)算處理，無法用OpenTSDB的查詢協(xié)議表示；用戶如果要表達(dá)這樣的語義，就必須在應(yīng)用程序中計(jì)算。
5.5 任意復(fù)雜的條件表達(dá)式
TSDB的Restful API對(duì)于只提供有限的幾種filter, 而并不支持任意filter通過AND/OR的組合。比如下面的例子，是一個(gè)TSQL業(yè)務(wù)中使用的查詢。其中WHERE條件部分是并不能用Restful API來表示的，因?yàn)镽estful下的filters是只有AND, 而OR只有在相同tag上通過'value1|value2|vale3'這樣的形式來表達(dá)。
where((obj_id='ems30_NA62_183249003' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or(obj_id='ems30_NA62_183249746' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or(obj_id='ems30_NA62_183246962' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or(obj_id='ems30_NA62_183248143' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or(obj_id='ems30_NA62_183249191' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or(obj_id='ems30_NA62_183249964' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or(obj_id='ems30_NA62_183247148' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C')) and `timestamp` between '2019-04-25 18:20:21' and '2019-04-25 18:20:31'...支持任意組合的AND/OR的條件表達(dá)式，對(duì)于應(yīng)用開發(fā)是很有意義的。在集團(tuán)基礎(chǔ)監(jiān)控業(yè)務(wù)(raptor-pro)中，一個(gè)突出的亮點(diǎn)是“定制化監(jiān)控報(bào)警”：允許業(yè)務(wù)方的用戶來定制查詢條件，并且查詢條件可以是任意的AND/OR組合。TSQL為"定制化監(jiān)控報(bào)警"的功能實(shí)現(xiàn)，提供了有力的技術(shù)保障。
5.6 多個(gè)metric之間join
這個(gè)查詢，把cpu.usage_system和cpu.usage_idle在hostname和timestamp上做等值join, 然后計(jì)算每5分鐘兩個(gè)度量值之和的sum。
select t1.hostname, tumble(t1.`timestamp`, interval '5' minute ) ts, sum(t1.`value` + t2.`value`) as sumV from tsdb.`cpu.usage_system` t1, tsdb.`cpu.usage_idle` t2 where t1.`timestamp` >='2019-05-01' and t1.`timestamp` <= '2019-05-01 01:00:00' and t1.hostname = t2.hostnameand t1.`timestamp`= t2.`timestamp` group by t1.hostname, ts上面的查詢，如果我們采用TSDB的多值模型，把cpu.usage_system和cpu.usage_idle處理成一個(gè)metric的不同的field, 則不需要join就可以完成。但如果我們需要在分組聚合后的結(jié)果上再做join, 多值模型也無法解決問題。
5.7 分組聚合后join計(jì)算
下面的查詢，分別對(duì)cpu.usage_system和cpu.usage_idel按照5分鐘計(jì)算聚合函數(shù)sum(), 再通過join, 對(duì)齊，計(jì)算相對(duì)應(yīng)的比例。并且，每個(gè)子查詢的Where條件，除了包括在tag上和時(shí)間戳上的條件，還包括值上的過濾條件。
類似這樣的查詢，是無法直接在TSDB的RestAPI來實(shí)現(xiàn)的；用戶只能在自己的應(yīng)用程序中實(shí)現(xiàn)，增加了應(yīng)用開發(fā)成本。
5.8 UDF擴(kuò)展功能
使用UDF來擴(kuò)展功能，對(duì)于時(shí)序數(shù)據(jù)庫這樣聚焦特定領(lǐng)域的數(shù)據(jù)庫來說，是非常必要的，因?yàn)橥鵖QL標(biāo)準(zhǔn)中定義的函數(shù)，并不能完全滿足需要。TSQL有一個(gè)完善的UDF的體系，用戶只要按照約定的接口，用Java語義就可以實(shí)現(xiàn)擴(kuò)展。比如，我們?cè)赥SQL中引入的把時(shí)間戳分割成不重合的窗口的函數(shù)tumble，其實(shí)現(xiàn)就是由下面不到15行代碼完成。
用戶可以用Java實(shí)現(xiàn)不同的scalar UDF或者aggregate UDF, 并把編譯后的jar加入到TSQL的系統(tǒng)類庫目錄，就可以自行擴(kuò)展TSQL的查詢計(jì)算功能了。
6.TSQL可視化查詢
阿里云TSDB已經(jīng)提供了TSQL可視化交互式開發(fā)功能，通過web頁面可以方便的進(jìn)行TSQL的測(cè)試和開發(fā)，如下圖Demo所示。
原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的通过SQL即可让监控分析更简单更高效的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Apache Flink 结合 Kafk
- 下一篇： 使用Quick BI连接Analytic