第20课：Spark Streaming中动态Batch Size实现初探
1 Batch duration 与Process Time
2 动态Batch size
Spark Streaming中有很多算子，每一个算子不会呈现线性规律， Batch duration处理数据越大，时间不会线性增长。
数据量大，不是加大Batch duration就能解决问题。
一切终端一切媒体都会变成实时交互性分布式流处理的媒体。
一年前看的一篇英文paper，收获很大，学习很多思路，会对流处理有很深刻的认识。
Adaptive Stream Processing using Dynamic Batch Sizing
Tathagata Das University of California Berkeley
Yuan Zhong Columbia University
Ion Stoica Scott Shenker University of California Berkeley
应liuhui_306 读者的要求，补充了部分内容；
Adaptive Stream Processing using Dynamic Batch Sizing论文思想博大精深，先窥其一二，在以后的学习中再逐步深入了。
这个论文的一个观点是要尽量把batch变小。越小，则越快，也就越安全。任何事物只要足够快，就可以屏蔽掉所有问题。
但在指定时间窗口限制下，对于Batch size调整幅度来说，是一个很综合的课题，数据量是一个方面，计算内部的算子也是非常重要的方面，某些算子下在数据量规模大的情况下，Batch Duration和延时之间的关系会很复杂。如图：
如果流处理系统对接收到的数据进行快速处理，批量处理时间不超过批处理间隔，在下一批数据到达之前，每个批处理都能完全处理完，这样，流处理的工作负载可以是稳定的。如流处理中数据处理失败，导致建立批量队列，处理时间随着时间的增加而增加，这样会意味着更多的数据要处理，而需要更高的处理时间。流处理时间和间隔时间表现为非线性的关系。
从图中我们看到对角线是流处理的一个稳定状态线（批处理时间=批间隔时间），批处理时间低于批间隔时间，意味着能对接受的数据快速处理，流处理就是稳定的，反之亦然。reduce操作在不同的数据吞吐速率1Mb/S，3MB/s，6MB/s，流处理能稳定处理。而Join操作涉及两个数据集，可能会产生O（M，N）条记录，shuffle操作对两个数据集操作可能需更高的处理时间，而带来不稳定。如join时候0.8MB/S，1.6MB/S还可以处理，2.4MB/S的数据吞吐率时，流处理可能来不及处理数据。
右边的两个图看出，reduce算子操作时候，批处理速率可以稳定增长，而join操作批处理速率上升到5MB/S时，来不及处理反而急速下降了，降至2MB/s的流处理速率。
论文中提到的详细场景如下：
第四张图有点特别，基于window的时间窗口的算子操作，随着批间隔时间的增加，小批量的数据处理，流处理时间呈下降。