剛下完班的時候,在公司無聊的坐着,一位同事拿了一些數據給我,說讓我實現一個類似交叉表格的統計報表。
源數據就是個日誌文本信息
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
要的結果是統計一下,各時段對應的超時毫秒的數量
理論上也不復雜,能找出數據規律,進行分組統計而已,但問題在於:
首先統計是上下文相關的,即通過上下文的數據相計算才能獲取到相應的指標
其次如何判斷上下文的場景,根據幾組字段判斷都有問題,即得不到唯一的標示
原來想着應該是輕而易舉的事情,先把數據導入oracle吧
有日期有時間,需要把文本的日期時間處理成oracle的date類型,可偏偏date類型不支持毫秒運算,第一個問題出來了,依賴於日誌中已有的毫秒進行上下文計算又有一定的問題。
先統計了再說吧
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
結果統計出來了,結果非預期的,又對幾條數據進行了統計和明細的對比,發現確實有些小問題,可問題出在哪裏,也說不清楚。
爲了解釋清楚這個問題,還是對數據加上行號吧,再次進行對比,發現數據的位置變化了,和原本的日誌順序是不一樣的。
爲了解決這個問題,還是用rownum加上表數據生成到另外一張測試表吧,再去看看行號和日誌的順序是否能夠對應,卻發現日誌的插入順序和行號是不一致的!
又問了下同事,業務邏輯到底是怎樣的,答曰:日誌中上下文的順序是很嚴格的
看來需要徹底解決行號問題了。
又在Excel中做了一下測試,Excel做測試很容易,先獲取上條記錄的毫秒信息,再進行排序,再把數據進行篩選,然後再進行分組判斷,最後進行交叉表的生成。
對應大數據量來說,Excel的拖拉顯然就滿了很多,其次還需要函數、排序、複製數據,總的來說還是比較耗時的。
還是想想怎麼解決行號問題吧,確保行號就是數據的原始順序,首先加了一個sequence,後來又在該表中增加了一個觸發器,然後把數據重新導入一遍
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;
再去驗證數據的順序,這次纔算正常了
數據正常了,業務邏輯就簡單多了,只需要把最內核的部分修改一下,按行號排序即可
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
統計完成後,再拷貝到Excel中進行數據透視錶轉換,再把表格數據拷貝出來,加一些美觀信息即可。
該件事情還是沒有得到完美解決
主要是毫秒的處理,理論上是時間的直接相減即可,可由於Oracle的date類型無法直接處理,只能採用日誌中的毫秒字段進行相減了,碰到相減爲負的,則再加回來1000,多少有些問題。
再其次, oracle導入時的數據順序有問題,不過我想也許是我自己還沒找解決問題的根本原因吧。