前言
又是一個超長的標題（攤手┓( ′?` )┏）。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更好的服務。
