据我所知，工资单通常是一个批处理过程，但我更想问的问题是：公司需要多少员工才能使用hadoop来处理工资单。
根据您所说的hadoop版本（1.0-纯mr，或2.0 with yarn）：
yarn解决了大多数单点故障问题（afaik），另一方面，以map/reduce的方式处理工资单对我来说简直是疯了。如果我们假设大多数公司（如果不是所有公司的话）都将这种数据存储在rdbms中，那么情况就更糟了。
总而言之，我认为mr只有在数据也存储在hdfs中，并且有许多其他更简单的方法在多台机器（或多个核心-通常这已经足够了）上分发工资单处理时才有意义，特别是如果必要的数据存储在rdbms中。
更新（见注解）：
为什么用mr做这份工作是疯狂的先生最适合数词——这不是开玩笑。令人惊讶的是，你能通过数词解决多少问题。你可以创建倒排索引（mr是google发明的，这就是google正在做的，所以它的出色也就不足为奇了）。
例如，spotify使用mr来计算哪首歌的收听频率。你可以想象，他们有巨大的日志（在文本形式或Cassandra，…）从每个用户听一首歌，他们需要创建一个报告的音乐标签，这是先生是最好的。
我还知道一个朋友的一个朋友，他在一家公司工作，专门研究算法，并把它们转移到hadoop中执行，这是因为hadoop集群的强大基础设施，比如管理或容错。
然而，现在有了yarn，更多的编程范例可以在hadoop（或yarn）集群上实现，而不仅仅是mr.使用apache twill，您甚至可以部署自己的应用范例，或者只需对现有的多线程应用程序稍加修改，就可以将其部署在现有的hadoop 2.0集群上。-有了这一点，在一个Yarn集群上运行一个工资单工作甚至是有意义的——前提是这是必要的，因为你需要为数百万的员工做这件事。