被动拉取方式是只有下游节点显式进行数据请求，上游节点才会将数据传输到下游节点，其本质是让相关数据被动地传输到下游计算节点。被动拉取方式的优势在于下游节点可以根据自身的负载状态、工作状态适时地进行数据请求，但上游节点的数据可能未必得到及时的计算。
大数据流式计算的实时性要求较高，数据需要得到及时处理，往往选择主动推送的数据传输方式。当然，主动推送方式和被动拉取方式不是完全对立的，也可以将两者进行融合，从而在一定程度上实现更好的效果。
- 编程接口
编程接口用于方便用户根据流式计算的任务特征，通过有向任务图来描述任务内在逻辑和依赖关系，并编程实现任务图中各节点的处理功能。用户策略的定制、业务流程的描述和具体应用的实现需要通过大数据流式计算系统提供的应用编程接口。良好的应用编程接口可以方便用户实现业务逻辑，减少编程工作量，并降低系统功能的实现门槛。
当前，大多数开源大数据流式计算系统都提供了类似于MapReduce的用户编程接口。例如，Storm提供Spout和Bolt应用编程接口，用户只需要定制Spout和Bolt的功能，并规定数据流在各个Bolt间的内在流向，明确数据流的有向无环图，即可满足对流式大数据的高效实时计算。也有部分大数据流式计算系统为用户提供了类SQL的应用编程接口，并给出了相应的组件，便于应用功能的实现。
- 高可用技术
大数据批量计算将数据事先存储到持久设备上，节点失效后容易实现数据重放。而大数据流式计算对数据不进行持久化存储，因此批量计算中的高可用技术不完全适用于流式计算环境。我们需要根据流式计算的新特征及其新的高可用要求有针对性地研究更加轻量、高效的高可用技术和方法。大数据流式计算系统的“高可用性”是通过状态备份和故障恢复策略实现的。当故障发生后，系统根据预先定义的策略进行数据的重放和恢复。按照实现策略，可以细分为被动等待（passive standby）、主动等待（active standby）和上游备份（upstreambackup）3种。
被动等待策略如图3-7左图所示，主节点B进行数据计算，副本节点B′处于待命状态，系统会定期地将主节点B上最新的状态备份到副本节点B′上。出现故障时，系统从备份数据中进行状态恢复。被动等待策略支持数据负载较高、吞吐量较大的场景，但故障恢复时间较长，可以通过对备份数据的分布式存储缩短恢复时间。该方式更适合精确式数据的恢复，可以很好地支持不确定性的计算应用，在当前流式数据计算中应用得最为广泛。
主动等待策略如图3-7右图所示，系统在为主节点B传输数据的同时，也为副本节点B传输一份数据副本，以主节点B为主进行数据计算，当主节点B出现故障时，副本节点B'完全接管主节点B的工作。主副节点需要分配同样的系统资源。这种方式故障恢复时间最短，但数据吞吐量较小，也浪费了较多的系统资源。在广域网环境中，系统负载往往不是过大时，主动等待策略是一个比较好的选择，可以在较短的时间内实现系统恢复。
第3章 数据
73