Open Distro for Elasticsearch SQL引擎架构详解一条SQL从ANTLR解析到Elasticsearch DSL的完整旅程【免费下载链接】sql Open Distro SQL Plugin项目地址: https://gitcode.com/gh_mirrors/sq/sqlOpen Distro for Elasticsearch SQL 插件让你用标准 SQL 直接查询 Elasticsearch 索引而不用手写 JSON DSL。它的核心是一套自研 SQL 引擎SQL 语句先经 ANTLR 语法解析再经过语义分析、逻辑计划优化最终被翻译成 Elasticsearch DSL 并异步执行返回结果。本文带你完整走一遍一条 SQL 在引擎内部的旅程 。整体架构四大模块一张图看懂这套 SQL 引擎可以拆成四个各司其职的核心模块模块职责一句话理解Parser 解析器基于 ANTLR 语法文件生成解析树读懂 SQL 的语法Analyzer 分析器语法与语义分析、类型检查确认查询说得通Core Engine 核心引擎逻辑计划 → 优化 → 物理计划决定怎么查最快Execution 执行层在工作线程执行计划并返回结果向 ES 发出真正的 DSL 请求一条 SQL 进入引擎后依次穿越这四个模块官方架构文档中有完整的流转示意图更详细的文字说明可参考架构文档docs/dev/Architecture.md。第 1 站ANTLR 把 SQL 字符串变成解析树一切从语法文件开始。项目用 ANTLR 定义了完整的 SQL 文法规则词法/语法定义sql/src/main/antlr/OpenDistroSQLParser.g4配套的词法文件是sql/src/main/antlr/OpenDistroSQLLexer.g4解析入口sql/src/main/java/com/amazon/opendistroforelasticsearch/sql/sql/antlr/SQLSyntaxParser.java以这条聚合查询为例SELECT user, count(*) AS cnt FROM accounts GROUP BY user解析器做了三件贴心小事大小写不敏感内部用CaseInsensitiveCharStream包装输入select和SELECT等价友好的报错挂了一个自定义SyntaxAnalysisErrorListener语法写错时给出可读的提示而不是抛出一串堆栈输出解析树CST这是文法层面的树还不是最终形态下一站再提纯。第 2 站AST 构建与语义分析类型检查在这里把关 解析树只是骨架引擎还需要一个语义化的抽象语法树ASTsql/src/main/java/com/amazon/opendistroforelasticsearch/sql/sql/parser/AstBuilder.java负责把 CST 转换为UnresolvedPlan未解析的 AST随后core/src/main/java/com/amazon/opendistroforelasticsearch/sql/analysis/Analyzer.java以访问者模式逐节点遍历 AST完成符号解析与类型推导。语义分析的核心是类型环境TypeEnvironment分析到FROM表时先把该索引的每个字段及其类型注册进符号表之后每个表达式比如user字段、count(*)、WHERE age 18都会在类型环境中推导自己的类型。类型是怎么一层层合成出来的下图直观展示了字面量、字段引用、函数调用各自的类型合成规则这就是为什么写错函数参数时会收到精确报错例如Function [LOG] cannot work with [INTEGER, KEYWORD]. Usage: LOG(NUMBER T) → DOUBLE报错里同时告诉你了函数的正确用法对新手非常友好。WHERE 条件中的谓词AND/OR/比较/IN也都在这一阶段被逐一解析、优化第 3 站逻辑计划优化为物理计划 ⚙️语义分析的输出是一棵逻辑计划树LogicalPlan——Filter、Aggregation、Sort、Limit等逻辑算子按查询结构组装此时还和任何存储无关。接着core/src/main/java/com/amazon/opendistroforelasticsearch/sql/planner/Planner.java上场先用基于规则的优化器LogicalPlanOptimizer改写逻辑计划比如MergeFilterAndFilter合并相邻过滤、PushFilterUnderSort过滤下推等规则再委托存储引擎实现成物理计划PhysicalPlan。对 Elasticsearch 而言最有价值的优化是把多个算子合并成一次 ES 请求。规则目录elasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/planner/logical/rule/下就有专门的规则例如MergeAggAndIndexScan.java把聚合 索引扫描合并为一个带聚合的 ES 查询避免先拉全量数据再内存聚合MergeSortAndIndexScan.java把排序下推到 ES 的sort让倒排索引直接排好序。这些合并规则正是 SQL 引擎在大数据量下保持高性能的关键。第 4 站翻译成 Elasticsearch DSL 并异步执行 ️物理计划落地时elasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/storage/ElasticsearchStorageEngine.java及其存储实现会把算子翻译成 ES 原生能力过滤条件→ Lucene 查询Term / Range / Wildcard无法映射的复杂表达式退化为脚本过滤.../storage/script/filter/FilterQueryBuilder.java聚合→ ES 的 Bucket / Metric 聚合构建器.../storage/script/aggregation/目录排序→ ESsort子句.../storage/script/sort/SortQueryBuilder.java。执行阶段由elasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/executor/ElasticsearchExecutionEngine.java负责。它有两个重要的工程设计线程模型解析、分析、计划都在 ES 传输线程上完成禁止阻塞操作而真正发请求的执行动作放到工作线程池中避免拖垮集群分页与保护大结果集用 scroll 游标分页返回同时执行保护器.../executor/protector/监控内存消耗防止 JOIN 等内存操作影响 Elasticsearch 的可用性。执行完成后响应被解析、格式化为统一的结果结构默认 JDBC 风格schema 行数据返回给客户端。至此一条 SQL 完成了从文本到 ES DSL 的完整旅程。如何亲手体验这条旅程不需要深入代码三种方式任选其一即可跑通Kibana SQL Workbench安装插件后在 Kibana 中直接写 SQL 并查看执行计划workbench/目录即其源码命令行 CLIsql-cli/提供了终端版 SQL 客户端拉下源码阅读跟着本文四个模块的顺序看实现git clone https://gitcode.com/gh_mirrors/sq/sql下图是 SQL CLI 的实际使用效果一条 SQL 回车即得表格化结果关键模块速查表架构到源码的对应关系旅程阶段核心类/文件参考路径ANTLR 语法定义OpenDistroSQLParsersql/src/main/antlr/OpenDistroSQLParser.g4解析入口SQLSyntaxParsersql/src/main/java/com/amazon/opendistroforelasticsearch/sql/sql/antlr/SQLSyntaxParser.javaCST → ASTAstBuildersql/src/main/java/com/amazon/opendistroforelasticsearch/sql/sql/parser/AstBuilder.java语义分析Analyzercore/src/main/java/com/amazon/opendistroforelasticsearch/sql/analysis/Analyzer.java逻辑→物理计划Plannercore/src/main/java/com/amazon/opendistroforelasticsearch/sql/planner/Planner.java执行引擎接口ExecutionEnginecore/src/main/java/com/amazon/opendistroforelasticsearch/sql/executor/ExecutionEngine.javaES DSL 翻译ElasticsearchStorageEngineelasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/storage/ElasticsearchStorageEngine.javaES 合并优化规则logical rule 目录elasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/planner/logical/rule/ES 执行引擎ElasticsearchExecutionEngineelasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/executor/ElasticsearchExecutionEngine.java插件入口SQLPluginplugin/src/main/java/com/amazon/opendistroforelasticsearch/sql/plugin/SQLPlugin.java架构总览文档Architecture.mddocs/dev/Architecture.md小结回顾这条 SQL 的旅程ANTLR 解析树 → AST 与语义/类型检查 → 逻辑计划优化 → 合并为 ES 原生查询 → 工作线程异步执行 → 统一格式返回。整个设计有两个值得借鉴的思路——用逻辑计划/物理计划两层抽象把查询语义与存储实现解耦让引擎可以面向不同存储以及把重操作移出 ES 传输线程并加上资源保护保证查询插件不会拖垮集群。理解了这四站再去看core、sql、elasticsearch三个模块的源码基本就不会迷路了。【免费下载链接】sql Open Distro SQL Plugin项目地址: https://gitcode.com/gh_mirrors/sq/sql创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Open Distro for Elasticsearch SQL引擎架构详解一条SQL从ANTLR解析到Elasticsearch DSL的完整旅程【免费下载链接】sql Open Distro SQL Plugin项目地址: https://gitcode.com/gh_mirrors/sq/sqlOpen Distro for Elasticsearch SQL 插件让你用标准 SQL 直接查询 Elasticsearch 索引而不用手写 JSON DSL。它的核心是一套自研 SQL 引擎SQL 语句先经 ANTLR 语法解析再经过语义分析、逻辑计划优化最终被翻译成 Elasticsearch DSL 并异步执行返回结果。本文带你完整走一遍一条 SQL 在引擎内部的旅程 。整体架构四大模块一张图看懂这套 SQL 引擎可以拆成四个各司其职的核心模块模块职责一句话理解Parser 解析器基于 ANTLR 语法文件生成解析树读懂 SQL 的语法Analyzer 分析器语法与语义分析、类型检查确认查询说得通Core Engine 核心引擎逻辑计划 → 优化 → 物理计划决定怎么查最快Execution 执行层在工作线程执行计划并返回结果向 ES 发出真正的 DSL 请求一条 SQL 进入引擎后依次穿越这四个模块官方架构文档中有完整的流转示意图更详细的文字说明可参考架构文档docs/dev/Architecture.md。第 1 站ANTLR 把 SQL 字符串变成解析树一切从语法文件开始。项目用 ANTLR 定义了完整的 SQL 文法规则词法/语法定义sql/src/main/antlr/OpenDistroSQLParser.g4配套的词法文件是sql/src/main/antlr/OpenDistroSQLLexer.g4解析入口sql/src/main/java/com/amazon/opendistroforelasticsearch/sql/sql/antlr/SQLSyntaxParser.java以这条聚合查询为例SELECT user, count(*) AS cnt FROM accounts GROUP BY user解析器做了三件贴心小事大小写不敏感内部用CaseInsensitiveCharStream包装输入select和SELECT等价友好的报错挂了一个自定义SyntaxAnalysisErrorListener语法写错时给出可读的提示而不是抛出一串堆栈输出解析树CST这是文法层面的树还不是最终形态下一站再提纯。第 2 站AST 构建与语义分析类型检查在这里把关 解析树只是骨架引擎还需要一个语义化的抽象语法树ASTsql/src/main/java/com/amazon/opendistroforelasticsearch/sql/sql/parser/AstBuilder.java负责把 CST 转换为UnresolvedPlan未解析的 AST随后core/src/main/java/com/amazon/opendistroforelasticsearch/sql/analysis/Analyzer.java以访问者模式逐节点遍历 AST完成符号解析与类型推导。语义分析的核心是类型环境TypeEnvironment分析到FROM表时先把该索引的每个字段及其类型注册进符号表之后每个表达式比如user字段、count(*)、WHERE age 18都会在类型环境中推导自己的类型。类型是怎么一层层合成出来的下图直观展示了字面量、字段引用、函数调用各自的类型合成规则这就是为什么写错函数参数时会收到精确报错例如Function [LOG] cannot work with [INTEGER, KEYWORD]. Usage: LOG(NUMBER T) → DOUBLE报错里同时告诉你了函数的正确用法对新手非常友好。WHERE 条件中的谓词AND/OR/比较/IN也都在这一阶段被逐一解析、优化第 3 站逻辑计划优化为物理计划 ⚙️语义分析的输出是一棵逻辑计划树LogicalPlan——Filter、Aggregation、Sort、Limit等逻辑算子按查询结构组装此时还和任何存储无关。接着core/src/main/java/com/amazon/opendistroforelasticsearch/sql/planner/Planner.java上场先用基于规则的优化器LogicalPlanOptimizer改写逻辑计划比如MergeFilterAndFilter合并相邻过滤、PushFilterUnderSort过滤下推等规则再委托存储引擎实现成物理计划PhysicalPlan。对 Elasticsearch 而言最有价值的优化是把多个算子合并成一次 ES 请求。规则目录elasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/planner/logical/rule/下就有专门的规则例如MergeAggAndIndexScan.java把聚合 索引扫描合并为一个带聚合的 ES 查询避免先拉全量数据再内存聚合MergeSortAndIndexScan.java把排序下推到 ES 的sort让倒排索引直接排好序。这些合并规则正是 SQL 引擎在大数据量下保持高性能的关键。第 4 站翻译成 Elasticsearch DSL 并异步执行 ️物理计划落地时elasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/storage/ElasticsearchStorageEngine.java及其存储实现会把算子翻译成 ES 原生能力过滤条件→ Lucene 查询Term / Range / Wildcard无法映射的复杂表达式退化为脚本过滤.../storage/script/filter/FilterQueryBuilder.java聚合→ ES 的 Bucket / Metric 聚合构建器.../storage/script/aggregation/目录排序→ ESsort子句.../storage/script/sort/SortQueryBuilder.java。执行阶段由elasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/executor/ElasticsearchExecutionEngine.java负责。它有两个重要的工程设计线程模型解析、分析、计划都在 ES 传输线程上完成禁止阻塞操作而真正发请求的执行动作放到工作线程池中避免拖垮集群分页与保护大结果集用 scroll 游标分页返回同时执行保护器.../executor/protector/监控内存消耗防止 JOIN 等内存操作影响 Elasticsearch 的可用性。执行完成后响应被解析、格式化为统一的结果结构默认 JDBC 风格schema 行数据返回给客户端。至此一条 SQL 完成了从文本到 ES DSL 的完整旅程。如何亲手体验这条旅程不需要深入代码三种方式任选其一即可跑通Kibana SQL Workbench安装插件后在 Kibana 中直接写 SQL 并查看执行计划workbench/目录即其源码命令行 CLIsql-cli/提供了终端版 SQL 客户端拉下源码阅读跟着本文四个模块的顺序看实现git clone https://gitcode.com/gh_mirrors/sq/sql下图是 SQL CLI 的实际使用效果一条 SQL 回车即得表格化结果关键模块速查表架构到源码的对应关系旅程阶段核心类/文件参考路径ANTLR 语法定义OpenDistroSQLParsersql/src/main/antlr/OpenDistroSQLParser.g4解析入口SQLSyntaxParsersql/src/main/java/com/amazon/opendistroforelasticsearch/sql/sql/antlr/SQLSyntaxParser.javaCST → ASTAstBuildersql/src/main/java/com/amazon/opendistroforelasticsearch/sql/sql/parser/AstBuilder.java语义分析Analyzercore/src/main/java/com/amazon/opendistroforelasticsearch/sql/analysis/Analyzer.java逻辑→物理计划Plannercore/src/main/java/com/amazon/opendistroforelasticsearch/sql/planner/Planner.java执行引擎接口ExecutionEnginecore/src/main/java/com/amazon/opendistroforelasticsearch/sql/executor/ExecutionEngine.javaES DSL 翻译ElasticsearchStorageEngineelasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/storage/ElasticsearchStorageEngine.javaES 合并优化规则logical rule 目录elasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/planner/logical/rule/ES 执行引擎ElasticsearchExecutionEngineelasticsearch/src/main/java/com/amazon/opendistroforelasticsearch/sql/elasticsearch/executor/ElasticsearchExecutionEngine.java插件入口SQLPluginplugin/src/main/java/com/amazon/opendistroforelasticsearch/sql/plugin/SQLPlugin.java架构总览文档Architecture.mddocs/dev/Architecture.md小结回顾这条 SQL 的旅程ANTLR 解析树 → AST 与语义/类型检查 → 逻辑计划优化 → 合并为 ES 原生查询 → 工作线程异步执行 → 统一格式返回。整个设计有两个值得借鉴的思路——用逻辑计划/物理计划两层抽象把查询语义与存储实现解耦让引擎可以面向不同存储以及把重操作移出 ES 传输线程并加上资源保护保证查询插件不会拖垮集群。理解了这四站再去看core、sql、elasticsearch三个模块的源码基本就不会迷路了。【免费下载链接】sql Open Distro SQL Plugin项目地址: https://gitcode.com/gh_mirrors/sq/sql创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
