产品发布

RELEASE
揭密首个面向IaaS的查询语言:ZStack Query Language(ZQL)

ZStack研发团队 | 2018-08-14 19:11

为了简化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进行在增强,使其对所有查询条件可以进行提示和补全。




欢迎大家在官网下载页面

/product_downloads/

进行免费的下载安装和试用。


咨询

021-61733682

400-962-2212