ClickHouse和他的朋友们(8)纯手工打造的SQL解析器
/ 点击现实生活中的物品一旦被标记为“纯手工打造”,给人的第一感觉就是“上乘之品”,一个字“贵”,比如北京老布鞋。
但是在计算机世界里,如果有人告诉你 ClickHouse 的 SQL 解析器是纯手工打造的,是不是很惊讶!
这个问题引起了不少网友的关注,所以本篇聊聊 ClickHouse 的纯手工解析器,看看它们的底层工作机制及优缺点。
枯燥先从一个 SQL 开始:
1 | EXPLAIN SELECT a,b FROM t1 |
token
首先对 SQL 里的字符逐个做判断,然后根据其关联性做 token 分割:
比如连续的 WordChar,那它就是 BareWord,解析函数在 Lexer::nextTokenImpl(),解析调用栈:
1 | DB::Lexer::nextTokenImpl() Lexer.cpp:63 |
ast
token 是最基础的元组,他们之间没有任何关联,只是一堆生冷的词组与符号,所以我们还需对其进行语法解析,让这些 token 之间建立一定的关系,达到一个可描述的活力。
ClickHouse 在解每一个 token 的时候,会根据当前的 token 进行状态空间进行预判(parse 返回 true 则进入子状态空间继续),然后决定状态跳转,比如:
1 | EXPLAIN -- TokenType::BareWord |
逻辑首先会进入Parsers/ParserQuery.cpp 的 ParserQuery::parseImpl 方法:
1 | bool res = query_with_output_p.parse(pos, node, expected) |
这里会对所有 query 类型进行 parse 方法的调用,直到有分支返回 true。
我们来看第一层 query_with_output_p.parse Parsers/ParserQueryWithOutput.cpp:
1 | bool parsed = |
跳进第二层 explain_p.parse ParserExplainQuery::parseImpl状态空间:
1 | bool ParserExplainQuery::parseImpl(Pos & pos, ASTPtr & node, Expected & expected) |
s_explain.ignore 方法会进行一个 keyword 解析,解析出 ast node:
1 | EXPLAIN -- keyword |
跃进第三层 select_p.parse ParserSelectWithUnionQuery::parseImpl状态空间:
1 | bool ParserSelectWithUnionQuery::parseImpl(Pos & pos, ASTPtr & node, Expected & expected) |
parser.parse 里又调用第四层 ParserSelectQuery::parseImpl 状态空间:
1 | bool ParserSelectQuery::parseImpl(Pos & pos, ASTPtr & node, Expected & expected) |
第五层 exp_list_for_select_clause.parse ParserExpressionList::parseImpl状态空间继续:
1 | bool ParserExpressionList::parseImpl(Pos & pos, ASTPtr & node, Expected & expected) |
… … 写不下去个鸟!
可以发现,ast parser 的时候,预先构造好状态空间,比如 select 的状态空间:
- expression list
- from tables
- where
- group by
- with …
- order by
- limit
在一个状态空间內,还可以根据 parse 返回的 bool 判断是否继续进入子状态空间,一直递归解析出整个 ast。
总结
手工 parser 的好处是代码清晰简洁,每个细节可防可控,以及友好的错误处理,改动起来不会一发动全身。
缺点是手工成本太高,需要大量的测试来保证其正确性,还需要一些fuzz来保证可靠性。
好在ClickHouse 已经实现的比较全面,即使有新的需求,在现有基础上修修补补即可。