OLAP解析工具简单对比

 

 

目前已知和了解的SQL解析转义工具有Antlr，Calcite和SparkSQL，就这三种解析转义的优缺点做个简单的阐述

 

简介

Antlr

是一款非常经典的解析工具，它基于g4文件，只要熟悉其语法机构，即可创建一种新的语言（可以进行词义和语义解析的）。

 

流程

样例/模板

csvFile: hdr row+ ; hdr : row ; row : field (',' field)* '\r'? '\n' ; field     : TEXT     | STRING     |     ;   TEXT   : ~[,\n\r"]+ ; STRING : '"' ('""'|~'"')* '"' ; // quote-quote is an escaped quote

 

Antlr在解析这一块的确很优秀，可以指定或者重写语法块以实现更快速、便捷的访问token，但其本身无法对已经创建好的语法树进行更改（我目前了解到的是如此），因此需要自身将解析出来的token再进一步的转换封装（spark和hive就是这样做的）。

而我们在OLAP一期的操作是使用为字符串替换原则，即解析出语法树并记录语法树规则后对单个语法树中的字段进行替换。

 

Calcite

和Antlr一样，都是SQL语法解析器，不过它是基于javacc的（文件扩展名以jj为后缀），语法结构更接近java语言。

流程

样例/模板

options {     JavaCC的选项 }   PARSER_BEGIN(解析器类名) package 包名; import 库名;   public class 解析器类名 {     任意的Java代码 } PARSER_END(解析器类名)   扫描器的描述   解析器的描述

 

Calcite的功能十分强大，不仅有解析还有验证优化过程，且支持动态修改已生成的语法树，可以实现语法树的转义操作，目前flink，kylin都是基于此做的二次开发。

 

Calcite的解析阶段无需做更多的适配操作，和Antlr的解析时间差不太多，但当加入验证阶段时（模型查询时需要验证字段是否存在），自己手写的Antlr解析+字段验证和Calcite自身的解析+验证就体现出了差距，多次试验发现Calcite的整体耗时要大于Antlr，几乎是Antlr的1.5倍+，且Calcite验证阶段还需要单独编写Schema和Table信息。

 

Calcite的查询阶段是基于Calcite自身的jdcb方式将验证后的SQL直接查询（实现Calcite支持的查询操作，类似Spark的RDD），可以真正做到一个SQL搞定一切。

 

SparkSQL

流程

 

SparkSQL是基于Antrl的二次开发，在解析之上加入了logicalPlan。SparkSQL意在做到对用户而言一条SQL搞定一切，且基于RDD实现分布式查询，性能更为高效。SparkSQL已经发展多年，为更多的人熟悉和了解。

 

对比

基于以上的介绍，他们的优缺点如下

 

 

解析引擎 对比项	Antrl	Calcite	SparkSQL
自身特性	轻，快，只能做解析，无法进行查询操作	功能丰富，查询方面可能是基于内存的	功能丰富，支持分布式
上手速度	快，熟悉语法结构即可	慢于Antlr，需要了解多方面的知识	较慢，需要了解RDD和logicalPlan
文档完整度	目前能够搜索到的文档基本上能够解决生产问题	文档偏少，都是一些基础的使用	文档较多，各种问题的解决方案都可以找到
新功能修改量	当有新的语法时只需要修改g4文件并重新编译+修改解析代码	当需要实现新的语法时需要修改jj文件并重新编译+修改解析代码 语法验证模块每增加一种新的引擎时需要新增一种schema 查询模块和验证模块一样，都需要新增处理逻辑	当需要实现新的语法时需要修改g4文件并重新编译 验证模型由spark自身完成，只需要传入正确的catalog即可（新的datasource） 每新增一种引擎需要单独实现一种RDD
其他	如果想做转义，对于简单的SQL，Antlr能够胜任，但当SQL很复杂时，可能就无能为力或者难度很大，如各种嵌套SQL，各种复杂的函数处理 其实现在很多引擎都支持SQL了，如ES（需要引入插件包），DRUID（新版）因此也可以把转义只做到最里层最简单的	当定义好新的schema和table以及查询操作时以及实现了转义操作，不需要单独去实现。目前已经支持es，druid，spark等 支持跨源操作，但是是基于内存的	Spark的查询是基于RDD的，只要实现底表的数据查询即可完成转义（如将ES的某个索引数据转为RDD） 支持跨源操作，是否分布式基于RDD的获取方式，但最外层的计算是在内存 SparkSQL自身可能比较重，需要引入各种依赖的环境