為了簡化UI工作并為運維人員提供一種更加靈活的資源查詢方式，ZStack在2.6版本中推出了***面向IaaS的查詢語言 —— ZStack Query Language，簡稱ZQL。

[[240169]]

背景

IaaS管理著海量的數(shù)據(jù)中心資源，如何對這些資源進行靈活快速的查詢是運維人員面臨的一個難題。在以往的IaaS軟件中，往往只對單個資源的某些字段提供有限的API查詢支持，例如可以通過虛擬機的IP字段查詢，這不足夠也不靈活。運維人員在做復雜查詢時往往得繞開IaaS軟件直接查詢其后端數(shù)據(jù)庫，這既要求運維人員要了解IaaS資源的內部關系，又帶來了數(shù)據(jù)庫誤操作的風險。

從ZStack正式發(fā)布的***個版本ZStack0.6開始，我們就致力在API層面提供跟數(shù)據(jù)庫級別的查詢功能，ZStack的每個資源都包含一個Query API，能夠通過資源的自身字段以及資源的關聯(lián)資源字段進行查詢。例如：

QueryVmInstance name~=web-vm state=Running

這里查詢所有名字包含web-vm字符串，正在運行中的VM。又例如：

QueryVmInstance vmNics.eip.vip.ip='22.22.22.22'

EIP是虛擬機的關聯(lián)資源，這里查詢網(wǎng)卡綁定了EIP為22.22.22.22的虛擬機。

Query API功能強大：

用戶可以通過count參數(shù)返回滿足查詢條件資源數(shù)量，類似SQL的select count(*);

通過fields參數(shù)指定要返回的字段，類似SQL的select uuid,name from;

通過sortBy、sortDirection參數(shù)指定排序的字段和方向，類似SQL的order by;

通過start、limit參數(shù)實現(xiàn)分頁查詢，類似SQL的limit和offset。

Query API除了使用方便外，定義也很簡單。程序員在ZStack中增加了一種新資源后，只需要在代碼中定義如下class:

@AutoQuery(replyClass = APIQueryVmInstanceReply.class, inventoryClass = VmInstanceInventory.class)

public class APIQueryVmInstanceMsg extends APIQueryMessage {

}

不需要寫任何實現(xiàn)，對應資源就具有了Query API。

ZStack內部包含一個Query Service負責處理所有資源的Query API，將他們翻譯成相應的SQL語句，在查詢條件中包含關聯(lián)資源條件時會生成對應的Join子句。

基于Query API， ZStack0.6版本就包含了超過400萬個單項查詢條件，組合查詢條件數(shù)為400萬的階乘。極大的方便了運維和復雜UI的設計。但Query API仍然包含一些缺陷：

Ø 查詢條件之間只能是AND邏輯，無法執(zhí)行OR邏輯，條件之間也無法加括號實現(xiàn)復雜邏輯組合

Ø 不支持類似SQL中的sub query子句

Ø 單個API只能查詢一種資源，查詢多種資源時需要調用多個API

Ø 不支持跟監(jiān)控系統(tǒng)的查詢語言整合

隨著ZStack UI的場景越來越豐富，Query API的限制使得UI端的工作越來越多，很多場景需要多次調用Query API進行數(shù)據(jù)組合。例如在監(jiān)控Top 5頁面(用于檢測系統(tǒng)中CPU、內存、磁盤、網(wǎng)絡等資源使用率***5個資源的頁面)，需要先采用Query API將虛擬機、物理機等資源信息查詢回來，再調用監(jiān)控系統(tǒng)ZWatch的API查詢對應的監(jiān)控數(shù)據(jù)。

Query API在未來的ZStack版本中會一直保留并維護，其后端實現(xiàn)已經(jīng)從原來的Query Service替換成ZQL

ZStack Query Language

使用過著名issue管理系統(tǒng)JIRA的開發(fā)者都知道JIRA在進行高級搜索的時候提供一種查詢語言JQL (JIRA Query Language)，能夠使用一種類似SQL的DSL(Domain Specific Language)對JIRA中ticket的各個字段進行高效的查詢。ZQL跟JQL類似，也是一種類似SQL的DSL，先來看一個例子：

query vminstance where name='webvm' or vmnics.ip='192.168.0.10' or (vmnics.eip = '172.20.100.100' and (cpuNum >= 8 or clusterUuid in ('fe13b725c80e45709f0414c266a80239','73ca1ca7603d454f8fa7f3bb57097f80')))

在這個簡單例子中，可以看到很多熟悉的SQL元素，例如and/or條件、括號、>=/in操作符等。ZQL可以看作SQL的一個子集外加ZStack根據(jù)自身需求進行的增強的查詢語言。它的基本結構如下：

QUERY queryTarget (WHERE condition+)? restrictBy? returnWith? groupBy? orderBy? limit? offset? filterBy? namedAs?

query關鍵詞

一條ZQL語句通常以query關鍵字開頭，queryTarget表示要查詢的資源或資源字段的集合。前面的例子中vminstance代表虛擬機，例如host代表物理機、zone代表區(qū)域，所有可被查詢的資源都有自己的名稱。如果不希望返回資源的所有字段，只希望獲得資源的一個或多個字段，實現(xiàn)類似SQL的select uuid,name from ...的功能，可以在資源名后指定字段名，多個字段名用逗號隔離，例如：

query vminstance.uuid,name,cpuNum

該查詢返回所有虛擬機的UUID、名稱以及CPU數(shù)量。

除了query關鍵字，查詢也能以count和sum關鍵字開頭，前者返回滿足查詢條件資源的總數(shù)，后者可以對資源的某個字段進行求和。例如：

count vminstance where cpuNum > 8

返回系統(tǒng)中CPU數(shù)量超過8核的虛擬機的總數(shù)。

sum vminstance.memorySize by name where cpuNum > 8

用虛擬機名字對CPU核數(shù)超過8個的虛擬機進行分組，對它們的memorySize字段進行求和。如果系統(tǒng)中有兩個10CPU8G的虛擬機都名為webvm，則求和后返回webvm虛擬機總內存使用數(shù)為16G。翻譯成SQL則為：

select sum(memorySize) from vminstance where cpuNum > 8 group by name

WHERE從句

ZQL的WHERE從句跟SQL的WHERE從句類似，支持and/or邏輯操作符、括號組合，條件的比較符支持=，!=，>，>=，<, <=, like, not like, is null, is not null, in, not in，查詢條件名為資源的字段名。跟SQL不一樣的地方在于，ZQL的查詢條件可以是關聯(lián)資源的字段，例如：

query vminstance where vmNics.eip.vip.ip='22.22.22.22'

注意where從句前無需寫類似SQL的from xx從句，因為query vminstance已經(jīng)限定了被查詢的資源

這里vip跟eip關聯(lián)，eip跟vmnic關聯(lián)，vmnic又跟vminstance關聯(lián)，則我們可以指定vip的IP作為查詢條件。這正是ZQL的強大之處，對于多個關聯(lián)資源的查詢，無需調用多次API在應用端組合數(shù)據(jù)，也無需像SQL一樣寫復雜的join從句，只需要像編程一樣通過點號(.)引用另一個資源即可， ZQL的翻譯器會自動將跨資源引用翻譯成對應的SQL join從句。

WHERE從句可以包含子查詢，類似于SQL的sub query功能，例如：

query vminstance where vmNics.l3NetworkUuid in (query l3network.uuid where ipRanges.networkCidr='10.1.0.0/24')

這里找出所有CIRD為10.1.0.0/24的三層網(wǎng)絡上運行的虛擬機。

上面這個例子也可以用更簡單的方法實現(xiàn)：query vminstance where vmNics.l3network.ipRanges.networkCidr='10.1.0.0/24'，這里只是為了演示子查詢功能

GROUP BY、ORDER BY、LIMIT、OFFSET 子句

跟SQL一樣，ZQL支持GROUP BY、ORDER BY、LIMIT、OFFSET關鍵字，以實現(xiàn)分組、排序、分頁等功能。

GROUP BY：

通過虛擬機的區(qū)域UUID和集群UUID分組，統(tǒng)計各區(qū)域中各集群中虛擬機的數(shù)量。

count vminstance group by zoneUuid,clusterUuid

ORDER BY：

查詢所有虛擬機，使用cpuNum字段降序排序。

1. query vminstance order by cpuNum desc

LIMIT、OFFSET：

使用limit和offset實現(xiàn)分頁：

query vminstance limit 100 offset 10

多資源查詢

對于多個資源的查詢，可以通過多條query查詢語句實現(xiàn)，語句之間使用分號分隔，例如：

query vminstance where name = 'my-vm';

query host where cpuNum > 10;

query zone;

則一次調用即可返回三種資源的查詢結果。由于返回的結果是一個map的JSON結構，為了方便獲得對應語句的查詢結果，可以使用named as關鍵字對查詢語句命名，例如：

query vminstance where name = 'my-vm' named as 'vm';

query host where cpuNum > 10 named as 'host';

query zone named as 'zone';

則在返回的JSON map中，可以通過vm、host、zone作為key獲得對應語句的查詢結果。

合并監(jiān)控查詢 (return with從句)

在ZStack中使用了兩種數(shù)據(jù)庫：關系數(shù)據(jù)庫存放元數(shù)據(jù)，時序數(shù)據(jù)庫存放監(jiān)控數(shù)據(jù)。由于不同數(shù)據(jù)庫查詢方式不一樣，在ZQL之前，用戶要查詢一個資源的監(jiān)控數(shù)據(jù)，需要先通過Query API獲得該資源的元數(shù)據(jù)，再通過ZWatch的查詢API獲得其監(jiān)控數(shù)據(jù)。例如要查詢一個名為webvm虛擬機的CPU使用率監(jiān)控數(shù)據(jù)，要執(zhí)行如下API：

QueryVmInstance fields=uuid name=webvm

GetMetricData namespace=ZStack/VM metricName=CPUUsedUtilization labels=VMUuid=QueryVmInstance返回的UUID offsetAheadOfCurrentTime=60

ZQL通過return with子句解決這個問題。return with是一種插件機制，它允許子系統(tǒng) 通過插件將自身的查詢條件注入ZQL中，ZQL會先執(zhí)行關系數(shù)據(jù)庫查詢，將滿足條件資源的原數(shù)據(jù)查詢出來后，再將資源的主鍵(primary key)作為輸入條件調用實現(xiàn)return with子句的插件，***將插件的查詢結果一并返回給ZQL的調用者。

上述查詢虛擬機監(jiān)控數(shù)據(jù)的需求可以通過一條ZQL語句實現(xiàn)：

query vminstance.hostUuid,uuid where name = 'webvm' return with (zwatch{resultName='webvm-cpu',metricName='CPUAllUsedUtilization',offsetAheadOfCurrentTime=60})

返回：

{

"results": [

{

"inventories": [

{

"hostUuid": "f8271f58468b4281a212a43e530b5535",

"uuid": "05781209d24341ac84fc055ae71820ac"

}

],

"returnWith": {

"webvm-cpu": [

{

"labels": {

"VMUuid": "05781209d24341ac84fc055ae71820ac"

},

"time": 1533280402,

"value": 0.8

},

{

"labels": {

"VMUuid": "05781209d24341ac84fc055ae71820ac"

},

"time": 1533280462,

"value": 0.8

}

]

}

}

],

"success": true

}

這里我們用一條ZQL語句中即返回了我們感興趣的元數(shù)據(jù)字段：uuid和hostUuid，也返回了該虛擬機的監(jiān)控數(shù)據(jù)。細心的讀者已經(jīng)注意到我們在ZWatch查詢字段中指定了參數(shù)resultName='webvm-cpu'，并且在返回的JSON map中監(jiān)控數(shù)據(jù)的key也是webvm-cpu。跟named as關鍵字一樣，這是為了執(zhí)行多條ZWatch查詢子句時方便檢索返回結果準備的。 ZStack UI使用非常復雜的ZQL查詢語句，例如在TOP 5頁面，一條ZQL查詢包含多達13個ZWatch查詢：

ZQLQuery zql="query vmInstance.uuid,name where zoneUuid='89e148fb667c404dbc5309a2e956fa28' and hypervisorType='KVM' and type='UserVm' and state='Running' return with (zwatch{resultName='CPUAllUsedUtilization',metricName='CPUAllUsedUtilization',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='MemoryUsedInPercent',metricName='MemoryUsedInPercent',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='MemoryFreeInPercent',metricName='MemoryFreeInPercent',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='DiskAllReadOps',metricName='DiskAllReadOps',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='DiskAllWriteOps',metricName='DiskAllWriteOps',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='DiskAllReadBytes',metricName='DiskAllReadBytes',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='DiskAllWriteBytes',metricName='DiskAllWriteBytes',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='NetworkOutBytes',metricName='NetworkOutBytes',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'},zwatch{resultName='NetworkInBytes',metricName='NetworkInBytes',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'},zwatch{resultName='NetworkOutPackets',metricName='NetworkOutPackets',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'},zwatch{resultName='NetworkInPackets',metricName='NetworkInPackets',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'},zwatch{resultName='NetworkOutErrors',metricName='NetworkOutErrors',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'},zwatch{resultName='NetworkInErrors',metricName='NetworkInErrors',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'})"

上例是在ZStack CLI中執(zhí)行時的例子，使用\對引號轉義

當資源特別多時，時序數(shù)據(jù)庫查詢性能可能成為多條ZWatch查詢的性能瓶頸，故return with會通過并發(fā)的方式執(zhí)行插件，默認并發(fā)度為10。例如上述例子中的13條ZWatch查詢會在10個線程中并發(fā)執(zhí)行。用戶可以通過全局配置zql.returnWith.concurrency更改并發(fā)度，例如

UpdateGlobalConfig category=query name=zql.returnWith.concurrency value=15

限制查詢 (restrict by從句)

ZStack的企業(yè)管理模塊包含一個功能，可以對管理綁定某個區(qū)域，使得該管理員只能管理該區(qū)域內的資源，這就要求我們的ZQL對該管理員的查詢請求只返回與其綁定區(qū)區(qū)中的資源。

對于虛擬機這樣的資源，其元數(shù)據(jù)本身就帶zoneUuid字段用于標識所在區(qū)域。但對于eip這樣的資源，其元數(shù)據(jù)并無任何字段表示區(qū)域屬性，區(qū)域屬性是由其所在的三層網(wǎng)絡或綁定的虛擬機確定的。例如要查詢某個區(qū)域內的eip，可以使用：

# 通過與虛擬機的綁定關系查詢

query eip where vmNic.vmInstance.zoneUuid = '52fdad0a2c0d4131a6c0fc6c1b7141a6'

或

# 通過所在三層網(wǎng)絡確定

query eip where vip.l3Network.zoneUuid = '52fdad0a2c0d4131a6c0fc6c1b7141a6'

無論那種方式，都需要調用者了解知道eip跟zone之間的關聯(lián)關系，這對API的使用者提出了非?？量痰囊?。ZQL通過restrict by從句解決這個問題。跟return with從句類似，restrict by也是個插件框架，它允許其它服務通過插件解讀restrict by從句中指定的條件，向生成的SQL中注入額外條件。例如上面的eip例子通過restrict by從句可以寫成：

query eip restrict by (zone.uuid='52fdad0a2c0d4131a6c0fc6c1b7141a6')

這里調用者無需知道eip跟zone之間的邏輯關系，restrict by的路徑插件會自動計算兩者的邏輯關系，并生成對應的SQL join從句。這里eip既可以通過所在三層網(wǎng)絡，也可以通過綁定的虛擬機確定和區(qū)域的關系，插件會自動計算路徑權重，使用權重***的路徑生成SQL語句。

對于eip這個例子，插件會選取通過三層網(wǎng)絡的關系生成SQL語句。因為eip可能沒有跟虛擬機綁定，但其一定處于某個三層網(wǎng)絡，故三層網(wǎng)絡這條路徑的權重更高。

restrict by支持多個條件，通過逗號分隔，多個條件之間是AND關系。

除了給ZQL調用者使用外，restrict by插件在ZStack內部也被其它服務廣泛使用。例如賬號系統(tǒng)會通過插件在普通賬戶調用ZQL的時候注入跟賬號關聯(lián)的SQL語句，使得普通賬號只能查詢到屬于該賬號的資源;又例如SNS服務會通過插件注入語句讓ZQL只能查詢到非系統(tǒng)類型的接收端。

未來

ZQL為ZStack提供了一種類似SQL的IaaS查詢語言，并且能夠通過return with插件框架跟其它非關系數(shù)據(jù)庫系統(tǒng)進行查詢整合。在未來的版本中我們還會繼續(xù)豐富其功能，目前有兩個方向：

filter by從句

雖然return with的ZWatch插件能讓我們在查詢資源元數(shù)據(jù)的同時查詢其監(jiān)控數(shù)據(jù)，但還不能將監(jiān)控數(shù)據(jù)作為元數(shù)據(jù)的查詢條件，例如無法通過一條ZQL實現(xiàn)查詢某個集群中所有CPU使用率超過90%的虛擬機。這在未來版本中會通過filter by從句實現(xiàn)，例如：

query vminstance where clusterUuid = '33e26bd547d149fbb190436cc9aca824' filter by (zwatch{metricName='CPUAllUsedUtilization', offsetAheadOfCurrentTime=60, threshold>90})

同樣，filter by從句會實現(xiàn)成類似return with的插件框架，用于整合非關系數(shù)據(jù)庫的查詢條件。

智能CLI 

ZQL有大量的從句，每個ZStack又有大量的可查詢字段，目前ZStack CLI可以對Query API的可查詢字段進行補全，但ZQL還暫時無法補全。未來版本中，我們會對CLI進行在增強，使其對所有查詢條件可以進行提示和補全。