2.4 Apache Storm
2.4.1 简介
Strom 原由 Twitter 开发,2011 年开源。Storm 基于开源 Apache Storm,是一个分布式、可靠、容错的实时计算系统。用于对大规模流式数据提供实时处理。Storm 有众多适用场景:实时分析、持续计算、分布式 ETL 等。Storm 有如下几个特点:
- 适用场景广泛
- 易扩展,可伸缩性高
- 保证无数据丢失
- 容错性好
- 易于构建和操控
- 多语言
Storm 作为计算平台,在业务层为用户提供了更为易用的业务实现方式:CQL(Continuous Query Language—持续查询语言)。CQL 具有以下几个特点:
- 使用简单:CQL 语法和标准 SQL 语法类似,只要具备 SQL 基础,通过简单地学习,即可快速地进行业务开发。
- 功能丰富:CQL 除了包含标准 SQL 的各类基本表达式等功能之外,还特别针对流处理场景增加了窗口、过滤、并发度设置等功能。
- 易于扩展:CQL 提供了拓展接口,以支持日益复杂的业务场景,用户可以自定义输入、输出、序列化、反序列化等功能来满足特定的业务场景
- 易于调试:CQL 提供了详细的异常码说明,降低了用户对各种错误的处理难度
Storm 是自由的开源软件,一个分布式的、容错的实时计算系 统。Storm 可以非常可靠的处理庞大的数据流,用于处理 Hadoop 的批量数据。Storm 很简单,支持许多种编程语言,使用起来非常有趣。Storm 由 Twitter 开源而来,其它知名的应用企业包括 Groupon、淘宝、支付宝、阿里巴巴、乐元素、Admaster 等等。
Storm 有许多应用领域:实时分析、在线机器学习、不停顿的计算、分布式 RPC(远过程调用协议,一种通过网络从远程计算机程序上请求服务)、 ETL(Extraction-Transformation-Loading 的缩写,即数据抽取、转换和加载)等等。Storm 的处理速度惊人:经测 试,每个节点每秒钟可以处理 100 万个数据元组。Storm 是可扩展、容错,很容易设置和操作。
在 Storm 中,先要设计一个用于实时计算的图状结构,我们称之为拓扑(topology)。这个拓扑将会被提交给集群,由集群中的主控节点 (master node)分发代码,将任务分配给工作节点(worker node)执行。一个拓扑中包括 spout 和 bolt 两种角色,其中 spout 发送消息,负责将数据流以 tuple 元组的形式发送出去;而 bolt 则负责 转换这些数据流,在 bolt 中可以完成计算、过滤等操作,bolt 自身也可以随机将数据发送给其他 bolt。由 spout 发射出的 tuple 是不可变数 组,对应着固定的键值对。
2.4.2 架构
图 11 Storm 架构图
Storm 框架主要由 7 部分组成
- Topology:一个实时应用的计算任务被打包作为 Topology 发布,这同 Hadoop 的 MapReduce 任务相似。
- Spout:Storm 中的消息源,用于为 Topology 生产消息(数据),一般是从外部数据源(如 Message Queue、RDBMS、NoSQL、Realtime Log)不间断地读取数据并发送给 Topology 消息(tuple 元组)。
- Bolt:Storm 中的消息处理者,用于为 Topology 进行消息的处理,Bolt 可以执行过滤,聚合, 查询数据库等操作,而且可以一级一级的进行处理。
- Stream:产生的数据(tuple 元组)。
- Stream grouping:在 Bolt 任务中定义的 Stream 进行区分。
- Task:每个 Spout 或者 Bolt 在集群执行许多任务。
- Worker:Topology 跨一个或多个 Worker 节点的进程执行。
Storm 服务由主备 Nimbus 进程、对应的 UI 进程和多个 Supervisor 进程组成,如 下图 所示。
表 1 结构图说明
名称 | 说明 |
---|---|
Nimbus | Storm 服务的控制中心节点,在 HA 模式下包含主用 Nimbus 和备用 Nimbus。 主用 Nimbus:负责接收客户端提交的任务,并在集群中分发任务给 Supervisor;同时监听状态等。 备用 Nimbus:当主用 Nimbus 故障时,备用 Nimbus 将取代主用 Nimbus 对外提供服务。 |
Supervisor | 负责监听并接受 Nimbus 分配的任务,根据需要启动和停止属于自己管理的 Worker 进程。Worker 进程是运行具体处理组件逻辑的进程。每个 Worker 是一个 JVM 进程。 |
UI | Storm 业务监控界面,用于查看运行的拓扑情况。 |
ZooKeeper | ZooKeeper 为 Storm 服务中各进程提供分布式协作服务。主备 Nimbus、Supervisor、Worker 将自己的信息注册到 ZooKeeper 中,Nimbus 据此感知各个角色的健康状态。 |
Logviewer | Storm 业务进程日志查看界面,用于查看 Worker 进程的日志信息。 |
原理
表格 5 基本概念
概念 | 说明 |
---|---|
Tuple | Storm 核心数据结构,是消息传递的基本单元,不可变 Key-Value 对,这些 Tuple 会以一种分布式的方式进行创建和处理。 |
Stream | Storm 的关键抽象,是一个无边界的连续 Tuple 序列。 |
Topology | 在 Storm 平台上运行的一个实时应用程序,由各个组件(Component)组成的一个 DAG(Directed Acyclic Graph)。一个 Topology 可以并发地运行在多台机器上,每台机器上可以运行该 DAG 中的一部分。Topology 与 Hadoop 中的 MapReduce Job 类似,不同的是,它是一个长驻程序,一旦开始就不会停止,除非人工中止。 |
Spout | Topology 中产生源数据的组件,是 Tuple 的来源,通常可以从外部数据源(如消息队列、数据库、文件系统、TCP 连接等)读取数据,然后转换为 Topology 内部的数据结构 Tuple,由下一级组件处理。 |
Bolt | Topology 中接受数据并执行具体处理逻辑(如过滤,统计、转换、合并、结果持久化等)的组件。 |
Worker | 是 Topology 运行态的物理进程。每个 Worker 是一个 JVM 进程,每个 Topology 可以由多个 Worker 并行执行,每个 Worker 运行 Topology 中的一个逻辑子集。 |
Task | Worker 中每一个 Spout/Bolt 的线程称为一个 Task。 |
Stream groupings | Storm 中的 Tuple 分发策略,即后一级 Bolt 以什么分发方式来接收数据。当前支持的策略有:Shuffle Grouping, Fields Grouping, All Grouping, Global Grouping, Non Grouping, Directed Grouping。 |
图 2 描述了一个由 Spout、Bolt 组成的 DAG,即 Topology。图中每个矩型框代表 Spout 或者 Bolt,矩型框内的节点表示各个并发的 Task,Task 之间的“边”代表数据流——Stream。
图 2 Topology 示意图
- 可靠性
Storm 提供三种级别的数据可靠性:
- 至多一次:处理的数据可能会丢失,但不会被重复处理。此情况下,系统吞吐量最大。
- 至少一次:保证数据传输可靠,但可能会被重复处理。此情况下,对在超时时间内没有获得成功处理响应的数据,会在 Spout 处进行重发,供后续 Bolt 再次处理,会对性能稍有影响。
- 精确一次:数据成功传递,不丢失,不冗余处理。此情况下,性能最差。
可靠性不同级别的选择,需要根据业务对可靠性的要求来选择、设计。例如对于一些对数据丢失不敏感的业务,可以在业务中不考虑数据丢失处理从而提高系统性能;而对于一些严格要求数据可靠性的业务,则需要使用精确一次的可靠性方案,以确保数据被处理且仅被处理一次。
- 容错
Storm 是一个容错系统,提供较高可用性。 表 3 从 Storm 的不同部件失效的情况角度解释其容错能力:
表 3 容错能力
失效场景 | 说明 |
---|---|
Nimbus 失效 | Nimbus 是无状态且快速失效的。当主 Nimbus 失效时,备 Nimbus 会接管,并对外提供服务。 |
Supervisor 失效 | Supervisor 是工作节点的后台守护进程,是一种快速失效机制,且是无状态的,并不影响正在该节点上运行的 Worker,但是会无法接收新的 Worker 分配。当 Supervisor 失效时,OMS 会侦测到,并及时重启该进程。 |
Worker 失效 | 该 Worker 所在节点上的 Supervisor 会在此节点上重新启动该 Worker。如果多次重启失败,则 Nimbus 会将该任务重新分配到其它节点。 |
节点失效 | 则该节点上的所有分配的任务会超时,而 Nimbus 会将这些 Worker 重新分配到其他节点。 |
开源特性
- 分布式实时计算框架
开源 Storm 集群中的每台机器上都可以运行多个工作进程,每个工作进程又可创建多个线程,每个线程可以执行多个任务,任务是并发进行数据处理。
- 高容错
如果在消息处理过程中有节点、进程等出现异常,提供重新部署该处理单元的能力。
- 可靠的消息保证
支持 At-Least Once、At-Most Once、Exactly Once 的数据处理模式。
- 安全机制
提供基于 Kerberos 的认证以及可插拔的授权机制,提供支持 SSL 的 Storm UI 以及 Log Viewer 界面,同时支持与大数据平台其他组件(如 ZooKeeper,HDFS 等)进行安全集成。
- 灵活的拓扑定义及部署
使用 Flux 框架定义及部署业务拓扑,在业务 DAG 发生变化时,只需对 YAML DSL(domain-specific language)定义进行修改,无需重新编译及打包业务代码。
- 与外部组件集成
支持与多种外部组件集成,包括:Kafka、HDFS、HBase、Redis 或 JDBC/RDBMS 等服务,便于实现涉及多种数据源的业务。
2.4.3 与组件的关系
Storm,提供实时的分布式计算框架,它可以从数据源(如 Kafka、TCP 连接等)中获得实时消息数据,在实时平台中完成高吞吐、低延迟的实时计算,并将结果输出到消息队列或者进行持久化。Storm 与其他组件的关系如 图 1 所示:
图 12 Storm 组件关系图
Storm 和 Streaming 的关系
Storm 和 Streaming 都使用的开源 Apache Storm 内核,不同的是,Storm 使用的内核版本是 1.0.2,Streaming 使用的是 0.10.0。Streaming 组件一般用来在升级场景 继承过度业务,比如之前版本已经部署 Streaming 并且有业务在运行的情况下,升级后仍然可以使用 Streaming。如果是新搭建的集群,则建议使 用 Storm。
Storm 1.0.2 新增特性说明:
- 分布式缓存 :提供命令行工具共享和更新拓扑的所需要的外部资源(配置),无需重新打包和部署拓扑。
- Native Streaming Window API :提供基于窗口的 API。
- 资源调度器 :新增基于资源的调度器插件,可以在拓扑定义时指定可使用的最大资源,并且通过配置的方式指定用户的资源配额,从而管理该用户名下的拓扑资源。
- State Management :提供带检查点机制的 Bolt 接口,当事件失败时,Storm 会自动管理 bolt 的状态并且执行恢复。
- 消息采样和调试 :在 Storm UI 界面可以开关拓扑或者组件级别的调试,将流消息按采样比率输出到指定日志中。
- Worker 动态分析 :在 Storm UI 界面可以收集 Wokrer 进程的 Jstack、Heap 日志,并且可以重启 Worker 进程。
- 拓扑日志级别动态调整 :提供命令行和 Storm UI 两种方式对运行中的拓扑日志进行动态修改。
- 性能提升 :与之前的版本相比,Storm 的性能得到了显著提升。虽然,拓扑的性能和用例场景及外服服务的依赖有很大的关系,但是对于大多数场景来说,性能可以提升 3 倍。
本章参考
- [1]. spark 的前世今生以及其组件介绍和应用 - Spark 高速集群计算平台 http://f.dataguru.cn/thread-621195-1-1.html
- [2]. Apache Storm 的历史及经验教训 https://www.oschina.net/translate/history-of-apache-storm-and-lessons-learned?lang=chs&page=2#
- [3]. storm 发展历史 https://blog.csdn.net/chengqiuming/article/details/78984286
- [4]. 新一代大数据处理引擎 Apache Flink https://www.ibm.com/developerworks/cn/opensource/os-cn-apache-flink/index.html
- [5]. 阿里云高级技术专家张毅萍:我眼中的边缘计算 https://blog.csdn.net/weixin_43970890/article/details/90715830
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论