本文主要是指spark+kafka，不包括flink。
摘要
1.spark streaming有限速（max rate），有反压(back pressure)。
2.structured streaming没有反压，只有限速。
1.为什么要限速和反压
一个spark集群，资源总是有限。如果一个处理周期接收过多的数据，造成周期内数据处理不完，就会造成executor OOM等问题。相反地，如果一个处理周期接收的数据过少，则会造成资源的浪费，以及kafka消息的堆积。
所以合理的限速和反压显得非常重要。
如果集群资源不够大，流应用程序不能以接收数据的速度处理数据，接收端可以通过设置最大速率限制以记录/秒为单位来限制速率。在Spark 1.5中，我们引入了一个称为背压的功能，它消除了设置速率限制的需要，因为Spark Streaming会自动计算出速率限制，并在处理条件改变时动态调整它们。这个反压力可以通过设置配置参数spark.streaming.backpressure.enabled为true来启用。
2.spark streaming
2.1限速
spark streaing连接kafka分为两种方式。
2.1.1.recive方式
此方式可以通过设置spark.streaming.receiver.maxRate参数
Maximum rate (number of records per second) at which each receiver will receive data. Effectively, each stream will consume at most this number of records per second. Setting this configuration to 0 or a negative number will put no limit on the rate.
可通过此参数控制receiver每秒接收的数据量。此参数值须大于0，如果小于0将视为不限制。
2.1.2.direct方式
此方式可以通spark.streaming.kafka.maxRatePerPartition参数来控制速率。
Maximum rate (number of records per second) at which data will be read from each Kafka partition when using the new Kafka direct stream API.
1.direct方式应通过spark.streaming.kafka.maxRatePerPartition方式来控制速率。2。此方式意为每秒每个分区接收的数据量。
2.2反压
从spark1.5开始引入了反压的概念。它通过设置spark.streaming.backpressure.enabled参数=true/false来实现。
Enables or disables Spark Streaming's internal backpressure mechanism (since 1.5). This enables the Spark Streaming to control the receiving rate based on the current batch scheduling delays and processing times so that the system receives only as fast as the system can process. Internally, this dynamically sets the maximum receiving rate of receivers. This rate is upper bounded by the values spark.streaming.receiver.maxRate and spark.streaming.kafka.maxRatePerPartition if they are set (see below).
1.backpressure可以动态的决定当前批次处理的数据量。由系统根据当前批次的延迟和处理时间决定。
2.backpressure应和maxRate/maxRatePerPartition 配合使用。后两个参数将决定backpressure下每个批次处理数据量的上限。
2.3反压的启动问题
前面讲到反压spark.streaming.backpressure.enabled参数应与spark.streaming.receiver.maxRate and spark.streaming.kafka.maxRatePerPartition一起使用，但也不是必须。如果没有设置后两个参数，在kafka有大量消息积压的时候，首次启动backpressure并不会生效，那么还是会将全部消息拉取到集群中，如果资源不够，将再次撑爆资源。
那么在这种情况下，还可以设置以下参数：
spark.streaming.backpressure.initialRate
开始反应时的初次速率。
为什么会有这个参数的存在，是因为反压的工作原理，是根据上一次批次处理数据的时间以及延迟来决定将要向上游拉取数据的量。在初次启动时，并没有上一次的数据可供参考，这时反压并不生效。
所以启动反压spark.streaming.backpressure.enabled时，必须与spark.streaming.backpressure.initialRate或者(spark.streaming.receiver.maxRate /spark.streaming.kafka.maxRatePerPartition)绑定使用。
3.structured streaming
3.1 structured streaming目前为止没有反压机制，要控制当前批次的速率，只有通过参数maxOffsetsPerTrigger.
Rate limit on maximum number of offsets processed per trigger interval. The specified total number of offsets will be proportionally split across topicPartitions of different volume.
每个trigger处理数据的最大值，将均匀从各个kafka 分区拉取数据。
4.比较
限制速率与反压孰优孰劣呢
1.限制速率需要去事先估算资源和数据量，不一定准确，如果误差较大，需重启任务。
2.设置一个死的速率，在低峰时，如凌晨，会造成资源浪费（这个时候正处在离线任务处理高峰期）；在高峰时，固然会有削峰的效果，但是也造成了数据的延迟，在一些实时性比较高的情况下，不是一个好的选择。
3.反压应该是一个比较好的选择。特别是搭配上资源动态分配时，在凌晨能释放不少资源。
5.structured streaming 为什么不/不能使用反压？
既然反压机制明显优于限制速率，而structured streaming又优于spark streaming的情况下，structured streaming反而没有设置背压机制呢？
个人观点，是因为structured streaming接收kafka的方式是类似于receiver的方式，而非direct。所以只能限制整体数量，而无法限制分区的数量，更无法做反压。
There are not receiver-based sources in Structured Streaming, so that's totally not necessary. From another point of view, Structured Streaming cannot do real backpressure, because, such as, Spark cannot tell other applications to slow down the speed of pushing data into Kafka.
参考资料
https://spark.apache.org/docs/1.6.3/configuration.html#spark-streaming
https://spark.apache.org/docs/2.3.0/structured-streaming-kafka-integration.html
https://stackoverflow.com/questions/44871621/how-spark-structured-streaming-handles-backpressure