《基于storm构建一个实时数据分析系统概要课件》由会员分享，可在线阅读，更多相关《基于storm构建一个实时数据分析系统概要课件（23页珍藏版）》请在金锄头文库上搜索。
1、一次自我救赎 之返回码系统重构,社交网络运营部-接入运维组 hobdong 2015-01-14,hobodong(董超) 来自社交网络运营部运营服务中心接入层运维组 目前负责SNG用户端监控系统(返回码，测速，自动化监控，业务考核)、华佗开放项目的开发，同时也参与接入运维的相关工作。,自我介绍,什么是返回码系统？,http返回码： 200 404 500 .,cgi逻辑返回码： 20000 20001 20002 .,返回码的原理？,返回码的目标用户？,用途：反映用户侧最真实的用户请求质量，以及监控各个地区运营商的请求质量，及时发现用户请求的异常，提升用户体验。,运维关注 http返回码：
2、200 502 404 500 .,开发关注 cgi逻辑返回码： 20000 20001 .,QA关注整个业务的质量,目前接入域名：763个，接入cgi个数：40141，涉及SNG IEG CDG OMG WXG，每天上报次数保守估计达：50亿次,返回码之前的架构，以及架构的瓶颈,通过js上报,文件推送,文件推送,读取文件,1.数据流通过文件的形式实现，效率低，延迟大。 2.数据分析的cdp集群，无法平行扩展，数据归并的节点是单点。 3.管理比较原始，扩容机器比较麻烦。 4.模块混合部署，无法容灾。,为什要重构？,因为蛋疼！,每天晚上由于集群高负载，导致数据堆积，引起的磁盘告警 每天早上来由于
3、集群故障丢数据，被QA和开发屌 每次扩容挨个去配置数据接入规则，配到眼花 遗留系统无法支持增加移动侧相关特性，被开发挑战 与其在别人挖的坑里面挣扎，不如自己动手重构，自我救赎,重构开始,技术选型，为什么选择storm？ 1.中心已经有成功的案例，模调就是基于storm构建的，有现成的框架。 2.Storm是一个免费开源、分布式、高容错的实时计算系统。具备以下优点： 分布式系统：可横向拓展。 运维简单：Storm的部署的确简单。 高度容错：模块都是无状态的，随时宕机重启。 无数据丢失：Storm创新性提出的ack消息追踪框架和复杂的事务性处理,能够满足很多级别的数据处理需求。 多语言：支持pyt
4、hon java等语言构建拓扑,新架构的设计,zookeeper,新架构的优点,1.使用storm集群，可平行扩展和容灾。 2.模块之间通过L5调用，支持容灾。 3.使用消息队列和mongoDB替代之前文件推送的方式，提高数据传输效率 4.无论是L5还是storm都有完善的管理系统，扩容，变更，下线都比较便捷。 5.整个架构无单点，无论哪层负载不够，都可以平行扩容。,怎么做到灰度接入，前后台兼容？,1.兼容前端接入协议，这样可以保证业务侧无感知 2.后端数据分析入库的数据格式也要保证和之前一致 3.搭建新架构的集群，然后通过tgw灰度接入一小部分流量进行验证，对比两个集群加工的数据 4.持续放
5、量，观察新集群的负载和健康度，及时发现由于流量增加引起的集群问题。 5.放量完成之后，线上观察一段时间，发现问题可以切换到老集群继续运行。 6.整个切换完成之后，即可下线老集群，回收机器了。,遇到哪些坑？,现象：放量之后，storm集群的机器内存一直在涨，最终导致机器故障，需要人工确认修复重启，6000电话告警不断。,分析：上机器看发现java进程的内存不断上涨，直到机器物理内存全部被耗尽，和网平的同事确认，由于机器上的内存被耗尽，agent上报超时，无法触发自动重启流程，必须6000告警给负责人，人工确认修理，通过带外重启才可以。 Storm配置中是有配置每个worker的内存大小限制的，我
6、设置的是4096m，每台机器有两个worker，理论上worker的内存是不会超过4096m的，但实际在机器上查看worker的内存超过了4096，并且不断在涨。,定位解决：我们用的是0.8版本，java使用的内存无法有效的控制，从社区里面获取高版本进行升级。,现象：升级之后，发现内存一直在涨，导致worker一直重启,遇到哪些坑？,分析： 通过jmap分析java虚拟机取出内存镜像，发现还是消息队列一直再涨，然后通过走查代码发现，有个bolt代码有问题。有个翻译运营商的逻辑，每条数据通过顺序查找去实现的， 66745条数据顺序查找。,解决：排序数据，然后使用二分查找法替换之前的顺序查找，并且
7、加大worker数量，增加并发数。时间复杂度从O(N)降到了O(logn)。,遇到哪些坑？,现象：入库节点IO特别高，导致机器性能差，消息队列数据堆积，内存一直在涨。,分析：通过分析代码，发现了之前框架里面的入库逻辑是把每个要入库的数据按照库表和时间为单位写入到文件里面，通过load data infile的方法入库，这种方法比直接insert要高效。但是返回码有个特殊的地方在于入库的策略是按照cgiId来进行分表的，目前接入了上万个cgi，所以每次入库会同时向上万个文件同时写数据，这样肯定会引起机器的IO高负载，来不及处理，导致消息队列堆积。,解决：入库方式从load data 改为 ins
8、ert ，调整入库频率，改为一次入库多条记录，从而降低数据库连接数，目前并发的峰值数据连接数在200左右，在可接受范围内。,遇到哪些坑？,现象：Mysql增长太快，innoddb删除不一起作用,分析： innoddb 默认是把所有库表数据保存一个文件里面，删除单个库表，无法释放磁盘空间。,解决： 只要设置mysql配置innodb-file-per-table=1，就可以让mysql的每个库表都是一个文件，删除单个库表就可以释放磁盘空间了。,遇到哪些坑？,现象：新架构全量切换之后，每天4点开始数据丢失，持续15分钟之后恢复。,分析：顺着整个数据流向开始排查，用户端浏览器-前端接入机器-数据收集
9、server-mongoDB-storm集群的各个节点-数据库，最终定位到mongoDB机器的问题，每天凌晨4点会执行一个crontab脚本，使用repairDatabase方法对MongoDB需要进行数据碎片整理，会扫描db中的所有数据，并通过重新插入来整理数据集合，缺点是速度太慢，操作的时候对DB的读写操作会变得非常慢，甚至会出现写操作丢失的情况，因此这个时候最好直接停掉客户端的写操作。,解决：对碎片清理的逻辑做下修改，在清理之前先删除这些积压的数据，然后在进行碎片整理，因为这些积压数据一旦积压说明肯定没用了，直接删除即可。,遗留问题,1.Storm集群节点机器负载不均衡。 2.接入机逻辑过重，导致单台机器并发量不高。 3.入库逻辑未做容灾，入库失败的情况下，会出现丢数据。 4.关于storm的莫名其妙的问题。 5.缺乏自身监控，需建设。,未来的走向,未来的走向,移动端的http请求大部分都是从手机上的各个应用中发出的，不同于PC来源于浏览器，因此有必要发布适用于各个平台的返回码组件，集成到不同平台的应用中，满足不同端的监控需求。,未来的走向,开放,集成,
