在 256G 的巨大的二进制文件中匹配二进制子串，这适合交给 Hadoop 吗？谢
aheadlead 2014-12-25 10:45:30 +08:00 4046 次点击这是一个创建于 3945 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 1 vivid 2014-12-25 10:51:11 +08:00  1 fgrep 很快的 。昨天在一个100G的大文件中查找 也不慢啊。 有上传这会,早结束了。 |
 | 2 icedx 2014-12-25 10:52:19 +08:00 via Android 1 不适合... |
 | 5 hahastudio 2014-12-25 10:59:23 +08:00 1 不适合吧？ 因为这个大文件你不能拆，在分发的时候就不好办 如果刚好匹配结果被拆到两个分片呢？ 而且网络里传这个整块的大文件也会是噩梦= = 不知道你是在什么场景下要做这件事情，试试其他的方案？不要匹配二进制子串呢？ |
 | 6 aheadlead OP @hahastudio 这个大文件每台机器都有.. |
| 7 OP @hahastudio 场景：折腾 |
| 8 aheadlead OP @hahastudio 匹配时分片可以有一定重合哇。 重合的距离是关键词（用的ac自动机）最长的长度减一 |
 | 9 hicdn 2014-12-25 11:02:02 +08:00 1 你首先得解决在文件切割时你的目标字符串不被截断问题 |
 | 12 jerry2014 2014-12-25 11:06:16 +08:00 1 可以写个配置文件，指定不同偏移量，然后把配置文件提交给Hadoop。。。 |
| 14 hahastudio 2014-12-25 11:08:55 +08:00  1 @aheadlead 那都有的话其实也算好办啊 你分发的就是分片的头尾，你已经想清楚头尾了啊 其实我觉得这个场景连 hadoop 都不用，自己写一个简单的 master/slave，slave 就接受要搜索的范围和搜索内容，把结果返回给 master 就行了= = |
| 15 aheadlead OP @hahastudio 有现成的工具吗..我已经在自己写了...但是最近考试太多...希望能尽快搞定 |
| 16 vivid 2014-12-25 11:14:59 +08:00 |
| 17 icedx 2014-12-25 11:52:41 +08:00 via Android 让每台机器从不同的位置读… |
 | 20 weikey 2014-12-25 12:43:55 +08:00 via iPhone 一次性的就没必要搭集群啦，常用的机器多，可考虑spark |
Select Language