Spark学习笔记（20）Spark Streaming中动态Batch Size实现初探

本期内容：
1. Batch Duration与Process Time
2. 动态Batch Size

　　不要低估Batch Duration与Process Time匹配的问题。两者关系不是线性规律。不是数据量大，就简单加大Batch Duration来解决问题。前面推荐的论文很重要。参加定制班，不是简单学编程，要懂得设计思想。

　　我们看论文是怎么实现动态Batch Size。

　　现代数据处理的应用中，流进来的数据越来越大，所以采取分布式的流处理技术。要判断各个算子、各种负载是否是预期中的。某单位时间内，往往数据很大到，不便于存储，单台机器不能及时处理完。大数据公司往往要对当下的新数据进行分析判断以获得最新的信息。一切媒体都不能抗拒媒体完全实时性的潮流趋势，否则会被淘汰。
　　传统的单台机器处理方式不能适应需求，分布式流处理绝对是一个有前途的技术方向之一。

　　目前的大数据处理框架主要是一系列在接收数据上的MapReduce风格的批处理。其中一种处理方式是动态的调整资源（内存、CPU等）。也有丢弃数据的方式，但在一些情况下不允许。如何应对现实中突发场景的变化？资源不会是随数据增大而同倍增大。其实如果足够快，就什么问题都没有。比如处理足够快，就不会丢数据，就不需要临时保存。

　　这个论文的一个观点是要尽量把batch变小。越小，则越快，也就越安全。任何事物只要足够快，就可以屏蔽掉所有问题。
　　Heron推出的原因是应对波峰的处理方式需要从设计上去改变。Storm虽然已不错，但在架构上不能满足越来越大的业务需求。

　　谈到了什么因素导致延迟。接收数据并放入队列、等待时间、处理时间...都是delay。

　　坐标图中，虚线隔离出安全、非安全区域。例如Join的处理，单位时间批处理量大的处理，随着时间的推移，会先变得不安全：处理延迟会陡增。

　　静态模型的办法，处理能力确实会很有限。很难预测行为。要设计一个算法，调整batch的大小。
　　要对信息进行统计，下一次处理之前要看上一次的统计信息，已决定如何调整。其实不那么简单。
　　实现动态的Batch Size的方案是固定点迭代（Fixed-point Iteration）。算法实现再拿一节课深入分析。

　　高手应该是搞思想和理论研究的。不要停留在工程级别。多有想法。