33-Storm学习-史上最通俗易懂Storm教程：大白话介绍Storm

一、Storm到底是什么？

Apache Storm是一个分布式实时大数据处理系统。Storm设计用于在容错和水平可扩展方法中处理大量数据。

Storm 是一个分布式的，可靠的，容错的数据流处理系统。它会把工作任务委托给不同类型的组件，每个组件负责处理一项简单特定的任务。

相较于hadoop的优势 

相对于hadoop而言，strom的优势在于对于应对大数据两的实时数据处理上，因为hadoop在处理大数据过程中高延时的特点使得其面对实时数据缺乏足够的应对策略，目前strom已经被广泛的应用在诸如金融系统，实时推送系统，预警系统，网站统计等多个场景中，他可伸缩性高，不存在数据丢失，高容错性，高健壮性等特点都使得他在未来拥有更广阔的天地.

mysql，hadoop与storm

mysql：事务性系统，面临海量数据的尴尬
hadoop：离线批处理
storm：实时计算

二、storm的特点是什么？

（1）适用场景广泛：支撑各种实时类的项目场景：实时处理消息以及更新数据库，基于最基础的实时计算语义和API（实时数据处理领域）；对实时的数据流持续的进行查询或计算，同时将最新的计算结果持续的推送给客户端展示，同样基于最基础的实时计算语义和API（实时数据分析领域）；对耗时的查询进行并行化，基于DRPC，即分布式RPC调用，单表30天数据，并行化，每个进程查询一天数据，最后组装结果

storm做各种实时类的项目都ok

（2）高度的可伸缩性：如果要扩容，直接加机器，调整storm计算作业的并行度就可以了，storm会自动部署更多的进程和线程到其他的机器上去，无缝快速扩容扩容起来

（3）保证数据不丢失：storm的消息可靠机制开启后，可以保证一条数据都不丢。数据不丢失，也不重复计算

（4）超强的健壮性：storm集群非常容易管理，轮流重启节点不影响应用。从历史经验来看，storm比hadoop、spark等大数据类系统，健壮性多的多，因为元数据全部放zookeeper，不在内存中，随便挂都不要紧。特别的健壮，稳定性和可用性很高

（5）使用的便捷性：核心语义非常的简单，开发起来效率很高。用起来很简单，开发API还是很简单的。

（6）容错性好：在消息处理过程中出现异常， storm会进行重试

 

Storm的集群架构以及核心概念

1、Storm的集群架构

Nimbus，Supervisor，ZooKeeper，Worker，Executor，Task

 

• Nimbus：负责在集群里面发送代码，分配工作给机器，并且监控状态。全局只有一个。相当于master的角色。
• Supervisor：监听分配给它那台机器的工作，根据需要启动/关闭工作进程Worker。每一个要运行Storm的机器上都要部署一个，并且，按照机器的配置设定上面分配的槽位数。
• zookeeper：Storm重点依赖的外部资源。Nimbus和Supervisor甚至实际运行的Worker都是把心跳保存在Zookeeper上的。Nimbus也是根据Zookeerper上的心跳和任务运行状况，进行调度和任务分配的。两者之间的调度器。
• Worker：具体处理组建逻辑的进程
• Task：不再与物理进程对应，是处理任务的线程，

放一张Nimbus和Supervisior的关系图

 

2、Storm的核心概念

Topology，Spout，Bolt，Tuple，Stream

• Topology拓扑：务虚的一个概念
• Spout：数据源的一个代码组件，就是我们可以实现一个spout接口，写一个java类，在这个spout代码中，我们可以自己尝试去数据源获取数据，比如说从kafka中消费数据
• bolt：一个业务处理的代码组件，spout会将数据传送给bolt，各种bolt还可以串联成一个计算链条，java类实现了一个bolt接口

一堆spout+bolt，就会组成一个topology，就是一个拓扑，实时计算作业，spout+bolt，一个拓扑涵盖数据源获取/生产+数据处理的所有的代码逻辑，topology

• tuple：就是一条数据，每条数据都会被封装在tuple中，在多个spout和bolt之间传递
• stream：就是一个流，务虚的一个概念，抽象的概念，源源不断过来的tuple，就组成了一条数据流

数据处理的流程

Topology是一个完成的数据处理流程，在Nimbus提交jar，然后Nimbus分发到Supervisior中，Sport负责数据流的读入，是入口，然后Bolt是处理数据加工数据的节点，中间数据被封装在Tuple中，然后Bolt节点可以产生新的Tuple。总体流程图如下

 

Storm的并行度以及流分组

掌握最常见的storm开发范式，spout消费kafka，后面跟一堆bolt，bolt之间设定好流分组的策略

在bolt中填充各种代码逻辑

了解如何将storm拓扑打包后提交到storm集群上去运行

掌握如何能够通过storm ui去查看你的实时计算拓扑的运行现状

 

并行度(parallelism)概念

• 一个运行中的拓扑是由什么构成的：工作进程（worker processes），执行器（executors）和任务（tasks）
• 在 Worker 中运行的是拓扑的一个子集。一个 worker 进程是从属于某一个特定的拓扑的，在 worker 进程中会运行一个或者多个与拓扑中的组件相关联的 executor。一个运行中的拓扑就是由这些运行于 Storm集群中的很多机器上的进程组成的。
• 一个 executor 是由 worker 进程生成的一个线程。在 executor 中可能会有一个或者多个 task，这些 task 都是为同一个组件（spout 或者 bolt）服务的。
• task 是实际执行数据处理的最小工作单元（注意，task 并不是线程） —— 在你的代码中实现的每个 spout 或者 bolt 都会在集群中运行很多个 task。在拓扑的整个生命周期中每个组件的 task 数量都是保持不变的，不过每个组件的 executor数量却是有可能会随着时间变化。在默认情况下 task 的数量是和 executor 的数量一样的，也就是说，默认情况下 Storm会在每个线程上运行一个 task。

Storm的流分组策略

• Storm的分组策略对结果有着直接的影响，不同的分组的结果一定是不一样的。其次，不同的分组策略对资源的利用也是有着非常大的不同
• 拓扑定义的一部分就是为每个Bolt指定输入的数据流，而数据流分组则定义了在Bolt的task之间如何分配数据流。

八种流分组定义

Shuffle grouping:

• 随机分组：随机的将tuple分发给bolt的各个task，每个bolt实例接收到相同数量的tuple。

Fields grouping:

• 按字段分组：根据指定的字段的值进行分组，举个栗子，流按照“user-id”进行分组，那么具有相同的“user-id”的tuple会发到同一个task，而具有不同“user-id”值的tuple可能会发到不同的task上。这种情况常常用在单词计数，而实际情况是很少用到，因为如果某个字段的某个值太多，就会导致task不均衡的问题。

Partial Key grouping:

• 部分字段分组：流由分组中指定的字段分区，如“字段”分组，但是在两个下游Bolt之间进行负载平衡，当输入数据歪斜时，可以更好地利用资源。优点。有了这个分组就完全可以不用Fields grouping了

All grouping:

• 广播分组：将所有的tuple都复制之后再分发给Bolt所有的task，每一个订阅数据流的task都会接收到一份相同的完全的tuple的拷贝。

Global grouping:

• 全局分组：这种分组会将所有的tuple都发到一个taskid最小的task上。由于所有的tuple都发到唯一一个task上，势必在数据量大的时候会造成资源不够用的情况。

None grouping:

• 不分组：不指定分组就表示你不关心数据流如何分组。目前来说不分组和随机分组效果是一样的，但是最终，Storm可能会使用与其订阅的bolt或spout在相同进程的bolt来执行这些tuple

Direct grouping:

• 指向分组：这是一种特殊的分组策略。以这种方式分组的流意味着将由元组的生成者决定消费者的哪个task能接收该元组。指向分组只能在已经声明为指向数据流的数据流中声明。tuple的发射必须使用emitDirect种的一种方法。Bolt可以通过使用TopologyContext或通过在OutputCollector（返回元组发送到的taskID）中跟踪emit方法的输出来获取其消费者的taskID。

Local or shuffle grouping: 

• 本地或随机分组：和随机分组类似，但是如果目标Bolt在同一个工作进程中有一个或多个任务，那么元组将被随机分配到那些进程内task。简而言之就是如果发送者和接受者在同一个worker则会减少网络传输，从而提高整个拓扑的性能。有了此分组就完全可以不用shuffle grouping了。