JiajunBernoulli的博客

调试后，很快就能在测试专用方法assertFieldOrigin找到SqlValidatorTest$getFieldOrigins这个血缘入口方法。具体的实现如下：通过sqlSelect获得scope，每个scope再取出对应selectItem的SqlQualified。注意这里的selectItem是擦除了别名的，上面代码有个stripAs方法；getFieldOrigin是处理每个Field的方法，但是看代码只支持select语句，不支持insert语句。至此，可以获得列对应的表信息。

Calcite中血缘解析的使用和实现介绍

Calcite的Calc优化到底怎么用？

文章目录CreateParseValidateConvertExecuteSelectParseValidateConvertCreateParse直接使用CalciteParser将String的Sql解析为SqlNode，虚拟列对应的SqlNode的SqlComputedColumn在Flink的设计文档中，虚拟列也被称为计算列。其实应该是刻意与Calcite原生的虚拟列区分开，因为Flink的计算列在Calcite的虚拟列上进行了一些封装。ValidateFlink不对DDL做val

前言从社区的jira发现了一个CTE相关的问题，着手修复前先看了看Calcite是如何处理CTE的。流程ParseParse完之后将CTE分成SqlWith了两部分withList(CTE定义可能有多个)和body两部分， body就是写在最后一段的查询(有可能不会用到所有定义的CTE)ValidateValidateWith的时候会对withList的的每一项进行验证ConvertconvertWith的时候先从body开始因为from的表可能是CTE中定义的，所以是在conver

文章目录前言VolcanoPlannerchangeTraitssetRootfindBestExp总结前言之前分析过HepPlanner的调用以及Graph的变化，这次再来看看VolcanoPlanner的的调用和RelSet的变化VolcanoPlanner从VolcanoPlannerTest的单测不难发现，提供给用户直接调用的接口主要是changeTraits、setRoot、findBestExp三个实际上更这三个方法都被封装在了Programs中，用户一般直接使用Programs#r

文章目录前言优化优化方式runHepPlannerrunVolcanoPlanner入口总结前言在Flink1.9之前只使用Calcite进行优化，之后因为Blink的合入才带来了Flink自己的优化策略。本文以Flink1.8为例子，看看Calcite的优化规则应该怎么使用。优化优化方式Calcite有两种优化方式，Flink所有的优化规则也都是用的这两种runHepPlannerFlink在使用HepPlanner的时候拆成了三层，最底层的负责创建Calcite的HepPlanner并执行

文章目录前言GraphaddRelToGraphLogicalTableScanLogicalProjectLogicalUnionLogicalIntersectapplyRulesapplyRule总结前言读到了篇有用的博客，介绍了Hepplaner的调用流程，总结起来就是setRoot()将RelNode注册到Graph中(Graph的顶点叫HepRelVertex是对RelNode封装)，再进入findBest()按照program一组组的执行优化规则，从Graph中取出符合的点来应用规则。G

文章目录介绍调试起承转合总结介绍列裁剪是一种常见的SQL优化手段，Calcite当中通过RelFieldTrimmer来实现。代码基于calcite-1.29.0大概看一下这个类，它持有两个对象，relBuilder用来构建plan、trimFieldsDispatcher通过反射调用获得结果；它的方法可以分为三类，流程类、裁剪类和辅助类，下文会提到。调试我们可以通过debug单测来学习RelFieldTrimmer的处理逻辑，RelFieldTrimmerTest会通过RelBuilde

文章目录前言文件概览ParseValidateconvertoptimize单测分析ParseValidateConvertOptimize前言之前分析了Flink中如何使用Calcite的，这次再来看看Kylin。与Flink直接使用Calcite的社区版本不同，Kylin单独维护了一个自己版本的Calcite这种方式优点是遇到能够更深入的开发一些社区不具备的功能，缺点是和社区同步升级成本较高(Calcite的社区版本已经到1.30.0了，Kylin还是在1.16.0的基础上发版)文件概览先粗

文章目录前言分析parseplanner前言已经有过一些博客介绍了Calcite的源码，但还没有介绍过如何使用Calcite的。Flink解析和优化用的都是Calcite，加上Flink的代码质量，应该是最适合参考的项目之一了。分析Flink一直致力于流批一体的处理，重构了不少代码，但是SQL的解析优化都在table模块中1.14.3的flink依赖的calcite版本是1.26.0parseFlink有很多自己的语法，所以在flink-sql-parse中自定义了很多语法。Flink沿用了

文章目录背景规则UnionPullUpConstantsRule做了什么？怎么做的?AggregateProjectPullUpConstantsRule做了什么?怎么做的?背景之前设计的tranform存在一个bug，可以通过将limit上提来解决，所以学习一下Calcite上提的规则。顺便也为之后的公共表达式消除打下基础。规则UnionPullUpConstantsRule做了什么？从名字不难看出是将union的常量上提，例如下面的SQL有两个常量2select 2, deptno, jo

Calcite展开View的流程

前言Calcite使用JavaCC进行Parse，有着自己独特的parse语法。如果想对其进行修改，而又不影响原生的语法，通常会加一个配置参数——参数关闭的时候保持Calcite原生的Parse逻辑，开启后用自己写的逻辑。下面总结了增加配置的几个步骤步骤定义接口方法实现接口方法使用接口方法总结...

文章目录前言格式Text/StringXMLJSONDOT属性级别前言我们知道Calcite会将SQL为RelNode构成的执行计划，为了分析执行计划，经常会使用RelOptUtil.toString()将其转为字符串。其实，除了这种字符串之外还有更多的格式，可以展示执行计划：XML、JSON、DOT。格式在SqlExplainFormat中可以看到这四种格式，其中TEXT其实和String一样在RelOptUtilTest.java中构建一个单测，利用已有的relBuilder可以快速构建一个

几个月前Calcite举办了一次线上的讨论会，讨论了开源的发展，也分享了Calcite这些年的演变。个人认为Calcite的发展史有助于学习Calcite，于是单独截取出来分享了一下。LucidDB这是一个数据库项目，包括了JDBC构成的前端和C++编写的后端。插件化C++编写的后端放在LucidDB中比较重，于是将其剥离，抽象为Adapter。不仅减轻了SQL解析优化的压力，还便于不同的引擎实现不同的后端逻辑。同时，这个阶段也将cataglog、rbo和cbo都改为可插拔的。3. Ca

最近Calcite的PMC进行了一次分享，演示了如何使用Calcite，视频在Youtube对应的源码在GitHub，不过源码的LuceneQueryProcessor只是一个模版，我将实现的代码贴在下面/** * Plans and executes an SQL query in the file specified */ public static void main(String[] args) throws Exception { if (args.length !=

文章目录前言HepPlanerfindBestExpexecuteProgramapplyRulesVolcanPlannerfindBestExpdrive前言在debug优化规则的时候总是容易走偏，找不到重点，于是刻意总结了一下优化规则中比较重要的代码位置。首先，Calcite的优化分为HepPlaner(RBO)和VolcanoPlanner(CBO)，所以调用的主要代码都在他们当中HepPlanerHepPlaner会通过findBestExp去找到最优的planfindBestExp

文章目录前言ParseSqlParserUtilValidateSqlValidatorUtilSqlTypeUtilOptimizeRelOptUtilRelMdUtilRelToSqlRelToSqlConverterUtil其他UtilConversionUtil前言工欲善其事，必先利其器，借助已有的一些工具类可以提高使用Calcite进行开发的效率。我们知道Calcite将SQL转换可以分为下面几个阶段：Parse->Validate->Optimize当进行SQL翻译的时候，还

文章目录前言分析命中条件单元测试testProjectAggregateMergeNoOptestProjectAggregateMergeSum0testProjectAggregateMerge前言Calcite专注于SQL优化，有着大量的优化规则。本文以Calcite的1.27.0版本为例，介绍它的各种优化规则。分析命中条件这是触发ProjectAggregateMergeRule最典型的特征：Project的输入有一个Aggregate单元测试在RelOptRulesTest.jav

在Parser.jj(扫描器)、SqlParserTest.java、reference.md中新增关键字在Parser.jj描述解析器(需要遵循JavaCC的规范)，这个类主要有三个功能作为解析使用的SQL statement描述关键字的使用返回Java的SqlNode编写Java实现对应的SqlNode，这个类也有三个功能：记录Operand(如果有的话)和OPERATOR实现转SQL的unparse实现validate(通常会将具体逻辑写在SqlValidatorTest.

前言解决将validator.validateWithItem((SqlWithItem) withItem)代码放到验证from CTE的时候只需要修改两个单测就可以跑通

文章目录前言算子介绍新增代码新增类型date +/- datedate +/- 1新增单测前言Spark3中支持 date +/- date和 date +/- int但Calcite解析的时候还不支持注意这里提示Supported form(s): NUMERIC + NUMERIC 、DATETIME_INTERVAL等等下面便通过修改Calcite的源码来支持这个运算，注意我是在branch-1.22分支上建立了dev分支进行演示算子介绍Calcite将运算符和许多函数都注册在

CalciteResource.java这是一个接口，绑定了参数与BaseMessage，同时声明了异常Class(CalciteException、SqlValidatorException)CalciteResource.properties将CalciteResource.java中新增的方法，functionName和Message同步到属性文件当中下图箭头指出的key就是刚刚看到过的两个方法名首字母大写单元测试(一般是在SqlValidatorTest.java)与SqlToRe.

文章目录前言案例查询流程核心流程前言Calcite的学习资料并不丰富，于是自己便想通过debug单元测试的代码来学习。至于debug的案例就是官方提供的csvTest了，对新人而言csv应该比数据库要友好。案例查询流程在example/csv/src/test/java/org/apache/calcite/test/CsvTest.java中有很多单元测试的方法，我选择最简单的testSelect()。加入断点，开始debug。直接进入发现是一个checkSql()，似乎和检查相关。接着进入

首先熟悉SQL的流程环节，Sql 的执行过程一般可以分为下图中的四个阶段，Calcite 同样也是这样：

文章目录简介教程下载并构建初次查询简介Apache Calcite是用于构建数据库和数据管理系统的开源框架。它包括一个SQL 解析器，一个用于在关系代数中构建表达式的API以及一个查询计划引擎。教程官方为我们提供了简单的教程，但是我在学习的时候遇到了坑，于是记录一下分享出来。下载并构建git clone https://github.com/apache/calcite.gitcd calcite/example/csv./sqlline刚开始就卡在这，简直是劝退教程…最开始怀疑是