1

現在、HDFSとMapReduce用の小さなHadoopクラスターを実行しており、次のページに従ってS3をローカルHDFSに交換しようとしています。

HDFS用のAmazonS3

私が直面している問題は、JobTrackerを起動するときに、メタデータ（jobtracker.info）がすでに存在する場合、Hadoopがこのファイルにアクセス/上書きしようとすると、そのファイルの所有者がMapRedの所有者。hadoop-core-1.0.3（JobTracker.java）での比較：

FileStatus systemDirStatus = fs.getFileStatus(systemDir);
if (!systemDirStatus.getOwner().equals( getMROwner().getShortUserName())) {
    throw new AccessControlException("The systemdir " + systemDir +
      " is not owned by " + getMROwner().getShortUserName());
}

ここでsystemDirStatus.getOwner()、は空の文字列（s3ファイル所有者）をgetMROwner().getShortUserName()返し、「mapredHADOOP_USER_NAME 」を返しますが、この値はJobTrackerノードで環境変数を設定することで空の文字列以外に簡単に変更できます。

この問題は、S3が「ファイル所有者」を維持していないことによる犠牲者であり、HadoopのNativeS3FilesystemとJets3tはこの事実を補うために何もしません。

Hadoopにパッチを適用せずにこれを回避する方法はありますか？EMRがS3でサポートされていることを考えると、これを達成するための何らかの方法があるはずだと思います。まだEMRに移行したくないので、HDFSにS3を使用しながら、独自のEC2クラスターでMapReduceを実行し続けたいことに注意してください。

前もって感謝します！

ラス

4

1 に答える 1

0

それで、さらなる調査の後、私は私の問題の解決策に出くわしました：

S3がファイルのパーミッション/所有者を維持しない上記の問題は、S3がサポートするHadoop JobTrakcerをHDFSとして使用しようとすると、2つの異なる場所に現れます。

  1. JobTrakcerの再起動中に、jobtracker.confファイルがすでに存在する場合。
  2. JobTrakcerがHDFSのステージングディレクトリから情報を取得しようとしたときに、ジョブの2番目のタスクに移行しているとき。

「JobTrackers」は一度だけ開始され、ジョブの完了時に破棄されるため、これらの問題の前者はElasticMapReduceに現れることはありません。org.apache.hadoop.mapreduce.JobSubmissionFilesただし、2つ目は、使用しているHadoopのバージョンによっては、クラスでのチェックの犠牲になる可能性があります。

ほとんどのCDH3ディストリビューション（私はcdh3u3、cdh3u4、およびcdh3u5のみをチェックしました）では、ファイルの所有者とアクセス許可が2つの別々のステートメントでチェックされ、より詳細なログが追加されます（cdh3u5からの抜粋--JobSubmissionFiles.java）：

FileStatus fsStatus = fs.getFileStatus(stagingArea);
  String owner = fsStatus.getOwner();
  if (!(owner.equals(currentUser) || owner.equals(realUser))) {
     throw new IOException("The ownership on the staging directory " +
                  stagingArea + " is not as expected. " + 
                  "It is owned by " + owner + ". The directory must " +
                  "be owned by the submitter " + currentUser + " or " +
                  "by " + realUser);
  }
  if (!fsStatus.getPermission().equals(JOB_DIR_PERMISSION)) {
    LOG.info("Permissions on staging directory " + stagingArea + " are " +
      "incorrect: " + fsStatus.getPermission() + ". Fixing permissions " +
      "to correct value " + JOB_DIR_PERMISSION);
    fs.setPermission(stagingArea, JOB_DIR_PERMISSION);
  }

String ownerがnullまたは空の文字列値を持っている場合、ジョブを実行しているマシンからプルされたcurrentUserまたはに一致することはないことに注意してください。realUser

Apache 0.20.2、1.0.x、2.0.x、およびCDH4を含む古いバージョンおよび最近のバージョンのhadoopでは、このチェックが1つのステートメントに結合され、空の所有者がデフォルトのアクセス許可にロールオーバーできるようになります。 Apache Hadoop 1.0.3からのスニペット-JobSubmissionFiles.java）：

FileStatus fsStatus = fs.getFileStatus(stagingArea);
  String owner = fsStatus.getOwner();
  if (!(owner.equals(currentUser) || owner.equals(realUser)) || 
      !fsStatus.getPermission().equals(JOB_DIR_PERMISSION)) {
     throw new IOException("The ownership/permissions on the staging " +
                  "directory " + stagingArea + " is not as expected. " + 
                  "It is owned by " + owner + " and permissions are "+ 
                  fsStatus.getPermission() + ". The directory must " +
                  "be owned by the submitter " + currentUser + " or " +
                  "by " + realUser + " and permissions must be rwx------");
  }

簡単に言うと、拡張された比較ではなく、折りたたまれた比較を使用してHadoopのバージョンに切り替えると、S3の問題が修正されました。

于 2013-02-13T02:41:11.357 に答える