我熟悉 Cloudera 的基础架构或架构：
主节点包括 NameNode、SecondaryNameNode、JobTracker 和 HMaster。从节点包括 DataNode、TaskTracker 和 HRegionServer。
Master 节点应该都在它们自己的节点上（除非它是一个小集群，否则可以组合 SecondaryNameNode、JobTracker 和 HMaster，如果它是一个非常小的集群，甚至是 NameNode）。
从节点应始终位于同一节点上。从节点越多越好。
SecondaryNameNode 用词不当，除非您启用它以实现高可用性。
MapR 是否维护此设置？它有什么相似之处，又有什么不同？
@JamCon 在他的回复中提供了很好的信息，但有一些事情值得澄清：
关于补丁的评论不准确。MapR 在其发行版中打包了广泛的 Hadoop 项目，因此您无需单独编译任何内容。而且 MapR 具有与任何其他发行版相同的 API，这意味着它们的软件包与兼容性无关，而只是来自社区的错误修复/增强。让 Hadoop 生态系统项目在 MapR 上运行通常不需要额外的工作。据我所知，他们至少每月发布一次生态系统更新，以跟上新的增强功能。
关于 YARN 的加入，自 14 年 7 月以来，我们一直在跨大型集群的 YARN 上运行 MapR！我相信 MapR 有自己的生态系统项目审查流程，一旦他们确定项目已准备好获得企业支持，他们就会将 MapR 打包版本升级到 GA。
MapR 有点偏离原版 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 级别合并更好的安全性的机会，正如“访问控制表达式”和集群/作业/卷 ACL 的实现所见。
总的来说，这是一个结构良好的产品。我最大的担忧是他们已经偏离了标准，以至于当采用新的创新时，他们的适应速度很慢，因为它必须融入他们高度修改的环境中。YARN 就是一个完美的例子……他们还没有发布它，尽管他们的竞争对手已经发布了。
从 MapR 架构的角度来看，没有主节点。主节点在典型的 Hadoop 架构中提供的功能是在 MapR 的“数据节点”内分布和执行的。
https://www.mapr.com/why-hadoop/why-mapr/architecture-matters
MapR 没有主节点，内置机制，但在 Cloudera 中有主节点，辅助名称节点和资源管理器 http://commandstech.com/mapr-vs-cloudera-vs-hortonworks/