发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA

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

              
2013-10-28 08:44
赞助商链接

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集群能运行很长时间。

storm      EDA事件驱动      大数据     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com