Storm 介绍

介绍

Storm的简介

Storm是Twitter开源的分布式实时大数据处理框架，被业界称为实时版Hadoop。随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍，比如网站统计、推荐系统、预警系统、金融系统(高频交易、股票)等等，大数据实时处理解决方案（流计算）的应用日趋广泛，目前已是分布式技术领域最新爆发点，而Storm更是流计算技术中的佼佼者和主流。
按照storm作者的说法，Storm对于实时计算的意义类似于Hadoop对于批处理的意义。Hadoop提供了map、reduce原语，使我们的批处理程序变得简单和高效。同样，Storm也为实时计算提供了一些简单高效的原语，而且Storm的Trident是基于Storm原语更高级的抽象框架，类似于基于Hadoop的Pig框架，让开发更加便利和高效。

Storm的优点

• Storm实现的一些特征决定了他的性能和可靠性，Storm使用Netty传送消息，这就消除了中间的排队过程，使得消息能够直接在任务自身之间流动，在消息的背后，是一种用于序列化和反序列化Storm的的原语类型的自动化且高效的机制。
• Storm 的一个最有趣的地方是它注重容错和管理，Storm 实现了有保障的消息处理,所以每个元组(Turple)都会通过该拓扑(Topology)结构进行全面处理;
• 如果一个元组还未处理会自动从Spout处重发，Storm 还实现了任务级的故障检测，在一个任务发生故障时，消息会自动重新分配以快速重新开始处理。

Storm的特性

• 使用场景广泛
  • Storm可以实时处理数据和更新DB。
  • API可以满足大量的场景。
• 可伸缩性搞
  • Storm的可伸缩性可以让storm每秒可以处理的消息量达到很高。
  • Storm使用ZooKeeper来协调集群内的各种配置使得Storm的集群可以很容易的扩展。
• 保证数据五丢失
  • 实时系统必须保证所有的数据被成功的处理。storm保证每一条消息都会被处理。
• 异常健壮：
  • storm集群非常容易管理，轮流重启节点不影响应用。
• 容错性好：
  • 在消息处理过程中出现异常， storm会进行重试
• 语言无关性：
  • Storm的topology和消息处理组件(Bolt)可以用任何语言来定义， 这一点使得任何人都可以使用storm

Storm的物理架构

nimbus

• Storm的Master，负责资源分配和任务调度，一个Storm集群只有一个Nimbus
• 集群的主节点，对整个集群的资源进行管理
• nimbus是一个无状态的节点，所有的一切都存储在Zookeeper

supervisor

• Storm的Slave，负责接收Nimbus分配的任务，管理所有Worker
• 一个Supervisor节点中包含多个Worker进程。默认是4个
• 一般情况下一个topology对应一个worker

woker

• 每个工作进程里面有多个Task

Task

• Storm集群中每个Spout和Boly都有若干个任务（tasks）来执行
• worker中每一个spout/bolt的线程称为一个task
• 同一个spout/bolt的task可能会共享一个物理线程，该线程称为executor

Storm的并行机制

• Topology由一个或多个Spout/Bolt组件构成。运行中的Topology由一个或多Supervisor节点中的Worker构成
• 默认情况下一个Supervisor节点运行4个Worker，由defaults.yaml/storm.yaml中的属性决定：
  • supervisor.slots.ports：6700 6701 6702 6703
  • 在代码中可以使用new Config().setNumWorkers(3)，最大数量不能超过配置的supervisor.slots.ports数量。
• Worker为特定拓扑的一个或多个组件Spout/Bolt产生一个或多个Executor。默认情况下一个Worker运行一个Executor。
• Executor为特定拓扑的一个或多个组件Spout/Bolt实例运行一个或多个Task。默认情况下一个Executor运行一个Task。

DAG

• 有向无环图（DAG）
• DAG是一个没有循环的、又向的有向图
  • 它由有限个顶点和有向边组成，每条有向边都从一个顶点指向另一个顶点
  • 从任意一个顶点出发都不能通过这些有向边回到原来的顶点
  • 有向无环图就是一个从一个图中的任何一点出发，不管走过多少个分岔口，都没有回到原来这个点的可能性
• 条件
  • 每个顶点出现且只出现一次
  • 若存在一条从顶点 A 到顶点 B 的路径，那么在序列中顶点 A出现在顶点 B 的前面。

Storm的计算架构

Topology

• Storm 的拓扑是对实时计算应用逻辑的封装，它的作用与 MapReduce 的任务（Job）很相似，区别在于 MapReduce 的一个 Job 在得到结果之后总会结束，而拓扑会一直在集群中运行，直到你手动去终止它。
• 拓扑还可以理解成由一系列通过数据流（Stream Grouping）相互关联的 Spout 和 Bolt 组成的的拓扑结构。

Stream

• 数据流是Storm中最核心的抽象概念
• 一个数据流指的是在分布式环境中并行创建，处理的一组元组的无界序列
• 数据流可以由一种能够表述数据流中元域的模式来定义

Tuple

• Stream中最小数据组成单元
• 每个tuple可以包含多列，字段类型可以是integer, long, short, byte, string, double, float,boolean和byte array

Spout

• 拓补图的数据源，可以从其他存储对接数据源
• 读取外部的数据将其转换成元组进行传输

Bolt

• 用户处理数据，但是有可能数据需要金国多个bolt进行处理
• 通过数据过滤（filtering）、函数处理（functions）、聚合（aggregations）、联结（joins）、数据库交互等功能

StreamGroup

• 为拓扑中的每个 Bolt 的确定输入数据流是定义一个拓扑的重要环节。
• 数据流分组定义了在 Bolt 的不同任务（tasks）中划分数据流的方式。在 Storm 中有八种内置的数据流分组方式。

Reliablity

• 可靠性
• Storm 可以通过拓扑来确保每个发送的元组都能得到正确处理
• 通过跟踪由 Spout 发出的每个元组构成的元组树可以确定元组是否已经完成处理
• 每个拓扑都有一个“消息延时”参数，如果 Storm 在延时时间内没有检测到元组是否处理完成，就会将该元组标记为处理失败，并会在稍后重新发送该元组

Storm的通信机制

Worker进程间通信原理

• worker进程间消息传递机制
• worker进程
  • 为了管理流入和传出的消息，每个worker进程都有一个独立的接收线程和发送线程
  • 接收线程来负责将外部发送过来的消息移动到对应的executor线程的inconming-queue中
  • 发送线程负责从worker的transfer-queue中读取消息，并通过网络发送给其他的worker
• executor线程
  • 每个executor有独立的incoming-queue和outging-queue
  • Worker接收线程将收到的江西通过task编号传递给对应的executor的incoming-queues
  • executor有单独的线程分别来处理spout/bolt的业务逻辑，业务逻辑输出的中间数据会存放在outgoing-queue
  • 当executor的outgoing-queue中的tuple达到一定的阀值，executor的发送线程将批量获取outgoing-queue中的tuple,并发送到transfer-queue中
  • 每个worker进程控制一个或者多个executor线程，用户可在代码中进行配置。

Worker进程内通信原理

• Disruptor是一个Queue
  • Disruptor是实现了“队列”的功能，而且是一个有界队列(长度有限)。而队列的应用场景自然就是“生产者-消费者”模型
• Disruptor一种线程之间信息无锁的交换方式
• Disruptor主要特点
  • 1、 没有竞争=没有锁=非常快。
    2、 所有访问者都记录自己的序号的实现方式，允许多个生产者与多个消费者共享相同的数据结构。
• Disruptor 核心技术点
  • Disruptor可以看成一个事件监听或消息机制，在队列中一边生产者放入消息，另外一边消费者并行取出处理.
  • 底层是单个数据结构：一个ring buffer（环形数据缓冲区）

Storm的容错机制

集群节点宕机

• Nimbus宕机
• 单点故障
  • 从1.0.0版本以后，Storm的Nimbus是高可用的。
• 非Nimbus节点
  • 故障时，该节点上所有Task任务都会超时，Nimbus会将这些Task任务重新分配到其他服务器上运行

进程故障

• Worker
  • 每个Worker中包含数个Bolt（b ao t）任务。
  • Supervisor负责监控这些任务，当worker失败后会尝试在本机启动它
  • 如果启动过程一直失败，并且无法向Nimbus发送心跳，Nimbus回将该Worker重新分配到其他服务器上
• Supervisor
  • 无状态（所有状态信息都存放在zookeeper中来管理）
  • 快速失败（每当遇到任何情况，都会自动毁灭）
    • 快速失败
      • 在用迭代器遍历一个集合对象时，如果遍历过程中对集合对象的内容进行了修改，则会抛出Concurrent Modification Exception，java.util包下的集合类都是快速失败的，不能在多线程下发生并发修改
    • 安全失败
      • 采用安全失败机制的集合容器，在遍历时不是直接在集合内容上访问的而是先复制原有集合内容，在拷贝的集合上进行遍历java.util.concurrent包下的容器都是安全失败，可以在多线程下并发使用，并发修改。
  • Nimbus
    • 无状态（所有的状态信息都存放在Zookeeper中来管理）
    • 快速失败（每当遇到任何异常情况，都会自动毁灭）

任务级容错

• Bolt任务crash引起的消息未被应答。
  • 此时，acker中所有与此Bolt任务关联的消息都会因为超时而失败，对应的Spout的fail方法将
    被调用。
• acker任务失败。
  • 如果acker任务本身失败了，它在失败之前持有的所有消息都将超时而失败。Spout的fail方法
    将被调用。
• Spout任务失败。
  • 在这种情况下，与Spout任务对接的外部设备(如MQ)负责消息的完整性。

消息的完整性

• 消息的完整性定义
  • 每个从Spout（Storm中数据源点）发出的Tuple（Storm中最小的消息单元）可能会生成成
    千上万个新的Tuple
  • 形成一颗Tuple树，当整颗Tuple树的节点都被成功处理了，我们就说从Spout发出的Tuple被
    完全处理了。
• 消息完整性机制–Acker
  • acker的任务就是追踪从spout中流出来的每一个message id绑定的若干tuple的处理路径，
  • 如果在用户设置的最大超时时间内这些tuple没有被完全处理，那么acker就会告知spout该消息处理失败了
  • 相反则会告知spout该消息处理成功了。
• XOR异或
  • 异或的运算法则为：0异或0=0，1异或0=1，0异或1=1，1异或1=0（同为0，异为1）
  • A xor B…xor B xor A = 0，其中每一个操作数出现且仅出现两次
  • 验证方式：
    • spout或者bolt在处理完tuple后，都会告诉acker我已经处理完了该源tuple(如tupleId=1)，如果emit一个tuple的话，同时会告诉acker我发射了一个tuple(如tupleId=2)，如果在大量的高并发的消息的情况下，传统的在内存中跟踪执行情况的方式，内存的开销会非常大，甚至内存溢出
    • acker巧妙的利用了xor的机制，只需要维护一个msgId的标记位即可，处理方法是acker在初始的时候，对每个msgId初始化一个校验值ack-val(为0)，在处理完tuple和emittuple的时候，会先对这两个个值做xor操作，生成的中间值再和acker中的当前校验值ack-val做xor生成新的ack-val值，当所有的tuple都处理完成都得到确认，那么最后的ack-val自然就为0了