hi、
我想到是一个实现方案是在flink端ddl建立lookup表的时候，一张flink表对应上面说的那个外部子查询虚拟表，相当于flink建了一个视图吧
Dream-底限 于2020年10月14日周三 下午2:23写道：
> hi、
>
> 》》你说的点查sql子表可以节省开销，不是很理解，是指同一个key关联多张维表，然后查询外部系统时一个key带出多个表的数据吗？这个应该和目前flink的实现机制不太一致。
> 是的，可以理解为用一个key查询一个视图，这个视图来自于多表关联；在不做视图的情况下，直接点查外部系统的子查询，在flink端依然是原查询样式
> 依然是：JOIN
hi、
》》你说的点查sql子表可以节省开销，不是很理解，是指同一个key关联多张维表，然后查询外部系统时一个key带出多个表的数据吗？这个应该和目前flink的实现机制不太一致。
是的，可以理解为用一个key查询一个视图，这个视图来自于多表关联；在不做视图的情况下，直接点查外部系统的子查询，在flink端依然是原查询样式 依然是：
JOIN table2 FOR SYSTEM_TIME AS OF
table1.proctime，只不过table2不再是一个物理实表，如：table2=（select
col from table）
Leonard Xu 于2020年10月13日周二
Hi,
我理解网络开销更多来自于当前的lookup实现每次都需要访问外部系统，如果能做一些cache机制，这样能省掉较多的开销。
你说的点查sql子表可以节省开销，不是很理解，是指同一个key关联多张维表，然后查询外部系统时一个key带出多个表的数据吗？这个应该和目前flink的实现机制不太一致。
> 在 2020年10月13日，10:03，Dream-底限 写道：
>
> hi、
>
hi、
现在流表查询外部维表的时候，在有多张维表的情况下会多次查询外部系统，这就导致多次网络请求回传，社区后续会不会支持时态表子查询，就是根据指定的key查询外部系统的时候不再是一次查询一个指定的表，可以点查一个sql子表，这样网络io会小一些
