Flink Streaming SQL Join

传统的离线 Batch SQL (面向有界数据集的 SQL)有三种基础的实现方式,分别是 Nested-loop Join(嵌套循环)、Sort-Merge Join 和 Hash Join

Nested-loop Join 最为简单直接,将两个数据集加载到内存,并用内嵌遍历的方式来逐个比较两个数据集内的元素是否符合 Join 条件。Nested-loop Join 虽然时间效率以及空间效率都是最低的,但胜在比较灵活适用范围广,因此其变体 BNL 常被传统数据库用作为 Join 的默认基础选项。

Sort-Merge Join 顾名思义,分为两个 Sort 和 Merge 阶段。首先将两个数据集进行分别排序,然后对两个有序数据集分别进行遍历和匹配,类似于归并排序的合并。值得注意的是,Sort-Merge 只适用于 Equi-Join(Join 条件均使用等于作为比较算子)。Sort-Merge Join 要求对两个数据集进行排序,成本很高,通常作为输入本就是有序数据集的情况下的优化方案。

Hash Join 同样分为两个阶段,首先将一个数据集转换为 Hash Table,然后遍历另外一个数据集元素并与 Hash Table 内的元素进行匹配。第一阶段和第一个数据集分别称为 build 阶段和 build table,第二个阶段和第二个数据集分别称为 probe 阶段和 probe table。Hash Join 效率较高但对空间要求较大,通常是作为 Join 其中一个表为适合放入内存的小表的情况下的优化方案。和 Sort-Merge Join 类似,Hash Join 也只适用于 Equi-Join。

相对于离线的 Join,实时 Streaming SQL(面向无界数据集的 SQL)无法缓存所有数据,因此 Sort-Merge Join 要求的对数据集进行排序基本是无法做到的.
在实时流钟,需要保存的历史数据无止境地增长,导致很不合理的内存磁盘资源占用,而且单个元素的匹配效率也会越来越低。类似的问题也存在于 Hash Join 中。

那么有没有可能设置一个缓存剔除策略,将不必要的历史数据及时清理呢?答案是肯定的,关键在于缓存剔除策略如何实现,这也是 Flink SQL 提供的三种 Join 的主要区别。

flink sql join

flink 流表join语法

SELECT [column_list]
FROM table1 [AS ]
[LEFT] JOIN table2 FOR SYSTEM_TIME AS OF table1.proctime [AS ]
ON table1.column-name1 = table2.column-name1

必须加上FOR SYSTEM_TIME AS OF table1.proctime,表示JOIN维表当前时刻所看到的每条数据。
缓存说明
connector.lookup.cache.type

指定NONE表示不需支持缓存,每次维表JOIN操作都会执行查询语句,适用于JOIN数据经常变动的场景,性能较低。

指定LRU表示使用LRU算法更替缓存数据,每次查询后若无缓存会更替缓存数据,通过max-rows和ttl设定缓存数据量和过期时间,适用于大部分场景。

指定ALL表示所有数据计算开始前全部缓存到内存中,通过ttl时间设定全量更替的频`率,适用于数据量不大可全量缓存的场景。

你可能感兴趣的:(Flink Streaming SQL Join)