龙空技术网

流计算框架Apache Storm核心概念、架构设计

软件架构 855

前言:

此刻我们对“apache分布式框架”可能比较关注,看官们都想要了解一些“apache分布式框架”的相关文章。那么小编在网摘上搜集了一些关于“apache分布式框架””的相关知识,希望朋友们能喜欢,兄弟们一起来了解一下吧!

一、Apache Storm 是什么?

Apache Storm 是Twitter免费、开源的分布式实时计算系统,擅长处理海量数据,适用于数据实时处理而非批处理。

MapReduce框架主要解决的是静态数据的批量处理,即MapReduce 框架处理的是已存储到位的数据;但是流计算系统在启动是,一般数据并没有完全到位,而是源源不断地流入。

批处理系统一般重视数据处理的吞吐量;流处理系统则更加关注数据处理的延时,希望流入的数据越快处理越好;

开发人员可以基于开源流处理框架Storm,快速搭建一套健壮的、易用的实时流处理系统。

二、Apache Storm核心概念

要了解Storm,首先要了解Storm的设计思想和核心概念。

Nimbus:Storm集群主节点,负责资源分配和任务调度。我们提交任务和停止任务都是在Nimbus上操作的。一个Storm集群只有一个Nimbus节点。Supervisor:Storm集群工作节点,接受Nimbus分配任务,管理所有Worker。Worker:工作进程,每个工作进程中都有多个Task。Task:任务,每个Spout和Bolt都是一个任务,每个任务都是一个线程。Topology:计算拓扑,包含了应用程序的逻辑。Stream:消息流,关键抽象,是没有边界的Tuple序列。Spout:消息流的源头,Topology的消息生产者。Bolt:消息处理单元,可以过滤、聚合、查询数据库。Stream grouping:消息分发策略,一共6种,定义每个Bolt接受何种输入。Reliability:可靠性,Storm保证每个Tuple都会被处理。

Spout、Stream、Tuple 三者之间的关系

Storm Topology

Spout、Bolt、Tuple 三者之间的关系

Stream Grouping - 消息分发策略,用来告知Topology 如何在2个组件之间(如Spout和Bolt之间,或者不同的Bolt之间)进行Tuple的传送,

1. Shuffle Grouping :随机分组,尽量均匀分布到下游Bolt中。

将流分组定义为混排。这种混排分组意味着来自Spout的输入将混排,或随机分发给此Bolt中的任务。shuffle grouping对各个task的tuple分配的比较均匀。

2. Fields Grouping :按字段分组,按数据中field值进行分组;相同field值的Tuple被发送到相同的Task。

这种grouping机制保证相同field值的tuple会去同一个task,这对于WordCount来说非常关键,如果同一个单词不去同一个task,那么统计出来的单词次数就不对了。如果按照user-id分组,则tuple中有相同user-id的将分发给同一个task。

3. All grouping :广播分发。

广播发送, 对于每一个tuple将会分发到每一个bolt中处理。

4. Global grouping :全局分组,tuple被分配到一个Bolt中的一个Task,实现事务性的Topology。

Stream中的所有的tuple都会发送给同一个bolt任务处理,所有的tuple将会发送给拥有最小task_id的bolt任务处理。

5. None grouping :不分组。

不关注并行处理负载均衡策略时使用该方式,目前等同于shuffle grouping,另外storm将会把bolt任务和他的上游提供数据的任务安排在同一个线程下。

6. Direct grouping :直接分组,或者指定分组。

由tuple的发送单元直接决定tuple将发射给那个bolt,一般情况下是由接收tuple的bolt决定接收哪个bolt 发送的Tuple。这是一种比较特别的分组方法,用这种分组意味着消息的发送者指定由消息接收者的哪个task处理这个消息。 只有被声明为Direct Stream的消息流可以声明这种分组方法。而且这种消息tuple必须使用emitDirect方法来发送。消息处理者可以通过TopologyContext来获取处理它的消息的taskid (OutputCollector.emit方法也会返回taskid)。

三、Apache Storm 架构设计

Storm运行方式和Hadoop有点类似:

在Hadoop上运行的是MapReduce作业;在Storm上运行的是Topology;

一个MapReduce作业最终会完成计算并结束运行,而一个Topology将持续处理消息,直到人为终止。

Storm集群采用Master-Worker的节点方式,其中Master节点运行名为:Nimbus的后台程序(类似Hadoop中的JobTracker),负责在集群范围内分发代码、为Worker分配任务和监测故障。

而每个Worker节点运行名为:Supervisor的后台程序,负责监听分配给它所在机器的工作,即根据Nimbus分配的任务来决定启动或停止Worker进程。

Storm 集群架构设计如下图所示。

Storm 采用Zookeeper来作为分布式协调组件,负责Nimbus和多个Supervisor之间的所有协调工作。

Nimbus后台进程和Supervisor后台进程都是快速失败(Fail-fast)和无状态(Stateless)的,Master节点并没有直接和Worker节点通信,而是借助Zookeeper将状态信息存放在Zookeeper中或本地磁盘中,以便节点故障时进行快速恢复。

Storm的工作流程如下图所示。

(1)客户端提交Topology到Storm集群(Nimbus);

(2)Nimbus将分配给Supervisor的任务写入Zookeeper;

(3)Supervisor从Zookeeper中获取分配的任务(Task),并启动Worker进程;

(4)Worker进程执行具体的任务;

四、Storm和Spark Streaming比较

Storm和Spark Streaming的最大区别在于:

Storm可以实现毫秒级响应;Spark Streaming无法实现毫秒级的流计算;

Spark Streaming无法实现毫秒级的流计算,是因为其将流数据按批处理窗口大小(通常在0.5-2s之间),分解为一系列批处理作业,在这个过程中会产生多个Spark作业,且每一段数据的处理都会经过Spark DAG图分解、任务调度过程,因此无法实现毫秒级响应。

Storm出来的单位是Tuple,只需要极小的延迟。

标签: #apache分布式框架