天工TSDB又添利器，SQL挖掘更多數據價值

本文做者：天工智能物聯網

通過二十多年的發展，伴隨着AI、大數據、雲計算等技術的日新月異，物聯網的價值逐漸凸顯，成爲了互聯網和傳統公司爭相佈局之地。而做爲物聯網領域數據存儲的首選，時序數據庫也進入人們的視野。

 

百度智能雲在時序數據庫領域佈局較早。早在2016年7月，百度智能雲就在其天工物聯網平臺上發佈了TSDB，這是國內首個多租戶的分佈式時序數據庫產品，可以支持製造、交通、能源、智慧城市等多個產業領域。2018年5月，百度智能雲天工平臺在TSDB上加持了SQL引擎，成爲首個支持SQL的雲上時序數據庫服務，至此用戶能夠更加熟悉方便地對數據進行操做，同時充分利用SQL函數的計算能力，挖掘數據價值。

 

本月，百度智能雲天工TSDB的SQL引擎正式對外開放，全部套餐用戶都可使用SQL查詢功能。接下來，本文會從如下幾個方面帶你全方位的瞭解百度智能雲天工TSDB上的SQL生態。

 

爲何TSDB須要SQL支持？

 

百度智能雲天工TSDB一直有完整的API接口查詢支持，在此基礎上，如今又正式開放了SQL引擎，其中的緣由有如下幾個方面：

 

首先，SQL的學習成本較低，對於技術人員而言，更符合平常使用習慣；即便是非技術人員，學習起來也很容易上手，能夠省去熟悉API的學習成本。

 

其次，從可支持查詢的場景而言，由於API接口的格式相對固定，雖然能夠支持絕大部分的查詢場景，可是相對來講，不如SQL可表達的語義豐富，一個典型的場景是TSDB中多個metric的聯合查詢，使用SQL中的join便可很方便的實現。

 

再者，SQL生態能夠更方便的對接BI系統，經過SQL查詢功能，TSDB數據庫能夠和現有的BI平臺實現無縫對接。

 

最後，不管是傳統的數據存儲服務或者計算框架，都有本身對應的SQL生態，例如HiveSql，SparkSql。百度智能雲天工TSDB做爲專一於時序數據的存儲服務，也應該有對應的SQL生態。

 

TSDB SQL引擎能作什麼？

 

TSDB支持標準ANSI SQL語義，查詢數據的體驗與傳統的SQL體驗同樣簡潔明瞭。用戶使用TSDB的SQL引擎，能夠像API接口同樣訪問TSDB的時序數據，同時還能夠利用SQL強大的計算函數能力。

 

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

 

假設有一個智能電錶監控的物聯網集成方案，採集了智能電錶的各個監控點的數據。在TSDB中這樣組織（以下圖），metric爲SmartMeter，表示TSDB存的是智能電錶的數據，每一個電錶有power和current兩個域（field），用兩個tag，即meterID和city，來表明每一個數據點來自哪一個電錶ID和城市。電錶每5s上傳一次功率值和電流值。

 

 

能夠將上表當作一個二維表，針對二維表來寫SQL語句。

 

 

作完這些基礎工做後，咱們來看具體場景下如何應用SQL語句來解決問題。

 

➤ 應用場景一：要過濾功率值大於400、電流值小於5，電錶ID爲2345HDYE的數據：

 

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

 

獲得數據以下：

 

 

➤ 應用場景二：電錶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;

 

獲得數據以下：

 

 

從上面的示例能夠看到，用戶能夠像訪問RDS同樣使用SQL訪問TSDB，支持字段過濾，排序，分組，聚合等經常使用操做。同時由於時序數據的特性，還可使用time_bucket來計算帶時間窗口的聚合函數。

 

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

 

▷  全部類型的域的查詢：TSDB如今支持整型、浮點型、字符串類型和Bytes類型。

 

▷  對於原始數據的掃描、支持filter、orderBy、limit等經常使用語義。

 

▷  對於函數計算場景，支持SUM、AVG、COUNT等經常使用聚合函數，並支持按照tag、時間窗口等分組；同時支持包括floor、abs等經常使用的計算函數。

 

除了以上和API接口保持一致的功能以外，TSDB SQL還支持：多metric的join操做，可用於不一樣metric之間的聯合查詢。

 

TSDB SQL引擎性能優化

 

數據查詢引擎的架構通常分爲存儲層和計算層，前者負責對接數據源和原始數據的讀取；後者負責生成查詢計劃並作優化，以便更高效地從存儲層獲取數據。在這一部分，咱們將介紹TSDB SQL引擎在計算層進行的查詢優化方面的工做。

 

計算層對查詢計劃的優化主要分爲：基於成本的優化（Cost-Based Optimization）和基於規則的優化（Rule-Based Optimization）。使用CBO時，計算層會在多個查詢計劃間挑選一個成本最低的查詢計劃執行，在評估成本時可能須要用到存儲層提供的一些數據相關信息。而使用RBO更多的是使用一些規則，在對原始查詢計劃作等價變換的基礎上，不斷優化出性能更優的查詢計劃，其中比較常見的規則有謂詞下推，列裁剪等等，這裏以謂詞下推爲例做下簡要介紹。

 

謂詞下推（Predicate Pushdown）的思路是經過將SQL語句中WHERE 子句中的謂詞移到儘量離數據源靠近的位置，從而可以提前進行數據過濾並有可能更好地利用索引。下面經過一個例子來講明：

 

繼續利用上一章節中的場景，假設咱們除了SmartMeter這個metric以外，還有另一個metric來記錄電錶的溫度：

 

如今須要join這兩個metric來對特定的電錶進行聯合查詢，SQL語句以下：

 

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

 

針對上述的SQL語句，會生成以下左圖的原始查詢計劃：虛線以上能夠認爲是計算層生成的查詢計劃，虛線如下對應存儲層的數據源。這個查詢計劃使用TableScan算子將兩個metric的數據掃描出來，而後完成join操做，並在join以後的結果上作「MeterID= ' 2345HDYE」的條件過濾，最後輸出結果。

 

 

而右圖是通過"謂詞下推"優化以後的查詢計劃，能夠看到，filter算子也就是「MeterID = ' 2345HDYE」的過濾，被下推到了TableScan算子下面，這樣的調整有什麼好處呢？

 

首先，TableScan算子再也不須要對原始數據進行全表掃描，只須要獲取通過「MeterID = ' 2345HDYE」過濾以後的數據，從數據量來講獲得了縮減。

 

其次，若是SmartMeter和SmartTempreture做爲數據源，自己就對MeterID這個字段的過濾有優化的話，查詢性能就能獲得進一步的提高，這也就是上面提到的更好的利用數據源的索引。

 

最後，因爲TableScan輸出的數據量減小了，須要join的數據量也就減小了。

 

能夠看到，謂詞下推是經過儘量移動過濾表達式至靠近數據源的位置，來減小算子之間須要傳遞的數據量，進而優化查詢計劃。TSDBSQL現已支持timestamp，field以及tag上絕大部分的謂詞下推，而且實現了OrderBy，Limit下推等一系列優化規則；同時在一些聚合函數場景下，SQL支持經過分佈式計算來優化查詢計劃的執行，這裏暫不一一展開。

 

相信經過本文的介紹，你們已經對使用SQL引擎訪問百度智能雲天工TSDB有了必定的瞭解。目前，百度智能雲團隊仍在不斷完善TSDB上的SQL生態，好比經過JDBC/ODBC來鏈接TSDB等。將來，SQL生態將延伸到天工的其餘產品上，好比物管理服務等，從而實現天工產品的多數據源一站式SQL查詢。

原文連接地址：https://developer.baidu.com/topic/show/290141