Storm实时处理方案架构

《Storm实时处理方案架构》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、1文档说明该文档描述的是以storm为主体的实时处理架构，该架构包括了数据收集部分,实时处理部分，及数据落地部分。关于不同部分的技术选型与业务需求及个人对相关技术的熟悉度有关，会一一进行分析。该架构是本人所掌握的一种架构，可能会与其他架构冇相似的部分，个人会一一解释对其的理解。这个文章写的很详细，相信对人家在实时处理整体理解上会有帮助的。2实时处理架构2.1整体架构图MetaQ館端业务系统数据获IIZAPIIq莒监控11■号数据接入闵:Starm实时处理系统数捱落地层IIDFS(hadoop)Lustrevvv.blogchong^QB架构说明：整个数据处理流程包括四部分，一部分是数据接入层，

2、该部分从前端业务系统获取数据；中间部分是最重要的storm实时处理部分，数据从接入层接入，经过实吋处理后传入数据落地层；第三部分为数据落地层，该部分指定了数据的落地方式；第四部分元数据管理器。2.2数据接入层该部分有多种数据收集方式，包括使用消息队列(MetaQ),直接通过网络Socket传输数据，前端业务系统专有数据采集API,对Log问价定时监控。为什么选择消息队列?这或许是大家比较疑惑的地方，会疑惑为什么不把数据直接导入storm屮。使用消息队列作为数据中间处理组件的原因是，在大批量数据处理时，前端业务数据产生速度可能会很快，而实吋处理或者其他处理速度跟不上，会影响整个系统处理性能，引入

3、消息队列之后，我们可以把数据临时存储在消息队列中，后端处理速度就不会影响前端业务数据的产生，比较专业的术语叫做解除耦合，增加系统扩展性，系统各组件异步运行。为什么使用MetaQ?在消息队列选择上，kafka是一个比较通用的，开源吋间较长的消息发布订阅系统，而MeteiQ是基于kafka发的，使用我们比较熟悉的Java发，并且在此基础上作了一定的改进，如数据可靠及事务处理等。另一方面，这是国人开源的东西，各方而的文档比较完整，并且冇相关的实例接口。所以使用MetaQ作为消息中间件，开发成本比较低，乂有较好的性能。2.2.2Socket部分人使用网络Socket编程实现Storm的数据接入。这是一

4、种比较直接的数据采集方式，并且确实有些Storm相关的项目使用这种数据接入方式。这种数据接入方式比较简单，维护成木较低，但数据量相对于使用消息中间件來说较小。难点：使用Socket采集数据比较麻烦的是，FtlT*Storm的Spout,的地址是不定的，无法确定其地址，则前端业务系统就无法将数据准确的发送的某个具体IP地址上的端口小。解决方法如下：(1)我们可以使用zookeeper作为传输诂，Spout执行后，将本地冇效的1P地址及可用正在监控的端口等信息写入zookeeper中，前端业务系统从zookeeper口录屮获取该信息。(2)使用元数据指导前端业务系统数据发送，Spout将本地IP及

5、端口信息存入元数据管理器中，前端业务系统从元数据管理器中获取该参数信息。2.2.3前端业务系统数据采集API这种数据采集方式就不多说了，前端业务系统为Spout专门设计的数据采集API,Spout只需调用该API就能获取数据。2.2.4Log文件监控有时候我们的数据源是已经保存下来的log文件，那Spout就必须监控Log文件的变化，及时将变化部分的数据提取写入Storm+，这很难做到完全实时性。2.3Storm实时处理系统2.3.1说明前面部分数据接入层其实已经包含部分storm相关的内容，例如一些数据采集接口就是屈于Storm的Spout部分，我把该部分单独拿出来的意思是把实时处理核心部分

6、作为一个大章节，即实时处理部分（除数据接入及数据落地的接口）。2.3.2使用Storm原因为何选择Storm作为实时处理的核心呢？Storm作为开源比较早的款实吋处理系统，其功能比较完善，其failover机制相当给力，无论是woker还是supervisor,甚至是task,只要挂掉都能口动重启；其性能经过测试还是相当不错的月•目前网络相关资料较多，这就意味着开发代价会小很多；其扩展性非常好，能够横向扩展。Storm前的短处在与nimbus单点,如果nimbus挂掉,整个系统会挂掉，这是Storm需要改进的地方，不过nimbus的系统压力不大，一般情况下也不会出现宕机。2.3.3实时处理业务

7、接口该部分需要捉供一个实时业务处理的接口，即将用户的业务层需求转换为实时处理的具体模式。例如模仿Hive提供一个类Sql的业务接口，我们将一类数据在元数据管理器屮描述是-个表，不同字段是表屮不同字段select固定数据查询（异常或者脏数据处理），max/min/avg最大最小值count/sum求和或次数统计（比女IIpv等）count（distinct）去重计数（典型的如UV）orderby排序