storm概念学习及流处理与批处理的区别

在过去10 年中,随着互联网应用的高速发展,企业积累的数据量越来越大,越来越多。随着Google MapReduce、Hadoop 等相关技术的出现,处理大规模数据变得简单起来,但是这些数据处理技术都不是实时的系统,它们的设计目标也不是实时计算。毕竟实时的计算系统和基于批处理模型的系统(如Hadoop)有着本质的区别。

但是随着大数据业务的快速增长,针对大规模数据处理的实时计算变成了一种业务上的需求,缺少“实时的Hadoop 系统”已经成为整个大数据生态系统中的一个巨大缺失。Storm 正是在这样的需求背景下出现的,Storm 很好地满足了这一需求。

在Storm 出现之前,对于需要实现计算的任务,开发者需要手动维护一个消息队列和消息处理者所组成的实时处理网络,消息处理者从消息队列中取出消息进行处理,然后更新数据库,发送消息给其他队列。所有这些操作都需要开发者自己实现。这种编程实现的模式存在以下缺陷。

集群环境配置下的Storm存在两类节点:主控节点和工作节点。此外,为了实现集群的状态维护和配置管理,还需要一类特殊的节点:协调节点。整体架构如下图:

一、组成原理:

1、主控节点,即运行nimbus守护进程的节点。 nimbus负责在集群分发的代码,将任务分配给其他机器,并负责故障监测。

2、工作节点,即运行supervisor守护进程的节点。

     supervisor监听分配所在机器,根据nimbus的委派,在必要时启动和关闭工作进程。(工作节点是实时数据处理作业运行的节点)

     其中,计算在节点上的物理单元是worker,也即工作进程;计算的逻辑单元是executor,也即计算线程。(有点像spark哦) 然而计算的作业逻辑单元是topology,也称拓扑;计算的任务逻辑单元是task(还是有点像spark哦).

     每个worker执行特定topology的executor子集,每个executor执行一个或多个task。

   一个topology主要有两类组件(component):spout和bolt.分别是流失数据在topology中的起始单元和处理单元。

3、协调节点,即运行Zookeeper服务端进程的节点。

     Zookeeper是一种分布式的状态协同服务,通过放松一致性的要求,为应用建立高层的协同原语(阻塞和更强一致性的要求),当前分布式系统中,广泛应用于状态监控和配置管理。

二、Storm主要的编程概念:spoutblottopology

1、spout  是流式处理的源头,是一个计算的起始单元,它封装数据源中的数据为storm可以识别的数据项。 spout可以从消息中间件中(如kafka、kestrel等)中读取数据产生流式元祖数据,也可以从其他接口如Twitter streaming API直接获取流式数据。

2、bolt 是处理过程单元,从输入流中获取一定数量的数据项处理后,将结果作为输出流发送。流式数据处理的业务逻辑,大部分是在bolt中实现的,如各类函数、过滤器、连接操作、聚集操作、数据库操作等。

3、topology是由spout和bolt为点组成的网络,网络中的边表示一个bolt订阅了某个或某个其他bolt或spout的输出流。topology可以是任意复杂多阶段流计算的网络,在Storm急群众提交后立即运行。

 storm拓扑topology:

三、流处理与批处理

     1、系统的输入包括两类数据:实时的流式数据静态的离线数据。其中,流式数据是前端设备实时发送的识别数据、GPS数据等,是通过消息中间件实现的事件触发,推送至系统的。离线数据是应用需要用到的基础数据(提前梳理好的)等关系数据库中的离线数据,是通过数据库读取接口获取而批量处理的系统。

     2、系统的输出也包括流式数据和离线数据。其中,流式数据是写入消息中间件的指定数据队列缓存,可以被异步推送至其他业务系统。离线数据是计算结果,直接通过接口写入业务系统的关系型数据库。

     3、业务的计算结果输出方式是通过两个条件决定的。一、结果产生的频率:若计算结果产生的频率可能会较高,则结果以流式数据的形式写入消息中间件。(比如要实时监控该客户所拥有的标签,也就是说要以极高的速度被返回,这类结果以流式数据形式被写入消息中间件。) 这是因为数据库的吞吐量很可能无法适应告诉数据的存取需求。 二、结果需要写入的数据库表规模:若需要插入结果的数据表已经很庞大,则结果以流式数据的形式写入消息中间件,待应用层程序实现相关队列数据的定期或定量的批量数据库转储。(比如宽表异常庞大,每次查询数据库就会有很高的延迟,那么就将结果信息暂时存入中间件层,晚些时候再定时或定量的进行批量数据库转储) 。这是因为大数据表的读取和写入操作对毫秒级别的相应时间仍是无能为力。 若以上两个条件均无要求,结果可以直接写入数据库的相应表中。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏华章科技

日处理20亿数据,实时用户行为服务系统架构实践

以猜你喜欢为例,猜你喜欢为应用内用户提供潜在选项,提高成交效率。旅行是一项综合性的需求,用户往往需要不止一个产品。作为一站式的旅游服务平台,跨业务线的推荐,特别...

7820
来自专栏架构之路

大数据时代的技术hive:hive介绍

  我最近研究了hive的相关技术,有点心得,这里和大家分享下。   首先我们要知道hive到底是做什么的。下面这几段文字很好的描述了hive的特性:   1....

34040
来自专栏MessageQueue

初探Kafka Streams

Kafka在0.10版本推出了Stream API,提供了对存储在Kafka内的数据进行流式处理和分析的能力。

16910
来自专栏北京马哥教育

Redis集群技术

1. Redis常见集群技术 长期以来,Redis本身仅支持单实例,内存一般最多10~20GB。这无法支撑大型线上业务系统的需求。而且也造成资源的利用率过低——...

42170
来自专栏数据之美

手把手教你 Spark 性能调优

0、背景 上周四接到反馈,集群部分 spark 任务执行很慢,且经常出错,参数改来改去怎么都无法优化其性能和解决频繁随机报错的问题。 看了下任务的历史运行情况,...

1.4K100
来自专栏Albert陈凯

一文读懂非关系型数据库(NoSQL)

一文读懂非关系型数据库(NoSQL) 本文共11000字****,阅读全文约需30分钟****。本文为大家解析非关系型数据库(NoSQL)。 前言 ---- ?...

70860
来自专栏大数据和云计算技术

大数据和云计算技术周报(第40期):NoSQL特辑

本期有 HBase、HBase+ES、StreamSets、explain、Cassandra、Redis。 希望大家会喜欢!

11720
来自专栏云加头条

CRS : 腾讯云 Redis 产品架构解析

Redis作为key-value数据库里的最热门的一员,在保持key-value数据库的简单快速的优点基础上,具有一些部分关系数据库的优点,例如数据结构丰富、操...

2.8K20
来自专栏大数据文摘

5大架构:细数数据平台的组成与扩展

27680
来自专栏Hadoop实操

0457-如何使用Cloudera Manager手动收集诊断包

如果您拥有Cloudera Enterprise许可证,那么我们就能借助于Cloudera Manager提供的收集集群诊断包功能,通过Cloudera的后台S...

16840

扫码关注云+社区

领取腾讯云代金券