分布式流式计算平台的设计与实现

分类号：ＴＰ３１９

密级：

洳≥：ｊ～＇－４

硕士学位论文

⑧

论文题目分布式流式计算平台的设计与实现

吴峻

邵健副教授作者姓名指导教师

肖俊副教授

学科（专业）

所在学院

提交日期计算机应用计算机科学与技术２０１４年１月２０日

ＡＤｉｓｓｅｒｔａｔｉｏｎＳｕｂｍｉｔｔｅｄｔｏＺｈｅｊｉａｎｇ

ＵｎｉｖｅｒｓｉｔｙｆｏｒｔｈｅＤｅｇｒｅｅｏｆ

ＭａｓｔｅｒｏｆＥｎｇｉｎｅｅｒｉｎｇ１—１一

⑧

ＴＩＴＬＥ旦曼墨ｉｇ坠垒旦鱼ｉ堡卫！星堡星巫丛ｉＱ里Ｑ垂垒

ｓｔｒｅａｍｃｏｍｐｕｔｍＲｐｌａｔＩＯｎｎ

Ａｕｔｈｏｒ：ＪｕｎＷｕ

Ｓｕｐｅｒｖｉｓｏｒ：Ａｓｓｏｃ．Ｐｒｏｆ．ＪｉａｎＳｈａｏ

ＡＳＳＯＣ．Ｐｒｏｆ．ＪｕｎＸｉａｏ

Ｓｕｂｊｅｃｔ：

Ｃｏｌｌｅｇｅ：

ＳｕｂｍｉｔｔｅｄＤａｔｅ：２０１４．．１．．２０

浙江大学硕士学位论文摘要

摘要

在当今的信息时代，每天世界各地的传感器、移动设备、在线交易和社交网络都会实时产生海量数据。许多服务需要对于这些源源不断的产生的各种类型的数据做出迅速响应。由于数据的流速、流向随时可以发生变化。擅长大吞吐量批量式处理的传统的分布式处理模式并不能很好地加以处理。在这种情况下，专门针对流式数据的计算平台应运而生，强调实时性，能对输入数据进行迅速的复杂处理，实时返回处理结果。

本文首先研究了目前国内外流行的流式计算平台，分析并比较了它们的使用场景，以及对于一些特定问题的具体解决方案，并指出了它们存在的一些问题。

然后，本文提出了一种流式计算平台——Ｄｓｔｒｅａｍ的设计方案，说明了其特色之处，从某些方面解决了之前提出的问题。同时，本文对提出的设计方案给出了具体实现方案。

最后，本文在完成的ＤＳｔｒｅａｍ流式计算平台的基础上，实现了一个基于乐纹的音频检索应用，以证明ＤＳｔｒｅａｍ平台的实用性，并对未来其他基于流式计算平台应用的实现提供了参考。

关键词：流式计算，分布式，并行计算

浙江大学硕士学位论文Ａｂｓ”ａｃｔ

Ａｂｓｔｒａｃｔ

Ｎｏｗａｄａｙｓ，ｓｅｎｓｏｒｓ，ｍｏｂｉｌｅｄｅｖｉｃｅｓａｒｅｇｅｎｅｒａｔｉｎｇｈｕｇｅａｍｏｕｎｔｓｏｆｄａｔａｅｖｅｒｙｍｉｎｕｔｅ

ｓｔｅａｄｙｓｔｒｅａｍｏｆｔｈｅｓｅｔｙｐｅｓｏｆｄａｔａｇｅｎｅｒａｔｅｄ

ｃａｎｉｎｔｈｅｗｏｒｌｄ，Ｍａｎｙｏｎｌｉｎｅｓｅｒｖｉｃｅｓｒｅｑｕｉｒｅａｒｅｓｐｏｎｄｑｕｉｃｋｌｙ．Ｓｉｎｃｅｔｈｅｒａｔｅａｎｄｔｈｅｄｅｓｔｉｎａｔｉｏｎｏｆｄａｔａｆｌｏｗｃｈａｎｇｅａｔａｎｙｔｉｍｅ，

ｔｒａｄｉｔｉｏｎａｌｄｉｓｔｒｉｂｕｔｅｄｃｏｍｐｕｔｉｎｇｍｅｔｈｏｄｓｔｈａｔｈａｓａｄｖａｎｔａｇｅｉｎｂａｔｃｈｐｒｏｃｅｓｓｉｎｇｃｏｕｌｄｎｏｔｄｅａｌｗｉｔｈｓｔｒｅａｍｄａｔａｗｅｌｌ．Ｔｈｅｒｅｆｏｒｅ，ｄｉｓｔｒｉｂｕｔｅｄｓｔｒｅａｍｃｏｍｐｕｔｉｎｇｐｌａｔｆｏｒｍｓ

ｔｏａｒｅｄｅ－ｓｉｇｎｅｄｐｒｏｃｅｓｓｒｅａｌ－ｔｉｍｅｄａｔａｉｎａｃｕｓｔｏｍｃｏｍｐｌｅｘｗａｙａｎｄｍａｋｅｑｕｉｃｋｒｅｓｐｏｎｓｅｓ．

Ａｔｆｉｒｓｔ，ｔｈｉｓｐａｐｅｒｒｅｖｉｅｗｓｓｏｍｅｐｏｐｕｌａｒｓｔｒｅａｍｃｏｍｐｕｔｉｎｇｐｌａｔｆｏｒｍｓｉｎｔｈｅｗｏｒｌｄ，ａｎａｌｙｚｅｓｔｈｅｉｒ

ｏｆｔｈｅｍ．ｕｓｅｃａｓｅｓａｎｄｃｏｍｐａｒｅｓｔｈｅｉｒａｂｉｌｉｔｉｅｓ．Ａｎｄｐｏｉｎｔｅｄｏｕｔｓｏｍｅｗｅａｋｐｏｉｎｔｓ

Ｔｈｅｎ，ｔｈｅｐａｐｅｒｐｒｅｓｅｎｔｓａｄｅｓｉｇｎｏｆａｓｔｒｅａｍｃｏｍｐｕｔｉｎｇｐｌａｔｆｏｒｍ—ＤＳｔｒｅａｍ，ｗｈｉｃｈｓｏｌｖｅｓｔｈｅａｂｏｖｅｐｒｏｂｌｅｍｓｉｎｓｏｍｅｗａｙ．Ａｔｔｈｅｓａｍｅｔｉｍｅ，ｔｈｅｉｍｐｌｅｍｅｎｔａｔｉｏｎｄｅｔａｉｌｓｏｆＤＳｔｒｅａｍａｒｅｅｘｐｌａｉｎｅｄ．

Ｆｉｎａｌｌｙ，ｂａｓｅｄｏｎｔｈｅｃｏｍｐｌｅｔｅｄＤＳｔｒｅａｍ

ａｎｐｌａｔｆｏｒｍ，ｔｈｅｐａｐｅｒｄｅｓｉｇｎｓａｎｄｉｍｐｌｅｍｅｎｔｓａｕｄｉｏｓｅａｒｃｈａｐｐｌｉｃａｔｉｏｎｂａｓｅｄｏｎａｕｄｉｏｆｉｎｇｅｒｐｒｉｎｔｓ．Ｔｈｉｓｄｅｍｏｎｓｔｒａｔｅｓｔｈｅｆｕｎｃｔｉｏｎ－

ａｎａｌｉｔｉｅｓｏｆＤＳｔｒｅａｍｐｌａｔｆｏｒｍ，ａｎｄｇｉｖｅｓ

ｏｎｅｘａｍｐｌｅａｂｏｕｔｈｏｗｔｏｉｍｐｌｅｍｅｎｔａｐｐｌｉｃａｔｉｏｎｓｓｔｒｅａｍｃｏｍｐｕｔｉｎｇｐｌａｔｆｏｒｍｓ．

Ｋｅｙｗｏｒｄｓ：ＳｔｒｅａｍＣｏｍｐｕｔｉｎｇ，Ｄｉｓｔｒｉｂｕｔｅｄ，ＰａｒａｌｌｅｌＣｏｍｐｕｔｉｎｇ

浙江大学硕士学位论文目次

目次

摘要．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．ｉＡｂｓｔｒａｃｔ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．ｉｉ目次．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．Ｉ图目次．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．ＩＩＩ表目次．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．Ｉｖ第１章绪论．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１

１．１课题背景…．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１

１．２本文的工作内容．．．．．．…．．．．．．．．．．．．．．．．．．．．．．．．．．．．１

１．３本文的组织结构．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３

１．４本章小结．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３

第２章相关技术．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．４

２．１常见流式计算平台．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．４

２．２流式计算平台中的常见设计．．．．．．．．．．．．．．．．．．．．．．．．．．．．５

２．３本章小结．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．９第３章ＤＳｔｒｅａｍ流式计算平台的系统设计．．．．．．．．．．．．．．．．．１０

３．１平台特点．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１０

３．２概念及定义．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１ｌ

３．３系统设计．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１３

３．４本章小结．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１７第４章ＤＳｔｒｅａｍ流式计算平台的具体实现．．．．．．．．．．．．．．．．．１８

４．１基础模块．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１８４．２主控节点．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．２５

４．３计算节点．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．２８

４．４本章小结．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３５

塑江查学硕士学位论文目次第５章基于ＤＳｔｒｅａｍ平台和乐纹的音乐检索．．．．．．．．．．．．．．．３６

５．１概述．．．．．…．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３６５．２架构设计．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３７５．３具体实现………。。。．。………．。．……。。．。．，。…３８５．４本章小结．．．．．．．．．．．．．．．．．．．…．．．．．．．．．．．．．．．．．．．．４７第６章总结与展望．．．．．．．．．．．．．．．．．．．．．．．．．．．．．４８

６．１工作总结．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．４８６．２未来展望．．．．．．．．．．．．．．．．．．．．…．．．．，．．．．．．．．．．．．．．４８参考文献．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．５１攻读硕士学位期间主要的研究成果．．．．．．．．．．．．．．．．．．．．．５４致谢．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．５５

浙江大学硕士学位论文图目次

图目次

３．１拓扑图示例．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．

３．２ＤＳｔｒｅａｍ平台的整体架构．．．．．．．．．．．．．．．．．．．．．．．．．

３．３处理单元消息的过滤．．．．．．．．．．．．．．．．．．．．．．．．．．．

４．１Ｚｏｏｋｅｅｐｅｒ中存储数据的组织结构．．．．．．．．．．．．．．．．．．．．

４．２配置目录中存储数据的组织结构．．．．．．．．．．．．．．．．．．．．．

４．３Ｄ．Ｂｕｓ服务示意图．．．．．．．．．．．．．．．．．．．．．．．．．．．．．

４．４Ｄ．Ｂｕｓ调试工具．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．

４．５监控页首页．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．

４．６监控页对拓扑图的展示．．．．．．．．．．．．．．．．．．．．．．．．．．

４．７消息队列和消息分发器．．．．．．．．．．．．．．．．．．．．．．．．．．

４．８主从消息备份．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．

５．１基于乐纹的音乐检索架构图．．．．．．．．．．．．．．．．．．．．．．．

５．２在乐纹数据库中插入新特征．．．．．．．．．．．．．．．．．．．．．．．

５．３在乐纹数据库中插入新特征．．．．．．．．．．．．．．．．．．．．．．．

５．４频谱图中能量较大的点．．．．．．．．．．．．．．．．．．．．．．．．．．

５．５频谱图中能量较大的点和附近的点配对．．．．．．．．．．．．．．．．．

５．６音频上传界面．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．

５．７音频查询结果界面．．．．．．．．．．．．．．．．．．．．．．．．．．．．．

５．８音频播放页面．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．

５．９实时录音识别界面．．．．．．．．．．．．．．．．．．．．．．．．．．．．．他怕Ｂ侈加挖乃拐Ｍ四弱＂加知钙舛钙钙％％

浙江大学硕士学位论文表目次

表目次

５．１乐纹特征Ｋｅｙ包含的内容．．．．．．．．．．．．．．．．．．．．．．．．．３９５．２乐纹特征Ｖａｌｕｅ包含的内容．．．．．．．．．．．．．．．．．．．．．．．．３９５．３乐曲元数据库表设计．．．．．．．．．．．．．．．．．．．．．．．．．．．４ｌＩＶ

浙江大学硕士学位论文第１章绪论

第１章绪论

１．１课题背景

随着信息技术的不断发展以及网络设备的不断进步，人们对互联网服务的依赖程度越来越深，越来越多的数据存储在云端并在互联网上流通，互联网服务提供商们面临着大数据的挑战。同时，人们对互联网服务的要求也越来越苛刻，互联网服务的响应时间和可靠程度都会严重损害用户体验，进而影－向用户对服务的选择。互联网服务商若想赢得用户，必须做出健全并且响应及时的产品。

对于大数据的离线批量处理，在２００８年提出的ＭａｐＲｅｄｕｃｅ［１】模式已经较为成熟，相关开源实现Ｈａｄｏｏｐ项目已被六百余家企业或机构广泛采用【２］。对于大数据的实时流式处理，由于ＭａｐＲｅｄｕｃｅ模式的实时性不强，需要采用其他方案。近年来，

近年来，有一些在ＭａｐＲｅｄｕｃｅ框架的基础上做实时计算的尝试【３］，但受限于ＭａｐＲｅｄｕｃｅ框架的设计，实际应用场景有限。为弥补ＭａｐＲｅｄｕｃｅ模式关于实时计算的不足，流式计算的概念被提出来，不确定速率的数据像流水一样按照预定路径经由各计算节点并最终得到计算结果。一些企业也提出了自己的流式计算框架，如ＩＢＭ的ＳｔｒｅａｍＢａｓｅ［３］，Ｙａｈｏｏ的￥４１４］，Ｔｗｉｔｔｅｒ的Ｓｔｏｒｍ［５］等。

目前Ｔｗｉｔｔｅｒ公司的许多业务逻辑如用户消息订阅和实时搜索的处理都依赖自家的流式计算平台Ｓｔｏｒｍ，并且其有计划将其到更广的应用场景中【６】。可见流式计算平台在当今互联网应用场景中的重要性。

１．２本文的工作内容

分布式流式计算平台用于解决分布式计算中对实时性要求较高的应用问题。其中主要需要解决的问题有：

对数据流的实时响应，在使用合适的数据抽象的前提下，设计高效的数据传输策略。 对流速、流量不断变化的输入流做出合适的响应，保障流数据能够得到处理。

浙江大学硕士学位论文第ｉ章绪论

对平台内运行的相关计算任务的管理，对平台内运行的计算任务进行监控，对运行出错情况以及节点故障的适当处理。

良好的可扩展性，为开发者提供方便的扩展接口，以显著扩展流式计算平台的可用场景。

为了更好地设计出并具体实现分布式流式计算平台，本文首先介绍并分析了目前一些主流的分布式流式计算平台，如Ｙａｈｏｏ公司的￥４１４］、Ｔｗｉｔｔｅｒ公司的Ｓｔｏｒｍ［５】以及ＩＢＭ的Ｓｔｒｅａ．ｍＢａｓｅ［７］等，并针对流式计算平台的特点分析了在一些具体设计上各种方案的优劣，进而加以总结并最终提出本文的分布式流式系统的设计。

本文的主要工作在于介绍分布式流式计算平台ＤＳｔｒｅａｍ的设计及实现。ＤＳｔｒｅａｍ使用Ｊａｖａ语言实现并运行于Ｌｉｎｕｘ系统的服务器集群中，该平台具体实现了以下主要特点：

高效的数据传输，使用高性能的网络库在节点问传输数据，并恰当地分配计算资源以避免部分网络传输。

运行时自动重新分配集群内节点的计算资源，以时刻适应平台内数据流速变化。

保障每条流消息至少被处理一次，计算进程的崩溃或者单节点故障都不会造成严重后果。

开发者可以使用Ｊａｖａ语言扩展ＤＳｔｒｅａｍ系统本身的功能，也能轻松使用非Ｊａｖａ语言开发ＤＳｔｒｅａｍ下的计算逻辑。在平台运行时可以动态更新线上的计算逻辑。

提供单文件，一行命令快速部署的功能，并额外地允许在运行时对平台本身进行动态调试。

在介绍了分布式流式计算平台ＤＳｔｒｅａｍ的设计及实现之后，本文还介绍了在ＤＳｔｒｅａｍ平台上设计并具体实现了基于乐纹的音乐检索应用。通过对应用的具体开发，分析说明了在ＤＳｔｒｅａｍ平台对实际应用开发的支持，并为后续应用开发提供了参考。

浙江大学硕士学位论文第ｉ章绪论１．３本文的组织结构

本文共有六章，每章内容如下：

第一章：本章是本文的绪论，主要介绍分布式流式计算平台课题的背景，接着简要介绍了本文的工作内容，最后介绍了本文的组织结构。

第二章：本章主要分析了目前流行的流式计算平台，并对分布式流式计算平台的某些具体设计进行了分析，指出了各种设计的优劣之处。

第三章：本章介绍ＤＳｔｒｅａｍ流式处理平台需要包含的特点，然后介绍了平台的架构设计，说明了平台中各个组件的功能。

第四章：本章在第三章的基础上对ＤＳｔｒｅａｍ流式处理平台中的各个组件说明了具体实现细节和注意事项。

第五章：本章在ＤＳｔｒｅａｍ流式处理平台的基础上开发一套基于乐纹的音频检索应用。通过该应用的开发，验证了ＤＳｔｒｅａｍ的功能。

第六章：本章对本文的工作进行了总结，列举了本文所得成果并指出了仍然存在的不足，对未来的工作进行了展望。

１．４本章小结

本章介绍了分布式流式计算平台的产生背景，简要说明了当前现有分布式流式计算框架的现状，随后介绍了本文的工作内容和组织结构，使读者对本文的内容有一个总体的初步了解。

浙江大学硕士学位论文第２章相关技术

第２章相关技术

流式计算有着与传统的批量式处理不同的一些特点，因此需要更有效的专用解决方案。本章将介绍现有的一些知名流式计算项目，并分析总结流式计算平台在设计上采取的方案和特点，为本文的实现提供指导和参考。

２．１常见流式计算平台

２．１．１ＳｔｒｅａｍＢａｓｅ

ＳｔｒｅａｍＢａｓｅ［７】是一款由ＩＢＭ开发的功能丰富的商业流数据计算平台。它使用Ｊａｖａ语言开发，并支持在ＥｃｌｉｐｓｅＩＤＥ中进行二次开发。ＳｔｒｅａｍＢａｓｅ提供了许多组件用来帮助构建应用程序，用户在ＥｃｌｉｐｓｅＩＤＥ中只需要用鼠标将不同的控件连接起来并做简单的设置就能编译出流式应用程序。ＳｔｒｅａｍＢａｓｅ还提供了类似于ＳＱＬ的语言来表达计算过程，并提供了对不同关系数据库的支持。

ＳｔｒｅａｍＢａｓｅ对容错问题提供了多种解决策略。在需要保持状态的情况下，采用主从节点一起计算或者将关键的中间状态存放在可靠的存储设备中来解决。在不需要保持状态的情况下，主节点故障时只需重新计算上游数据即可。

２．１．２Ｓ４

ＳｃａｌａｂｌｅＳｔｒｅａｍｉｎｇＳ４（ＳｉｍｐｌｅＳｙｓｔｅｍ）是Ｙａｈｏｏ公司提出的流式计算平台【４】，

最初用于解决数据收集和机器学习在搜索应用中的现实问题，如在网页中呈现付费广告ｏ

ｓ４采用了Ａｃｔｏｒ模式，处理单元之间不共享状态，只传递事件。受ＭａｐＲｅｄｕｃｅ的启发，ｓ４集群中所有处理节点地位相同，无中心控制。在容错方面，ｓ４依赖Ｚｏｏｋｅｅｐｅｒ服务发现节点故障，并将事件从故障节点迁移到其他节点。

浙江大学硕士学位论文第２章相关技术２．１．３Ｓｔｏｒｍ

Ｓｔｏｒｍ［５］是最初由Ｔｗｉｔｔｅｒ公司实现的流式计算平台，用于解决Ｔｗｉｔｔｅｒ海量用户消息的传递、实时推送，搜索索引的更新等问题。

Ｓｔｏｒｍ许多设计同ｓ４接近，但略有不同，比如Ｓｔｏｒｍ中处理单元细分为数据源（Ｓｐｏｕｔ）和其他处理单元（Ｂｏｌｔ）。这种设计使得Ｓｔｏｒｍ的“保障消息处理”只备份数据源产生的消息，对于处理单元拓扑中其他地方的故障使用轻量的校验码完成校验，一旦发生问题则将备份消息从数据源处重新流一遍。

Ｓｔｏｒｍ的核心部分使用Ｃｌｏｊｕｒｅ语言实现，该语言较为小众【８】，使得其维护门槛较高。

２．１．４其他

还有一些非通用型的分布式流式处理平台，专注于做好特定种类的事情，如用于收集日志的ＡｐａｃｈｅＦｌｕｍｅ［９］，ＦａｃｅｂｏｏｋＳｃｒｉｂｅ［１０］，专注于传递消息的ＡｐａｃｈｅＫａｆｋａ［１１】等。

２．２流式计算平台中的常见设计

考虑到流式计算平台的设计有重合的部分，本节将从几个实现的方面来比较当前流式计算平台在设计上的不同。

通常，可以使用一个有向无环图（ＤｉｒｅｃｔｅｄＡｃｙｃｌｉｃＧｒａｐｈ，以下简称“拓扑图”）来表达流式计算平台中数据可能的流向，在该图中的每个节点为一个处理单元（ＰｒｏｃｅｓｓｉｎｇＥｌｅｍｅｎｔ）。平台一般会对在图中流动的数据设计某种模型，处理单元输入并输出符合该模型的数据。

２．２．１处理单元的设计模式

在不同的平台中，拓扑图和处理单元的设计使用不同的模式，常见的有以下几种： Ａｃｔｏｒ模式

浙江大学硕士学位论文笫２章相关技术

Ａｃｔｏｒ模式是在此环境中最常用的一种模式。不同的Ａｃｔｏｒ互相独立，Ａｃｔｏｒ之间只传递消息数据。一个Ａｃｔｏｒ对应于一个处理单元，处理单元之间没有形式上的不同，皆为传递（接收和发送）消息。许多流式计算平台使用了Ａｃｔｏｒ模式，比如Ｙａｈｏｏｓ４等。部分编程语言如Ｅｒｌａｎｇ，Ｓｃａｌａ在语言层面上较好地实现了Ａｃｔｏｒ模式，有些流式计算平台，比如Ｅｓｃ［１２］，选择使用这类语言编写，简化了部分实现。

Ｐｕｂｌｉｓｈｅｒ，Ｓｕｂｓｃｒｉｂｅｒ模式

该模式常见于有简单的处理消息订阅、广播需求的平台中，如ＡｐａｃｈｅＫａｔｋａ。对于每种消息类型，皆有订阅者和发布者两种角色，订阅者接收消息，发布者发送消息。在拓扑图中，订阅者和发布者形成完全二分图。如果要对消息数据进行加工，相关处理单元需要同时成为订阅者和发布者并处理两种不同的消息，在实际使用中稍有不便。

Ｓｏｕｒｃｅ．Ｄｅｃｏｒａｔｏｒ，Ｓｉｎｋ模式

该模式常见于为日志收集设计的平台，如Ｆｌｕｍｅ以及Ｓｃｒｉｂｅ。在拓扑图上的节点只能是数据源（Ｓｏｕｒｃｅ），数据槽（Ｓｉｎｋ），或者是对数据进行修改数据的装扮者（Ｄｅｃｏｒａｔｏｒ）。本质上是对Ａｃｔｏｒ模式中的Ａｃｔｏｒ的行为做了进一步的划分。由于被设计为日志收集任务，数据源和数据槽不一定是处理单元的输出或输入，也可以是平台所能理解的特定文件或来自网络的数据流，即无需为简单的文件读取或网络流数据读取单独编写处理单元。

２．２．２拓扑图的相关设计

２．２．２．１动态变化

允许拓扑图在运行时动态变化将极大地提高系统的灵活性，但在分布式系统中修改拓扑图需要将新的拓扑图通知到所有受影响的节点，开发者可能会滥用此功能频繁地修改拓扑图，实际开销不容忽视。

少数实现允许局部拓扑图在运行时进行动态更改，如Ｅｓｃ【Ｊ２】平台。其他平台往往采用固定的拓扑图并在消息路由上增加额外规则间接地实现一定程度的动态，

浙江大学硕士学位论文第２章相关技术如在ｓ４中通过对消息中Ｋｅｙ的设定可以将消息传递给不同的处理单元实例，实际的处理单元实例可以有不同的实现。

２．２．２．２数据汇聚

对于拓扑图中入度大于１的处理单元，如果要求其所有输入消息能够同时到达。则有数据汇聚的问题。若实现数据汇聚，需要平台内部提供中间队列和相关逻辑，在等待所有消息到达之后再一次性传入相关处理单元。为防止消息无限堆积，对于在一定时间内收集全的消息进行丢弃。数据汇聚增加了系统实现的复杂度，也限定了处理单元输入是一条消息时输出也是一个消息。

在没有限定处理单元输入一条消息输出一条消息的情况下，也可将数据汇聚的复杂问题交由处理单元层面实现，使用一个处理单元接收并缓存消息，在收集足够的消息后，再发送给下游处理单元。

２．２．３负载均衡的实现方式

在分布式计算环境中，负载均衡是个较为复杂的问题。问题具体分为本地调度和全局调度两个层面。本地调度在节点内选择进／线程，全局调度则为在集群中选择节点。两个层面都有两种实现方式：

１．分配者主动分配，工作者被动接受。

２．工作者主动轮询分配者（也可以是阻塞的）。

方式１将可能遇到分配者算法得出的分配方案实际并不优秀的情况。方式２使得每个工作者只在空闲时才会开始工作，但每个工作者都要和分配者建立长连接，在工作者数目较多的情况下会增加系统负担。并且在所有工作者都不可用的时候，分配者需要采用队列保存消息。

２．２．４处理单元的实体

对于处理单元在操作系统中的实体，也有进程、线程以及纤程三种设计的选择。 进程

浙江大学硕士学位论文第２章相关技术

每个处理单元使用独立的进程，可将处理单元之间的影响降到最小，但进程间数据传递会导致额外开销。使用Ｅｒｌａｎｇ语言编写的平台自然地在此方面取得优势。

线程

处理单元直接运行在平台的某个进程内，可使得数据传递更有效率，但如果任意线程崩溃，可能会破坏出于同一进程中的其他线程。Ｊａｖａ系平台多采用此方式。

纤程

在类似Ｎｏｄｅ．ｊｓ［１３】的无阻塞、事件驱动的运行环境下，纤程是个不错的选择。相比于线程，其具有开销小，访问资源无需加锁的优点。但多个纤程只是一个线程，不能充分利用多核资源，同时在不直接提供纤程支持的编程语言（如Ｊａｖａ）中，使用纤程比较困难。Ｒｔｓｔｒｅａｍ［１４］中部分使用了此方式。

２．２．５可扩展性

２．２．５．１平台本身的可扩展性

部分流式计算平台除了流式处理的核心功能外，还提供了其他的扩展功能。良好的可扩展性会扩大平台的使用场景，为此平台需要有可扩展的接口，或者流式处理核心框架足够灵活，允许用户在其上实现其他复杂逻辑。比如ＳｔｒｅａｍＢａｓｅ平台提供了一些适配器，可以从ＣＳＶ、ＪＤＢＣ等来源读取数据，用户也可以订制其他适配器。Ｓｔｏｒｍ在平台下实现了Ｔｒｉｄｅｎｔ，可以提供额外的如保障一次处理和在内存中执行ＭａｐＲｅｄｕｃｅ的功能。

２．２．５．２对其他语言的支持

一些计算平台为了弥补自身语言限制的不足，使用了ＪＳＯＮ序列化的方案以和其他编程语言交换数据，或者使用Ｔｈｒｉｆｔ方案以统一编程语言之间的接口进而支持其他语言。这两种方案都还有改进空间：ＪＳＯＮ序列化会转义非ＡＳＣＩＩ文本数据使得其不适合交换二进制数据，而使用Ｔｈｒｉｆｔ方案则需要为此生成额外的代码。

浙江大学硕士学位论文第２章相关技术２．３本章小结

本章首先介绍了一些知名流式计算平台的重要特点，接着从不同侧面介绍并分析了当前流式计算平台所采用的解决方案，为本文的流式计算平台的设计提供了参考。

浙江大学硕士学位论文第３章ＤＳｔｒｅａｍ流式计算平台的系统设计

第３章ＤＳｔｒｅａｍ流式计算平台的系统设计

本章在借鉴了其他分布式流式计算项目的一些特性的基础上，提出了分布式流式计算平台ＤＳｔｒｅａｍ的系统设计方案。

３．１平台特点

ＤＳｔｒｅａｍ是分布式流式计算的简称，如何在分布式环境下让数据自由流动，并合理利用所有计算资源是本平台设计考虑的重点。为了使平台的使用者及开发者能够方便地进行二次开发及相关调试，本平台也有一定相应设计。ＤＳｔｒｅａｍ在设计之初即为一个轻量的，只处理流式计算相关任务的平台，但计算组件难免会用到其他的资源，如外部关系型数据库，内存数据库等。对此，ＤＳｔｒｅａｍ提供了一种简单的开放式的可插拔服务组件机制使得平台本身可以方便扩展。具体来说，ＤＳｔｒｅａｍ平台具有以下特点：

动态调度：当数据流速度过快时，平台可以自动挑选合适的节点增加处理单元的实例个数。当数据流速度降低时，平台会销毁闲置的处理单元实例以释放计算资源。

高可用性：对于平台内的某个处理单元实例意外崩溃的情况，ＤＳｔｒｅａｍ可以自动重新运行该处理单元，必要时ＤＳｔｒｅａｍ将会在其他节点进行重试。对于主控节点崩溃的情况，ＤＳｔｒｅａｍ集群将暂时失去全局调度能力但依然保持数据处理能力，待主控节点恢复时即可全面恢复功能。对于单个计算节点故障的情况，ＤＳｔｒｅａｍ会自动在其他计算节点上重试故障节点上正在进行处理和尚未处理完的消息。

高可扩展性：ＤＳｔｒｅａｍ平台基于Ｊａｖａ实现，对于继承ＪａｖａＲｕｎｎａｂｌｅ实现的Ｊａｖａ线程处理单元提供原生支持，对于使用其他语言实现的处理单元，ＤＳｔｒｅａｍ通过Ｄ．Ｂｕｓ提供统一的接口，使得其他语言在无需依赖ＤＳｔｒｅａｍ代码的情况下就可以实际使用ＤＳｔｒｅａｍ功能。另外，平台提供了一套简单的框架，允许加载

浙江大学硕士学位论文第３章ＤＳｔｒｅａｍ流式计算平台的系统设计

额外的服务组件，如自定义的数据库服务组件，补充ＤＳｔｒｅａｍ在存储等方面缺失的功能。

低延迟：对于流式计算的应用场景，用户对实时性要求很高。ＤＳｔｒｅａｍ使用了恰当的队列设计以及高效的节点间通信手段，最大可能地降低延迟。

方便开发及调试：对于升级的处理单元，ＤＳｔｒｅａｍ可以在无需停止现有数据流的情况下将系统中运行的对应处理单元替换成升级后的版本。

３．２概念及定义

３．２．１处理单元

处理单元（ＰｒｏｃｅｓｓｉｎｇＥｌｅｍｅｎｔ）为基本的可运行程序。在ＤＳｔｒｅａｍ平台中，处理单元可以是Ｊａｖａ线程或者是操作系统可以运行的进程，后者将通过Ｄ．Ｂｕｓ接口同ＤＳｔｒｅａｍ交互。同一个处理单元可以有多个运行的实例，也可以分布在不同的工作节点上。ＤＳｔｒｅａｍ允许用户定义处理单元的实例个数的最大值和最小值，也可以详细指定某个节点上某个处理单元实例的个数。对于用户没有指定的情况，ＤＳｔｒｅａｍ将自动按照系统资源和数据流速确定实例数。

３．２．２拓扑图

拓扑图（Ｔｏｐｏｌｏｇｙ）为连接处理单元的一张有向图，描述了在平台中数据应该如何流动。如果处理单元Ａ到处理单元Ｂ有一条有向边，那么处理单元Ａ的任何实例的输出，如果满足处理单元Ｂ的输入条件，就会进入处理单元Ｂ的待处理队列。处理单元Ｂ的某一实例会从队列中取出数据来处理。考虑到数据本地性，平台会优先尝试使用本地的处理单元实例来处理，如果本地没有对应的处理单元，或者本地的处理单元实际已经堆积了一定数量未处理的数据，无法及时处理新数据，平台会尝试将数据交给远程节点处理。

如果处理单元Ａ有多个后继处理单元，那么处理单元Ａ的输出，只要满足后继处理单元的输入要求，就会传给后继处理单元。对于拓扑图中的入度为０的处理

本文来源：https://www.bwwdw.com/article/0iiq.html