16 | Spark Streaming：Spark的实时流计算API

老师，Spark团队对Spark streaming更新越来越少，Spark streaming存在使用Processing time 而非 Event time，批流代码不统一等问题，而Structured streaming对这些都有一定改进。所以Structure streaming 会替代Spark streaming或者Flink，成为主流的流计算引擎吗？

没用过spark streaming, 用storm比较多。 觉得流处理关键在于要在窗口内尽快地把到来的数据处理完，不要造成数据堆积，内存溢出。 其中牵涉到了如何高效地接受数据，如何并行尽快地处理数据。 觉得优化可以从：接受输入，处理算法，处理单元数量，GC调优等方面入手吧。 有个问题，对于RDD如果transform链很长，感觉是否会对性能造成一定影响，特别是流式或者图形计算？老师能否解答一下。 谢谢！

批处理可以选择spark；流处理：spark stream，storm，Flink；还有现在大统一的beam 请问：这些技术都要学一遍吗？精力放在哪个技术上？ 如果我是初学者，我能直接学beam其它都不学吗？

上一条留言没有说完。 spark streaming 需要设置 batch time 是多少，这决定时效性，以及调度的 overhead，另外要看自己需要的吞吐多大，并发是不是有特殊需求。 spark streaming 有几个点不太喜欢，修改业务逻辑后，需要删除 checkpoint 才行，这会导致从头计算；慢节点没法解决，当一个 batch 里面有一个节点很难的时候，整个 batch 都无法完成。 一个反常识的点：实时 etl 同样吞吐下，flink 比 spark streaming 更节省资源。 另外官方已经放弃 spark streaming，转向structured streaming，但是从邮件列表看又没有 commiter 在管，导致 pr 没人 review，或许这和 spark 整体的重心或者方向有关吧

既然DStream底层还是RDD，那我认为针对RDD的一些优化策略对DStream也有效。比如平衡RDD分区减少数据倾斜，在tranformation链中优先使用filter/select/first减少数据量，尽量串接窄依赖函数方便实现节点间并行计算和单节点链式计算优化，join时优化分区或使用broadcast减少stage间shuffle。 另外专门针对流数据的处理，个人经验上主要是要根据业务需求微调window length和sliding interval以达到吞吐量和延时之间的一个最优平衡，时间窗口越大，一个RDD可以一次批处理的数据就越多，Spark的优势就可以发挥出来，吞吐量就上去了。而滑动间隔越大，windowed DStream在固定时间内的RDD就越少，系统的任务队列里同时需要处理的计算当然就越少，不过这两个调整都会加大数据更新延迟和牺牲数据实时性，所以说要根据业务真实需求谨慎调整。 不过个人理解RDD里面用来避免重复计算的cache和persist无法用来减少窗口滑动产生的重复计算，因为窗口每滑动一次，都产生一个新的RDD，而persist只针对其中某个RDD进行缓存，在RDD这种low level api里面，应该是无法知道下个窗口中的RDD和现在的RDD到底有多少数据是重叠的。对于这点理解是否正确望老师解答！

优化的定义很广，不知道在这个领域大家提到这个词主要指的是什么？望解答 不过，对具体实现细节不了解的情况下有几个猜测： 我会改变时间粒度，来减少RDD本身带来的开销，上文的例子里时间粒度如果设置成10秒应该逻辑上也是可行的。 另外，我大概会考虑多使用persist来减少因为窗口滑动产生的重复计算。

在满足需求的情况下尽可能的使用更宽的窗口长度，减少rdd的处理链

稳定性：对于7*24小时的流式任务至关重要 低延迟高吞吐量

嗨，有人吗？第三行代码应该是ssc： lines = ssc.socketTextStream("localhost", 9999) ？？

sc和ssc的区别是什么？我理解ssc才是那个streamingContext吧，如果是这样，那么又出现错误了。