在线阅读杂志

    2018年05月20日

    第10期 总第484期

    封面文章
    “网银”殊途同归路
    金融服务似乎正在以你想要的方式前行。 相应的,金融的生态及格局也在发生重大变化。技术的推动让金融的数字化转型愈发明显,传统金融机构“离柜率”同互联网银行业务激增形成强烈的对比。[详细]
    精彩推荐
  • 揭密首个面向IaaS的查询语言:ZStack Query Language(ZQL)

    时间:2018-08-15    来源:    作者: 我要评论() 字号:T | T

  • 为了简化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的count();

    通过fields参数指定要返回的字段,类似SQL的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' (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的uuid,name from ...的功能,可以在资源名后指定字段名,多个字段名用逗号隔离,例如:

    query vminstance.uuid,name,cpuNum

    该查询返回所有虚拟机的UUID、名称以及CPU数量。

    除了query关键字,查询也能以count和sum关键字开头,前者返回满足查询条件资源的总数,后者可以对资源的某个字段进行求和。例如:

    vminstance where cpuNum > 8

    返回系统中CPU数量超过8核的虚拟机的总数。

    sum vminstance.memorySize by name where cpuNum > 8

    用虚拟机名字对CPU核数超过8个的虚拟机进行分组,对它们的memorySize字段进行求和。如果系统中有两个10CPU8G的虚拟机都名为webvm,则求和后返回webvm虚拟机总内存使用数为16G。翻译成SQL则为:

    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分组,统计各区域中各集群中虚拟机的数量。

    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' hypervisorType='KVM' type='UserVm' 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进行在增强,使其对所有查询条件可以进行提示和补全。

    欢迎大家在ZStack官网下载页面

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

  • 加入收藏
  • [ 作者: ]
  • 分享到: 更多
    标签:
  • 相关推荐
    无相关信息
  • 最新消息
    · 细思极恐 网友公认的手机最不安全的五大瞬间2018-08-15
    · HGBC在迅雷链完成全链条部署,基因+区块链将迎快速发展2018-08-15
    · 确定!360手机新品果然为N7 Pro各方面表现完胜上代2018-08-15
    · 360手机新品售价多少?知情人告诉你2299元起2018-08-15
    · 360手机新品价格泄露:标准版2299元2018-08-15
      已有条评论,查看更多评伦发表评论
  • 用户名:  密码:              匿名发表  | 注册会员
  • 网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述