一种通用混合计算中间件的设计与实现

张洪豪 姚欣 王劲松 姚世春

摘  要： 随着接入设备的激增，网络应用及协议的不断涌现和互联网流量的爆发式增长，给数据分析与处理带来了极大的挑战。大数据环境中数据处理应用所呈现出的趋势是实时在线计算、离线批式计算以及动态响应式计算相互结合、相互影响，这就要求底层计算资源具备同时提供实时计算、批式计算及响应式计算的能力，然而传统的系统架构和编程模型已经无法满足这种混合计算需求。文中设计并实现一种构建在流式数据处理过程IStream之上的混合计算中间件（General?purpose Hybrid Computing Middleware，GHCM），它以统一、灵活的高层抽象将相互依赖的高并发实时处理业务逻辑、批处理业务逻辑和跨层次动态调用无缝融合起来。实验数据表明，GHCM在解决混合计算问题上具有良好的性能，在大幅缩短开发时间的同时为用户提供了可重用和易扩展等支持。

关键词： 混合计算中间件; IStream模型设计; 数据处理; 程序无缝融合; 系统实现; 性能分析

中图分类号： TN911.2?34; TP302                 文献标识码： A                      文章编号： 1004?373X（2020）12?0055?06

Abstract： The sharp increase of access devices， the continuous emergence of network applications and protocols， and the explosive growth of Internet traffic bring a great challenge to data analysis and processing. The trend presented by the data processing applications in the big data environment is the mutual integration and mutual interaction of real?time online computing， offline batch computing and dynamic responsive computing， which requires that the underlying computing resources have the ability to simultaneously provide real?time computing， batch computing and responsive computing， but the traditional system architecture and programming model is unable to meet the needs of this kind of hybrid computing. A general?purpose hybrid computing middleware （GHCM） based on the streaming data treating process IStream is designed and implemented， which integrates the interdependent high concurrent real?time processing business logic， batching business logic and cross level dynamic call seamlessly with a unified and flexible high?level abstraction. The experimental data show that GHCM has good performance in solving the hybrid computing difficulty， and provides users with reusable and easily extensible support while significantly reducing development time.

Keywords： GHCM; IStream model design; data processing; procedure seamless integration; system implementation; performance analysis

0  引  言

当前，大数据计算引擎及相应的编程模型已经成为云计算领域发展速度最快的技术之一，Hadoop[1]作为典型代表，以其新颖的构思和出色的大规模数据处理能力一度成为首选的大数据分析和计算平台。然而，在研究和实际应用中人们已经意识到Hadoop在面对低延迟和具有复杂数据关系的大数据问题时具有很大的不适应性[2?3]。随着不同应用场景的出现，Hadoop在大数据处理领域的霸主地位被逐渐撼动，一大批新型计算引擎相继问世，Spark[4]和Storm就是其中的优秀代表，前者为海量数据批处理提供了高效的解决方案，后者则被视为高并发实时计算领域的新标准。

2018年中国大数据技术与产业发展白皮书[5]指出，企业必须根据不同的场景灵活使用合适的技术，复杂场景中的大数据应用可能同时包含不同特征的源数据和计算需求，单一的计算模式已无法满足整个应用的需求。分布式网络安全软件在监测网络流量时需要同时完成如下工作：

1） 快速处理实时注入系统的数据流;

2） 将实时计算所累积的信息与其他静态数据结合起来由离线计算模块分析处理;

3） 分析产生的结果在用户发出动态请求时被渲染成图形界面并返回给用户。

为实现上述类型的应用程序，用户通常需要同时管理两套计算框架来分别完成实时处理任务与批处理任务。前者给用户带来较大的开发、协调和维护困难并且系统性能无法得到保证;后者则是低效的系统设计方案，程序性能会受到底层计算引擎的严重制约。

鉴于此，本文提出一种具有通用性的编程模型，它以抽象过程IStream和发布/订阅机制为核心，将实时计算、批式计算和动态响应式计算无缝融入一套应用程序中，并且为应用程序带来跨层次的可重用性和可扩展性。系统底层实现细节都被编程模型所隐藏，取而代之的是简单的高层抽象概念和接口。本文所提出的通用混合计算中间件（General?purpose Hybrid Computing Middleware，GHCM）被实现在Spark和Storm计算引擎之上，经GHCM优化（任务压缩、提前聚合等技术）之后的用户程序借助Spark提供的快速批量计算模型和Storm提供的快速持续计算模型可以获得相较于传统架构更快的数据处理速度。

1  相关工作

MapReduce[6]是Google公司开发出的一种高效、可扩展的并行计算框架，其所提供的编程模型可以将用户程序分解为3个相互关联的处理步骤：Map，Shuffle和Reduce。这种编程模型具有较好的通用性，能够实现大多数计算需求。但MapReduce过于依赖文件系统，运行过程中频繁访问磁盘所产生的时间开销较大，也不能对多阶段的流水线式处理过程提供很好的支持。Hadoop是MapReduce框架的开源实现，具有与MapReduce相似的作业调度器和分布式文件系统。在实际应用中，Hadoop表现出的局限性与MapReduce也十分相似。FlumeJava[7]构建在MapReduce之上，弥补了MapReduce模型无法实现流水线处理过程的缺憾。FlumeJava提供的高层API具有较强的表达能力，可以被用来编写运行在MapReduce之上的多阶段处理程序。FlumeJava的不足之处在于不具备跨阶段优化能力，而且无法识别并删除代码中的冗余接口调用。Apache Crunch是FlumeJava的开源实现，它在Hadoop上实现了与FlumeJava类似的功能，且已经添加了对Spark框架的支持。Dryad[8]是微软公司提出并實现的分布式计算框架。Dryad用执行计划图描述用户程序，图中的节点代表数据计算单元，连接不同节点的有向边代表数据传输通道。与Hadoop相似，Dryad使所有底层实现细节透明化，用户只需调用Dryad提供的API就能得到分布式数据计算服务，但在通用性方面有所欠缺。

2  基于IStream的发布/订阅模型

GHCM的核心是IStream的数据计算单元和建立其上的发布/订阅模型。IStream发布/订阅模型[9]是一种分布式计算环境下的近同步通信模型，它以交互协议为基础，以数指分离机制为核心，提供了一种面向多层实体、具有可重用性和可扩展性的计算单元动态调用服务。

2.1  IStream发布/订阅模型的设计

与传统的发布/订阅模型不同，IStream发布/订阅模型采用了指令与数据相互分离的设计方案，发布指令与传递数据是两个独立的互不干扰的过程，如图1所示。图中：msg cache是专注于收发调用指令和反馈信息的系统部件，常用的消息中间件都可以作为msg cache的底层实现，如Kafka和ActiveMQ;sink可以是集群内的文件系统、数据库、队列中间件或其他存储结构，主要被用来承载或传递计算实体在各个阶段产生的计算结果。

2.2  IStream发布/订阅模型的动态交互性

IStream发布/订阅模型会将集群内所有正在运行的计算单元划分为两类：非响应式计算单元和响应式计算单元。IStream发布/订阅模型借助数指分离策略消除了计算单元之间的强关联，把所有响应式计算单元视作可以向外提供服务的独立实体，并且通过集群内部的消息中间件接收并响应调用请求。这种动态调用过程不仅可以出现在GHCM程序内的IStream之间，其他外部程序也可以作为发布者参与其中。GHCM运行时系统会为Supervisor进程指定一个端口，外部程序发出的调用请求正是通过这个端口传递给Supervisor的。在这种跨层次动态交互过程中，用户程序只需关注高层业务流程的设计，并在必要的时候调用GHCM系统对外开放的计算资源，Supervisor进程作为响应式计算单元的外部代理，已将所有底层细节屏蔽掉，呈现给外部程序的只是一套简洁的调用和反馈接口。

2.3  IStream发布/订阅模型的可重用性和扩展性

IStream发布/订阅模型为GHCM程序和外部程序带来的另一个好处是提高组件的可重用性和可扩展性。在图2中，GHCM程序1原本只包含IStream 1和IStream 2。

随着新计算需求的提出，开发者为这个GHCM程序编写了第3个计算单元IStream 3。为了使IStream 3承接并处理IStream 2产生的数据，开发者只需少量修改IStream 2的程序代码：声明一种指令发布策略，并指向IStream 3所监听的消息缓存msg cache 2。重新编译并运行GHCM程序1之后，新添加的计算单元已然能够无缝融入原有的处理流程中。可以看出，这种低耦合的结构能被很容易地扩展成更大、更复杂的系统。GHCM程序由3个计算单元组成，IStream 1作为非响应式计算单元不接受来自其他实体的动态调度，而IStream 2和IStream 3都是系统内的响应式计算单元。

始终处于运行状态的IStream 1作为系统唯一的入口单元，能使该GHCM程序不间断地执行数据处理任务而无需等待外部调用。当用户1发出操作请求后，应用程序1会直接从sink 1中读取数据，然后把数据交付给用户。而对应用程序2，每当用户2提交操作请求，通过Host上的Supervisor进程动态调用IStream 2，并在收到Supervior发送的反馈信息后从sink 2中取出所需的计算结果。

3  GHCM系统实现与性能分析

GHCM运行时系统会根据用户程序中的IStream操作序列构造出一幅初始的流处理图（Stream Processing Graph，SPG）。SPG经过任务压缩、任务扩展和提前聚合等优化处理，最终会被系统分割、编译并提交到底层计算引擎上执行。将IStream编程模型作为通用混合计算中间件实现在Spark和Storm计算框架之上。

3.1  系统架构及工作流程

GHCM系统架构如图3所示。

开发者编写的应用程序处于系统最高抽象层，用户应用程序之下分别是GHCM类库和运行时系统。GHCM类库定义了用户需要遵循的语法规则，即以抽象计算单元IStream为核心的编程模型。运行时系统是GHCM的核心，该层主要由SPG Builder，SPG Optimizer，Code Generator，Task Compiler，Task Submission，Task Tracker和Supervisor七部分组成，它们所实现的功能分别是：

1） SPG Builder：构建与用户代码相对应的流处理图。

2） SPG Optimizer：利用相关技术对初始SPG进行优化处理。

3） Code Generator：将优化之后的SPG以IStream为单位分解开，再把DIStream和SIStream分别翻译成符合Storm和Spark编程规范的独立程序。

4） Task Compiler：编译需要提交到Storm和Spark上执行的作业。

5） Task Submission：向计算集群提交作业。

6） Task Track：追踪计算引擎产生的日志及性能参数并及时向上反馈。

7） Supervisor：IStream的代理，监听并转发来自外部程序的动态调用请求。

3.2  SPG优化相关技术

SPG的优化技术可从任务压缩、提前聚合以及任务扩展等多途径提高资源利用率并且提升程序运行速度。在很多情况下，许多操作能被串联起来以流水线的形式在同一个计算节点中处理完成，而不必将每一步处理任务分别派发到不同的计算节点中执行。例如，SPG中相邻的filter操作和map操作可以被压缩到同一个任务中，这对数据集中的每一个原组先判断其是否满足过滤条件，若满足条件则立刻进行map变换，然后将结果传递出去，不满足筛选标准的原组会被直接丢弃。

在底层实现时，同样存在许多能被压缩执行的操作。这些操作具有的共同特点是有限依赖性，即“父操作”发出的任意一个数据原组只被“子操作”至多引用一次，且“父操作”向“子操作”传递数据时不需要重新分组，具有这种简单线性依赖的操作序列能在不改变计算结果的前提下被合并执行。当用户程序中存在大量连续的有限依赖运算时，这种优化手段带来的性能提升将十分显著。

任务压缩除了能优化有限依赖运算，还能够去除冗余接口调用。例如：用户在进行map操作后又调用了功能相似的mapToPair（）接口，这种情况下第一个map（）调用将被删除，其操作代码会被融合到mapToPair处理过程中。

在编程模型提供的API中包含多个针对形式数据的聚合操作接口，如reduceByKey（）和groupByKey（），该类型操作的实现建立在正确的数据分类基础之上。为了在集群中实现这两种运算，通常采用的方式是先将“父操作”产生的所有数据记录按照散列值重新分组，再将各组数据分别引导至不同计算节点或不同计算进程中，之后才能开始进行数据聚合。对于那些同时满足交换律和结合律的聚合操作来说，这种处理方式无疑是低效的，因为一部分数据之间的聚合操作不必被推迟并等待下游节点完成。所以，更快速的处理方式是先在父节点中进行一次局部数据聚合操作，再对数据分组并交给下游节点进行全局聚合处理。这种提前聚合模型带来的好处是：实现更快的处理速度以及网络带宽的高效利用。经过上游节点的局部聚合，需要传输的数据量会大幅减少，因而传输延迟也会大幅降低。

在圖1中的DIStream 2需要同时监听并处理分别来自4个不同数据源的数据，如果它处理数据的速度低于数据注入的速度，那么数据将会在DIStream 2中持续堆积并最终造成系统性能的大幅度降低。任务扩展是一种旨在提高任务并发性的优化方案，通过增加工作节点和工作进程来充分利用系统计算能力，从而加快任务处理速度。

3.3  实例优化

首先，任务压缩优化技术将对原始SPG进行处理。DIStream 2中的连续有限依赖操作union，flatMap和mapToPair被集成到同一步操作中，SIStream 1中的有限依赖操作以流水线的形式被装配起来。另外，SIStream 1包含的冗余函数调用groupByKey（）和reduceByKey（）会在当前优化过程中被剔除。系统对DIStream 2进行扩展优化引入一个新的处理流程，以并发处理的方式分担计算压力。针对SIStream 1中的reduceByKey（）调用，系统通过对上游操作进行修改，使得数据聚合操作被提前至union（）处理过程中。这种局部聚合操作能大幅度减少中间结果传输量，并最终提升系统处理速度。

其次，编译期间GHCM会对SPG进行动态优化，SPG Optimizer通过合并有限依赖操作、提高程序并发性和充分利用数据局部性原理，重构能与经验丰富的程序员手动优化相媲美的程序。任务压缩优化技术以合并连续数据操作的方式提高程序运行速度，优化前后SPG中接口调用次数的改变能够直观地反映出这种技术的优化效果，对GHCM的优化模块进行改进，使它在处理结束时记录下重构之后的SPG。在对5个不同规模的示例程序进行任务压缩优化之后，统计得到的接口调用次数变化情况如表1所示。

在这5个测试程序中，最小接口调用次数为4，最大为24，经过压缩处理之后，原始程序被不同程度地精简。图4用任务压缩率的变化情况重新表述了本次测试得到的结果。

为了验证任务扩展和提前聚合的有效性，分别以两个计算单元DIStream 2和SIStream 1为测试目标，记录下优化前后程序性能的改变。在验证过程中任务压缩功能一直处于激活状态，任务扩展功能和提前聚合功能则根据测试需求被手动激活或禁用。

针对任务扩展优化技术，设计了5个对比测试场景，分别为DIStream 2提供了1，2，4，8和16个并发数据源，每个数据源包含了一份大小为11 GB的样本数据（约300万条记录），实验结果如图5所示。

当数据源个数为1时，DIStream 2所花费的时间约为33 s，因为Optimizer只会在应对多数据源时才会扩展用户程序，所以此时优化器对DIStream 2的运行时间影响甚微。随着并发数据源个数的增加，原始DIStream 2的运行时间经过相对平缓的爬升（数据源个数小于等于4）之后陡然增加。造成这种波动的原因是，初期，程序可以利用工作节点本身的处理能力应对多条并发数据流，但当并发量超出节点所能承载的范围后数据将会持续堆积，系统吞吐量随之大幅度下降。与之对应的，扩展后的程序运行时间不会随着数据并发量的提高而显著增加，工作节点间因交换数据而产生的时间开销远远低于数据堆积对系统性能造成的影响。

对SIStream 1的测试结果建立在一份4.11 GB的样本数据之上。结果显示，将reduceByKey（）接口所要求的聚合操作提前至union（）阶段后，SIStream 1获得了近22%的速度提升，分析表明因局部聚合而减少的网络数据传输开销对系统提速贡献最大。

3.4  GHCM系统性能分析

除了编程模型的通用性、灵活性和简洁性，提高系统性能也尤为重要。在应用程序层面，经过SPG Optimizer优化之后的用户程序可以与经验丰富的程序员手动调优的程序相媲美。而在系统底层，通过高性能计算引擎Spark和Storm来提高系统处理速度。

通过造出一组包含4个程序的测试集（包含基准程序，即root program）来评价GHCM的性能。其中，所选取的基准程序主要用于对网络流量进行实时分析，当它检测到异常流量时就会立即发出告警信息并通过关联分析算法进行攻击场景重建。此外，该程序可以在用户发出请求时将各项统计信息绘制成动态图像。在线模块主要用于统计实时流量的状态信息，例如：网络瞬时流量、协议所占比例情况、关键节点服务器状态等。离线模块将IDS告警日志作为关联规则的数据源，对每一条独立的入侵检测数据通过IP进行攻击溯源，经过告警关联判断，告警决策树生成，对整个攻击流程进行关联分析，还原攻击者对目标机器攻击的整个场景。该流量分析系统是混合计算模式在实际应用场景中的一个典型案例：系统的流量监测、分析功能对应于实时计算模式;攻击场景重建涉及到对大量数据的迭代运算，所以这项功能对应于批式计算模式;而接收用户请求并动态绘图的功能属于响应式计算模式。尝试以三种方式重新实现该流量分析程序：程序A将全部业务逻辑移植到Hadoop框架上;程序B分解原程序的业务逻辑，把实时任务移植到Storm框架上，把批处理任务移植到Spark框架上;程序C分解原程序的业务逻辑，把实时任务移植到Storm框架上，把批处理任务移植到Spark框架上，并对实时任务和批处理任务进行手动优化。

由表2可以看出：程序A无法满足对实时流量的分析需求以及动态绘图需求，只能在离线模式下实现攻击场景重建功能，但在实际应用场合，脱离了异常流量实时分析的攻击场景重建是没有意义的。程序B依托于底层的Storm计算引擎和Spark计算引擎，可承担实时计算任务和批处理计算任务，但无法提供跨层次动态调用服务，缺乏可重用性和易扩展性。程序C是在程序B的基础上进行手动优化所生成的测试程序，二者所能提供的计算服务完全一致。

为比较上述4个程序的性能，分别以实时处理速度和批处理速度为指标考察各待测程序。离线处理模块使用的测试数据是天津理工大学IDS系统所产生的告警日志（512 240条记录），在测试实时处理模块时，将路由器产生的镜像流量以700 MB/min的速度注入系统并将其作为源数据。实验过程中，提交作业、分发作业等时间开销没有被纳入统计范围，所关注的是待测功能模块的“净处理时间”，而且对于每个程序取其3次测试结果的平均值作为最终性能參数，实验结果如图6和图7所示。运行在Hadoop平台上的攻击场景重建程序所耗费的处理时间比运行在Spark平台上的相同程序多出近1倍，到达11 635 s。主要原因是，攻击场景重建程序涉及大量迭代运算，Hadoop在处理过程中需要多次访问磁盘（读写中间计算结果），而Spark会将中间结果暂存在主存之中，使得在后续迭代过程中尽可能避免磁盘I/O代价。

观察测试结果可以发现，手动优化之后的程序C相较于未调优的原始程序B无论是在实时模块吞吐量还是离线模块处理速度方面都有较大幅度的提高，而且GHCM程序所实现的处理能力十分接近于手动优化之后的水平。

4  结  语

针对高并发实时计算、大批量数据离线计算和动态响应式计算相结合的应用需求，提出一种基于抽象计算单元IStream的通用编程模型，在实现混合计算模式的同时提供了跨层次的可重用性和易扩展性。借助SPG优化技术和底层计算引擎带来的强大计算能力，GHCM中间件系统的性能可以得到足够的保障。对于开发者而言，系统底层繁杂的实现细节完全被GHCM简单的高层抽象所取代，只需把所有精力投入到上层业务逻辑的设计过程中即可。此外，系统内部中间计算结果的传递效率和跨层次交互优化是未来工作中需要着力解决的关键问题。