记一次数据分析的全过程

运维 数据库运维
刚下完班的时候,在公司无聊的坐着,一位同事拿了一些数据给我,说让我实现一个类似交叉表格的统计报表。我原以为是最多十几分钟就搞定的事情,没想到花了2个小时,所以印象比较深,就把全过程记录了下来。

刚下完班的时候,在公司无聊的坐着,一位同事拿了一些数据给我,说让我实现一个类似交叉表格的统计报表。

我原以为是最多十几分钟就搞定的事情,没想到花了2个小时,所以印象比较深,就把全过程记录了下来

源数据就是个日志文本信息

  1. 2008/1/11               02:14:33:181           181          00001c68                SeqID       418370    ToBack()=TRUE       Len=154  MsgID=x00000202                  
  2.  
  3. 2008/1/11               02:14:33:181           181          00001c68                SeqID       418370    ToFront()=TRUE      Len=260  MsgID=x08000202                BEIP=192.168.1.162                BEPort=22049 
  4.  
  5. 2008/1/11               03:05:42:330           330          00004110                SeqID       418370    ToBack()=TRUE       Len=154  MsgID=x00000202                  
  6.  
  7. 2008/1/11               03:05:42:346           346          00004110                SeqID       418370    ToFront()=TRUE      Len=261  MsgID=x08000202                BEIP=192.168.1.163                BEPort=22049 

要的结果是统计一下,各时段对应的超时毫秒的数量

理论上也不复杂,能找出数据规律,进行分组统计而已,但问题在于:

首先统计是上下文相关的,即通过上下文的数据相计算才能获取到相应的指标

其次如何判断上下文的场景,根据几组字段判断都有问题,即得不到唯一的标示

原来想着应该是轻而易举的事情,先把数据导入oracle吧

有日期有时间,需要把文本的日期时间处理成oracle的date类型,可偏偏date类型不支持毫秒运算,第一个问题出来了,依赖于日志中已有的毫秒进行上下文计算又有一定的问题。

先统计了再说吧

  1. select b.hours, 
  2. case when overlap<10 then '<10ms' 
  3.      when overlap<20 then '10-20' 
  4.      when overlap<30 then '20-30' 
  5.      when overlap<40 then '30-40' 
  6.      when overlap<50 then '40-50' 
  7.      when overlap<60 then '50-60'       
  8.      when overlap<70 then '60-70' 
  9.      when overlap<80 then '70-80' 
  10.      when overlap<90 then '80-90'   
  11.      else '>90ms' 
  12. end tt, 
  13. count(*) 
  14. from 
  15. select a.f,a.d from 
  16. select k,a,b,f,d,g,c, 
  17.        LAG(c, 1, 0) OVER (partition by f,dORDER BY B,g) lastc, 
  18.        LAG(b, 1, 0) OVER (partition by f,dORDER BY B,g) lastb, 
  19.        case when c - LAG(c, 1, 0) OVER (ORDER BY tt)>=0 then c - LAG(c, 1, 0) OVER (ORDER BY tt) 
  20.         else  c - LAG(c, 1, 0) OVER (ORDER BY tt)+1000 end aa 
  21.   fromtest6 t  
  22. ) a 
  23. where a.g='ToFront()=TRUE' anda.aa>90 ) 
  24. order by f,d,b,g 
  25. ) b 
  26. group by b.hours, 
  27. case when overlap<10 then '<10ms' 
  28.      when overlap<20 then '10-20' 
  29.      when overlap<30 then '20-30' 
  30.      when overlap<40 then '30-40' 
  31.      when overlap<50 then '40-50' 
  32.      when overlap<60 then '50-60'       
  33.      when overlap<70 then '60-70' 
  34.      when overlap<80 then '70-80' 
  35.      when overlap<90 then '80-90'   
  36.      else '>90ms' 
  37. end 

结果统计出来了,结果非预期的,又对几条数据进行了统计和明细的对比,发现确实有些小问题,可问题出在哪里,也说不清楚。

为了解释清楚这个问题,还是对数据加上行号吧,再次进行对比,发现数据的位置变化了,和原本的日志顺序是不一样的。

为了解决这个问题,还是用rownum加上表数据生成到另外一张测试表吧,再去看看行号和日志的顺序是否能够对应,却发现日志的插入顺序和行号是不一致的!

又问了下同事,业务逻辑到底是怎样的,答曰:日志中上下文的顺序是很严格的

看来需要彻底解决行号问题了。

又在Excel中做了一下测试,Excel做测试很容易,先获取上条记录的毫秒信息,再进行排序,再把数据进行筛选,然后再进行分组判断,最后进行交叉表的生成。

对应大数据量来说,Excel的拖拉显然就满了很多,其次还需要函数、排序、复制数据,总的来说还是比较耗时的。

  1. create or replace trigger trigger_test6 
  2.   before insert on test6  
  3.   for each row 
  4. declare 
  5. begin 
  6.   select tt.nextval into :new.tt from dual; 
  7. end trigger_test6; 

再去验证数据的顺序,这次才算正常了

数据正常了,业务逻辑就简单多了,只需要把最内核的部分修改一下,按行号排序即可

  1. select rr,k,a,b,f,d,g,c, 
  2.        LAG(c, 1, 0) OVER (ORDER BY tt)lastc, 
  3.        LAG(b, 1, 0) OVER (ORDER BY tt)lastb      
  4.   from test6 t  

统计完成后,再拷贝到Excel中进行数据透视表转换,再把表格数据拷贝出来,加一些美观信息即可。

该件事情还是没有得到完美解决

主要是毫秒的处理,理论上是时间的直接相减即可,可由于Oracle的date类型无法直接处理,只能采用日志中的毫秒字段进行相减了,碰到相减为负的,则再加回来1000,多少有些问题。

再其次,oracle导入时的数据顺序有问题,不过我想也许是我自己还没找解决问题的根本原因吧。

【编辑推荐】

  1. 浅析数据仓库设备趋势:聚焦BI,细分市场
  2. 加快数据仓库加载无需添加硬件的解决方法
  3. SQL Server数据挖掘之理解聚类算法和顺序聚类算法
  4. SQL Server数据挖掘中的几个问题之理解列的用法
  5. SQL Server数据挖掘中的几个问题之理解内容类型

 

 

责任编辑:艾婧 来源: baoqiangwang的博客
相关推荐

2019-06-11 09:23:38

2021-02-11 14:06:38

Linux内核内存

2012-11-06 10:19:18

Java自定义加载Java类

2011-04-18 15:56:10

软件测试

2011-02-22 10:46:02

Samba配置

2021-10-14 10:53:20

数据库查询超时

2017-09-22 10:16:16

MySQL数据库用户数据

2019-08-26 09:50:09

2017-12-19 14:00:16

数据库MySQL死锁排查

2023-10-10 12:05:45

2020-04-08 16:14:50

Python数据可视化

2009-12-08 17:56:16

WCF配置

2009-04-13 12:37:18

2011-01-21 17:51:52

2011-09-06 15:38:20

QT安装

2024-08-27 08:00:00

2021-08-19 09:50:53

Java内存泄漏

2021-11-23 21:21:07

线上排查服务

2010-06-11 13:15:07

UML软件

2017-04-25 18:03:11

Caffe深度学习框架
点赞
收藏

51CTO技术栈公众号