目前使用streampark开发的场景中90%以上需求都是表的打宽需求。使用flink sql的join完成需求开发有很多缺点。如下： a.regular join 核心问题是state还会持续增大，占用大量内存，故障恢复时间长。 b.interval join 核心问题需要业上有明确的过期时间否则就又变成了regular join。 c.temporal join 核心问题是只能监测一个流表的变化。

导致做flink表的打宽任务需要成熟的flink开发人员来完成，对业务数据的大小和变更延迟等有足够的了解才能完成开发任务。flink sql开发打宽需求和离线业务开发打宽需求相比开发效率相差较大，稳定性也比较差。

streampark 可以做一个开发成本接近离线开发效率的一种打宽开发模块。这里我们先称作widetable模块。给flink 开发人员甚至产品、分析师、数仓、普通开发人员提供一种更高效、更稳定的开发方式，来实时打宽需求的开发工作。

widetable 实现的架构图：

交互层：

开启widetable打宽的方式可以有两种： a.产品可以拖拽的方式完成宽表的开发。 b.数仓、分析师、不同业务开发可以写一个hive sql就可以完成宽表的开发。

解析层：

功过解析用户的输入生成flink 任务完成flink

部署层：

使用streampark 部署模块完成flink 任务的部署，部署到k8s或yarn上。

中间件和存储层：

这部分会在后面的实时打宽逻辑图中有所体现。

数据打宽实现逻辑图：

设计核心思路：

扩展temporal join，使temporal join能够监测所有维表的变化进行打宽。带来好处是数据状态外置，开发再也不用关心状态过大问题、数据的先后顺序等问题。而且数变化打宽延是在1秒内，不再需要担心业务上的时效要求不能满足的问题。