Cloudera のインフラストラクチャまたはアーキテクチャに精通しています。
マスター ノードには、NameNode、SecondaryNameNode、JobTracker、および HMaster が含まれます。スレーブ ノードには、DataNode、TaskTracker、および HRegionServer が含まれます。
マスター ノードはすべて独自のノード上にある必要があります (小さなクラスターでない限り、SecondaryNameNode、JobTracker、および HMaster を組み合わせることができ、本当に小さなクラスターの場合は NameNode でさえ)。
スレーブ ノードは常に同じノードに配置する必要があります。スレーブノードが多いほど、より楽しくなります。
高可用性のために有効にしない限り、SecondaryNameNode は誤称です。
MapR はこのセットアップを維持しますか? どのように似ていて、どのように違うのでしょうか?
MapR は、通常の Hadoop および CDH ディストリビューションとは少し異なります。ほとんどのサービスと構造 (ジョブ トラッカー、データ ノード、HBase マスターとリージョン、MR など) を保持していますが、いくつかの重要な違いがあります。
MapR のディストリビューションに関する特徴的な項目の 1 つは、HDFS を使用しないことです。独自のカスタム FS があり、HA を備え、ネーム ノードなしで (分散メタデータを介して) 動作します。また、他の Hadoop ディストリビューションよりも何年も前に NFS アクセスを有効にしたり、スナップショットを作成したりできました。
ただし、カスタム FS は配布を少し複雑にします。たとえば、製品やサービスを実行したい場合、MapR 固有のパッチをインストールする必要があることがよくあります。mahout を実行するには、https://github.com/mapr/mahoutから MapR パッチを適用してコンパイルする必要があります。しかし、「アクセス制御式」とクラスター/ジョブ/ボリューム ACLの実装に見られるように、FS レベルでより優れたセキュリティを組み込む機会も与えられます。
全体として、よく構成された製品です。私の最大の懸念は、新しいイノベーションが採用されたときに、高度に変更された環境に組み込む必要があるため、標準から大きく逸脱していることです。YARN は完璧な例です...競合他社がリリースしたにもかかわらず、彼らはまだリリースしていません。