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

 

移植所帶來的問題是各處依賴包，和各種api不兼容。沒關系，我可以看一下源碼，然后自己寫一個。細看了一下reader的代碼，發現mapreduce使用了BufferedInputStream的mark，reset來尋找XML的tag，這個tag就是我們在提交作業所設置的，比如<log>，</log>這樣的標簽。Java中stream流的mark和reset，允許指針回讀，即在找到<log>時，mark一下指針，然后再找到</log>標簽，最后通過reset方法，返回到mark的位置，把<log></log>內的數據讀取出來。但在匹配的過程中，我發現mapred使用了BufferedInputStream 的 read(); 方法，該方法返回下一個可讀的字節。那么整個處理過程就是讀一個字節，比較一個字節，我沒有在mapreduce中用這樣的算法，但我測試過，向緩沖區（BufferedInputStream）中一個字節一個字節的讀，性能嚴重不足，read(); 方法平均返回時間在331納秒，處理一個170M的xml文檔（tag比較多），竟然花了200+秒。（streaming模塊還寫了一個faster*方法，哎，慢死了）

 

周敏同學提供了pig中處理xml的reader，但pig那邊的代碼我還沒細看，也不知道hadoop的jira中有沒有新的feature來解決現有xml的問題。如果有的話，不防可以告訴我一下下。呵呵。 

 

現在有一個構思，即主要思想仍然圍繞字節比較，因為字符串匹配效率更低，另外算法源于String.indexOf(“”)，即找到<log>這個后，記住位置，然后再找</log>，這樣算完全匹配，中間的內容用system.arraycopy來復制到新的字節數組，目前這算法我實現了一半，即找到<log>和</log>后，把這兩個簽標全部替換掉，170M文檔，用時2.2秒（最快1.3秒）。

 

算法及問題：

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