百度智能云天工TSDB的SQL引擎正式對外開放

　　經(jīng)過二十多年的發(fā)展，伴隨著AI、大數(shù)據(jù)、云計算等技術(shù)的突飛猛進(jìn)，物聯(lián)網(wǎng)的價值逐漸凸顯，成為了互聯(lián)網(wǎng)和傳統(tǒng)公司爭相布局之地。而作為物聯(lián)網(wǎng)領(lǐng)域數(shù)據(jù)存儲的首選，時序數(shù)據(jù)庫也進(jìn)入人們的視野。

　　百度智能云在時序數(shù)據(jù)庫領(lǐng)域布局較早。早在2016年7月，百度智能云就在其天工物聯(lián)網(wǎng)平臺上發(fā)布了TSDB，這是國內(nèi)首個多租戶的分布式時序數(shù)據(jù)庫產(chǎn)品，能夠支持制造、交通、能源、智慧城市等多個產(chǎn)業(yè)領(lǐng)域。2018年5月，百度智能云天工平臺在TSDB上加持了SQL引擎，成為首個支持SQL的云上時序數(shù)據(jù)庫服務(wù)，至此用戶可以更加熟悉方便地對數(shù)據(jù)進(jìn)行操作，同時充分利用SQL函數(shù)的計算能力，挖掘數(shù)據(jù)價值。

　　本月，百度智能云天工TSDB的SQL引擎正式對外開放，所有套餐用戶均可使用SQL查詢功能。接下來，本文會從以下幾個方面帶你全方位的了解百度智能云天工TSDB上的SQL生態(tài)。

　　為什么TSDB需要SQL支持?

　　百度智能云天工TSDB一直有完整的API接口查詢支持，在此基礎(chǔ)上，現(xiàn)在又正式開放了SQL引擎，其中的原因有以下幾個方面：

　　首先，SQL的學(xué)習(xí)成本較低，對于技術(shù)人員而言，更符合日常使用習(xí)慣;即使是非技術(shù)人員，學(xué)習(xí)起來也很容易上手，可以省去熟悉API的學(xué)習(xí)成本。

　　其次，從可支持查詢的場景而言，因為API接口的格式相對固定，雖然可以支持絕大部分的查詢場景，但是相對來說，不如SQL可表達(dá)的語義豐富，一個典型的場景是TSDB中多個metric的聯(lián)合查詢，使用SQL中的join即可很方便的實現(xiàn)。

　　再者，SQL生態(tài)可以更方便的對接BI系統(tǒng)，通過SQL查詢功能，TSDB數(shù)據(jù)庫可以和現(xiàn)有的BI平臺實現(xiàn)無縫對接。

　　最后，無論是傳統(tǒng)的數(shù)據(jù)存儲服務(wù)或者計算框架，都有自己對應(yīng)的SQL生態(tài)，例如HiveSql，SparkSql。百度智能云天工TSDB作為專注于時序數(shù)據(jù)的存儲服務(wù)，也應(yīng)該有對應(yīng)的SQL生態(tài)。

　　TSDB SQL引擎能做什么?

　　TSDB支持標(biāo)準(zhǔn)ANSI SQL語義，查詢數(shù)據(jù)的體驗與傳統(tǒng)的SQL體驗一樣簡潔明了。用戶使用TSDB的SQL引擎，可以像API接口一樣訪問TSDB的時序數(shù)據(jù)，同時還可以利用SQL強(qiáng)大的計算函數(shù)能力。

　　讓我們先通過一個簡單的示例，來了解下如何在TSDB上使用SQL：

　　假設(shè)有一個智能電表監(jiān)控的物聯(lián)網(wǎng)集成方案，采集了智能電表的各個監(jiān)控點的數(shù)據(jù)。在TSDB中這樣組織(如下圖)，metric為SmartMeter，表示TSDB存的是智能電表的數(shù)據(jù)，每個電表有power和current兩個域(field)，用兩個tag，即meterID和city，來代表每個數(shù)據(jù)點來自哪個電表ID和城市。電表每5s上傳一次功率值和電流值。

　　可以將上表看成一個二維表，針對二維表來寫SQL語句。

　　做完這些基礎(chǔ)工作后，我們來看具體場景下如何應(yīng)用SQL語句來解決問題。

　　?應(yīng)用場景一：要過濾功率值大于400、電流值小于5，電表ID為2345HDYE的數(shù)據(jù)：

　　select timestamp, power, current,MeterID, City from SmartMeter where power > 400 and current<5 and MeterID= ' 2345HDYE'。

　　得到數(shù)據(jù)如下：

　　?應(yīng)用場景二：電表ID為2345HDYE的電表中，返回每10秒的功率平均值：

　　select time_bucket(timestamp, '10seconds') as TIME, avg(power) as AVG_POWER, current, City from SmartMeter groupby time_bucket(timestamp, '10 seconds') order by TIME;

　　得到數(shù)據(jù)如下：

　　從上面的示例可以看到，用戶可以像訪問RDS一樣使用SQL訪問TSDB，支持字段過濾，排序，分組，聚合等常用操作。同時因為時序數(shù)據(jù)的特性，還可以使用time_bucket來計算帶時間窗口的聚合函數(shù)。

　　除了以上示例中所提到的，TSDB SQL的查詢功能盡可能的和API查詢接口對齊，這樣用戶就可以在兩種查詢方式上靈活切換，具體包括：

　　? 所有類型的域的查詢：TSDB現(xiàn)在支持整型、浮點型、字符串類型和Bytes類型。

　　? 對于原始數(shù)據(jù)的掃描、支持filter、orderBy、limit等常用語義。

　　? 對于函數(shù)計算場景，支持SUM、AVG、COUNT等常用聚合函數(shù)，并支持按照tag、時間窗口等分組;同時支持包括floor、abs等常用的計算函數(shù)。

　　除了以上和API接口保持一致的功能之外，TSDB SQL還支持：多metric的join操作，可用于不同metric之間的聯(lián)合查詢。

　　TSDB SQL引擎性能優(yōu)化

　　數(shù)據(jù)查詢引擎的架構(gòu)一般分為存儲層和計算層，前者負(fù)責(zé)對接數(shù)據(jù)源和原始數(shù)據(jù)的讀取;后者負(fù)責(zé)生成查詢計劃并做優(yōu)化，以便更高效地從存儲層獲取數(shù)據(jù)。在這一部分，我們將介紹TSDB SQL引擎在計算層進(jìn)行的查詢優(yōu)化方面的工作。

　　計算層對查詢計劃的優(yōu)化主要分為：基于成本的優(yōu)化(Cost-Based Optimization)和基于規(guī)則的優(yōu)化(Rule-Based Optimization)。使用CBO時，計算層會在多個查詢計劃間挑選一個成本最低的查詢計劃執(zhí)行，在評估成本時可能需要用到存儲層提供的一些數(shù)據(jù)相關(guān)信息。而使用RBO更多的是使用一些規(guī)則，在對原始查詢計劃做等價變換的基礎(chǔ)上，不斷優(yōu)化出性能更優(yōu)的查詢計劃，其中比較常見的規(guī)則有謂詞下推，列裁剪等等，這里以謂詞下推為例作下簡要介紹。

　　謂詞下推(Predicate Pushdown)的思路是通過將SQL語句中WHERE 子句中的謂詞移到盡可能離數(shù)據(jù)源靠近的位置，從而能夠提早進(jìn)行數(shù)據(jù)過濾并有可能更好地利用索引。下面通過一個例子來說明：

　　繼續(xù)利用上一章節(jié)中的場景，假設(shè)我們除了SmartMeter這個metric之外，還有另外一個metric來記錄電表的溫度：

　　現(xiàn)在需要join這兩個metric來對特定的電表進(jìn)行聯(lián)合查詢，SQL語句如下：

　　select * from martMeter joinSmartTemperature on SmartMeter.MeterID = SmartTemperature.MeterID where MeterID= ' 2345HDYE';

　　針對上述的SQL語句，會生成如下左圖的原始查詢計劃：虛線以上可以認(rèn)為是計算層生成的查詢計劃，虛線以下對應(yīng)存儲層的數(shù)據(jù)源。這個查詢計劃使用TableScan算子將兩個metric的數(shù)據(jù)掃描出來，然后完成join操作，并在join之后的結(jié)果上做“MeterID= ' 2345HDYE”的條件過濾，最后輸出結(jié)果。

　　而右圖是經(jīng)過"謂詞下推"優(yōu)化之后的查詢計劃，可以看到，filter算子也就是“MeterID = ' 2345HDYE”的過濾，被下推到了TableScan算子下面，這樣的調(diào)整有什么好處呢?

　　首先，TableScan算子不再需要對原始數(shù)據(jù)進(jìn)行全表掃描，只需要獲取經(jīng)過“MeterID = ' 2345HDYE”過濾之后的數(shù)據(jù)，從數(shù)據(jù)量來說得到了縮減。

　　其次，如果SmartMeter和SmartTempreture作為數(shù)據(jù)源，本身就對MeterID這個字段的過濾有優(yōu)化的話，查詢性能就能得到進(jìn)一步的提升，這也就是上面提到的更好的利用數(shù)據(jù)源的索引。

　　最后，由于TableScan輸出的數(shù)據(jù)量減少了，需要join的數(shù)據(jù)量也就減少了。

　　可以看到，謂詞下推是通過盡可能移動過濾表達(dá)式至靠近數(shù)據(jù)源的位置，來減少算子之間需要傳遞的數(shù)據(jù)量，進(jìn)而優(yōu)化查詢計劃。TSDBSQL現(xiàn)已支持timestamp，field以及tag上絕大部分的謂詞下推，并且實現(xiàn)了OrderBy，Limit下推等一系列優(yōu)化規(guī)則;同時在一些聚合函數(shù)場景下，SQL支持通過分布式計算來優(yōu)化查詢計劃的執(zhí)行，這里暫不一一展開。

　　相信通過本文的介紹，大家已經(jīng)對使用SQL引擎訪問百度智能云天工TSDB有了一定的了解。目前，百度智能云團(tuán)隊仍在不斷完善TSDB上的SQL生態(tài)，比如通過JDBC/ODBC來連接TSDB等。未來，SQL生態(tài)將延伸到天工的其他產(chǎn)品上，比如物管理服務(wù)等，從而實現(xiàn)天工產(chǎn)品的多數(shù)據(jù)源一站式SQL查詢。