一次數(shù)據(jù)分析的全過(guò)程

剛下完班的時(shí)候，在公司無(wú)聊的坐著，一位同事拿了一些數(shù)據(jù)給我，說(shuō)讓我實(shí)現(xiàn)一個(gè)類似交叉表格的統(tǒng)計(jì)報(bào)表。

我原以為是最多十幾分鐘就搞定的事情，沒想到花了2個(gè)小時(shí)，所以印象比較深，就把全過(guò)程記錄了下來(lái)

源數(shù)據(jù)就是個(gè)日志文本信息

要的結(jié)果是統(tǒng)計(jì)一下，各時(shí)段對(duì)應(yīng)的超時(shí)毫秒的數(shù)量

理論上也不復(fù)雜，能找出數(shù)據(jù)規(guī)律，進(jìn)行分組統(tǒng)計(jì)而已，但問(wèn)題在于：

首先統(tǒng)計(jì)是上下文相關(guān)的，即通過(guò)上下文的數(shù)據(jù)相計(jì)算才能獲取到相應(yīng)的指標(biāo)

其次如何判斷上下文的場(chǎng)景，根據(jù)幾組字段判斷都有問(wèn)題，即得不到唯一的標(biāo)示

原來(lái)想著應(yīng)該是輕而易舉的事情，先把數(shù)據(jù)導(dǎo)入oracle吧

有日期有時(shí)間，需要把文本的日期時(shí)間處理成oracle的date類型，可偏偏date類型不支持毫秒運(yùn)算，第一個(gè)問(wèn)題出來(lái)了，依賴于日志中已有的毫秒進(jìn)行上下文計(jì)算又有一定的問(wèn)題。

先統(tǒng)計(jì)了再說(shuō)吧

select b.hours,

case when overlap<10 then '<10ms'

when overlap<20 then '10-20'

when overlap<30 then '20-30'

when overlap<40 then '30-40'

when overlap<50 then '40-50'

when overlap<60 then '50-60'      

when overlap<70 then '60-70'

when overlap<80 then '70-80'

when overlap<90 then '80-90'  

else '>90ms'

end tt,

count(*)

from

(

select a.f,a.d from

(

select k,a,b,f,d,g,c,

LAG(c, 1, 0) OVER (partition by f,d ORDER BY B,g) lastc,

LAG(b, 1, 0) OVER (partition by f,d ORDER BY B,g) lastb,

case when c - LAG(c, 1, 0) OVER (ORDER BY tt)>=0  then c - LAG(c, 1, 0) OVER (ORDER BY tt)

else  c - LAG(c, 1, 0) OVER (ORDER BY tt)+1000 end aa

from test6 t 

) a

where a.g='ToFront()=TRUE' and a.aa>90 )

order by f,d,b,g

) b

group by b.hours,

case when overlap<10 then '<10ms'

when overlap<20 then '10-20'

when overlap<30 then '20-30'

when overlap<40 then '30-40'

when overlap<50 then '40-50'

when overlap<60 then '50-60'      

when overlap<70 then '60-70'

when overlap<80 then '70-80'

when overlap<90 then '80-90'  

else '>90ms'

end

結(jié)果統(tǒng)計(jì)出來(lái)了，結(jié)果非預(yù)期的，又對(duì)幾條數(shù)據(jù)進(jìn)行了統(tǒng)計(jì)和明細(xì)的對(duì)比，發(fā)現(xiàn)確實(shí)有些小問(wèn)題，可問(wèn)題出在哪里，也說(shuō)不清楚。

為了解釋清楚這個(gè)問(wèn)題，還是對(duì)數(shù)據(jù)加上行號(hào)吧，再次進(jìn)行對(duì)比，發(fā)現(xiàn)數(shù)據(jù)的位置變化了，和原本的日志順序是不一樣的。

為了解決這個(gè)問(wèn)題，還是用rownum加上表數(shù)據(jù)生成到另外一張測(cè)試表吧，再去看看行號(hào)和日志的順序是否能夠?qū)?yīng)，卻發(fā)現(xiàn)日志的插入順序和行號(hào)是不一致的！

又問(wèn)了下同事，業(yè)務(wù)邏輯到底是怎樣的，答曰：日志中上下文的順序是很嚴(yán)格的

看來(lái)需要徹底解決行號(hào)問(wèn)題了。

又在Excel中做了一下測(cè)試，Excel做測(cè)試很容易，先獲取上條記錄的毫秒信息，再進(jìn)行排序，再把數(shù)據(jù)進(jìn)行篩選，然后再進(jìn)行分組判斷，最后進(jìn)行交叉表的生成。

對(duì)應(yīng)大數(shù)據(jù)量來(lái)說(shuō)，Excel的拖拉顯然就滿了很多，其次還需要函數(shù)、排序、復(fù)制數(shù)據(jù)，總的來(lái)說(shuō)還是比較耗時(shí)的。

還是想想怎么解決行號(hào)問(wèn)題吧，確保行號(hào)就是數(shù)據(jù)的原始順序，首先加了一個(gè)sequence，后來(lái)又在該表中增加了一個(gè)觸發(fā)器，然后把數(shù)據(jù)重新導(dǎo)入一遍

create or replace trigger trigger_test6

before insert on test6 

for each row

declare

begin

select tt.nextval into :new.tt from dual;

end trigger_test6;

再去驗(yàn)證數(shù)據(jù)的順序，這次才算正常了

數(shù)據(jù)正常了，業(yè)務(wù)邏輯就簡(jiǎn)單多了，只需要把最內(nèi)核的部分修改一下，按行號(hào)排序即可

select rr,k,a,b,f,d,g,c,

LAG(c, 1, 0) OVER (ORDER BY tt) lastc,

LAG(b, 1, 0) OVER (ORDER BY tt) lastb     

from test6 t

統(tǒng)計(jì)完成后，再拷貝到Excel中進(jìn)行數(shù)據(jù)透視表轉(zhuǎn)換，再把表格數(shù)據(jù)拷貝出來(lái)，加一些美觀信息即可。

該件事情還是沒有得到完美解決

主要是毫秒的處理，理論上是時(shí)間的直接相減即可，可由于Oracle的date類型無(wú)法直接處理，只能采用日志中的毫秒字段進(jìn)行相減了，碰到相減為負(fù)的，則再加回來(lái)1000，多少有些問(wèn)題。

再其次， oracle導(dǎo)入時(shí)的數(shù)據(jù)順序有問(wèn)題，不過(guò)我想也許是我自己還沒找解決問(wèn)題的根本原因吧。