一脸懵逼学习Storm---(一个开源的分布式实时计算系统)

Storm的官方网址:http://storm.apache.org/index.html

1:什么是Storm?

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

2:Storm的特点:

(1)编程模型简单
   在大数据处理方面相信大家对hadoop已经耳熟能详,基于Google Map/Reduce来实现的Hadoop为开发者提供了map、reduce原语,使并行批处理程序变得非常地简单和优美。
   同样,Storm也为大数据 的实时计算提供了一些简单优美的原语,这大大降低了开发并行实时处理的任务的复杂性,帮助你快速、高效的开发应用。
(2)可扩展
   在Storm集群中真正运行topology的主要有三个实体:工作进程、线程和任务。Storm集群中的每台机器上都可以运行多个工作进程,每个 工作进程又可创建多个线程,每个线程可以执行多个任务,任务是真正进行数据处理的实体,我们开发的spout、bolt就是作为一个或者多个任务的方式执 行的。
   因此,计算任务在多个线程、进程和服务器之间并行进行,支持灵活的水平扩展。
(3)高可靠性
   Storm可以保证spout发出的每条消息都能被“完全处理”,这也是直接区别于其他实时系统的地方,如S4。
   spout发出的消息后续可能会触发产生成千上万条消息,可以形象的理解为一棵消息树,其中spout发出的消息为树根,Storm会跟踪 这棵消息树的处理情况,只有当这棵消息树中的所有消息都被处理了,Storm才会认为spout发出的这个消息已经被“完全处理”。如果这棵消息树中的任 何一个消息处理失败了,或者整棵消息树在限定的时间内没有“完全处理”,那么spout发出的消息就会重发。

(4)高容错性
   如果在消息处理过程中出了一些异常,Storm会重新安排这个出问题的处理单元。Storm保证一个处理单元永远运行(除非你显式杀掉这个处理单元)。
   当然,如果处理单元中存储了中间状态,那么当处理单元重新被Storm启动的时候,需要应用自己处理中间状态的恢复。
(5)Storm集群和Hadoop集群表面上看很类似。Hadoop上运行的是MapReduce jobs,而在Storm上运行的是拓扑(topology);
   Hadoop擅长于分布式离线批处理,而Storm设计为支持分布式实时计算;
   Hadoop新的spark组件提供了在hadoop平台上运行storm的可能性;

3:Storm的基本概念:

在深入理解Storm之前,需要了解一些概念:
  Topologies : 拓扑,也俗称一个任务
  Spouts : 拓扑的消息源
  Bolts : 拓扑的处理逻辑单元
  tuple:消息元组
  Streams : 流
  Stream groupings :流的分组策略
  Tasks : 任务处理单元
  Executor :工作线程
  Workers :工作进程
  Configuration : topology的配置

4:Storm与Hadoop的对比:

(1)Topology 与 Mapreduce :
   一个关键的区别是: 一个MapReduce job最终会结束, 而一个topology永远会运行(除非你手动kill掉)
(2)Nimbus 与 ResourManager:
   在Storm的集群里面有两种节点: 控制节点(master node)和工作节点(worker node)。控制节点上面运行一个叫Nimbus后台程序,它的作用类似Hadoop里面的JobTracker。Nimbus负责在集群里面分发代码,分配计算任务给机器, 并且监控状态。
(3)Supervisor (worker进程)与NodeManager(YarnChild):
   每一个工作节点上面运行一个叫做Supervisor的节点。Supervisor会监听分配给它那台机器的工作,根据需要启动/关闭工作进程。每一个工作进程执行一个topology的一个子集;一个运行的topology由运行在很多机器上的很多工作进程组成。 

5:Storm 体系架构:

(1)Nimbus和Supervisor之间的所有协调工作都是通过Zookeeper集群完成。:
(2)Nimbus进程和Supervisor进程都是快速失败(fail-fast)和无状态的。所有的状态要么在zookeeper里面, 要么在本地磁盘上。
(3)这也就意味着你可以用kill -9来杀死Nimbus和Supervisor进程, 然后再重启它们,就好像什么都没有发生过。这个设计使得Storm异常的稳定。

  5.1:Storm中的Nimbus和Supervisor:

  5.2:Storm中的Topologies: 一个topology是spouts和bolts组成的图, 通过stream groupings将图中的spouts和bolts连接起来,如下图:

  5.3:Storm中的Stream     消息流stream是storm里的关键抽象;     一个消息流是一个没有边界的tuple序列, 而这些tuple序列会以一种分布式的方式并行地创建和处理;     通过对stream中tuple序列中每个字段命名来定义stream;     在默认的情况下,tuple的字段类型可以是:integer,long,short, byte,string,double,float,boolean和byte array;     可以自定义类型(只要实现相应的序列化器)。

  5.4:Storm中的Spouts     消息源spout是Storm里面一个topology里面的消息生产者;     一般来说消息源会从一个外部源读取数据并且向topology里面发出消息:tuple;     Spouts可以是可靠的也可以是不可靠的:如果这个tuple没有被storm成功处理,可靠的消息源spouts可以重新发射一个tuple, 但是不可靠的消息源spouts一旦发出一个tuple就不能重发了;     消息源可以发射多条消息流stream:          使用OutputFieldsDeclarer.declareStream来定义多个stream,             然后使用SpoutOutputCollector来发射指定的stream。   5.4:Storm中的Bolts     所有的消息处理逻辑被封装在bolts里面;     Bolts可以做很多事情:过滤,聚合,查询数据库等等。     Bolts可以简单的做消息流的传递,也可以通过多级Bolts的组合来完成复杂的消息流处理;比如求TopN、聚合操作等(如果要把这个过程做得更具有扩展性那么可能需要更多的步骤)。     Bolts可以发射多条消息流:          使用OutputFieldsDeclarer.declareStream定义stream;          使用OutputCollector.emit来选择要发射的stream;     Bolts的主要方法是execute,:          它以一个tuple作为输入,使用OutputCollector来发射tuple;          通过调用OutputCollector的ack方法,以通知这个tuple的发射者spout;     Bolts一般的流程:       处理一个输入tuple,  发射0个或者多个tuple, 然后调用ack通知storm自己已经处理过这个tuple了;            storm提供了一个IBasicBolt会自动调用ack。  5.5:Storm中的Stream groupings     定义一个topology的关键一步是定义每个bolt接收什么样的流作为输入;     stream grouping就是用来定义一个stream应该如何分配数据给bolts;     Storm里面有7种类型的stream grouping:       Shuffle Grouping——随机分组, 随机派发stream里面的tuple,保证每个bolt接收到的tuple数目大致相同;       Fields Grouping——按字段分组, 比如按userid来分组, 具有同样userid的tuple会被分到相同的Bolts里的一个task, 而不同的userid则会被分配到不同的bolts里的task;       All Grouping——广播发送,对于每一个tuple,所有的bolts都会收到;          Global Grouping——全局分组, 这个tuple被分配到storm中的一个bolt的其中一个task。再具体一点就是分配给id值最低的那个task;       Non Grouping——不分组,这个分组的意思是说stream不关心到底谁会收到它的tuple。目前这种分组和Shuffle grouping是一样的效果, 有一点不同的是storm会把这个bolt放到这个bolt的订阅者同一个线程里面去执行;       Direct Grouping——直接分组, 这是一种比较特别的分组方法,用这种分组意味着消息的发送者指定由消息接收者的哪个task处理这个消息。 只有被声明为Direct Stream的消息流可以声明这种分组方法。而且这种消息tuple必须使用emitDirect方法来发射。       消息处理者可以通过TopologyContext来获取处理它的消息的task的id (OutputCollector.emit方法也会返回task的id);       Local or shuffle grouping——如果目标bolt有一个或者多个task在同一个工作进程中,tuple将会被随机发生给这些tasks。否则,和普通的Shuffle Grouping行为一致。   5.6:Storm中的Workers     一个topology可能会在一个或者多个worker(工作进程)里面执行;     每个worker是一个物理JVM并且执行整个topology的一部分;     比如,对于并行度是300的topology来说,如果我们使用50个工作进程来执行,那么每个工作进程会处理其中的6个tasks;     Storm会尽量均匀的工作分配给所有的worker;   5.7:Storm中的Tasks     每一个spout和bolt会被当作很多task在整个集群里执行     每一个executor对应到一个线程,在这个线程上运行多个task     stream grouping则是定义怎么从一堆task发射tuple到另外一堆task     可以调用TopologyBuilder类的setSpout和setBolt来设置并行度(也就是有多少个task)

6:离线计算是什么?流式计算是什么?

1:离线计算是什么?
    离线计算:批量获取数据、批量传输数据、周期性批量计算数据、数据展示
    代表技术:Sqoop批量导入数据、HDFS批量存储数据、MapReduce批量计算数据、Hive批量计算数据、azkaban任务调度
    1,hivesql
    2、调度平台
    3、Hadoop集群运维
    4、数据清洗(脚本语言)
    5、元数据管理
    6、数据稽查
    7、数据仓库模型架构

2:流式计算是什么
    流式计算:数据实时产生、数据实时传输、数据实时计算、实时展示
    代表技术:Flume实时获取数据、Kafka/metaq实时数据存储、Storm/JStorm实时数据计算、Redis实时结果缓存、持久化存储(mysql)。
    一句话总结:将源源不断产生的数据实时收集并实时计算,尽可能快的得到计算结果

3:离线计算与实时计算的区别
    最大的区别:实时收集、实时计算、实时展示

4:Storm是什么?
    Flume实时采集,低延迟
    Kafka消息队列,低延迟
    Storm实时计算,低延迟
    Redis实时存储,低延迟
    Storm用来实时处理数据,特点:低延迟、高可用、分布式、可扩展、数据不丢失。提供简单容易理解的接口,便于开发。
    海量数据?数据类型很多,产生数据的终端很多,处理数据能力增强

5:Storm与Hadoop的区别
    Storm用于实时计算,Hadoop用于离线计算。
    Storm处理的数据保存在内存中,源源不断;Hadoop处理的数据保存在文件系统中,一批一批。
    Storm的数据通过网络传输进来;Hadoop的数据保存在磁盘中。
    Storm与Hadoop的编程模型相似
Job:任务名称
JobTracker:项目经理
TaskTracker:开发组长、产品经理
Child:负责开发的人员
Mapper/Reduce:开发人员中的两种角色,一种是服务器开发、一种是客户端开发

Topology:任务名称
Nimbus:项目经理
Supervisor:开组长、产品经理
Worker:开人员
Spout/Bolt:开人员中的两种角色,一种是服务器开发、一种是客户端开发

 7、Storm核心组件:

Nimbus:负责资源分配和任务调度。Nimbus任务分配,对任务监控。
Supervisor:负责接受nimbus分配的任务,启动和停止属于自己管理的worker进程。---通过配置文件设置当前supervisor上启动多少个worker。Supervisor当前物理机器上的管理者,接受Nimbus分配的任务,启动自己的Worker,Worker数量是根据端口号来的。
Worker:运行具体处理组件逻辑的进程。Worker运行的任务类型只有两种,一种是Spout任务,一种是Bolt任务。Worker执行具体任务的组件,任务类型有两种,分别是Spout任务,bolt任务,一个worker中可能同时存在多个spout任务和多个bolt任务。
Task:worker中每一个spout/bolt的线程称为一个task. 在storm0.8之后,task不再与物理线程对应,不同spout/bolt的task可能会共享一个物理线程,该线程称为executor。Task是Spout任务,bolt任务,每个Task属于某个组件并发度中的一个。一个Task本质是一个线程。默认情况下,executor=thread=task并发度:一个类型的任务,被几个线程同时执行。

8、Storm编程模型:

Topology:Storm中运行的一个实时应用程序的名称。(拓扑)
Spout:在一个topology中获取源数据流的组件。
    通常情况下spout会从外部数据源中读取数据,然后转换为topology内部的源数据。spout获取外部数据源。
Bolt:接受数据然后执行处理的组件,用户可以在其中执行自己想要的操作。bolt业务逻辑处理节点,可以存在多个,将结果数据保存到redis上面,bolt是并发执行的,多个线程在同时做意见事情。
Tuple:一次消息传递的基本单元,理解为一组消息就是一个Tuple。tuple消息发送的最小单元,是一个tuple对象,对象有一个list。
Stream:表示数据的流向。streamGroup数据分组策略。一个storm程序可以获取多个数据源。一个topology的数据是自己独有的,和其他的topology没有关系。

9:Storm架构和编程模型总结

1、编程模型
    DataSource:外部数据源
    Spout:接受外部数据源的组件,将外部数据源转化成Storm内部的数据,以Tuple为基本的传输单元下发给Bolt
    Bolt:接受Spout发送的数据,或上游的bolt的发送的数据。根据业务逻辑进行处理。发送给下一个Bolt或者是存储到某种介质上。介质可以是Redis可以是mysql,或者其他。
    Tuple:Storm内部中数据传输的基本单元,里面封装了一个List对象,用来保存数据。
    StreamGrouping:数据分组策略
        7种:shuffleGrouping(Random函数),Non Grouping(Random函数),FieldGrouping(Hash取模)、Local or ShuffleGrouping 本地或随机,优先本地。
        
2、并发度
    用户指定的一个任务,可以被多个线程执行,并发度的数量等于线程的数量。一个任务的多个线程,会被运行在多个Worker(JVM)上,有一种类似于平均算法的负载均衡策略。尽可能减少网络IO,和Hadoop中的MapReduce中的本地计算的道理一样。
    
    
3、架构
    Nimbus:任务分配
    Supervisor:接受任务,并启动worker。worker的数量根据端口号来的。
    Worker:执行任务的具体组件(其实就是一个JVM),可以执行两种类型的任务,Spout任务或者bolt任务。
    Task:Task=线程=executor。 一个Task属于一个Spout或者Bolt并发任务。
    Zookeeper:保存任务分配的信息、心跳信息、元数据信息。
    
4、Worker与topology
    一个worker只属于一个topology,每个worker中运行的task只能属于这个topology。    反之,一个topology包含多个worker,其实就是这个topology运行在多个worker上。
    一个topology要求的worker数量如果不被满足,集群在任务分配时,根据现有的worker先运行topology。如果当前集群中worker数量为0,那么最新提交的topology将只会被标识active,不会运行,只有当集群有了空闲资源之后,才会被运行。

待续......

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT技术精选文摘

Netty高性能之道

1. 背景 1.1. 惊人的性能数据 最近一个圈内朋友通过私信告诉我,通过使用Netty4 + Thrift压缩二进制编解码技术,他们实现了10W TPS(1K...

2287
来自专栏性能与架构

Java 9 新特性:Reactive Streams

2712
来自专栏架构师之旅

【Java SE】Java NIO系列教程(一) Java NIO 概述

Java NIO 由以下几个核心部分组成: Channels Buffers Selectors 虽然Java NIO 中除此之外还有很多类和组件,但在我看来...

1957
来自专栏Java Edge

Kafka架构解析1之背景及架构介绍简介为何使用消息系统常用Message Queue对比Kafka架构拓扑结构Producer消息路由

3195
来自专栏C#

简单易用的.NET免费开源RabbitMQ操作组件EasyNetQ解析

   对于目前大多的.NET项目,其实使用的技术栈都是差不多,估计现在很少用控件开发项目的了,毕竟一大堆问题。对.NET的项目,目前比较适合的架构ASP.NET...

2438
来自专栏偏前端工程师的驿站

Architecture Pattern: Publish-subscribe Pattern

1. Brief                               一直对Observer Pattern和Pub/Sub Pattern有所混淆,下...

18310
来自专栏前沿技墅

再聊服务化基石:也有IO的事儿

1335
来自专栏Java编程技术

高性能网络通信框架Netty-基础概念篇

Netty是一种可以轻松快速的开发协议服务器和客户端网络应用程序的NIO框架,它大大简化了TCP或者UDP服务器的网络编程,但是你仍然可以访问和使用底层的API...

972
来自专栏大数据架构

Kafka设计解析(八)- Exactly Once语义与事务机制原理

1433
来自专栏chenssy

【死磕Netty】-----Netty的核心组件

原文出处http://cmsblogs.com/ 『chenssy』 转载请注明原创出处,谢谢! 在第一篇博客中(【死磕Netty】-----NIO基础详解),...

3985

扫码关注云+社区