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