Storm在spider.io应用的经验教训

banq 13-10-28
              

Storm at spider.io - London Storm

spider.io 是一个为在线广告提供反恶意软件,反恶意点击的系统,其任务是如何从大量日志中发现广告舞弊点击以骗取广告费。

spider.io 原先已经使用Queue/Worker来扩展其系统,问题:
1.太依赖代码,写太多底层代码不是每个人都擅长的。
2.维持in-memory数据库带来费用提高,主要是AWS内存费用。
3.不能动弹伸缩扩展,整个DB集群需要重启。

迁移到Storm后:
1.将自己的基于事件流驱动event-stream-based迁移到Storm,这样有整个开源社区来盯着它。
2.从内存数据库移植到HBase,能够持久数据很长时间。

spider.io在2011年9月花一个月由一个工程师搞定Storm。期间经过几次波折,他们现在状况是:

使用 Storm,和Mahout结对
● 使用 Cascading + Mahout来对付亿万级别广告展现。
● 实时响应使用 Trident + Mahout

使用“坏签名”识别新的僵尸网络IP地址,以及嫌疑出版商。
能够在线学习适应新出现的威胁模型

他们的经验教训是:
如果你的业务变化,你的架构必须跟随变化。
● 只有在下面请看选择Storm:
○ 如果你已经有一个基于事件流的系统,使用Storm能够更有弹性。
○ 你的业务需要的实时分析组件正好是一个事件流驱动模型。
○ 你乐于在基于底层编码。

● 下面情况不要使用Storm:
○ 你无需实时数据分析
○ 你只是觉得它很酷。

使用Cascading实现Hadoop jobs,使用Storm用来实现实时分析,这两者搭配真的很方便:
○ 保留了基于事件流的范式
○进行升级迁移时,不必换一个角度来思考Sotrm(因为你习惯了EDA方式)
○ 能够共享代码
○ 有一个通用分析组件库来评估他们。
●一个适当的可管理的Storm集群能运行很长时间。