再探Apache Storm(1)---概述

Apache Storm

Apache Storm 是一个分布式的流式处理系统,最早由Twitter收购的BackType推出,后贡献给Apache基金会。Storm 具有低延迟、容错、高可用等特性,适合处理那些实时性要求较高的流式数据。

首先要介绍一下批处理与流处理。以计算双十一当日淘宝网的订单交易金额总量为例,批处理就是在第二天拿到所有的数据之后,再进行汇总操作;而流处理则不需要如此,它可以提前处理,每当有一笔订单成交时,就将这笔订单数据丢到这个系统,然后累加,等到双十一过去,最后一笔订单处理完毕,双十一当天的交易总额也就计算完毕了。总结一下,批处理处理的数据是固定的、已有的,而流处理则面对的是未来的、不可预测的流入数据。相比批处理、流处理具有更加实时的优势,同时由于面临着未来不可预知的数据,有一些额外的如负载等挑战。

还记得每年的双十一淘宝实时交易大屏么,背后就是用流处理技术做的,当然用批处理技术也能做,但是延迟要高一点,不过这种微批量技术是后来提出的了。

安装与部署

Storm 依赖 zookeeper 来做高可用,所以需要部署额外的zk集群。

关于 Apache Storm 的安装与部署之前写过一篇博客,就不重说一遍了。

请参考 基于Docker Swarm搭建Apache Storm集群

是基于Docker部署的,没有docker基础的可能理解起来麻烦一点,不过这时代docker应该快成程序员必备知识了吧,学了总归没错。

架构

关于 Storm 的架构,接触多了大数据平台之后就会发现,都是差不多的。集群中有两种节点,一种是主节点(Storm中叫 Nimbus),负责元数据的处理和任务调度;另一种叫从节点(工作节点,Storm 中叫 Supervisor),负责启动某一种任务实例,执行具体的任务。

在Storm中,用户提交的任务被称为拓扑(topology),它是一个有向无环图(DAG),一个topology中定义了数据是如何被处理的,其中有两种节点 spout和bolt。Nimbus获取到topology时,根据定义的 spout 和 bolt 类型和各自的个数(并发度)划分成一个个的任务task,并根据supervisor的运行情况分配任务,supervisor从zk接收到任务之后,启动worker执行任务,每个worker对应的就是一个JVM容器,每个worker会启动executor,一般情况下一个executor会负责处理一个task。至此,任务的各个组件就准备好了,只等数据流入。

Storm 本身没有设计高可用机制,各个组件都是被设计成快速失败的,为了实现高可用机制,storm将所有的元数据信息都存放在了zookeeper集群中,这样即便是storm组件失效了,也能重新调度到其他的节点上继续执行。

apache storm architecture

后记

在写这个系列的时候,Apache Storm 在实际场景中已经使用的挺少的了,大概沿着 Storm -> Spark Streaming -> Flink 的路径转变。从大公司的角度来看,据去年大沙来做的分享来管中窥豹,阿里内部现在也在主要用 Flink,自己重写的 JStorm 已经有快一年没有更新了,而如果不考虑文档修改,则早在两年前就停止继续开发了;从另一个角度,阿里收购 Apache Flink 商业公司 Data Artisans 这一事也能看出阿里未来的发展趋势。

写这个系列,主要还是为了回顾整理一下 Storm 中的一些技术点吧,曾经学的时候都没有怎么写过笔记,又或者是情怀?还记得大四的时候孙瑞师兄还去阿里实习做 Storm 相关的工作,如今不过两年,Storm 恍如已淹没在历史的尘土之中,技术更新如此之快,令人不禁唏嘘。

参考

Apache Storm

我在阿里的这两年

Storm:最火的流式处理框架

Storm工作原理(1)

使用 Twitter Storm 处理实时的大数据

Getting Started with Storm

Learning Storm