欢迎访问一起赢论文辅导网
本站动态
联系我们

手机:15327302358
邮箱:peter.lyz@163.com

Q Q:
910330594  
微信paperwinner
工作时间:9:00-24:00

机械论文
当前位置:首页 > 机械论文
支持Unikernel的流式计算引擎:Hummer
来源:一起赢论文网     日期:2019-12-12     浏览数:506     【 字体:

  a large number of services to support various applications and hardware configurations.However,many of them are useless,such as sound card or printer driver,and generally resultsin a huge system size and unnecessary computation overhead.Besides,the hypervisor has tosimulate clock interrupts so that traditional operating systems can work properly,which causesthat most computing resources are consumed by the operating system when there is no workload.To reduce the unnecessary computing overhead caused by useless services,we consider utilizingthe Unikernel to make Hummer bypasses the operating system and run directly on hypervisor orbare-metal environment.Particularly,Hummer also supports quick deployment and startup in acluster.To the author’s best knowledge,we are the first to apply Unikernel to the design of bigdata stream computing engines.Secondly,since localized compilation and third-party librarydependencies make C++applications difficult to deployed in a cluster,we can utilize Unikernelto solve these problems by packaging the application as an image and eliminating the divergence ofmachine using hypervisor.Thirdly,we designed a flexible task-oriented network communicationsolution to decouple the network communication component from TaskManager as normal task.This brings many benefits,such as heterogeneous network support and network source isolation.In most situations,batch processing pays more attention to the throughput,and it almost occupiesall the bandwidth of network IO,thus significantly affects the latency sensitive stream processing.Most existing solutions are not optimized for this situation.Nevertheless,we can solve this problemby isolating batch and stream networks using our flexible task-oriented network configuration.Our experiments show that the end-to-end record processing latencies of Hummer is less than30ms,which is also 1.7xand 15.8xlower than that of Flink and Spark Streaming,respectively.Moreover,the achievable throughput of Hummer is around 2xfaster than that of Flink.TheHummer image using Unikernel is only around 100MB,and the boot time is about 2s.Keywords  big data;data stream;distributed computation;stream processing system;Unikernelsystem1 引 言在现代科学技术快速发展的背景下,社会网络信息呈现爆炸性、指数式增长,传统社会计算正由关联规则挖掘等结构化分析转换为更高层次的宏观知识挖掘,数据量快速增长和多源数据联合分析对大数据计算引擎提出了新的要求.社会计算中,社会公共安全、企业商务智能和舆情计算等领域均体现出实时计算的重要性.如何解决社会计算场景下的海量数据实时计算问题已成为目前急迫之需.传统数据中心中,为了保证环境隔离与管理方便,应用一般独立部署,存在集群资源利用率低、部署和扩展复杂、资源无法动态调整、无法快速响应业务等问题.因此,越来越多的企业通过云计算平台,将传统数据中心运行模式由独立部署升级为混合部署,使用虚拟化技术将计算资源整合,解决传统数据中心中的上述问题.此外,虚拟化技术还可用于众核处理器,通过将处理器模拟为多个单核处理器,提高众核处理器利用率.图 1 集群应用部署模式目前主流集群应用部署模式如图1(a)所示,在物理硬件层使用虚拟化技术以消除硬件差异,复用计算资源并支持动态扩容.虚拟化层之上安装操作系统,并于操作系统之上安装容器服务,以提供良好6571 计  算  机  学  报 2019年.此运行模式中,所有用户应用以容器形式运行于容器服务中.操作系统的功能只是为容器服务提供资源调度等必要支撑,但由于虚拟化技术已包含资源管理等功能,操作系统层变得冗余.因此,为减少传统操作系统无关组件带来的性能开销和消除操作系统与虚拟化层资源调度的冲突,图1(b)将用户应用直接在虚拟化层运行,形成绕过操作系统的部署模式.该模式适用于对延迟敏感的流式处理系统.目前,Spark[1-2]、Storm[3]、Apache Flink[4]等主流计算引擎均不支持绕过操作系统部署模式,依托传统操作系统造成了不必要的性能开销[5],影响计算引擎性能.此外,由于 C++等本地化编译语言可移植性较差,难以解决用户作业在集群中批量部署的问题,大多数计算引擎选择使用JVM 技术实现,其内存访问及垃圾回收机制带来了无关的性能开销.为此,本 文 使 用 C++ 语 言 实 现 了 一 个 支 持Unikernel[6]的流式大数据计算引擎 Hummer.系统通过使用 Dataflow 模型,提供面向流式处理场景的低延迟消息处理服务;同时,系统将批式处理当作特殊的流处理,以实现高吞吐量的批式消息处理.本文所做的贡献主要有:(1)提出了第一个支持 Unikernel的流式大数据计算引擎 Hummer.系统同时支持流式处理和批式 处 理,支 持 分 布 式 环 境 下 的 快 速 部 署 与 启 动.Hummer可绕过传统操作系统,直接部署于虚拟化层或裸机,减少了传统操作系统无关组件带来的性能开销,解决了传统操作系统调度和 Hypervisor调度冲突问题,同时也解决了 C++应用需本地化编译,难以在集群中批量部署的问题.(2)提出全新的网络通信方案,将网络负载当作普通任务负载对待,简化 TaskManager设计,以适配 Unikernel单一地址空间及轻量化设计.同时,系统支持精确到每个任务的网络配置,支持异构网络部署及网络资源物理隔离.(3)本文对比展示了流计算引擎在 Unikernel、Docker以及 CentOS系统下的性能,分析了容器技术及虚拟化技术在流计算引擎应用的优劣,为高性能大数据计算引擎提出新的设计思路.本文第 2 节介绍主流的流计算引擎模型以及Unikernel基本概念;在第3节介绍本系统的设计与实现;在第4节介绍系统的实验设计及实验结果,并给出分析;最后,在第5节总结本文所述工作,并对未来研究做出展望.2 背景及相关工作2.1 大数据计算引擎MapReduce[7]作为第一代计算引擎打开了大数据分析的篇章,通过将算法拆分为 Map 和 Reduce阶段,实现分布式 并 行计算 以 及容错等 功 能.但同时,MapReduce也有表达能力 差、中间结果 存储在HDFS中、磁盘读写开销大以及迭代任务支持性较差等缺点.Tez[8]等 为代表的第 二 代计算引 擎使用灵活的 DAG(Directed Acyclic Graph,有向无环图)取代 MapReduce模型.Spark 与 Flink作为第三代计算引擎代表,在使用 DAG 基础上增加了实时计算功能[2].第 三代 计 算 引 擎使 用的 计 算模 型 分 为BSP(Bulk Synchronous Parallel)模 型和 Dataflow模型两类:(1)BSP模型.MapReduce[7]、Dryad[9-10]、Spark和 FlumeJava[11]等系统使用 BSP[12]模型.如图2所示,模型将计算划分为多个阶段,阶段内部由并行的本地运算组成,阶段之间通过 barrier同步.计算阶段的引入简化了系统容错及资源调度,系统调度器在阶段之间进行快照保存或重新调度等操作即可.由于计算单元随着阶段的转换而改变,因此可减少数据在集群节点间的移动,所以使用 BSP模型的系统吞吐量往往较高,且具有较好的容错和扩展性能.但使用 BSP模型处理流式数据时,需要将流式数据按照时间片 T 划分为 micro-bath计算,其数据处理延迟的下界为 T,且由于每个 micro-batch任务之间需要与 master通信并等待新一轮调度,T 值不能设置太小,否则会显著增加系统调度开销[13].因此,使用 BSP模型的系统往往导致数据处理延迟较高.图 2 BSP模型图(2)Dataflow 模型.Dataflow 模型[14]最早应用于数 据 库 系 统[15-17]中.近 年 来,逐 渐 被 Naiad[18]、Flink[19]、StreamScope[20]等一些追求低延迟的流式计算引擎所使用.如图3所示,Dataflow 模型中,计算不再按照阶段划分,而是转换为由 operator节点8期 李 冰等:支持 Unikernel的流式计算引擎:Hummer7571.operator是系 统 中 的 基 本 计 算 单 元,在系统启动时被创建,随后生存于系统整个生命周期.模型中数据以record形式进入系统,并在 oper-ator间流动.与 BSP 模型不同的是,record间不需要与 master通信或等待新的调度,同时也没有任何barrier,因此 Dataflow 模型的处理延迟非常低.但是由于模型没有计算阶段划分,系统难以选择合适的时机进行快照保存或重新调度等操作,因此使用Dataflow 模型的系统通常需要利用分布式全局一致性快照算法[21]来进行容错.图 3 Dataflow 模型图2.2 微内核操作系统传统操作系统的设计理念是为了支持众多的应用软件和硬件配置,众多的硬件和功能支持使操作系统体积变得庞大,造成了不小的计算资源开销.另外,为了使传统操作系统可以正常工作,Hypervisor必须模拟时钟中断,这使得操作系统在没有负载时也会消耗计算资源,造成资源浪费[22].微内核操作系统(Unikernel)是专用的、单地址空间的、使用 Library OS构建出来的镜像.系统将硬件驱动当作支持库,只编译用户应用需要的驱动,进程间资源调度和硬件适配全部由底 层 Hypervisor负责,实现轻量级操作系统 内核.其具有应用体积小、启动速度快、高安全性、高性能等特性,且由于Unikernel计算资源完全交由 Hypervisor管理,解决了传统操作系统的资源管理和 Hypervisor资源管理冲突造成性能下降的问题.较传统操作系统,Unikernel在虚拟化环境下拥有更好的性能.3 Hummer系统介绍本节详细介绍 Hummer的内部实现,从系统架构开始,介绍了一个 WordCount程序如何从用户代码转换为作业并在集群中执行.本系统使用 C++语言实现,代码约为3万行.3.1 系统架构设计由于主从架构相比无主架构,具有高吞吐、低延迟等特性,且本系统中主节点不会成为性能瓶颈.因此本系统采用主从架构设计,其架构图如图4所示,包含 Client、JobManager和 TaskManager三个部分.图 4 系统架构图用户客户端 Client是用户与系统交互的桥梁,负责将用户代码转换为 DAG 并对其进行优化,随后客户端将 DAG 和 UDF(User-Defined Function)序列化并提交至JobManager等待执行,同时,客户端还支持查看任务进度和取消任务等操作.用户使用 系 统 时,首 先 需 启 动 JobManager实例,JobManager从用户客户端 Client接受作业,并负责作业的管理与调度.TaskManager负责计算节点上计算 资 源 及 作 业 任 务 管 理,可 从 JobManager接受任务,并放于空闲 Slot执行,Slot是系统计算资源管理的基本单位.Hummer采 用 两 种 不 同 方 案 实 现 控 制 流 通信和数据流通信.控制流通 信 用于 JobManager和TaskManager之间传递控制信息.可支持JobManager单节点上万并发连接.数据流通信用于在 TaskManager之间传递用户作业中的数据流信息,通过 TCP Stream实现,并利用 零拷贝、CPU CacheLine优化 等 技 术提升性能.由于 Unikernel应用难以调试.除支持 Unikernel模式外,Hummer还支持传统的单机及分布式环境,便于用户对作业代码及框架进行调试.3.2 编程模型介绍与 Flink等主流流计算系统相似,Hummer使用 DAG 表示用户作业,DAG 中的节点表示用户作8571 计  算  机  学  报 2019年:2018-04-27;在线出版日期:2018-12-28.本课题得到中国科学院战略先导科技专项(A 类)(XDA19020400)资助.李 冰,博士研究生,主要研究方向为流计算系统、存储系统、分布式系统.E-mail:libingqgzy@163.com.张志斌,博士,副研究员,主要研究方向为网络流处理、网络测量.钟巧灵,博士研究生,主要研究方向为深度学习、深度学习系统、分布式系统.程学旗,博士,教授,博士生导师,主要研究领域为信息检索、社会计算、分布式计算.支持 Unikernel的流式计算引擎:Hummer李 冰1),2) 张志斌1),2) 钟巧灵1),2) 程学旗1)1)(中国科学院计算技术研究所 中国科学院网络数据科学与技术重点实验室 北京 100190)2)(中国科学院大学计算机与控制学院 北京 100049)摘 要 社会计算中,社会公共安全、企业商务智能和舆情计算等众多领域均对实时计算的性能提出了越来越高的要求.流式计算引擎作为大数据计算研究领域的研究热点之一,致力于提供高吞吐量和低延迟的实时计算能力.流式处理任务对处理延迟非常敏感,数据价值随着处理时长的增长而快速递减.传统流式计算引擎设计中,操作系统、JVM 等占用大量计算资源,如何提升计算资源利用率成为目前亟待解决的问题.为此,本文提出了一种基于 C++语言实现的支持 Unikernel的高性能实时数据分析计算引擎 Hummer.首先,通过引入 Unikernel机制,Hummer可绕过传统操作系统,直接运行于裸机或虚拟化层,减少传统操作系统无关组件带来的性能开销,支持分布式环境下的快速部署与启动,为高性能大数据计算引擎设计提出新的思路.其次,通过使用 Unikernel对计算引擎进行封装,解决了 C++应用需本地化编译、难以在集群中部署的问题.最后,系统使用灵活的网络通信方案,支持异构网络部署及网络资源隔离.实验表明,Hummer端到端处理延迟低于30ms,较 Flink系统低2倍,较 Spark Streaming低15.8倍,且吞吐量达到 Flink的2倍.使用 Unikernel封装的 Hummer系统镜像仅为100MB,启动时间约为2s.关键词 大数据;数据流;分布式计算;流处理系统;微内核操作系统中图法分类号 TP311   DOI号 10.11897/SP.J.1016.2019.01755Hummer:A Stream Computing Engine with Unikernel SupportLI Bing1),2) ZHANG Zhi-Bin1),2) ZHONG Qiao-Ling1),2) CHENG Xue-Qi 1)1)(CAS Key Laboratory of Network Data Science and Technology,Institute of Computing Technology,Chinese Academy of Sciences,Beijing 100190)2)(School of Computer and Control Engineering,University of Chinese Academy of Sciences,Beijing 100049)Abstract In social computing,it is well-known that the real-time computing plays an importantrole in social public security,business intelligence and public opinion monitoring.Therefore,inorder to provide high throughput and low latency capabilities,the stream computing engine hassprung up recently as a research hotspot in big data computing area.Generally,most streamprocessing tasks is very sensitive to latency,and the data value decreases rapidly as the processingtime increases.In the traditional streaming computing engine design,the operating system,JVM,etc.occupy a large amount of computing resources and suffer from JVM overheads such aspointer chasing and transparent memory management.Lacking their inability to exploit modernCPUs efficiently and not being able to utilize the entire network bandwidth of modern high-speednetworks.How to improve the utilization of computing resources has become an urgent problemto be solved.Therefore,we propose a high-performance real-time stream computing engine,referred to as Hummer,by utilizing C++ programing language and Unikernel.It is known thatthe traditional operating systems,like CentOS,are designed as a general-purpose system and处理任务,边表示数据流动,使用 DAG有两大优势:(1)DAG 允许任务有多个输入输出,简化了诸如Join等经典数据操作的实现;(2)DAG的边明确表达了数据的流通路径,有利于系统对任务调度进行优化.考 虑 到 系 统 对 数 据 处 理 实 时 性 的 要 求,Hummer使用 Dataflow 模型.系统将流式数据抽象为 DataStream,支持从内存、文件、socket、kafka等输入 源 或 其 他 DataStream 的 输 出 创 建.并 通 过map、flatMap、groupBy、reduce等 Transform 操 作进 行 转 换,生 成 新 的 DataStream.系 统 自 动 将Transform 操作分散部署在多个节点并行计算,部署和调度过程对用户完全透明.本文以 WordCount为例,介绍如何从用户代码转换为作业并在集群中执行.过程1为 WordCount用户作业代码.代码2~4行通过JobManager获取StreamExecutionEnvironment对象,对象中记录了用户作业和集群配置等信息,默认情况系统会自动检测计算节点硬件环境进行配置.随后,代码6行从文件source.txt创建 DataStream,7~10行依次在DataStream 上做flatMap、groupBy、count和 print操作,来对 DataStream 进行转换.转换操作均采用抽象接口设计,用户可通过继承相应接口实现 UDF操作.最后,代码11~12行将作业进行命名,并提交给集群执行.流式处理中,execute方法返回作业提交结果,批式处理则阻塞客户端程序直到作业执行完毕,并返回作业执行结果.过程1. WordCount作业.1.//get execution environment from JobManager2.shared_ptr〈StreamExecutionEnvironment〉env3. =StreamExecutionEnvironment4.  ∷getExecutionEnvironment(JobManager);5.//create dataStream from source6.auto dataStream=env→fromFile(“source.txt”);7.dataStream8. →FlatMap(new SplitStringFunction())9. →groupByCount()10. →print〈std∷tuple〈string,int〉〉();11.auto &result=12. env→execute(“Distributed world count.”);3.3 分布式运行说明本小节以 WordCount作业为例,详细介绍了作业从代码至分布式运行的整个流程.用户作业输入系统后进行一些列转换,由作业源代码转换为最终的 ExecutionGraph,并交由 TaskManager执行,作业转换过程如图5所示.图 5 用户作业转换图3.3.1 DAG逻辑视图生成用户代码提交至客户端后首先被转换为Stream-Graph.StreamGraph是未经优化的作业 DAG,其逻辑结构与用户代码相对应.StreamGraph由 Stream-Node和 StreamEdge组 成.StreamNode是 计 算 节点,其中包含SourceOperator、OneInputOperator和TwoInputOperator三 种 operator.SourceOperator负责表示 DAG 中没有输入,只有输出的节点,一般表示用户程序中的数据源输入;OneInputOperator表示 DAG 中只有一个输入的节点,可用于表示用户代码中一个输入对应一个输出的 Map,FlatMap等 操 作,也 可 表 示 只 有 一 个 输 入 但 没 有 输 出 的SinkOperator等 特 殊 节 点,SinkOperator是 DAG中的尾节点,用于表示用户代码中的运算结果输出逻辑;TwoInputOperator表示 DAG 中有两个输入的节点,多个输入可由 OneInputOperator和 TwoInput-Operator组合表示.StreamEdge表示 DAG 中的边,记录了数据在系统中的流动规则.图 6 WordCount StreamGraph图6进一步展示了3.2节中作业 WordCount生成的StreamGraph,图6中每个 StreamNode节点代表了用户代码中对数据流的一次操作,StreamEdge8期 李 冰等:支持 Unikernel的流式计算引擎:Hummer9571流动方向.3.3.2 DAG 逻辑视图优化客户端生成 StreamGraph后通过对其优化,生成JobGraph,并将其提交至JobManager.JobGraph是StreamGraph经优化后的任务逻辑视图,由Job-Vertex和 JobEdge组 成.JobVertex 包 含 Stream-Graph中 的 一 个 或 多 个 StreamNode 计 算 任 务,JobEdge表示JobVertex间的数据流动.系统 支 持 使 用 OP(Operator)融 合 机 制 优 化StreamGraph.OP融合机制使用如图7的规则将关联度较高的operator合并.融合有两大优势:(1)确保关联度较高的operator不会跨节点分布,避免序列化和网络传输开销;(2)避免同节点下 operator通信带来的内存拷贝开销和多线程资源竞争.图8为3.3.1节中 WordCount的StreamGraph图 7 OP融合规则图 8 WordCount JobGraph生成的JobGraph.图中的JobVertex节点代表优化后的数 据 处 理 任 务,已 将 部 分 StreamNode 合 并.JobEdge表示数据流动方向.3.3.3 DAG物理视图生成JobManager收到客户端提交的JobGraph后,JobManager将其 转 换 为 ExecutionGraph.与 抽 象的JobGraph 不同,ExecutionGraph 包 含 了 作 业 执行与 调 度 所 需 的 全 部 信 息,由 StreamTask 和StreamEdge组 成.StreamTask 由 JobGraph 中 的JobVertex结合调度方案生成,包含了作业任务信息与作业 调 度 信 息,与 物 理 执 行 环 境 中 的 任 务 一一对应,是 TaskManager中任 务执行的 基 本单位.StreamEdge包 含 StreamTask 之 间 的 连 接 信 息.图9为由3.3.2节中 WordCount的JobGraph生成的 ExecutionGraph.图 9 WordCount ExecutionGraphJobManager收到JobGraph后,需要对JobGraph中的每个节点确定运行并行度.分配过程中参照用户配置的作业总并行度、节点并行度以及节点最大和最小并行度进行分配.如未指定节点并行度,则根据剩余计算资源平均分配,并保证节点并行度在用户配置允许范围且总并行度不超过用户作业配置.随后JobManager根据并行度设置生成调度方案.由于JobGraph生成时已使用 OP融合机制将关联度较 高的 operator合 并,系统使 用 Round-robin策略生成任务调度策略,并尽量保证JobGraph 中同一节点的不同副本分配至不同 TaskManager.作业 调 度 方 案 生 成 后,结 合 JobGraph 生 成StreamTask,并对相关联节点生成StreamEdge连接0671 计  算  机  学  报 2019年Edge分为 MemoryEdge与NetworkEdge,分别用于连接同节点和跨界点的StreamTask.最后,系统将 NetworkEdge转换为 MemoryEdge和一个负责网络连接的 StreamTask.系统可根据用户网络配置,对不同作业任务节点网络连接分配不同的计算资源,实现灵活的网络配置支持.同时,通过将不同任务封装为统一的 StreamTask,可消除不同任务间的差异,简化 TaskManager的设计.随后JobManager根 据 StreamTask 中 的 调 度 信 息 将StreamTask序列化并发送至对应 TaskManager.3.3.4 任务执行TaskManager收到任务后对其反序列化并初始化 StreamTask对象,并对相关联的 StreamTask使用高性能无锁队列建立连接;跨节点网络连接组件由于已被封装为 StreamTask,在 TaskManager 看来与其余任务无异,故无需关注.随后,TaskManager将封装好的 StreamTask 分配至空闲 Slot执行,Slot是系统资源分配的基本单位,一个Slot代表占用一个CPU 内核.最后,Slot通过StreamTask的invoke()方法启动任务,并通过cancel()和stop()等接口对任务行管理,这种轻量级设计可以使 TaskManager占用更少的资源,更好的适配 Unikernel等单一地址空间场景.由于 Unikernel应用难以调 试,为了便于用户对作业代码及框架进行调试,除支持 Unikernel部署模式外,系统还支持单机以及传统的分布式模式运行.单机环境下,JobManager和 TaskManager之间通过函数调用取代actor机制进行通信,Task之间使用共享内存等方式进行通信,用户作业代码和计算引擎共用同一进程,进一步简化用户代码调试难度.3.4 网络通信设计说明系统网络通信分控制流通信和数据流通信两部分.控制流通信用于在JobManager和 TaskManager间传递控制信息,其特点为 JobManager单节点高并发连接,但传输数据量少.数据流连接用户任务间的数据流传输,并发度低,仅在需要传输数据的任务间建立连接,但传输数据量大,对延迟敏感.基于以上原因,本系统将控制流网络通信和数据流网络通信独立设计:(1)控制流通信.控制流通信使用基于协程机制的 Actor[23]模型实现.模型中最基本的运算单元是actor,每个 actor可完成一组独立的功能,actor之间通过 异 步 消 息 传 递 调 用.使 用 Actor机 制 可以将系统JobManager和 TaskManager解偶,并使JobManager单节点支持上万并发连接.(2)数 据 流 通 信.主 流 流 计 算 引 擎 中,Task-Manager统一负责网络通信传输,这种方式可以简化系统设计实现流程,但同时也降低了系统网络配置的灵活性,单一的网络拓扑结构无法应对复杂的业务 场 景.Hummer使 用 全 新 的 网 络 设 计,Task-Manager不再管理数据流网络通信,而将网络通信当作普通任务负载对待,用户可针对每个任务单独配置网络通信方案.网络通信支持独占一个或多个Slot,也可使用 OP融合机制与任务共享 Slot.与主流方案相比,本方案将网络负载与 TaskManager解耦,简 化 TaskManager 设 计 以 适 配 Unikernel场景,此外,本方案还有以下优势:① 灵活的网络配置.可根据任务优先级和任务类型针对任务单独配置网络模块.网络IO 需求较低的任 务 使 用 OP 融 合 的 形 式 与 任 务 负 载 共 享Slot,降低内存拷贝等开销;网络IO 需求较高的任务可单独占用一个或多个 Slot来满足其较高的网络性能需求.② 异构网络支持.针对不同的任务连接不同的硬件网络环境,实现异构网络接入支持.③ 网络 资 源 隔 离.在 传 统 批 式 处 理 流 程 中,Shuffle阶段对网络带宽使用率较高,通常情况下会占用几乎全部网络资源,严重影响到对延迟敏感的流式处理系统,目前工业界常常将流式处理和批式处理分别部署于两个物理集群,以减少批式处理对流式处理的影响.Hummer通过在同一集群中对批式处理和流式处理分别使用不同的网络接口,做到物理网络隔离,减少批式处理中网络带宽占用对流式处理的影响,在提高集群资源利用率的同时降低维护成本.3.5 容错及扩展说明与 BSP模型不同,Dataflow 模型由于没有计算阶段划分,难以在同一时刻对系统记录全局快照,容错较为困难,本系统使用分布式全局一致性快照算法[24]实现容错,支持 Exactly-once语义.系 统每隔固定时间间隔记录全局快照并备份输入源位置,出错时将所有计算节点恢复至最近快照并回退输入源至相应位置.系统要求数据源可缓存数据并可从任意时刻回放.如图10所示,系统每隔固定的时间向数据源中注入 Barrier,并使之随数据记录在 DAG 中流动,当Barrier流动到计算节点时,计算节点会对当前的状态记录快照,当 Barrier流动到Sink节点时,全局快照记录完成,整个快 照记录 过 程中,数据流无需暂8期 李 冰等:支持 Unikernel的流式计算引擎:Hummer1671停,快照记录代价较小.但当系统出错时,需要将全部计算节点恢复至最近快照状态,并回退输入流至相应位置,数据恢复代价较大.图 10 分布式全局一致性快照算法4 实 验4.1 实验环境实验集群由四台服务器组成,其中一台机器作为JobManager和 TaskManager共享使用,三台机器 TaskManager 独 享 使 用,服 务 器 CPU 配 置 为Intel(R)Xeon(R)CPU E5-2640v4@2.40GHzx2、内存128GB、10Gbps网卡.操作系统为 CentOS7.3、内核为3.10.0、GCC编译器版本6.2.1、QEMU版本2.0.0.实验数据集使用小说《Game of Thrones》多次拼接生成,文本大小16GB,共155 800 000行,包含单词2 900 520 000个,实验从批式处理和流式处理两个方面比较 Hummer与 Flink、Spark的性能,并对比虚拟化环境下使用 Unikernel封装的 Hummer与 CentOS系统封装的 Flink性能差距,实验 Spark版 本 为 spark-2.2.0-bin-hadoop2.7,Flink 版 本 为1.4.2-hadoop28-scala_2.11.4.2 批式处理批处理实验任务流程如图11所示,实验使用小说文本文 件 做 数 据 源,系 统 读 入 数 据 后 依 次 进 行字符串分割、GroupBy和 Sum 操作,最后将计算结果写入磁盘保存.实验从 CPU、内存、吞吐量三方面比较 单 机 环 境 和 四 节 点 集 群 环 境 下 Hummer 与Spark、Spark Streaming和Flink在 CentOS系统下的性能.实验中所有系统均使用最大系统资源配置,且关闭容错功能.图 11 批式处理实验任务流程图系统在单机环境下的吞吐量如表1所示,Spark由于使用 BSP模型,其吞吐量对比 Dataflow 模型的Flink与 Hummer具有先天优势.实验表明,Hummer吞吐量约为同样使用 Dataflow 模型的 Flink系统的两倍,与使用 BSP 模型的 Spark和 Spark Streaming相差无几.由图12系统 CPU 使用率对比图可以看出,Flink和Spark几乎占满了CPU 资源,而 Hummer的 CPU 使用率约为80%,如能提升IO 性能,系统整体性能会有进一步提升.图13为系统内存使用率对比图,可以看出,Hummer做为针对虚拟化环境优化的轻量级系统,内存利用率明显低于 Spark和 Flink.在4节点集群环境下,Hummer依然保持较好的性能,由于硬件资源I/O 限制,四个系统均未达到线性扩展,但由表2可以看出,Hummer在四节点分布式环境下依然具有良好的性能.表 1 单机环境性能对比表系统名称 任务耗时/s 吞吐量/(MB/s)Spark  96  170.66Spark Streaming  101  162.21Flink  236  69.42Hummer  115  142.47表 2 四节点集群环境性能对比表系统名称 任务耗时/s 吞吐量/(MB/s)Spark  38  431.15Spark Streaming  65  252.06Flink  80  204.80Hummer  41  399.61图 12 系统 CPU 利用率对比图图 13 系统内存利用率对比图2671 计  算  机  学  报 2019年

[返回]
上一篇:智能家居场景联动中基于知识图谱的隐式冲突检测方法研究
下一篇:通用串预测算法及在AVS2屏幕与混合内容视频编码中的应用