Storm -- 实时计算平台

2019-03-02 23:42|来源: 网路

1.1   实时流计算

互联网从诞生的第一时间起,对世界的最大的改变就是让信息能够实时交互,从而大大加速了各个环节的效率。正因为大家对信息实时响应、实时交互的需求,软件行业除了个人操作系统之外,数据库(更精确的说是关系型数据库)应该是软件行业发展最快、收益最为丰厚的产品了。记得十年前,很多银行别说实时转账,连实时查询都做不到,但是数据库和高速网络改变了这个情况。

随着互联网的更进一步发展,从Portal信息浏览型到Search信息搜索型到SNS关系交互传递型,以及电子商务、互联网旅游生活产品等将生活中的流通环节在线化。对效率的要求让大家对于实时性的要求进一步提升,而信息的交互和沟通正在从点对点往信息链甚至信息网的方向发展,这样必然带来数据在各个维度的交叉关联,数据爆炸已不可避免。因此流式处理加NoSQL产品应运而生,分别解决实时框架和数据大规模存储计算的问题。

早在7、8年前诸如UC伯克利、斯坦福等大学就开始了对流式数据处理的研究,但是由于更多的关注于金融行业的业务场景或者互联网流量监控的业务场景,以及当时互联网数据场景的限制,造成了研究多是基于对传统数据库处理的流式化,对流式框架本身的研究偏少。目前这样的研究逐渐没有了声音,工业界更多的精力转向了实时数据库。

2010年Yahoo!对S4的开源,2011年twitter对Storm的开源,改变了这个情况。以前互联网的开发人员在做一个实时应用的时候,除了要关注应用逻辑计算处理本身,还要为了数据的实时流转、交互、分布大伤脑筋。但是现在情况却大为不同,以Storm为例,开发人员可以快速的搭建一套健壮、易用的实时流处理框架,配合SQL产品或者NoSQL产品或者MapReduce计算平台,就可以低成本的做出很多以前很难想象的实时产品:比如一淘数据部的量子恒道品牌旗下的多个产品就是构建在实时流处理平台上的。

本教程是一本对storm的基础介绍手册,但是我们也希望它不仅仅是一本storm的使用手册,我们会在其中加入更多我们在实际数据生产过程的经验和应用的架构,最后的目的是帮助所有愿意使用实时流处理框架的技术同仁,同时也默默的改变这个世界。

1.2   Storm特点

Storm是一个开源的分布式实时计算系统,可以简单、可靠的处理大量的数据流。Storm有很多使用场景:如实时分析,在线机器学习,持续计算,分布式RPC,ETL等等。Storm支持水平扩展,具有高容错性,保证每个消息都会得到处理,而且处理速度很快(在一个小集群中,每个结点每秒可以处理数以百万计的消息)。Storm的部署和运维都很便捷,而且更为重要的是可以使用任意编程语言来开发应用。

Storm有如下特点:

  • 编程模型简单

在大数据处理方面相信大家对hadoop已经耳熟能详,基于Google Map/Reduce来实现的Hadoop为开发者提供了map、reduce原语,使并行批处理程序变得非常地简单和优美。同样,Storm也为大数据的实时计算提供了一些简单优美的原语,这大大降低了开发并行实时处理的任务的复杂性,帮助你快速、高效的开发应用。

  • 可扩展

在Storm集群中真正运行topology的主要有三个实体:工作进程、线程和任务。Storm集群中的每台机器上都可以运行多个工作进程,每个工作进程又可创建多个线程,每个线程可以执行多个任务,任务是真正进行数据处理的实体,我们开发的spout、bolt就是作为一个或者多个任务的方式执行的。

因此,计算任务在多个线程、进程和服务器之间并行进行,支持灵活的水平扩展。

  • 高可靠性

Storm可以保证spout发出的每条消息都能被“完全处理”,这也是直接区别于其他实时系统的地方,如S4。

请注意,spout发出的消息后续可能会触发产生成千上万条消息,可以形象的理解为一棵消息树,其中spout发出的消息为树根,Storm会跟踪这棵消息树的处理情况,只有当这棵消息树中的所有消息都被处理了,Storm才会认为spout发出的这个消息已经被“完全处理”。如果这棵消息树中的任何一个消息处理失败了,或者整棵消息树在限定的时间内没有“完全处理”,那么spout发出的消息就会重发。

考虑到尽可能减少对内存的消耗,Storm并不会跟踪消息树中的每个消息,而是采用了一些特殊的策略,它把消息树当作一个整体来跟踪,对消息树中所有消息的唯一id进行异或计算,通过是否为零来判定spout发出的消息是否被“完全处理”,这极大的节约了内存和简化了判定逻辑,后面会对这种机制进行详细介绍。

这种模式,每发送一个消息,都会同步发送一个ack/fail,对于网络的带宽会有一定的消耗,如果对于可靠性要求不高,可通过使用不同的emit接口关闭该模式。

上面所说的,Storm保证了每个消息至少被处理一次,但是对于有些计算场合,会严格要求每个消息只被处理一次,幸而Storm的0.7.0引入了事务性拓扑,解决了这个问题,后面会有详述。

  •  高容错性

如果在消息处理过程中出了一些异常,Storm会重新安排这个出问题的处理单元。Storm保证一个处理单元永远运行(除非你显式杀掉这个处理单元)。

当然,如果处理单元中存储了中间状态,那么当处理单元重新被Storm启动的时候,需要应用自己处理中间状态的恢复。

  • 支持多种编程语言

除了用java实现spout和bolt,你还可以使用任何你熟悉的编程语言来完成这项工作,这一切得益于Storm所谓的多语言协议。多语言协议是Storm内部的一种特殊协议,允许spout或者bolt使用标准输入和标准输出来进行消息传递,传递的消息为单行文本或者是json编码的多行。

Storm支持多语言编程主要是通过ShellBolt, ShellSpout和ShellProcess这些类来实现的,这些类都实现了IBolt 和 ISpout接口,以及让shell通过java的ProcessBuilder类来执行脚本或者程序的协议。

可以看到,采用这种方式,每个tuple在处理的时候都需要进行json的编解码,因此在吞吐量上会有较大影响。

  • 支持本地模式

Storm有一种“本地模式”,也就是在进程中模拟一个Storm集群的所有功能,以本地模式运行topology跟在集群上运行topology类似,这对于我们开发和测试来说非常有用。

  • 高效

用ZeroMQ作为底层消息队列, 保证消息能快速被处理

 

继续观看请跳转原创地址:http://blog.linezing.com/category/storm-quick-start


转自:http://www.cnblogs.com/subsir/articles/2838983

相关问答

更多
  • 当下雨的时候,风暴都到了
  • Storm是什么文件[2023-06-19]

    Storm译为汉语即‘暴风雨’、“暴风雪”,是暴风影音软件的英文名,是一种媒体播放器。   Storm还是一个分布式的、容错的实时计算系统,由BackType开发,广泛用于进行实时日志处理,实时统计、实时风控、实时推荐等场景中,目前最新版本是Storm 0.8.0。   Storm还是外文歌曲的名字,具体可在百度音乐中搜索。
  • 感谢您对Dataflow编程模型的兴趣! 的确,Dataflow和Apache Storm都支持流处理,但是有一些重要的区别: Dataflow支持同一个“窗口化”API下的批量和流式计算,而据我所知,Storm就是一个流式系统。 用于定义计算拓扑的API在Dataflow和Storm中非常不同。 Dataflow API很大程度上模仿了FlumeJava :您可以像操作真实集合一样操纵逻辑PCollection对象(并行集合;您可以将其视为逻辑数据集),并根据将不同并行操作(如ParDo )应用到其他结果 ...
  • 在风暴谷歌集团找到答案。 似乎DRCP拓扑将发出一个元组,其中包含由DRCP spout作为流接收的参数,然后在处理完成时指示回(使用称为请求ID的唯一标识)。 在同一个线程中,hadoop可能最适合这些情况,除非数据不够大,并且可以一直处理。 Found the answer in the storm google group. Seems that DRCP topologies will emit a tuple with parameters that is received by DRCP spo ...
  • 您可以使用Apache Kafka作为分布式和强大的队列,可以处理大量数据,并使您能够将邮件从一个端点传递到另一个端点。 风暴不是队列。 它是一种具有分布式实时处理能力的系统,意味着可以对实时数据进行并行执行各种操作。 这些工具的共同流程(据我所知)如下: 实时系统 - > Kafka - > Storm - > NoSql - > BI(可选) 所以你有你的实时应用程序处理大量的数据,发送到卡夫卡队列。 风暴从卡夫卡拉取数据并应用一些必要的操纵。 在这一点上,您通常希望从这些数据中获得一些好处,因此您可以 ...
  • 免责声明:我是Apache Flink提交者和PMC成员,只熟悉Storm的高级设计,而不是其内部。 Apache Flink是统一流和批处理的框架。 Flink的运行时原生支持这两个域,这是由于并行任务之间的流水线数据传输,包括流水线洗牌。 记录将立即从生产任务发送到接收任务(在收集缓冲区进行网络传输之后)。 可以使用阻止数据传输来选择执行批处理作业。 Apache Spark是一个支持批处理和流处理的框架。 Flink的批处理API看起来很相似,并且解决了与Spark类似的用例,但在内部方面却有所不同。 ...
  • 关于加缪,是的,启动工作的调度员应该工作。 他们在LinkedIn上使用的是Azkaban,你也可以看一下。 如果在另一个完成之前启动,则会读取一些数据量两次。 由于第二个作业将从第一个作业使用的相同偏移开始读取。 关于加缪与S3,目前我不认为这已经到位。 Kafka actually retains events for a configurable period of time -- events are not purged immediately upon consumption like othe ...
  • 你可以使用fieldsGrouping 。 您可以声明一个字段,通过该字段对元组进行分组(在您的情况下为id )。 我只是假设您的输入流是具有id和body字段的JSON对象 {"id":"1234","body":"some body"} 还假设您的拓扑结构有一个喷口,两个螺栓,即BoltA和BoltB。 在BoltB中,覆盖declareOutputFields方法并填写详细信息。 public void declareOutputFields(OutputFieldsDeclarer declare ...
  • 检查此链接 现在我可以在Netbeans中开发拓扑,在本地测试它们,并最终将它们部署到集群上的Nimbus。 这个解决方案对我很有用!!! 添加到配置文件: conf.put(Config.NIMBUS_HOST, "123.456.789.101); //YOUR NIMBUS'S IP conf.put(Config.NIMBUS_THRIFT_PORT,6627); //int is expected here 另外,添加以下内容: System.setProperty("storm.jar",

  • 我不知道你正在使用的平台,但在C ++ 10ms是永恒的 。 我认为你正在使用错误的工具来完成工作。 使用C ++,提供一些本地查询应该不到一微秒。 触摸多个内存位置和/或必须等待磁盘或网络I / O的非本地查询别无选择,只能花费更多时间。 在这种情况下,并行性是你最好的朋友。 你必须找到瓶颈。 是I / O吗? 是CPU吗? 是内存带宽吗? 是内存访问时间吗? 在找到瓶颈之后,您可以改进它,异步它和/或乘以(=并行化)它。 I don't know the platform you're using, b ...