SparkStreaming中定义了DStream这个概念。每个DStream由一系列的的RDD组成。官方文档如下：
Internally, a DStream is represented by a continuous series of RDDs, which is Spark’s abstraction of an immutable, distributed dataset. Each RDD in a DStream contains data from a certain interval, as shown in the following figure.
但是文档上并没有提及每个RDD对应的时间周期是多少。我问了许多人，都认为这个时间周期对应了一个DStream的duration。比如，有如下的代码创建了一个JavaDStream，那么其RDD对应的时间周期应该是10秒：
SparkConf conf = new SparkConf().setAppName("StreamingWindow");
JavaStreamingContext jssc = new JavaStreamingContext(conf, Durations.seconds(10));
JavaReceiverInputDStream<String> lines = jssc.socketTextStream(args[0],
Integer.parseInt(args[1]), StorageLevel.MEMORY_AND_DISK_SER());
JavaDStream<String> words = lines.flatMap(new FlatMapFunction<String, String>() {
@Override
public Iterable<String> call(String s) throws Exception {
return Lists.newArrayList(SPACE.split(s));
}
})；当然只可能是10秒，否则也找不到其他设置RDD周期的地方。可是这种解释终究难以让人信服，只好深入SparkStreaming的源码来看一下了。顺着JavaDStream的继承关系一路找上去，其最终的基类是DStream。在最开始的类描述和类定义就有最关键的信息：
原来RDD所对应的时间周期是一个名为slideDuration的函数所返回的。这个函数在基类中没有定义，那么我继续往子类里找。很快，我就在InputStream里找到了这个函数的定义，如下：
这下就真相大白了，来自于ssc.graph.batchDuration。再继续查看StreammingContext，果然，graph函数里的batchDuration来自于构造函数里的Duration，这与先前的猜测一致。也就是说，SparkStreaming的每个Duration对应了一个RDD。完整的关系图如下：
所以，DStream的每个RDD的时间跨度都是StreamingContext的_batchDur？如果你真这么想，那就大错特错了！从Spark的代码风格就可以看出来，开发者们是很严谨的人。再仔细看看DStream里的那个函数名，叫slideDuration – 滑动周期，而StreamingContext里的变量名叫_batchDur – 批处理周期。如果二者代表的意义一样，为什么要弄两个名字呢？
滑动周期？是不是很熟悉？You got it！于是我又看了下WindowedDStream，于是真的真相大白了：
然后再看看DStream的window函数：
DStream有两个window函数，用来创建窗口。每个窗口有两个变量：窗口大小和滑动周期。在第一个函数中，窗口大小通过参数指定，滑动周期来自于调用函数的DStream（如果这个DStream是由StreamingContext直接创建的，那么滑动周期刚好等于批处理周期）。在第二个函数中，窗口大小和滑动周期都是通过函数指定。
然而，在WindowedDStream中，它的slideDuration函数返回的是这个窗口的滑动周期。也就是说，每个滑动窗口才对应着一个RDD，而不是一个批处理周期对应一个RDD。
逻辑可以很复杂，也可以很简单，最终二者是可以统一的：
1. 所有的DStream都可以看作是WindowedDStream
2. 每个窗口都有窗口大小和滑动周期
3. StreamingContext直接创建的窗口，可以叫做基本窗口，它的窗口大小和滑动周期与批处理周期相同
Done!