我在接受采访时被问到这个问题。我在解释Hadoop的缺点时问了这个问题。
我告诉他们的缺点是：
1.单主节点导致的单点故障
2.安全性不是最好的
3.仅适用于处理非常大的数据/文件。
现在，当我更多地了解这些缺点时，我很困惑Hadoop的批处理性质是否不适合处理组织中的工资单？
你能告诉我我的假设是否正确吗？
我在面试时给出的答案完全不同。我告诉他们，由于hadoop作业的分布式特性，一个地方的工资更新可能不会很快反映在数据库中，并且所有节点的数据都不一致。
我想我也应该提到，由于批处理性质，更新不会立即反映在所有节点中
这个问题的最终答案是否是最佳答案？
答案 0 :(得分：0)
据我所知，工资单通常是一个批处理流程，但我要问的问题是 - 公司需要多少员工才能需要hadoop来完成工资单处理。
并且取决于你所谈论的hadoop版本（1.0 - 基于MR的纯粹，或者与YARN的2.0）：
YARN解决了大多数单点故障问题（AFAIK），另一方面 - 以地图/缩小方式处理工资单对我来说似乎很疯狂。更重要的是，当我们可以假设大多数公司（如果不是全部）都有这种数据存储在RDBMS中时。
总结一下，我会说MR只有在数据也存储在HDFS中才有意义，还有许多其他更简单的方法可以在多台机器上分配工资单处理（或多核心 - 通常这已经足够了） - 特别是如果必要的数据存储在RDBMS中。
更新（请参阅评论）：
为什么使用MR来完成这项工作是疯了？ - MR最适合计算单词 - 这不是一个笑话。相当令人惊讶的部分是，通过计算单词可以解决多少问题。你可以创建倒排索引（MR是由谷歌发明的，这就是谷歌正在做的事情，所以它毕竟不令人惊讶，它是如此之好）。
Spotify例如使用MR可能会计算哪首歌是经常收听的。你可以想象，他们有每个用户听一首歌的巨大日志（文字形式或Cassandra，......），他们需要为音乐标签创建一个关于此的报告，这是MR处于最佳状态的地方
我也知道，关于一位朋友的朋友，他正在一家公司工作（工作），专门从事算法并将其转移到Hadoop作为MR执行。之所以这样做是因为Hadoop集群的强大基础架构，如管理或容错。
然而，对于YARN，现在可以在Hadoop（或YARN）集群之上实现更多的编程范例，而不仅仅是MR。使用Apache Twill，您甚至可以部署自己的应用程序范例，或者只是将现有的多线程应用程序稍微修改一下，然后将其部署在现有的Hadoop 2.0集群上。 - 有了它，甚至可以在YARN集群上运行工资单作业 - 只要它是必要的，因为你需要为数百万员工做这件事。