0.13.0-SNAPSHOT 版本现状
QueryOperator
查询语句的 SQL 解析按顺序主要分为 4 个部分:
解析 SELECT 子句
解析 FROM 子句
解析 WHERE 子句
解析 WHERE 子句后的特殊声明 SpecialClause(如 Group by,Limit 等)
我们重点关注第一部分和第四部分。
在查询语句中,一部分查询的类型是由第一部分确定的,另一部分查询的类型是由第四部分确定的。
如聚合查询, select count(s1) from root.sg.d1
,显然由 SELECT 子句,即第一部分确定。
而 Group by 查询,select count(s1) from root.sg.d1 group by ([1, 10), 2ms)
,则由第四部分确定。
总结:
由第一部分确定的查询类型包括:
普通查询
聚合查询
last 查询
UDF 查询
由第四部分确定的查询类型包括:
Group by 查询
Group by fill 查询
Fill 查询
Align by device 查询
我们计划为每种查询类型新建一个逻辑运算符,如为 Group by
新建 GroupByQueryOperator
,以此方便之后物理计划生成的重构,即将物理计划生成放在不同种类的逻辑运算符内完成。
此前,是按照 SELECT -> FROM -> WHERE -> SpecialClause 的顺序进行解析,这显然不再合理,因为没办法提前知道由第四部分决定的查询类型。
因此,计划将解析顺序改为,SpecialClause -> SELECT -> FROM -> WHERE
首先明确一个概念,QueryOperator 继承自 SFWOperator。
其中有三个成员变量,SelectOperator,FromOperator 和 FilterOperator。
SFWOperator
的继承类包括:
以 DeleteOperator
为例:
其只是为了利用 SelectOperator
中的前(后)缀路径。
这显然是当时设计的时候图省事,就直接让这几个类继承 SFW 了。SFWOperator
还有对于 Where 子句中过滤条件的优化,这是 Insert、Delete 等运算符根本没必要去跑的。
因此,这些类可以从 SFWOperator
的子类中分离出来。(这部分交给宇荣去做了)
此时,SFWOperator
就可以直接干掉,其中的成员变量直接拿到 QueryOperator
内。因为其只有一个子类为 QueryOperator
.
我们继续来看查询部分。
此前,普通查询中 SELECT 子句中的后缀路径,聚合查询中的聚合函数等信息是存储在SFWOperator
内的 SelectOperator
内的,而不是存储在 QueryOperator
内里。
这部分中的后缀路径、聚合函数、UDF及算数表达式等信息,都会被包装为一个 List<ResultColumn>
的一个 List,其中相关操作都会在ResultColumn
内部完成,我们暂时不关心内部实现。
于是,由第一部分决定的查询类型对外暴露的 SelectComponent 是相同的,只有 SelectComponent
内部的 ResultColumn 类型不同。
这个在读取到第一个 Select 元素时就可以进行判断,并生成对应的查询类型。
于是最后 QueryOperator
的类图为:
QueryOperator
主要内容如下:
这里由于 Select、From 等只用来存储内容,并没有逻辑运算符的特性,因此其不应该继承 Operator,于是重新命名为 XxxComponent
。
SpecialClauseCompent 的类图为: