标签 ‘ 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 教程
Trident 是 Storm 的一种高度抽象的实时计算模型,它可以将高吞吐量(每秒百万级)数据输入、有状态的流式处理与低延时的分布式查询无缝结合起来。如果你了解 Pig 或者 Cascading 这样的高级批处理工具,你就会发现他们和 Trident 的概念非常相似。Trident 同样有联结(join)、聚合(aggregation)、分组(grouping)、函数(function)以及过滤器(filter)这些功能。Trident 为数据库或者其他持久化存储上层的状态化、增量式处理提供了基础原语。由于 Trident 有着一致的、恰好一次的语义,因此推断出 Trident 拓扑的状态也是一件很容易的事。
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 有大量配置项用于调整 nimbus、supervisors 和拓扑的行为。有些配置项是系统级的配置项,在拓扑中不能修改,另外一些配置项则是可以在拓扑中修改的。
每一个配置项都在 Storm 代码库的 defaults.yaml 中有一个默认值。可以通过在 Nimbus 和 Supervisors 的环境变量中定义一个 storm.yaml 来覆盖默认值。最后,在使用 StormSubmitter 提交拓扑时也可以定义基于具体拓扑的配置项。但是,基于拓扑的配置项仅仅能够覆盖那些以 “TOPOLOGY” 作为前缀的配置项。