基于Twitter Storm数据实时研究处理工具探究.docVIP

基于Twitter Storm数据实时研究处理工具探究 　　【摘要】过去的十年是数据处理变革的十年，MapReduce，Hadoop以及一些相关的技术使得我们能处理的数据量比以前要大得多得多。但是这些数据处理技术都不是实时的系统，它们设计的目的也不是为了实时计算。没有什么办法可以简单地把hadoop变成一个实时计算系统。然而大规模的实时数据处理已经越来越成为一种业务需求了，而缺少一个“实时版本的hadoop”已经成为数据处理整个生态系统的一个巨大缺失。twitter storm的出现弥补了hadoop在实时处理方面的不足，本文就twitter storm在实时数据计算方面的优点和架构实现进行研究。 【关键词】twitter storm 实时计算 实时数据处理 一、Twitter Storm的优点 Storm出现之前，你可能需要自己手动维护一个由消息队列和消息处理者所组成的实时处理网络，消息处理者从消息队列取出一个消息进行处理，更新数据库，发送消息给其它队列，等等等等。不幸的是，这种方式有以下几个缺陷： （1）单调乏味：你花费了绝大部分开发时间去配置把消息发送到哪里，部署消息处理者，部署中间消息节点 — 你的大部分时间花在设计，配置这个数据处理框架上，而你真正关心的消息处理逻辑在你的代码里面占的比例很少。 （2）脆弱：不够健壮，你要自己写代码保证所有的消息处理者和消息队列正常运行。 （3）伸缩性差：当一个消息处理者的消息量达到阀值，你需要对这些数据进行分流，你需要配置这些新的处理者以让他们处理分流的消息。 虽然对于一个大量消息处理系统来说，分解到最后就是消息队列和消息处理者的组合，而消息处理无疑是实时计算的基础。那么现在问题就是：怎样去做才能不丢失数据，可以很好的扩展到更大的消息量并且非常容易操作呢？ Storm定义了一批实时计算的原语。如同hadoop大大简化了并行批量数据处理，storm的这些原语大大简化了并行实时数据处理。storm的一些关键特性如下： （1）适用场景广泛： storm可以用来处理消息和更新数据库（消息流处理）， 对一个数据量进行持续的查询并返回客户端（持续计算）， 对一个耗资源的查询作实时并行化的处理（分布式方法调用），storm的这些基础原语可以满足大量的场景。 （2）可伸缩性高：Storm的可伸缩性可以让storm每秒可以处理的消息量达到很高。为了扩展一个实时计算任务，你所需要做的就是加机器并且提高这个计算任务的并行度设置（parallelism setting）。作为Storm可伸缩性的一个例证， 一个Storm应用在一个10个节点的集群上每秒处理1000000个消息，包括每秒一百多次的数据库调用。Storm使用ZooKeeper来协调集群内的各种配置使得Storm的集群可以很容易的扩展很大。 （3）保证无数据丢失： 实时系统必须保证所有的数据被成功的处理。 那些会丢失数据的系统的适用场景非常窄， 而storm保证每一条消息都会被处理， 这一点和S4相比有巨大的反差。 （4）异常健壮：不像Hadoop—出了名的难管理，storm集群非常容易管理。容易管理是storm的设计目标之一。 （5）容错性好：如果在消息处理过程中出了一些异常，storm会重新安排这个出问题的处理逻辑。storm保证一个处理逻辑永远运行，除非你显式杀掉这个处理逻辑。 （6）语言无关性：健壮性和可伸缩性不应该局限于一个平台。Storm的topology和消息处理组件可以用任何语言来定义，这一点使得任何人都可以使用storm。 二、Twitter Storm的关键概念 （1）计算拓补（Topologies） ：一个实时计算应用程序的逻辑在storm里面被封装到topology对象里面，我把它叫做计算拓补。Storm里面的topology相当于Hadoop里面的一个MapReduce Job，它们的关键区别是：一个MapReduce Job最终总是会结束的，然而一个storm的topoloy会一直运行，除非你显式的杀死它。 一个Topology是Spouts和Bolts组成的图状结构， 而链接Spouts和Bolts的则是Stream groupings。 （2）消息流（Streams）：消息流是storm里面的最关键的抽象。一个消息流是一个没有边界的tuple序列， 而这些tuples会被以一种分布式的方式并行地创建和处理。对消息流的定义主要是对消息流里面的tuple的定义，我们会给tuple里的每个字段一个名字。并且不同tuple的对应字段的类型必须一样。也就是说： 两个tuple的第一个字段的类型必须一样，第二个字段的类型必须一