数据它就像一股小溪，源源不绝。
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 在实际场景中已经使用的挺少的了，大概沿着 Storm -> Spark Streaming -> Flink 的路径转变。从大公司的角度来看，据去年大沙来做的分享来管中窥豹，阿里内部现在也在主要用 Flink，自己重写的 JStorm 已经有快一年没有更新了，而如果不考虑文档修改，则早在两年前就停止继续开发了；从另一个角度，阿里收购 Apache Flink 商业公司 Data Artisans 这一事也能看出阿里未来的发展趋势。
写这个系列，主要还是为了回顾整理一下 Storm 中的一些技术点吧，曾经学的时候都没有怎么写过笔记，又或者是情怀？还记得大四的时候孙瑞师兄还去阿里实习做 Storm 相关的工作，如今不过两年，Storm 恍如已淹没在历史的尘土之中，技术更新如此之快，令人不禁唏嘘。