在 256G 的巨大的二进制文件中匹配二进制子串，这适合交给 Hadoop 吗？谢

vivid

2014 年 12 月 25 日

fgrep 很快的。昨天在一个100G的大文件中查找也不慢啊。
有上传这会,早结束了。

aheadlead

2014 年 12 月 25 日

@vivid 如果是对查询要求1分钟内返回呢...我这机器多

hahastudio

2014 年 12 月 25 日

不适合吧？
因为这个大文件你不能拆，在分发的时候就不好办
如果刚好匹配结果被拆到两个分片呢？
而且网络里传这个整块的大文件也会是噩梦= =

不知道你是在什么场景下要做这件事情，试试其他的方案？不要匹配二进制子串呢？

aheadlead

2014 年 12 月 25 日

@hahastudio 这个大文件每台机器都有..

aheadlead

2014 年 12 月 25 日

@hahastudio 匹配时分片可以有一定重合哇。
重合的距离是关键词（用的ac自动机）最长的长度减一

hicdn

2014 年 12 月 25 日

你首先得解决在文件切割时你的目标字符串不被截断问题

aheadlead

2014 年 12 月 25 日

@vivid 另外grep似乎不适合多字符串匹配

jerry2014

2014 年 12 月 25 日

可以写个配置文件，指定不同偏移量，然后把配置文件提交给Hadoop。。。

aheadlead

2014 年 12 月 25 日

@jerry2014 请推荐一个hadoop快速入门指南感谢🙏

hahastudio

2014 年 12 月 25 日

@aheadlead 那都有的话其实也算好办啊
你分发的就是分片的头尾，你已经想清楚头尾了啊

其实我觉得这个场景连 hadoop 都不用，自己写一个简单的 master/slave，slave 就接受要搜索的范围和搜索内容，把结果返回给 master 就行了= =

aheadlead

2014 年 12 月 25 日

@hahastudio 有现成的工具吗..我已经在自己写了...但是最近考试太多...希望能尽快搞定

vivid

2014 年 12 月 25 日

@aheadlead 频繁使用
1) 上传文件到hdfs
2) 用bash + hadoop stream 尝试，机器多 1分钟内绝对可以完成的啊

icedx

2014 年 12 月 25 日

@aheadlead 米有然后你可以试着用缓存...

weikey

2014 年 12 月 25 日

一次性的就没必要搭集群啦，常用的机器多，可考虑spark

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.