MAPR架构Vs的Cloudera的架构

Question

我熟悉的Cloudera公司的基础设施或建筑：

主节点包括NameNode的，SecondaryNameNode，JobTracker的，和HMASTER。 从节点包括DataNode，TaskTracker和HRegionServer。

主节点应该都在它们自己的节点上（除非它的小群集比SecondaryNameNode，JobTracker和HMaster可以组合在一起，甚至NameNode也是如此，如果它是一个非常小的群集）。

从节点应始终位于同一节点上。越多的从节点越多。

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

MapR是否保持此设置？它有什么相似之处？它有什么不同？

Answer 1

MapR背离了香草Hadoop & CDH发行了一下。它保留了大部分的服务和结构（Job Tracker，Data Nodes，HBase Master & Region，MR等），但是有一些显着的不同。

有关MapR发行版的一个定义是它不使用HDFS。它有自己的定制FS，它具有高可用性并且无需命名节点（通过分布式元数据）运行。它还允许它们在Hadoop发行版的其余部分之前启用NFS访问，并且可以快照。

自定义FS确实使其分发复杂化了一点，但是...例如，当您要运行产品或服务时，您通常需要安装MapR特定的修补程序。当你想运行mahout时，你需要使用https://github.com/mapr/mahout的MapR补丁进行编译。但是它也使他们有机会在FS级别上实现更好的安全性，如实施“Access Control Expressions”和Cluster/Job/Volume ACL所示。

总的来说，这是一个结构良好的产品。我最担心的是他们已经偏离了这个标准，即当采用新的创新时，他们的适应变得很慢，因为它必须被纳入他们高度改进的环境中。 YARN是一个完美的例子......尽管他们的竞争对手已经有了，但他们还没有发布它。

Answer 2

在his reply通过@JamCon良好的信息，但也有一些事情值得澄清：

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

关于包含YARN，自2014年7月以来，我们一直在YARN上跨越大型集群运行MapR！我相信MapR拥有自己的生态系统项目审查流程，并且一旦他们确定项目已经准备好进行企业支持，他们就会将MapR打包版本提交给GA。

Answer 3

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

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