前言
又是一個超長的标題（攤手┓( ´∀` )┏）。Spark Streaming 曆史比較悠久，也确實非常好用，更重要的是，大家已經用熟了，有的還做了不少工具了，是以覺得這東西特别好了，不會像一開始各種吐槽了。反倒是Structured Streaming， 吐槽點比較多，但是到目前，我們經過一番實踐，覺得是時候丢掉Spark Streaming 更新到Structured Streaming了。
更新問題
你看，DB公司已經沒怎麼對Spark Streaming做更新了。
API統一
DStream 和 RDD 看起來很相似，但其實是兩個不同的東西，DStream是對RDD在流式計算的裡的Wrap。是以流式和批處理，你其實比較難複用的。但是在Structured Streaming中，都是對Dataframe的操作，複雜邏輯處理會很容易的在批處理和流式計算中複用。
支援實時流式
Structured Streaming 已經在2.3.0中支援實時流式，潛力可見一斑了。一行代碼就可以讓原來的微批流轉化為實時流。
同一執行個體多流支援
以前我一直希望啟動一個spark streaming程式，然後可以動态添加或者删減流，但是在Spark Streaming中，API層次就不允許你這麼做。你需要自己重新去封裝一套，并且适當的對Kafka那側做些調整才能達到訴求。而在Structured Streaming中，天生就是多流的管理的。你可以随時停止一個流，啟動一個新流，通過API擷取流的狀态，所有這些，都讓流成為Service 變得很容易。StreamingPro實作了流式服務，你可以送出新的流，管理已有的流，參考着mlsql-stream。
更好的限制
Structured Streaming 是面向Dataframe(表)的，合适的限制會讓代碼更易于閱讀，并且保持更好的運作效率。今天，我們發現，table,sql都是大資料裡不可或缺的概念，Structured Streaming 則是更傾向這些概念，而Spark Streaming還是一個面向RDD的東西。
更好的中繼資料管理
我想大家都有自己的offset管理（在Spark Streaming）裡，大家的做法五花八門,缺乏标準，Spark Streaming的實作則是一種腦殘式實作。在Structured Streaming，這個問題得到了更好的解決。
對流站在一個更高的抽象層次上
Spark Streaming一切都在于你自己的代碼，而Structured Streaming則為你做了更好的抽象。比如如果結果集不大，那麼用complete模式可以保證在一些常見存儲中全量覆寫寫而實作exactly-once。而wartermark等概念則更是流式計算中常見的訴求。Structured Streaming是站在對流站在一個更好的抽象層次上讓你使用的，enjoy它吧。
一些實踐問題
比如這個Structured Streaming如何實作Parquet存儲目錄按時間分區，還有就是監控，可能不能複用以前Spark Streaming那套機制了。
結束語
是時候丢掉Spark Streaming 更新到Structured Streaming了，讓我們享受DB更好的服務。