沒(méi)想到Hadoop在解析XML時(shí)如此糾結(jié)，以至于新版api的mapreduce竟然放棄了XML格式的format以及reader，在老版（hadoop-0.19.*）的streaming模塊提供了這樣的api，由于我用的hadoop-0.20.2 3U1版本，因此需要把處理XML的幾個(gè)類(lèi)移植過(guò)來(lái)使用。

 

移植所帶來(lái)的問(wèn)題是各處依賴(lài)包，和各種api不兼容。沒(méi)關(guān)系，我可以看一下源碼，然后自己寫(xiě)一個(gè)。細(xì)看了一下reader的代碼，發(fā)現(xiàn)mapreduce使用了BufferedInputStream的mark，reset來(lái)尋找XML的tag，這個(gè)tag就是我們?cè)谔峤蛔鳂I(yè)所設(shè)置的，比如<log>，</log>這樣的標(biāo)簽。Java中stream流的mark和reset，允許指針回讀，即在找到<log>時(shí)，mark一下指針，然后再找到</log>標(biāo)簽，最后通過(guò)reset方法，返回到mark的位置，把<log></log>內(nèi)的數(shù)據(jù)讀取出來(lái)。但在匹配的過(guò)程中，我發(fā)現(xiàn)mapred使用了BufferedInputStream 的 read(); 方法，該方法返回下一個(gè)可讀的字節(jié)。那么整個(gè)處理過(guò)程就是讀一個(gè)字節(jié)，比較一個(gè)字節(jié)，我沒(méi)有在mapreduce中用這樣的算法，但我測(cè)試過(guò)，向緩沖區(qū)（BufferedInputStream）中一個(gè)字節(jié)一個(gè)字節(jié)的讀，性能?chē)?yán)重不足，read(); 方法平均返回時(shí)間在331納秒，處理一個(gè)170M的xml文檔（tag比較多），竟然花了200+秒。（streaming模塊還寫(xiě)了一個(gè)faster*方法，哎，慢死了）

 

周敏同學(xué)提供了pig中處理xml的reader，但pig那邊的代碼我還沒(méi)細(xì)看，也不知道hadoop的jira中有沒(méi)有新的feature來(lái)解決現(xiàn)有xml的問(wèn)題。如果有的話(huà)，不防可以告訴我一下下。呵呵。 

 

現(xiàn)在有一個(gè)構(gòu)思，即主要思想仍然圍繞字節(jié)比較，因?yàn)樽址ヅ湫矢?，另外算法源于String.indexOf(“”)，即找到<log>這個(gè)后，記住位置，然后再找</log>，這樣算完全匹配，中間的內(nèi)容用system.arraycopy來(lái)復(fù)制到新的字節(jié)數(shù)組，目前這算法我實(shí)現(xiàn)了一半，即找到<log>和</log>后，把這兩個(gè)簽標(biāo)全部替換掉，170M文檔，用時(shí)2.2秒（最快1.3秒）。

 

算法及問(wèn)題：

首先提供一個(gè)BufferedInputStream，默認(rèn)大小8k，在程序中建一個(gè)字節(jié)數(shù)組，大小為4k，即每次向BufferedInputStream讀4k，這個(gè)效率是很不錯(cuò)的，然后去尋找<log>.toArray這樣的字節(jié)數(shù)組，這一步速度是很驚人的。但這里有一個(gè)小的問(wèn)題，即每次讀4k的大小去處理，那很有可能<log></log>位于兩次讀取的一尾一頭，那么我的想法是做一個(gè)半循環(huán)的字節(jié)數(shù)組，即如果在4k的字節(jié)數(shù)組中的最后找到<log>，那么就把前面未匹配的仍掉，然后把<log>標(biāo)簽移到字節(jié)數(shù)組最前端，然后另用這個(gè)字節(jié)數(shù)組再向BufferedInputStream中去讀4k-5長(zhǎng)度的內(nèi)容（5是<log>的字節(jié)長(zhǎng)度）。關(guān)于4k這個(gè)大小，首先要對(duì)XML數(shù)據(jù)進(jìn)行sampling，即確定<log></log>當(dāng)中的內(nèi)容長(zhǎng)度，然后再定這個(gè)緩沖buf的大小。