Spark Streaming揭秘 Day20

动态Batch size实现初探(上)

今天开始，主要是通过对动态Batch size调整的论文的解析，来进一步了解SparkStreaming的处理机制，因为比较偏理论，么有代码演示。

缘起

从目前的业务发展来看，线上处理目前来看已经越来越重要，而一个突出的矛盾就是，传统框架Oracle+j2ee的框架下，存在一个致命的问题，就是无法突破单台机器的局限，可能容纳此刻流入的数据，于是分布式流处理程序越来越火热。

流处理的核心是追求更快的处理速度。但是以目前的技术现状来看，还无法达到最快，所以容错问题也非常的重要。目前主流的框架，都会使用MapReduce思想对流入的数据不断进行处理，MapReduce最大的优势是在于自身带有完备的容错机制。

挑战

流处理系统最大的挑战是在于，可能会面对突然来临的波峰，流处理系统必须能应对这种情况。

过去的系统的解决方式：

1. 丢弃数据：只能在一些特殊场景使用，对业务会有影响。

2. 动态调整资源：很多时候，资源和数据的增长不是线性关系，很难根据数据的趋势来调整资源。

在SparkStreaming中，使用了第三种方案，就是动态调整Batch size。

一般来说，Batch size越小就越快，越快就越安全，低延时是首要的目标。

但在指定时间窗口限制下，对于Batch size调整幅度来说，是一个很综合的课题，数据量是一个方面，计算内部的算子也是非常重要的方面，某些算子下在数据量规模大的情况下，Batch Duration和延时之间的关系会很复杂。

从Join的时间曲线可以看到，当数据流速增加到2.4MB/s时，处理速度恶化明显加快，而在Reduce中，表现完全不同。

算法要求

如何调整，需要一个算法的支持。

因为不同的算子下，处理延时并不是呈现线性规律，随着吞吐量的变化，很难用静态模型预测实际情况的。

对于这个算求在要求拥有更低的延时的同时，必须能能适配不同算子带来的变化。

同时，在设计时还需要有一些其他的难点考虑：

1. 能对workload的非线性表现进行适配。
2. 能消除干扰因素影响。
3. 能平衡计算精确性和灵活性之间的矛盾。

具体算法，我们将在明天展开。

欲知后事如何，且听下回分解

DT大数据每天晚上20：00YY频道现场授课频道68917580