Flink计算列实现原理

前言

因为工作需要使用到Calcite的虚拟列，而Flink的计算列使用了Calcite虚拟列的部分实现，于是调研了一些Flink计算列的实现原理。

Create

Parse

直接使用CalciteParser将String的Sql解析为SqlNode，虚拟列对应的SqlNode的SqlComputedColumn

在Flink的设计文档中，虚拟列也被称为计算列。其实应该是刻意与Calcite原生的虚拟列区分开，因为Flink的计算列在Calcite的虚拟列上进行了一些封装。

Validate

Flink不对DDL做validate，所以直接return

Convert

根据create table对应的SqlNode即SqlCreateTable，生成CatalogTableImpl。CatalogTableImpl的ComputedColumn中多出来type信息

type的信息可以根据表达式推断出来

Execute

执行的时候，由不同的catalog实现自己的creatTable逻辑

• GenericInMemoryCatalog#createTable

从CatalogTableITCase#testInsertSourceTableExpressionFields单测可以看到Flink直接将CatalogTableImpl封装到了ResolvedCatalogTable，注册到GenericInMemoryCatalog的tables中

ResolvedCatalogTable的父接口是CatalogBaseTable，tables的类型为Map<ObjectPath, CatalogBaseTable>，所以ResolvedCatalogTable可以注册到tables

• HiveCatalog#createTable

并没有找到使用虚拟列创建HiveTable的单测HiveTableFactoryTest#testGenericTable，使所以我手动改写了一下以便查看虚拟列的create

schema的信息被组织成Map<String, String>的结构，通过hive的Table#setParameters接口持久化下来

注意这种情况下，所有的schema都维护在parameters当中，sd的columns为空

Select

Parse

parse依旧复用Calcite的，此时只认识SqlIdentifier并不会区分出ComputedColumn

Validate

首先会根据properties生成TableSchema

持有TableSchema被层层封装进RelOptTableImpl，注册到Calcite的TableNamespace

注意rowType中是包含计算列的

Convert

Flink自己处理了计算列的转换

而不是使用Calcite的虚拟列convert逻辑