文章目录
背景
大数据计算中,SQL生成的执行计划第一轮会经过固定规则的优化,第二轮会根据原计划,生成多条结合成本的的执行计划,根据cost 进行排序,选出最优的执行计划。
理论知识
原始计划如左图,
有三种执行方案
方案1,scan表1,scan表2,然后hash ,再join
方案2,scan表1,scan表2,然后broadcast 表1 ,再join
方案2,scan表1,scan表2,然后broadcast 表2 ,再join
从成本(只看行数)来看,如果表aa_user 行数远小于bb_order ,那 方案2得出来的成本就是最优的。
下面是示意图
示例
aa_user 的表行数远小于bb_order
bash
public static void main(String[] args) {
EnvironmentSettings settings = EnvironmentSettings.inBatchMode();
TableEnvironment tableEnvironment = TableEnvironment.create(settings);
Schema schema = Schema.newBuilder().column("count", DataTypes.INT()).column("word", DataTypes.STRING()).build();
Schema schema1 = Schema.newBuilder().column("id", DataTypes.INT()).column("name", DataTypes.STRING()).build();
tableEnvironment.createTemporaryTable("aa_user", TableDescriptor.forConnector("filesystem").schema(schema)
.option("path","/Users/xx/IdeaProjects/flink-demo/data/order.csv").format("csv").build());
tableEnvironment.createTemporaryTable("bb_order", TableDescriptor.forConnector("filesystem").schema(schema1)
.option("path","/Users/xx/IdeaProjects/flink-demo/data/user.csv").format("csv").build());
// tableEnvironment.executeSql("select * from aa_user").print();
//tableEnvironment.executeSql("select * from aa_user inner join bb_order on `aa_user`.`count`=`bb_order`.`id`").print();
String cost= tableEnvironment.explainSql("select * from aa_user inner join bb_order on `aa_user`.`count`=`bb_order`.`id`", ExplainDetail.ESTIMATED_COST);
System.out.println(cost);
}
结果展示
bash
== Abstract Syntax Tree ==
LogicalProject(count=[$0], word=[$1], id=[$2], name=[$3])
+- LogicalJoin(condition=[=($0, $2)], joinType=[inner])
:- LogicalTableScan(table=[[default_catalog, default_database, aa_user]])
+- LogicalTableScan(table=[[default_catalog, default_database, bb_order]])
== Optimized Physical Plan ==
NestedLoopJoin(joinType=[InnerJoin], where=[=(count, id)], select=[count, word, id, name], build=[left]): rowcount = 87.6, cumulative cost = {673.6 rows, 1484.0 cpu, 9344.0 io, 32.0 network, 40.0 memory}
:- Exchange(distribution=[broadcast]): rowcount = 2.0, cumulative cost = {4.0 rows, 320.0 cpu, 32.0 io, 32.0 network, 0.0 memory}
: +- TableSourceScan(table=[[default_catalog, default_database, aa_user]], fields=[count, word]): rowcount = 2.0, cumulative cost = {2.0 rows, 0.0 cpu, 32.0 io, 0.0 network, 0.0 memory}
+- TableSourceScan(table=[[default_catalog, default_database, bb_order]], fields=[id, name]): rowcount = 582.0, cumulative cost = {582.0 rows, 0.0 cpu, 9312.0 io, 0.0 network, 0.0 memory}
== Optimized Execution Plan ==
MultipleInput(readOrder=[0,1], members=[\nNestedLoopJoin(joinType=[InnerJoin], where=[(count = id)], select=[count, word, id, name], build=[left])\n:- [#1] Exchange(distribution=[broadcast])\n+- [#2] TableSourceScan(table=[[default_catalog, default_database, bb_order]], fields=[id, name])\n])
:- Exchange(distribution=[broadcast])
: +- TableSourceScan(table=[[default_catalog, default_database, aa_user]], fields=[count, word])
+- TableSourceScan(table=[[default_catalog, default_database, bb_order]], fields=[id, name])
结果解释
NestedLoopJoin:Flink 选择了嵌套循环连接(Nested Loop Join)作为执行 JOIN 的策略,使用 count = id 作为连接条件。
Exchange(distribution=[broadcast]):表示将 aa_user 表的数据广播分发,以减少数据移动的开销,rowcount = 2.0 表示预估的行数。
TableSourceScan:直接扫描表 aa_user 和 bb_order,并读取相应的字段。表 aa_user 预估有 2 行,表 bb_order 预估有 582 行