从分布式系统看流式计算的高可用技术

1        引言

近年来，一种新的数据密集型应用已经得到了广泛的认同，这类应用的特征是：数据不宜用持久稳定关系建模，而适宜用瞬态数据流建模。这些应用的实例包括金融服务、网络监控、电信数据管理、Web应用、生产制造、传感检测等等。在这种数据流模型中，单独的数据单元可能是相关的元组（tuples），例如网络测量、呼叫记录、网页访问等产生的数据。但是，这些数据以大量、快速、时变的数据流持续到达，由此产生了一些新的研究问题。

近年来，业界出现了不少数据流计算系统，虽然没有一个类似于Hadoop的集大成者，但是也都各具特色，包括工业界开源的Yahoo! S4、Twitter Storm、商用的IBM StreamBase及学术界开源的Borealis。

数据流处理涉及的关键技术之一就是高可用技术，技术选择往往决定了处理系统的架构实现。数据流系统的高可用技术也是源自于分布式系统，熟悉分布式系统的相关技术是我们研究数据流系统的前提，本文从布朗大学Jeong-Hyon Hwang的博士论文为起点，谈谈分布式系统和数据流系统的高可用技术。

2        数据库系统的高可用技术

像其他机械或者电子设备一样，计算机系统会发生故障。故障原因有多种，包括磁盘损坏、掉电或者软件错误等等。因此，数据库系统需要一种恢复机制，能够检测故障、并引导系统回到故障发生前的状态。早在70年代，数据库系统故障恢复方面的研究就开始了，我们回顾一下传统的基于磁盘的Rollback技术、Process-Pair方法、持久化队列，以及分布式数据库和工作流系统中使用的高可用技术。

2.1           基于磁盘的Rollback

除了硬件故障和软件Bug，数据库系统还可能遭受到事务故障（transactionfailures），原因可能是完整性约束的违背和死锁。如果发生这种故障，数据库的状态可能会变得不一致。因此，我们需要恢复机制能够保证事务的原子性，这通常分为以下几种：

l  Shadow Paging

Shadow paging使用两个页表，影子页表保存事务开始时的状态，当前页表保存事务操作时的状态。前者在事务销毁时变成新的页表，后者在事务提交后变成新的页表。

l  Log-based Schemes

基于日志的策略中，所有更新操作记录日志到持久化存储，如果发生故障，系统通过重放这些日志，使得存储系统恢复系统到先前的一致状态。通过定期产生Checkpoints，系统能够减少恢复时需要处理的日志记录数量。Checkpoint在持久化存储中保存了一致性状态。基于日志的恢复技术广泛应用于数据库产品，包括IBM DB2和MicrosoftSQL Server等。

这些数据库管理系统的恢复技术不是很适合于数据流处理。原因在于存储数据到磁盘的方式会带来很大开销，而且数据库事务的理论也不是适合于持续的数据流处理模型。

2.2           Process-Pair

数据库系统常常通过从源数据库复制数据来防止系统故障时造成的数据损坏，源数据库称为primary ，目标数据库称为standby。这个模型常常称为Process-Pair模型。Process-Pair有几种变化方式，区别在于运行时开销和恢复速度。

在冷备模式下，primary周期性地传输操作日志到standby，基于这些日志，standby异步执行这些操作。尽管操作日志常常被用到，primary也可以通过定期checkpoint自身状态，以便减少恢复时需要处理的日志数量。

在热备模式下，primary和standby同步执行所有的操作（例如，在发送结果到客户端之前执行每个更新操作）。相比执行性能，热备模式更重视恢复速度。冷备模式有相反的特性。

Process-Pair模型广泛应用于许多已有的数据库系统，包括IBM DB2 HADR (High Availability Disaster Recovery)、Oracle 10g/DataGuard和MSSQL 2005’s Database Mirroring。Oracle10g/DataGuard基于Oracle Streams构建，DataGuard支持三种恢复模式：maximumprotection (MPR)、maximum availability(MAV)和maximum performance (MPE)。MPR同步更新到作为相同事务部分的多个机器，提供精确恢复。MPE异步传输重放日志到standby，仅仅提供间隔恢复（gap recovery）。基于standby的可存取性，MAV在MPR和MPE间转化。

数据流处理中，考虑到应用需求，常常将Process-Pair模型加以变化，称为passivestandby、active standby和upstreambackup。这些技术能够提供精确恢复或者无损恢复。比较精确恢复，无损恢复能够提供较少的运行时开销和更快的恢复速度。根据恢复速度和资源使用，这三种改进的恢复技术拥有各自不同的特点。

2.3           持久化队列

Bernstein等人为客户端和服务器之间的事务请求开发了一种容错机制。利用持久化队列（Persistent Queues），它们的方法保证每个服务器只处理每个请求一次，保证一个客户端至少处理每个应答一次。

这个方法也不适合于数据流处理，因为它依赖事务的语义，并且在得到处理之前存储消息到持久化存储。数据流处理中有类似的方法，存储数据流源头的输入tuples。不像持久化队列，数据流处理中保存tuples在本地内存，直到下游算子处理完成。

2.4           分布式数据库的HA技术

         分布式数据库包括一系列站点，每个站点维护一个本地数据库系统，每个站点也会参与全局事务（例如，访问多个站点数据的事务）的执行。为了在服务器和网络故障时也能保证全局事务的原子性，分布式数据库通常使用两阶段提交协议（two-phase commit protocol）。

         当所有全局事务相关的站点都通知事务完成时，协议才被调用。两阶段协议是投票阶段和决策阶段，前者事务协调者检查是否每个相关站点都准备提交，后者协调者通知所有站点它对全局事务的决定（commit或abort）。两阶段提交协议也许会导致一种状态，事务的结果不能确定直到某个站点恢复。三阶段提交协议能够减少阻塞的可能性。

         尽管Process-Pair方法能够保护系统免受机器故障的影响，分布式数据库需要处理网络故障和大规模机器故障。因此，复制数据库到不同远程位置的技术被提出。这些副本技术主要分为两类：Eager Replication和Lazy Replication。

Eager Replication保持所有副本同步更新，这些副本作为原子事务的一部分，该方法常常导致序列化的执行，因此很难并发；另外，Eager Replication增加了事务的响应时间，因为对每个事务增加了格外的更新和消息传递。

       对比Eager Replication，Lazy Replication在可用性和一致性间取得平衡。事务发生时，只有一个副本更新，其他副本异步更新，相当于每个节点的独立事务。如果副本有不一致状态，系统负责协调状态。

这些副本技术在广域网范畴的数据流处理中是无用的，因为数据库事务的理论无法应用，由于高速的输入速率，算子副本的状态改变得太频繁。因为这个原因，广域网中的数据流处理，算子副本并发执行要比算子副本之间传递更新更加有效。

2.5            工作流系统的HA技术

       高可用技术在工作流管理系统（WFMS）的上下文中进行研究。在工作流系统中，例如IBM WebSphere MQ，数据传输通过几个达到共同目标的执行步骤。这些工作流系统通常使用standby服务器来屏蔽服务器故障。许多解决方案提交每个执行步骤的结果，同时存储消息到持久化存储，能够被primary和standby都访问到。为了达到可扩展方式的容错，一些工作流系统记录消息日志到处理节点而不是中心存储。变化的Process-Pair方法在Exotica workflow system中使用，没有checkpoint处理状态，Exotica记录工作流组件之间的消息日志。这个方法类似于数据流处理中的upstream backup，系统状态能够通过重放日志来恢复。

通常地，工作流系统的HA技术不会直接应用到数据流处理，因为它们依赖事务语义，这通常不适用于数据流处理的上下文。

3        分布式系统的高可用技术

分布式系统中有大量研究可靠性和高可用的技术。我们这里只是概要性地介绍两大类技术，分别是Rollback Recovery和Group Communication。

3.1           Rollback Recovery

这类技术将分布式系统视为一系列应用过程，它们通过网络进行交互。这些技术周期性地checkpoint应用过程的状态到持久化存储。当发生服务器故障时，应用过程从保存的状态重新开始，因此减少了丢失计算的数量。这些Rollback Recovery技术形式产生了一个的全局（系统范畴）一致性状态，作为恢复结果，过程的状态反映了消息的接收，发送者的状态反映了消息的发送。

早期的Rollback Recovery技术通过使用checkpoint来实现容错。这些基于checkpoint的技术分类如下：

l  Uncoordinated Checkpointing

该方法允许每个过程独立执行checkpoint。发生故障时，回滚过程到早期的checkpoint，直到全局性的一致性状态形成。这种串联回滚是Uncoordinated checkpointing的主要缺点，一个过程或许拿到无效的checkpoint，而它并不是全局一致性状态的一部分。

l  Coordinated Checkpointing

过程协调它们的checkpoints为了保存一个全局一致性状态。Coordinated checkpointing简化了恢复（由于过程仅仅需要从它们最近的checkpoint重启），并且减少了存储开销。不过这个方法会导致较大的延迟，因为在任何消息被发送到外部之前，全局checkpoint必须执行。这类技术保证了全局一致性，通过在发送任何应用消息之前，周期性地让所有过程执行checkpoints。

l  Communication-induced Checkpointing

基于每个应用消息上的协议信息，接收过程能够决定是否应该强制执行一个checkpoint，以防止上个checkpoint无效。除了这些强制的checkpoint，每个过程能够自动产生本地的checkpoints（例如，当状态很小且因此产生checkpoint开销）。因为这种方式不需要全局协调，所以它能够随着过程的数量增长进行扩展。

       基于日志的Rollback Recovery会合并checkpointing和非确定性的事件的日志（例如，消息的接收和硬件中断）。理论上，基于日志的Rollback Recovery依赖分段式的确定性，假设一个过程处理的所有非确定性事件能够被标识，并且在恢复过程中按照精确的原始顺序重放这些事件，过程就能够重建故障前的状态。因为这种方法能够恢复系统到某个故障点（而非最近一致性checkpoints集合），对于那种需要频繁与外部世界交互的应用，这种方法是非常有吸引力的。基于日志的Rollback Recovery有3个变化形式：

l  Pessimistic Logging

当事件的效果能够被其他过程或外部系统可见之前，保存每个非确定性事件到持久化存储。由于这个限制，Pessimistic Logging使得非故障期的性能下降。为了减少开销，一些协议依赖专门的硬件或者记录每条消息到发送者的非持久化内存。

l  Optimistic Logging

该方法异步地将非确定性事件存储到持久化存储（例如，首先保存这些事件到内存，然后周期性地刷写到持久化存储）。发生故障时，这种方法可能会产生孤儿过程（状态依赖于尚未记录日志的非确定性事件）。Optimistic Logging技术回滚这些孤儿过程直到没有这种过程残留。在无故障执行时，它们跟踪过程间的因果依赖。因果依赖也被用于记录事件日志，在事件的效果被外部系统看到之前。

l  Causal Logging

该方法比Optimistic Logging有更好的无故障运行性能，并且保持了Pessimistic Logging大部分的恢复优势。Causal Logging保证，每个有原因地影响过程的非确定性事件，都总会被写到持久化存储或过程的日志中。为了实现这点，过程基于应用消息上的因果信息，并基于这些消息更新它们的日志。

在数据流处理中，数据流由各个算子连接起来，它们代表了算子之间的依赖。因此，无需任何复杂机制，相互独立的算子可以轻易找到。利用这个特性，技术上可以产生细粒度的checkpointing，从而能大大减少checkpoint阻塞规则处理的持续时间；而且，我们可以做到分布式的备份框架，使得恢复可以并行；另外，备份的分布式部署及按策略调度checkpoints能够提升恢复速度。

3.2           Group Communication

在分布式系统中，一组远程过程之间的交互需要保证可靠性。例如，应用要求每条消息被传递给所有过程组内成员或者都不传递；并且，应用一般要求所有消息按照相同顺序传递给所有进程。以上两个条件定义了广播的原子性。原子性广播在分布式数据库中广泛使用，因为其保证了所有站点按照统一方式更新它们的本地数据库，即使站点或网络发生故障。Paxos算法可以在容错方式下达到分布式一致。这个算法有助于基于恢复技术进行故障恢复，因为它可以让一组副本很容易地对每个成员的健康状态达到一致。

数据流处理的Active Standby模式下，只要多个上游副本有数据到达，下游副本就可以进行处理。这个技术保护系统免于故障影响，即使没有故障监测和副本切换。

4   数据流系统的高可用技术

       大部分数据流处理的高可用技术基于故障恢复。在这些技术中，如果服务器故障，一组预先定义的备份机器将接管失败的执行。通常基于故障恢复的高可用方法有三类：

l  Passive Standby

在Passive Standby方式下，每个primary定期做checkpoints（即拷贝从上个checkpoint到当前状态的改变）到它的backup。

Passive Standby方式广泛试用于局域网集群，它能够经受高负载情况，却降低了恢复速度。一些已有技术将每个服务器上的计算进行拆分，将拆分后的部分备份到多个服务器。基于这种分布式备份，能够实现恢复的并行化，因而大大减少了恢复时间。

l  Active Standby

在Active Standby方式下，每个backup也会接收并处理输出数据，和primary并行，在广域网应用环境下，该方法是个好的选择。

比较Passive Standby，Active Standby方式保证了更快的恢复速度，低负载情况下所有backup使用和primary相同的资源。通过使用分配给tuples的序列数，Flux技术实现了无损和副本自由的故障恢复语义。Flux允许副本之间松耦合，一个副本能够比其他执行地更快，导致在很多时候执行交迭。Balazinska等人研究active Standby方法的变体，能够处理网络故障和分割。

l  Upstream Backup

在Upstream Backup方式下，每个primary记录它的输出数据到日志，这样即使下游primary发生故障，backup也能通过重放日志数据来从头重新构建丢失的状态。

Upstream Backup在无故障期间执行效率很高，因为其backup一致保持空闲状态。然而，它可能会花费较长时间来恢复状态较大的计算。例如，恢复一个带有30分钟窗口的Aggregate算子，需要重新处理30分钟内的所有tuples。对于那些算子的状态很小，并且资源紧缺，故障发生稀少的情况，Upstream Backup是个好的选择。

5   小结

         从以上高可用技术的介绍可以看出，数据流处理的高可用技术基于分布式处理方面的研究，并针对应用特性做了相应改进。流式计算和分布式计算本身就是一家，更好地了解分布式理论是设计优秀流式计算系统的必要条件。

6   参考文献

[1] Jeong-HyonHwang, Fast and highly-available stream processing.Doctoral Thesis / Dissertation, Brown University, May 2009