Storm实时处理方案架构.docxVIP

1 文档说明 该文档描述的是以storm为主体的实时处理架构，该架构包括了数据收集部分，实时处理部分，及数据落地部分。 关于不同部分的技术选型与业务需求及个人对相关技术的熟悉度有关，会一一进行分析。 该架构是本人所掌握的一种架构，可能会与其他架构有相似的部分，个人会一一解释对其的理解。 这个文章写的很详细，相信对大家在实时处理整体理解上会有帮助的。 ? 2 实时处理架构 2.1 整体架构图 架构说明： 整个数据处理流程包括四部分，一部分是数据接入层，该部分从前端业务系统获取数据；中间部分是最重要的storm实时处理部分，数据从接入层接入，经过实时处理后传入数据落地层；第三部分为数据落地层，该部分指定了数据的落地方式；第四部分元数据管理器。 2.2 数据接入层 该部分有多种数据收集方式，包括使用消息队列（MetaQ），直接通过网络Socket传输数据，前端业务系统专有数据采集API，对Log问价定时监控。 2.2.1 MetaQ 为什么选择消息队列? 这或许是大家比较疑惑的地方，会疑惑为什么不把数据直接导入storm中。 使用消息队列作为数据中间处理组件的原因是，在大批量数据处理时，前端业务数据产生速度可能会很快，而实时处理或者其他处理速度跟不上，会影响整个系统处 理性能，引入消息队列之后，我们可以把数据临时存储在消息队列中，后端处理速度就不会影响前端业务数据的产生，比较专业的术语叫做解除耦合，增加系统扩展性，系统各组件异步运行。 为什么使用MetaQ？ 在消息队列选择上，kafka是一个比较通用的，开源时间较长的消息发布订阅系统，而MetaQ是基于kafka开发的，使用我们比较熟悉的Java开发，并且在此基础上作了一定的改进，如数据可靠及事务处理等。另一方面，这是国人开源的东西，各方面的文档比较完整，并且有相关的实例接口。所以使用MetaQ作为消息中间件，开发成本比较低，又有较好的性能。 2.2.2 Socket 部分人使用网络Socket编程实现Storm的数据接入。这是一种比较直接的数据采集方式，并且确实有些Storm相关的项目使用这种数据接入方式。 这种数据接入方式比较简单，维护成本较低，但数据量相对于使用消息中间件来说较小。 难点： 使用Socket采集数据比较麻烦的是，由于Storm的Spout的地址是不定的，无法确定其地址，则前端业务系统就无法将数据准确的发送的某个具体IP地址上的端口中。解决方法如下： (1) 我们可以使用zookeeper作为传输站，Spout执行后，将本地有效的IP地址及可用正在监控的端口等信息写入zookeeper中，前端业务系统从zookeeper目录中获取该信息。 (2) 使用元数据指导前端业务系统数据发送，Spout将本地IP及端口信息存入元数据管理器中，前端业务系统从元数据管理器中获取该参数信息。 2.2.3 前端业务系统数据采集API 这种数据采集方式就不多说了，前端业务系统为Spout专门设计的数据采集API，Spout只需调用该API就能获取数据。 2.2.4 Log文件监控 有时候我们的数据源是已经保存下来的log文件，那Spout就必须监控Log文件的变化，及时将变化部分的数据提取写入Storm中，这很难做到完全实时性。 2.3 Storm实时处理系统 2.3.1 说明 前面部分数据接入层其实已经包含部分storm相关的内容，例如一些数据采集接口就是属于Storm的Spout部分，我把该部分单独拿出来的意思是把实时处理核心部分作为一个大章节，即实时处理部分（除数据接入及数据落地的接口）。 2.3.2 使用Storm原因 为何选择Storm作为实时处理的核心呢？Storm作为开源比较早的一款实时处理系统，其功能比较完善，其failover机制相当给力，无论是woker还是supervisor，甚至是task，只要挂掉都能自动重启；其性能经过测试还是相当不错的且目前网络相关资料较多，这就意味着开发代价会小很多；其扩展性非常好，能够横向扩展。Storm目前的短处在与nimbus单点，如果nimbus挂掉，整个系统会挂掉，这是Storm需要改进的地方，不过nimbus的系统压力不大，一般情况下也不会出现宕机。 2.3.3 实时处理业务接口 该部分需要提供一个实时业务处理的接口，即将用户的业务层需求转换为实时处理的具体模式。例如模仿Hive提供一个类Sql的业务接口，我们将一类数据在元数据管理器中描述是一个表，不同字段是表中不同字段 select ---------------------------固定数据查询（异常或者脏数据处理）， max/min/avg-------------------最大最小值 count/sum----------------------求和或次数