hadoop - 使用Hadoop处理工资单的缺点

Question

采访中有人问我这个问题。当我解释Hadoop的缺点时，有人问了这个问题。
我告诉他们的缺点是:
1.由于单个主节点而导致的单点故障。
2.安全性不是最佳状态。
3.仅适用于处理非常大的数据/文件。

现在，当我更多地了解缺点时，我感到困惑的是，Hadoop的批处理特性是否使其不适合在组织中处理工资单？
您能告诉我我的假设是否正确吗？
我在面试中给出的答案是完全不同的。我告诉他们，由于hadoop作业的分布式性质，一个地方的薪水更新可能不会很快反射(reflect)在数据库中，并且数据在所有节点上都不会保持一致。
我想我还应该提到，由于批处理的本质，更新不会立即反射(reflect)在所有节点中。
最后的答案是否是该问题的最佳答案？

Answer 1

据我所知，工资单通常是一个批处理过程，但是我想问的问题是-公司需要多少员工才能需要Hadoop来进行工资单处理。

并取决于您所讨论的hadoop版本(1.0-基于纯MR或YARN的2.0):

YARN解决了大多数单点故障问题(AFAIK)，另一方面-以 map /缩小方式处理工资单对我来说似乎很疯狂。当我们可以假设大多数公司(如果不是全部)都将这种数据存储在RDBMS中时，甚至更多。

综上所述，我要说的是，MR仅在数据也存储在HDFS中且有意义的情况下才有意义，并且有许多其他更简单的方法可以在多台计算机(或多个内核-通常应该已经足够)上分配薪水处理-特别是如果必要的数据存储在RDBMS中。

更新(请参阅评论):

为什么使用MR来完成这项工作很疯狂？ -MR最适合计数单词-这不是开 Jest 。相当令人惊讶的部分是，您可以通过计算单词数来解决多少问题。您可以创建倒排索引(MR是Google发明的，这就是Google所做的，所以毕竟它是如此出色也就不足为奇了)。

例如，Spotify正在使用MR来计数听过哪首歌。您可以想象，他们从每个听过歌曲的用户那里获得了巨大的日志(以文本形式或在Cassandra中，...)，并且他们需要为此创建一个音乐标签报告，这是MR最好的地方。

我也认识一个 friend 的 friend ，他在一家公司中工作(工作)，公司专门研究算法并将其作为MR在Hadoop中执行。这样做是由于Hadoop集群的强大基础架构，例如管理或容错能力。

但是，现在使用YARN，可以在Hadoop(或YARN)集群上实现更多的编程范例，而不仅仅是MR。使用Apache Twill，您甚至可以部署自己的应用程序范例，或者仅对现有的多线程应用程序进行一些修改，然后将其部署在现有的Hadoop 2.0集群上。 -有了它，甚至可以在YARN群集上运行工资核算作业-只要有必要，因为您需要为数百万名员工完成这项工作。