揭密首個面向IaaS的查詢語言：ZStack Query Language（ZQL）
為了簡化UI工作并為運維人員提供一種更加靈活的資源查詢方式，ZStack在2.6版本中推出了***面向IaaS的查詢語言 —— ZStack Query Language，簡稱ZQL。
背景
IaaS管理著海量的數據中心資源，如何對這些資源進行靈活快速的查詢是運維人員面臨的一個難題。在以往的IaaS軟件中，往往只對單個資源的某些字段提供有限的API查詢支持，例如可以通過虛擬機的IP字段查詢，這不足夠也不靈活。運維人員在做復雜查詢時往往得繞開IaaS軟件直接查詢其后端數據庫，這既要求運維人員要了解IaaS資源的內部關系，又帶來了數據庫誤操作的風險。
從ZStack正式發(fā)布的***個版本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邏輯，無法執(zhí)行OR邏輯，條件之間也無法加括號實現復雜邏輯組合
Ø 不支持類似SQL中的sub query子句
Ø 單個API只能查詢一種資源，查詢多種資源時需要調用多個API
Ø 不支持跟監(jiān)控系統(tǒng)的查詢語言整合
隨著ZStack UI的場景越來越豐富，Query API的限制使得UI端的工作越來越多，很多場景需要多次調用Query API進行數據組合。例如在監(jiān)控Top 5頁面(用于檢測系統(tǒng)中CPU、內存、磁盤、網絡等資源使用率***5個資源的頁面)，需要先采用Query API將虛擬機、物理機等資源信息查詢回來，再調用監(jiān)控系統(tǒng)ZWatch的API查詢對應的監(jiān)控數據。
Query API在未來的ZStack版本中會一直保留并維護，其后端實現已經從原來的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根據自身需求進行的增強的查詢語言。它的基本結構如下：
QUERY queryTarget (WHERE condition+)? restrictBy? returnWith? groupBy? orderBy? limit? offset? filterBy? namedAs?
query關鍵詞
一條ZQL語句通常以query關鍵字開頭，queryTarget表示要查詢的資源或資源字段的集合。前面的例子中vminstance代表虛擬機，例如host代表物理機、zone代表區(qū)域，所有可被查詢的資源都有自己的名稱。如果不希望返回資源的所有字段，只希望獲得資源的一個或多個字段，實現類似SQL的select uuid,name from ...的功能，可以在資源名后指定字段名，多個字段名用逗號隔離，例如：
query vminstance.uuid,name,cpuNum
該查詢返回所有虛擬機的UUID、名稱以及CPU數量。
除了query關鍵字，查詢也能以count和sum關鍵字開頭，前者返回滿足查詢條件資源的總數，后者可以對資源的某個字段進行求和。例如：
count vminstance where cpuNum > 8
返回系統(tǒng)中CPU數量超過8核的虛擬機的總數。
sum vminstance.memorySize by name where cpuNum > 8
用虛擬機名字對CPU核數超過8個的虛擬機進行分組，對它們的memorySize字段進行求和。如果系統(tǒng)中有兩個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：
通過虛擬機的區(qū)域UUID和集群UUID分組，統(tǒng)計各區(qū)域中各集群中虛擬機的數量。
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獲得對應語句的查詢結果。
合并監(jiān)控查詢 (return with從句)
在ZStack中使用了兩種數據庫：關系數據庫存放元數據，時序數據庫存放監(jiān)控數據。由于不同數據庫查詢方式不一樣，在ZQL之前，用戶要查詢一個資源的監(jiān)控數據，需要先通過Query API獲得該資源的元數據，再通過ZWatch的查詢API獲得其監(jiān)控數據。例如要查詢一個名為webvm虛擬機的CPU使用率監(jiān)控數據，要執(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í)行關系數據庫查詢，將滿足條件資源的原數據查詢出來后，再將資源的主鍵(primary key)作為輸入條件調用實現return with子句的插件，***將插件的查詢結果一并返回給ZQL的調用者。
上述查詢虛擬機監(jiān)控數據的需求可以通過一條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，也返回了該虛擬機的監(jiān)控數據。細心的讀者已經注意到我們在ZWatch查詢字段中指定了參數resultName='webvm-cpu'，并且在返回的JSON map中監(jiān)控數據的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í)行時的例子，使用\對引號轉義
當資源特別多時，時序數據庫查詢性能可能成為多條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ū)中的資源。
對于虛擬機這樣的資源，其元數據本身就帶zoneUuid字段用于標識所在區(qū)域。但對于eip這樣的資源，其元數據并無任何字段表示區(qū)域屬性，區(qū)域屬性是由其所在的三層網絡或綁定的虛擬機確定的。例如要查詢某個區(qū)域內的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既可以通過所在三層網絡，也可以通過綁定的虛擬機確定和區(qū)域的關系，插件會自動計算路徑權重，使用權重***的路徑生成SQL語句。
對于eip這個例子，插件會選取通過三層網絡的關系生成SQL語句。因為eip可能沒有跟虛擬機綁定，但其一定處于某個三層網絡，故三層網絡這條路徑的權重更高。
restrict by支持多個條件，通過逗號分隔，多個條件之間是AND關系。
除了給ZQL調用者使用外，restrict by插件在ZStack內部也被其它服務廣泛使用。例如賬號系統(tǒng)會通過插件在普通賬戶調用ZQL的時候注入跟賬號關聯的SQL語句，使得普通賬號只能查詢到屬于該賬號的資源;又例如SNS服務會通過插件注入語句讓ZQL只能查詢到非系統(tǒng)類型的接收端。
未來
ZQL為ZStack提供了一種類似SQL的IaaS查詢語言，并且能夠通過return with插件框架跟其它非關系數據庫系統(tǒng)進行查詢整合。在未來的版本中我們還會繼續(xù)豐富其功能，目前有兩個方向：
filter by從句
雖然return with的ZWatch插件能讓我們在查詢資源元數據的同時查詢其監(jiān)控數據，但還不能將監(jiān)控數據作為元數據的查詢條件，例如無法通過一條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進行在增強，使其對所有查詢條件可以進行提示和補全。
