基于storm构建一个实时数据分析系统研讨.ppt

重构开始，新架构的设计~ * 怎么做到灰度接入，前后台兼容？？ * 流量太大导致，遇到很多问题？ 一开始的开发过程还是比较顺利，因为是机遇之前成熟的架构和框架，很多问题都是发量之后才暴露出来的。 1.处理性能跟不上，storm版本过低导致内存设置不起作用，zeromq消息队列一直在涨，最终撑死机器 * 2.升级之后，发现内存一直在涨，导致work一直重启，通过分析java虚拟机取出内存镜像分析，发现还是消息队列一直再涨，然后通过走查代码发现，有个bolt代码有问题 * 3.入库节点IO特别高，导致机器性能差 * 4.Mysql增长太快，innoddb删除不一起作用 * 5.负载不均衡 * 遗留的问题？ * 未来的走向？开放与集成 * 一次自我救赎 之返回码系统重构 社交网络运营部-接入运维组 hobdong 2015-01-14 hobodong(董超) 来自社交网络运营部运营服务中心接入层运维组 目前负责SNG用户端监控系统(返回码，测速，自动化监控，业务考核)、华佗开放项目的开发，同时也参与接入运维的相关工作。 自我介绍 什么是返回码系统？ http返回码： 200 404 500 ….. cgi逻辑返回码： 20000 20001 20002 ….. 返回码的原理？？ 返回码的目标用户？？ 用途：反映用户侧最真实的用户请求质量，以及监控各个地区运营商的请求质量，及时发现用户请求的异常，提升用户体验。 浏览器 接入服务器 分析集群 数据库 运维关注 http返回码： 200 502 404 500 ….. 开发关注 cgi逻辑返回码： 20000 20001 …….. QA关注整个业务的质量 目前接入域名：763个，接入cgi个数：40141，涉及SNG IEG CDG OMG WXG，每天上报次数保守估计达：50亿次 返回码之前的架构，以及架构的瓶颈 通过js上报 接入服务器 文件推送 文件推送 Php脚本入库 读取文件 数据库 页面展示 离线任务分析 1.数据流通过文件的形式实现，效率低，延迟大。 2.数据分析的cdp集群，无法平行扩展，数据归并的节点是单点。 3.管理比较原始，扩容机器比较麻烦。 4.模块混合部署，无法容灾。 单点 为什要重构？？ 因为蛋疼！！ 每天晚上由于集群高负载，导致数据堆积，引起的磁盘告警 每天早上来由于集群故障丢数据，被QA和开发屌 每次扩容挨个去配置数据接入规则，配到眼花 遗留系统无法支持增加移动侧相关特性，被开发挑战 与其在别人挖的坑里面挣扎，不如自己动手重构，自我救赎~ 重构开始 技术选型，为什么选择storm？ 1.中心已经有成功的案例，模调就是基于storm构建的，有现成的框架。 2.Storm是一个免费开源、分布式、高容错的实时计算系统。具备以下优点： 分布式系统：可横向拓展。 运维简单：Storm的部署的确简单。 高度容错：模块都是无状态的，随时宕机重启。 无数据丢失：Storm创新性提出的ack消息追踪框架和复杂的事务性处理,能 够满足很多级别的数据处理需求。 多语言：支持python java等语言构建拓扑 新架构的设计 zookeeper 新架构的优点 1.使用storm集群，可平行扩展和容灾。 2.模块之间通过L5调用，支持容灾。 3.使用消息队列和mongoDB替代之前文件推送的方式，提高数据传输效率 4.无论是L5还是storm都有完善的管理系统，扩容，变更，下线都比较便捷。 5.整个架构无单点，无论哪层负载不够，都可以平行扩容。 怎么做到灰度接入，前后台兼容？？ 1.兼容前端接入协议，这样可以保证业务侧无感知 2.后端数据分析入库的数据格式也要保证和之前一致 3.搭建新架构的集群，然后通过tgw灰度接入一小部分流量进行验证，对比两个集群加工的数据 4.持续放量，观察新集群的负载和健康度，及时发现由于流量增加引起的集群问题。 5.放量完成之后，线上观察一段时间，发现问题可以切换到老集群继续运行。 6.整个切换完成之后，即可下线老集群，回收机器了。 遇到哪些坑？ 现象：放量之后，storm集群的机器内存一直在涨，最终导致机器故障，需要人工确认修复重启，6000电话告警不断。 分析：上机器看发现java进程的内存不断上涨，直到机器物理内存全部被耗尽，和网平的同事确认，由于机器上的内存被耗尽，agent上报超时，无法触发自动重启流程，必须6000告警给负责人，人工确认修理，通过带外重启才可以。 Storm配置中是有配置每个worker的内存大小限制的，我设置的是4096m，每台机器有两个worker，理论上worker的内存是不会超过4096m的，但实际在机器上查看wor