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

[aheadlead]

[vivid]

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

[icedx]

不适合...

[aheadlead]

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

[aheadlead]

@icedx 有啥简单的解决方案吗

[hahastudio]

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

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

[aheadlead]

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

[aheadlead]

@hahastudio 场景：折腾

[aheadlead]

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

[hicdn]

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

[aheadlead]

@hicdn 见8楼

[aheadlead]

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

[jerry2014]

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

[aheadlead]

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

[hahastudio]

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

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

[aheadlead]

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

[vivid]

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

[icedx]

让每台机器从不同的位置读…

[aheadlead]

@icedx 有现成的轮子吗？

[icedx]

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

[weikey]

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