storm怎么保证数据不重不漏不storm 丢失数据

来源：蜘蛛抓取(WebSpider) 时间：2016-09-03 07:01 标签： 暗黑2storm.dll丢失
简单明了，Storm让大数据分析变得轻松加愉快--任务易storm为什么总是和消息队列一起用呢？storm的一个 spout读取数据库时，如果spout是多个线程的话，那么 线程并发读取数据，数据都是一样的。应该怎么处理，让spout是单线程的吗？
谢邀storm的解决问题的scope主要在于流计算，说流计算之前我们先简单的说下一般数据处理系统的过程。一般数据处理简单说要有几个环节：数据采集，数据计算，结果输出。题主的问题主要是在数据采集和计算之间的对接。一般来说计算系统（storm）不会自己产生业务数据，业务数据一般来自页面的埋点，或者对数据库log的解析，对于storm来说采集系统是个外部系统。 采集系统是数据的生产者，流计算（storm）是数据的消费者。二者的速度并不是时时刻刻匹配的，中间就需要需要一个缓冲，这个模型下消息队列在适合不过了。当然为什么一般用kafka，这个超出了这个问题，我们暂不讨论。如果题主要处理的数据不是实时产生的而是静态数据那就没必要使用消息队列了，当然也没必要使用storm，使用hadoop MR更合适。关于spout会不会重复读取数据的问题，简单来说消息队列中数据会分partition支持多并发。
题主可以看看kafka的文档，一般消息队列，对一份数据（一个topic，对应离线系统的表）会分不同的parition，不同的spout并发可以读取不同的parition，当然一个并发可以读取多个parition，但是多个并发读取一个parition会引起混乱这就是题主的问题。也就是实际应用中一个parition只会有一个并发读取。
Q1：storm为什么总是和消息队列一起用呢？&br&A：消息队列提供了这样一些功能，对于流式计算来说都是很有价值的：&br&1）可靠缓存。诚如楼上@杨晓青 所言，流式计算所处理的数据一般来源于其他正在执行中的应用，而数据产生速度与storm应用数据消费速度并不一定是匹配的，况且应用的使用在不同的时间点上压力是波动的，所以也有可能出现数据产生速度大于消费速度的情景。此时消息队列提供一个可靠的缓存，可以防止数据丢失，也避免了数据堆积在storm端的内存中。&br&2）流式模型。storm应用模式中，数据以流的方式在不同的逻辑、物理节点上流转，消息队列和storm这类流式计算进行搭配是极为符合的。在流式模型中，与离线模型不同的是对实时性有所要求，而消息队列的性能及producer/consumer模型也完全符合这种模式。&br&3）消息总线。很多时候在整个大的系统中我们把“事件”作为业务的驱动，而大系统中通常存在大量模块分布在不同设备和环境中，两两连接会形成一张巨大且复杂的网，这是不优雅且没必要的。而消息队列可以以一种总线的方式出现，负责消息的传递和分发，直接减少了模块间的耦合程度。在这样一种背景下，storm应用作为系统的数据处理模块，对接消息队列也是很显而易见的。&br&&br&Q2：storm对接数据库时如何避免重复消费？&br&A：首先，当然不会是单线程，这会使spout本身成为一个性能瓶颈，并且存在单点问题。如果你所说的数据库是Hbase这样的非关系型数据库，那么Hbase有分区，根据不同spout task id每个spout task负责不同的分区即可避免消息重复；如果是关系型数据库，可以根据不同的spout task id确定select 结果的范围，每个task负责不同的数据范围即可避免消息重复。
Q1：storm为什么总是和消息队列一起用呢？ A：消息队列提供了这样一些功能，对于流式计算来说都是很有价值的： 1）可靠缓存。诚如楼上@杨晓青 所言，流式计算所处理的数据一般来源于其他正在执行中的应用，而数据产生速度与storm应用数据消费速度并不一定是…
谢邀。&br&storm总是和消息队列一起用，但是并不是说是必须这样用，只不过是流处理作为一个长期存在的任务，需要从某一个地方源源不断的，能够很快速的获取数据，正因为有这样的业务需求，队列才成为了一个最常用，也是最简单的数据推送客户端。&br&&br&如果spout是多线程运行，必然会有多个客户端从消息队列中读取数据，一般消息队列都会保证多个客户端同事读取不读取重复数据且不会有数据丢失，这个稍微了解下队列机制就可以明白。
谢邀。 storm总是和消息队列一起用，但是并不是说是必须这样用，只不过是流处理作为一个长期存在的任务，需要从某一个地方源源不断的，能够很快速的获取数据，正因为有这样的业务需求，队列才成为了一个最常用，也是最简单的数据推送客户端。 如果spout是多…
已有帐号？
无法登录？
社交帐号登录
分布式计算/数据架构初学storm，业务场景是实时的对用户的某个行为次数进行统计，超过某个值就发出消息提醒。我现在不明白的是，比如我在bolt中解析出user_id=5的这个行为，如何将它与原来的数据进行累加呢？原先所有用户的行为数据统计肯定是存在一个地方，是通过数据库吗？如果是存在数据库或者是某个地方，这种分布式的处理，如何避免更新和查询时的冲突呢？
不请自答，既然答了就好好说说：首先，对于storm来说，最佳的实践是尽可能地保证每个任务都是“无状态”的，那么什么是无状态？简单来说就是任务内部不保存“本地数据”。这样做的好处最大的一点就是可以快速恢复并且降低数据丢失风险。由于storm应用是7*24运行在线上的，所以设计时必须假设异常是会经常发生的，那么当异常发生时，缓存在任务本地缓存中的数据就会丢失。那么假设数据存储在本地任务以外的存储容器里，且这个容器已经做了容灾相关的工作，那么当异常发生时只需要简单地将任务重启即可。那么和这个问题有什么关系呢？题主的问题需要对一个id的出现次数进行统计，如果超过阈值就报警，对于这个业务来说，就不单纯的是数据加工的问题，还需要存储。有三种方案可以选，一种是spout反序列化之后将数据以id为key进行fieldGrouping，这样保证id相同的消息都会被发往同一个bolt任务进行处理，在bolt任务本地缓存中维护一个map进行收集信息。优点是实现方便，能支持的QPS非常高，性能好；缺点是假设异常发生那么所有数据全部完蛋，而且很可能数据在缓存中无限积累导致OOM；第二种是在第一种的基础上做副本，也就是说对于同一条消息会被统计两次做主从备份，这种方案可以解决单点问题，但是资源利用率只有50%并且还是可能OOM；第三种方案就是接外部内存存储容器，例如redis，这种方案下spout到bolt只需要shuffle即可，每次来消息都在对应id下的计数器累加，如果超过阈值则发送消息并且删除，这种方案的好处在于实现了任务的无状态，坏处在于需要维护一套redis，并且由于存储时存在网络传输，所以最高性能远不如前两种。具体就看需求啦~
“累加”操作的最后一步，肯定要在一个节点完成的，不存在并发问题。
“累加”操作的最后一步，肯定要在一个节点完成的，不存在并发问题。
已有帐号？
无法登录？
社交帐号登录
程序员/懒鬼/不工作就很呆storm笔记_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
上传于||文档简介
&&自​己​组​织​的​学​习​笔​记​,​给​大​家​分​享​,​一​起​学​习​。
阅读已结束，如果下载本文需要使用2下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩20页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢

我要回帖

更多关于 暗黑2storm.dll丢失 的文章

 

随机推荐