揭密首個面向IaaS的查詢語言：ZStack Query Language（ZQL）
為了簡化UI工作并為運維人員提供一種更加靈活的資源查詢方式，ZStack在2.6版本中推出了***面向IaaS的查詢語言 —— ZStack Query Language，簡稱ZQL。
背景
IaaS管理著海量的數據中心資源，如何對這些資源進行靈活快速的查詢是運維人員面臨的一個難題。在以往的IaaS軟件中，往往只對單個資源的某些字段提供有限的API查詢支持，例如可以通過虛擬機的IP字段查詢，這不足夠也不靈活。運維人員在做復雜查詢時往往得繞開IaaS軟件直接查詢其后端數據庫，這既要求運維人員要了解IaaS資源的內部關系，又帶來了數據庫誤操作的風險。
從ZStack正式發布的***個版本ZStack0.6開始，我們就致力在API層面提供跟數據庫級別的查詢功能，ZStack的每個資源都包含一個Query API，能夠通過資源的自身字段以及資源的關聯資源字段進行查詢。例如：
QueryVmInstance name~=web-vm state=Running
這里查詢所有名字包含web-vm字符串，正在運行中的VM。又例如：
QueryVmInstance vmNics.eip.vip.ip='22.22.22.22'
EIP是虛擬機的關聯資源，這里查詢網卡綁定了EIP為22.22.22.22的虛擬機。
Query API功能強大：
用戶可以通過count參數返回滿足查詢條件資源數量，類似SQL的select count(*);
通過fields參數指定要返回的字段，類似SQL的select uuid,name from;
通過sortBy、sortDirection參數指定排序的字段和方向，類似SQL的order by;
通過start、limit參數實現分頁查詢，類似SQL的limit和offset。
Query API除了使用方便外，定義也很簡單。程序員在ZStack中增加了一種新資源后，只需要在代碼中定義如下class:
@AutoQuery(replyClass = APIQueryVmInstanceReply.class, inventoryClass = VmInstanceInventory.class)
public class APIQueryVmInstanceMsg extends APIQueryMessage {
}
不需要寫任何實現，對應資源就具有了Query API。
ZStack內部包含一個Query Service負責處理所有資源的Query API，將他們翻譯成相應的SQL語句，在查詢條件中包含關聯資源條件時會生成對應的Join子句。
基于Query API， ZStack0.6版本就包含了超過400萬個單項查詢條件，組合查詢條件數為400萬的階乘。極大的方便了運維和復雜UI的設計。但Query API仍然包含一些缺陷：
Ø 查詢條件之間只能是AND邏輯，無法執行OR邏輯，條件之間也無法加括號實現復雜邏輯組合
Ø 不支持類似SQL中的sub query子句
Ø 單個API只能查詢一種資源，查詢多種資源時需要調用多個API
Ø 不支持跟監控系統的查詢語言整合
隨著ZStack UI的場景越來越豐富，Query API的限制使得UI端的工作越來越多，很多場景需要多次調用Query API進行數據組合。例如在監控Top 5頁面(用于檢測系統中CPU、內存、磁盤、網絡等資源使用率***5個資源的頁面)，需要先采用Query API將虛擬機、物理機等資源信息查詢回來，再調用監控系統ZWatch的API查詢對應的監控數據。
Query API在未來的ZStack版本中會一直保留并維護，其后端實現已經從原來的Query Service替換成ZQL
ZStack Query Language
使用過著名issue管理系統JIRA的開發者都知道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根據自身需求進行的增強的查詢語言。它的基本結構如下：
QUERY queryTarget (WHERE condition+)? restrictBy? returnWith? groupBy? orderBy? limit? offset? filterBy? namedAs?
query關鍵詞
一條ZQL語句通常以query關鍵字開頭，queryTarget表示要查詢的資源或資源字段的集合。前面的例子中vminstance代表虛擬機，例如host代表物理機、zone代表區域，所有可被查詢的資源都有自己的名稱。如果不希望返回資源的所有字段，只希望獲得資源的一個或多個字段，實現類似SQL的select uuid,name from ...的功能，可以在資源名后指定字段名，多個字段名用逗號隔離，例如：
query vminstance.uuid,name,cpuNum
該查詢返回所有虛擬機的UUID、名稱以及CPU數量。
除了query關鍵字，查詢也能以count和sum關鍵字開頭，前者返回滿足查詢條件資源的總數，后者可以對資源的某個字段進行求和。例如：
count vminstance where cpuNum > 8
返回系統中CPU數量超過8核的虛擬機的總數。
sum vminstance.memorySize by name where cpuNum > 8
用虛擬機名字對CPU核數超過8個的虛擬機進行分組，對它們的memorySize字段進行求和。如果系統中有兩個10CPU8G的虛擬機都名為webvm，則求和后返回webvm虛擬機總內存使用數為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的查詢條件可以是關聯資源的字段，例如：
query vminstance where vmNics.eip.vip.ip='22.22.22.22'
注意where從句前無需寫類似SQL的from xx從句，因為query vminstance已經限定了被查詢的資源
這里vip跟eip關聯，eip跟vmnic關聯，vmnic又跟vminstance關聯，則我們可以指定vip的IP作為查詢條件。這正是ZQL的強大之處，對于多個關聯資源的查詢，無需調用多次API在應用端組合數據，也無需像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的三層網絡上運行的虛擬機。
上面這個例子也可以用更簡單的方法實現：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關鍵字，以實現分組、排序、分頁等功能。
GROUP BY：
通過虛擬機的區域UUID和集群UUID分組，統計各區域中各集群中虛擬機的數量。
count vminstance group by zoneUuid,clusterUuid
ORDER BY：
查詢所有虛擬機，使用cpuNum字段降序排序。
1. query vminstance order by cpuNum desc
LIMIT、OFFSET：
使用limit和offset實現分頁：
query vminstance limit 100 offset 10
多資源查詢
對于多個資源的查詢，可以通過多條query查詢語句實現，語句之間使用分號分隔，例如：
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獲得對應語句的查詢結果。
合并監控查詢 (return with從句)
在ZStack中使用了兩種數據庫：關系數據庫存放元數據，時序數據庫存放監控數據。由于不同數據庫查詢方式不一樣，在ZQL之前，用戶要查詢一個資源的監控數據，需要先通過Query API獲得該資源的元數據，再通過ZWatch的查詢API獲得其監控數據。例如要查詢一個名為webvm虛擬機的CPU使用率監控數據，要執行如下API：
QueryVmInstance fields=uuid name=webvm
GetMetricData namespace=ZStack/VM metricName=CPUUsedUtilization labels=VMUuid=QueryVmInstance返回的UUID offsetAheadOfCurrentTime=60
ZQL通過return with子句解決這個問題。return with是一種插件機制，它允許子系統 通過插件將自身的查詢條件注入ZQL中，ZQL會先執行關系數據庫查詢，將滿足條件資源的原數據查詢出來后，再將資源的主鍵(primary key)作為輸入條件調用實現return with子句的插件，***將插件的查詢結果一并返回給ZQL的調用者。
上述查詢虛擬機監控數據的需求可以通過一條ZQL語句實現：
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語句中即返回了我們感興趣的元數據字段：uuid和hostUuid，也返回了該虛擬機的監控數據。細心的讀者已經注意到我們在ZWatch查詢字段中指定了參數resultName='webvm-cpu'，并且在返回的JSON map中監控數據的key也是webvm-cpu。跟named as關鍵字一樣，這是為了執行多條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中執行時的例子，使用\對引號轉義
當資源特別多時，時序數據庫查詢性能可能成為多條ZWatch查詢的性能瓶頸，故return with會通過并發的方式執行插件，默認并發度為10。例如上述例子中的13條ZWatch查詢會在10個線程中并發執行。用戶可以通過全局配置zql.returnWith.concurrency更改并發度，例如
UpdateGlobalConfig category=query name=zql.returnWith.concurrency value=15
限制查詢 (restrict by從句)
ZStack的企業管理模塊包含一個功能，可以對管理綁定某個區域，使得該管理員只能管理該區域內的資源，這就要求我們的ZQL對該管理員的查詢請求只返回與其綁定區區中的資源。
對于虛擬機這樣的資源，其元數據本身就帶zoneUuid字段用于標識所在區域。但對于eip這樣的資源，其元數據并無任何字段表示區域屬性，區域屬性是由其所在的三層網絡或綁定的虛擬機確定的。例如要查詢某個區域內的eip，可以使用：
# 通過與虛擬機的綁定關系查詢
query eip where vmNic.vmInstance.zoneUuid = '52fdad0a2c0d4131a6c0fc6c1b7141a6'
或
# 通過所在三層網絡確定
query eip where vip.l3Network.zoneUuid = '52fdad0a2c0d4131a6c0fc6c1b7141a6'
無論那種方式，都需要調用者了解知道eip跟zone之間的關聯關系，這對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既可以通過所在三層網絡，也可以通過綁定的虛擬機確定和區域的關系，插件會自動計算路徑權重，使用權重***的路徑生成SQL語句。
對于eip這個例子，插件會選取通過三層網絡的關系生成SQL語句。因為eip可能沒有跟虛擬機綁定，但其一定處于某個三層網絡，故三層網絡這條路徑的權重更高。
restrict by支持多個條件，通過逗號分隔，多個條件之間是AND關系。
除了給ZQL調用者使用外，restrict by插件在ZStack內部也被其它服務廣泛使用。例如賬號系統會通過插件在普通賬戶調用ZQL的時候注入跟賬號關聯的SQL語句，使得普通賬號只能查詢到屬于該賬號的資源;又例如SNS服務會通過插件注入語句讓ZQL只能查詢到非系統類型的接收端。
未來
ZQL為ZStack提供了一種類似SQL的IaaS查詢語言，并且能夠通過return with插件框架跟其它非關系數據庫系統進行查詢整合。在未來的版本中我們還會繼續豐富其功能，目前有兩個方向：
filter by從句
雖然return with的ZWatch插件能讓我們在查詢資源元數據的同時查詢其監控數據，但還不能將監控數據作為元數據的查詢條件，例如無法通過一條ZQL實現查詢某個集群中所有CPU使用率超過90%的虛擬機。這在未來版本中會通過filter by從句實現，例如：
query vminstance where clusterUuid = '33e26bd547d149fbb190436cc9aca824' filter by (zwatch{metricName='CPUAllUsedUtilization', offsetAheadOfCurrentTime=60, threshold>90})
同樣，filter by從句會實現成類似return with的插件框架，用于整合非關系數據庫的查詢條件。
智能CLI
ZQL有大量的從句，每個ZStack又有大量的可查詢字段，目前ZStack CLI可以對Query API的可查詢字段進行補全，但ZQL還暫時無法補全。未來版本中，我們會對CLI進行在增強，使其對所有查詢條件可以進行提示和補全。
