02、Storm入门到精通storm3-0
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
ZooKeeper连接端口 storm使用的本地文件系统目录(必须存在并且storm进程可 读写) Storm集群运行模式([distributed|local]) Local模式下是否使用ZeroMQ作消息系统，如果设置为false 则使用java消息系统。默认为false ZooKeeper中Storm的根目录位置
• Storm 记录级容错原理
在storm的topology中有一个系统级组件，叫做acker。 这个acker的任务就是追踪从spout中流出来的每一个 message id绑定的若干tuple的处理路径，如果在用户设置 的最大超时时间内这些tuple没有被完全处理，那么acker 就会告知spout该消息处理失败 了，相反则会告知spout该 消息处理成功了。在刚才的描述中，我们提到了”记录 tuple的处理路径”，如果曾经尝试过这么做的同学可以仔 细地思考一下 这件事的复杂程度。但是storm中却是使用 了一种非常巧妙的方法做到了。在说明这个方法之前，我 们来复习一个数学定理。
Storm深入学习
• Storm 记录级容错原理
举个例子。在图中，在 spout由message 1绑定的tuple1 和tuple2经过了bolt1和bolt2的处理生成两个新的tuple，并 最终都流向了bolt3。当这个过程完成处理完时，称 message 1被完全处理了。
Storm深入学习
nimbus.supervisor.timeout supervisor的心跳超时时间,一旦超过nimbus会认为该supervisor已死并停 .secs 止为它分发新任务.
unch.secs
nimbus.reassign
task启动时的一个特殊超时设置.在启动后第一次心跳前会使用该值来临 时替代nimbus.task.timeout.secs.
Storm深入学习
• Storm 记录级容错原理
A xor A = 0. A xor B…xor B xor A = 0，其中每一个操作数出现且仅出现 两次。 storm中使用的巧妙方法就是基于这个定理。具体过 程是这样的：在spout中系统会为用户指定的message id生 成一个对应的64位整数，作为一个root id。root id会传递 给acker及后续的bolt作为该消息单元的唯一标识。同时无 论是spout还是bolt每次新生成一个tuple的时候，都会赋予 该 tuple一个64位的整数的id。Spout发射完某个message id 对应的源tuple之后，会告知acker自己发射的root id及生成 的那些源tuple的id。
Storm深入学习
Storm深入学习
• • • • • • • Storm 记录级容错原理 Storm 配置详解 Storm 批处理 Storm TOPN Storm 流程聚合 Storm DRPC Storm executor、worker、task之间的关系和调 优 • Storm异常解决
Storm深入学习
• Storm 记录级容错原理 首先来看一下什么叫做记录级容错？storm允许 用户在spout中发射一个新的源tuple时为其指定一个 message id, 这个message id可以是任意的object对象。 多个源tuple可以共用一个message id，表示这多个 源 tuple对用户来说是同一个消息单元。storm中记 录级容错的意思是说，storm会告知用户每一个消息 单元是否在指定时间内被完全处理了。那什么叫 做 完全处理呢，就是该message id绑定的源tuple及由 该源tuple后续生成的tuple经过了topology中每一个 应该到达的bolt的处理。
Storm深入学习
• Storm 记录级容错原理
Storm深入学习
• Storm 记录级容错原理
Storm深入学习
• Storm 记录级容错原理
Storm深入学习
• Storm 记录级容错原理
可能有些细心的同学会发现，容错过程存在一个可能 出错的地方，那就是，如果生成的tuple id并不是完全各异 的，acker可能会在消息单元完全处理完成之前就错误的计 算为0。这个错误在理论上的确是存在的，但是在实际中 其概率是极低极低的，完全可以忽略。
storm.zookeeper.session.timeout
storm.id
客户端连接ZooKeeper超时时间
运行中拓扑的id,由storm name和一个唯一随机数组成。
Байду номын сангаас
Storm深入学习
• Storm配置详解
nimbus.host nimbus.thrift.port nimbus.childopts nimbus.task.timeout.secs nimbus.monitor.freq.secs nimbus服务器地址 nimbus的thrift监听端口 通过storm-deploy项目部署时指定给nimbus进程的jvm选项 心跳超时时间，超时后nimbus会认为task死掉并重分配给另一个地址。 nimbus检查心跳和重分配任务的时间间隔.注意如果是机器宕掉nimbus 会立即接管并处理。
当发现task失败时nimbus是否重新分配执行。默认为真，不建议修改。
Storm深入学习
• Storm 记录级容错原理
而bolt呢，每次接受到一个输入tuple处理完之后，也会告 知acker自己处理的输入tuple的id及新生 成的那些tuple的id。 Acker只需要对这些id做一个简单的异或运算，就能判断出 该root id对应的消息单元是否处理完成了。下面通过一个 图示来说明这个过程。
Storm深入学习
• Storm配置详解
配置项 配置说明
storm.zookeeper.servers
storm.zookeeper.port storm.local.dir storm.cluster.mode storm.local.mode.zmq storm.zookeeper.root
ZooKeeper服务器列表
• Storm 记录级容错原理
在storm的topology中有一个系统级组件，叫做acker。 这个acker的任务就是追踪从spout中流出来的每一个 message id绑定的若干tuple的处理路径，如果在用户设置 的最大超时时间内这些tuple没有被完全处理，那么acker 就会告知spout该消息处理失败 了，相反则会告知spout该 消息处理成功了。在刚才的描述中，我们提到了”记录 tuple的处理路径”，如果曾经尝试过这么做的同学可以仔 细地思考一下 这件事的复杂程度。但是storm中却是使用 了一种非常巧妙的方法做到了。在说明这个方法之前，我 们来复习一个数学定理。
Storm深入学习
• Storm 记录级容错原理
举个例子。在图中，在 spout由message 1绑定的tuple1 和tuple2经过了bolt1和bolt2的处理生成两个新的tuple，并 最终都流向了bolt3。当这个过程完成处理完时，称 message 1被完全处理了。
Storm深入学习
nimbus.supervisor.timeout supervisor的心跳超时时间,一旦超过nimbus会认为该supervisor已死并停 .secs 止为它分发新任务.
unch.secs
nimbus.reassign
task启动时的一个特殊超时设置.在启动后第一次心跳前会使用该值来临 时替代nimbus.task.timeout.secs.
Storm深入学习
• Storm 记录级容错原理
A xor A = 0. A xor B…xor B xor A = 0，其中每一个操作数出现且仅出现 两次。 storm中使用的巧妙方法就是基于这个定理。具体过 程是这样的：在spout中系统会为用户指定的message id生 成一个对应的64位整数，作为一个root id。root id会传递 给acker及后续的bolt作为该消息单元的唯一标识。同时无 论是spout还是bolt每次新生成一个tuple的时候，都会赋予 该 tuple一个64位的整数的id。Spout发射完某个message id 对应的源tuple之后，会告知acker自己发射的root id及生成 的那些源tuple的id。
Storm深入学习
Storm深入学习
• • • • • • • Storm 记录级容错原理 Storm 配置详解 Storm 批处理 Storm TOPN Storm 流程聚合 Storm DRPC Storm executor、worker、task之间的关系和调 优 • Storm异常解决
Storm深入学习
• Storm 记录级容错原理 首先来看一下什么叫做记录级容错？storm允许 用户在spout中发射一个新的源tuple时为其指定一个 message id, 这个message id可以是任意的object对象。 多个源tuple可以共用一个message id，表示这多个 源 tuple对用户来说是同一个消息单元。storm中记 录级容错的意思是说，storm会告知用户每一个消息 单元是否在指定时间内被完全处理了。那什么叫 做 完全处理呢，就是该message id绑定的源tuple及由 该源tuple后续生成的tuple经过了topology中每一个 应该到达的bolt的处理。
Storm深入学习
• Storm 记录级容错原理
Storm深入学习
• Storm 记录级容错原理
Storm深入学习
• Storm 记录级容错原理
Storm深入学习
• Storm 记录级容错原理
可能有些细心的同学会发现，容错过程存在一个可能 出错的地方，那就是，如果生成的tuple id并不是完全各异 的，acker可能会在消息单元完全处理完成之前就错误的计 算为0。这个错误在理论上的确是存在的，但是在实际中 其概率是极低极低的，完全可以忽略。
storm.zookeeper.session.timeout
storm.id
客户端连接ZooKeeper超时时间
运行中拓扑的id,由storm name和一个唯一随机数组成。
Байду номын сангаас
Storm深入学习
• Storm配置详解
nimbus.host nimbus.thrift.port nimbus.childopts nimbus.task.timeout.secs nimbus.monitor.freq.secs nimbus服务器地址 nimbus的thrift监听端口 通过storm-deploy项目部署时指定给nimbus进程的jvm选项 心跳超时时间，超时后nimbus会认为task死掉并重分配给另一个地址。 nimbus检查心跳和重分配任务的时间间隔.注意如果是机器宕掉nimbus 会立即接管并处理。
当发现task失败时nimbus是否重新分配执行。默认为真，不建议修改。
Storm深入学习
• Storm 记录级容错原理
而bolt呢，每次接受到一个输入tuple处理完之后，也会告 知acker自己处理的输入tuple的id及新生 成的那些tuple的id。 Acker只需要对这些id做一个简单的异或运算，就能判断出 该root id对应的消息单元是否处理完成了。下面通过一个 图示来说明这个过程。
Storm深入学习
• Storm配置详解
配置项 配置说明
storm.zookeeper.servers
storm.zookeeper.port storm.local.dir storm.cluster.mode storm.local.mode.zmq storm.zookeeper.root
ZooKeeper服务器列表