storm,mapreduce本质是什么,结合本人实际项目经验谈谈

storm,mapreduce就是将一个任务交给一堆人去做的框架.交给一堆人去做,就必然涉及沟通,管理这些问题,所以storm其本质是组件分工协作与管理的一个最佳实践.

storm框架更关注整个架构的非功能性需求方面.

如同erp是企业管理最佳实践的一个实现.

让我们思考如果没有storm,mapreduce这些框架,我们是怎么做的?会面临那些难题?

为什么要引入这个框架?

引入一个我接触的典型业务场景:仪器结果文件解析入库(ipd解析),这个业务就是将检验仪器传送的结果信息文件解析后存入业务数据的检验结果表.

首先看看演变过程:

一开始这个功能针对一个单一实验室,最多十几台仪器,每日样本文件数大约1万,我们提供一个后台解析程序,轮询文件目录,单线程不停的跑就可以支撑.

期间由于程序bug,硬件问题等原因出现过多次down机,运维人员表示压力很大,于是专门开发了一个监控程序,监视这个解析程序,发现有问题就会重启这个程序,并记录异常日志.

随着业务量的提升,压力越来越大,针对瓶颈,进一步拆封程序为分发程序和多个解析程序.分发程序负责获取文件,并将文件均分到几个子目录,解析程序去指定的子目录检索文件解析.

这样,我们的监控程序要监控所有这些程序,同时,还要有一定机制将解析失败的文件放到重试目录,重试多次无效后放入错误目录,并给出报警.

可以看到我们是利用一个共享磁盘让解析,分发程序交互的.

后来随着公司系统逐步上云,所有实验室的仪器结果集中上传中心服务器的hdfs文件系统,整体业务量变大上百倍,未来可能达到千万级别.

一个方案是旧的模式克隆多份.这时候随着部署的系统的增多,组件的管理,可靠性,可用性,容灾,负载平衡,伸缩性这些问题随之而来,旧的模式简单的克隆已经无法满足这些非功能性需求.

可以看到,随着组件,节点的暴涨,最大的问题已经变成运维管理的问题,大力气是落在服务治理头上.

这时候急需一套成熟的框架来管理这些分布在各处又互相协作的组件,按照一定规则可靠的执行.

而storm和mapreduce提供的功能正是我们需要的.

最终我们我们将原来的业务逻辑再次包装为storm中的spout,bolt组件,让storm去执行管理.

业务扩张后,只要简单的扩展节点就能满足要求.

系统间的信息流,组件间的信息流,这些都可以考虑在storm框架下实现为可管理,高可靠,高伸缩性的协同组件系统架构.