标签 ‘ Storm

Apache Storm 官方文档 —— 在生产环境中运行拓扑

原文链接    译者:魏勇

在生产环境集群中运行拓扑的方式与本地模式非常相似,主要包括以下几个步骤:

阅读全文

Apache Storm 官方文档 —— 问题与解决

原文链接    译者:魏勇

本文介绍了用户在使用 Storm 过程中遇到的问题与相应的解决方法。

阅读全文

Apache Storm 官方文档 —— 本地模式

原文链接    译者:魏勇

本地模式是一种在本地进程中模拟 Storm 集群的工作模式,对于开发和测试拓扑很有帮助。在本地模式下运行拓扑与在集群模式下运行拓扑的方式很相似。

阅读全文

Apache Storm 官方文档 —— Storm 集群安装配置

原文链接    译者:魏勇

本文详细介绍了 Storm 集群的安装配置方法。如果需要在 AWS 上安装 Storm,你应该先了解一下 storm-deploy 项目。storm-deploy 可以自动完成 E2 上 Storm 集群的准备、配置、安装的全部过程,同时还设置好了 Ganglia,方便监控 CPU、磁盘以及网络的使用信息。

阅读全文

Apache Storm 官方文档 —— Trident Spouts

原文链接    译者:魏勇

与一般的 Storm API 一样,spout 也是 Trident 拓扑的数据来源。不过,为了实现更复杂的功能服务,Trident Spout 在普通的 Storm Spout 之上另外提供了一些 API 接口。

数据源、数据流以及基于数据流更新 state(比如数据库)的操作,他们之间的耦合关系是不可避免的。Trident State 一文中有这方面的详细解释,理解他们之间的这种联系对于理解 spout 的运作方式非常重要。

阅读全文

Apache Storm 官方文档 —— Trident State

原文链接    译者:魏勇

Trident 中含有对状态化(stateful)的数据源进行读取和写入操作的一级抽象封装工具。这个所谓的状态(state)既可以保存在拓扑内部(保存在内存中并通过 HDFS 来实现备份),也可以存入像 Memcached 或者 Cassandra 这样的外部数据库中。而对于 Trident API 而言,这两种机制并没有任何区别。

阅读全文

Apache Storm 官方文档 —— Trident API 概述

原文链接    译者:魏勇

Trident 的核心数据模型是“流”(Stream),不过与普通的拓扑不同的是,这里的流是作为一连串 batch 来处理的。流是分布在集群中的不同节点上运行的,并且对流的操作也是在流的各个 partition 上并行运行的。

阅读全文

Apache Storm 官方文档 —— Trident 教程

原文链接    译者:魏勇

Trident 是 Storm 的一种高度抽象的实时计算模型,它可以将高吞吐量(每秒百万级)数据输入、有状态的流式处理与低延时的分布式查询无缝结合起来。如果你了解 Pig 或者 Cascading 这样的高级批处理工具,你就会发现他们和 Trident 的概念非常相似。Trident 同样有联结(join)、聚合(aggregation)、分组(grouping)、函数(function)以及过滤器(filter)这些功能。Trident 为数据库或者其他持久化存储上层的状态化、增量式处理提供了基础原语。由于 Trident 有着一致的、恰好一次的语义,因此推断出 Trident 拓扑的状态也是一件很容易的事。

阅读全文

Apache Storm 官方文档 —— 理解 Storm 拓扑的并行度(parallelism)概念

原文链接    译者:魏勇

一个运行中的拓扑是由什么构成的:工作进程(worker processes),执行器(executors)和任务(tasks)

在一个 Storm 集群中,Storm 主要通过以下三个部件来运行拓扑:

  1. 工作进程(worker processes)
  2. 执行器(executors)
  3. 任务(tasks)

阅读全文

Apache Storm 官方文档 —— 容错性

原文链接    译者:魏勇

本文通过问答的形式解释了 Storm 的容错性原理。


工作进程(worker)死亡时会发生什么?

工作进程死亡的时候,supervisor 会重新启动这个进程。如果在启动过程中仍然一直失败,并且无法向 Nimbus 发送心跳,Nimbus 就会将这个 worker 重新分配到其他机器上去。

阅读全文

Apache Storm 官方文档 —— FAQ

原文链接    译者:魏勇

Storm 最佳实践

关于配置 Storm + Trident 的建议

  • worker 的数量最好是服务器数量的倍数;topology 的总并发度(parallelism)最好是 worker 数量的倍数;Kafka 的分区数(partitions)最好是 Spout(特指 KafkaSpout)并发度的倍数
  • 在每个机器(supervisor)上每个拓扑应用只配置一个 worker
  • 在拓扑最开始运行的时候设置使用较少的大聚合器,并且最好是每个 worker 进程分配一个
  • 使用独立的调度器(scheduler)来分配任务(关于Scheduler 的知识请参考 xumingming 的博客 —— 译者注)
  • 在每个 worker 上只配置使用一个 acker —— 这是 0.9.x 版本的默认特性,不过在早期版本中有所不同
  • 在配置文件中开启 GC 日志记录;如果一切正常,日志中记录的 major GC 应该会非常少
  • 将 trident 的 batch interval 配置为你的集群的端到端时延的 50% 左右
  • 开始时设置一个很小的 TOPOLOGY_MAX_SPOUT_PENDING(对于 trident 可以设置为 1,对于一般的 topology 可以设置为 executor 的数量),然后逐渐增大,直到数据流不再发生变化。这时你可能会发现结果大约等于 “2 × 吞吐率(每秒收到的消息数) × 端到端时延” (最小的额定容量的2倍)。

阅读全文

Apache Storm 官方文档 —— 命令行操作

原文链接    译者:魏勇

本文介绍了 Storm 命令行客户端中的所有命令操作。如果想要了解怎样设置你的 Strom 客户端和远程集群的交互,请按照配置开发环境一文中的步骤操作。

阅读全文

Apache Storm 官方文档 —— 消息的可靠性保障

原文链接    译者:魏勇

Storm 能够保证每一个由 Spout 发送的消息都能够得到完整地处理。本文详细解释了 Storm 如何实现这种保障机制,以及作为用户如何使用好 Storm 的可靠性机制。

阅读全文

Apache Storm 官方文档 —— 配置

原文链接    译者:魏勇

Storm 有大量配置项用于调整 nimbus、supervisors 和拓扑的行为。有些配置项是系统级的配置项,在拓扑中不能修改,另外一些配置项则是可以在拓扑中修改的。

每一个配置项都在 Storm 代码库的 defaults.yaml 中有一个默认值。可以通过在 Nimbus 和 Supervisors 的环境变量中定义一个 storm.yaml 来覆盖默认值。最后,在使用 StormSubmitter 提交拓扑时也可以定义基于具体拓扑的配置项。但是,基于拓扑的配置项仅仅能够覆盖那些以 “TOPOLOGY” 作为前缀的配置项。

阅读全文

Apache Storm 官方文档 —— 基础概念

原文链接    译者:魏勇

Storm 系统中包含以下几个基本概念:

  1. 拓扑(Topologies)
  2. 流(Streams)
  3. 数据源(Spouts)
  4. 数据流处理组件(Bolts)
  5. 数据流分组(Stream groupings)
  6. 可靠性(Reliability)
  7. 任务(Tasks)
  8. 工作进程(Workers)

译者注:由于 Storm 的几个基础概念无论是直译还是意译均不够清晰,而且还会让习惯了 Storm 编程模型的读者感到困惑,因此后文在提及这些概念时大多还会以英文原文出现,希望大家能够谅解。

阅读全文

return top