优化从大数据集中提取文本

Question

我有一个反复出现的问题，我需要在日志文件中搜索与某个模式匹配的所有线程。例如以下

（线程a）blah blah (线程 b) blha (thread a) match blah （线程 c）等等等等 （线程 d）等等匹配 （线程 a）xxx

将从线程 a & d 生成所有行

有多个日志文件（压缩）。多个是数百或数千。每个未压缩文件最多可达 20MB。

我现在这样做的方法是首先在所有文件中grep“匹配”，将（线程x）部分切割成一个排序/uniq文件，然后在文件上使用fgrep与原始日志集上的匹配线程。

我已经在并行化初始 grep 和最终 grep。但是，这仍然很慢。

有没有办法提高这个工作负载的性能？ （我虽然是hadoop，但它需要太多的资源来设置/实现）

这是整个过程的脚本。

#!/bin/bash 文件=/tmp/thg.$$ PAT=1 美元 转移 陷阱“rm -f $文件”3 13 pargrep "$PAT" $@ | awk '{ 打印 $6 }' | sed 's/(\(.*\)):/\1/' |排序 |唯一的>$文件 pargrep --fgrep $FILE $@ rm -f $文件

并行 grep 是一个更长的脚本，它管理一个最多包含 N 个处理 M 个文件的 grep 进程的队列。每个 grep 进程都会生成一个中间文件（在 /dev/shm 或 /tmp - 一些内存文件系统中），然后在队列从任务中耗尽时将其连接起来。

今天我的工作站在一组约 3000 个文件上运行超过 24 小时后，我不得不重新启动它。我猜双 xeon 8GB 和 16GB 交换不适合这样的工作负载:-)

Answer 1

更新

为了并行解压缩和 grep 文件，请尝试使用 GNU Parallel 类似这样的东西：

parallel -j 8 -k --eta 'gzcat {} | grep something ' ::: *.gz 

原答案

嗯嗯......我看你没有得到任何答案，所以我会伸出我的脖子试一试。我没有对此进行测试，因为我周围没有多少 GB 的空闲数据...

首先，我会对脚本进行基准测试，看看是什么占用了时间。具体来说，是初始grep阶段，还是awk|sed|sort|uniq阶段？

我会删除sort|uniq，因为我怀疑对多个 GB 进行排序会占用您的时间。如果是这种情况，可以尝试将 sort|uniq 替换为 awk，如下所示：

pargrep ... | ... | awk '!seen[$0]++'

它只会在第一次出现时打印每一行，而不需要对整个文件进行排序。

如果做不到这一点，我认为您需要对各个阶段的时间进行基准测试并进行报告。此外，您应该考虑发布您的pargrep 代码，因为这可能是瓶颈。另外，您是否考虑过在这部分使用 GNU Parallel？