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

我原以為是最多十幾分鐘就搞定的事情，沒想到花了2個小時，所以印象比較深，就把全過程記錄了下來

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

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

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

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

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

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

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

有日期有時間，需要把文本的日期時間處理成oracle的date類型，可偏偏date類型不支持毫秒運算，第一個問題出來了，依賴于日志中已有的毫秒進行上下文計算又有一定的問題。

先統(tǒng)計了再說吧

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,dORDER BY B,g) lastc, 
       LAG(b, 1, 0) OVER (partition by f,dORDER 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 
  fromtest6 t  
) a 
where a.g='ToFront()=TRUE' anda.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)計出來了，結(jié)果非預(yù)期的，又對幾條數(shù)據(jù)進行了統(tǒng)計和明細的對比，發(fā)現(xiàn)確實有些小問題，可問題出在哪里，也說不清楚。

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

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

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

看來需要徹底解決行號問題了。

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

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

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; 

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

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

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)計完成后，再拷貝到Excel中進行數(shù)據(jù)透視表轉(zhuǎn)換，再把表格數(shù)據(jù)拷貝出來，加一些美觀信息即可。

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

主要是毫秒的處理，理論上是時間的直接相減即可，可由于Oracle的date類型無法直接處理，只能采用日志中的毫秒字段進行相減了，碰到相減為負的，則再加回來1000，多少有些問題。

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

【編輯推薦】

1. 淺析數(shù)據(jù)倉庫設(shè)備趨勢：聚焦BI，細分市場
2. 加快數(shù)據(jù)倉庫加載無需添加硬件的解決方法
3. SQL Server數(shù)據(jù)挖掘之理解聚類算法和順序聚類算法
4. SQL Server數(shù)據(jù)挖掘中的幾個問題之理解列的用法
5. SQL Server數(shù)據(jù)挖掘中的幾個問題之理解內(nèi)容類型