数据分析系统阶段总结

波动系统阶段总结1背景波动系统最开始开发给ad-tech内部使用，到提供给客服、销售同学使用，再到数据传达至代理商，经历了几次大的变化，现在正式交接运营，由运营同学维护，所以有此阶段总结。2需求从我接手后，波动系统经历了如下需求：优化页面加载时间，将每日cdielog加载改为多线程方式；在各页面添加导出全部代理商，全部客户信息，top行业，查询词，pid导出；在客户分析页面添加上涨下跌top20，top100代理商数据，同时添加导出全部功能；波动系统加载时间入绿皮；增加波动系统权限管理功能，所有用户必须经过认证和授权之后才能访问；添加每小时导出波动系统总消耗数据，与张黎的每日消耗数据对比；增加波动消耗报警短信和邮件功能，每日定时发短信和邮件给代理商；两次重新获取并恢复用户操作日志；系统交接运营，调整线下脚本和线上代码，分离数据获取和数据制作流程；消耗报警短信改为长短信，并上线；2.1线下数据层变更由于波动系统提交运营，线下数据层被拆分成了两个部分：数据获取和数据制作，数据获取由张黎负责，波动系统只负责数据制作。目录结构也发生了变化：目录功能Conf线下数据层的配置文件：ca.confDataCdielog及其它数据文件的存储目录Result从线上数据算出来的PV数据，按天存储Log线上程序输出，邮件、短信和消耗总表数据Script线下数据层的数据制作脚本所在目录Op_script线下数据层的数据获取脚本所在目录Temp目前temp目录只用来存储配置线下短信白名单的文件脚本和配置文件说明：文件功能Conf/ca.conf定义数据处理过程中的公共变量和函数Conf/specialUser用户角色配置文件，角色编码含义参考后文Conf/csmap配置客服与销售的对应关系Conf/keyword.txt报警短信中的屏蔽词列表Conf/mail_receiver公司内部的波动邮件收件人列表Conf/ldap配置用户是否需要经过passport验证，线下设为FALSEConf/sms配置是否给代理商发送报警短信和邮件，线下设为FALSETemp/sms_recv当上一个文件设为不发送短信时，可以在此文件中设置白名单Op_script/op_daily_get_data.sh获取天级别数据，张黎负责Op_script/op_hourly_get_data.sh获取小时级别数据，张黎负责Op_script/biTran.sh获取admBI系统中的客户消耗数据，由于原始数据产生时间的问题，被单独设置了一个crontab任务Op_script/useroperation.sh获取客户操作日志，由于原始数据产生时间的问题，被单独设置了一个crontab任务Script/day.sh按天处理数据Script/hour.sh按小时处理数据Script/cdieEveryhour.sh处理cd日志，去掉测试账号，删除无用的列Script/cdie_middle.sh删除无用的列，并计算点击记录的业务类型Script/free_account.sh去掉测试账号Script/pv.sh处理leadie日志，生成线上可用的pv数据Script/linkunit.sh处理leadie日志，生成线上可用的pv数据，链接单元用Script/acid2indu3.sh从leadserver.dat中获取客户id到客户行业的映射表Script/useroperation.sh用户操作日志处理，生成一份各个操作的次数统计文件和一份操作详细文件Script/cdieEveryday.sh与按小时处理cd日志脚本类似，多了一个去除不及业绩点击的流程Script/getValid.sh去除不及业绩的点击记录Script/brandCustomer.sh处理品牌客户信息，主要看是否替换前一天的品牌客户列表，防止错误发生张黎的脚本主要负责把数据放到指定的位置，数据处理的脚本从指定位置去处理这些数据。注意crontab的设置，目前有4个，一个按天，一个按小时，其中都是，先调用张黎的脚本，再调用数据处理脚本，另外两个是因为数据获取的时间比较特殊（如果时间没到获取的数据将不是最新的），所以单独抽出来执行。3开发从系统开发的角度，我把上面的需求分为两类，一是模块开发，包括权限控制和消耗报警两个大的需求；一是二次开发，除了模块开发以外的其他需求都是二次开发，二次开发主要是在张金的架构基础上进行局部的修改和添加，比如将单线程改为多线程，从已有导出top10接口得到导出全部数据接口，在已有页面添加新的数据表格，重新获取操作日志等，这一部分我会略写，只介绍里边需要注意的点，此次总结主要介绍模块开发。3.1权限控制3.1.1架构下面的架构图从两个方向看，横向是用户登录时所发生的权限控制流程，纵向是每个环节里所调用的接口和数据，首先，这不是一个好的权限控制系统，因为它只有用户-角色2级关系，一个好的权限控制系统应该是3级关系，用户-角色-权限（即资源）都能动态配置，由于此架构的局限性，导致目前无法动态创建角色，而只能为用户分配已有角色，下个版本可能会修改此结构。这一部分的线上代码在/search/apache下。3.1.2认证1，认证直接使用公司的ldap服务器，又称passport：内网LDAP地址：ldap.sogou-inc.com线上LDAP地址：rldap.sogou-inc.com2，对于波动系统线上和线下可以配置ldap是否启用，在线上根目录下conf/ldap文件内，写入FLASE则ldap失效，其余皆生效。3.1.2授权1，用户角色配置文件conf/specialUser,，管理员手动添加用户和角色，其code含义：1领导产品开发2.1品牌总监2.2中小总监4.1华北大区经理4.2华东大区经理4.3华南大区经理4.4华中大区经理conf/csmap文件专为客服配置权限，其中两列，第一列为客服的sogou邮箱前缀，第二列为系统已开通权限的销售的sogou邮箱前缀，此对应关系由客服同学自己定；data/channelRole/data/channelRole为渠道经理的权限文件，无需配置，每个小时都会自动从adm组的mis系统中获取最新数据，以更新某渠道经理所管辖的代理商信息，需要注意的是，用户开通mis系统最好使用sogou邮箱，否则若使用搜狐邮箱，而该用户的搜狐邮箱前缀和搜狗邮箱前缀又不同，就必须修改代码来为该用户开通权限。2，角色缓存，系统使用了一个单例类来存储所有的用户信息，包括用户的搜狗邮箱前缀，角色，和所管辖的代理商、客户信息，每个用户的信息不只加载一遍，每个用户登录都会解析文件conf/specialUser和conf/csmap中的信息。3，页面控制，由于波动系统没有使用现存权限框架，对于页面上的元素需要自己实现授权，所以直接采用嵌入java代码，从session中获取用户的角色，根据用户角色判断是否有权访问某个页面的标签，若无权限，则直接不显示。4，渠道经理数据过滤，大区经理和渠道经理在页面上所看到的内容格式是一样，唯一差别在于他们所看到的数据量不同，渠道经理只能看到自己所管辖范围内的客户和代理商信息，而大区经理可以看到他管辖的所有渠道经理所管辖的客户和代理商信息，所以这一层数据的过滤在后台实现，波动系统从ADM处每小时获取当前渠道经理的信息，包括邮箱，管辖客户和代理商的id，角色，在调用接口时使用id信息过滤cdielog日志，然后再进行后续数据制作操作。5，权限拦截器，实现一个权限系统必须要有自己的拦截器，其流程为，用户登录在session中存入用户信息拦截器判断用户权限用户退出，清除session中用户信息。波动系统的session过期时间为2小时，在web.xml文件中配置。其登录和推出分别有login和logout类完成，拦截器由servlet来完成，拦截器的原理就是对用户的每一个http请求，都进行一次判断，波动系统没有使用web系统中通用的拦截器，直接对每个请求进行判断。3.2消耗报警3.2.1流程图3.2.2短信接口最终使用了sohu无线提供的长短信接口，接口的信息都在SendLongMessage.java中，这与我之前开发的普通短信接口不一样，普通短信接口是tcp协议的，长短信接口是http协议的，而且使用GET方式传递参数。3.2.3邮件接口邮件接口ADM组卢兆满同事给的，是一个基于spring框架的RMI接口，需要在波动系统中引入spring包和adm同事提供的接口封装jar包，然后配置applicationContext.xml文件，然后就可以调用，该接口支持普通文本和html格式，如果使用outlook接收该接口发出的邮件，会在邮件正文末尾有一个小图标，这是ADM同事用来统计邮件发送状态的。邮件发送后，不会返回成功，只会返回成功发送到ADM邮件服务器，ADM邮件服务器收到我们发送的邮件后，会放入邮件发送队列，这个邮件服务器会从队列中取出邮件，一个个发送给搜狗邮件服务器，然后发送给客户。4日常维护波动系统虽然交接到运营同学手中，但有些日常维护工作仍然需要开发人员参与。4.1添加用户添加用户的页面在；（user：admin，pwd：sogou-inc）用户权限分配方式分为两类：客服同学和非客服同学，两个页面来分别管理，客服同学只能对应到某个渠道经理上，非客服同学可以根据全体，大区，渠道经理来具体分配权限。添加用户的流程，adtech组内需要申请者发邮件抄送刚总，组外同学需要发邮件给开发人员并抄送马总和申请者所在组的组长。4.2代理商信息管理因为有每天给代理商发短信的需求，所以有了代理商的邮箱和手机号存储修改的需求，这个信息的维护在页面。4.3补发短信和邮件可能因为数据缺失的原因需要补发或者重发短信和邮件，该功能实现在页面；直接点击补发昨日或今日短信就可以补发昨日和今日的短信和邮件。4.4重做数据可能因为源数据不稳定，需要重做数据，或恢复数据，这个工作不是在线上进行，而是在线下机完成，然后由运营同学把数据rsync到线上。线下重做数据的脚本在目录/search/odin/CAData/script下，以tool开头的脚本都是用来重做数据的，只需要执行这个脚本，并在脚本后跟上相应的日期或小时数的变量。所有的线上问题都是线下恢复数据，然后rsync到线上，然后重启线上resin。几乎所有的问题都是由于数据不完整或格式不正确导致的，所以有问题时马上查看数据。4.4故障处理4.4.1程序bug目前程序bug只出现过一次，还是因为第三方数据不完整，从而导致潜在的空指针异常发生。数据格式不正确也有可能导致程序bug，比如程序如果本该是一个整型数字，却提供了一个字符串，就会导致类型转换异常的bug。4.4.2数据缺失数据缺失只要补齐数据，重启系统就可以了。5系统架构波动分析系统从结构上可以清晰地划分为如下三个层次：线下数据层、WEB后端层及WEB前端层。线下数据层周期性地从各个数据源抓取数据并经过一定程度的中间处理，生成中间日志文件。WEB后端层加载中间日志文件，并根据前端的请求，计算出全部数据结果，返回给前端。WEB前端层接受用户的请求，从后端获取请求的数据结果，并将数据渲染成用户最终看到的页面。5.1线下数据层的说明线下数据层的主体包含两部分：1.制作线下数据的SHELL脚本及运行于后台的cronjob，这些脚本大部分都周期性的运行，可在10.12.17.7上运行crontab–l查看具体运行设置。2.发送实时波动邮件的脚本。波动分析系统的核心数据来源是cdielog计费日志。但原始的cdielog首先比较大（每天接近一个G），再次含有一些波动分析系统中用不上的数据。因此，从内存使用及性能优化的角度考虑，波动分析系统并没有