实时计算既有Flink，为何又推出个StreamPark？

StreamPark 2.0.0 版本于2023年2月21日正式发布，有流处理需求的开发者可以通过StreamPark官网以及GitHub去下载apache配置。StreamPark这次更新的亮点是，前端构建和启动速度同历史版本比提升了 5~10 倍，并且对 Apache Flink 做了更好的支持，支持最新的 Flink 1.16版，同时Flink 作业 on Kubernetes 达到生产可用级别。

在了解StreamPark 2.0.0 版本具体更新了哪些内容前apache配置，我们先来脑补下定义，到底是什么StreamPark ?Flink本身就是一个开源流处理框架，为何StreamPark会成为Apache重点孵化的项目？二者到底是什么关系？

让流处理更简单

从官方定义看，StreamPark 是一个流处理应用开发管理框架apache配置。基于StreamPark，开发者可以轻松构建和管理流处理应用程序，更好地使用Apache Flink 和 Apache Spark 编写流处理应用程序的开发框架，同时可支持更多其他引擎。StreamPark最早叫做StreamX，于2021年4月正式开源；2022年2月24日，StreamPark发布1.2.2首个稳定版；2022年8月更名为StreamPark。

大体来看，StreamPark是一个位居Flink 之上的开发管理平台，有了StreamPark，用户可以无障碍地拥抱Flink ，更快地构建实时数仓和流式数仓，相当于是一个流处理应用的服务总线apache配置。

当然，StreamPark的核心能力可能会更多，包括但不限于应用开发、调试、交互查询、部署、运维、实时数仓等，比如：除了标准配置和开发流程，还有Flink SQL开发工作台、一站式流任务开发管理平台的内嵌，多版本流引擎的支持，多集群环境的支持等等apache配置。

有效解决Flink on Kubernetes太重的问题

StreamPark之所以成为开源社区关注的重点项目，除了细节上更新，比如：提供了Docker 方式一键部署启动 StreamPark ，支持了通过 copy 已有的作业来快速创建一个新的作业，更大程度地提升了 StreamPark 的易用性……还有一个关键性的用户体验，那就是Flink on Kubernetes实现生产级别的构建apache配置。

当企业决定使用Flink做数据引擎时，通常会使用Flink on Kubernetes模式做实时任务流管理apache配置。但Flink没有解决一个问题，那就是每提交一个任务，需要打包新的镜像提交到私有仓库，然后再调用Flink Run指令拉通Kubernetes，最终获取镜像运行Pod，任务提交后还要去Kubernetes查log，镜像流程太长。如果单纯地使用命令去提交每个任务，任务量太大，增加了开发的压力。如何解决Flink原生镜像需要二次构建的问题？StreamPark可以让Flink的构建、测试和部署变得更自动化！

在StreamPark 2.0.0 版本中，修复了诸多Bug，可支持查看 Kubernetes 部署模式下的实时日志，重构了作业运行状态这部分的实现apache配置。目前，在作业部署提交、运行状态等各个方面已做了大量的测试，整体稳定性和可用性也经过企业大量作业的验证，能达到生产可用级别。

值得一提的是，StreamPark为了提升易用性，在新版本中从强依赖MySQL扩展了新的数据库类型，包括H2和PostgreSQLapache配置。其中，系统默认使用H2，对于想要快速体验的用户来说，直接下载安装包、执行启动脚本启动服务即可，无需其他额外配置和操作就可以体验 StreamPark 带来的方便与快捷，并且有效降低了使用成本。