基于Storm的实时大数据处理

基于Storm的实时大数据处理 摘要：随着互联网的发展，需求也在不断地改变，基于互联网的营销业务生命周期越来越短，业务发展变化越来越快，许多业务数据量以指数级增长等等都要求对大量的数据做实时处理，并要求保证数据准确可靠。面对这些挑战云计算、大数据概念应运而生，Hadoop、Storm等技术如雨后春笋般出现。本文就当今最火的实时流数据处理系统Storm进行详细介绍。在介绍Storm之前首先详细介绍了实时计算和分布式系统相关技术概念以便为后面内容做铺垫。通过对Storm的基本概念、核心理念、运行机制和编程场景进行了全面的探讨，使得我们对Storm有了一个比较全面的理解和方便我们在这方面进行更进一步的学习。 关键字：Storm；实时大数据；流数据处理

1 概要 当今世界，信息爆炸的时代，互联网上的数据正以指数级别的速度增长。新浪微博注册用户已经超过3亿，用户日平均在线时长60min，平均每天发布超过1亿条微博[1]。在这种背景下，云计算的概念被正式提出，立即引起了学术界和产业界的广泛关注和参与。Google是云计算最早的倡导者，随后各类大型软件公司都争先在“云计算”领域进行一系列的研究和部署工作。目前最流行的莫过于Apache的开源项目Hadoop分布式计算平台，Hadoop专注于大规模数据存储和处理。这种模型对以往的许多情形虽已足够，如系统日志分析、网页索引建立（它们往往都是把过去一段时间的数据进行集中处理），但是在实时大数据方面，Hadoop的MapReduce却显得力不从心，业务场景中需要低延迟的响应，希望在秒级别或者毫秒级别完成分析，得到响应，并希望能够随着数据量的增大而扩展。此时，Twitter公司推出开源分布式、容错的实时流计算系统Storm，它的出现使得大规模数据实时处理成为可能，填补了该领域的空白。 Storm是一个类似于Hadoop可以处理大量数据流的分布式实时计算系统。但是二者存在很大的区，其最主要的区别在于Storm的数据一直在内存中流转，Hadoop使用磁盘作为交换介质，需要读写磁盘。在应用领域方面，Storm是基于流的实时处理，Hadoop是基于任务调度的批量处理。另一个方面，Hadoop基于HDFS需要切分输入数据、产生中间数据文件、排序、数据压缩、多份复制等，效率比较低，而Storm基于ZeroMQ这个高性能消息通讯库，不持久化数据[2]。

2 实时计算介绍 实时计算（Real-time computing）也称为即时计算，是计算机科学中对受到“实时约束”的计算机硬件和计算机软件系统的研究，实时约束是从事件发生到系统回应之间的最长时间限制。实时程序必须保证在严格的时间限制内响应。 互联网领域的实时计算一般都是针对海量数据进行的，实时计算最重要的一个需求是能够实时响应计算结果，一般要求为秒级。互联网行业的实时计算可以分为以下两种应用场景： （1）持续计算：主要用于互联网流式数据处理。所谓流式数据是指将数据看作是数据流的形式来处理。数据流是一系列数据记录的集合体。常见的数据流如网站的访问 PV/UV、点击、搜索关键字。 （2）实时分析：主要用于特定场合下的数据分析处理。当数据量很大，且存在无穷的查询条件组合，或穷举并提前计算和保存结果的代价很大时，实时计算就可以发挥作用，将部分计算或全部计算过程推迟到查询阶段进行，但要求能够实时响应。 实时计算需要解决的问题和难点是实时存储和实时计算。实时存储可以通过使用高性能的NoSQL存储来实现，实时的计算需要依赖于计算过程全内存化。实时计算过程一般划分为以下三个阶段：数据的产生与收集、传输与分析处理、存储并对外提供服务。对于分布式系统来说，系统的可配置性、可维护性、可伸缩性十分重要，实时计算并不适用于所有场景，因此需要根据实际业务需求和实际场景，从众多的技术和框架中进行选择。

3 分布式系统相关技术介绍 3.1 HBase HBase是一个高可靠、高性能、面向列、可伸缩的开源分布式数据库，根据Google发表的Bigtable论文进行设计，可以说是Google Bigtable的开源实现。与Bigtable依赖于GFS作为其文件存储系统和Chubby作为集群协同服务类似，HBase的依赖于Hadoop HDFS提供的底层文件存储服务和Zookeeper提供的协同服务，并使用Hadoop MapReduce作为其海量数据处理的编程模型。使用者利用廉价的PC服务器便可以搭建HBase组成的大规模结构化存储集群[1]。HBase使用Java开发，实现了Bigtable的大部分特性，JVM之上的语言可以直接利用其提供的API，而其他语言可以通过Thrift API或RESFul API来实现调用。HBase基于HDFS提供的高可靠的底层存储支持以及 Zookeeper提供的稳定的协调服务和故障恢复（fail-over）机制，为上层提供结构化存储服务，而Hadoop MapReduce为HBas和HDFS提供了高性能的并行计算能力。与关系数据库不同，HBase更适合于存储非结构化的数据，能够对大规模的数据提供随机、实时的读写访问。 3.2 Zookeeper Zookeeper分布式服务框架是Apache Hadoop的一个子项目，是Hadoop集群管理的一个必不可少的模块，其实现的功能与Google的Chubby基本一致，主要用来解决分布式集群中应用系统的一致性问题，为分布式集群提供了配置信息维护，统一命名服务、状态同步服务、集群管理、队列管理等支持[1]。Zookeeper实现了分布式系统中复杂易错的关键服务，为用户提供简单易用的接口和高性能高可用的系统。 Zookeeper提供基于类似文件系统的目录节点树的方式来存储数据（但并不适合于存储大数据），通过维护和监控数据的状态变化，从而达到基于数据的集群管理的效果。

4 Storm机制 Storm 是 Twitter 公司开源的一个分布式的、可伸缩的、容错的实时计算系统。如同Hadoop大大简化了并行批量数据处理，Storm定义了一批实时计算的原语，大大简化了并行实时数据处理。从总体架构上来看，Storm 与 Hadoop 非常相似，且解决了 Hadoop 实时性差的问题，因此也被称为“实时的 Hadoop”系统。可以说，Storm 之于实时处理，就好比 Hadoop 之于批处理[2]。表1从系统角色、应用名称、组件接口三个方面展示了 Hadoop 与 Storm之间的对应关系和相似性。 Hadoop Storm 作用

系统角色 JobTracker Nimus 任务调度，资源管理

TaskTracker Supervisor 启动和停止执行进程，汇报节点状态 Child Worker 业务逻辑具体执行的进程

应用名称 Job Topology 用户自定义任务 组件接口 Mapper/Reducer Spout/Bolt 编程模型 表1 Hadoop与Storm Storm是当今最火的流式处理解决方案，拥有非常多的特性，下面就其主要特性进行介绍： （1）广泛的适用场景。基于Storm 提供的基础原语之上可以构建满足许多应用场景的实时计算应用。Storm 提供简单的API使得开发者能够轻松地编写复杂、可靠的实时数据处理应用来处理无界的持续的流数据。如实时分析、在线机器学习、持续计算、分布式 RPC、ETL 处理等。 （2）高可伸缩性。Zookeeper来配置进程管理，是的Storm的集群扩展十分方便。Storm的可伸缩性是的Storm每秒可以处理大量的信息。通过简单的添加及其并修改Topology的并行设置便可以动态的对集群进行水平扩展。 （3）高性能。Storm使用高性能的序列化工具Kryo和消息队列ZeroMQ，且因为消息是无状态的，数据流不需要持久化，因此有着非常优秀的性能。在一个10个节点组成的小集群中，一个简单的应用每秒可以处理数以百万计的消息，包括上百次的数据库访问。 （4）高可靠性。实时系统必须保证所有的数据被成功的处理。允许丢失数据的系统的适用场景非常有限，与其丢失数据实的时系统相反，Storm有着高效可靠的消息确认机制，保证每一条消息都会被处理。 （5）异常健壮。相对于Hadoop集群，Storm集群更容易管理，这也是Storm的设计目标之一。Storm虽然也采用主从结构，但其节点的无状态性和fail-over的设计使得它并不存在单点故障问题。 （6）容错性。Storm保证一个Topology一直运行，除非它被显式停止。因此如果数据在处理过程中发生异常，Storm能够重新发现异常的场景。 （7）语言无关性。Storm的开发语言为Clojure和Java，非JVM语言可以通过stdin/stdout以JSON格式协议与Storm进行通信。Storm可Topology和消息处理组件可以用任何语言来定义，因此任何语言的开发者都可以使用Storm。

4.1 Storm 基本概念 为了理解Storm的架构和工作原理，开发基于Storm的实时处理应用，有必要深入理解Storm的一些基本概念，图1形象地描述了Storm中一些基本元素的相互关心，以下是对Storm中一些关键基本概念的介绍。

图1 Storm基本元素示意图 （1）Topology：即计算拓扑，是一个由Spouts和Bolts通过stream groupings连接组成的图状结构，其中封装着实时计算应用程序的逻辑。Storm的Topology与Hadoop的 Job类似，不同的是一个MapReduce Job最终会结束，然而一个Storm的Topology会一直运行（除非它被显式的停止）。 （2）Stream：消息流Stream是Storm里面最关键的抽象。Stream是无界的tuples序列，这些tuples以一种分布式的方式并行地创建和处理。我们可以通过对Stream中的tuple的schema的命名来定义Steam的schema。每个Stream定义时都会声明一个ID，默认为“default”。tuple的字段类型可以使用编程语言中的基本类型，但也可以使用自定义类型，只要实现对应的序列化器。 （3）Spout：它是Topology中消息流的源，即tuple的生产者。一般来说Spout从一个外部源（如kestrel队列或Twitter的流API）读取数据并向Topology里面发送tuple。消息源Spout分为可靠与不可靠两张类别。可靠的消息源中，如果一个tuple没有被Storm成功的处理，则会被重新发送。不可靠的Spout的tuple只发送一次，不理会tuple是否成功被处理。Spout可以发送多条消息流Stream，只需声明所发送的多个消息流，并在发送tuple时指定使用的Stream。 （4）Bolt：它是Topology中的消息处理单元，封装着消息处理的业务逻辑，是消息的消费者和生产者。Bolt可以执行过滤、聚合、连接、数据库访问等操作。复杂的消息流处理往往需要很多步骤，从而也就需要经过很多Bolts。与Spout类似，Bolts也可以发射多条消息流。 （5）Stream Grouping：声明每个Bolt接受哪些流作为输入时构建一个Topology的基本步骤，而Stream grouping则是定义了流在Bolt的tasks中是如何分配的，即下游的Bolt对上游的Spout或Bolt的订阅方式。Storm提供了7中内建的Stream grouping方式，也可以通过实现CustomStreamGrouping接口来自定义stream grouping，以下是对Storm提供的7种stream grouping的介绍： a) Shuffle grouping：随机分组，随机的在Bolt的tasks实例之间分发图tuple，保证每个Bolt接受到的tuple数目相同。 b) Field grouping：安字段分组，保证stream中指定的字段拥有相同值的tuple会被分发到同一个task中，不同值的tuple一般分布到不同的task中。 c) All grouping：广播发送，表示stream中每一个tuple都会被复制，分发给Bolt的所有task实例。 d) Global grouping：全局分组，整个stream中的所有tuple会被汇集到Bolt的一个task实例中，一般选择汇集到ID值最小的task中。 e) None grouping：不分组，表示stream不关心如何分组。目前这种分组和Shuffle grouping是一样的效果，不同的是Storm会把这种Bolt放到它所订阅的Spout或Bolt的同一个线程里面去执行。 f) Direct grouping：直接分组，这是一种比较特别的分组方法，tuple的发送者明确指定由消息接收者的某一个task处理这个消息。只有被声明为direct stream的stream才可以使用该分组方法。 Local or shuffle grouping：表示若目标Bolt有一个或多个tasks在同一个worker进程中，则会将所有tuples随机分组给进程中的tasks。否则，跟普通的shuffle grouping效果一样。 （6）Reliability：Storm提供了一种消息确认机制来保证每个tuple都会被Topology完整的执行，如图2所示。Storm会追踪由每个Spout tuple所产生的tuple树（一个Bolt处理一个tuple之后可能会发射别的tuple从而可以形成树状结构），并且跟踪这棵tuple树什么时候成功处理完。每个Topology都有一个消息超时的设置，如果Storm在设置时间内没有检