實時計算既有Flink，為何又推出個StreamPark？

StreamPark 2.0.0 版本於2023年2月21日正式釋出，有流處理需求的開發者可以透過StreamPark官網以及GitHub去下載。StreamPark這次更新的亮點是，前端構建和啟動速度同歷史版本比提升了 5~10 倍，並且對 Apache Flink 做了更好的支援，支援最新的 Flink 1.16版，同時Flink 作業 on Kubernetes 達到生產可用級別。

在瞭解StreamPark 2.0.0 版本具體更新了哪些內容前，我們先來腦補下定義，到底是什麼StreamPark ?Flink本身就是一個開源流處理框架，為何StreamPark會成為Apache重點孵化的專案?二者到底是什麼關係?

讓流處理更簡單

從官方定義看，StreamPark 是一個流處理應用開發管理框架。基於StreamPark，開發者可以輕鬆構建和管理流處理應用程式，更好地使用Apache Flink 和 Apache Spark 編寫流處理應用程式的開發框架，同時可支援更多其他引擎。StreamPark最早叫做StreamX，於2021年4月正式開源;2022年2月24日，StreamPark釋出1.2.2首個穩定版;2022年8月更名為StreamPark。

大體來看，StreamPark是一個位居Flink 之上的開發管理平臺，有了StreamPark，使用者可以無障礙地擁抱Flink ，更快地構建實時數倉和流式數倉，相當於是一個流處理應用的服務匯流排。

當然，StreamPark的核心能力可能會更多，包括但不限於應用開發、除錯、互動查詢、部署、運維、實時數倉等，比如：除了標準配置和開發流程，還有Flink SQL開發工作臺、一站式流任務開發管理平臺的內嵌，多版本流引擎的支援，多叢集環境的支援等等。

有效解決Flink on Kubernetes太重的問題

StreamPark之所以成為開源社群關注的重點專案，除了細節上更新，比如：提供了Docker 方式一鍵部署啟動 StreamPark ，支援了透過 copy 已有的作業來快速建立一個新的作業，更大程度地提升了 StreamPark 的易用性……還有一個關鍵性的使用者體驗，那就是Flink on Kubernetes實現生產級別的構建。

當企業決定使用Flink做資料引擎時，通常會使用Flink on Kubernetes模式做實時任務流管理。但Flink沒有解決一個問題，那就是每提交一個任務，需要打包新的映象提交到私有倉庫，然後再呼叫Flink Run指令拉通Kubernetes，最終獲取映象執行Pod，任務提交後還要去Kubernetes查log，映象流程太長。如果單純地使用命令去提交每個任務，任務量太大，增加了開發的壓力。如何解決Flink原生映象需要二次構建的問題?StreamPark可以讓Flink的構建、測試和部署變得更自動化!

在StreamPark 2.0.0 版本中，修復了諸多Bug，可支援檢視 Kubernetes 部署模式下的實時日誌，重構了作業執行狀態這部分的實現。目前，在作業部署提交、執行狀態等各個方面已做了大量的測試，整體穩定性和可用性也經過企業大量作業的驗證，能達到生產可用級別。

值得一提的是，StreamPark為了提升易用性，在新版本中從強依賴MySQL擴充套件了新的資料庫型別，包括H2和PostgreSQL。其中，系統預設使用H2，對於想要快速體驗的使用者來說，直接下載安裝包、執行啟動指令碼啟動服務即可，無需其他額外配置和操作就可以體驗 StreamPark 帶來的方便與快捷，並且有效降低了使用成本。