是时候丢掉Spark Streaming 升级到Structured Streaming了

前言

又是一个超长的标题（摊手┓( ´∀` )┏）。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更好的服务。