ａ　ｌａｒｇｅ　ｎｕｍｂｅｒ　ｏｆ　ｓｅｒｖｉｃｅｓ　ｔｏ　ｓｕｐｐｏｒｔ　ｖａｒｉｏｕｓ　ａｐｐｌｉｃａｔｉｏｎｓ　ａｎｄ　ｈａｒｄｗａｒｅ　ｃｏｎｆｉｇｕｒａｔｉｏｎｓ．Ｈｏｗｅｖｅｒ，ｍａｎｙ　ｏｆ　ｔｈｅｍ　ａｒｅ　ｕｓｅｌｅｓｓ，ｓｕｃｈ　ａｓ　ｓｏｕｎｄ　ｃａｒｄ　ｏｒ　ｐｒｉｎｔｅｒ　ｄｒｉｖｅｒ，ａｎｄ　ｇｅｎｅｒａｌｌｙ　ｒｅｓｕｌｔｓｉｎ　ａ　ｈｕｇｅ　ｓｙｓｔｅｍ　ｓｉｚｅ　ａｎｄ　ｕｎｎｅｃｅｓｓａｒｙ　ｃｏｍｐｕｔａｔｉｏｎ　ｏｖｅｒｈｅａｄ．Ｂｅｓｉｄｅｓ，ｔｈｅ　ｈｙｐｅｒｖｉｓｏｒ　ｈａｓ　ｔｏｓｉｍｕｌａｔｅ　ｃｌｏｃｋ　ｉｎｔｅｒｒｕｐｔｓ　ｓｏ　ｔｈａｔ　ｔｒａｄｉｔｉｏｎａｌ　ｏｐｅｒａｔｉｎｇ　ｓｙｓｔｅｍｓ　ｃａｎ　ｗｏｒｋ　ｐｒｏｐｅｒｌｙ，ｗｈｉｃｈ　ｃａｕｓｅｓｔｈａｔ　ｍｏｓｔ　ｃｏｍｐｕｔｉｎｇ　ｒｅｓｏｕｒｃｅｓ　ａｒｅ　ｃｏｎｓｕｍｅｄ　ｂｙ　ｔｈｅ　ｏｐｅｒａｔｉｎｇ　ｓｙｓｔｅｍ　ｗｈｅｎ　ｔｈｅｒｅ　ｉｓ　ｎｏ　ｗｏｒｋｌｏａｄ．Ｔｏ　ｒｅｄｕｃｅ　ｔｈｅ　ｕｎｎｅｃｅｓｓａｒｙ　ｃｏｍｐｕｔｉｎｇ　ｏｖｅｒｈｅａｄ　ｃａｕｓｅｄ　ｂｙ　ｕｓｅｌｅｓｓ　ｓｅｒｖｉｃｅｓ，ｗｅ　ｃｏｎｓｉｄｅｒ　ｕｔｉｌｉｚｉｎｇｔｈｅ　Ｕｎｉｋｅｒｎｅｌ　ｔｏ　ｍａｋｅ　Ｈｕｍｍｅｒ　ｂｙｐａｓｓｅｓ　ｔｈｅ　ｏｐｅｒａｔｉｎｇ　ｓｙｓｔｅｍ　ａｎｄ　ｒｕｎ　ｄｉｒｅｃｔｌｙ　ｏｎ　ｈｙｐｅｒｖｉｓｏｒ　ｏｒｂａｒｅ－ｍｅｔａｌ　ｅｎｖｉｒｏｎｍｅｎｔ．Ｐａｒｔｉｃｕｌａｒｌｙ，Ｈｕｍｍｅｒ　ａｌｓｏ　ｓｕｐｐｏｒｔｓ　ｑｕｉｃｋ　ｄｅｐｌｏｙｍｅｎｔ　ａｎｄ　ｓｔａｒｔｕｐ　ｉｎ　ａｃｌｕｓｔｅｒ．Ｔｏ　ｔｈｅ　ａｕｔｈｏｒ’ｓ　ｂｅｓｔ　ｋｎｏｗｌｅｄｇｅ，ｗｅ　ａｒｅ　ｔｈｅ　ｆｉｒｓｔ　ｔｏ　ａｐｐｌｙ　Ｕｎｉｋｅｒｎｅｌ　ｔｏ　ｔｈｅ　ｄｅｓｉｇｎ　ｏｆ　ｂｉｇｄａｔａ　ｓｔｒｅａｍ　ｃｏｍｐｕｔｉｎｇ　ｅｎｇｉｎｅｓ．Ｓｅｃｏｎｄｌｙ，ｓｉｎｃｅ　ｌｏｃａｌｉｚｅｄ　ｃｏｍｐｉｌａｔｉｏｎ　ａｎｄ　ｔｈｉｒｄ－ｐａｒｔｙ　ｌｉｂｒａｒｙｄｅｐｅｎｄｅｎｃｉｅｓ　ｍａｋｅ　Ｃ＋＋ａｐｐｌｉｃａｔｉｏｎｓ　ｄｉｆｆｉｃｕｌｔ　ｔｏ　ｄｅｐｌｏｙｅｄ　ｉｎ　ａ　ｃｌｕｓｔｅｒ，ｗｅ　ｃａｎ　ｕｔｉｌｉｚｅ　Ｕｎｉｋｅｒｎｅｌｔｏ　ｓｏｌｖｅ　ｔｈｅｓｅ　ｐｒｏｂｌｅｍｓ　ｂｙ　ｐａｃｋａｇｉｎｇ　ｔｈｅ　ａｐｐｌｉｃａｔｉｏｎ　ａｓ　ａｎ　ｉｍａｇｅ　ａｎｄ　ｅｌｉｍｉｎａｔｉｎｇ　ｔｈｅ　ｄｉｖｅｒｇｅｎｃｅ　ｏｆｍａｃｈｉｎｅ　ｕｓｉｎｇ　ｈｙｐｅｒｖｉｓｏｒ．Ｔｈｉｒｄｌｙ，ｗｅ　ｄｅｓｉｇｎｅｄ　ａ　ｆｌｅｘｉｂｌｅ　ｔａｓｋ－ｏｒｉｅｎｔｅｄ　ｎｅｔｗｏｒｋ　ｃｏｍｍｕｎｉｃａｔｉｏｎｓｏｌｕｔｉｏｎ　ｔｏ　ｄｅｃｏｕｐｌｅ　ｔｈｅ　ｎｅｔｗｏｒｋ　ｃｏｍｍｕｎｉｃａｔｉｏｎ　ｃｏｍｐｏｎｅｎｔ　ｆｒｏｍ　ＴａｓｋＭａｎａｇｅｒ　ａｓ　ｎｏｒｍａｌ　ｔａｓｋ．Ｔｈｉｓ　ｂｒｉｎｇｓ　ｍａｎｙ　ｂｅｎｅｆｉｔｓ，ｓｕｃｈ　ａｓ　ｈｅｔｅｒｏｇｅｎｅｏｕｓ　ｎｅｔｗｏｒｋ　ｓｕｐｐｏｒｔ　ａｎｄ　ｎｅｔｗｏｒｋ　ｓｏｕｒｃｅ　ｉｓｏｌａｔｉｏｎ．Ｉｎ　ｍｏｓｔ　ｓｉｔｕａｔｉｏｎｓ，ｂａｔｃｈ　ｐｒｏｃｅｓｓｉｎｇ　ｐａｙｓ　ｍｏｒｅ　ａｔｔｅｎｔｉｏｎ　ｔｏ　ｔｈｅ　ｔｈｒｏｕｇｈｐｕｔ，ａｎｄ　ｉｔ　ａｌｍｏｓｔ　ｏｃｃｕｐｉｅｓａｌｌ　ｔｈｅ　ｂａｎｄｗｉｄｔｈ　ｏｆ　ｎｅｔｗｏｒｋ　ＩＯ，ｔｈｕｓ　ｓｉｇｎｉｆｉｃａｎｔｌｙ　ａｆｆｅｃｔｓ　ｔｈｅ　ｌａｔｅｎｃｙ　ｓｅｎｓｉｔｉｖｅ　ｓｔｒｅａｍ　ｐｒｏｃｅｓｓｉｎｇ．Ｍｏｓｔ　ｅｘｉｓｔｉｎｇ　ｓｏｌｕｔｉｏｎｓ　ａｒｅ　ｎｏｔ　ｏｐｔｉｍｉｚｅｄ　ｆｏｒ　ｔｈｉｓ　ｓｉｔｕａｔｉｏｎ．Ｎｅｖｅｒｔｈｅｌｅｓｓ，ｗｅ　ｃａｎ　ｓｏｌｖｅ　ｔｈｉｓ　ｐｒｏｂｌｅｍｂｙ　ｉｓｏｌａｔｉｎｇ　ｂａｔｃｈ　ａｎｄ　ｓｔｒｅａｍ　ｎｅｔｗｏｒｋｓ　ｕｓｉｎｇ　ｏｕｒ　ｆｌｅｘｉｂｌｅ　ｔａｓｋ－ｏｒｉｅｎｔｅｄ　ｎｅｔｗｏｒｋ　ｃｏｎｆｉｇｕｒａｔｉｏｎ．Ｏｕｒ　ｅｘｐｅｒｉｍｅｎｔｓ　ｓｈｏｗ　ｔｈａｔ　ｔｈｅ　ｅｎｄ－ｔｏ－ｅｎｄ　ｒｅｃｏｒｄ　ｐｒｏｃｅｓｓｉｎｇ　ｌａｔｅｎｃｉｅｓ　ｏｆ　Ｈｕｍｍｅｒ　ｉｓ　ｌｅｓｓ　ｔｈａｎ３０ｍｓ，ｗｈｉｃｈ　ｉｓ　ａｌｓｏ　１．７ｘａｎｄ　１５．８ｘｌｏｗｅｒ　ｔｈａｎ　ｔｈａｔ　ｏｆ　Ｆｌｉｎｋ　ａｎｄ　Ｓｐａｒｋ　Ｓｔｒｅａｍｉｎｇ，ｒｅｓｐｅｃｔｉｖｅｌｙ．Ｍｏｒｅｏｖｅｒ，ｔｈｅ　ａｃｈｉｅｖａｂｌｅ　ｔｈｒｏｕｇｈｐｕｔ　ｏｆ　Ｈｕｍｍｅｒ　ｉｓ　ａｒｏｕｎｄ　２ｘｆａｓｔｅｒ　ｔｈａｎ　ｔｈａｔ　ｏｆ　Ｆｌｉｎｋ．ＴｈｅＨｕｍｍｅｒ　ｉｍａｇｅ　ｕｓｉｎｇ　Ｕｎｉｋｅｒｎｅｌ　ｉｓ　ｏｎｌｙ　ａｒｏｕｎｄ　１００ＭＢ，ａｎｄ　ｔｈｅ　ｂｏｏｔ　ｔｉｍｅ　ｉｓ　ａｂｏｕｔ　２ｓ．Ｋｅｙｗｏｒｄｓ　 ｂｉｇ　ｄａｔａ；ｄａｔａ　ｓｔｒｅａｍ；ｄｉｓｔｒｉｂｕｔｅｄ　ｃｏｍｐｕｔａｔｉｏｎ；ｓｔｒｅａｍ　ｐｒｏｃｅｓｓｉｎｇ　ｓｙｓｔｅｍ；Ｕｎｉｋｅｒｎｅｌｓｙｓｔｅｍ１　引　言在现代科学技术快速发展的背景下，社会网络信息呈现爆炸性、指数式增长，传统社会计算正由关联规则挖掘等结构化分析转换为更高层次的宏观知识挖掘，数据量快速增长和多源数据联合分析对大数据计算引擎提出了新的要求．社会计算中，社会公共安全、企业商务智能和舆情计算等领域均体现出实时计算的重要性．如何解决社会计算场景下的海量数据实时计算问题已成为目前急迫之需．传统数据中心中，为了保证环境隔离与管理方便，应用一般独立部署，存在集群资源利用率低、部署和扩展复杂、资源无法动态调整、无法快速响应业务等问题．因此，越来越多的企业通过云计算平台，将传统数据中心运行模式由独立部署升级为混合部署，使用虚拟化技术将计算资源整合，解决传统数据中心中的上述问题．此外，虚拟化技术还可用于众核处理器，通过将处理器模拟为多个单核处理器，提高众核处理器利用率．图 １　集群应用部署模式目前主流集群应用部署模式如图１（ａ）所示，在物理硬件层使用虚拟化技术以消除硬件差异，复用计算资源并支持动态扩容．虚拟化层之上安装操作系统，并于操作系统之上安装容器服务，以提供良好６５７１ 计　　算　　机　　学　　报 ２０１９年．此运行模式中，所有用户应用以容器形式运行于容器服务中．操作系统的功能只是为容器服务提供资源调度等必要支撑，但由于虚拟化技术已包含资源管理等功能，操作系统层变得冗余．因此，为减少传统操作系统无关组件带来的性能开销和消除操作系统与虚拟化层资源调度的冲突，图１（ｂ）将用户应用直接在虚拟化层运行，形成绕过操作系统的部署模式．该模式适用于对延迟敏感的流式处理系统．目前，Ｓｐａｒｋ［１－２］、Ｓｔｏｒｍ［３］、Ａｐａｃｈｅ　Ｆｌｉｎｋ［４］等主流计算引擎均不支持绕过操作系统部署模式，依托传统操作系统造成了不必要的性能开销［５］，影响计算引擎性能．此外，由于 Ｃ＋＋等本地化编译语言可移植性较差，难以解决用户作业在集群中批量部署的问题，大多数计算引擎选择使用ＪＶＭ 技术实现，其内存访问及垃圾回收机制带来了无关的性能开销．为此，本 文 使 用 Ｃ＋＋ 语 言 实 现 了 一 个 支 持Ｕｎｉｋｅｒｎｅｌ［６］的流式大数据计算引擎 Ｈｕｍｍｅｒ．系统通过使用 Ｄａｔａｆｌｏｗ 模型，提供面向流式处理场景的低延迟消息处理服务；同时，系统将批式处理当作特殊的流处理，以实现高吞吐量的批式消息处理．本文所做的贡献主要有：（１）提出了第一个支持 Ｕｎｉｋｅｒｎｅｌ的流式大数据计算引擎 Ｈｕｍｍｅｒ．系统同时支持流式处理和批式 处 理，支 持 分 布 式 环 境 下 的 快 速 部 署 与 启 动．Ｈｕｍｍｅｒ可绕过传统操作系统，直接部署于虚拟化层或裸机，减少了传统操作系统无关组件带来的性能开销，解决了传统操作系统调度和 Ｈｙｐｅｒｖｉｓｏｒ调度冲突问题，同时也解决了 Ｃ＋＋应用需本地化编译，难以在集群中批量部署的问题．（２）提出全新的网络通信方案，将网络负载当作普通任务负载对待，简化 ＴａｓｋＭａｎａｇｅｒ设计，以适配 Ｕｎｉｋｅｒｎｅｌ单一地址空间及轻量化设计．同时，系统支持精确到每个任务的网络配置，支持异构网络部署及网络资源物理隔离．（３）本文对比展示了流计算引擎在 Ｕｎｉｋｅｒｎｅｌ、Ｄｏｃｋｅｒ以及 ＣｅｎｔＯＳ系统下的性能，分析了容器技术及虚拟化技术在流计算引擎应用的优劣，为高性能大数据计算引擎提出新的设计思路．本文第 ２ 节介绍主流的流计算引擎模型以及Ｕｎｉｋｅｒｎｅｌ基本概念；在第３节介绍本系统的设计与实现；在第４节介绍系统的实验设计及实验结果，并给出分析；最后，在第５节总结本文所述工作，并对未来研究做出展望．２　背景及相关工作２．１　大数据计算引擎ＭａｐＲｅｄｕｃｅ［７］作为第一代计算引擎打开了大数据分析的篇章，通过将算法拆分为 Ｍａｐ 和 Ｒｅｄｕｃｅ阶段，实现分布式 并 行计算 以 及容错等 功 能．但同时，ＭａｐＲｅｄｕｃｅ也有表达能力 差、中间结果 存储在ＨＤＦＳ中、磁盘读写开销大以及迭代任务支持性较差等缺点．Ｔｅｚ［８］等 为代表的第 二 代计算引 擎使用灵活的 ＤＡＧ（Ｄｉｒｅｃｔｅｄ　Ａｃｙｃｌｉｃ　Ｇｒａｐｈ，有向无环图）取代 ＭａｐＲｅｄｕｃｅ模型．Ｓｐａｒｋ 与 Ｆｌｉｎｋ作为第三代计算引擎代表，在使用 ＤＡＧ 基础上增加了实时计算功能［２］．第 三代 计 算 引 擎使 用的 计 算模 型 分 为ＢＳＰ（Ｂｕｌｋ　Ｓｙｎｃｈｒｏｎｏｕｓ　Ｐａｒａｌｌｅｌ）模 型和 Ｄａｔａｆｌｏｗ模型两类：（１）ＢＳＰ模型．ＭａｐＲｅｄｕｃｅ［７］、Ｄｒｙａｄ［９－１０］、Ｓｐａｒｋ和 ＦｌｕｍｅＪａｖａ［１１］等系统使用 ＢＳＰ［１２］模型．如图２所示，模型将计算划分为多个阶段，阶段内部由并行的本地运算组成，阶段之间通过 ｂａｒｒｉｅｒ同步．计算阶段的引入简化了系统容错及资源调度，系统调度器在阶段之间进行快照保存或重新调度等操作即可．由于计算单元随着阶段的转换而改变，因此可减少数据在集群节点间的移动，所以使用 ＢＳＰ模型的系统吞吐量往往较高，且具有较好的容错和扩展性能．但使用 ＢＳＰ模型处理流式数据时，需要将流式数据按照时间片 Ｔ 划分为 ｍｉｃｒｏ－ｂａｔｈ计算，其数据处理延迟的下界为 Ｔ，且由于每个 ｍｉｃｒｏ－ｂａｔｃｈ任务之间需要与 ｍａｓｔｅｒ通信并等待新一轮调度，Ｔ 值不能设置太小，否则会显著增加系统调度开销［１３］．因此，使用 ＢＳＰ模型的系统往往导致数据处理延迟较高．图 ２　ＢＳＰ模型图（２）Ｄａｔａｆｌｏｗ 模型．Ｄａｔａｆｌｏｗ 模型［１４］最早应用于数 据 库 系 统［１５－１７］中．近 年 来，逐 渐 被 Ｎａｉａｄ［１８］、Ｆｌｉｎｋ［１９］、ＳｔｒｅａｍＳｃｏｐｅ［２０］等一些追求低延迟的流式计算引擎所使用．如图３所示，Ｄａｔａｆｌｏｗ 模型中，计算不再按照阶段划分，而是转换为由 ｏｐｅｒａｔｏｒ节点８期 李　冰等：支持 Ｕｎｉｋｅｒｎｅｌ的流式计算引擎：Ｈｕｍｍｅｒ７５７１．ｏｐｅｒａｔｏｒ是系 统 中 的 基 本 计 算 单 元，在系统启动时被创建，随后生存于系统整个生命周期．模型中数据以ｒｅｃｏｒｄ形式进入系统，并在 ｏｐｅｒ－ａｔｏｒ间流动．与 ＢＳＰ 模型不同的是，ｒｅｃｏｒｄ间不需要与 ｍａｓｔｅｒ通信或等待新的调度，同时也没有任何ｂａｒｒｉｅｒ，因此 Ｄａｔａｆｌｏｗ 模型的处理延迟非常低．但是由于模型没有计算阶段划分，系统难以选择合适的时机进行快照保存或重新调度等操作，因此使用Ｄａｔａｆｌｏｗ 模型的系统通常需要利用分布式全局一致性快照算法［２１］来进行容错．图 ３　Ｄａｔａｆｌｏｗ 模型图２．２　微内核操作系统传统操作系统的设计理念是为了支持众多的应用软件和硬件配置，众多的硬件和功能支持使操作系统体积变得庞大，造成了不小的计算资源开销．另外，为了使传统操作系统可以正常工作，Ｈｙｐｅｒｖｉｓｏｒ必须模拟时钟中断，这使得操作系统在没有负载时也会消耗计算资源，造成资源浪费［２２］．微内核操作系统（Ｕｎｉｋｅｒｎｅｌ）是专用的、单地址空间的、使用 Ｌｉｂｒａｒｙ　ＯＳ构建出来的镜像．系统将硬件驱动当作支持库，只编译用户应用需要的驱动，进程间资源调度和硬件适配全部由底 层 Ｈｙｐｅｒｖｉｓｏｒ负责，实现轻量级操作系统 内核．其具有应用体积小、启动速度快、高安全性、高性能等特性，且由于Ｕｎｉｋｅｒｎｅｌ计算资源完全交由 Ｈｙｐｅｒｖｉｓｏｒ管理，解决了传统操作系统的资源管理和 Ｈｙｐｅｒｖｉｓｏｒ资源管理冲突造成性能下降的问题．较传统操作系统，Ｕｎｉｋｅｒｎｅｌ在虚拟化环境下拥有更好的性能．３　Ｈｕｍｍｅｒ系统介绍本节详细介绍 Ｈｕｍｍｅｒ的内部实现，从系统架构开始，介绍了一个 ＷｏｒｄＣｏｕｎｔ程序如何从用户代码转换为作业并在集群中执行．本系统使用 Ｃ＋＋语言实现，代码约为３万行．３．１　系统架构设计由于主从架构相比无主架构，具有高吞吐、低延迟等特性，且本系统中主节点不会成为性能瓶颈．因此本系统采用主从架构设计，其架构图如图４所示，包含 Ｃｌｉｅｎｔ、ＪｏｂＭａｎａｇｅｒ和 ＴａｓｋＭａｎａｇｅｒ三个部分．图 ４　系统架构图用户客户端 Ｃｌｉｅｎｔ是用户与系统交互的桥梁，负责将用户代码转换为 ＤＡＧ 并对其进行优化，随后客户端将 ＤＡＧ 和 ＵＤＦ（Ｕｓｅｒ－Ｄｅｆｉｎｅｄ　Ｆｕｎｃｔｉｏｎ）序列化并提交至ＪｏｂＭａｎａｇｅｒ等待执行，同时，客户端还支持查看任务进度和取消任务等操作．用户使用 系 统 时，首 先 需 启 动 ＪｏｂＭａｎａｇｅｒ实例，ＪｏｂＭａｎａｇｅｒ从用户客户端 Ｃｌｉｅｎｔ接受作业，并负责作业的管理与调度．ＴａｓｋＭａｎａｇｅｒ负责计算节点上计算 资 源 及 作 业 任 务 管 理，可 从 ＪｏｂＭａｎａｇｅｒ接受任务，并放于空闲 Ｓｌｏｔ执行，Ｓｌｏｔ是系统计算资源管理的基本单位．Ｈｕｍｍｅｒ采 用 两 种 不 同 方 案 实 现 控 制 流 通信和数据流通信．控制流通 信 用于 ＪｏｂＭａｎａｇｅｒ和ＴａｓｋＭａｎａｇｅｒ之间传递控制信息．可支持ＪｏｂＭａｎａｇｅｒ单节点上万并发连接．数据流通信用于在 ＴａｓｋＭａｎａｇｅｒ之间传递用户作业中的数据流信息，通过 ＴＣＰ　Ｓｔｒｅａｍ实现，并利用 零拷贝、ＣＰＵ　ＣａｃｈｅＬｉｎｅ优化 等 技 术提升性能．由于 Ｕｎｉｋｅｒｎｅｌ应用难以调试．除支持 Ｕｎｉｋｅｒｎｅｌ模式外，Ｈｕｍｍｅｒ还支持传统的单机及分布式环境，便于用户对作业代码及框架进行调试．３．２　编程模型介绍与 Ｆｌｉｎｋ等主流流计算系统相似，Ｈｕｍｍｅｒ使用 ＤＡＧ 表示用户作业，ＤＡＧ 中的节点表示用户作８５７１ 计　　算　　机　　学　　报 ２０１９年：２０１８－０４－２７；在线出版日期：２０１８－１２－２８．本课题得到中国科学院战略先导科技专项（Ａ 类）（ＸＤＡ１９０２０４００）资助．李　冰，博士研究生，主要研究方向为流计算系统、存储系统、分布式系统．Ｅ－ｍａｉｌ：ｌｉｂｉｎｇｑｇｚｙ＠１６３．ｃｏｍ．张志斌，博士，副研究员，主要研究方向为网络流处理、网络测量．钟巧灵，博士研究生，主要研究方向为深度学习、深度学习系统、分布式系统．程学旗，博士，教授，博士生导师，主要研究领域为信息检索、社会计算、分布式计算．支持 Ｕｎｉｋｅｒｎｅｌ的流式计算引擎：Ｈｕｍｍｅｒ李　冰１），２）　张志斌１），２）　钟巧灵１），２）　程学旗１）１）（中国科学院计算技术研究所 中国科学院网络数据科学与技术重点实验室　北京　１００１９０）２）（中国科学院大学计算机与控制学院　北京　１０００４９）摘　要　社会计算中，社会公共安全、企业商务智能和舆情计算等众多领域均对实时计算的性能提出了越来越高的要求．流式计算引擎作为大数据计算研究领域的研究热点之一，致力于提供高吞吐量和低延迟的实时计算能力．流式处理任务对处理延迟非常敏感，数据价值随着处理时长的增长而快速递减．传统流式计算引擎设计中，操作系统、ＪＶＭ 等占用大量计算资源，如何提升计算资源利用率成为目前亟待解决的问题．为此，本文提出了一种基于 Ｃ＋＋语言实现的支持 Ｕｎｉｋｅｒｎｅｌ的高性能实时数据分析计算引擎 Ｈｕｍｍｅｒ．首先，通过引入 Ｕｎｉｋｅｒｎｅｌ机制，Ｈｕｍｍｅｒ可绕过传统操作系统，直接运行于裸机或虚拟化层，减少传统操作系统无关组件带来的性能开销，支持分布式环境下的快速部署与启动，为高性能大数据计算引擎设计提出新的思路．其次，通过使用 Ｕｎｉｋｅｒｎｅｌ对计算引擎进行封装，解决了 Ｃ＋＋应用需本地化编译、难以在集群中部署的问题．最后，系统使用灵活的网络通信方案，支持异构网络部署及网络资源隔离．实验表明，Ｈｕｍｍｅｒ端到端处理延迟低于３０ｍｓ，较 Ｆｌｉｎｋ系统低２倍，较 Ｓｐａｒｋ　Ｓｔｒｅａｍｉｎｇ低１５．８倍，且吞吐量达到 Ｆｌｉｎｋ的２倍．使用 Ｕｎｉｋｅｒｎｅｌ封装的 Ｈｕｍｍｅｒ系统镜像仅为１００ＭＢ，启动时间约为２ｓ．关键词　大数据；数据流；分布式计算；流处理系统；微内核操作系统中图法分类号 ＴＰ３１１　　　ＤＯＩ号 １０．１１８９７／ＳＰ．Ｊ．１０１６．２０１９．０１７５５Ｈｕｍｍｅｒ：Ａ　Ｓｔｒｅａｍ　Ｃｏｍｐｕｔｉｎｇ　Ｅｎｇｉｎｅ　ｗｉｔｈ　Ｕｎｉｋｅｒｎｅｌ　ＳｕｐｐｏｒｔＬＩ　Ｂｉｎｇ１），２）　ＺＨＡＮＧ　Ｚｈｉ－Ｂｉｎ１），２）　ＺＨＯＮＧ　Ｑｉａｏ－Ｌｉｎｇ１），２）　ＣＨＥＮＧ　Ｘｕｅ－Ｑｉ　１）１）（ＣＡＳ　Ｋｅｙ　Ｌａｂｏｒａｔｏｒｙ　ｏｆ　Ｎｅｔｗｏｒｋ　Ｄａｔａ　Ｓｃｉｅｎｃｅ　ａｎｄ　Ｔｅｃｈｎｏｌｏｇｙ，Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｃｏｍｐｕｔｉｎｇ　Ｔｅｃｈｎｏｌｏｇｙ，Ｃｈｉｎｅｓｅ　Ａｃａｄｅｍｙ　ｏｆ　Ｓｃｉｅｎｃｅｓ，Ｂｅｉｊｉｎｇ　１００１９０）２）（Ｓｃｈｏｏｌ　ｏｆ　Ｃｏｍｐｕｔｅｒ　ａｎｄ　Ｃｏｎｔｒｏｌ　Ｅｎｇｉｎｅｅｒｉｎｇ，Ｕｎｉｖｅｒｓｉｔｙ　ｏｆ　Ｃｈｉｎｅｓｅ　Ａｃａｄｅｍｙ　ｏｆ　Ｓｃｉｅｎｃｅｓ，Ｂｅｉｊｉｎｇ　１０００４９）Ａｂｓｔｒａｃｔ　Ｉｎ　ｓｏｃｉａｌ　ｃｏｍｐｕｔｉｎｇ，ｉｔ　ｉｓ　ｗｅｌｌ－ｋｎｏｗｎ　ｔｈａｔ　ｔｈｅ　ｒｅａｌ－ｔｉｍｅ　ｃｏｍｐｕｔｉｎｇ　ｐｌａｙｓ　ａｎ　ｉｍｐｏｒｔａｎｔｒｏｌｅ　ｉｎ　ｓｏｃｉａｌ　ｐｕｂｌｉｃ　ｓｅｃｕｒｉｔｙ，ｂｕｓｉｎｅｓｓ　ｉｎｔｅｌｌｉｇｅｎｃｅ　ａｎｄ　ｐｕｂｌｉｃ　ｏｐｉｎｉｏｎ　ｍｏｎｉｔｏｒｉｎｇ．Ｔｈｅｒｅｆｏｒｅ，ｉｎｏｒｄｅｒ　ｔｏ　ｐｒｏｖｉｄｅ　ｈｉｇｈ　ｔｈｒｏｕｇｈｐｕｔ　ａｎｄ　ｌｏｗ　ｌａｔｅｎｃｙ　ｃａｐａｂｉｌｉｔｉｅｓ，ｔｈｅ　ｓｔｒｅａｍ　ｃｏｍｐｕｔｉｎｇ　ｅｎｇｉｎｅ　ｈａｓｓｐｒｕｎｇ　ｕｐ　ｒｅｃｅｎｔｌｙ　ａｓ　ａ　ｒｅｓｅａｒｃｈ　ｈｏｔｓｐｏｔ　ｉｎ　ｂｉｇ　ｄａｔａ　ｃｏｍｐｕｔｉｎｇ　ａｒｅａ．Ｇｅｎｅｒａｌｌｙ，ｍｏｓｔ　ｓｔｒｅａｍｐｒｏｃｅｓｓｉｎｇ　ｔａｓｋｓ　ｉｓ　ｖｅｒｙ　ｓｅｎｓｉｔｉｖｅ　ｔｏ　ｌａｔｅｎｃｙ，ａｎｄ　ｔｈｅ　ｄａｔａ　ｖａｌｕｅ　ｄｅｃｒｅａｓｅｓ　ｒａｐｉｄｌｙ　ａｓ　ｔｈｅ　ｐｒｏｃｅｓｓｉｎｇｔｉｍｅ　ｉｎｃｒｅａｓｅｓ．Ｉｎ　ｔｈｅ　ｔｒａｄｉｔｉｏｎａｌ　ｓｔｒｅａｍｉｎｇ　ｃｏｍｐｕｔｉｎｇ　ｅｎｇｉｎｅ　ｄｅｓｉｇｎ，ｔｈｅ　ｏｐｅｒａｔｉｎｇ　ｓｙｓｔｅｍ，ＪＶＭ，ｅｔｃ．ｏｃｃｕｐｙ　ａ　ｌａｒｇｅ　ａｍｏｕｎｔ　ｏｆ　ｃｏｍｐｕｔｉｎｇ　ｒｅｓｏｕｒｃｅｓ　ａｎｄ　ｓｕｆｆｅｒ　ｆｒｏｍ　ＪＶＭ　ｏｖｅｒｈｅａｄｓ　ｓｕｃｈ　ａｓｐｏｉｎｔｅｒ　ｃｈａｓｉｎｇ　ａｎｄ　ｔｒａｎｓｐａｒｅｎｔ　ｍｅｍｏｒｙ　ｍａｎａｇｅｍｅｎｔ．Ｌａｃｋｉｎｇ　ｔｈｅｉｒ　ｉｎａｂｉｌｉｔｙ　ｔｏ　ｅｘｐｌｏｉｔ　ｍｏｄｅｒｎＣＰＵｓ　ｅｆｆｉｃｉｅｎｔｌｙ　ａｎｄ　ｎｏｔ　ｂｅｉｎｇ　ａｂｌｅ　ｔｏ　ｕｔｉｌｉｚｅ　ｔｈｅ　ｅｎｔｉｒｅ　ｎｅｔｗｏｒｋ　ｂａｎｄｗｉｄｔｈ　ｏｆ　ｍｏｄｅｒｎ　ｈｉｇｈ－ｓｐｅｅｄｎｅｔｗｏｒｋｓ．Ｈｏｗ　ｔｏ　ｉｍｐｒｏｖｅ　ｔｈｅ　ｕｔｉｌｉｚａｔｉｏｎ　ｏｆ　ｃｏｍｐｕｔｉｎｇ　ｒｅｓｏｕｒｃｅｓ　ｈａｓ　ｂｅｃｏｍｅ　ａｎ　ｕｒｇｅｎｔ　ｐｒｏｂｌｅｍｔｏ　ｂｅ　ｓｏｌｖｅｄ．Ｔｈｅｒｅｆｏｒｅ，ｗｅ　ｐｒｏｐｏｓｅ　ａ　ｈｉｇｈ－ｐｅｒｆｏｒｍａｎｃｅ　ｒｅａｌ－ｔｉｍｅ　ｓｔｒｅａｍ　ｃｏｍｐｕｔｉｎｇ　ｅｎｇｉｎｅ，ｒｅｆｅｒｒｅｄ　ｔｏ　ａｓ　Ｈｕｍｍｅｒ，ｂｙ　ｕｔｉｌｉｚｉｎｇ　Ｃ＋＋ ｐｒｏｇｒａｍｉｎｇ　ｌａｎｇｕａｇｅ　ａｎｄ　Ｕｎｉｋｅｒｎｅｌ．Ｉｔ　ｉｓ　ｋｎｏｗｎ　ｔｈａｔｔｈｅ　ｔｒａｄｉｔｉｏｎａｌ　ｏｐｅｒａｔｉｎｇ　ｓｙｓｔｅｍｓ，ｌｉｋｅ　ＣｅｎｔＯＳ，ａｒｅ　ｄｅｓｉｇｎｅｄ　ａｓ　ａ　ｇｅｎｅｒａｌ－ｐｕｒｐｏｓｅ　ｓｙｓｔｅｍ　ａｎｄ处理任务，边表示数据流动，使用 ＤＡＧ有两大优势：（１）ＤＡＧ 允许任务有多个输入输出，简化了诸如Ｊｏｉｎ等经典数据操作的实现；（２）ＤＡＧ的边明确表达了数据的流通路径，有利于系统对任务调度进行优化．考 虑 到 系 统 对 数 据 处 理 实 时 性 的 要 求，Ｈｕｍｍｅｒ使用 Ｄａｔａｆｌｏｗ 模型．系统将流式数据抽象为 ＤａｔａＳｔｒｅａｍ，支持从内存、文件、ｓｏｃｋｅｔ、ｋａｆｋａ等输入 源 或 其 他 ＤａｔａＳｔｒｅａｍ 的 输 出 创 建．并 通 过ｍａｐ、ｆｌａｔＭａｐ、ｇｒｏｕｐＢｙ、ｒｅｄｕｃｅ等 Ｔｒａｎｓｆｏｒｍ 操 作进 行 转 换，生 成 新 的 ＤａｔａＳｔｒｅａｍ．系 统 自 动 将Ｔｒａｎｓｆｏｒｍ 操作分散部署在多个节点并行计算，部署和调度过程对用户完全透明．本文以 ＷｏｒｄＣｏｕｎｔ为例，介绍如何从用户代码转换为作业并在集群中执行．过程１为 ＷｏｒｄＣｏｕｎｔ用户作业代码．代码２～４行通过ＪｏｂＭａｎａｇｅｒ获取ＳｔｒｅａｍＥｘｅｃｕｔｉｏｎＥｎｖｉｒｏｎｍｅｎｔ对象，对象中记录了用户作业和集群配置等信息，默认情况系统会自动检测计算节点硬件环境进行配置．随后，代码６行从文件ｓｏｕｒｃｅ．ｔｘｔ创建 ＤａｔａＳｔｒｅａｍ，７～１０行依次在ＤａｔａＳｔｒｅａｍ 上做ｆｌａｔＭａｐ、ｇｒｏｕｐＢｙ、ｃｏｕｎｔ和 ｐｒｉｎｔ操作，来对 ＤａｔａＳｔｒｅａｍ 进行转换．转换操作均采用抽象接口设计，用户可通过继承相应接口实现 ＵＤＦ操作．最后，代码１１～１２行将作业进行命名，并提交给集群执行．流式处理中，ｅｘｅｃｕｔｅ方法返回作业提交结果，批式处理则阻塞客户端程序直到作业执行完毕，并返回作业执行结果．过程１．　ＷｏｒｄＣｏｕｎｔ作业．１．／／ｇｅｔ　ｅｘｅｃｕｔｉｏｎ　ｅｎｖｉｒｏｎｍｅｎｔ　ｆｒｏｍ　ＪｏｂＭａｎａｇｅｒ２．ｓｈａｒｅｄ＿ｐｔｒ〈ＳｔｒｅａｍＥｘｅｃｕｔｉｏｎＥｎｖｉｒｏｎｍｅｎｔ〉ｅｎｖ３．　＝ＳｔｒｅａｍＥｘｅｃｕｔｉｏｎＥｎｖｉｒｏｎｍｅｎｔ４．　　∷ｇｅｔＥｘｅｃｕｔｉｏｎＥｎｖｉｒｏｎｍｅｎｔ（ＪｏｂＭａｎａｇｅｒ）；５．／／ｃｒｅａｔｅ　ｄａｔａＳｔｒｅａｍ　ｆｒｏｍ　ｓｏｕｒｃｅ６．ａｕｔｏ　ｄａｔａＳｔｒｅａｍ＝ｅｎｖ→ｆｒｏｍＦｉｌｅ（“ｓｏｕｒｃｅ．ｔｘｔ”）；７．ｄａｔａＳｔｒｅａｍ８．　→ＦｌａｔＭａｐ（ｎｅｗ　ＳｐｌｉｔＳｔｒｉｎｇＦｕｎｃｔｉｏｎ（））９．　→ｇｒｏｕｐＢｙＣｏｕｎｔ（）１０．　→ｐｒｉｎｔ〈ｓｔｄ∷ｔｕｐｌｅ〈ｓｔｒｉｎｇ，ｉｎｔ〉〉（）；１１．ａｕｔｏ　＆ｒｅｓｕｌｔ＝１２．　ｅｎｖ→ｅｘｅｃｕｔｅ（“Ｄｉｓｔｒｉｂｕｔｅｄ　ｗｏｒｌｄ　ｃｏｕｎｔ．”）；３．３　分布式运行说明本小节以 ＷｏｒｄＣｏｕｎｔ作业为例，详细介绍了作业从代码至分布式运行的整个流程．用户作业输入系统后进行一些列转换，由作业源代码转换为最终的 ＥｘｅｃｕｔｉｏｎＧｒａｐｈ，并交由 ＴａｓｋＭａｎａｇｅｒ执行，作业转换过程如图５所示．图 ５　用户作业转换图３．３．１　ＤＡＧ逻辑视图生成用户代码提交至客户端后首先被转换为Ｓｔｒｅａｍ－Ｇｒａｐｈ．ＳｔｒｅａｍＧｒａｐｈ是未经优化的作业 ＤＡＧ，其逻辑结构与用户代码相对应．ＳｔｒｅａｍＧｒａｐｈ由 Ｓｔｒｅａｍ－Ｎｏｄｅ和 ＳｔｒｅａｍＥｄｇｅ组 成．ＳｔｒｅａｍＮｏｄｅ是 计 算 节点，其中包含ＳｏｕｒｃｅＯｐｅｒａｔｏｒ、ＯｎｅＩｎｐｕｔＯｐｅｒａｔｏｒ和ＴｗｏＩｎｐｕｔＯｐｅｒａｔｏｒ三 种 ｏｐｅｒａｔｏｒ．ＳｏｕｒｃｅＯｐｅｒａｔｏｒ负责表示 ＤＡＧ 中没有输入，只有输出的节点，一般表示用户程序中的数据源输入；ＯｎｅＩｎｐｕｔＯｐｅｒａｔｏｒ表示 ＤＡＧ 中只有一个输入的节点，可用于表示用户代码中一个输入对应一个输出的 Ｍａｐ，ＦｌａｔＭａｐ等 操 作，也 可 表 示 只 有 一 个 输 入 但 没 有 输 出 的ＳｉｎｋＯｐｅｒａｔｏｒ等 特 殊 节 点，ＳｉｎｋＯｐｅｒａｔｏｒ是 ＤＡＧ中的尾节点，用于表示用户代码中的运算结果输出逻辑；ＴｗｏＩｎｐｕｔＯｐｅｒａｔｏｒ表示 ＤＡＧ 中有两个输入的节点，多个输入可由 ＯｎｅＩｎｐｕｔＯｐｅｒａｔｏｒ和 ＴｗｏＩｎｐｕｔ－Ｏｐｅｒａｔｏｒ组合表示．ＳｔｒｅａｍＥｄｇｅ表示 ＤＡＧ 中的边，记录了数据在系统中的流动规则．图 ６　ＷｏｒｄＣｏｕｎｔ　ＳｔｒｅａｍＧｒａｐｈ图６进一步展示了３．２节中作业 ＷｏｒｄＣｏｕｎｔ生成的ＳｔｒｅａｍＧｒａｐｈ，图６中每个 ＳｔｒｅａｍＮｏｄｅ节点代表了用户代码中对数据流的一次操作，ＳｔｒｅａｍＥｄｇｅ８期 李　冰等：支持 Ｕｎｉｋｅｒｎｅｌ的流式计算引擎：Ｈｕｍｍｅｒ９５７１流动方向．３．３．２　ＤＡＧ 逻辑视图优化客户端生成 ＳｔｒｅａｍＧｒａｐｈ后通过对其优化，生成ＪｏｂＧｒａｐｈ，并将其提交至ＪｏｂＭａｎａｇｅｒ．ＪｏｂＧｒａｐｈ是ＳｔｒｅａｍＧｒａｐｈ经优化后的任务逻辑视图，由Ｊｏｂ－Ｖｅｒｔｅｘ和 ＪｏｂＥｄｇｅ组 成．ＪｏｂＶｅｒｔｅｘ 包 含 Ｓｔｒｅａｍ－Ｇｒａｐｈ中 的 一 个 或 多 个 ＳｔｒｅａｍＮｏｄｅ 计 算 任 务，ＪｏｂＥｄｇｅ表示ＪｏｂＶｅｒｔｅｘ间的数据流动．系统 支 持 使 用 ＯＰ（Ｏｐｅｒａｔｏｒ）融 合 机 制 优 化ＳｔｒｅａｍＧｒａｐｈ．ＯＰ融合机制使用如图７的规则将关联度较高的ｏｐｅｒａｔｏｒ合并．融合有两大优势：（１）确保关联度较高的ｏｐｅｒａｔｏｒ不会跨节点分布，避免序列化和网络传输开销；（２）避免同节点下 ｏｐｅｒａｔｏｒ通信带来的内存拷贝开销和多线程资源竞争．图８为３．３．１节中 ＷｏｒｄＣｏｕｎｔ的ＳｔｒｅａｍＧｒａｐｈ图 ７　ＯＰ融合规则图 ８　ＷｏｒｄＣｏｕｎｔ　ＪｏｂＧｒａｐｈ生成的ＪｏｂＧｒａｐｈ．图中的ＪｏｂＶｅｒｔｅｘ节点代表优化后的数 据 处 理 任 务，已 将 部 分 ＳｔｒｅａｍＮｏｄｅ 合 并．ＪｏｂＥｄｇｅ表示数据流动方向．３．３．３　ＤＡＧ物理视图生成ＪｏｂＭａｎａｇｅｒ收到客户端提交的ＪｏｂＧｒａｐｈ后，ＪｏｂＭａｎａｇｅｒ将其 转 换 为 ＥｘｅｃｕｔｉｏｎＧｒａｐｈ．与 抽 象的ＪｏｂＧｒａｐｈ 不同，ＥｘｅｃｕｔｉｏｎＧｒａｐｈ 包 含 了 作 业 执行与 调 度 所 需 的 全 部 信 息，由 ＳｔｒｅａｍＴａｓｋ 和ＳｔｒｅａｍＥｄｇｅ组 成．ＳｔｒｅａｍＴａｓｋ 由 ＪｏｂＧｒａｐｈ 中 的ＪｏｂＶｅｒｔｅｘ结合调度方案生成，包含了作业任务信息与作业 调 度 信 息，与 物 理 执 行 环 境 中 的 任 务 一一对应，是 ＴａｓｋＭａｎａｇｅｒ中任 务执行的 基 本单位．ＳｔｒｅａｍＥｄｇｅ包 含 ＳｔｒｅａｍＴａｓｋ 之 间 的 连 接 信 息．图９为由３．３．２节中 ＷｏｒｄＣｏｕｎｔ的ＪｏｂＧｒａｐｈ生成的 ＥｘｅｃｕｔｉｏｎＧｒａｐｈ．图 ９　ＷｏｒｄＣｏｕｎｔ　ＥｘｅｃｕｔｉｏｎＧｒａｐｈＪｏｂＭａｎａｇｅｒ收到ＪｏｂＧｒａｐｈ后，需要对ＪｏｂＧｒａｐｈ中的每个节点确定运行并行度．分配过程中参照用户配置的作业总并行度、节点并行度以及节点最大和最小并行度进行分配．如未指定节点并行度，则根据剩余计算资源平均分配，并保证节点并行度在用户配置允许范围且总并行度不超过用户作业配置．随后ＪｏｂＭａｎａｇｅｒ根据并行度设置生成调度方案．由于ＪｏｂＧｒａｐｈ生成时已使用 ＯＰ融合机制将关联度较 高的 ｏｐｅｒａｔｏｒ合 并，系统使 用 Ｒｏｕｎｄ－ｒｏｂｉｎ策略生成任务调度策略，并尽量保证ＪｏｂＧｒａｐｈ 中同一节点的不同副本分配至不同 ＴａｓｋＭａｎａｇｅｒ．作业 调 度 方 案 生 成 后，结 合 ＪｏｂＧｒａｐｈ 生 成ＳｔｒｅａｍＴａｓｋ，并对相关联节点生成ＳｔｒｅａｍＥｄｇｅ连接０６７１ 计　　算　　机　　学　　报 ２０１９年Ｅｄｇｅ分为 ＭｅｍｏｒｙＥｄｇｅ与ＮｅｔｗｏｒｋＥｄｇｅ，分别用于连接同节点和跨界点的ＳｔｒｅａｍＴａｓｋ．最后，系统将 ＮｅｔｗｏｒｋＥｄｇｅ转换为 ＭｅｍｏｒｙＥｄｇｅ和一个负责网络连接的 ＳｔｒｅａｍＴａｓｋ．系统可根据用户网络配置，对不同作业任务节点网络连接分配不同的计算资源，实现灵活的网络配置支持．同时，通过将不同任务封装为统一的 ＳｔｒｅａｍＴａｓｋ，可消除不同任务间的差异，简化 ＴａｓｋＭａｎａｇｅｒ的设计．随后ＪｏｂＭａｎａｇｅｒ根 据 ＳｔｒｅａｍＴａｓｋ 中 的 调 度 信 息 将ＳｔｒｅａｍＴａｓｋ序列化并发送至对应 ＴａｓｋＭａｎａｇｅｒ．３．３．４　任务执行ＴａｓｋＭａｎａｇｅｒ收到任务后对其反序列化并初始化 ＳｔｒｅａｍＴａｓｋ对象，并对相关联的 ＳｔｒｅａｍＴａｓｋ使用高性能无锁队列建立连接；跨节点网络连接组件由于已被封装为 ＳｔｒｅａｍＴａｓｋ，在 ＴａｓｋＭａｎａｇｅｒ 看来与其余任务无异，故无需关注．随后，ＴａｓｋＭａｎａｇｅｒ将封装好的 ＳｔｒｅａｍＴａｓｋ 分配至空闲 Ｓｌｏｔ执行，Ｓｌｏｔ是系统资源分配的基本单位，一个Ｓｌｏｔ代表占用一个ＣＰＵ 内核．最后，Ｓｌｏｔ通过ＳｔｒｅａｍＴａｓｋ的ｉｎｖｏｋｅ（）方法启动任务，并通过ｃａｎｃｅｌ（）和ｓｔｏｐ（）等接口对任务行管理，这种轻量级设计可以使 ＴａｓｋＭａｎａｇｅｒ占用更少的资源，更好的适配 Ｕｎｉｋｅｒｎｅｌ等单一地址空间场景．由于 Ｕｎｉｋｅｒｎｅｌ应用难以调 试，为了便于用户对作业代码及框架进行调试，除支持 Ｕｎｉｋｅｒｎｅｌ部署模式外，系统还支持单机以及传统的分布式模式运行．单机环境下，ＪｏｂＭａｎａｇｅｒ和 ＴａｓｋＭａｎａｇｅｒ之间通过函数调用取代ａｃｔｏｒ机制进行通信，Ｔａｓｋ之间使用共享内存等方式进行通信，用户作业代码和计算引擎共用同一进程，进一步简化用户代码调试难度．３．４　网络通信设计说明系统网络通信分控制流通信和数据流通信两部分．控制流通信用于在ＪｏｂＭａｎａｇｅｒ和 ＴａｓｋＭａｎａｇｅｒ间传递控制信息，其特点为 ＪｏｂＭａｎａｇｅｒ单节点高并发连接，但传输数据量少．数据流连接用户任务间的数据流传输，并发度低，仅在需要传输数据的任务间建立连接，但传输数据量大，对延迟敏感．基于以上原因，本系统将控制流网络通信和数据流网络通信独立设计：（１）控制流通信．控制流通信使用基于协程机制的 Ａｃｔｏｒ［２３］模型实现．模型中最基本的运算单元是ａｃｔｏｒ，每个 ａｃｔｏｒ可完成一组独立的功能，ａｃｔｏｒ之间通过 异 步 消 息 传 递 调 用．使 用 Ａｃｔｏｒ机 制 可以将系统ＪｏｂＭａｎａｇｅｒ和 ＴａｓｋＭａｎａｇｅｒ解偶，并使ＪｏｂＭａｎａｇｅｒ单节点支持上万并发连接．（２）数 据 流 通 信．主 流 流 计 算 引 擎 中，Ｔａｓｋ－Ｍａｎａｇｅｒ统一负责网络通信传输，这种方式可以简化系统设计实现流程，但同时也降低了系统网络配置的灵活性，单一的网络拓扑结构无法应对复杂的业务 场 景．Ｈｕｍｍｅｒ使 用 全 新 的 网 络 设 计，Ｔａｓｋ－Ｍａｎａｇｅｒ不再管理数据流网络通信，而将网络通信当作普通任务负载对待，用户可针对每个任务单独配置网络通信方案．网络通信支持独占一个或多个Ｓｌｏｔ，也可使用 ＯＰ融合机制与任务共享 Ｓｌｏｔ．与主流方案相比，本方案将网络负载与 ＴａｓｋＭａｎａｇｅｒ解耦，简 化 ＴａｓｋＭａｎａｇｅｒ 设 计 以 适 配 Ｕｎｉｋｅｒｎｅｌ场景，此外，本方案还有以下优势：① 灵活的网络配置．可根据任务优先级和任务类型针对任务单独配置网络模块．网络ＩＯ 需求较低的任 务 使 用 ＯＰ 融 合 的 形 式 与 任 务 负 载 共 享Ｓｌｏｔ，降低内存拷贝等开销；网络ＩＯ 需求较高的任务可单独占用一个或多个 Ｓｌｏｔ来满足其较高的网络性能需求．② 异构网络支持．针对不同的任务连接不同的硬件网络环境，实现异构网络接入支持．③ 网络 资 源 隔 离．在 传 统 批 式 处 理 流 程 中，Ｓｈｕｆｆｌｅ阶段对网络带宽使用率较高，通常情况下会占用几乎全部网络资源，严重影响到对延迟敏感的流式处理系统，目前工业界常常将流式处理和批式处理分别部署于两个物理集群，以减少批式处理对流式处理的影响．Ｈｕｍｍｅｒ通过在同一集群中对批式处理和流式处理分别使用不同的网络接口，做到物理网络隔离，减少批式处理中网络带宽占用对流式处理的影响，在提高集群资源利用率的同时降低维护成本．３．５　容错及扩展说明与 ＢＳＰ模型不同，Ｄａｔａｆｌｏｗ 模型由于没有计算阶段划分，难以在同一时刻对系统记录全局快照，容错较为困难，本系统使用分布式全局一致性快照算法［２４］实现容错，支持 Ｅｘａｃｔｌｙ－ｏｎｃｅ语义．系 统每隔固定时间间隔记录全局快照并备份输入源位置，出错时将所有计算节点恢复至最近快照并回退输入源至相应位置．系统要求数据源可缓存数据并可从任意时刻回放．如图１０所示，系统每隔固定的时间向数据源中注入 Ｂａｒｒｉｅｒ，并使之随数据记录在 ＤＡＧ 中流动，当Ｂａｒｒｉｅｒ流动到计算节点时，计算节点会对当前的状态记录快照，当 Ｂａｒｒｉｅｒ流动到Ｓｉｎｋ节点时，全局快照记录完成，整个快 照记录 过 程中，数据流无需暂８期 李　冰等：支持 Ｕｎｉｋｅｒｎｅｌ的流式计算引擎：Ｈｕｍｍｅｒ１６７１停，快照记录代价较小．但当系统出错时，需要将全部计算节点恢复至最近快照状态，并回退输入流至相应位置，数据恢复代价较大．图 １０　分布式全局一致性快照算法４　实　验４．１　实验环境实验集群由四台服务器组成，其中一台机器作为ＪｏｂＭａｎａｇｅｒ和 ＴａｓｋＭａｎａｇｅｒ共享使用，三台机器 ＴａｓｋＭａｎａｇｅｒ 独 享 使 用，服 务 器 ＣＰＵ 配 置 为Ｉｎｔｅｌ（Ｒ）Ｘｅｏｎ（Ｒ）ＣＰＵ　Ｅ５－２６４０ｖ４＠２．４０ＧＨｚｘ２、内存１２８ＧＢ、１０Ｇｂｐｓ网卡．操作系统为 ＣｅｎｔＯＳ７．３、内核为３．１０．０、ＧＣＣ编译器版本６．２．１、ＱＥＭＵ版本２．０．０．实验数据集使用小说《Ｇａｍｅ　ｏｆ　Ｔｈｒｏｎｅｓ》多次拼接生成，文本大小１６ＧＢ，共１５５　８００　０００行，包含单词２　９００　５２０　０００个，实验从批式处理和流式处理两个方面比较 Ｈｕｍｍｅｒ与 Ｆｌｉｎｋ、Ｓｐａｒｋ的性能，并对比虚拟化环境下使用 Ｕｎｉｋｅｒｎｅｌ封装的 Ｈｕｍｍｅｒ与 ＣｅｎｔＯＳ系统封装的 Ｆｌｉｎｋ性能差距，实验 Ｓｐａｒｋ版 本 为 ｓｐａｒｋ－２．２．０－ｂｉｎ－ｈａｄｏｏｐ２．７，Ｆｌｉｎｋ 版 本 为１．４．２－ｈａｄｏｏｐ２８－ｓｃａｌａ＿２．１１．４．２　批式处理批处理实验任务流程如图１１所示，实验使用小说文本文 件 做 数 据 源，系 统 读 入 数 据 后 依 次 进 行字符串分割、ＧｒｏｕｐＢｙ和 Ｓｕｍ 操作，最后将计算结果写入磁盘保存．实验从 ＣＰＵ、内存、吞吐量三方面比较 单 机 环 境 和 四 节 点 集 群 环 境 下 Ｈｕｍｍｅｒ 与Ｓｐａｒｋ、Ｓｐａｒｋ　Ｓｔｒｅａｍｉｎｇ和Ｆｌｉｎｋ在 ＣｅｎｔＯＳ系统下的性能．实验中所有系统均使用最大系统资源配置，且关闭容错功能．图 １１　批式处理实验任务流程图系统在单机环境下的吞吐量如表１所示，Ｓｐａｒｋ由于使用 ＢＳＰ模型，其吞吐量对比 Ｄａｔａｆｌｏｗ 模型的Ｆｌｉｎｋ与 Ｈｕｍｍｅｒ具有先天优势．实验表明，Ｈｕｍｍｅｒ吞吐量约为同样使用 Ｄａｔａｆｌｏｗ 模型的 Ｆｌｉｎｋ系统的两倍，与使用 ＢＳＰ 模型的 Ｓｐａｒｋ和 Ｓｐａｒｋ　Ｓｔｒｅａｍｉｎｇ相差无几．由图１２系统 ＣＰＵ 使用率对比图可以看出，Ｆｌｉｎｋ和Ｓｐａｒｋ几乎占满了ＣＰＵ 资源，而 Ｈｕｍｍｅｒ的 ＣＰＵ 使用率约为８０％，如能提升ＩＯ 性能，系统整体性能会有进一步提升．图１３为系统内存使用率对比图，可以看出，Ｈｕｍｍｅｒ做为针对虚拟化环境优化的轻量级系统，内存利用率明显低于 Ｓｐａｒｋ和 Ｆｌｉｎｋ．在４节点集群环境下，Ｈｕｍｍｅｒ依然保持较好的性能，由于硬件资源Ｉ／Ｏ 限制，四个系统均未达到线性扩展，但由表２可以看出，Ｈｕｍｍｅｒ在四节点分布式环境下依然具有良好的性能．表 １　单机环境性能对比表系统名称 任务耗时／ｓ 吞吐量／（ＭＢ／ｓ）Ｓｐａｒｋ　 ９６　 １７０．６６Ｓｐａｒｋ　Ｓｔｒｅａｍｉｎｇ　 １０１　 １６２．２１Ｆｌｉｎｋ　 ２３６　 ６９．４２Ｈｕｍｍｅｒ　 １１５　 １４２．４７表 ２　四节点集群环境性能对比表系统名称 任务耗时／ｓ 吞吐量／（ＭＢ／ｓ）Ｓｐａｒｋ　 ３８　 ４３１．１５Ｓｐａｒｋ　Ｓｔｒｅａｍｉｎｇ　 ６５　 ２５２．０６Ｆｌｉｎｋ　 ８０　 ２０４．８０Ｈｕｍｍｅｒ　 ４１　 ３９９．６１图 １２　系统 ＣＰＵ 利用率对比图图 １３　系统内存利用率对比图２６７１ 计　　算　　机　　学　　报 ２０１９年