返回介绍

2.4 Apache Storm

发布于 2024-09-23 22:27:22 字数 9333 浏览 0 评论 0 收藏 0

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 是可扩展、容错,很容易设置和操作。

image-20191204221112271

在 Storm 中,先要设计一个用于实时计算的图状结构,我们称之为拓扑(topology)。这个拓扑将会被提交给集群,由集群中的主控节点 (master node)分发代码,将任务分配给工作节点(worker node)执行。一个拓扑中包括 spout 和 bolt 两种角色,其中 spout 发送消息,负责将数据流以 tuple 元组的形式发送出去;而 bolt 则负责 转换这些数据流,在 bolt 中可以完成计算、过滤等操作,bolt 自身也可以随机将数据发送给其他 bolt。由 spout 发射出的 tuple 是不可变数 组,对应着固定的键值对。

2.4.2 架构

image-20191204221045108

图 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 进程组成,如 下图 所示。

image-20191204221130565

表 1 结构图说明

名称说明
NimbusStorm 服务的控制中心节点,在 HA 模式下包含主用 Nimbus 和备用 Nimbus。 主用 Nimbus:负责接收客户端提交的任务,并在集群中分发任务给 Supervisor;同时监听状态等。 备用 Nimbus:当主用 Nimbus 故障时,备用 Nimbus 将取代主用 Nimbus 对外提供服务。
Supervisor负责监听并接受 Nimbus 分配的任务,根据需要启动和停止属于自己管理的 Worker 进程。Worker 进程是运行具体处理组件逻辑的进程。每个 Worker 是一个 JVM 进程。
UIStorm 业务监控界面,用于查看运行的拓扑情况。
ZooKeeperZooKeeper 为 Storm 服务中各进程提供分布式协作服务。主备 Nimbus、Supervisor、Worker 将自己的信息注册到 ZooKeeper 中,Nimbus 据此感知各个角色的健康状态。
LogviewerStorm 业务进程日志查看界面,用于查看 Worker 进程的日志信息。

原理

表格 5 基本概念

概念说明
TupleStorm 核心数据结构,是消息传递的基本单元,不可变 Key-Value 对,这些 Tuple 会以一种分布式的方式进行创建和处理。
StreamStorm 的关键抽象,是一个无边界的连续 Tuple 序列。
Topology在 Storm 平台上运行的一个实时应用程序,由各个组件(Component)组成的一个 DAG(Directed Acyclic Graph)。一个 Topology 可以并发地运行在多台机器上,每台机器上可以运行该 DAG 中的一部分。Topology 与 Hadoop 中的 MapReduce Job 类似,不同的是,它是一个长驻程序,一旦开始就不会停止,除非人工中止。
SpoutTopology 中产生源数据的组件,是 Tuple 的来源,通常可以从外部数据源(如消息队列、数据库、文件系统、TCP 连接等)读取数据,然后转换为 Topology 内部的数据结构 Tuple,由下一级组件处理。
BoltTopology 中接受数据并执行具体处理逻辑(如过滤,统计、转换、合并、结果持久化等)的组件。
Worker是 Topology 运行态的物理进程。每个 Worker 是一个 JVM 进程,每个 Topology 可以由多个 Worker 并行执行,每个 Worker 运行 Topology 中的一个逻辑子集。
TaskWorker 中每一个 Spout/Bolt 的线程称为一个 Task。
Stream groupingsStorm 中的 Tuple 分发策略,即后一级 Bolt 以什么分发方式来接收数据。当前支持的策略有:Shuffle Grouping, Fields Grouping, All Grouping, Global Grouping, Non Grouping, Directed Grouping。

图 2 描述了一个由 Spout、Bolt 组成的 DAG,即 Topology。图中每个矩型框代表 Spout 或者 Bolt,矩型框内的节点表示各个并发的 Task,Task 之间的“边”代表数据流——Stream。

image-20191204221224165

图 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 所示:

image-20191204221313946

图 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 倍。

本章参考

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文