THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
现状
QueryOperator
...
而 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，以此方便之后物理计划生成的重构，即将物理计划生成放在不同种类的逻辑运算符内完成。
...
首先明确一个概念，QueryOperator 继承自 SFWOperator。
其中有三个成员变量，SelectOperator，FromOperator 和 FilterOperator。
SFWOperator 的继承类包括：
以 DeleteOperator 为例：
其只是为了利用 SelectOperator 中的前（后）缀路径。
这显然是当时设计的时候图省事，就直接让这几个类继承 SFW 了。SFWOperator 还有对于 Where 子句中过滤条件的优化，这是 Insert、Delete 等运算符根本没必要去跑的。
因此，这些类可以从 SFWOperator 的子类中分离出来。（这部分交给宇荣去做了）
...
此前，普通查询中 SELECT 子句中的后缀路径，聚合查询中的聚合函数等信息是存储在SFWOperator内的 SelectOperator 内的，而不是存储在 QueryOperator 内里。
这部分中的后缀路径、聚合函数、UDF及算数表达式等信息，都会被包装为一个 List<ResultColumn> 的一个 List，其中相关操作都会在ResultColumn 内部完成，我们暂时不关心内部实现。
...
这个在读取到第一个 Select 元素时就可以进行判断，并生成对应的查询类型。
于是最后 QueryOperator 的类图为：
QueryOperator主要内容如下：
这里由于 Select、From 等只用来存储内容，并没有逻辑运算符的特性，因此其不应该继承 Operator，于是重新命名为 XxxComponent。
...
SpecialClauseCompent 的类图为：
