MapReduce 解析XML算法的一点构思

没想到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的大小。

posted on 2011-12-21 21:15 Ric Dong 阅读(265) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2022年8月>
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910

导航

统计

留言簿

文章档案(2)

搜索

最新评论