在过去的5个月里，Apache Flink社区一直在努力处理超过780个问题。Flink社区没有将流解决看作是构建快速连续数据管道的更快分析和更加条理化的方式，而是构建数据驱动和数据密集型应使用程序的范例，并将数据解决逻辑和应使用程序/业务逻辑集成。

Flink背后的团队旨在让这个平台满足进行数据工程/数据解决的使用户，以及构建数据/事件驱动应使用程序的使用户，当然还有那些在应使用程序中将这两个方面结合在一起的使用户感觉自然。

重新部署和解决的流程模型：额外支持动态资源分配和动态释放YARN和Mesos调度器上的资源，以提高资源利使用率，故障恢复以及动态扩展。此外，此功能为Flink与Kubernetes集成的未来改进奠定了基础。

支持广播状态：常规流的解决由控制流的消息配置。通过将规则或者模式广播到函数的所有并行实例，它们可以应使用于常规流的所有事件。

改进的网络堆栈：在流解决环境中，两个性能指标非常重要：推迟和吞吐量。Flink 1.5改进了网络堆栈，基于信誉的流量控制并改善了传输推迟。基于信誉的流量控制将“on the wire”上的数据量降至最低，同时保持高吞吐量。

Task-local状态恢复：Task-local状态恢复利使用作业通常因为单个崩溃的operator，TaskManager或者机器而失败的事实。在将operator的状态写入远程存储器时，Flink现在也可以在每台机器的本地磁盘上保留一份副本。在故障转移的情况下，调度程序会尝试将任务重新安排到其以前的计算机，并从本地磁盘而不是远程存储装载状态，从而加快恢复速度。

SQL和表API的扩展连接支持： Flink 1.5添加了对窗口化外部Equi连接的支持。对于不应在有限时间间隔内连接两个流表的情况，Flink SQL现在还支持非窗口式内部连接。这可以实现全历史匹配，这在许多标准SQL语句中很常见。