基于 IBM InfoSphere Streams 平台高性能流计算应用的构建

概要

进入 21 世纪，由于处理器性能的大幅提升以及网络技术和应用的日新月异， 数据的传播和交换正经历革命性的变化。图灵奖获得者吉姆·格雷（Jim Gray）认为，网络环境下每 18 个月产生的数据量等于过去几千年的数据量之和。不仅如此，数据还具有实时、异构、非结构化等一系列特点。目前大多数数据分析平台如 Hadoop，采用离线计算的方式来处理具有上述特征的数据，耗费的时间少则数天，多则数月，极大地延误了业务决策的执行，最终造成商机的丧失。流计算就是伴随着大量非结构化、异构、动态流数据实时分析处理进而快速做出业务决策需要而孕育产生的新技术，它解决了传统离线计算过于耗时这一主要矛盾。与传统离线计算利用相对静态存储的数据进行业务分析的过程不同，流计算要求能够连续地把分析过程运用于不断更新的动态流数据，并且能够对业务分析模型进行动态调整，从而产生更加准确的数据以帮助决策。

IBM 公司的 InfoSphere Streams（以下简称 Streams）产品就是适应这种要求而产生的分布式流计算平台。它源于 IBM 研究院 2003 年开始的 System S 项目，总共有 80 多位 IBM 专业人员参与其中，于 2009 年完成产品化工作，现已成功推出两个主版本。Streams 前瞻性地把支持每秒 6G 或者每小时 21600G （相当于互联网上所有网页数量之和）数据处理能力作为系统设计的指标，实现了流数据“永恒分析”的能力。通过创新的流构架和数学算法，Streams 成功地解决了流计算中一系列具有挑战性的问题：

• 对于事件和变化需求的迅速响应
• 对于现有系统连续处理数据能力数量级上的提升
• 对于多种数据形式和类型的适应
• 对于系统高可靠性，异构性以及分布性的高效管理

除 Streams 产品之外，比较有名的流计算平台是雅虎贡献给 apache 开源组织的分布式流计算平台 S4。项目开源地址 (http://s4.io/) 首页是这样描述 S4 的：S4 是一个通用的、分布式的、具有可扩展性的、部分容错能力、支持插件的流计算平台。通过研究可以发现，S4 与 Streams 相比，只能算是一个半成品，存在者很多问题尚需解决的问题。比如，数据通讯只支持 UDP 协议，不能保证可靠的数据传输，缺乏负载均衡机制，必须采取手工方式进行部署等。

相比较，Streams 作为一个流计算平台，不仅实现了系统的高可靠性，高可扩展性，负载均衡等设计目标，而且提供了完整的解决方案，包括一个运行时环境和编程模型来简化需要对大批量连续流数据 进行提取、过滤、分析以及关联的应用程序的开发，能够广泛应用于制造、零售、交通运输、金融证券以及监管各行各业的解决方案之中，使得实时快速做出决策的理念得以实现。下面我们先从 Streams 的运行时环境出发，来探讨 Steams 的整体架构；然后给出 Streams 应用程序的拓扑结构以及构建高性能 Streams 应用程序应该考虑的一系列问题。最后将讨论 Streams 的失败恢复机制以及高可用性。

Streams 实例

Streams 运行时环境也称为 Streams 实例，它由一系列相互交互的，运行在一个或多个主机上的服务构成。典型的拓扑结构如下图所示：

图 1 InfoSphere Streams 实例架构
 

如上图所示的典型的拓扑结构下，管理服务部署于一台独立的管理主机上，提供如下服务：

• Streams Web 服务 (SWS) 是一个可选的服务，提供 Streams 实例基于 web 通讯协议的访问与管理。
• Streams 应用程序管理器 (SAM) 接收和处理作业的提交和取消请求，主要通过和调度器 (SCH) 进行交互来实现。
• Streams 资源管理器 (SRM) 负责 Streams 实例的初始化，聚合系统范围内的性能度量指标，并和 每个应用主机上的主机控制器 (HC) 进行交互。
• 调度器 (SCH) 从 SRM 收集运行时性能度量指标，之后把这些信息发送给 SAM 来确定哪个应用主机 被调度以运行特定的 Streams 应用程序。缺省的调度模式是基于负载均衡的，基于预测的调度模式 使用资源消耗模型来确定合适的主机来运行应用程序。
• 命名服务 (NS) 用于提供管理服务的位置信息。
• 认证授权服务 (AAS) 用于认证并且授权用户的服务请求和访问。
• 恢复数据库用来存储管理服务运行状态，当发生软硬件故障时可用于系统的恢复。

除了运行一系列管理服务的管理主机之外，还存在一个或多个应用主机，用于执行 Streams 应用程序。 每个应用主机包括：

• 主机控制器 (HC) 用于启动和监控运行在特定主机上的所有处理元素 (PE)。
• 处理元素容器 (PEC) 以操作系统二进制程序形式存在，主要负责对处理元素 (PE) 的动态加载来完成特定的任务。

此外，在这种典型拓扑结构下，还需要共享文件系统来共享实例的配置信息以及跨主机的 SPL 应用程序执行体。共享文件系统必须和 POSIX 兼容，一般可使用网络文件系统 （NFS）和 IBM 通用并行文件系统（GPFS）。

Streams 应用程序

Streams 应用程序是由 Streams 运行时调度执行的程序，可在一个或多个应用主机上并发执行。其拓扑结构如下图所示：

图 2. Streams 应用程序结构
 

为方便描述，首先给出 Streams 应用程序中的一些术语：

• 流：代表任何来自于数据源的连续数据流，数据的表现形式是由一系列属性构成的元组。
• 运算符：流数据处理的功能组件，接收一个或多个输入流，对流数据对应的元组和属性进行处理，最终产生一个或多个输出流。

Streams 应用程序由相互连接在一起的运算符构成，给出了运行时如何进行流处理的定义。SPL(Streams Processing Language) 是 IBM 提供的专门用于构建 Streams 应用程序的声明性语言。使用 SPL，用户只需声明所要完成的功能，Streams 运行时环境将负责确定最佳执行方案，从而极大隐藏了底层的实现细节，简化了 Streams 应用程序开发。此外，SPL 还提供了如下功能：

• 用于灵活组合并行和分布数据流图的编程语言 ；
• 内置泛型流处理运算符的工具箱，包括所有基本流关系运算符，以及很多常用的运算符（例如：拆分，多路分解等）；
• 可扩展的运算符框架，支持增加新的泛型类型以及可配置的运算符，轻松实现对现有以及传统分析工具的封装；
• 适用范围广泛的适配器，用于从外部数据源提取数据并把数据发布到外部目标，例如，网络套接口，数据库，文件系统，等。

Streams 应用程序在被 SPL 优化编译器编译成可部署的组件之后，通过分布式运行时环境进行部署和管理。运行时环境连续监控计算资源的状态和利用率，并且能够根据软硬件失败和资源变化情况进行自适应。Streams 应用程序的部署是由提交作业的形式完成的。一般来说，应用程序和作业是一对多的关系。通过提交多个作业，一套应用程序处理逻辑能够以多个任务的形式执行，从而达到并行处理的效果。Streams 实例中的作业执行不是由操作系统来调度的，而是由 SCH 来完成调度的。一个作业对应的一个或多个 PE 将被 PEC 按需进行动态加载，避免了操作系统层面上代价高昂的进程上下文切换。

尽管 SCH 服务将为 Streams 应用程序的执行提供最佳调度，在构建 Streams 应用程序时，我们还须考虑应用程序对数据处理量，响应延时以及可扩展性的特殊要求。一般来说，可从如下几方面进行考虑：

• 应用程序的动态组合：Streams 运行时允许同一个 Streams 实例同时运行多个应用程序。其中一个应用程 序可负责流数据的导出（使用 Export 运算符），然后另外一个或多个应用程序来消费导出的流数据（使用 Import 运算符）。Export 和 Import 运算符能够以松耦合的方式进行组合，这样上游和下游应用程序可以 独立部署，并且在负载过大的情况下还可按需部署新的下游应用程序以及动态调整 Import 运算符的订阅属 性，以达到负载均衡处理的效果。
• 运算符的并行处理：
  • 当发现单个运算符是数据处理的瓶颈时，可部署运算符的多份拷贝，然后每份拷贝运行在单独的主机上， 只负责处理数据的子集，以达到并行处理的效果。特别适用于处理器密集型的运算符，并且单个处理器或 主机不能满足吞吐量需求的情况。
  • 处理器密集型的运算也可以被分割为多个阶段。流数据的处理是一个阶段接着一个阶段的，从而达到流水 线处理以及分段，分散运算符负载的效果。由于流水线模式下，每个元组需要流经所有的运算符，因而容易 造成 PE 之间需要进行大量数据的通讯，这种问题在 PE 分散于不同主机的情况下尤为显著。
  • 并行流水线：通过流水线并行化，可以按流数据的复杂程度来组装多条流水线，处理速度比较低的单条流 水线不会影响其它流水线的处理，从而在整体上提高了流水线的效率；同时单条流水线可以进行融合或者至 少共存于同一台主机上，以减少网络对数据处理的影响；而整个流水线应该分散在不同的主机上，以便最大 限度的利用资源。并行流水线的结构如下图所示： 
    
    图 3 Streams 运算符的并行流水线模型
     
    
    
• 多个运算符融合为一个 PE：当运算符被融合到 PE 之后，它们之间的通讯是通过函数调用的方式完成的，运 算符之间元组的传递是通过内存引用完成的。相比较，融合之前的运算符使用传输协议来完成通讯，往往涉 及跨网络的信息传输。因此融合技术能极大地降低通讯代价，提升响应时间和吞吐量。SPL 编译器提供了融合 优化技术来确定如何把运算符以最佳的方式融合为一个或多个 PE，为此应用程序需要先期运行一段时间以收集 资源的使用特征，包括 CPU 的消耗状况以及运算符之间的数据流量等信息。
• 运算符以预配置的方式进行主机定位：Streams 运行时提供了 PE 动态主机定位的能力，但这种定位往往是基于 负载均衡或者预测的资源使用状况来进行的。对于特定的 Streams 应用程序，可能需要从应用程序逻辑模块划分 的角度进行主机定位的预先优化配置。比如说，使用 SPL 来显示指定哪些运算符能够定位在一起，哪些运算符一 定不能定位在一起，以及允许运算符定位的主机集合。一般来说，主机可通过主机标签进行逻辑上的归类，然 后运算符通过和主机标签关联来限定能够运行该运算符的主机集合，而不是直接跟物理主机关联。这样 Streams 运行时就会根据作业提交时刻的实际情况从和该标签相关的主机集合里进行动态调配。

在构建并行 Streams 应用程序的过程中，除了考虑上述提到的一系列问题，还需要特别考虑应用程序中运算符的状态。 很多运算符在处理元组的过程中保持状态的。在这种情况下，由于并行处理而对流数据进行的拆分将导致运算符处理 结果发生变化。另外，运算符的状态保持，对于 Streams 应用程序的失败恢复也是需要考虑的一个问题。下面我们将 列举 Streams 运算符中和状态相关的一些场景以供参考：

• 元组的历史：运算符调用参数或者输出赋值表达式可以直接引用之前收到的元组，也就是元组的历史数据。 一般是通过输入端口名称的下标来访问的。
• 运算符窗口：指运算符输入端口最近收到元组的逻辑集合，一般用于数据的聚合运算。
• 运算符定制逻辑：包含运算符在元组处理过程中保持的局部状态以及接收到元组和结束符的逻辑处理语句。
• 用户自行使用 C++ 和 Java 开发的原生运算符也可能包含状态信息。

Streams 失败恢复和高可用性

Streams 作为商用的流计算平台，也提供了内置的软硬件的失败恢复机制，涵盖以下内容：

• PE 重启和主机重定位 有些运算符由于内在的逻辑以及依赖关系，是不能实现失败后的 PE 重启和重布局。例如，运算符可能依赖于一个本地 非共享的文件，PE 重启和重布局之后有可能无法找到这个文件。另一方面，Streams 运行时没有运算符内在逻辑以及 依赖关系的信息，因此需要运算符显示告诉 Streams 运行时是否支持 PE 重启和主机重定位。相关的配置项是：restartable 和 relocatable。仅配置为 restartable 的 PE，不会进行主机的重定位 ，也就是说，只有在之前运行它的主机可用的情况下， 才会进行自动重启；而同时配置为 restartable 和 relocatable 的 PE，将自动在同一台或者另一台主机上重启；没有配置为 restartable 的 PE，需要手动取消并且重新提交一个新的作业来实现重启。
• 恢复应用主机 应用主机是运行 HC 服务的主机。如果 HC 失败或者停止响应， SRM 将标记该主机不可调度，之后 SAM 将把运行在失败主机上的 所有 PE 状态标记为未知。标记为未知状态的 PE 不能自动重启，可以通过重启 HC、把失败主机从主机池中去除等方法实现 PE 的 重布局。
• 恢复管理主机 管理主机是运行一系列管理服务的主机。缺省情况之下，Streams 实例是不允许管理服务的失败恢复。为了使管理服务的失败 恢复功能可用，Streams 实例需要把运行时的状态数据存储在一个 IBM DB2 失败恢复数据库中。并且需要设置 RecoveryMode 属 性为打开状态，来通知 Streams 实例使用失败恢复数据库。