Amazon EMRリリース 6.0.0

• Amazon 7.x EMR リリースのアプリケーションバージョン

• Amazon EMR 6.x リリースのアプリケーションバージョン

• Amazon EMR 5.x リリースのアプリケーションバージョン

• Amazon EMR 4.x リリースのアプリケーションバージョン

サポートされているアプリケーション

• AWS SDK for Java バージョン 1.11.711

• Ganglia バージョン 3.7.2

• Hadoop バージョン 3.2.1

• HBase バージョン 2.2.3

• HCatalog バージョン 3.1.2

• Hive バージョン 3.1.2

• Hudi バージョン 0.5.0-incubating

• Hue バージョン 4.4.0

• JupyterHub バージョン 1.0.0

• Livy バージョン 0.6.0

• MXNet バージョン 1.5.1

• Oozie バージョン 5.1.0

• Phoenix バージョン 5.0.0

• Presto バージョン 0.230

• Spark バージョン 2.4.4

• TensorFlow バージョン 1.14.0

• Zeppelin バージョン 0.9.0-SNAPSHOT

• Zookeeper バージョン 3.4.14

• コネクタおよびドライバー: DynamoDB Connector 4.14.0

新機能

• YARN Docker Runtime Support - Spark ジョブなどのYARNアプリケーションは、Docker コンテナのコンテキストで実行できるようになりました。これにより、Amazon EMRクラスターにカスタムライブラリをインストールしなくても、Docker イメージで依存関係を簡単に定義できます。詳細については、「Amazon 6.0.0 を使用して Docker と Docker の統合を設定し、Spark アプリケーションを実行する」を参照してください。 EMR

• Hive LLAP サポート - Hive はLLAP実行モードをサポートして、クエリのパフォーマンスを向上させました。詳細については、「Hive の使用LLAP」を参照してください。

変更点、機能強化、解決した問題

• これは、クラスターのスケールアップ/スケールダウンに失敗した場合、またはアプリケーション障害を引き起こした場合の Amazon EMR Scaling の問題を修正するためのリリースです。

• Amazon クラスターEMR上のデーモンがYARNノードの状態やノードHDFSの状態の収集などのヘルスチェックアクティビティを実行している場合に、大規模で使用率の高いクラスターでスケーリングリクエストが失敗する問題を修正しました。これは、クラスター上のデーモンがノードのヘルスステータスデータを内部 Amazon EMRコンポーネントに通信できなかったために発生しました。

• クラスターEMR上のデーモンが改善され、IP アドレスが再利用されたときのノードの状態が正しく追跡され、スケーリングオペレーション中の信頼性が向上しました。

• SPARK-29683。Spark が使用可能なすべてのノードが拒否リストに登録されていると想定していたため、クラスターのスケールダウン中にジョブエラーが発生する問題を修正しました。

• YARN-9011。クラスターのスケールアップまたはスケールダウンを試みたときに、YARN廃止時の競合状態が原因でジョブの失敗が発生する問題を修正しました。

• Amazon クラスターEMR上のデーモンと YARN/ の間でノードの状態が常に一貫しているようにすることで、クラスターのスケーリング中にステップまたはジョブが失敗する問題を修正しましたHDFS。

• Kerberos 認証で有効になっている Amazon クラスターで、スケールダウンやステップ送信などのEMRクラスターオペレーションが失敗する問題を修正しました。これは、Amazon クラスターEMR上のデーモンが Kerberos チケットを更新しなかったためです。これは、プライマリノードで HDFS/YARN と安全に通信するために必要です。

• 新しい Amazon EMRリリースでは、Amazon の古い の「最大オープンファイル」制限を低くして問題が修正AL2されていますEMR。Amazon EMRリリース 5.30.1、5.30.2、5.31.1、5.32.1、6.0.1、6.1.1、6.2.1、5.33.0、6.3.0 以降では、「最大オープンファイル」設定が高い永続的な修正が追加されました。

• Amazon Linux

  • Amazon Linux 2 は 6.x EMR リリースシリーズのオペレーティングシステムです。

  • systemd は、Linux 1 upstart inAmazon の代わりにサービス管理に使用されます。

• Java 開発キット (JDK）

  • Corretto JDK 8 は 6.x EMR リリースシリーズのデフォルトJDKです。

• Scala

  • Scala 2.12 は、Apache Spark および Apache Livy で使用されます。

• Python 3

  • Python 3 が の Python のデフォルトバージョンになりましたEMR。

• YARN ノードラベル

  • Amazon 6.x EMR リリースシリーズ以降、YARNノードラベル機能はデフォルトで無効になっています。アプリケーションマスタープロセスは、デフォルトでコアノードとタスクノードの両方で実行できます。YARN ノードラベル機能を有効にするには、 yarn.node-labels.enabledおよび のプロパティを設定しますyarn.node-labels.am.default-node-label-expression。詳細については、「Understanding Primary, Core, and Task Nodes」を参照してください。

既知の問題

• 古い AL2 [新しいリリースで修正済み] の「最大オープンファイル」制限を引き下げます。Amazon EMRリリース: emr-5.30.x、emr-5.31.0、emr-5.32.0、emr-6.0.0、emr-6.1.0、および emr-6.2.0 は、古いバージョンの ofAmazon Linux 2 (AL2) に基づいています。これは、Amazon EMRクラスターがデフォルトの で作成されたときに「最大オープンファイル」の ulimit 設定が低くなりますAMI。Amazon EMRリリース 5.30.1、5.30.2、5.31.1、5.32.1、6.0.1、6.1.1、6.2.1、5.33.0、6.3.0 以降には、「最大オープンファイル」設定が高い永続的な修正が含まれています。オープンファイルの上限が低いリリースでは、Spark ジョブを送信するときに「Too many open files」というエラーが発生します。影響を受けるリリースでは、Amazon のEMRデフォルト ulimit 設定AMIは「最大オープンファイル」で 4096 で、 latestAmazon Linux 2 の 65536 ファイル制限よりも低くなっていますAMI。「最大オープンファイル」の ulimit 設定が低い場合、Spark ドライバーとエグゼキュータが 4096 を超えるファイルを開こうとすると、Spark ジョブが失敗します。この問題を解決するために、Amazon EMRにはクラスターの作成時に ulimit 設定を調整するブートストラップアクション (BA) スクリプトがあります。

  この問題の永続的な修正がない古い Amazon EMRバージョンを使用している場合、次の回避策により、インスタンスコントローラーの ulimit を最大 65536 個のファイルに明示的に設定できます。

  コマンドラインから ulimit を明示的に設定する

  1. /etc/systemd/system/instance-controller.service を編集して、Service セクションに次のパラメータを追加します。

     LimitNOFILE=65536

     LimitNPROC=65536

  2. 再起動 InstanceController

     $ sudo systemctl daemon-reload

     $ sudo systemctl restart instance-controller

  ブートストラップアクション (BA) を使用して ulimit を設定する

  ブートストラップアクション (BA) スクリプトを使用して、クラスター作成時にインスタンスコントローラーの ulimit を 65536 ファイルに設定することもできます。

  #!/bin/bash
  for user in hadoop spark hive; do
  sudo tee /etc/security/limits.d/$user.conf << EOF
  $user - nofile 65536
  $user - nproc 65536
  EOF
  done
  for proc in instancecontroller logpusher; do
  sudo mkdir -p /etc/systemd/system/$proc.service.d/
  sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
  [Service]
  LimitNOFILE=65536
  LimitNPROC=65536
  EOF
  pid=$(pgrep -f aws157.$proc.Main)
  sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
  done
  sudo systemctl daemon-reload

• 、SparkR PySpark、Spark-shell などの Spark インタラクティブシェルは、追加のライブラリでの Docker の使用をサポートしていません。 SparkR

• Amazon EMRバージョン 6.0.0 で Python 3 を使用するには、 PATHを に追加する必要がありますyarn.nodemanager.env-whitelist。

• AWS Glue Data Catalog を Hive のメタストアとして使用する場合、Live Long and Process (LLAP) 機能はサポートされません。

• Spark と Docker の統合で Amazon EMR 6.0.0 を使用する場合は、Docker ランタイムで Spark ジョブを送信するときに障害が発生しないように、クラスター内のインスタンスを同じインスタンスタイプと同じ量のEBSボリュームで設定する必要があります。

• Amazon 6EMR.0.0 HBaseでは、Amazon S3 ストレージモードは HBASE-24286 の問題の影響を受けます。HBase 既存の S3 データを使用してクラスターが作成されると、 マスターは を初期化できません。

• 複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

  Amazon EMRリリース 5.20.0 以降で複数のプライマリノードと Kerberos 認証を使用してクラスターを実行すると、クラスターがしばらく実行した後に、スケールダウンやステップ送信などのクラスターオペレーションで問題が発生する可能性があります。期間は、定義した Kerberos チケットの有効期間によって異なります。スケールダウンの問題は、自動スケールダウンリクエストと送信した明示的なスケールダウンリクエストの両方に影響します。その他のクラスターオペレーションも影響を受ける可能性があります。

  回避方法:

  • SSH 複数のプライマリノードを持つEMRクラスターのリードプライマリノードへのhadoopユーザーとして。

  • 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。

    kinit -kt <keytab_file> <principal>

    通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。

  注記

  この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。