1. 流数据处理（stream data processing）有哪两种基本模式?从系统吞吐率和时间延迟性看, 这两种模式各有什么特点?
参考答案：目前有两种主流的流计算模式：Native Stream Processing System（逐条处理模式）（图15-3）和Micro-batch Stream Processing System（打包处理模式）（图15-4）。Native Stream Processing System是基于数据按其读入顺序逐条进行处理，每一条数据到达即可得到即时处理（假设系统没有过载），延迟时间（delay time）较短，系统响应性好。Micro-batch Stream Processing System是将数据流先作预处理，打包成含多条数据的batch（批次）再交给系统处理。打包处理模式的特点是系统吞吐率（throughput）较高，容错处理更好。
2. Spark的micro-batch模型RDD (resilient distributed dataset)以2秒为单位截取数据流构成一个个数据包。如果以小于2秒或大于2秒为单位截取数据流构成RDD, 各有什么利弊?
参考答案：流数据处理计算以时间窗口截取生成RDD数据包，时间窗口的大小（如每2秒）将决定RDD数据包的大小。如果以小于2秒的时间窗口截取数据包，所形成的RDD可能尺寸太小。在后续的流计算（stream computing）中，RDD数据包将进一步拆分成分区（partition），每一个分区将以多副本形式存储到HDFS（Hadoop Distributed File System）存储系统上。RDD尺度太小会导致分区碎片化，使得HDFS的管理效率降低，也导致整个流计算处理系统的吞吐率降低。
如果时间窗口取得太大（远大于2秒），所生成的RDD数据包尺寸较大，包含数据量大，只要拆分后分区（partition）的大小不超出HDFS的数据块（data block）的尺度，就可以得到有效处理。但时间窗口取得太大、RDD数据包大的缺点是：尽管系统吞吐率有所提高，但对每条流数据而言，系统响应时间可能相对变长，不利于某些时间敏感性的应用要求。
3. 什么是Spark计算逻辑模型（抽象模型）Topology？什么是Spark计算物理模型（计算架构）？计算逻辑模型是如何映射到实际计算架构上的？
参考答案：Storm并行计算是基于由Spout（数据源）和Bolt（处理节点）组成的有向拓扑图Topology来实现。这里，流数据是以Tuple（基本数据单元，可看作一组各种类型的值域组成的多元组）的形式在Spout与Bolt之间流转。Spout负责将输入数据流转换成一个个Tuples, 发送给Bolt处理。每个Bolt读取上游传来的Tuples，向下游发送处理后的Tuples。Storm的Topology实际上定义了并行计算的逻辑模型（或者称抽象模型），也即定义了并行计算的步骤和流程。逻辑架构主要包含以下组件：
- 数据模型 Tuple
- 数据流 Stream
- 数据源 Spout
- 处理单元 Bolt
- 分发策略 Stream Grouping
Topology只是一个Storm作业流程的逻辑设计，真正要实现这个逻辑设计，还需要Storm计算物理模型（计算架构）来支撑。这就涉及到如何在Hadoop平台上部署Storm的软件组件；如何将Topology定义的逻辑组件映射到物理节点上运行的进程或线程，实现多任务并行处理；如何提供系统容错和故障恢复功能。Storm的计算架构（物理模型）包含如下组件：
- Storm主控程序 Nimbus
- 集群调度器 Zookeeper
- 工作节点控制程序 Supervisor
- 工作进程 Worker
- 执行进程 Executor
- 计算任务 Task
计算逻辑模型到实际计算架构的映射是通过系统为Topology分配工作节点（worker）、执行进程（executor）和任务线程（Task）来实现的。即当一个计算作业的Topology提交给系统后，Storm需要把物理计算资源（worker/executor/task）调度分配给Topology的spout和bolt，已完成相应的计算步骤。
5. 根据5.3节的Acker工作机制，说明为什么Acker收到一条Ack消息使ack-val=0时，就意味着该条tuple的处理结束？
参考答案：Storm可靠性要求发出的Spout每一个tuple都会完成处理过程，其含义是这个tuple以及由这个tuple所产生的所有后续的子tuples都被成功处理。Storm设计了一个Acker机制来提供这个可靠性。其基本工作原理可简述为：
- Acker（一个独立运行的监督线程）设置64-bit校核参数ack-val的初始值为0；
- Spout发出的tuple都带有一个64-bit随机生成的msgId；
- Bolt处理完输入的tuple，若创建了新的衍生tuples向下游发送，在向Acker发送消息确认输入tuple完成时，它会先把输入tuple的msgId与所有衍生tuples的msgId（也是64-bit的全新ID）作XOR运算，然后把结果tmp-ack-val发送给Acker；
- Acker每次收到新tmp-ack-val，都会将其与目前的ack-val做XOR运算，并存储运算结果：ack-val = (ack-val) XOR (tmp-ack-val)，其结果是ack-val所含值总是目前Tuple Tree中所有tuples的msgId的XOR运算值
- Acker如果发现运算后ack-val=0（即ack-val目前值与tmp-ack-val值完全相同），就知道该tuple的计算结束。因为只有整个Tuple Tree在规定时间内（timeout）再无新的tuple产生，才会导致tmp-ack-val与ack-val值完全相同。
有无可能由于两个衍生tuple的ID值碰巧相同，造成ack-val在Tuple Tree处理完之前就变成0？由于衍生tuple也是64-bit的随机数，两个64-bit随机生成的ID值完全一样的概率非常低，几乎可忽略不计，因此在Tuple Tree处理完之前ack-val为0的概率非常小，可忽略不计。
6. 图15-30的Acker算例如果扩展为如下的1个Spout + 4个Bolts情形， ack_val的初始值仍然为0。列出计算步骤验证：在步骤三结束时，ack_val = 0。
参考答案：步骤一：初始化 ack-val = 0;
ack-val = 1001 XOR 1010 XOR 0101 = 0110
步骤二：Bolt1发送的tmp-ack-val = 1001 XOR 1110 = 0111
收到Bolt1的tmp-ack-val后ack-val更新为：ack-val = (ack-val) XOR (tmp-ack-val) = 0110 XOR 0111 = 0001
Bolt2发送的tmp-ack-val = 1010 XOR 1111= 0101
收到Bolt2的tmp-ack-val后ack-val更新为：ack-val = (ack-val) XOR (tmp-ack-val) = 0001 XOR 0101 = 0100
Bolt3发送的tmp-ack-val = 0101XOR 1011= 1110
收到Bolt3的tmp-ack-val后ack-val更新为：ack-val = (ack-val) XOR (tmp-ack-val) = 0100 XOR 1110 = 1010
步骤三：Bolt3发送的tmp-ack-val =1110 XOR 1111 XOR 0111= 1010
收到Bolt3的tmp-ack-val后ack-val更新为：ack-val = (ack-val) XOR (tmp-ack-val) = 1010 XOR 1010 = 0
由此可知，步骤三结束时ack-val=0，计算结束。
