flink 多个 stream的join处理实现

多个stream的join的难点主要在于以下的几个地方的：
1.多个stream在时间上无法保证数据的到达问题的，很可能会出现相关联的多个stream的话，一个到达了，一个还没有达到的情况的，这种情况下应该怎么处理？我们经常需要一个数据的兜底方案来保证这种操作的。
怎么解决这种多个stream数据的停留问题的。这个过程中，我们必须要有其他的补偿的方案来解决这个问题的。否则对应的数据会形成不消费处理的情况的，对于整体的分析和处理，这种情况肯定是不允许的情况的。
解决方案可以有如下的集中方案：
1）使用redis缓存数据，这个对于少量数据的处理是可以接受的；
建信金科对应的第一个版本就是使用redis完成对应的数据的中间数据的存储的，但是随着数据量的增大的话，后续需要维护redis的代码以及给予redis很高的维护压力和内存扩充压力，redis本身的并发支撑能力还不是很高的。
2）使用侧向输出流，将未处理的数据收集起来，输出到对应的存储中，后续进行这部分数据的处理操作和实现；这个会增加后续的流程处理，不建议这么做的。后续需要维护多个数据的。
3)使用hbase或者是其他的工具，进行及时的数据查询和处理，这个可以利用即席查询的功能实现。
4）数据一开始就导入到hudi等数据湖中，后续的操作可以直接使用数据湖的实时查询和对应的存储来满足要求，相当于方案二以及方案三的一种组合的方式来综合实施起来的操作的。也是我认为的最完善的一种技术解决方案的。
5）多个stream进行join操作的时候，自己来管理state的数据的。可以自己来管理数据的，当数据来的话，执行join操作处理的，数据没有来的话，对应的存储在state中来进行保存即可的。后续的话，等到某一部分的数据来的话，可以直接从state中删除相关的数据的，从而实现自动的state的数据的管理的。这个方案我认为是处理state的一个比较好的方案的。
2.多个stream处理的时候，异常问题的排查和分析，怎么知道对应的是哪个stream的数据出现了问题？这个机制需要怎么来实现和分析。特别是对于实时的数据而言，异常数据的排查和分析会比较的艰难，当存在多个stream进行连接实现的话，这种怎么来保证相关问题的解决，是一个难点问题的。
现在可能比较好的一种方式是实时收集异常信息进行存储，后续查询相关的异常信息来进行事后分析操作，但是这种不是一个很完善的技术解决方案的。