Storm基础理论

Storm流式计算基础

○ 什么是Storm？

Storm是一个开源的、分布式、流式计算系统。

大家都知道现在我们都处于一个信息爆炸头的时代，有很多公司处理的数据量就很大，而且增长速度很惊人。但作为一个程序猿还是很懒的，当我们目前面临1wQPS的时候，绝对不会去考虑10wQPS的时候我们该怎么做。就在我们刚写完一个系统的时候，几倍的流量就来打你的脸，那这个时候该怎么办呢？大部分的公司在这个时候想到的办法就是升级服务器配置。因为开发前面的那个系统已经耗费不少时间了，要是开发一个几倍流量的系统，估计得雇佣多几个更有经验的程序猿，开发更长的时间才能开发出来。这个估计老板会选择买点更好的服务器算了。一开始这确实是个最方便最省钱的办法，但是很多公司都踏上了一条升级服务器配置的不归路。升着升着普通的机器就满足不了用户的需求了。

所以说当数据规模达到这种程度的情况下，资金也比较雄厚了，已经有了足够牛逼的开发团队，许多公司都不愿意当这个冤大头了，迫于无奈之下都想到的是同一个办法：把任务拆解到多台计算机上去执行，对外只提供一个接口

1.数据量大--------> 分
2.                 布
3.增长太快--------> 式

之前有人曾经开发过分布式系统，都没有成功。后来google提出了三篇重要意义的论文，BigTable、GFS、MapReduce。然后被人看到这三篇论文之后就开发出了hadoop，基于hadoop的改进hadoop的系统就陆续出现了。由于hadoop有一整套的生态系统，所以现在人们谈到分布式就必谈到hadoop。但hadoop并不能解决大部分的计算需求。MapReduce只能处理批量式计算需求，数据得在计算之前就都准备好。收集数据得花一段时间，再进行计算又花一段时间，因此没有实时性。

○ Storm基本组件

Storm的主从结构

1.                     Supervisor
2.         Zookeeper   Supervisor
3.Nimbus ? Zookeeper ? Supervisor
4.         Zookeeper   Supervisor
5.                     Supervisor

主从结构：简单，高效，但主节点存在单点问题

• Nimbus

  • 主节点
  • 只负责整体分配工作
  • 不具体干活
  • 老板

• Supervisor

  • 从节点
  • 直接管理干活的Worker
  • 小组经理

• Worker

  • 真正干活(TASK)的进程

• Heron改进
  

• Storm DRPC
  

• Storm UI

Storm作业提交运行流程

• 用户编写Storm Topolgy
• 使用Client提交Topology给Nimbus
• Nimbus指派ask给Supervisor
• Supervisor为Task启动Worker
• Worker执行Task