我熟悉Cloudera的基础设施或架构：
主节点包括NameNode，SecondaryNameNode，JobTracker和HMaster。从节点包括DataNode，TaskTracker和HRegionServer。
主节点应该都在它们自己的节点上（除非它可以组合一个小型集群，而不是SecondaryNameNode，JobTracker和HMaster，如果它是一个非常小的集群，甚至是NameNode）。
从属节点应始终位于同一节点上。奴隶节点越多，越好。
SecondaryNameNode是用词不当，除非您为高可用性启用它。
MapR是否保持此设置？它是如何相似的，它有何不同？
@JamCon在his reply提供的良好信息，但有些事情值得澄清：
有关补丁的评论不准确。 MapR在其发行版中打包了大量Hadoop项目，因此您无需单独编译任何内容。并且MapR与任何其他发行版具有相同的API，这意味着它们的包不是关于兼容性，而是来自社区的错误修复/增强功能。通常不需要额外的工作来使Hadoop生态系统项目在MapR上运行。据我所知，他们每个月至少发布一次生态系统更新，以便随时了解新的增强功能。
关于YARN的加入，自14年7月以来，我们一直在YARN上运行大型集群上的MapR！我相信MapR拥有自己的生态系统项目审核流程，一旦确定项目已准备好为企业提供支持，他们就会将MapR打包版本转化为GA。
MapR稍微偏离了vanilla Hadoop和CDH发行版。它保留了大部分服务和结构（Job Tracker，Data Nodes，HBase Master＆Region，MR等），但存在一些显着差异。
关于MapR分发的一个定义是它不使用HDFS。它有自己的自定义FS，它具有HA并且没有名称节点（通过分布式元数据）运行。它还允许他们在其余的Hadoop发行版之前几年启用NFS访问，以及快照。
自定义FS确实使它们的分发变得复杂，但是......例如，当您想要运行产品或服务时，通常需要安装MapR特定的补丁。如果要运行mahout，需要使用https://github.com/mapr/mahout中的MapR补丁进行编译。但它也为他们提供了在FS级别上实现更好安全性的机会，正如“Access Control Expressions”和群集/作业/卷ACL的实现所示。
总的来说，它是一个结构良好的产品。我最担心的是他们偏离了这样的规范，即当采用新的创新时，它们的适应速度很慢，因为它必须被纳入其高度改变的环境中。 YARN是一个完美的例子......他们还没有发布它，即使他们的竞争对手也有。
从MapR的架构角度来看，没有主节点。主节点在典型的Hadoop架构中提供的功能是在MapR的“数据节点”内分布和执行的。
https://www.mapr.com/why-hadoop/why-mapr/architecture-matters
MapR没有主节点，内置mechansim但在Cloudera中有主节点，辅助名称节点和资源管理器http://commandstech.com/mapr-vs-cloudera-vs-hortonworks/