// 假如topic就一张表，不必区别，假如多张表，能够经过database 与 table 区别，放到下一步去处理

　　// 假如topic就一张表，不必区别，假如多张表，能够经过database 与 table 区别，放到下一步去处理

　　思维：先去状况去取，假如没有，去外部查询，一起去存到状况里边。StateTtlConfig 的过期时刻能够设置短点。

　　缺陷：也不能一了百了处理某些问题，热备数据过多，【重视尚硅谷，轻松学IT】或许冷数据过大，都会对state 或许 外部数据库形成压力。

　　// 数据处理，过来一条条数据，然后依照自己的事务逻辑先去mapState去找，假如没有再去 外部去找

　　比方上面说到的字典表，每一个Task都需求这份数据，那么需求join这份数据的时分就能够运用播送维表。

　　「考虑:」假如把维表流也经过实时监控binlog到kafka，当维度数据发生改变时，更新放到状况中，这种方法，是不是更具有时效性呢？

　　由于维表是一张不断改变的表（静态表仅仅动态表的一种特例）。那怎么 JOIN 一张不断改变的表呢？假如用传统的 JOIN 语法来表达维表 JOIN，是不完整的。由于维表是一向在更新改变的，假如用这个语法那么相关上的是哪个时刻的维表呢？【重视尚硅谷，轻松学IT】咱们是不知道的，结果是不确定的。所以 Flink SQL 的维表 JOIN 语法引入了Temporal Table 的标准语法，用来声明相关的是维表哪个时刻的快照。

　　一般相关会一向保存相关双侧的数据，数据也就会一向胀大，直到撑爆内存导致使命失利，Temporal Join则能够定时整理过期数据，在合理的内存装备下即可防止内存溢出。

　　运用事情时刻特点（即行时刻特点），能够检索曩昔某个时刻点的键值。这答应在一个一起的时刻点衔接两个表。

　　假定咱们有一个订单表，每个订单都有不同钱银的价格。为了将此表正确地标准化为单一钱银，每个订单都需求与下订单时的恰当钱银兑换率相结合。

　　依据界说，运用processing-time特点，衔接将一直回来给定键的最新值。能够将查找表看作是一个简略的HashMap，它存储来自构建端的一切记载。这种衔接的强壮之处在于，当在Flink中无法将表详细化为动态表时，它答应Flink直接针对外部体系作业。

　　Lookup Join 一般用于经过衔接外部表（维度表）弥补信息，要求一个表具有处理时刻特点，另一个表使 Lookup Source Connector。

　　四种join方法不存在肯定的一了百了，更多的是针对事务场景在各指标上的权衡取舍，因而看官需求结合场景来挑选合适的。