大白话strom——问题收集（持续更新ing）

本文导读： 一、基于storm的应用 二、storm的单点故障解决 三、strom与算法的结合学习
四、杂记——常见问题的解答
五、http://www.blogchong.com/catalog.asp?tags=问题整理(storm)

---

 Storm存在的一些问题：（V 0.7.4以前）

一、编程门槛对普通用户较高 二、框架无持久化存储 三、框架不提供消息接入模块 —— kafka 四、storm ui 功能简单 五、跨topology的boit复用 六、nimbus单点故障
七、topology不支持动态部署

---

 storm业务需求：

1、条件过滤
    这是storm最基本的处理方式，对符合条件的数据进行实时过滤，将符合条件的数据保存下来，这种实时查询的业务需求在实际应用中很常见。
2、中间件计算
    咱们须要改变数据中某一个字段（例如是数值），咱们须要利用一个中间值通过计算（值比较、求和、求平均等）后改变该值，而后将数据从新输出。
3、求TopN
    相信你们对TopN类的业务需求也是比较熟悉的，在规定的时间窗口内，统计数据出现的TopN，该类处理在购物及电商业务需求中，比较常见。
4、分布式RPC
    storm有对RPC进行专门的设计，分布式RPC用于对storm上大量的函数调用进行并行计算，最后将结果返回给客户端。
5、推荐系统
    在实时处理时从mysql及hadoop中获取数据库中的信息，例如在电影推荐系统中，传入数据为用户当前点播电影信息，从后数据库中获取的是该用户以前的一些点播电影信息统计。
6、批处理
    所谓批处理就是数据积攒到必定触发条件 ，就批量输出，所谓的触发条件相似事件窗口到了，统计数量够了及检测到某种数据传入等等。
7、热度统计
    热度统计实现依赖于TimeCacheMap数据结构，该结构可以在内存中保持近期活跃的对象。咱们可使用它来实现例如论坛中的热帖排行统计等。

---

一、基于storm的应用系统：

（1）基于storm的网络爬虫系统的设计与实现：

大致框架：

　　众所周知，爬虫系统里几个必不可少的模块，像下载、解析、回写待爬资源、存储等，本质上他们像是一个责任链，但后一个module又基于前一个module，因此能够理解为一种流处理模型，从咱们拿到待爬URL一直处处理完毕存储数据，这是一个完整的过程。如您看到的这张图，若是咱们实现了storm化，那么基于storm强大的功能，咱们的爬虫能够完美运行在storm集群上，而且每类处理器咱们均可以很是灵活的分配其线程数，耗时的处理咱们多开几个线程，能够实现资源合理利用，固然既然是集群，你的某个任务具体运行在哪里，storm已经帮您分配好了，而且帮咱们实现了节点失效等处理。

　　最后若是bolt间传输的消息量比较大，有可能网络是个瓶颈。

 

其余应用：——基于storm的实时交通情况的设计与分析

1. 基于Storm实时路况分析和实时路径推荐系统
2. 用storm来监测车辆速度是否超过80 km/h
3. 公共交通出行服务大数据平台设计方案
4. 基于Storm云平台的地图道路匹配算法研究

............ 

 

 

---

二、storm单点故障问题：

（1）采用master组解决单点故障

思路：

zookeeper解决方案仍是至关复杂的，最近想到使用master组来解决这一问题，一个系统只有一个master组，它由若干个节点组成，好处：
一、结构简单，容易理解和实现
二、master组中的一个节点无论理集群内全部元数据，而只分担其中一部分，这样系统的扩展能力更强，不会受限于元数据
三、master组中的节点互备，能够解决单点故障问题
四、为性能而优化，专一于解决小文件性能问题，目标是达到实时检索

讨论：P2P解决方案

问：master组的实现，hadoop的热备份等都比较困难？

答：master数据备份能够直接采用多写方式，只有一个异常的master恢复时，才须要同步。

问：zookeeper是仅仅适用于hbase这种master slave模式仍是也适应于multi master？

答：ZooKeeper使用没有限制的，好比它的分布式锁能力和配置能力，有普遍的应用。关于Master组腾讯的XFS就采用了，不过仍然有个单点的顶层Master，采用了ZooKeeper作主备切换。顶层的单点Master，一般有两个备，在数据未同步时，叫Newbie（学习者），只有数据一致后才叫Standby，数据的一致是经过两阶段来保证的。

 

----讨论-----后续见：storm源码之一个class解决nimbus单点问题【转】

--单点问题能够参考hdfs的实现~

--hdfs的namenode也是单节点，secondnode也只是为合并操做日志以缩短namenode的启动时间而设。目前hadoop的namenode单点问题也是下一代hadoop要解决的重要问题。

--那是2.0以前的版本，如今两个namenode之间采用nfs共享元数据，经过zookeeper选举一个做为当前active，另外一个做为standby，当active挂了以后，可以在短期内切换到standby节点，实现高可用~

--nimbus节点利用nfs共享存储也是一种解决方案。能够经过将Froastman实现的storage.clj做以下修改：

(^boolean isSupportDistributed [this]
true))))

　　Nathanmarz所以在0.8.2版本的基础上，新开了storm-0.8.2-ha分支，专门用来解决nimbus单点问题，并将Frostman已完成的nimbus-storage代码合并到该分支。

　　Rostman在nimbus-storage基础上继续增长了nimbus多节点选举机制，(目前还没有被Nathanmarz合并入storm-ha分支)。

　　nimbus单点问题的解决思路

　　一、Frostman的工做已为完全解决nimbus单点问题奠基了重要基础：

• • nimbus ip地址动态获取
  • topology代码存储方案可定制
  • nimbus多节点选举，宕机自动切换
  • nimbus leader状态ui展现

　　在Frostman工做的基础上继续深刻，将极大减小工做量。
　　二、Frostman并未解决topology代码如何在多个nimbus节点或集群全部节点间共享的问题。Nathamarz的理想规划是：实现storm集群中全部nimbus、supervisor机器之间经过P2P协议共享topology代码，但目前限于BitTorrent未完成的工做，目前暂停了nimbus-ha分支的开发。
　　三、最终选定的解决方案：实现定制的nimbus-storage插件NimbusCloudStorage，使得全部nimbus节点在启动后均从leader 轮询下载本地不存在的topology代码。依次知足supervisor在nimbus节点切换后下载代码的需求。

 

 

---

三、Storm与算法的结合： 

 　　...........

　　基于storm的聚类算法的分析与实现，基于storm的关联规则的分析与实现，storm平台一致性哈希算法的分析与研究等等...

 

 

---

四、杂记：

　　　　——storm常见问题解答

转载于http://blog.csdn.net/hguisu/article/details/8454368#t3 （20121231）

1、我有一个数据文件，或者我有一个系统里面有数据，怎么导入storm作计算？

　　你须要实现一个Spout，Spout负责将数据emit到storm系统里，交给bolts计算。怎么实现spout能够参考官方的kestrel spout实现：
https://github.com/nathanmarz/storm-kestrel

　　若是你的数据源不支持事务性消费，那么就没法获得storm提供的可靠处理的保证，也不必实现ISpout接口中的ack和fail方法。

2、Storm为了保证tuple的可靠处理，须要保存tuple信息，这会不会致使内存OOM？

　　Storm为了保证tuple的可靠处理，acker会保存该节点建立的tuple id的xor值，这称为ack value，那么每ack一次，就将tuple id和ack value作异或(xor)。当全部产生的tuple都被ack的时候， ack value必定为0。这是个很简单的策略，对于每个tuple也只要占用约20个字节的内存。对于100万tuple，也才20M左右。关于可靠处理看这个：
https://github.com/nathanmarz/storm/wiki/Guaranteeing-message-processing

3、Storm计算后的结果保存在哪里？能够保存在外部存储吗？

　　Storm不处理计算结果的保存，这是应用代码须要负责的事情，若是数据不大，你能够简单地保存在内存里，也能够每次都更新数据库，也能够采用NoSQL存储。storm并无像s4那样提供一个Persist API，根据时间或者容量来作存储输出。这部分事情彻底交给用户。

　　数据存储以后的展示，也是你须要本身处理的，storm UI只提供对topology的监控和统计。

4、Storm怎么处理重复的tuple？

　　由于Storm要保证tuple的可靠处理，当tuple处理失败或者超时的时候，spout会fail并从新发送该tuple，那么就会有tuple重复计算的问题。这个问题是很难解决的，storm也没有提供机制帮助你解决。一些可行的策略：
　　（1）不处理，这也算是种策略。由于实时计算一般并不要求很高的精确度，后续的批处理计算会更正实时计算的偏差。
　　（2）使用第三方集中存储来过滤，好比利用mysql,memcached或者redis根据逻辑主键来去重。
　　（3）使用bloom filter作过滤，简单高效。

5、Storm的动态增删节点

　　我在storm和s4里比较里谈到的动态增删节点，是指storm能够动态地添加和减小supervisor节点。对于减小节点来讲，被移除的supervisor上的worker会被nimbus从新负载均衡到其余supervisor节点上。在storm 0.6.1之前的版本，增长supervisor节点不会影响现有的topology，也就是现有的topology不会从新负载均衡到新的节点上，在扩展集群的时候很不方便，须要从新提交topology。所以我在storm的邮件列表里提了这个问题，storm的开发者nathanmarz建立了一个issue 54并在0.6.1提供了rebalance命令来让正在运行的topology从新负载均衡，具体见：
https://github.com/nathanmarz/storm/issues/54
　　和0.6.1的变动：
http://groups.google.com/group/storm-user/browse_thread/thread/24a8fce0b2e53246

　　storm并不提供机制来动态调整worker和task数目。

6、Storm UI里spout统计的complete latency的具体含义是什么？为何emit的数目会是acked的两倍？

　　这个事实上是storm邮件列表里的一个问题。Storm做者marz的解答：

　　The complete latency is the time from the spout emitting a tuple to that
tuple being acked on the spout. So it tracks the time for the whole tuple
tree to be processed.

　　If you dive into the spout component in the UI, you'll see that a lot of
the emitted/transferred is on the __ack* stream. This is the spout
communicating with the ackers which take care of tracking the tuple trees. 

　　简单地说，complete latency表示了tuple从emit到被acked通过的时间，能够认为是tuple以及该tuple的后续子孙（造成一棵树）整个处理时间。其次spout的emit和transfered还统计了spout和acker之间内部的通讯信息，好比对于可靠处理的spout来讲，会在emit的时候同时发送一个_ack_init给acker，记录tuple id到task id的映射，以便ack的时候能找到正确的acker task。

 

7、strom不能实现不一样topology之间stream的共享

　　Storm中Stream的概念是Topology内惟一的，只能在Topology内按照“发布-订阅”方式在不一样的计算组件（Spout和Bolt）之间进行数据的流动，而Stream在Topology之间是没法流动的。

　　对于不一样topology前半部分共用Spouts和Bolts不能直接复用，解放方案有如下三种：

　　（1）kill原topology，共用前半部分的Spouts和Bolts，在分支Bolt处分别处理，从新打包造成新的topology并提交；

　　（2）从相同的外部数据源单独读取数据，设计与前一个topology相同的新topology处理后面的新任务；

　　（3）经过Kafka消息中间件实现不一样topology的Spout共享数据源，从新部署运行新的topology便可。

参考连接：Storm数据流模型的分析及讨论

 

 

---

 参考连接：

大白话storm——几点问题