MapR架构Vs Cloudera架构

Question

我熟悉Cloudera的基础架构或架构：

主节点包括NameNode、SecondaryNameNode、JobTracker和HMaster。从节点包括DataNode、TaskTracker和HRegionServer。

主节点应该都在它们自己的节点上(除非它是一个小集群，否则SecondaryNameNode、JobTracker和HMaster可以组合在一起，如果它是一个非常小的集群，甚至可以是NameNode )。

从节点应该始终放在同一节点上。从节点越多，性能越好。

SecondaryNameNode是一个用词不当的词，除非您为高可用性启用它。

MapR是否维护此设置？它有什么相似之处，又有什么不同？

Answer 1

@JamCon在his reply中提供了不错的信息，但有一些事情值得澄清：

关于补丁的评论是不准确的。MapR在其发行版中打包了广泛的Hadoop项目，因此您不必单独编译任何内容。而且MapR和任何其他发行版都有相同的API，这意味着他们的包不是关于兼容性的，而只是来自社区的错误修复/增强。在MapR上运行Hadoop生态系统项目通常不需要额外的工作。据我所知，他们每月至少发布一次生态系统更新，以保持最新的增强功能。

关于YARN的包含，我们从7月14日开始在大型集群的YARN上运行MapR！我相信MapR有他们自己的生态系统项目审查过程，一旦他们确定一个项目已经准备好接受企业支持，他们就会将MapR打包版本升级到GA。

Answer 2

MapR与普通的Hadoop和CDH发行版略有不同。它保留了大多数服务和结构(作业跟踪器、数据节点、HBase主和区域、MR等)，但有一些显著的差异。

关于MapR发行版的定义之一是它不使用HDFS。它有自己的自定义文件系统，该文件系统具有HA功能，并且在没有名称节点的情况下运行(通过分布式元数据)。它还允许他们比其他Hadoop发行版提前几年启用NFS访问，以及快照。

不过，自定义文件系统确实使它们的分布有点复杂……例如，当您要运行产品或服务时，通常需要安装特定于MapR的修补程序。当你想运行mahout时，你需要使用https://github.com/mapr/mahout的MapR补丁来编译它。但它也为他们提供了在FS级别结合更好的安全性的机会，正如"Access Control Expressions“和集群/作业/卷ACL的实现所看到的那样。

总体而言，它是一个结构良好的产品。我最担心的是，他们已经偏离了标准，以至于当采用新的创新时，他们适应得很慢，因为它必须被纳入他们高度修改的环境中。纱线就是一个很好的例子。他们还没有发布，尽管他们的竞争对手已经发布了。

Answer 3

从架构的角度来看，使用MapR没有主节点。相反，主节点在典型的Hadoop架构中提供的功能是在MapR的“数据节点”中分布和执行的。

https://www.mapr.com/why-hadoop/why-mapr/architecture-matters