介绍
当我在浏览网页关注一些我定期访问网站的更新时，我发现Tom Hayden的一篇很酷的文章，使用Amazon Elastic Map Reduce（EMR）和mrjob，以计算从millionbase archive下载的象棋游戏的输赢率，慢慢地从中发现乐趣。由于数据量仅约为1.75GB，含200万左右的国际象棋游戏，我不确定他为何使用Hadoop，但我能理解他的目标，从mrjob和EMR中学习并获得乐趣。既然问题基本上只是看每个文件的resultl lines和汇总不同的结果，似乎非常适合shell命令的流处理。我试着用相同的数据量处理，我的笔记本电脑得到结果只需12秒左右（处理速度约为270MB /秒），而Hadoop处理了约26分钟（处理速度约1.14MB /秒）。
在报告用7 c1. machine在集群中处理数据所需要的时间为26分钟，汤姆写到：“这可能比在我的机器上按顺序运行快，但如果我做了一些聪明的本地多线程应用程序可能更好。”
这是绝对正确的，但即使串行处理可以击败26分钟。虽然汤姆只是为了娱乐在做项目，人们往往使用Hadoop和其他所谓的大数据（TM）工具来做实世界的处理和分析工作，其实这些工作可以用更简单的工具和不同的技术做得更快。
其中尤其未充分利用是使用标准的shell工具和命令进行数据处理的方法。这种方法的好处是大量的，因为通过shell命令创建一个数据管道意味着所有的处理步骤可以并行完成。这基本上就像在本地计算机上拥有你自己的风暴集群。甚至喷口，螺栓，和水槽的概念转移至壳管和它们之间的命令。你可以很容易地用基本的命令构造相比许多现代大数据（TM）工具有表现更出色的流处理管道。
另外一点是批处理与流分析方法的比较。汤姆在开头提到在装载10000个游戏，并在本地做了分析后，他的内存有些紧缺。这是因为所有的游戏数据被加载到RAM用于分析。但是这个问题可以很容易地通过流媒体分析解决，因为它基本不占内存。我们创建的流处理管道会比Hadoop的实施快235倍以上，并基本不使用内存。
了解数据
在管道中的第一步是从PGN文件中获取数据的。因为我不知道这是什么样的格式，我搜索了维基百科。
[Event "F/S Return Match"] [Site "Belgrade, Serbia Yugoslavia|JUG"] [Date "1992.11.04"] [Round "29"] [White "Fischer, Robert J."] [Black "Spassky, Boris V."] [Result "1/2-1/2"] (moves from the game follow...)
我们只关心比赛的结果，其中只有3个实际结果。在1-0的情况下是指白色赢了，0-1的情况下是指黑色赢，1 / 2-1 / 2的情况说明比赛是一场平局。还有a- 的情况说明比赛正在进行或无法得分，但我们因为我们的目的忽略它。
采集样本数据
要做的第一件事是获取很多游戏数据。这实际比我想象的更加困难，但在网上看了会儿之后，我在从rozim发现GitHub上的一个git repository有大量的游戏。我用这个编译一组3.46GB的数据，约汤姆测试的两倍。下一步是把所有的数据放到我们的管道。
建立一个处理管道
如果你照着操作并计时你的处理，别忘了清除你的操作系统的页面缓存，否则你的处理时间是无效的。
shell命令对于数据处理管道很好，因为你免费获得并行。为了证明这一点，在你的终端尝试一个简单的例子。
sleep 3 | echo "Hello world."
它可能看起来是上面的会睡3秒钟，然后打印出“Hello World”的，但实际上这两个步骤都在同一时间完成。这一基本事实就是shell命令能够为一种能在单个计算机上运行的简单的非IO结合的处理系统极大的加速的原因。
在开始分析管道之前，先来看一下它到底有多快的参考值，我们可以简单地转储数据到/ dev / null。
在这种情况下，大约需要13秒经过3.46GB，约272MB /秒。这显示了在该系统上数据处理的上限，由于IO约束处理。
现在，我们可以开始分析管道，第一步是使用cat来生成数据流。
cat *.pgn
由于只有result lines在文件中是有趣的，我们可以简单地扫一遍所有的数据文件，并挑选出含有“Result”中有grep的。
cat *.pgn | grep "Result"
这将使我们只能从文件得到Result lines。如果我们愿意，我们可以简单地使用sort和uniq命令，以获得的文件中的所有独特项目的列表以及它们的计数。
cat *.pgn | grep "Result" | sort | uniq -c
这是一个非常简单明了的分析管道，并且使我们在大约70秒得到结果。相比较Hadoop集群，假设线性缩放这些，需要约52分钟处理。
为了进一步降低速度，我们可以从管道中拿出sort | uniq的步骤，并将它们用AWK代替，AWK是一个基于事件的数据处理的奇妙的工具/语言。
cat *.pgn | grep "Result" | awk '{ split($0, a, "-"); res = substr(a[1], length(a[1]), 1); if (res == 1) white++; if (res == 0) black++; if (res == 2) draw++;} END { print white+black+draw, white, black, draw }'
这将需要记录每个结果，用连字符分割它，并立即将字符放到左侧，即一个0表示黑色赢一次，一个1表示白色赢一次，一个2表示平局。注意$0是一个内置的变量，它表示整个记录。
这将运行时间约减少到65秒，因为我们正在处理两倍的数据，这是大约47倍的加速。
因此，单在这一点上，我们用一个天真的本地解决方案已经有大约47的加速。此外，内存使用情况是零，因为唯一的存储数据是实际计数，而且递增的3整数几乎不占内存空间。然而在运行中htop显示，grep是目前单个CPU核心充分使用遭遇的瓶颈。
并行化瓶颈
未使用的核心这个问题可以是用出色的xargs命令解决，这将使我们能够并行化的grep。由于xargs预期以某种特定的方式输入，使用find与-print0参数会更安全和容易，以确保每个被传递给xargs的文件名是空值终止。相应-0的显示xargs预期空值终止输入。此外，-n表示给每个过程投入多少，-P表示并行运行的进程数。同样重要的是，这样的并行流水线不保证传递顺序，如果你习惯用分布式处理系统，这就不是一个问题。该grep的-F表示我们只是在匹配固定字符串并没有做任何花哨的正则表达式，并能提供一个小的加速，这是我在测试中没有注意到的。
find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk '{ split($0, a, "-"); res = substr(a[1], length(a[1]), 1); if (res == 1) white++; if (res == 0) black++; if (res == 2) draw++;} END { print NR, white, black, draw }'
这个结果运行约38秒，这是一个额外的40％左右的降低在管道中并行grep工序的处理时间。这会让我们比Hadoop快约77倍。
虽然我们已经通过在我们的管道上并行grep步骤显着改善性能，我们实际上可以完全用AWK过滤输入记录（在此情况中是lines），并且只在那些包含字符串“Result”操作来删除整个步骤。
find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 awk '/Result/ { split($0, a, "-"); res = substr(a[1], length(a[1]), 1); if (res == 1) white++; if (res == 0) black++; if (res == 2) draw++;} END { print white+black+draw, white, black, draw }'
你可能认为这是正确的解决方案，但是这将输出每个文件的个别结果，当我们想将它们聚集在一起时。由此产生的正确应用在概念上MapReduce的应用非常相似。
time find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 awk '/Result/ { split($0, a, "-"); res = substr(a[1], length(a[1]), 1); if (res == 1) white++; if (res == 0) black++; if (res == 2) draw++ } END { print white+black+draw, white, black, draw }' | awk '{games += $1; white += $2; black += $3; draw += $4; } END { print games, white, black, draw }'
通过将第二个AWK的步骤加在最后，我们获得了需要的汇总的游戏信息。
这进一步显著地提高了速度，达到约18秒的运行时间，即约Hadoop的174倍。
不过，我们仍可以用mawk让它更快一点，这往往完全取代gawk，可以提供更好的表现。
find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk '/Result/ { split($0, a, "-"); res = substr(a[1], length(a[1]), 1); if (res == 1) white++; if (res == 0) black++; if (res == 2) draw++ } END { print white+black+draw, white, black, draw }' | mawk '{games += $1; white += $2; black += $3; draw += $4; } END { print games, white, black, draw }'
这个find | xargs mawk | mawk管道将我们的运行时间下降到约12秒，即约270MB /秒，比Hadoop快235倍。
结论
希望这说明了一些使用和滥用工具的要点，如Hadoop用于数据处理的任务能在一台机器上用简单的shell命令和工具更好地实现。如果你有一个庞大的数据量，或确实需要分布式处理，然后像Hadoop的工具可能是必需的，但更多的往往是这些天我看到一些使用Hadoop的场景，如果使用关系数据库或其他解决方案能好得多，不管是在性能，实施成本还是后续维护方面。
翻译自： Adam Drake http://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html
Leave a Reply