リリース 6.14.0 リリース 6.13.0 リリース 6.12.0 リリース 6.11.1 リリース 6.11.0 リリース 6.10.0 リリース 6.9.0 リリース 6.8.0 リリース 6.7.0 リリース 6.6.0 リリース 5.35.0 リリース 5.34.0 リリース 6.5.0 リリース 6.4.0 リリース 5.32.0 リリース 6.2.0 リリース 5.31.0 リリース 6.1.0 リリース 6.0.0 リリース 5.30.1 リリース 5.30.0 リリース 5.29.0 リリース 5.28.1 リリース 5.28.0 リリース 5.27.0 リリース 5.26.0 リリース 5.25.0 リリース 5.24.1 リリース 5.24.0 リリース 5.23.0 リリース 5.22.0 リリース 5.21.1 リリース 5.21.0 リリース 5.20.0 リリース 5.19.0 リリース 5.18.0 リリース 5.17.1 リリース 5.17.0 リリース 5.16.0 リリース 5.15.0 リリース 5.14.1 リリース 5.14.0 リリース 5.13.0 リリース 5.12.2 リリース 5.12.1 リリース 5.12.0 リリース 5.11.3 リリース 5.11.2 リリース 5.11.1 リリース 5.11.0 リリース 5.10.0 リリース 5.9.0 リリース 5.8.2 リリース 5.8.1 リリース 5.8.0 リリース 5.7.0 リリース 5.6.0 リリース 5.5.3 リリース 5.5.2 リリース 5.5.1 リリース 5.5.0 リリース 5.4.0 リリース 5.3.1 リリース 5.3.0 リリース 5.2.2 リリース 5.2.1 リリース 5.2.0 リリース 5.1.0 リリース 5.0.3 リリース 5.0.0 リリース 4.9.5 リリース 4.9.4 リリース 4.9.3 リリース 4.9.2 リリース 4.9.1 リリース 4.8.4 リリース 4.8.3 リリース 4.8.2 リリース 4.8.0 リリース 4.7.2 リリース 4.7.1 リリース 4.7.0 リリース 4.6.0 リリース 4.5.0 リリース 4.4.0 リリース 4.3.0 リリース 4.2.0

Amazon EMR リリースノートのアーカイブ

すべての Amazon EMR リリースのリリースノートは以下から入手できます。各リリースの包括的なリリース情報については、「Amazon EMR 6.x リリースバージョン」、「Amazon EMR 5.x リリースバージョン」、および「Amazon EMR 4.x リリースバージョン」を参照してください。

新しい Amazon EMR リリースが利用可能になったときに更新を受け取るには、https://docs.aws.amazon.com/emr/latest/ReleaseGuide/amazon-emr-release-notes.rss で Amazon EMR リリースノートの RSS フィードをサブスクライブします。

リリース 6.14.0

次のリリースノートには、Amazon EMR リリース 6.14.0 に関する情報が含まれています。6.13.0 からの変更が含まれています。リリースタイムラインの詳細については、「変更ログ」を参照してください。

新機能

Amazon EMR 6.14.0 supports Apache Spark 3.4.1, Apache Spark RAPIDS 23.06.0-amzn-2, Flink 1.17.1, Iceberg 1.3.1, and Trino 422.
Amazon EMR 6.14.0 以降で作成したクラスターについて、ap-southeast-3 アジアパシフィック (ジャカルタ) リージョンで Amazon EMR Managed Scaling を利用できるようになりました。

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

6.14.0 リリースでは、Amazon EC2 で実行されている Amazon EMR でのログ管理が最適化されています。その結果、クラスターログのストレージコストがわずかに削減される可能性があります。
6.14.0 リリースでは、Amazon EBS ボリュームのサイズに大きなばらつきがあるさまざまなコアインスタンスを考慮して、スケーリングワークフローが改善されています。この改善はコアノードにのみ適用され、タスクノードのスケールダウン操作には影響しません。
6.14.0 リリースでは、Amazon EMR が Apache Hadoop YARN ResourceManager and HDFS NameNode などのオープンソースアプリケーションとやり取りする方法が改善されています。この改善により、クラスタースケーリングによる運用遅延のリスクが軽減され、オープンソースアプリケーションとの接続の問題が原因で発生する起動障害が軽減されます。
6.14.0 リリースでは、クラスター起動時のアプリケーションのインストールが最適化されます。これにより、Amazon EMR アプリケーションの特定の組み合わせのクラスター起動時間が短縮されます。
6.14.0 リリースでは、カスタムドメインの VPC で実行されているクラスターがコアノードまたはタスクノードの再起動に遭遇したときに、クラスターのスケールダウン操作が停止することがある問題が修正されています。

Amazon EMR 5.36 以降、または 6.6 以降の最新のパッチリリースを使用してクラスターを起動すると、Amazon EMR はデフォルトの Amazon EMR AMI に最新の Amazon Linux 2 リリースを使用します。詳細については、「Amazon EMR にデフォルトの Amazon Linux AMI を使用する」を参照してください。

OsReleaseLabel (Amazon Linux バージョン)	Amazon Linux カーネルバージョン	利用可能日	サポートされるリージョン
2.0.20230906.0	4.14.322	2023 年 9 月 11 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)、イスラエル (テルアビブ)

リリース 6.13.0

次のリリースノートには、Amazon EMR リリース 6.13.0 に関する情報が含まれています。6.12.0 からの変更が含まれています。リリースタイムラインの詳細については、「変更ログ」を参照してください。

新機能

Amazon EMR 6.13.0 supports Apache Spark 3.4.1, Apache Spark RAPIDS 23.06.0-amzn-1, CUDA Toolkit 11.8.0, and JupyterHub 1.5.0.

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

6.13.0 リリースでは、Amazon EMR ログ管理デーモンが改善され、クラスター終了コマンドが発行されたときに、すべてのログが定期的に Amazon S3 にアップロードされるようになりました。これにより、クラスターの終了が速くなります。
6.13.0 リリースでは Amazon EMR のログ管理機能が強化され、すべてのログファイルを Amazon S3 に一貫してタイムリーにアップロードできるようになりました。これは特に、長時間稼働する EMR クラスターにメリットをもたらします。

OsReleaseLabel (Amazon Linux バージョン)	Amazon Linux カーネルバージョン	利用可能日	サポートされるリージョン
2.0.20230808.0	4.14.320	2023 年 8 月 24 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)、イスラエル (テルアビブ)

リリース 6.12.0

次のリリースノートには、Amazon EMR リリース 6.12.0 に関する情報が含まれています。6.11.0 からの変更が含まれています。リリースタイムラインの詳細については、「変更ログ」を参照してください。

新機能

Amazon EMR 6.12.0 supports Apache Spark 3.4.0, Apache Spark RAPIDS 23.06.0-amzn-0, CUDA 11.8.0, Apache Hudi 0.13.1-amzn-0, Apache Iceberg 1.3.0-amzn-0, Trino 414, and PrestoDB 0.281.
Amazon EMR リリース 6.12.0 以降は、Apache Livy、HiveServer2 (HS2) 経由の Apache Hive、Trino、Presto、Hue との LDAP 統合をサポートしています。6.12.0 以降を使用する EMR クラスターに Apache Spark と Apache Hadoop をインストールし、LDAP を使用するように設定することもできます。詳細については、「Amazon EMR での認証に Active Directory または LDAP サーバーを使用する」を参照してください。

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

Amazon EMR リリース 6.12.0 以降では、Java 11 ランタイム環境で Flink を実行できます。詳細については、「Flink が Java 11 で実行されるよう設定する」を参照してください。

Amazon EMR 6.12.0 は、Trino を除き、Amazon Corretto 8 を使用するすべてのアプリケーションをデフォルトでサポートします。Trino の場合、Amazon EMR は Amazon EMR リリース 6.9.0 以降、デフォルトで Amazon Corretto 17 をサポートしています。Amazon EMR は Amazon Corretto 11 および 17 を使用する一部のアプリケーションもサポートしています。これらのアプリケーションのリストを以下の表に示します。クラスターのデフォルト JVM を変更する場合は、クラスター上で実行される各アプリケーションに対して「特定の Java 仮想マシンを使用するようにアプリケーションを設定」の手順を実行してください。1 つのクラスターに使用できる Java ランタイムバージョンは 1 つだけです。Amazon EMR は、同じクラスター上の異なるランタイムバージョンで異なるノードやアプリケーションを実行することをサポートしていません。

Amazon EMR は Apache Spark、Apache Hadoop、および Apache Hive で Amazon Corretto 11 と 17 の両方をサポートしていますが、これらのバージョンの Corretto を使用すると、一部のワークロードでパフォーマンスが低下する可能性があります。デフォルトを変更する前に、ワークロードをテストすることをお勧めします。

Amazon EMR 6.12 でのアプリケーションのデフォルト Java バージョン
アプリケーション	Java/Amazon Corretto バージョン (デフォルトは太字)
差分	17、11、8
Flink	11、8
Ganglia	8
HBase	11、8
HCatalog	17、11、8
Hadoop	17、11、8
[Hive]	17、11、8
Hudi	17、11、8
Iceberg	17、11、8
Livy	17、11、8
Oozie	17、11、8
フェニックス	8
PrestoDB	8
Spark	17、11、8
Spark RAPIDS	17、11、8
Sqoop	8
Tez	17、11、8
Trino	17
Zeppelin	8
Pig	8
Zookeeper	8

6.12.0 リリースでは、Presto または Trino を実行する EMR クラスターのクラスタースケーリングワークフローに新しい再試行メカニズムが追加されています。この改善により、サイズ変更操作が 1 回失敗したためにクラスターのサイズ変更が無期限に停止するリスクが軽減されます。また、クラスターのスケールアップとスケールダウンが速くなるため、クラスターの使用率も向上します。
6.12.0 リリースでは、正常に廃止されているコアノードが完全に廃止される前に何らかの理由で異常が発生すると、クラスターのスケールダウン操作が停止することがある問題が修正されています。
6.12.0 リリースでは、クラスターのスケールダウンロジックが改善され、クラスターの HDFS レプリケーション係数設定を下回るコアノードのスケールダウンが試みられることがなくなりました。これはデータの冗長性要件に合致し、スケーリング操作が停止する可能性が低くなります。
6.12.0 リリースでは、インスタンスの状態変化を記録する速度が向上し、Amazon EMR のヘルスモニタリングサービスのパフォーマンスと効率が向上します。この改善により、複数のカスタムクライアントツールやサードパーティーアプリケーションを実行しているクラスターノードのパフォーマンスが低下する可能性が低くなります。
6.12.0 リリースでは、Amazon EMR のクラスター上のログ管理デーモンのパフォーマンスが向上しています。その結果、同時実行性の高いステップを実行する EMR クラスターでは、パフォーマンスが低下する可能性が低くなります。
Amazon EMR リリース 6.12.0 では、ログ管理デーモンがアップグレードされ、ローカルインスタンスストレージ上のオープンファイルハンドルでアクティブに使用されているすべてのログと、関連するプロセスが識別されるようになりました。このアップグレードにより、ログが Amazon S3 にアーカイブされた後に Amazon EMR がファイルを適切に削除し、ストレージスペースを再利用できるようになります。
6.12.0 リリースには、ローカルクラスターファイルシステム内の空で未使用のステップディレクトリを削除するログ管理デーモンの機能強化が含まれています。空のディレクトリが多すぎると、Amazon EMR デーモンのパフォーマンスが低下し、ディスクが過剰に使用される可能性があります。
6.12.0 リリースでは、YARN タイムラインサーバーのログのログローテーションが可能になります。これにより、特に長時間稼働するクラスターのディスク過剰使用シナリオが最小限に抑えられます。
Amazon EMR 6.10.0 以降では、デフォルトのルートボリュームサイズが 15 GB に増えました。以前のリリースでは、デフォルトのルートボリュームサイズは 10 GB でした。

OsReleaseLabel (Amazon Linux バージョン)	Amazon Linux カーネルバージョン	利用可能日	サポートされるリージョン
2.0.20230727.0	4.14.320	2023 年 8 月 14 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)、イスラエル (テルアビブ)
2.0.20230719.0	4.14.320	2023 年 8 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)、イスラエル (テルアビブ)
2.0.20230628.0	4.14.318	2023 年 7 月 12 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)

リリース 6.11.1

次のリリースノートには、Amazon EMR リリース 6.11.1 に関する情報が含まれています。6.11.0 からの変更が含まれています。リリースタイムラインの詳細については、「変更ログ」を参照してください。

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

ノードが廃止試行と同時に追加または削除されると、ロック競合が原因でデッドロックに陥る可能性があります。その結果、Hadoop Resource Manager (YARN) が応答しなくなり、着信コンテナと現在実行中のコンテナのすべてに影響が及びます。
このリリースには、高可用性クラスターが再起動後に障害状態から回復できるようにする変更が含まれています。
このリリースには Hue と HBase のセキュリティ修正が含まれています。
このリリースでは、Amazon EMR で Spark でワークロードを実行しているクラスターが contains、startsWith、endsWith、および like でメッセージが表示されずに間違った結果を受け取る可能性があるという問題が修正されています。この問題は、Amazon EMR Hive3 メタストアサーバー (HMS) のメタデータを含むパーティション化されたフィールドで式を使用する場合に発生します。
このリリースでは、ユーザー定義関数 (UDF) がない場合の Glue 側のスロットリングの問題が修正されています。
このリリースでは、YARN が廃止された場合に、ログプッシャーが S3 にコンテナログをプッシュする前に、ノードログ集約サービスによってコンテナログが削除される問題が修正されています。
このリリースでは、Hadoop でノードラベルが有効になっている場合の FairShare スケジューラメトリクスの問題が修正されています。
このリリースでは、spark-defaults.conf の spark.yarn.heterogeneousExecutors.enabled 設定にデフォルトの true 値を設定したときに Spark のパフォーマンスに影響する問題が修正されています。
このリリースでは、低減タスクがシャッフルデータの読み取りに失敗する問題が修正されています。この問題により、メモリ破損エラーで Hive のクエリが失敗していました。
このリリースでは、Presto または Trino を実行する EMR クラスターのクラスタースケーリングワークフローに新しい再試行メカニズムが追加されています。この改善により、サイズ変更操作が 1 回失敗したためにクラスターのサイズ変更が無期限に停止するリスクが軽減されます。また、クラスターのスケールアップとスケールダウンが速くなるため、クラスターの使用率も向上します。
このリリースでは、クラスターのスケールダウンロジックが改善され、クラスターの HDFS レプリケーション係数設定を下回るコアノードのスケールダウンが試みられることがなくなりました。これはデータの冗長性要件に合致し、スケーリング操作が停止する可能性が低くなります。
ログ管理デーモンがアップグレードされ、ローカルインスタンスストレージ上のオープンファイルハンドルでアクティブに使用されているすべてのログと、関連するプロセスが識別されるようになりました。このアップグレードにより、ログが Amazon S3 にアーカイブされた後に Amazon EMR がファイルを適切に削除し、ストレージスペースを再利用できるようになります。
このリリースには、ローカルクラスターファイルシステム内の空で未使用のステップディレクトリを削除するログ管理デーモンの機能強化が含まれています。空のディレクトリが多すぎると、Amazon EMR デーモンのパフォーマンスが低下し、ディスクが過剰に使用される可能性があります。

OsReleaseLabel (Amazon Linux バージョン)	Amazon Linux カーネルバージョン	利用可能日	サポートされるリージョン
2.0.20230727.0	4.14.320	2023 年 8 月 14 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、カナダ (中部)

リリース 6.11.0

次のリリースノートには、Amazon EMR リリース 6.11.0 に関する情報が含まれています。6.10.0 からの変更が含まれています。リリースタイムラインの詳細については、「変更ログ」を参照してください。

新機能

Amazon EMR 6.11.0 は、Apache Spark 3.3.2-amzn-0、Apache Spark RAPIDS 23.02.0-amzn-0、CUDA 11.8.0、Apache Hudi 0.13.0-amzn-0、Apache Iceberg 1.2.0-amzn-0、Trino 410-amzn-0、PrestoDB 0.279-amzn-0 をサポートしています。

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

Amazon EMR 6.11.0 では、DynamoDB コネクタがバージョン 5.0.0 にアップグレードされています。バージョン 5.0.0 では AWS SDK for Java 2.x が使用されます。以前のリリースでは AWS SDK for Java 1.x が使用されていました。このアップグレードの結果として、Amazon EMR 6.11 で DynamoDB コネクタを使用する前にコードをテストすることを強くお勧めします。
Amazon EMR 6.11.0 の DynamoDB コネクタは、DynamoDB サービスを呼び出すとき、dynamodb.endpoint プロパティに指定されたリージョンの値を使用します。dynamodb.endpoint を使用するときに dynamodb.region も設定し、両方のプロパティで同じ AWS リージョンをターゲットにすることをお勧めします。dynamodb.endpoint を使用し、dynamodb.region を設定しない場合、Amazon EMR 6.11.0 の DynamoDB コネクタは無効なリージョンの例外を返し、Amazon EC2 インスタンスメタデータサービス (IMDS) からの AWS リージョン情報を調整しようとします。コネクタが IMDS からリージョンを取得できない場合は、デフォルトで米国東部 (バージニア北部) (us-east-1) になります。次のエラーは、dynamodb.region プロパティを適切に設定しないと発生する可能性のある無効なリージョンの例外の例です: error software.amazon.awssdk.services.dynamodb.model.DynamoDbException: Credential should be scoped to a valid region.。2.x への AWS SDK for Java アップグレードによって影響を受けるクラスの詳細については、Amazon EMR-DynamoDB コネクタの GitHub リポジトリにある「Upgrade AWS SDK for Java from 1.x to 2.x (#175)」のコミットを参照してください。
このリリースでは、列の名前変更操作後に Delta Lake を使用して Amazon S3 に Delta テーブルデータを保存すると列データが NULL になる問題が修正されています。Delta Lake のこの実験的機能の詳細については、「Delta Lake User Guide」の「Column rename operation」を参照してください。
6.11.0 リリースでは、複数のプライマリノードがあるクラスターからプライマリノードの 1 つを複製してエッジノードを作成する際に発生する可能性のある問題が修正されています。複製されたエッジノードは、スケールダウン操作で遅延を引き起こしたり、プライマリノードのメモリ使用率が高くなったりする可能性があります。EMR クラスターと通信するエッジノードを作成する方法の詳細については、GitHub の aws-samples リポジトリにある「Edge Node Creator」を参照してください。
6.11.0 リリースでは、Amazon EMR が再起動後に Amazon EBS ボリュームをインスタンスに再マウントするために使用する自動化プロセスが改善されました。
6.11.0 リリースでは、Amazon EMR が Amazon CloudWatch に公開する Hadoop メトリクスに断続的なギャップが生じる問題が修正されています。
6.11.0 リリースでは、クラスターのノードの除外リストを含む YARN 構成ファイルの更新が、ディスクの過剰使用により中断される EMR クラスターの問題が修正されています。更新が不完全だと、今後のクラスターのスケールダウン操作が妨げられます。このリリースでは、クラスターが正常に動作し、スケーリング操作が期待どおりに機能することが保証されます。
Amazon EMR 6.10.0 以降では、デフォルトのルートボリュームサイズが 15 GB に増えました。以前のリリースでは、デフォルトのルートボリュームサイズは 10 GB でした。
Hadoop 3.3.3 では YARN (YARN-9608) に変更が加えられ、アプリケーションが完了するまでコンテナが実行されていたノードは廃止状態のままになります。この変更により、シャッフルデータなどのローカルデータが失われることはなく、ジョブを再実行する必要もなくなります。このアプローチでは、マネージドスケーリングが有効になっているかどうかにかかわらず、クラスターのリソースが十分に活用されない可能性もあります。

Amazon EMR リリース 6.11.0 以降および 6.8.1、6.9.1、6.10.1 では、この問題を解決するために yarn-site.xml の yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications の値が false に設定されています。

この修正は YARN-9608 によって発生した問題を解決するものですが、マネージドスケーリングが有効になっているクラスターでのシャッフルデータ損失が原因で Hive ジョブが失敗する可能性があります。このリリースでは、Hive ワークロードにも yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data を設定することで、このリスクを軽減しました。この設定は、Amazon EMR リリース 6.11.0 以降でのみ使用できます。

注記

このリリースは、さらに 1 つのパッチリリースが続いているため、AMI の自動更新は行われなくなりました。パッチリリースは 2 番目の小数点の後の数字 (6.8.1) で示されます。最新のパッチリリースを使用しているかどうかを確認するには、「リリースガイド」で利用可能なリリースを確認するか、コンソールでクラスターを作成するとき、または ListReleaseLabels API あるいは list-release-labels CLI アクションを使用するときに Amazon EMR リリースドロップダウンを確認してください。新しいリリースに関する最新情報を入手するには、「最新情報」ページの RSS フィードにサブスクライブしてください。

OsReleaseLabel (Amazon Linux バージョン)	Amazon Linux カーネルバージョン	利用可能日	サポートされるリージョン
2.0.20230727.0	4.14.320	2023 年 8 月 14 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)、イスラエル (テルアビブ)
2.0.20230719.0	4.14.320	2023 年 8 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)、イスラエル (テルアビブ)
2.0.20230628.0	4.14.318	2023 年 7 月 12 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (ミラノ)、欧州 (スペイン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)
2.0.20230612.0	4.14.314	2023 年 6 月 23 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (ミラノ)、欧州 (スペイン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)
2.0.20230504.1	4.14.313	2023 年 5 月 16 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)

リリース 6.10.0

次のリリースノートには、Amazon EMR リリース 6.10.0 に関する情報が含まれています。6.9.0 からの変更が含まれています。リリースタイムラインの詳細については、「変更ログ」を参照してください。

新機能

Amazon EMR 6.10.0 は、Apache Spark 3.3.1、Apache Spark RAPIDS 22.12.0、CUDA 11.8.0、Apache Hudi 0.12.2-amzn-0、Apache Iceberg 1.1.0-amzn-0、Trino 403、PrestoDB 0.278.1 をサポートしています。
Amazon EMR 6.10.0 には、Hudi テーブル内のデータへの読み取りアクセスを提供するネイティブ Trino-Hudi コネクタが含まれています。コネクタは trino-cli --catalog hudi で有効化でき、trino-connector-hudi との要件に合わせてコネクタを設定できます。Amazon EMR とのネイティブ統合により、Hudi テーブルのクエリに trino-connector-hive を使用する必要がなくなりました。新しいコネクタでサポートされる設定のリストについては、Trino のドキュメントの「Hudi connector」ページを参照してください。
Amazon EMR リリース 6.10.0 以降では、Apache Zeppelin と Apache Flink の統合がサポートされています。詳細については、「Amazon EMR の Zeppelin から Flink ジョブを操作する」を参照してください。

既知の問題点

Hadoop 3.3.3 では YARN (YARN-9608) に変更が加えられ、アプリケーションが完了するまでコンテナが実行されていたノードは廃止状態のままになります。この変更により、シャッフルデータなどのローカルデータが失われることはなく、ジョブを再実行する必要もなくなります。このアプローチでは、マネージドスケーリングが有効になっているかどうかにかかわらず、クラスターのリソースが十分に活用されない可能性もあります。

Amazon EMR 6.10.0 でこの問題を回避するには、yarn-site.xml の yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications の値を false に設定します。Amazon EMR リリース 6.11.0 以降および 6.8.1、6.9.1、6.10.1 では、この問題を解決するために設定がデフォルトで false にセットされています。

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

Amazon EMR 6.10.0 では、Apache Spark 用の Amazon Redshift の統合のために minimal-json.jar の依存関係が削除され、必要な Spark-Redshift 関連の jar が Spark のエグゼキュータークラスパス spark-redshift.jar、spark-avro.jar、および RedshiftJDBC.jar に自動的に追加されます。
6.10.0 リリースでは、クラスター上のログ管理デーモンが改善され、EMR クラスター内の追加のログフォルダを監視できるようになりました。この改善により、ディスクの過剰使用シナリオが最小限に抑えられます。
6.10.0 リリースでは、クラスター上のログ管理デーモンが停止すると、自動的に再起動されます。この改善により、ディスクの過剰使用が原因でノードが異常に見えるリスクが軽減されます。
Amazon EMR 6.10.0 は EMRFS ユーザーマッピング用のリージョンのエンドポイントをサポートしています。
Amazon EMR 6.10.0 以降では、デフォルトのルートボリュームサイズが 15 GB に増えました。以前のリリースでは、デフォルトのルートボリュームサイズは 10 GB でした。
6.10.0 リリースでは、残りのすべての Spark エグゼキューターが YARN リソースマネージャーを備えた廃止予定のホスト上にあるとき Spark ジョブが停止する問題が修正されています。
Amazon EMR 6.6.0 から 6.9.x では、動的パーティションと ORDER BY 句または SORT BY 句を使用した INSERT クエリには常に 2 つのリデューサーがあります。この問題は、OSS が変更された HIVE-20703 が原因です。これにより、動的ソートパーティションの最適化がコストベースの決定下に置かれます。ワークロードで動的パーティションのソートが不要な場合は、hive.optimize.sort.dynamic.partition.threshold プロパティを -1 に設定して新機能を無効にし、リデューサーの数を正しく計算することをお勧めします。この問題は、HIVE-22269 の一部として OSS Hive で修正され、Amazon EMR 6.10.0 で修正されています。

注記

OsReleaseLabel (Amazon Linux バージョン)	Amazon Linux カーネルバージョン	利用可能日	サポートされるリージョン
2.0.20230727.0	4.14.320	2023 年 8 月 14 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)、イスラエル (テルアビブ)
2.0.20230719.0	4.14.320	2023 年 8 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)、イスラエル (テルアビブ)
2.0.20230628.0	4.14.318	2023 年 7 月 12 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (ミラノ)、欧州 (スペイン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)
2.0.20230612.0	4.14.314	2023 年 6 月 23 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (ミラノ)、欧州 (スペイン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)
2.0.20230504.1	4.14.313	2023 年 5 月 16 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (ミラノ)、欧州 (スペイン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)
2.0.20230418.0	4.14.311	2023 年 5 月 3 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (ミラノ)、欧州 (スペイン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)
2.0.20230404.1	4.14.311	2023 年 4 月 18 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (UAE)
2.0.20230404.0	4.14.311	2023 年 4 月 10 日	米国東部 (バージニア北部)、欧州 (パリ)
2.0.20230320.0	4.14.309	2023 年 3 月 30 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (UAE)
2.0.20230207.0	4.14.304	2023 年 2 月 22 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (UAE)

リリース 6.9.0

次のリリースノートには、Amazon EMR リリース 6.9.0 に関する情報が含まれています。Amazon EMR リリース 6.8.0 からの変更が含まれています。リリースタイムラインの詳細については、「変更ログ」を参照してください。

新機能

Amazon EMR リリース 6.9.0 は、Apache Spark RAPIDS 22.08.0、Apache Hudi 0.12.1、Apache Iceberg 0.14.1、Trino 398、Tez 0.10.2 をサポートしています。
Amazon EMR リリース 6.9.0 には、新しいオープンソースアプリケーションである Delta Lake 2.1.0 が含まれています。
Apache Spark 用の Amazon Redshift の統合は、Amazon EMR リリース 6.9.0 以降に含まれています。以前はオープンソースツールであったこのネイティブインテグレーションは Spark コネクタと呼ばれるもので、これを使用して Apache Spark アプリケーションを構築することで、Amazon Redshift と Amazon Redshift Serverless 内のデータを読み書きできます。詳細については、「Amazon EMR での Apache Spark 用の Amazon Redshift インテグレーションの使用」を参照してください。
Amazon EMR リリース 6.9.0 では、クラスターのスケールダウン中に Amazon S3 にログをアーカイブするためのサポートが追加されています。以前は、Amazon S3 にログファイルをアーカイブできるのはクラスター終了時のみでした。この新機能により、クラスターで生成されたログファイルは、ノードが終了した後も Amazon S3 に残ります。詳細については、「クラスターのログ記録とデバッグを設定する」を参照してください。
長時間実行されるクエリをサポートするため、Trino には耐障害性実行メカニズムが組み込まれました。耐障害性実行では、失敗したクエリやそのコンポーネントタスクを再試行することで、クエリの失敗を軽減します。詳細については、「Trino での耐障害性実行」を参照してください。
Amazon EMR で Apache Flink を使用して、Apache Hive テーブル、または Iceberg、Kinesis、Kafka などの任意の Flink テーブルソースのメタデータの BATCH 処理と STREAM 処理を統合することができます。AWS Management Console、AWS CLI、または Amazon EMR API を使用して、AWS Glue Data Catalog を Flink のメタストアとして指定できます。詳細については、「Amazon EMR で Flink を設定する」を参照してください。
Amazon SageMaker Studio が含まれる EC2 クラスター上の Amazon EMR の Apache Spark、Apache Hive、および Presto クエリの AWS Identity and Access Management (IAM) ランタイムロールと AWS Lake Formation ベースのアクセスコントロールを指定できるようになりました。詳細については、「Configure runtime roles for Amazon EMR steps」を参照してください。

既知の問題点

Amazon EMR リリース 6.9.0 では、Apache Ranger が有効になっているクラスターでは Trino は動作しません。Ranger で Trino を使用する必要がある場合は、AWS Support にお問い合わせください。
Amazon Redshift integration for Apache Spark を使用している場合に、time、timetz、timestamp、timestamptz のいずれかにマイクロ秒の精度を Parquet 形式で設定していると、コネクタがその時間値を最も近いミリ秒値に四捨五入します。回避策として、テキストアンロード形式 unload_s3_format パラメータを使用してください。
Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。
Amazon SageMaker Studio から Amazon EMR クラスターへの接続は、403 Forbidden レスポンスコードで断続的に失敗することがあります。このエラーは、クラスターでの IAM ロールの設定に 60 秒以上かかる場合に発生します。回避策として、Amazon EMR パッチをインストールして再試行を有効にし、タイムアウトを最低 300 秒に増やすことができます。以下の手順を使用して、クラスターの起動時にブートストラップアクションを適用します。
1. 次の Amazon S3 URI から、ブートストラップスクリプトと RPM ファイルをダウンロードします。
```
s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/gcsc/replace-rpms.sh
s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/gcsc/emr-secret-agent-1.18.0-SNAPSHOT20221121212949.noarch.rpm
```
2. 前のステップのファイルを、所有する Amazon S3 バケットにアップロードします。バケットは、クラスターの起動を予定している同じ AWS リージョンに存在している必要があります。
3. EMR クラスターを起動するときに、次のブートストラップアクションを含めます。bootstrap_URI と RPM_URI を Amazon S3 の対応する URI に置き換えます。
```
--bootstrap-actions "Path=bootstrap_URI,Args=[RPM_URI]"
```
Amazon EMR リリース 5.36.0、および 6.6.0 から 6.9.0 では、Log4j2 プロパティのファイル名パターン設定が正しくないため、SecretAgent および RecordServer サービスコンポーネントでログデータが失われる可能性があります。設定が正しくないと、コンポーネントは 1 日に 1 つのログファイルしか生成しません。ローテーション戦略が実行されると、期待どおりに新しいログファイルが生成されず、既存のファイルが上書きされます。回避策として、ブートストラップアクションを使用して 1 時間ごとにログファイルを生成し、ファイル名に自動増分整数を追加してローテーションを処理します。

Amazon EMR 6.6.0 から 6.9.0 のリリースでは、クラスターを起動するときに次のブートストラップアクションを使用します。
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
```
Amazon EMR 5.36.0 では、クラスターを起動するときに次のブートストラップアクションを使用します。
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
```
Apache Flink にはネイティブ S3 FileSystem コネクタと Hadoop FileSystem コネクタが用意されており、アプリケーションが FileSink を作成して Amazon S3 にデータを書き込むことができます。この FileSink は、次の 2 つの例外のいずれかにより失敗します。
```
java.lang.UnsupportedOperationException: Recoverable writers on Hadoop are only supported for HDFS
```
```
Caused by: java.lang.NoSuchMethodError: org.apache.hadoop.io.retry.RetryPolicies.retryOtherThanRemoteAndSaslException(Lorg/apache/hadoop/io/retry/RetryPolicy;Ljava/util/Map;)Lorg/apache/hadoop/io/retry/RetryPolicy;
                                        at org.apache.hadoop.yarn.client.RMProxy.createRetryPolicy(RMProxy.java:302) ~[hadoop-yarn-common-3.3.3-amzn-0.jar:?]
```
回避策として、Flink の上記の問題を修正する Amazon EMR パッチをインストールできます。クラスターを起動するときにブートストラップアクションを適用するには、以下の手順を実行します。
1. flink-rpm を Amazon S3 バケットにダウンロードします。RPM パスは s3://DOC-EXAMPLE-BUCKET/rpms/flink/ です。
2. 次の URI を使用して Amazon S3 からブートストラップスクリプトと RPM ファイルをダウンロードします。regionName は、クラスターを起動する予定の AWS リージョンに置き換えます。
```
s3://emr-data-access-control-regionName/customer-bootstrap-actions/gcsc/replace-rpms.sh
```
3. Hadoop 3.3.3 では YARN (YARN-9608) に変更が加えられ、アプリケーションが完了するまでコンテナが実行されていたノードは廃止状態のままになります。この変更により、シャッフルデータなどのローカルデータが失われることはなく、ジョブを再実行する必要もなくなります。Amazon EMR 6.8.0 および 6.9.0 の場合、この方法では、マネージドスケーリングが有効になっているかどうかにかかわらず、クラスターのリソースが十分に活用されない可能性もあります。
  
  Amazon EMR 6.10.0 では、yarn-site.xml の yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications の値を false に設定することでこの問題を回避できます。Amazon EMR リリース 6.11.0 以降および 6.8.1、6.9.1、6.10.1 では、この問題を解決するために設定がデフォルトで false にセットされています。

変更、拡張、解決した問題

Amazon EMR リリース 6.9.0 以降では、Amazon EMR によってインストールされ、Log4j ライブラリを使用するすべてのコンポーネントは Log4j バージョン 2.17.1 以降を使用します。
Spark on Amazon EMR バージョン 6.6.0、6.7.0、6.8.0 で DynamoDB コネクタを使用すると、テーブルから何を読み込んでも空の結果が返されます。この状況は、入力分割が空でないデータを参照している場合でも変わりません。Amazon EMR リリース 6.9.0 では、この問題が修正されています。
Amazon EMR 6.9.0 では、Spark SQL を使用してデータを読み取る際の Apache Hudi による Lake Formation ベースのアクセスコントロールに対する限定的なサポートが追加されています。Spark SQL を使用する SELECT クエリがサポートされます。サポートは、列レベルのアクセス制御に限定されます。詳細については、「Hudi と Lake Formation」を参照してください。
Amazon EMR 6.9.0 を使用して、ノードラベルを有効にした Hadoop クラスターを作成すると、YARN メトリクス API はデフォルトのパーティションではなく、すべてのパーティションの集計情報を返します。詳細については、「YARN-11414」を参照してください。
Amazon EMR リリース 6.9.0 では、Trino を、Java 17 を使用するバージョン 398 にアップデートしました。Amazon EMR 6.8.0 で以前サポートされていた Trino のバージョンは Java 11 で動作する Trino 388 でした。この変更の詳細については、Trino のブログの「Trino updates to Java 17」を参照してください。
このリリースでは、EC2 クラスターの起動シーケンスでの Apache BigTop と Amazon EMR 間のタイミングシーケンスの不一致の問題が修正されています。このタイミングシーケンスの不一致は、システムが 2 つ以上の操作を適切なシーケンスで実行するのではなく、同時に実行しようとした場合に発生します。その結果、特定のクラスター構成でインスタンスの起動がタイムアウトし、クラスターの起動時間が遅くなりました。

注記

OsReleaseLabel (Amazon Linux バージョン)	Amazon Linux カーネルバージョン	利用可能日	サポートされるリージョン
2.0.20230727.0	4.14.320	2023 年 8 月 14 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)、イスラエル (テルアビブ)
2.0.20230719.0	4.14.320	2023 年 8 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)、イスラエル (テルアビブ)
2.0.20230628.0	4.14.318	2023 年 7 月 12 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230612.0	4.14.314	2023 年 6 月 23 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230504.1	4.14.313	2023 年 5 月 16 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230418.0	4.14.311	2023 年 5 月 3 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230404.1	4.14.311	2023 年 4 月 18 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230404.0	4.14.311	2023 年 4 月 10 日	米国東部 (バージニア北部)、欧州 (パリ)
2.0.20230320.0	4.14.309	2023 年 3 月 30 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230307.0	4.14.305	2023 年 3 月 15 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230207.0	4.14.304	2023 年 2 月 22 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221210.1	4.14.301	2023 年 1 月 12 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221103.3	4.14.296	2022 年 12 月 5 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)

リリース 6.8.0

次のリリースノートには、Amazon EMR リリース 6.8.0 に関する情報が含まれています。6.7.0 からの変更が含まれています。

新機能

Amazon EMR ステップ機能が Apache Livy エンドポイントと JDBC/ODBC クライアントをサポートするようになりました。詳細については、「Configure runtime roles for Amazon EMR steps」を参照してください。
Amazon EMR リリース 6.8.0 には Apache HBase リリース 2.4.12 が付属しています。この HBase リリースでは、HBase テーブルのアーカイブと削除の両方を行うことができます。Amazon S3 アーカイブプロセスでは、すべてのテーブルファイルの名前がアーカイブディレクトリに変更されます。このプロセスにはコストがかかり、時間を要する場合があります。これで、アーカイブプロセスをスキップして、大きなテーブルをすばやく削除することができます。詳細については、「HBase シェルを使用する」を参照してください。

既知の問題点

Hadoop 3.3.3 では YARN (YARN-9608) に変更が加えられ、アプリケーションが完了するまでコンテナが実行されていたノードは廃止状態のままになります。この変更により、シャッフルデータなどのローカルデータが失われることはなく、ジョブを再実行する必要もなくなります。Amazon EMR 6.8.0 および 6.9.0 の場合、この方法では、マネージドスケーリングが有効になっているかどうかにかかわらず、クラスターのリソースが十分に活用されない可能性もあります。

Amazon EMR 6.10.0 では、yarn-site.xml の yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications の値を false に設定することでこの問題を回避できます。Amazon EMR リリース 6.11.0 以降および 6.8.1、6.9.1、6.10.1 では、この問題を解決するために設定がデフォルトで false にセットされています。

変更、拡張、解決した問題

Amazon EMR リリース 6.5.0、6.6.0、または 6.7.0 が Apache Spark シェルを介して Apache Phoenix テーブルを読み取ると、Amazon EMR は NoSuchMethodError を生成しました。Amazon EMR リリース 6.8.0 では、この問題が修正されています。
Amazon EMR リリース 6.8.0 には Apache Hudi 0.11.1 が付属していますが、Amazon EMR 6.8.0 クラスターは Hudi 0.12.0 のオープンソース hudi-spark3.3-bundle_2.12 とも互換性があります。
Amazon EMR リリース 6.8.0 には、Apache Spark 3.3.0 が付属しています。この Spark リリースでは、Apache Log4j 2 と log4j2.properties ファイルを使用して Spark プロセス内の Log4j を設定します。クラスターで Spark を使用するか、カスタム設定パラメータを使用して EMR クラスターを作成し、Amazon EMR リリース 6.8.0 にアップグレードする場合は、Apache Log4j 2 の新しい spark-log4j2 設定分類とキー形式に移行する必要があります。詳細については、「Apache Log4j 1.x から Log4j 2.x への移行」を参照してください。

注記

OsReleaseLabel (Amazon Linux バージョン)	Amazon Linux カーネルバージョン	利用可能日	サポートされるリージョン
2.0.20230727.0	4.14.320	2023 年 8 月 14 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、カナダ (中部)
2.0.20230719.0	4.14.320	2023 年 8 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)
2.0.20230628.0	4.14.318	2023 年 7 月 12 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230612.0	4.14.314	2023 年 6 月 23 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230504.1	4.14.313	2023 年 5 月 16 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230418.0	4.14.311	2023 年 5 月 3 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230404.1	4.14.311	2023 年 4 月 18 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230404.0	4.14.311	2023 年 4 月 10 日	米国東部 (バージニア北部)、欧州 (パリ)
2.0.20230320.0	4.14.309	2023 年 3 月 30 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230307.0	4.14.305	2023 年 3 月 15 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230207.0	4.14.304	2023 年 2 月 22 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230119.1	4.14.301	2023 年 2 月 3 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221210.1	4.14.301	2023 年 12 月 22 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221103.3	4.14.296	2022 年 12 月 5 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221004.0	4.14.294	2022 年 11 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20220912.1	4.14.291	2022 年 9 月 6 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)

既知の問題点

Spark on Amazon EMR バージョン 6.6.0、6.7.0、6.8.0 で DynamoDB コネクタを使用すると、テーブルから何を読み込んでも空の結果が返されます。この状況は、入力分割が空でないデータを参照している場合でも変わりません。これは、Spark 3.2.0 が spark.hadoopRDD.ignoreEmptySplits をデフォルトで true に設定しているためです。回避策として、明示的に spark.hadoopRDD.ignoreEmptySplits を false に設定します。Amazon EMR リリース 6.9.0 では、この問題が修正されています。
Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。
Amazon EMR リリース 5.36.0、および 6.6.0 から 6.9.0 では、Log4j2 プロパティのファイル名パターン設定が正しくないため、SecretAgent および RecordServer サービスコンポーネントでログデータが失われる可能性があります。設定が正しくないと、コンポーネントは 1 日に 1 つのログファイルしか生成しません。ローテーション戦略が実行されると、期待どおりに新しいログファイルが生成されず、既存のファイルが上書きされます。回避策として、ブートストラップアクションを使用して 1 時間ごとにログファイルを生成し、ファイル名に自動増分整数を追加してローテーションを処理します。

Amazon EMR 6.6.0 から 6.9.0 のリリースでは、クラスターを起動するときに次のブートストラップアクションを使用します。
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
```
Amazon EMR 5.36.0 では、クラスターを起動するときに次のブートストラップアクションを使用します。
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
```

リリースタイムラインの詳細については、「変更ログ」を参照してください。

リリース 6.7.0

次のリリースノートには、Amazon EMR リリース 6.7.0 に関する情報が含まれています。6.6.0 からの変更が含まれています。

初回リリース日: 2022 年 7 月 15 日

新機能

Amazon EMR は Apache Spark 3.2.1、Apache Hive 3.1.3、HUDI 0.11、PrestoDB 0.272、Trino 0.378 をサポートするようになりました。
EC2 クラスター上の Amazon EMR 用の EMR ステップ (Spark、Hive) による IAM ロールおよび Lake Formation ベースのアクセスコントロールをサポートします。
Apache Ranger 対応クラスターでの Apache Spark データ定義ステートメントをサポートします。これには、Apache Ranger 対応クラスターで Apache Hive メタデータを読み書きする Trino アプリケーションのサポートが含まれるようになりました。詳細については、「Enable federated governance using Trino and Apache Ranger on Amazon EMR」を参照してください。

OsReleaseLabel (Amazon Linux バージョン)	Amazon Linux カーネルバージョン	利用可能日	サポートされるリージョン
2.0.20230727.0	4.14.320	2023 年 8 月 14 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、カナダ (中部)
2.0.20230719.0	4.14.320	2023 年 8 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)
2.0.20230628.0	4.14.318	2023 年 7 月 12 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230612.0	4.14.314	2023 年 6 月 23 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230504.1	4.14.313	2023 年 5 月 16 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230418.0	4.14.311	2023 年 5 月 3 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230404.1	4.14.311	2023 年 4 月 18 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230404.0	4.14.311	2023 年 4 月 10 日	米国東部 (バージニア北部)、欧州 (パリ)
2.0.20230320.0	4.14.309	2023 年 3 月 30 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230307.0	4.14.305	2023 年 3 月 15 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230207.0	4.14.304	2023 年 2 月 22 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230119.1	4.14.301	2023 年 2 月 3 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221210.1	4.14.301	2023 年 12 月 22 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221103.3	4.14.296	2022 年 12 月 5 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221004.0	4.14.294	2022 年 11 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20220912.1	4.14.291	2022 年 10 月 7 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20220719.0	4.14.287	2022 年 8 月 10 日	`us‑west‑1`, `eu‑west‑3`, `eu‑north‑1`, `ap‑south‑1`, `me‑south‑1`
2.0.20220606.1	4.14.281	2022 年 7 月 15 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)

既知の問題点

Amazon EMR リリース 6.5.0、6.6.0、または 6.7.0 が Apache Spark シェルを介して Apache Phoenix テーブルを読み取ると、Amazon EMR が誤った Hbase.compat.version を使用しているため、NoSuchMethodError が発生します。Amazon EMR リリース 6.8.0 では、この問題が修正されています。
Spark on Amazon EMR バージョン 6.6.0、6.7.0、6.8.0 で DynamoDB コネクタを使用すると、テーブルから何を読み込んでも空の結果が返されます。この状況は、入力分割が空でないデータを参照している場合でも変わりません。これは、Spark 3.2.0 が spark.hadoopRDD.ignoreEmptySplits をデフォルトで true に設定しているためです。回避策として、明示的に spark.hadoopRDD.ignoreEmptySplits を false に設定します。Amazon EMR リリース 6.9.0 では、この問題が修正されています。
Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。
Amazon EMR リリース 5.36.0、および 6.6.0 から 6.9.0 では、Log4j2 プロパティのファイル名パターン設定が正しくないため、SecretAgent および RecordServer サービスコンポーネントでログデータが失われる可能性があります。設定が正しくないと、コンポーネントは 1 日に 1 つのログファイルしか生成しません。ローテーション戦略が実行されると、期待どおりに新しいログファイルが生成されず、既存のファイルが上書きされます。回避策として、ブートストラップアクションを使用して 1 時間ごとにログファイルを生成し、ファイル名に自動増分整数を追加してローテーションを処理します。

Amazon EMR 6.6.0 から 6.9.0 のリリースでは、クラスターを起動するときに次のブートストラップアクションを使用します。
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
```
Amazon EMR 5.36.0 では、クラスターを起動するときに次のブートストラップアクションを使用します。
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
```

リリース 6.6.0

次のリリースノートには、Amazon EMR リリース 6.6.0 に関する情報が含まれています。6.5.0 からの変更が含まれています。

初回リリース日: 2022 年 5 月 9 日

ドキュメント更新日: 2022 年 6 月 15 日

新機能

Amazon EMR 6.6 は、Apache Spark 3.2、Apache Spark RAPIDS 22.02、CUDA 11、Apache Hudi 0.10.1、Apache Iceberg 0.13、Trino 0.367、PrestoDB 0.267 をサポートするようになりました。

OsReleaseLabel (Amazon Linux バージョン)	Amazon Linux カーネルバージョン	利用可能日	サポートされるリージョン
2.0.20230727.0	4.14.320	2023 年 8 月 14 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、カナダ (中部)
2.0.20230719.0	4.14.320	2023 年 8 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)、中東 (アラブ首長国連邦)、カナダ (中部)
2.0.20230628.0	4.14.318	2023 年 7 月 12 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230612.0	4.14.314	2023 年 6 月 23 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230504.1	4.14.313	2023 年 5 月 16 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230418.0	4.14.311	2023 年 5 月 3 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230404.1	4.14.311	2023 年 4 月 18 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230404.0	4.14.311	2023 年 4 月 10 日	米国東部 (バージニア北部)、欧州 (パリ)
2.0.20230320.0	4.14.309	2023 年 3 月 30 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230307.0	4.14.305	2023 年 3 月 15 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230207.0	4.14.304	2023 年 2 月 22 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20230119.1	4.14.301	2023 年 2 月 3 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221210.1	4.14.301	2023 年 12 月 22 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221103.3	4.14.296	2022 年 12 月 5 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20221004.0	4.14.294	2022 年 11 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20220912.1	4.14.291	2022 年 10 月 7 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20220805.0	4.14.287	2022 年 8 月 30 日	`us‑west‑1`
2.0.20220719.0	4.14.287	2022 年 8 月 10 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20220426.0	4.14.281	2022 年 6 月 10 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)
2.0.20220406.1	4.14.275	2022 年 5 月 2 日	米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、欧州 (ストックホルム)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アフリカ (ケープタウン)、南米 (サンパウロ)、中東 (バーレーン)

Amazon EMR 6.6 以降では、Log4j 1.x と Log4j 2.x を使用するアプリケーションは、それぞれ Log4j 1.2.17 (またはそれ以上) と Log4j 2.17.1 (またはそれ以上) を使用するようにアップグレードされます。CVE の問題を軽減するために提供されているブートストラップアクションを使用する必要はなくなります。
[マネージドスケーリング] Spark シャッフルデータマネージドスケーリング最適化 - Amazon EMR バージョン 5.34.0 以降、および EMR バージョン 6.4.0 以降では、マネージドスケーリングは Spark シャッフルデータ (Spark が特定の操作を実行するためにパーティション間で再分配するデータ) 対応になりました。シャッフル操作の詳細については、「Amazon EMR 管理ガイド」および「Spark のプログラミングガイド」の「Amazon EMR での EMR マネージドスケーリングの使用」を参照してください。
Amazon EMR 5.32.0 および 6.5.0 以降、Apache Spark の動的エグゼキューターサイズ設定はデフォルトで有効になっています。この機能をオンまたはオフにするには、spark.yarn.heterogeneousExecutors.enabled 設定パラメータを使用できます。

変更、拡張、解決した問題

Amazon EMR は、EMR のデフォルト AMI オプションを使用し、Apache Hadoop、Apache Spark、Apache Hive などの一般的なアプリケーションのみをインストールするクラスターの場合、クラスターの起動時間を平均で最大 80 秒短縮します。

既知の問題点

Amazon EMR リリース 6.5.0、6.6.0、または 6.7.0 が Apache Spark シェルを介して Apache Phoenix テーブルを読み取ると、Amazon EMR が誤った Hbase.compat.version を使用しているため、NoSuchMethodError が発生します。Amazon EMR リリース 6.8.0 では、この問題が修正されています。
Spark on Amazon EMR バージョン 6.6.0、6.7.0、6.8.0 で DynamoDB コネクタを使用すると、テーブルから何を読み込んでも空の結果が返されます。この状況は、入力分割が空でないデータを参照している場合でも変わりません。これは、Spark 3.2.0 が spark.hadoopRDD.ignoreEmptySplits をデフォルトで true に設定しているためです。回避策として、明示的に spark.hadoopRDD.ignoreEmptySplits を false に設定します。Amazon EMR リリース 6.9.0 では、この問題が修正されています。
Trino の長時間稼働クラスターでは、Amazon EMR 6.6.0 は Trino jvm.config のガベージコレクションログ記録パラメータを有効にして、ガベージコレクションログからより深い知見を得ることができます。この変更により、launcher.log (/var/log/trino/launcher.log) ファイルに多くのガベージコレクションログが追加されます。Amazon EMR 6.6.0 で Trino クラスターを実行している場合、追加されたログが原因で、クラスターを数日間実行した後にノードのディスク容量が不足することがあります。

この問題の回避策は、Amazon EMR 6.6.0 のクラスターを作成またはクローン作成する際に、以下のスクリプトをブートストラップアクションとして実行し、jvm.config のガベージコレクションログ記録パラメータを無効にすることです。
```
#!/bin/bash
  set -ex
  PRESTO_PUPPET_DIR='/var/aws/emr/bigtop-deploy/puppet/modules/trino'
  sudo bash -c "sed -i '/-Xlog/d' ${PRESTO_PUPPET_DIR}/templates/jvm.config"
```
Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。
Amazon EMR リリース 5.36.0、および 6.6.0 から 6.9.0 では、Log4j2 プロパティのファイル名パターン設定が正しくないため、SecretAgent および RecordServer サービスコンポーネントでログデータが失われる可能性があります。設定が正しくないと、コンポーネントは 1 日に 1 つのログファイルしか生成しません。ローテーション戦略が実行されると、期待どおりに新しいログファイルが生成されず、既存のファイルが上書きされます。回避策として、ブートストラップアクションを使用して 1 時間ごとにログファイルを生成し、ファイル名に自動増分整数を追加してローテーションを処理します。

Amazon EMR 6.6.0 から 6.9.0 のリリースでは、クラスターを起動するときに次のブートストラップアクションを使用します。
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
```
Amazon EMR 5.36.0 では、クラスターを起動するときに次のブートストラップアクションを使用します。
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
```

リリース 5.35.0

これは Amazon EMR リリース 5.35.0 のリリースノートです。

次のリリースノートには、Amazon EMR リリース 5.35.0 に関する情報が含まれています。5.34.0 からの変更が含まれています。

初回リリース日: 2022 年 3 月 30 日

新機能

Log4j 1.x と Log4j 2.x を使用する Amazon EMR リリース 5.35 アプリケーションは、それぞれ Log4j 1.2.17 (またはそれ以上) と Log4j 2.17.1 (またはそれ以上) を使用するようにアップグレードされます。以前のリリースの CVE の問題を軽減するためにブートストラップアクションを使用する必要はなくなります。「 CVE-2021-44228 を軽減するためのアプローチ」を参照してください。

変更、拡張、解決した問題

Flink の変更
タイプの変更	説明
アップグレード	Flink のバージョンを 1.14.2 にアップデートします。 log4j は 2.17.1 にアップグレードされました。

Hadoop の変更
タイプの変更	説明
EMR 5.34.0 以降の Hadoop オープンソースバックポート	YARN-10438: ClientRMService#getContainerReport() で null containerId を処理 YARN-7266: タイムラインサーバーのイベントハンドラースレッドがロックされている YARN-10438: RollingLevelDb ファイルが破損しているか、見つからない場合、ATS 1.5 が起動に失敗する HADOOP-13500: 設定プロパティオブジェクトのイテレーションの同期 YARN-10651: AbstractYarnScheduler.updateNodeResource() の NPE で CapacityScheduler がクラッシュする HDFS-12221: XmlEditsVisitor 内の xerces を置き換える HDFS-16410: OfflineEditsXmlLoader での XML 解析のセキュリティが保護されていない
Hadoop の変更と修正	KMS と HttpFS で使用されている Tomcat が 8.5.75 にアップグレードされました。 FileSystemOptimizedCommitterV2 で、コミッターの作成時に定義された commitJob 出力パスに成功マーカーが書き込まれました。commitJob とタスクレベルの出力パスは異なる場合があるため、マニフェストファイルで定義されているものを使用するようにパスが修正されました。これにより、Hive ジョブで、動的パーティションや UNION ALL などの操作を実行すると、成功マーカーが正しく書き込まれるようになりました。

Hive の変更点
タイプの変更	説明
Hive がオープンソースリリース 2.3.9 にアップグレードされました (これらの JIRA の修正を含む)	HIVE-17155: HiveConf.java の findConfFile() の設定パスにいくつか問題がある HIVE-24797: Avro スキーマを解析するときのデフォルト値の検証を無効にする HIVE-21563: registerAllFunctionsOnce を無効にすることで Table#getEmptyTable のパフォーマンスを向上させる HIVE-18147: java.net.BindException が発生してテストが失敗することがある: アドレスが既に使用されている HIVE-24608: Hive 2.3.x の HMS クライアントで get_table に切り替える HIVE-21200: ベクトル化 - Parquet の java.lang.UnsupportedOperationException をスローする日付列 HIVE-19228: commons-httpclient 3.x の使用を削除する
EMR 5.34.0 以降の Hive オープンソースバックポート	HIVE-19990: 結合条件に間隔のリテラルを含むクエリが失敗する HIVE-25824: branch-2.3 を log4j 2.17.0 にアップグレードする TEZ-4062: 投機的試行のスケジューリングはタスクが完了したら中止する必要がある TEZ-4108: 投機的実行の競合状態中の NullPointerException TEZ-3918: tez.task.log.level を設定しても機能しない
Hive のアップグレードと修正	Log4j バージョンの 2.17.1 へのアップグレード ORC バージョンの 1.4.3 へのアップグレード ShuffleScheduler のペナルティスレッドによる FixED のデッドロック
新機能	Hive クエリを AM ログに出力する機能が追加されました。これはデフォルトでは無効になっています。フラグ/設定: `tez.am.emr.print.hive.query.in.log`。ステータス (デフォルト): FALSE。

Oozie の変更
タイプの変更	説明
EMR 5.34.0 以降の Oozie オープンソースバックポート	OOZIE-3652: Oozie ランチャーは NoSuchFileException が発生した場合にディレクトリのリスト化を再試行する必要がある

Pig の変更
タイプの変更	説明
アップグレード	log4j は 1.2.17 にアップグレードされました。

既知の問題

Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。

リリース 5.34.0

次のリリースノートには、Amazon EMR リリース 5.34.0 に関する情報が含まれています。5.33.1 からの変更が含まれています。

初回リリース日: 2022 年 1 月 20 日

更新リリース日: 2022 年 3 月 21 日

新機能

[マネージドスケーリング] Spark シャッフルデータマネージドスケーリング最適化 - Amazon EMR バージョン 5.34.0 以降、および EMR バージョン 6.4.0 以降では、マネージドスケーリングは Spark シャッフルデータ (Spark が特定の操作を実行するためにパーティション間で再分配するデータ) 対応になりました。シャッフル操作の詳細については、「Amazon EMR 管理ガイド」および「Spark のプログラミングガイド」の「Amazon EMR での EMR マネージドスケーリングの使用」を参照してください。
[Hudi] Hudi の設定を簡素化するための改良点。オプティミスティック同時実行制御をデフォルトで無効にしました。

変更、拡張、解決した問題

これは、Amazon EMR Scaling がクラスターを正常にスケールアップ/スケールダウンできない場合や、アプリケーション障害を引き起こした場合の問題点を修正するためのリリースです。
以前は、マルチマスタークラスターでリソースマネージャーを手動で再起動すると、Zookeeper などの Amazon EMR のクラスター上のデーモンが、Zookeeper znode ファイル内の以前に廃止された、または失われたすべてのノードを再ロードしていました。これにより、特定の状況でデフォルトの制限を超えることがありました。Amazon EMR では、1 時間以上経過した、廃止された、または失われたノードレコードが Zookeeper ファイルから削除されるようになり、内部制限も引き上げられました。
Amazon EMR のクラスター上のデーモンが YARN ノード状態や HDFS ノード状態の収集などのヘルスチェックアクティビティを実行しているときに、大規模で使用率の高いクラスターのスケーリングリクエストが失敗する問題を修正しました。これは、クラスター上のデーモンがノードのヘルスステータスデータを内部の Amazon EMR コンポーネントに伝達できなかったために発生していました。
EMR のクラスター上のデーモンが改善され、IP アドレスが再利用されるときにノードの状態を正しく追跡できるようになり、スケーリング操作中の信頼性が向上しました。
SPARK-29683。Spark が使用可能なすべてのノードが拒否リストに登録されていると想定していたため、クラスターのスケールダウン中にジョブエラーが発生する問題を修正しました。
YARN-9011。クラスターがスケールアップまたはスケールダウンを試みたときに YARN 廃止の競合状態が原因でジョブ障害が発生する問題を修正しました。
Amazon EMR のクラスター上のデーモンと YARN/HDFS の間でノードの状態が常に一致するようにすることで、クラスターのスケーリング中のステップまたはジョブの障害に関する問題を修正しました。
Kerberos 認証で有効になっている Amazon EMR クラスターで、スケールダウンやステップ送信などのクラスター操作が失敗する問題を修正しました。これは、Amazon EMR のクラスター上のデーモンが、プライマリノードで実行されている HDFS/YARN と安全に通信するために必要な Kerberos チケットを更新しなかったためです。
Zeppelin をバージョン 0.10.0 にアップグレードしました。
Livy Fix - 0.7.1 にアップグレード
Spark のパフォーマンスの向上 - EMR 5.34.0 で特定の Spark 設定値がオーバーライドされると、異種エグゼキューターが無効になります。
WebHDFS と HttpFS サーバーはデフォルトで無効になっています。Hadoop 設定 dfs.webhdfs.enabled を使用して WebHDF を再度有効にすることができます。HttpFS サーバーを起動するには、sudo systemctl start hadoop-httpfs を使用します。

既知の問題点

Livy ユーザー偽装で使用される Amazon EMR Notebooks 機能は、HttpFS がデフォルトで無効になっているため機能しません。この場合、EMR notebooks は Livy 偽装が有効になっているクラスターに接続できません。回避策は、sudo systemctl start hadoop-httpfs を使用して EMR notebooks をクラスターに接続する前に、HttpFS サーバーを起動することです。
Apache Hadoop HttpFS サーバーはデフォルトで無効になるため、Hue クエリは Amazon EMR 6.4.0 では機能しません。Amazon EMR 6.4.0 で Hue を使用するには、sudo systemctl start hadoop-httpfs を使用して Amazon EMR プライマリノードで HttpFS サーバーを手動で起動するか、または Amazon EMR のステップを使用します。
Livy ユーザー偽装で使用される Amazon EMR Notebooks 機能は、HttpFS がデフォルトで無効になっているため機能しません。この場合、EMR notebooks は Livy 偽装が有効になっているクラスターに接続できません。回避策は、sudo systemctl start hadoop-httpfs を使用して EMR notebooks をクラスターに接続する前に、HttpFS サーバーを起動することです。
Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。

リリース 6.5.0

次のリリースノートには、Amazon EMR リリース 6.5.0 に関する情報が含まれています。6.4.0 からの変更が含まれています。

初回リリース日: 2022 年 1 月 20 日

更新リリース日: 2022 年 3 月 21 日

新機能

[マネージドスケーリング] Spark シャッフルデータマネージドスケーリング最適化 - Amazon EMR バージョン 5.34.0 以降、および EMR バージョン 6.4.0 以降では、マネージドスケーリングは Spark シャッフルデータ (Spark が特定の操作を実行するためにパーティション間で再分配するデータ) 対応になりました。シャッフル操作の詳細については、「Amazon EMR 管理ガイド」および「Spark のプログラミングガイド」の「Amazon EMR での EMR マネージドスケーリングの使用」を参照してください。
Amazon EMR 5.32.0 および 6.5.0 以降、Apache Spark の動的エグゼキューターサイズ設定はデフォルトで有効になっています。この機能をオンまたはオフにするには、spark.yarn.heterogeneousExecutors.enabled 設定パラメータを使用できます。
巨大な分析データセット用の Apache Iceberg オープンテーブル形式のサポート。
ranger-trino-plugin 2.0.1-amzn-1 のサポート
toree 0.5.0 のサポート

変更、拡張、解決した問題

Amazon EMR 6.5 リリースバージョンは Apache Iceberg 0.12.0 をサポートするようになり、Apache Spark 用 Amazon EMR ランタイム、Presto 用 Amazon EMR ランタイム、Apache Hive 用 Amazon EMR ランタイムによりランタイムが改善されています。
Apache Iceberg は、Amazon S3 の大規模データセット用のオープンテーブル形式であり、大きなテーブルに対する高速のクエリパフォーマンス、アトミックコミット、同時書き込み、および SQL 互換テーブルの進化を提供します。EMR 6.5 では、Apache Spark 3.1.2 を Iceberg テーブル形式で使用できます。
Apache Hudi 0.9 では Spark SQL DDL と DML のサポートが追加されています。これにより、SQL ステートメントだけを使用して Hudi テーブルを作成し、アップサートできるようになりました。Apache Hudi 0.9 では、クエリ側とライター側のパフォーマンスも向上しています。
Apache Hive 用 Amazon EMR ランタイムは、ステージング操作中の名前変更操作を削除することで Amazon S3 での Apache Hive のパフォーマンスを向上させ、テーブルの修復に使用されるメタストアチェック (MSCK) コマンドのパフォーマンスを向上させます。

既知の問題点

Amazon EMR リリース 6.5.0、6.6.0、または 6.7.0 が Apache Spark シェルを介して Apache Phoenix テーブルを読み取ると、Amazon EMR が誤った Hbase.compat.version を使用しているため、NoSuchMethodError が発生します。Amazon EMR リリース 6.8.0 では、この問題が修正されています。
高可用性 (HA) の Hbase バンドルクラスターは、デフォルトのボリュームサイズとインスタンスタイプではプロビジョニングに失敗します。この問題の回避策は、ルートボリュームのサイズを増やすことです。
Apache Oozie で Spark アクションを使用するには、以下の設定を Oozie workflow.xml ファイルに追加する必要があります。そうしないと、Hadoop や EMRFS などのいくつかの重要なライブラリが、Oozie が起動する Spark エグゼキューターのクラスパスから失われてしまいます。
```
<spark-opts>--conf spark.yarn.populateHadoopClasspath=true</spark-opts>
```
Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。

リリース 6.4.0

次のリリースノートには、Amazon EMR リリース 6.4.0 に関する情報が含まれています。6.3.0 からの変更が含まれています。

初回リリース日: 2021 年 9 月 20 日

更新リリース日: 2022 年 3 月 21 日

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

AWS SDK for Java バージョン 1.12.31
CloudWatch Sink バージョン 2.2.0
DynamoDB Connector バージョン 4.16.0
EMRFS バージョン 2.47.0
Amazon EMR Goodies バージョン 3.2.0
Amazon EMR Kinesis Connector バージョン 3.5.0
Amazon EMR Record Server バージョン 2.1.0
Amazon EMR Scripts バージョン 2.5.0
Flink バージョン 1.13.1
Ganglia バージョン 3.7.2
AWS Glue Hive Metastore Client バージョン 3.3.0
Hadoop バージョン 3.2.1-amzn-4
HBase バージョン 2.4.4-amzn-0
HBase-operator-tools 1.1.0
HCatalog バージョン 3.1.2-amzn-5
Hive バージョン 3.1.2-amzn-5
Hudi バージョン 0.8.0-amzn-0
Hue バージョン 4.9.0
Java JDK バージョン Corretto-8.302.08.1 (ビルド 1.8.0_302-b08)
JupyterHub バージョン 1.4.1
Livy バージョン 0.7.1-incubating
MXNet バージョン 1.8.0
Oozie バージョン 5.2.1
Phoenix バージョン 5.1.2
Pig バージョン 0.17.0
Presto バージョン 0.254.1-amzn-0
Trino バージョン 359
Apache Ranger KMS (マルチマスター透過的暗号化) バージョン 2.0.0
ranger-plugins 2.0.1-amzn-0
ranger-s3-plugin 1.2.0
SageMaker Spark SDK バージョン 1.4.1
Scala バージョン 2.12.10 (OpenJDK 64 ビットサーバー VM、Java 1.8.0_282)
Spark バージョン 3.1.2-amzn-0
spark-rapids 0.4.1
Sqoop バージョン 1.4.7
TensorFlow バージョン 2.4.1
tez バージョン 0.9.2
Zeppelin バージョン 0.9.0
Zookeeper バージョン 3.5.7
コネクタおよびドライバー: DynamoDB Connector 4.16.0

新機能

[マネージドスケーリング] Spark シャッフルデータマネージドスケーリング最適化 - Amazon EMR バージョン 5.34.0 以降、および EMR バージョン 6.4.0 以降では、マネージドスケーリングは Spark シャッフルデータ (Spark が特定の操作を実行するためにパーティション間で再分配するデータ) 対応になりました。シャッフル操作の詳細については、「Amazon EMR 管理ガイド」および「Spark のプログラミングガイド」の「Amazon EMR での EMR マネージドスケーリングの使用」を参照してください。
Apache Ranger 対応の Amazon EMR クラスターでは、Apache Spark SQL を使用して、INSERT INTO、INSERT OVERWRITE、および ALTER TABLE で Apache Hive メタストアテーブルでデータの挿入または更新を実行できます。Spark SQL で ALTER TABLE を使用する場合、パーティションの場所はテーブルの場所の子ディレクトリである必要があります。Amazon EMR は現在、パーティションの場所がテーブルの場所と異なるパーティションへのデータの挿入をサポートしていません。
PrestoSQL は Trino に名称変更されています。
Hive: LIMIT 句を使用した簡単な SELECT クエリの実行は、LIMIT 句に記述されているレコード数がフェッチされたらすぐにクエリの実行を停止すると、高速化されます。簡単な SELECT クエリは、GROUP BY/ORDER BY 句のないクエリ、またはリデューサーステージのないクエリです。例えば、SELECT * from <TABLE> WHERE <Condition> LIMIT <Number> です。

Hudi の同時実行制御

Hudi はオプティミスティック同時実行制御 (OCC) をサポートするようになりました。この OCC を UPSERT や INSERT などの書き込みオペレーションで利用して、複数のライターから同じ Hudi テーブルへの変更を許可できます。これはファイルレベルの OCC であるため、2 つのコミット (またはライター) は、その変更が競合しなければ、同じテーブルに書き込むことができます。詳細については、「Hudi Concurrency Control」を参照してください。

Amazon EMR クラスターには Zookeeper がインストールされており、OCC のロックプロバイダーとして利用できます。この機能を使いやすくするために、Amazon EMR クラスターには次のプロパティが事前設定されています。


hoodie.write.lock.provider=org.apache.hudi.client.transaction.lock.ZookeeperBasedLockProvider
hoodie.write.lock.zookeeper.url=<EMR Zookeeper URL>
hoodie.write.lock.zookeeper.port=<EMR Zookeeper Port>
hoodie.write.lock.zookeeper.base_path=/hudi

OCC を有効にするには、Hudi ジョブオプションを使用して、または Amazon EMR 設定 API を使用してクラスターレベルで、次のプロパティを設定する必要があります。


hoodie.write.concurrency.mode=optimistic_concurrency_control
hoodie.cleaner.policy.failed.writes=LAZY (Performs cleaning of failed writes lazily instead of inline with every write)
hoodie.write.lock.zookeeper.lock_key=<Key to uniquely identify the Hudi table> (Table Name is a good option)

Hudi モニタリング: Hudi メトリクスをレポートするための Amazon CloudWatch の統合

Amazon EMR は、Amazon CloudWatch への Hudi メトリクスの公開をサポートしています。これを有効にするには、次の必要な設定を行います。
```
hoodie.metrics.on=true
hoodie.metrics.reporter.type=CLOUDWATCH
```

変更できるオプションの Hudi 設定を以下に示します。

設定	説明	値
hoodie.metrics.cloudwatch.report.period.seconds	Amazon CloudWatch にメトリクスをレポートする頻度 (秒単位)	デフォルト値は 60 秒で、Amazon CloudWatch が提供するデフォルトの 1 分の解像度では問題ありません
hoodie.metrics.cloudwatch.metric.prefix	各メトリクス名に追加するプレフィックス	デフォルト値は空です (プレフィックスなし)
hoodie.metrics.cloudwatch.namespace	メトリクスが公開される Amazon CloudWatch 名前空間	デフォルト値は Hudi です
hoodie.metrics.cloudwatch.maxDatumsPerRequest	Amazon CloudWatch への 1 つのリクエストに含めるデータムの最大数	デフォルト値は 20 で、Amazon CloudWatch のデフォルトと同じです

Amazon EMR Hudi の設定のサポートと改善

EMR 設定 API と再設定機能を利用して、クラスターレベルで Hudi 設定を構成できるようになりました。Spark、Hive などの他のアプリケーションに似た /etc/hudi/conf/hudi-defaults.conf を使用して、新しいファイルベースの設定のサポートが導入されました。EMR では、ユーザーエクスペリエンスを向上させるためにデフォルト設定はほとんどありません。

— hoodie.datasource.hive_sync.jdbcurl はクラスター Hive サーバ URL に設定されるため、指定する必要がなくなりました。これは、Spark クラスターモードでジョブを実行する場合に特に便利です。この場合、以前は Amazon EMR マスター IP を指定する必要がありました。

— HBase 固有の設定。Hbase のインデックスを Hudi で使用する場合に役立ちます。

— 同時実行制御で説明されているように、Zookeeper はプロバイダー固有の設定をロックします。これにより、オプティミスティック同時実行制御 (OCC) の使用が容易になります。
渡す必要がある設定の数を減らし、可能な場合は自動的に推測するために、追加の変更が導入されました。

— partitionBy キーワードは、パーティション列を指定するために使用できます。

— Hive Sync を有効にすると、HIVE_TABLE_OPT_KEY, HIVE_PARTITION_FIELDS_OPT_KEY, HIVE_PARTITION_EXTRACTOR_CLASS_OPT_KEY を渡すのは必須ではなくなります。これらの値は、Hudi テーブル名とパーティションフィールドから推測できます。

— KEYGENERATOR_CLASS_OPT_KEY を渡すのは必須ではなく、より単純な SimpleKeyGenerator および ComplexKeyGenerator のケースから推測できます。

Hudi Caveats

Hudi では、読み取り時マージ (MoR) テーブルおよびブートストラップテーブルの Hive でのベクトル化された実行をサポートしていません。例えば、hive.vectorized.execution.enabled が true に設定されている場合、Hudi リアルタイムテーブルで count(*) は失敗します。回避策として、hive.vectorized.execution.enabled を false に設定して、ベクトル化された読み取りを無効にすることができます。
マルチライターサポートは、Hudi ブートストラップ機能とは互換性がありません。
Flink Streamer と Flink SQL は、このリリースでは実験的な機能です。これらの機能は、実稼働環境での使用はお勧めしません。

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

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

以前は、マルチマスタークラスターでリソースマネージャーを手動で再起動すると、Zookeeper などの Amazon EMR のクラスター上のデーモンが、Zookeeper znode ファイル内の以前に廃止された、または失われたすべてのノードを再ロードしていました。これにより、特定の状況でデフォルトの制限を超えることがありました。Amazon EMR では、1 時間以上経過した、廃止された、または失われたノードレコードが Zookeeper ファイルから削除されるようになり、内部制限も引き上げられました。
Amazon EMR のクラスター上のデーモンが YARN ノード状態や HDFS ノード状態の収集などのヘルスチェックアクティビティを実行しているときに、大規模で使用率の高いクラスターのスケーリングリクエストが失敗する問題を修正しました。これは、クラスター上のデーモンがノードのヘルスステータスデータを内部の Amazon EMR コンポーネントに伝達できなかったために発生していました。
EMR のクラスター上のデーモンが改善され、IP アドレスが再利用されるときにノードの状態を正しく追跡できるようになり、スケーリング操作中の信頼性が向上しました。
SPARK-29683。Spark が使用可能なすべてのノードが拒否リストに登録されていると想定していたため、クラスターのスケールダウン中にジョブエラーが発生する問題を修正しました。
YARN-9011。クラスターがスケールアップまたはスケールダウンを試みたときに YARN 廃止の競合状態が原因でジョブ障害が発生する問題を修正しました。
Amazon EMR のクラスター上のデーモンと YARN/HDFS の間でノードの状態が常に一致するようにすることで、クラスターのスケーリング中のステップまたはジョブの障害に関する問題を修正しました。
Kerberos 認証で有効になっている Amazon EMR クラスターで、スケールダウンやステップ送信などのクラスター操作が失敗する問題を修正しました。これは、Amazon EMR のクラスター上のデーモンが、プライマリノードで実行されている HDFS/YARN と安全に通信するために必要な Kerberos チケットを更新しなかったためです。
Apache YARN タイムラインサーバーのバージョン 1 および 1.5 のパフォーマンスの問題を修正するためのクラスターの設定

Apache YARN タイムラインサーバーのバージョン 1 および 1.5 では、特に Amazon EMR のデフォルト設定である yarn.resourcemanager.system-metrics-publisher.enabled=true を使用する場合に、非常にアクティブで大規模な EMR クラスターでパフォーマンスの問題が発生する可能性があります。オープンソースの YARN タイムラインサーバー v2 では、YARN タイムラインサーバーのスケーラビリティに関連するパフォーマンスの問題が解決されています。

この問題の他の回避策には、次のものがあります。
- yarn-site.xml で yarn.resourcemanager.system-metrics-publisher.enabled=false を設定します。
- クラスターの作成時にこの問題の修正を有効にします (以下を参照)。
次の Amazon EMR リリースには、この YARN タイムラインサーバーのパフォーマンス問題の修正が含まれています。

EMR 5.30.2、5.31.1、5.32.1、5.33.1、5.34.x、6.0.1、6.1.1、6.2.1、6.3.1、6.4.x

上記に示されている Amazon EMR リリースで修正を有効にするには、aws emr create-cluster コマンドのパラメータ --configurations file://./configurations.json で渡される設定の JSON ファイルで、以下のプロパティを true に設定します。または、再構成コンソール UI を使用して修正を有効にします。

configurations.json ファイルの内容の例
```
[
{
"Classification": "yarn-site",
"Properties": {
"yarn.resourcemanager.system-metrics-publisher.timeline-server-v1.enable-batch": "true",
"yarn.resourcemanager.system-metrics-publisher.enabled": "true"
},
"Configurations": []
}
]
```
WebHDFS と HttpFS サーバーはデフォルトで無効になっています。Hadoop 設定 dfs.webhdfs.enabled を使用して WebHDF を再度有効にすることができます。HttpFS サーバーを起動するには、sudo systemctl start hadoop-httpfs を使用します。
Amazon Linux リポジトリでは、現在、HTTPS がデフォルトで有効になります。Amazon S3 VPCE ポリシーを使用して特定のバケットへのアクセスを制限する場合は、新しい Amazon Linux バケット ARN arn:aws:s3:::amazonlinux-2-repos-$region/* をポリシーに追加する ($region を、エンドポイントがあるリージョンに置き換える) 必要があります。詳細については、AWS フォーラムの次のトピックを参照してください。Announcement: Amazon Linux 2 now supports the ability to use HTTPS while connecting to package repositories
Hive: 最後のジョブに HDFS でスクラッチディレクトリを使用できるようにすると、書き込みクエリのパフォーマンスが向上します。最後のジョブの一時データは Amazon S3 ではなく HDFS に書き込まれ、データは Amazon S3 デバイス間ではなく HDFS から最後のテーブルの場所 (Amazon S3) に移動されるため、パフォーマンスが向上します。
Hive: Glue メタストアパーティションプルーニングにより、クエリのコンパイル時間が最大 2.5 倍に改善されています。
デフォルトでは、組み込みの UDF が Hive から Hive メタストアサーバーに渡されると、Glue は限定された式演算子しかサポートしていないため、組み込みの UDF のサブセットのみが Glue メタストアに渡されます。hive.glue.partition.pruning.client=true を設定した場合、パーティションのプルーニングはすべてクライアント側で行われます。hive.glue.partition.pruning.server=true を設定した場合、パーティションのプルーニングはすべてサーバー側で行われます。

既知の問題

Apache Hadoop HttpFS サーバーはデフォルトで無効になるため、Hue クエリは Amazon EMR 6.4.0 では機能しません。Amazon EMR 6.4.0 で Hue を使用するには、sudo systemctl start hadoop-httpfs を使用して Amazon EMR プライマリノードで HttpFS サーバーを手動で起動するか、または Amazon EMR のステップを使用します。
Livy ユーザー偽装で使用される Amazon EMR Notebooks 機能は、HttpFS がデフォルトで無効になっているため機能しません。この場合、EMR notebooks は Livy 偽装が有効になっているクラスターに接続できません。回避策は、sudo systemctl start hadoop-httpfs を使用して EMR notebooks をクラスターに接続する前に、HttpFS サーバーを起動することです。
Amazon EMR バージョン 6.4.0 では、Phoenix は Phoenix コネクタコンポーネントをサポートしていません。
Apache Oozie で Spark アクションを使用するには、以下の設定を Oozie workflow.xml ファイルに追加する必要があります。そうしないと、Hadoop や EMRFS などのいくつかの重要なライブラリが、Oozie が起動する Spark エグゼキューターのクラスパスから失われてしまいます。
```
<spark-opts>--conf spark.yarn.populateHadoopClasspath=true</spark-opts>
```
Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。

リリース 5.32.0

次のリリースノートには、Amazon EMR リリース 5.32.0 に関する情報が含まれています。5.31.0 からの変更が含まれています。

初回リリース日: 2021 年 1 月 8 日

アップグレード

Amazon Glue コネクタをバージョン 1.14.0 にアップグレードしました
Amazon SageMaker Spark SDK をバージョン 1.4.1 にアップグレードしました
AWS SDK for Java をバージョン 1.11.890 にアップグレードしました
EMR DynamoDB Connector バージョン 4.16.0 にアップグレードしました
EMRFS をバージョン 2.45.0 にアップグレードしました
EMR Log Analytics Metrics をバージョン 1.18.0 にアップグレードしました
EMR MetricsAndEventsApiGateway Client をバージョン 1.5.0 にアップグレードしました
EMR Record Server をバージョン 1.8.0 にアップグレードしました
EMR S3 Dist CP をバージョン 2.17.0 にアップグレードしました
EMR Secret Agent をバージョン 1.7.0 にアップグレードしました
Flink をバージョン 1.11.2 にアップグレードしました
Hadoop をバージョン 2.10.1-amzn-0 にアップグレードしました
Hive をバージョン 2.3.7-amzn-3 にアップグレードしました
Hue をバージョン 4.8.0 にアップグレードしました
MXNet をバージョン 1.7.0 にアップグレードしました
OpenCV をバージョン 4.4.0 にアップグレードしました
Presto をバージョン 0.240.1-amzn-0 にアップグレードしました
Spark をバージョン 2.4.7-amzn-0 にアップグレードしました
TensorFlow をバージョン 2.3.1 にアップグレードしました

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

これは、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 のクラスター上のデーモンが、プライマリノードで実行されている HDFS/YARN と安全に通信するために必要な Kerberos チケットを更新しなかったためです。
Amazon EMR の新しいリリースでは、Amazon EMR の古い AL2 で「最大オープンファイル」の上限が低い問題が修正されています。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 EMR リリースについて」を参照してください。

新機能

Amazon EMR 5.32.0 および 6.5.0 以降、Apache Spark の動的エグゼキューターサイズ設定はデフォルトで有効になっています。この機能をオンまたはオフにするには、spark.yarn.heterogeneousExecutors.enabled 設定パラメータを使用できます。
インスタンスメタデータサービス (IMDS) V2 サポートステータス: Amazon EMR 5.23.1、5.27.1、および 5.32 以降のコンポーネントは、すべての IMDS 呼び出しに IMDSv2 を使用します。アプリケーションコードでの IMDS 呼び出しでは、IMDSv1 と IMDSv2 の両方を使用するか、または、セキュリティを強化するために IMDSv2 のみを使用するように IMDS を設定できます。その他の 5.x EMR リリースでは、IMDSv1 を無効にすると、クラスターの起動が失敗します。
Amazon EMR 5.32.0 以降では、Apache Ranger とネイティブに統合されるクラスターを起動できます。Apache Ranger は、Hadoop プラットフォーム全体で包括的なデータセキュリティを有効化、監視、管理するためのオープンソースフレームワークです。詳細については、「Apache Ranger」を参照してください。ネイティブ統合により、独自の Apache Ranger を導入して、Amazon EMR できめ細かなデータアクセス制御を実施できます。「Amazon EMR 管理ガイド」の「Amazon EMR と Apache Ranger を統合する」を参照してください。
Amazon EMR リリース 5.32.0 は Amazon EMR on EKS をサポートしています。EMR on EKS の開始方法の詳細については、「Amazon EMR on EKS とは」を参照してください。
Amazon EMR リリース 5.32.0 は Amazon EMR Studio (プレビュー) をサポートしています。EMR Studio の開始方法の詳細については、「Amazon EMR Studio (Preview)」を参照してください。
スコープ管理ポリシー: AWS のベストプラクティスに合わせて、Amazon EMR では、非推奨となるポリシーの置き換えとして v2 EMR スコープのデフォルト管理ポリシーが導入されています。「Amazon EMR 管理ポリシー」を参照してください。

既知の問題

Amazon EMR 6.3.0 および 6.2.0 のプライベートサブネットクラスターで、Ganglia ウェブ UI にアクセスできません。「アクセス拒否 (403)」というエラーが表示されます。Spark、Hue、JupyterHub、Zeppelin、Livy、Tez などの他のウェブ UI は正常に動作します。パブリックサブネットクラスターでの Ganglia ウェブ UI アクセスも正常に動作します。この問題を解決するには、sudo systemctl restart httpd を使用してプライマリノードで httpd サービスを再起動します。この問題は、Amazon EMR 6.4.0 で修正されています。
古い 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 は、古いバージョンの Amazon Linux 2 (AL2) に基づいており、デフォルトの AMI を使用して Amazon EMR クラスターを作成する場合に「最大オープンファイル」の ulimit 設定が低くなります。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 のデフォルト AMI の「最大オープンファイル」はデフォルトの ulimit 設定 4096 になっており、最新の Amazon Linux 2 AMI の上限 65536 ファイルよりも低くなっています。「最大オープンファイル」の ulimit 設定が低い場合、Spark ドライバーとエグゼキュータが 4096 を超えるファイルを開こうとすると、Spark ジョブが失敗します。この問題を解決するために、Amazon EMR には、クラスターの作成時に ulimit 設定を調整するブートストラップアクション (BA) スクリプトが用意されています。

この問題の永続的な修正がない古い Amazon EMR バージョンを使用している場合は、以下の回避策を使用すると、instance-controller 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
```
重要
Amazon Linux AMI または Amazon Linux 2 AMI (Amazon Linux マシンイメージ) を実行している Amazon EMR クラスターは、デフォルトの Amazon Linux 動作を使用します。再起動が必要な重要なカーネル更新が自動的にダウンロードされてインストールされることはありません。これは、デフォルトの Amazon Linux AMI を実行している他の Amazon EC2 インスタンスと同じ動作です。Amazon EMR バージョンのリリース後に、再起動が必要な新しい Amazon Linux ソフトウェア更新 (カーネル、NVIDIA、CUDA の更新など) が使用可能になった場合、デフォルトの AMI を実行する Amazon EMR クラスターインスタンスで、それらの更新が自動的にダウンロードされてインストールされることはありません。カーネルの更新を取得するために、Amazon EMR AMI をカスタマイズして、最新の Amazon Linux AMI を使用できます。
AWS Ranger 統合オプションを指定するセキュリティ設定を作成するためのコンソールサポートは、現在 GovCloud リージョンではサポートされていません。セキュリティ設定は CLI を使用して実行できます。「Amazon EMR 管理ガイド」の「EMR セキュリティ設定を作成する」を参照してください。

Amazon EMR 5.31.0 または 5.32.0 を使用するクラスターで AtRestEncryption または HDFS 暗号化が有効になっている場合、Hive クエリで次のランタイム例外が発生します。


TaskAttempt 3 failed, info=[Error: Error while running task ( failure ) : attempt_1604112648850_0001_1_01_000000_3:java.lang.RuntimeException: java.lang.RuntimeException: Hive Runtime Error while closing operators: java.io.IOException: java.util.ServiceConfigurationError: org.apache.hadoop.security.token.TokenIdentifier: Provider org.apache.hadoop.hbase.security.token.AuthenticationTokenIdentifier not found

Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。

リリース 6.2.0

次のリリースノートには、Amazon EMR リリース 6.2.0 に関する情報が含まれています。6.1.0 からの変更が含まれています。

初回リリース日: 2020 年 12 月 9 日

最終更新日: 2021 年 10 月 4 日

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

AWS SDK for Java バージョン 1.11.828
emr-record-server バージョン 1.7.0
Flink バージョン 1.11.2
Ganglia バージョン 3.7.2
Hadoop バージョン 3.2.1-amzn-1
HBase バージョン 2.2.6-amzn-0
HBase-operator-tools 1.0.0
HCatalog バージョン 3.1.2-amzn-0
Hive バージョン 3.1.2-amzn-3
Hudi バージョン 0.6.0-amzn-1
Hue バージョン 4.8.0
JupyterHub バージョン 1.1.0
Livy バージョン 0.7.0
MXNet バージョン 1.7.0
Oozie バージョン 5.2.0
Phoenix バージョン 5.0.0
Pig バージョン 0.17.0
Presto バージョン 0.238.3-amzn-1
PrestoSQL バージョン 343
Spark バージョン 3.0.1-amzn-0
spark-rapids 0.2.0
TensorFlow バージョン 2.3.1
Zeppelin バージョン 0.9.0-preview1
Zookeeper バージョン 3.4.14
コネクタおよびドライバー: DynamoDB Connector 4.16.0

新機能

HBase: コミットフェーズでの名前変更を削除し、永続的 HFile トラッキングを追加しました。「Amazon EMR リリースガイド」の「永続的 HFile トラッキング」を参照してください。
HBase:「Create a config that forces to cache blocks on compaction」をバックポートしました。
PrestoDB: ダイナミックパーティションプルーニングの改善。ルールベースの結合順序は、パーティション分割されていないデータに対して機能します。
スコープ管理ポリシー: AWS のベストプラクティスに合わせて、Amazon EMR では、非推奨となるポリシーの置き換えとして v2 EMR スコープのデフォルト管理ポリシーが導入されています。「Amazon EMR 管理ポリシー」を参照してください。
インスタンスメタデータサービス (IMDS) V2 サポートステータス: Amazon EMR 6.2 以降では、Amazon EMR コンポーネントはすべての IMDS 呼び出しに IMDSv2 を使用します。アプリケーションコードでの IMDS 呼び出しでは、IMDSv1 と IMDSv2 の両方を使用するか、または、セキュリティを強化するために IMDSv2 のみを使用するように IMDS を設定できます。以前の Amazon EMR 6.x リリースで IMDSv1 を無効にすると、クラスターの起動が失敗します。

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

これは、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 のクラスター上のデーモンが、プライマリノードで実行されている HDFS/YARN と安全に通信するために必要な Kerberos チケットを更新しなかったためです。
Amazon EMR の新しいリリースでは、Amazon EMR の古い AL2 で「最大オープンファイル」の上限が低い問題が修正されています。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: Spark ランタイムのパフォーマンスが向上しました。

既知の問題

Amazon EMR 6.2 で、EMR 6.2.0 の /etc/cron.d/libinstance-controller-java ファイルに対して正しくないアクセス許可が設定されています。ファイルに対するアクセス許可は、644 (-rw-r—r—) であるべきときに 645 (-rw-r--r-x) になります。その結果、Amazon EMR バージョン 6.2 ではインスタンス状態ログが記録されず、/emr/instance-logs ディレクトリは空になります。この問題は、Amazon EMR 6.3.0 以降で修正されています。

この問題を回避するには、クラスター起動時に以下のスクリプトをブートストラップアクションとして実行します。
```
#!/bin/bash
sudo chmod 644 /etc/cron.d/libinstance-controller-java
            
```
Amazon EMR 6.2.0 および 6.3.0 のプライベートサブネットクラスターで、Ganglia ウェブ UI にアクセスできません。「アクセス拒否 (403)」というエラーが表示されます。Spark、Hue、JupyterHub、Zeppelin、Livy、Tez などの他のウェブ UI は正常に動作します。パブリックサブネットクラスターでの Ganglia ウェブ UI アクセスも正常に動作します。この問題を解決するには、sudo systemctl restart httpd を使用してプライマリノードで httpd サービスを再起動します。この問題は、Amazon EMR 6.4.0 で修正されています。
Amazon EMR 6.2.0 で、httpd が連続して失敗し、Ganglia が利用できないという問題があります。「サーバーに接続できません」というエラーが表示されます。この問題が発生している、既に実行されているクラスターを修正するには、クラスターのプライマリノードに SSH 接続して、/etc/httpd/conf/httpd.conf にあるファイル httpd.conf に行 Listen 80 を追加します。この問題は、Amazon EMR 6.3.0 で修正されています。
セキュリティ設定を使用している場合、EMR 6.2.0 クラスターで HTTPD が失敗します。これにより、Ganglia ウェブアプリケーションのユーザーインターフェイスが使用できなくなります。Ganglia ウェブアプリケーションのユーザーインターフェイスにアクセスするには、クラスターのプライマリノード上の /etc/httpd/conf/httpd.conf ファイルに Listen 80 を追加します。クラスターへの接続の詳細については、「SSH を使用してプライマリノードに接続する」を参照してください。

EMR Notebooks では、セキュリティ構成を使用する場合、EMR 6.2.0 クラスターとの接続の確立にも失敗します。ノートブックは、カーネルのリストと Spark ジョブの送信に失敗します。代わりに、別のバージョンの Amazon EMR で EMR Notebooks を使用することをお勧めします。
古い 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 は、古いバージョンの Amazon Linux 2 (AL2) に基づいており、デフォルトの AMI を使用して Amazon EMR クラスターを作成する場合に「最大オープンファイル」の ulimit 設定が低くなります。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 のデフォルト AMI の「最大オープンファイル」はデフォルトの ulimit 設定 4096 になっており、最新の Amazon Linux 2 AMI の上限 65536 ファイルよりも低くなっています。「最大オープンファイル」の ulimit 設定が低い場合、Spark ドライバーとエグゼキュータが 4096 を超えるファイルを開こうとすると、Spark ジョブが失敗します。この問題を解決するために、Amazon EMR には、クラスターの作成時に ulimit 設定を調整するブートストラップアクション (BA) スクリプトが用意されています。

この問題の永続的な修正がない古い Amazon EMR バージョンを使用している場合は、以下の回避策を使用すると、instance-controller 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
```
重要
Amazon EMR 6.1.0 および 6.2.0 には、Hudi の挿入、アップサート、および削除操作すべてに大きな影響を及ぼす可能性があるパフォーマンスの問題が含まれています。Amazon EMR 6.1.0 または 6.2.0 で Hudi を使用する予定の場合は、AWS サポートに連絡して、パッチが適用された Hudi RPM を入手してください。
重要
Amazon Linux AMI または Amazon Linux 2 AMI (Amazon Linux マシンイメージ) を実行している Amazon EMR クラスターは、デフォルトの Amazon Linux 動作を使用します。再起動が必要な重要なカーネル更新が自動的にダウンロードされてインストールされることはありません。これは、デフォルトの Amazon Linux AMI を実行している他の Amazon EC2 インスタンスと同じ動作です。Amazon EMR バージョンのリリース後に、再起動が必要な新しい Amazon Linux ソフトウェア更新 (カーネル、NVIDIA、CUDA の更新など) が使用可能になった場合、デフォルトの AMI を実行する Amazon EMR クラスターインスタンスで、それらの更新が自動的にダウンロードされてインストールされることはありません。カーネルの更新を取得するために、Amazon EMR AMI をカスタマイズして、最新の Amazon Linux AMI を使用できます。
Amazon EMR 6.2.0 の Maven アーティファクトは公開されません。これらは Amazon EMR の将来のリリースで公開される予定です。
HBase ストアファイルシステムテーブルを使用した永続的な HFile トラッキングは、HBase リージョンのレプリケーション機能をサポートしていません。HBase リージョンレプリケーションの詳細については、「Timeline-consistent High Available Reads」を参照してください。
Amazon EMR 6.x と EMR 5.x の Hive バケット化バージョンの違い

EMR 5.x では OOS Apache Hive 2 を使用していますが、EMR 6.x では OOS Apache Hive 3を使用しています。オープンソースの Hive2 ではバケット化バージョン 1 を使用していますが、オープンソースの Hive3 ではバケット化バージョン 2 を使用しています。Hive 2 (EMR 5.x) と Hive 3 (EMR 6.x) のこのバケット化バージョンの違いは、Hive のバケット化ハッシュ関数が異なることを意味します。以下の例を参照してください。

次の表は、それぞれ EMR 6.x および EMR 5.x で作成した例です。
```
-- Using following LOCATION in EMR 6.x
CREATE TABLE test_bucketing (id INT, desc STRING)
PARTITIONED BY (day STRING)
CLUSTERED BY(id) INTO 128 BUCKETS
LOCATION 's3://your-own-s3-bucket/emr-6-bucketing/';

-- Using following LOCATION in EMR 5.x 
LOCATION 's3://your-own-s3-bucket/emr-5-bucketing/';
```
EMR 6.x と EMR 5.x の両方に同じデータを挿入しています。
```
INSERT INTO test_bucketing PARTITION (day='01') VALUES(66, 'some_data');
INSERT INTO test_bucketing PARTITION (day='01') VALUES(200, 'some_data');
```
S3 の場所を確認すると、バケット化ファイル名が異なることが示されています。これは、ハッシュ関数が EMR 6.x (Hive 3) と EMR 5.x (Hive 2) で異なるためです。
```
[hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-6-bucketing/day=01/
2020-10-21 20:35:16         13 000025_0
2020-10-21 20:35:22         14 000121_0
[hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-5-bucketing/day=01/
2020-10-21 20:32:07         13 000066_0
2020-10-21 20:32:51         14 000072_0
```
EMR 6.x で、Hive CLI で次のコマンドを実行し、バージョンの違いを確認することもできます。バケット化バージョン 2 が返されることに注意してください。
```
hive> DESCRIBE FORMATTED test_bucketing;
...
Table Parameters:
    bucketing_version       2
...
```
複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。
Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。

リリース 5.31.0

次のリリースノートには、Amazon EMR リリース 5.31.0 に関する情報が含まれています。5.30.1 からの変更が含まれています。

初回リリース日: 2020 年 10 月 9 日

最終更新日: 2020 年 10 月 15 日

アップグレード

Amazon Glue コネクタをバージョン 1.13.0 にアップグレードしました
Amazon SageMaker Spark SDK をバージョン 1.4.0 にアップグレードしました
Amazon Kinesis コネクタをバージョン 3.5.9 にアップグレードしました
AWS SDK for Java をバージョン 1.11.852 にアップグレードしました
Bigtop-tomcat をバージョン 8.5.56 にアップグレードしました
EMRFS をバージョン 2.43.0 にアップグレードしました
EMR MetricsAndEventsApiGateway Client をバージョン 1.4.0 にアップグレードしました
EMR S3 Dist CP をバージョン 2.15.0 にアップグレードしました
EMR S3 Select をバージョン 1.6.0 にアップグレードしました
Flink をバージョン 1.11.0 にアップグレードしました
Hadoop をバージョン 2.10.0 にアップグレードしました
Hive をバージョン 2.3.7 にアップグレードしました
Hudi をバージョン 0.6.0 にアップグレードしました
Hue をバージョン 4.7.1 にアップグレードしました
JupyterHub をバージョン 1.1.0 にアップグレードしました
MXNet をバージョン 1.6.0 にアップグレードしました
OpenCV をバージョン 4.3.0 にアップグレードしました
Presto をバージョン 0.238.3 にアップグレードしました
TensorFlow をバージョン 2.1.0 にアップグレードしました

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

これは、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 のクラスター上のデーモンが、プライマリノードで実行されている HDFS/YARN と安全に通信するために必要な Kerberos チケットを更新しなかったためです。
Amazon EMR の新しいリリースでは、Amazon EMR の古い AL2 で「最大オープンファイル」の上限が低い問題が修正されています。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 以降には、「最大オープンファイル」設定が高くなった永続的な修正が含まれるようになりました。
Hive の列統計は、Amazon EMR バージョン 5.31.0 以降でサポートされています。
コンポーネントのバージョンをアップグレードしました。
Amazon EMR 5.31.0 での EMRFS S3EC V2 のサポート。S3 Java SDK リリース 1.11.837 以降では、暗号化クライアントバージョン 2 (S3EC V2) がさまざまなセキュリティ機能強化とともに導入されました。詳細については、次を参照してください。
- S3 ブログ投稿: Updates to the Amazon S3 encryption client。
- AWS SDK for Java デベロッパーガイド: 暗号化および復号化クライアントを V2 に移行する。
- EMR 管理ガイド: Amazon S3 クライアント側暗号化。
下位互換性を保つため、暗号化クライアント V1 は SDK で引き続き使用できます。

新機能

古い 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 は、古いバージョンの Amazon Linux 2 (AL2) に基づいており、デフォルトの AMI を使用して Amazon EMR クラスターを作成する場合に「最大オープンファイル」の ulimit 設定が低くなります。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 のデフォルト AMI の「最大オープンファイル」はデフォルトの ulimit 設定 4096 になっており、最新の Amazon Linux 2 AMI の上限 65536 ファイルよりも低くなっています。「最大オープンファイル」の ulimit 設定が低い場合、Spark ドライバーとエグゼキュータが 4096 を超えるファイルを開こうとすると、Spark ジョブが失敗します。この問題を解決するために、Amazon EMR には、クラスターの作成時に ulimit 設定を調整するブートストラップアクション (BA) スクリプトが用意されています。

この問題の永続的な修正がない古い Amazon EMR バージョンを使用している場合は、以下の回避策を使用すると、instance-controller 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
```
Amazon EMR 5.31.0 を使用すると、Lake Formation と統合されるクラスターを起動できます。この統合により、AWS Glue Data Catalog 内のデータベースとテーブルに対して、きめ細かな列レベルのデータフィルタリングが提供されます。また、これにより、企業の ID システムから EMR Notebooks または Apache Zeppelin へのフェデレーションシングルサインオンが可能になります。詳細については、「Amazon EMR 管理ガイド」の「Amazon EMR と AWS Lake Formation の統合」を参照してください。

Amazon EMR と Lake Formation は現在、米国東部 (オハイオとバージニア北部)、米国西部 (北カリフォルニアとオレゴン)、アジアパシフィック (ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、パリ、ストックホルム)、南米 (サンパウロ) の 16 の AWS リージョンで利用可能です。

既知の問題

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

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。


TaskAttempt 3 failed, info=[Error: Error while running task ( failure ) : attempt_1604112648850_0001_1_01_000000_3:java.lang.RuntimeException: java.lang.RuntimeException: Hive Runtime Error while closing operators: java.io.IOException: java.util.ServiceConfigurationError: org.apache.hadoop.security.token.TokenIdentifier: Provider org.apache.hadoop.hbase.security.token.AuthenticationTokenIdentifier not found

Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。

リリース 6.1.0

次のリリースノートには、Amazon EMR リリース 6.1.0 に関する情報が含まれています。6.0.0 からの変更が含まれています。

初回リリース日: 2020 年 9 月 4 日

最終更新日: 2020 年 10 月 15 日

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

AWS SDK for Java バージョン 1.11.828
Flink バージョン 1.11.0
Ganglia バージョン 3.7.2
Hadoop バージョン 3.2.1-amzn-1
HBase バージョン 2.2.5
HBase-operator-tools 1.0.0
HCatalog バージョン 3.1.2-amzn-0
Hive バージョン 3.1.2-amzn-1
Hudi バージョン 0.5.2-incubating
Hue バージョン 4.7.1
JupyterHub バージョン 1.1.0
Livy バージョン 0.7.0
MXNet バージョン 1.6.0
Oozie バージョン 5.2.0
Phoenix バージョン 5.0.0
Presto バージョン 0.232
PrestoSQL バージョン 338
Spark バージョン 3.0.0-amzn-0
TensorFlow バージョン 2.1.0
Zeppelin バージョン 0.9.0-preview1
Zookeeper バージョン 3.4.14
コネクタおよびドライバー: DynamoDB Connector 4.14.0

新機能

ARM インスタンスタイプは、Amazon EMR バージョン 5.30.0 以降および Amazon EMR バージョン 6.1.0 以降でサポートされています。
M6g 汎用インスタンスタイプは、Amazon EMR バージョン 6.1.0 以降および Amazon EMR バージョン 5.30.0 以降でサポートされています。詳細については、「Amazon EMR 管理ガイド」の「サポートされるインスタンスタイプ」を参照してください。
EC2 プレイスメントグループ機能は、複数のプライマリノードクラスターのオプションとして Amazon EMR バージョン 5.23.0 以降でサポートされています。現在、プレイスメントグループ機能ではプライマリノードタイプのみがサポートされており、SPREAD ストラテジーは、これらのプライマリノードに適用されます。SPREAD 戦略では、ハードウェア障害の発生時に複数のプライマリノードが失われるのを防ぐため、少数のインスタンスを別個の基盤となるハードウェア全体に配置します。詳細については、「Amazon EMR 管理ガイド」の「EC2 プレイスメントグループと EMR の統合」を参照してください。
マネージドスケーリング - Amazon EMR バージョン 6.1.0 では、Amazon EMR Managed Scaling を有効にすることで、ワークロードに応じてクラスター内のインスタンスやユニットの数を自動的に増減できます。Amazon EMR は引き続きクラスターのメトリクスを評価し、クラスターのコストと速度を最適化するためのスケーリングを決定します。マネージドスケーリングは、Amazon EMR バージョン 5.30.0 以降 (6.0.0 を除く) でも使用できます。詳細については、「Amazon EMR 管理ガイド」の「クラスターリソースのスケーリング」を参照してください。
PrestoSQL バージョン 338 は EMR 6.1.0 でサポートされています。詳細については、「Presto」を参照してください。
- PrestoSQL は EMR 6.1.0 以降のバージョンでのみサポートされています。EMR 6.0.0 および EMR 5.x ではサポートされていません。
- アプリケーション名 Presto は、クラスターに PrestoDB をインストールするために引き続き使用されます。クラスターに PrestoDB をインストールするには、アプリケーション名 PrestoSQL を使用します。
- PrestoDB または PrestoSQL のいずれかをインストールできますが、両方を 1 つのクラスターにインストールすることはできません。クラスターの作成時に PrestoDB と PrestoSQL の両方を指定すると、検証エラーが発生し、クラスター作成リクエストは失敗します。
- PrestoSQL は、シングルマスタークラスターとマルチマスタークラスターの両方でサポートされています。マルチマスタークラスターでは、PrestoSQL または PrestoDB を実行するには、外部 Hive メタストアが必要です。「複数のプライマリノードを持つ Amazon EMR クラスターでサポートされるアプリケーション」を参照してください。
Docker を使用した Apache Hadoop および Apache Spark での ECR 自動認証サポート: Spark ユーザーは、Docker Hub および Amazon Elastic Container Registry (Amazon ECR) の Docker イメージを使用して、環境とライブラリの依存関係を定義できます。

Docker を設定し、Amazon EMR 6.x を使用して Docker で Spark アプリケーションを実行します。
EMR は Apache Hive ACID トランザクションをサポートしています。Amazon EMR 6.1.0 では、データベースの ACID プロパティに準拠するように Hive ACID トランザクションのサポートが追加されています。この機能を使用すると、Amazon Simple Storage Service (Amazon S3) のデータを使用して Hive マネージドテーブルで INSERT, UPDATE, DELETE, および MERGE の各オペレーションを実行できます。これは、ストリーミングの取り込み、データの再記述、MERGE を使用した一括更新、徐々に変化するディメンションなどのユースケースにとって重要な機能です。設定例とユースケースを含め、詳細については、「Amazon EMR supports Apache Hive ACID transactions」を参照してください。

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

これは、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 のクラスター上のデーモンが、プライマリノードで実行されている HDFS/YARN と安全に通信するために必要な Kerberos チケットを更新しなかったためです。
Amazon EMR の新しいリリースでは、Amazon EMR の古い AL2 で「最大オープンファイル」の上限が低い問題が修正されています。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 以降には、「最大オープンファイル」設定が高くなった永続的な修正が含まれるようになりました。
Apache Flink は EMR 6.0.0 ではサポートされていませんが、Flink 1.11.0 と EMR 6.1.0 ではサポートされています。これは、Hadoop 3 を公式にサポートする Flink の最初のバージョンです。「Apache Flink 1.11.0 Release Announcement」を参照してください。
Ganglia はデフォルトの EMR 6.1.0 パッケージバンドルから削除されました。

既知の問題

古い 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 は、古いバージョンの Amazon Linux 2 (AL2) に基づいており、デフォルトの AMI を使用して Amazon EMR クラスターを作成する場合に「最大オープンファイル」の ulimit 設定が低くなります。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 のデフォルト AMI の「最大オープンファイル」はデフォルトの ulimit 設定 4096 になっており、最新の Amazon Linux 2 AMI の上限 65536 ファイルよりも低くなっています。「最大オープンファイル」の ulimit 設定が低い場合、Spark ドライバーとエグゼキュータが 4096 を超えるファイルを開こうとすると、Spark ジョブが失敗します。この問題を解決するために、Amazon EMR には、クラスターの作成時に ulimit 設定を調整するブートストラップアクション (BA) スクリプトが用意されています。

この問題の永続的な修正がない古い Amazon EMR バージョンを使用している場合は、以下の回避策を使用すると、instance-controller 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
```
重要
Amazon EMR 6.1.0 および 6.2.0 には、Hudi の挿入、アップサート、および削除操作すべてに大きな影響を及ぼす可能性があるパフォーマンスの問題が含まれています。Amazon EMR 6.1.0 または 6.2.0 で Hudi を使用する予定の場合は、AWS サポートに連絡して、パッチが適用された Hudi RPM を入手してください。
spark.driver.extraJavaOptions と spark.executor.extraJavaOptions を使用してカスタムのガベージコレクション設定を指定すると、ガベージコレクション設定の競合のために、EMR 6.1 でドライバー/エグゼキュターの起動に失敗します。EMR リリース 6.1.0 では、代わりにプロパティ spark.driver.defaultJavaOptions と spark.executor.defaultJavaOptions を使用して、ドライバーとエグゼキュターのカスタムの Spark ガベージコレクション設定を指定する必要があります。詳細については、「Apache Spark のランタイム環境」および「Amazon EMR 6.1.0 での Spark ガベージコレクションの設定」を参照してください。
Oozie で Pig を (Hue 内で。Hue では、Oozie アクションを使用して Pig スクリプトを実行するため) 使用すると、native-lzo ライブラリをロードできないというエラーが生成されます。このエラーメッセージは情報であるため、Pig の実行はブロックされません。
Hudi 同時実行のサポート: 現在、Hudi は単一の Hudi テーブルへの同時書き込みをサポートしていません。さらに、Hudi は新しいライターの起動を許可する前に、進行中のライターによって行われた変更をロールバックします。同時書き込みは、このメカニズムを妨げて、競合状態を引き起こし、データの破損につながる可能性があります。データ処理ワークフローの一部として、いつでも 1 つの Hudi テーブルに対して動作する Hudi ライターが 1 つだけであることを確認してください。Hudi は、同じ Hudi テーブルに対して動作する複数の同時リーダーをサポートしています。
複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。
Amazon EMR 6.1.0 には、Presto を実行しているクラスターに影響する問題があります。長時間 (日単位) 後に、クラスターが「su: failed to execute /bin/bash: Resource temporarily unavailable」(su: /bin/bash の実行に失敗しました:リソースを一時的に利用できません) または「shell request failed on channel 0」(チャネル 0 でシェルリクエストが失敗しました) などのエラーをスローする可能性があります。この問題は、多すぎるライトウェイトプロセス (LWP) を生成する内部 Amazon EMR プロセス (InstanceController) が原因で発生し、最終的に Hadoop ユーザーが nproc の制限を超えることになります。これにより、ユーザーは追加のプロセスを開くことができなくなります。この問題の解決策は、EMR 6.2.0 にアップグレードすることです。

リリース 6.0.0

次のリリースノートには、Amazon EMR リリース 6.0.0 に関する情報が含まれています。

初回リリース日: 2020 年 3 月 10 日

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

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

注記

Flink、Sqoop、Pig、および Mahout は、Amazon EMR バージョン 6.0.0 では使用できません。

新機能

YARN Docker ランタイムのサポート - Spark ジョブなどの YARN アプリケーションは、Docker コンテナのコンテキストで実行できるようになりました。これにより、Amazon EMR クラスターにカスタムライブラリをインストールすることなく、Docker イメージの依存関係を簡単に定義できます。詳細については、「Docker 統合の設定」および「Amazon EMR 6.0.0 を使用して Docker で Spark アプリケーションを実行する」を参照してください。
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 のクラスター上のデーモンが、プライマリノードで実行されている HDFS/YARN と安全に通信するために必要な Kerberos チケットを更新しなかったためです。
Amazon EMR の新しいリリースでは、Amazon EMR の古い AL2 で「最大オープンファイル」の上限が低い問題が修正されています。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 は EMR 6.x リリースシリーズのオペレーティングシステムです。
- systemd は、Amazon Linux 1 で使用される upstart ではなく、サービス管理に使用されます。
Java Development Kit (JDK)
- Corretto JDK 8 は、EMR 6.x リリースシリーズのデフォルトの JDK です。
Scala
- Scala 2.12 は、Apache Spark および Apache Livy で使用されます。
Python 3
- Python 3 が EMR の Python のデフォルトバージョンになりました。
YARN ノードラベル
- Amazon EMR 6.x リリースシリーズ以降では、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 は、古いバージョンの Amazon Linux 2 (AL2) に基づいており、デフォルトの AMI を使用して Amazon EMR クラスターを作成する場合に「最大オープンファイル」の ulimit 設定が低くなります。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 のデフォルト AMI の「最大オープンファイル」はデフォルトの ulimit 設定 4096 になっており、最新の Amazon Linux 2 AMI の上限 65536 ファイルよりも低くなっています。「最大オープンファイル」の ulimit 設定が低い場合、Spark ドライバーとエグゼキュータが 4096 を超えるファイルを開こうとすると、Spark ジョブが失敗します。この問題を解決するために、Amazon EMR には、クラスターの作成時に ulimit 設定を調整するブートストラップアクション (BA) スクリプトが用意されています。

この問題の永続的な修正がない古い Amazon EMR バージョンを使用している場合は、以下の回避策を使用すると、instance-controller 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
```
PySpark、SparkR、spark-shell を含む Spark インタラクティブシェルは、追加のライブラリでの Docker の使用をサポートしていません。
Amazon EMR バージョン 6.0.0 で Python 3 を使用するには、PATH を yarn.nodemanager.env-whitelist に追加する必要があります。
Live Long and Process (LLAP) 機能は、AWS Glue Data Catalog を Hive のメタストアとして使用する場合はサポートされません。
Spark と Docker の統合で Amazon EMR 6.0.0 を使用する場合、Docker ランタイムで Spark ジョブを送信する際の失敗を回避するために、同じインスタンスタイプおよび同量の EBS ボリュームでクラスター内のインスタンスを設定する必要があります。
Amazon EMR 6.0.0 では、HBase on Amazon S3 ストレージモードは HBASE-24286 の問題の影響を受けます。既存の S3 データを使用してクラスターを作成する場合、HBase マスターは初期化できません。
複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.30.1

次のリリースノートには、Amazon EMR リリース 5.30.1 に関する情報が含まれています。5.30.0 からの変更が含まれています。

初回リリース日: 2020 年 6 月 30 日

最終更新日: 2020 年 8 月 24 日

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

Amazon EMR の新しいリリースでは、Amazon EMR の古い AL2 で「最大オープンファイル」の上限が低い問題が修正されています。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 以降には、「最大オープンファイル」設定が高くなった永続的な修正が含まれるようになりました。
インスタンスコントローラープロセスが無限数のプロセスをスポーンする問題を修正しました。
Hue が Hive クエリを実行できず、「データベースがロックされています」というメッセージが表示され、クエリの実行が妨げられる問題を修正しました。
EMR クラスターでより多くのタスクを同時に実行できるようにするための Spark の問題を修正しました。
Jupyter サーバーで「too many files open error」(開いているファイルの数が多すぎるエラー) が発生する、Jupyter Notebook の問題を修正しました。
クラスターの開始時間の問題を修正しました。

新機能

Tez UI および YARN タイムラインサーバーの永続アプリケーションインターフェイスは、Amazon EMR バージョン 6.x および EMR バージョン 5.30.1 以降で利用可能です。永続アプリケーション履歴へのワンクリックリンクアクセスにより、SSH 接続でウェブプロキシを設定せずに、ジョブ履歴にすばやくアクセスできます。アクティブなクラスターと終了したクラスターのログは、アプリケーションの終了後 30 日間利用できます。詳細については、「Amazon EMR 管理ガイド」の「永続アプリケーションユーザーインターフェイスの表示」を参照してください。
EMR Notebooks 実行 API を使用して、スクリプトまたはコマンドラインで EMR Notebooks を実行できます。AWS コンソールなしに EMR ノートブックの実行を開始、停止、一覧表示、および記述する機能を使用し、EMR ノートブックをプログラムで制御できます。パラメータ化されたノートブックセルを使用すると、新しいパラメータ値セットごとにノートブックのコピーを作成しなくても、複数の異なるパラメータ値をノートブックに渡すことができます。「EMR API のアクション」を参照してください。サンプルコードについては、「EMR Notebooks をプログラムで実行するサンプルコマンド」を参照してください。

既知の問題

古い 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 は、古いバージョンの Amazon Linux 2 (AL2) に基づいており、デフォルトの AMI を使用して Amazon EMR クラスターを作成する場合に「最大オープンファイル」の ulimit 設定が低くなります。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 のデフォルト AMI の「最大オープンファイル」はデフォルトの ulimit 設定 4096 になっており、最新の Amazon Linux 2 AMI の上限 65536 ファイルよりも低くなっています。「最大オープンファイル」の ulimit 設定が低い場合、Spark ドライバーとエグゼキュータが 4096 を超えるファイルを開こうとすると、Spark ジョブが失敗します。この問題を解決するために、Amazon EMR には、クラスターの作成時に ulimit 設定を調整するブートストラップアクション (BA) スクリプトが用意されています。

この問題の永続的な修正がない古い Amazon EMR バージョンを使用している場合は、以下の回避策を使用すると、instance-controller 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
```
EMR Notebooks

クラスターのプライマリノードにカーネルと追加の Python ライブラリをインストールする機能は、EMR バージョン 5.30.1 ではデフォルトで無効になっています。この機能の詳細については、「クラスターのプライマリノードへのカーネルと Python ライブラリのインストール」を参照してください。

この機能を有効にするには、以下の操作を行います。
1. EMR Notebooks のサービスロールにアタッチされているアクセス許可ポリシーで、次のアクションが許可されていることを確認します。
  
  elasticmapreduce:ListSteps
  
  詳細については、「EMR Notebooks のサービスロール」を参照してください。
2. AWS CLI を使用して、以下の例に示すように、EMR Notebooks をセットアップするクラスターでステップを実行します。us-east-1 を、クラスターが存在するリージョンに置き換えます。詳細については、「AWS CLI を使用したクラスターへのステップの追加」を参照してください。
```
aws emr add-steps  --cluster-id MyClusterID --steps Type=CUSTOM_JAR,Name=EMRNotebooksSetup,ActionOnFailure=CONTINUE,Jar=s3://us-east-1.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://awssupportdatasvcs.com/bootstrap-actions/EMRNotebooksSetup/emr-notebooks-setup.sh"]
                        
```
マネージドスケーリング

Presto がインストールされていない 5.30.0 クラスターおよび 5.30.1 クラスターでマネージドスケーリング操作を実行すると、特にスケールダウン操作の後にすぐ、スケールアップ操作が実行されたときに、アプリケーション障害が発生するか、ユニフォームインスタンスグループまたはインスタンスフリートが ARRESTED 状態のままになる場合があります。

回避策として、ジョブに Presto が必要ない場合でも、Amazon EMR リリース 5.30.0 および 5.30.1 を使用してクラスターを作成するときに、インストールするアプリケーションとして Presto を選択します。
複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。
Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。

リリース 5.30.0

次のリリースノートには、Amazon EMR リリース 5.30.0 に関する情報が含まれています。5.29.0 からの変更が含まれています。

初回リリース日: 2020 年 5 月 13 日

最終更新日: 2020 年 6 月 25 日

アップグレード

AWS SDK for Java をバージョン 1.11.759 にアップグレードしました
Amazon SageMaker Spark SDK をバージョン 1.3.0 にアップグレードしました
EMR Record Server をバージョン 1.6.0 にアップグレードしました
Flink をバージョン 1.10.0 にアップグレードしました
Ganglia をバージョン 3.7.2 にアップグレードしました
HBase をバージョン 1.4.13 にアップグレードしました
Hudi をバージョン 0.5.2 (incubating) にアップグレードしました
Hue をバージョン 4.6.0 にアップグレードしました
JupyterHub をバージョン 1.1.0 にアップグレードしました
Livy をバージョン 0.7.0 (incubating) にアップグレードしました
Oozie をバージョン 5.2.0 にアップグレードしました
Presto をバージョン 0.232 にアップグレードしました
Spark をバージョン 2.4.5 にアップグレードしました
コネクタとドライバーをアップグレードしました: Amazon Glue Connector 1.12.0、Amazon Kinesis Connector 3.5.0、EMR DynamoDB Connector 4.14.0

新機能

EMR Notebooks - 5.30.0 を使用して作成された EMR クラスターで使用する場合、EMR ノートブックカーネルはクラスター上で実行されます。これにより、ノートブックのパフォーマンスが向上し、カーネルをインストールおよびカスタマイズすることができます。また、クラスターのプライマリノードに Python ライブラリをインストールすることもできます。詳細については、「EMR 管理ガイド」の「カーネルとライブラリのインストールと使用」を参照してください。
マネージドスケーリング - Amazon EMR バージョン 5.30.0 以降では、EMR マネージドスケーリングを有効にすることで、ワークロードに応じてクラスター内のインスタンスやユニットの数を自動的に増減できます。Amazon EMR は引き続きクラスターのメトリクスを評価し、クラスターのコストと速度を最適化するためのスケーリングを決定します。詳細については、「Amazon EMR 管理ガイド」の「クラスターリソースのスケーリング」を参照してください。
Amazon S3 に保存されているログファイルの暗号化 - Amazon EMR バージョン 5.30.0 以降では、Amazon S3 に保存されているログファイルを AWS KMS カスタマー管理キーで暗号化することができます。詳細については、「Amazon EMR 管理ガイド」の「Amazon S3 に保存されているログファイルの暗号化」を参照してください。
Amazon Linux 2 のサポート - EMR バージョン 5.30.0 以降では、EMR は Amazon Linux 2 OS を使用します。新しいカスタム AMI (Amazon マシンイメージ) は、Amazon Linux 2 AMI に基づいている必要があります。詳細については、「カスタム AMI の使用」を参照してください。
Presto Graceful Auto Scale - 5.30.0 を使用する EMR クラスターでは、オートスケーリングのタイムアウト期間を設定することで、Presto タスクの実行が終了するまで待ってからノードの使用を停止できます。詳細については、「グレースフルな廃止による Presto Auto Scaling の使用」を参照してください。
新しい割り当て戦略オプションを使用したフリートインスタンスの作成 — EMR バージョン 5.12.1 以降では、新しい割り当て戦略オプションを使用できます。これにより、クラスターのプロビジョニングにかかる時間が短縮され、スポット割り当てがより正確になり、スポットインスタンスの中断が低減します。デフォルト以外の EMR サービスロールを更新する必要があります。「インスタンスフリートを構成する」を参照してください。
sudo systemctl stop コマンドと sudo systemctl start コマンド — Amazon Linux 2 OS を使用する EMR バージョン 5.30.0 以降では、EMR は sudo systemctl stop コマンドおよび sudo systemctl start コマンドを使用してサービスを再起動します。詳細については、「Amazon EMR でサービスを再起動するにはどうすればよいですか?」を参照してください。

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

EMR バージョン 5.30.0 では、デフォルトで Ganglia がインストールされません。クラスターの作成時に、Ganglia を明示的に選択してインストールできます。
Spark パフォーマンスの最適化。
Presto パフォーマンスの最適化。
Python 3 は、Amazon EMR バージョン 5.30.0 以降ではデフォルトです。
プライベートサブネット内のサービスアクセス用のデフォルトのマネージドセキュリティグループが更新され、複数の新しいルールが追加されました。サービスアクセスにカスタムセキュリティグループを使用している場合は、同じルールをデフォルトのマネージドセキュリティグループとして含める必要があります。詳細については、「サービスアクセスの Amazon EMR マネージドセキュリティグループ (プライベートサブネット)」を参照してください。Amazon EMR でカスタムサービスロールを使用する場合は、ec2:describeSecurityGroups にアクセス許可を付与して、セキュリティグループが正常に作成されたかどうかを EMR で検証できるようにする必要があります。EMR_DefaultRole を使用する場合、このアクセス許可はデフォルトのマネージドポリシーに既に含まれています。

既知の問題

古い 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 は、古いバージョンの Amazon Linux 2 (AL2) に基づいており、デフォルトの AMI を使用して Amazon EMR クラスターを作成する場合に「最大オープンファイル」の ulimit 設定が低くなります。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 のデフォルト AMI の「最大オープンファイル」はデフォルトの ulimit 設定 4096 になっており、最新の Amazon Linux 2 AMI の上限 65536 ファイルよりも低くなっています。「最大オープンファイル」の ulimit 設定が低い場合、Spark ドライバーとエグゼキュータが 4096 を超えるファイルを開こうとすると、Spark ジョブが失敗します。この問題を解決するために、Amazon EMR には、クラスターの作成時に ulimit 設定を調整するブートストラップアクション (BA) スクリプトが用意されています。

この問題の永続的な修正がない古い Amazon EMR バージョンを使用している場合は、以下の回避策を使用すると、instance-controller 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
```
マネージドスケーリング

Presto がインストールされていない 5.30.0 クラスターおよび 5.30.1 クラスターでマネージドスケーリング操作を実行すると、特にスケールダウン操作の後にすぐ、スケールアップ操作が実行されたときに、アプリケーション障害が発生するか、ユニフォームインスタンスグループまたはインスタンスフリートが ARRESTED 状態のままになる場合があります。

回避策として、ジョブに Presto が必要ない場合でも、Amazon EMR リリース 5.30.0 および 5.30.1 を使用してクラスターを作成するときに、インストールするアプリケーションとして Presto を選択します。
複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。
Hue 4.6.0 のデフォルトのデータベースエンジンは SQLite であり、外部データベースで Hue を使用しようとすると、SQLite が原因で問題が発生します。これを修正するには、hue-ini 設定分類の engine を mysql に設定します。この問題は、Amazon EMR バージョン 5.30.1 で修正されています。
Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。
- 同じテーブルから 2 つ以上のパーティションがスキャンされます。
- 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。
- 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。
この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。

リリース 5.29.0

次のリリースノートには、Amazon EMR リリース 5.29.0 に関する情報が含まれています。5.28.1 からの変更が含まれています。

初回リリース日: 2020 年 1 月 17 日

アップグレード

AWS SDK for Java をバージョン 1.11.682 にアップグレードしました
Hive をバージョン 2.3.6 にアップグレードしました
Flink をバージョン 1.9.1 にアップグレードしました
EMRFS をバージョン 2.38.0 にアップグレードしました
EMR DynamoDB Connector をバージョン 4.13.0 にアップグレードしました

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

Spark
- Spark パフォーマンスの最適化。
EMRFS
- 管理ガイドでは、整合性のあるビューを実現するために emrfs-site.xml デフォルト設定が更新されています。

既知の問題

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

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.28.1

次のリリースノートには、Amazon EMR リリース 5.28.1 に関する情報が含まれています。5.28.0 からの変更が含まれています。

初回リリース日: 2020 年 1 月 10 日

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

Spark
- Spark の互換性の問題が修正されました。
CloudWatch Metrics
- 複数のプライマリノードを持つ EMR クラスターでの Amazon CloudWatch メトリクスの発行が修正されました。
無効化されたログメッセージ
- 「...using old version (<4.5.8) of Apache http client」(Apache http クライアントの古いバージョン (<4.5.8) を使用) という誤ったログメッセージを無効にしました。

既知の問題

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

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.28.0

次のリリースノートには、Amazon EMR リリース 5.28.0 に関する情報が含まれています。変更は 5.27.0 に関連するものです。

初回リリース日: 2019 年 11 月 12 日

アップグレード

Flink をバージョン 1.9.0 にアップグレードしました
Hive をバージョン 2.3.6 にアップグレードしました
MXNet をバージョン 1.5.1 にアップグレードしました
Phoenix をバージョン 4.14.3 にアップグレードしました
Presto をバージョン 0.227 にアップグレードしました
Zeppelin をバージョン 0.8.2 にアップグレードしました

新機能

クラスターを作成するときに、Amazon EMR で Apache Hudi をインストールできるようになりました。詳細については、「Hudi」を参照してください。
(2019 年 11 月 25 日) 複数のステップを並行して選択して、クラスター使用率を改善し、コストを削減できるようになりました。また、保留中および実行中のステップの両方をキャンセルできるようになりました。詳細については、「AWS CLI およびコンソールを使用した手順の作業」を参照してください。
(2019 年 12 月 3 日) EMR クラスターを AWS Outposts で作成して実行できるようになりました。AWS Outposts により、オンプレミス施設でネイティブの AWS サービス、インフラストラクチャ、運用モデルが可能となりました。AWS Outposts 環境では、AWS クラウドで使用するのと同じ AWS API、ツール、インフラストラクチャを使用できます。詳細については、「AWS Outposts 上の EMR クラスター」を参照してください。
(2020 年 3 月 11 日) Amazon EMR バージョン 5.28.0 以降では、Local Zones をサポートする AWS リージョンの論理的拡張として、AWS Local Zones のサブネットで Amazon EMR クラスターを作成および実行できます。Local Zones を使用すると、Amazon EMR 機能と AWS のサービスのサブセット (コンピューティングサービスやストレージサービスなど) をユーザーの近くに配置して、ローカルで実行されるアプリケーションに非常に低いレイテンシーでアクセスできます。使用可能な Local Zones のリストについては、「AWS Local Zones」を参照してください。使用可能な AWS Local Zones へのアクセスの詳細については、「リージョン、アベイラビリティーゾーン、およびローカルゾーン」を参照してください。

Local Zones は、現在 Amazon EMR Notebooks をサポートしておらず、インターフェイス VPC エンドポイント (AWS PrivateLink) を使用した Amazon EMR への直接接続をサポートしていません。

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

高可用性クラスターに対するアプリケーションのサポートを拡大しました。
- 詳細については、「Amazon EMR 管理ガイド」の「複数のプライマリノードを持つ Amazon EMR クラスターでサポートされるアプリケーション」を参照してください。
Spark
- パフォーマンスの最適化
[Hive]
- パフォーマンスの最適化
Presto
- パフォーマンスの最適化

既知の問題

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

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.27.0

次のリリースノートには、Amazon EMR リリース 5.27.0 に関する情報が含まれています。5.26.0 からの変更が含まれています。

初回リリース日: 2019 年 9 月 23 日

アップグレード

AWS SDK for Java 1.11.615
Flink 1.8.1
JupyterHub 1.0.0
Spark 2.4.4
Tensorflow 1.14.0
コネクタおよびドライバー:
- DynamoDB Connector 4.12.0

新機能

(2019 年 10 月 24 日) EMR ノートブックの次の新機能は、すべての Amazon EMR リリースで利用できます。
- Git リポジトリを EMR ノートブックに関連付けて、バージョン管理された環境でノートブックを保存できます。リモートの Git リポジトリを使用して、コードをピアと共有し、既存の Jupyter Notebook を再利用できます。詳細については、「Amazon EMR 管理ガイド」の「Git リポジトリを Amazon EMR Notebooks に関連付ける」を参照してください。
- ノートブックの比較とマージを簡素化するために、nbdime ユーティリティが EMR ノートブックで利用できるようになりました。
- EMR ノートブックが JupyterLab をサポートするようになりました。JupyterLab は、Jupyter Notebook と完全に互換性があるウェブベースのインタラクティブな開発環境です。JupyterLab または Jupyter Notebook エディタでノートブックを開くことができるようになりました。
(2019 年 10 月 30 日) Amazon EMR バージョン 5.25.0 以降では、コンソールでクラスターの [概要] ページまたは [アプリケーションの履歴] タブから Spark 履歴サーバー UI に接続できます。SSH 接続でウェブプロキシを設定する代わりに、Spark 履歴サーバー UI にすばやくアクセスしてアプリケーションのメトリクスを確認し、アクティブなクラスターと終了したクラスターに関連するログファイルにアクセスできます。詳細については、「Amazon EMR 管理ガイド」の「永続アプリケーションユーザーインターフェイスへのクラスター外アクセス」を参照してください。

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

複数のプライマリノードを持つ Amazon EMR クラスター
- 複数のプライマリノードを持つ Amazon EMR クラスターに Flink をインストールして実行できます。詳細については、「サポートされるアプリケーションと機能」を参照してください。
- 複数のプライマリノードを持つ Amazon EMR クラスターに HDFS 透過的暗号化を設定することができます。詳細については、「HDFS Transparent Encryption on EMR clusters with Multiple Primary Nodes」を参照してください。
- 複数のプライマリノードを持つ Amazon EMR クラスターで実行されているアプリケーションの設定を変更できるようになりました。詳細については、「実行中のクラスター内のインスタンスグループの設定を指定する」を参照してください。
Amazon EMR-DynamoDB Connector
- Amazon EMR-DynamoDB Connector は、boolean、list、map、item、null の DynamoDB データ型をサポートするようになりました。詳細については、「Hive コマンドを実行するように Hive テーブルをセットアップする」を参照してください。

既知の問題

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

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.26.0

次のリリースノートには、Amazon EMR リリース 5.26.0 に関する情報が含まれています。5.25.0 からの変更が含まれています。

初回リリース日: 2019 年 8 月 8 日

最終更新日: 2019 年 8 月 19 日

アップグレード

AWS SDK for Java 1.11.595
HBase 1.4.10
Phoenix 4.14.2
コネクタおよびドライバー:
- DynamoDB Connector 4.11.0
- MariaDB Connector 2.4.2
- Amazon Redshift JDBC ドライバー 1.2.32.1056

新機能

(ベータ) Amazon EMR 5.26.0 を使用すると、Lake Formation と統合されるクラスターを起動できます。この統合により、AWS Glue Data Catalog 内のデータベースとテーブルへのきめ細かな列レベルのアクセスが提供されます。また、これにより、企業の ID システムから EMR Notebooks または Apache Zeppelin へのフェデレーションシングルサインオンが可能になります。詳細については、「Amazon EMR と AWS Lake Formation (ベータ) の統合」を参照してください。
(2019 年 8 月 19 日) Amazon EMR のパブリックアクセスブロックが、セキュリティグループをサポートしているすべての Amazon EMR リリースで利用できるようになりました。パブリックアクセスブロックは、各 AWS リージョンに適用されるアカウント全体の設定です。パブリックアクセスブロックにより、クラスターに関連付けられているセキュリティグループに、ポートで IPv4 0.0.0.0/0 または IPv6 ::/0 (パブリックアクセス) からのインバウンドトラフィックを許可するルールがある場合に、クラスターの起動が禁止されます (ポートが例外として指定されている場合を除く)。ポート 22 は、デフォルトで例外になります。詳細については、「Amazon EMR 管理ガイド」の「Amazon EMR のパブリックアクセスブロックの使用」を参照してください。

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

EMR Notebooks
- EMR 5.26.0 以降では、EMR Notebooks はデフォルトの Python ライブラリに加えて、ノートブックスコープの Python ライブラリもサポートしています。ノートブックスコープのライブラリは、クラスターを再作成したりノートブックをクラスターに再アタッチしたりすることなく、ノートブックエディター内からインストールできます。ノートブックスコープのライブラリは Python 仮想環境に作成されるため、現在のノートブックセッションにのみ適用されます。これにより、ノートブックの依存関係を分離できます。詳細については、「Amazon EMR 管理ガイド」の「ノートブックスコープのライブラリの使用」を参照してください。
EMRFS
- fs.s3.consistent.metadata.etag.verification.enabled を true に設定すると、ETag 検証機能 (ベータ) を有効にできます。この機能を有効にすると、EMRFS は Amazon S3 ETags を使用して、読み取られているオブジェクトが利用可能な最新バージョンであることを確認します。この機能は、Amazon S3 上のファイルが同じ名前を維持しながら上書きされる、更新後の読み取りのユースケースに役立ちます。この ETag 検証機能は、現在 S3 Select では使用できません。詳細については、「整合性のあるビューを設定する」を参照してください。
Spark
- 現在、次の最適化がデフォルトで有効になります: ダイナミックパーティションプルーニング、DISTINCT before INTERSECT、DISTINCT クエリが後に続く JOIN の SQL 計画統計推論の改善、スカラーサブクエリのフラット化、結合順序の最適化、ブルームフィルター結合。詳細については、「Spark のパフォーマンスの最適化」を参照してください。
- ソートマージ結合の全体的なステージコード生成が改善されました。
- クエリフラグメントとサブクエリの再利用が改善されました。
- Spark の起動時にエグゼキュターを事前割り当てする機能が改善されました。
- 結合の小さい側にブロードキャストヒントが含まれている場合、ブルームフィルター結合は適用されなくなりました。
Tez
- Tez に関する問題を解決しました。Tez UI は、複数のプライマリノードを持つ Amazon EMR クラスターで動作するようになりました。

既知の問題

ソートマージ結合の全体的なステージコード生成機能が改善されたことにより、有効にした場合、メモリプレッシャーが増加する可能性があります。この最適化によってパフォーマンスは向上しますが、十分なメモリを提供するように spark.yarn.executor.memoryOverheadFactor が調整されていない場合、ジョブの再試行または失敗が生じる可能性があります。この機能を無効にするには、spark.sql.sortMergeJoinExec.extendedCodegen.enabled を false に設定します。
複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.25.0

次のリリースノートには、Amazon EMR リリース 5.25.0 に関する情報が含まれています。5.24.1 からの変更が含まれています。

初回リリース日: 2019 年 7 月 17 日

最終更新日: 2019 年 10 月 30 日

Amazon EMR 5.25.0

アップグレード

AWS SDK for Java 1.11.566
Hive 2.3.5
Presto 0.220
Spark 2.4.3
TensorFlow 1.13.1
Tez 0.9.2
Zookeeper 3.4.14

新機能

(2019 年 10 月 30 日) Amazon EMR バージョン 5.25.0 以降では、コンソールでクラスターの [概要] ページまたは [アプリケーションの履歴] タブから Spark 履歴サーバー UI に接続できます。SSH 接続でウェブプロキシを設定する代わりに、Spark 履歴サーバー UI にすばやくアクセスしてアプリケーションのメトリクスを確認し、アクティブなクラスターと終了したクラスターに関連するログファイルにアクセスできます。詳細については、「Amazon EMR 管理ガイド」の「永続アプリケーションユーザーインターフェイスへのクラスター外アクセス」を参照してください。

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

Spark
- ブルームフィルターを使用して入力を事前フィルターすることで、一部の結合のパフォーマンスが改善されました。最適化はデフォルトでは無効になっており、Spark 設定パラメータ spark.sql.bloomFilterJoin.enabled を true に設定すると、有効にできます。
- 文字列型の列によるグループ化のパフォーマンスが改善されました。
- HBase がインストールされていないクラスターの R4 インスタンスタイプのデフォルトの Spark エグゼキュターメモリとコアの設定が改善されました。
- プルーニングするテーブルが結合の左側にある必要がある、ダイナミックパーティションプルーニング機能に関する以前の問題が解決されました。
- エイリアスを含む追加のケースに適用できるように、DISTINCT before INTERSECT 最適化が改善されました。
- DISTINCT クエリが後に続く JOIN の SQL 計画統計推論が改善されました。この改善はデフォルトでは無効になっており、Spark 設定パラメータ spark.sql.statsImprovements.enabled を true に設定すると、有効にできます。この最適化は Distinct before Intersect 機能で必要であり、spark.sql.optimizer.distinctBeforeIntersect.enabled を true に設定すると、自動的に有効になります。
- テーブルのサイズとフィルターに基づいて結合順序が最適化されました。この最適化はデフォルトでは無効になっており、Spark 設定パラメータ spark.sql.optimizer.sizeBasedJoinReorder.enabled を true に設定すると、有効にできます。
詳細については、「Spark のパフォーマンスの最適化」を参照してください。
EMRFS
- EMRFS の設定 fs.s3.buckets.create.enabled は、現在、デフォルトでは無効になります。テストでは、この設定を無効にすると、パフォーマンスが向上し、S3 バケットが意図せずに作成されることがなくなることがわかりました。アプリケーションがこの機能に依存する場合は、emrfs-site 設定分類でプロパティ fs.s3.buckets.create.enabled を true に設定すると、この機能を有効にできます。詳細については、「クラスターの作成時に設定を指定する」を参照してください。
セキュリティ設定のローカルディスク暗号化と S3 暗号化の改善 (2019 年 8 月 5 日)
- セキュリティ設定のセットアップで、Amazon S3 暗号化設定をローカルディスク暗号化設定から分離しました。
- リリース 5.24.0 以降で、EBS 暗号化を有効にするオプションが追加されました。このオプションを選択すると、ストレージボリュームに加えてルートデバイスボリュームが暗号化されます。以前のバージョンでは、ルートデバイスボリュームを暗号化するにはカスタム AMI を使用する必要がありました。
- 詳細については、「Amazon EMR 管理ガイド」の「暗号化オプション」を参照してください。

既知の問題

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

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.24.1

次のリリースノートには、Amazon EMR リリース 5.24.1 に関する情報が含まれています。5.24.0 からの変更が含まれています。

初回リリース日: 2019 年 6 月 26 日

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

TCP SACK サービス拒否の問題 (AWS-2019-005) など、重要な Linux カーネルセキュリティ更新を含めるように、Amazon EMR のデフォルトの Amazon Linux AMI を更新しました。

既知の問題

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

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.24.0

次のリリースノートには、Amazon EMR リリース 5.24.0 に関する情報が含まれています。5.23.0 からの変更が含まれています。

初回リリース日: 2019 年 6 月 11 日

最終更新日: 2019 年 8 月 5 日

アップグレード

Flink 1.8.0
Hue 4.4.0
JupyterHub 0.9.6
Livy 0.6.0
MxNet 1.4.0
Presto 0.219
Spark 2.4.2
AWS SDK for Java 1.11.546
コネクタおよびドライバー:
- DynamoDB Connector 4.9.0
- MariaDB Connector 2.4.1
- Amazon Redshift JDBC ドライバー 1.2.27.1051

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

Spark
- パーティションを動的にプルーニングするための最適化を追加しました。この最適化はデフォルトで無効になっています。これを有効にするには、Spark 設定パラメータ spark.sql.dynamicPartitionPruning.enabled を true に設定します。
- INTERSECT のクエリのパフォーマンスが改善されました。この最適化はデフォルトで無効になっています。これを有効にするには、Spark 設定パラメータ spark.sql.optimizer.distinctBeforeIntersect.enabled を true に設定します。
- 同じリレーションを使用する集計でスカラーサブクエリをフラット化するための最適化が追加されました。この最適化はデフォルトで無効になっています。これを有効にするには、Spark 設定パラメータ spark.sql.optimizer.flattenScalarSubqueriesWithAggregates.enabled を true に設定します。
- 全体的なステージコード生成が改善されました。
詳細については、「Spark のパフォーマンスの最適化」を参照してください。
セキュリティ設定のローカルディスク暗号化と S3 暗号化の改善 (2019 年 8 月 5 日)
- セキュリティ設定のセットアップで、Amazon S3 暗号化設定をローカルディスク暗号化設定から分離しました。
- EBS 暗号化を有効にするオプションが追加されました。このオプションを選択すると、ストレージボリュームに加えてルートデバイスボリュームが暗号化されます。以前のバージョンでは、ルートデバイスボリュームを暗号化するにはカスタム AMI を使用する必要がありました。
- 詳細については、「Amazon EMR 管理ガイド」の「暗号化オプション」を参照してください。

既知の問題

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

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.23.0

次のリリースノートには、Amazon EMR リリース 5.23.0 に関する情報が含まれています。5.22.0 からの変更が含まれています。

初回リリース日: 2019 年 4 月 1 日

最終更新日: 2019 年 4 月 30 日

アップグレード

AWS SDK for Java 1.11.519

新機能

(2019 年 4 月 30 日) Amazon EMR 5.23.0 以降では、YARN リソースマネージャー、HDFS NameNode、Spark、Hive、Ganglia といったアプリケーションの高可用性をサポートできるように、3 つのプライマリノードを持つクラスターを起動できます。プライマリノードは、現在この機能による潜在的な単一障害点ではありません。プライマリノードのいずれかに障害が発生した場合、Amazon EMR は自動的にスタンバイプライマリノードにフェイルオーバーし、障害が発生したプライマリノードを同じ設定とブートストラップアクションを持つ新しいプライマリノードに置き換えます。詳細については、「プライマリノードの計画と設定」を参照してください。

既知の問題

Tez UI (Amazon EMR リリース 5.26.0 で修正)

Tez UI は、複数のプライマリノードを持つ EMR クラスターでは動作しません。
Hue (Amazon EMR リリース 5.24.0 で修正)
- Amazon EMR で実行される Hue では、Solr はサポートされません。Amazon EMR リリース 5.20.0 以降、誤設定の問題により Solr が有効になり、次のような無害なエラーメッセージが表示されます。
  
  Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))
  
  Solr のエラーメッセージが表示されないようにするには、以下の操作を行います。
  1. SSH を使用してプライマリノードのコマンドラインに接続します。
  2. テキストエディタを使用して、hue.ini ファイルを開きます。例:
    
    sudo vim /etc/hue/conf/hue.ini
  3. 語句 appblacklist を検索して、行を次のように変更します。
    
    appblacklist = search
  4. 変更を保存して、次の例に示すように Hue を再起動します。
    
    sudo stop hue; sudo start hue
複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.22.0

次のリリースノートには、Amazon EMR リリース 5.22.0 に関する情報が含まれています。5.21.0 からの変更が含まれています。

重要

Amazon EMR リリース 5.22.0 以降、Amazon EMR は AWS 署名バージョン 4 のみを使用して Amazon S3 へのリクエストを認証します。リリースノートに署名バージョン 4 のみが使用されることが示されていない限り、それ以前の Amazon EMR リリースでは、場合によっては AWS 署名バージョン 2 が使用されることがあります。詳細については、「Amazon Simple Storage Service デベロッパーガイド」の「リクエストの認証 (AWS 署名バージョン 4)」および「リクエストの認証 (AWS 署名バージョン 2)」を参照してください。

初回リリース日: 2019 年 3 月 20 日

アップグレード

Flink 1.7.1
HBase 1.4.9
Oozie 5.1.0
Phoenix 4.14.1
Zeppelin 0.8.1
コネクタおよびドライバー:
- DynamoDB Connector 4.8.0
- MariaDB Connector 2.2.6
- Amazon Redshift JDBC ドライバー 1.2.20.1043

新機能

EBS 専用ストレージを使用する EC2 インスタンスタイプのデフォルトの EBS 設定を変更しました。Amazon EMR リリース 5.22.0 以降を使用してクラスターを作成する場合、デフォルトの EBS ストレージ容量はインスタンスのサイズに基づいて増加します。さらに、増加したストレージを複数のボリュームに分割することで、IOPS のパフォーマンスが向上しました。別の EBS インスタンスストレージ設定を使用する場合は、EMR クラスターを作成する際、または既存のクラスターをノードに追加する際に指定することができます。インスタンスタイプごとにデフォルトで割り当てられるストレージ容量とボリューム数の詳細については、「Amazon EMR 管理ガイド」の「インスタンスのデフォルト EBS ストレージ」を参照してください。

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

Spark
- YARN の Spark 用に新しい設定プロパティ spark.yarn.executor.memoryOverheadFactor が導入されました。このプロパティの値は、メモリオーバーヘッドの値をエグゼキュターメモリのパーセントに設定するスケール係数であり、最小は 384 MB です。spark.yarn.executor.memoryOverhead を使用してメモリオーバーヘッドが明示的に設定されている場合、このプロパティは影響しません。デフォルト値は 0.1875 で、18.75% を表します。Amazon EMR のこのデフォルトは、Spark で内部的に設定されたデフォルトの 10% よりも、エグゼキュターのメモリオーバーヘッド用に YARN コンテナに余分なスペースを残します。Amazon EMR のデフォルトの 18.75% では、TPC-DS ベンチマークでメモリ関連の障害が減ることが実証されています。
- パフォーマンスを向上させるために SPARK-26316 をバックポートしました。
Amazon EMR バージョン 5.19.0、5.20.0、および 5.21.0 では、YARN ノードラベルは HDFS ディレクトリに保存されます。状況によっては、このために、コアノードの起動が遅延し、クラスターのタイムアウトや起動エラーが発生します。Amazon EMR 5.22.0 以降、この問題は解決されています。YARN ノードラベルは各クラスターノードのローカルディスクに保存され、HDFS への依存が回避されています。

既知の問題

Hue (Amazon EMR リリース 5.24.0 で修正)
- Amazon EMR で実行される Hue では、Solr はサポートされません。Amazon EMR リリース 5.20.0 以降、誤設定の問題により Solr が有効になり、次のような無害なエラーメッセージが表示されます。
  
  Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))
  
  Solr のエラーメッセージが表示されないようにするには、以下の操作を行います。
  1. SSH を使用してプライマリノードのコマンドラインに接続します。
  2. テキストエディタを使用して、hue.ini ファイルを開きます。例:
    
    sudo vim /etc/hue/conf/hue.ini
  3. 語句 appblacklist を検索して、行を次のように変更します。
    
    appblacklist = search
  4. 変更を保存して、次の例に示すように Hue を再起動します。
    
    sudo stop hue; sudo start hue
複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.21.1

次のリリースノートには、Amazon EMR リリース 5.21.1 に関する情報が含まれています。5.21.0 からの変更が含まれています。

初回リリース日: 2019 年 7 月 18 日

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

TCP SACK サービス拒否の問題 (AWS-2019-005) など、重要な Linux カーネルセキュリティ更新を含めるように、Amazon EMR のデフォルトの Amazon Linux AMI を更新しました。

既知の問題

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

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.21.0

次のリリースノートには、Amazon EMR リリース 5.21.0 に関する情報が含まれています。5.20.0 からの変更が含まれています。

リリース日: 2019 年 2 月 18 日

最終更新日: 2019 年 4 月 3 日

アップグレード

Flink 1.7.0
Presto 0.215
AWS SDK for Java 1.11.479

新機能

(2019 年 4 月 3 日) Amazon EMR バージョン 5.21.0 以降では、実行中のクラスター内のインスタンスグループごとに、クラスター設定を上書きして追加の設定分類を指定できます。これを行うには、Amazon EMR コンソール、AWS Command Line Interface (AWS CLI)、または AWS SDK を使用します。詳細については、「実行中のクラスター内のインスタンスグループの設定を指定する」を参照してください。

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

Zeppelin
- ZEPPELIN-3878 をバックポートしました。

既知の問題

Hue (Amazon EMR リリース 5.24.0 で修正)
- Amazon EMR で実行される Hue では、Solr はサポートされません。Amazon EMR リリース 5.20.0 以降、誤設定の問題により Solr が有効になり、次のような無害なエラーメッセージが表示されます。
  
  Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))
  
  Solr のエラーメッセージが表示されないようにするには、以下の操作を行います。
  1. SSH を使用してプライマリノードのコマンドラインに接続します。
  2. テキストエディタを使用して、hue.ini ファイルを開きます。例:
    
    sudo vim /etc/hue/conf/hue.ini
  3. 語句 appblacklist を検索して、行を次のように変更します。
    
    appblacklist = search
  4. 変更を保存して、次の例に示すように Hue を再起動します。
    
    sudo stop hue; sudo start hue
Tez
- この問題は、Amazon EMR 5.22.0 で修正されています。
  
  クラスタープライマリノードへの SSH 接続を使用して http://MasterDNS:8080/tez-ui で Tez UI に接続すると、「Adapter operation failed - Timeline server (ATS) is out of reach。Either it is down, or CORS is not enabled」(アダプタの操作に失敗しました - タイムラインサーバー (ATS) に到達できません。停止しているか、または CORS が有効になっていません) というエラーが表示されるか、タスクで予期せずに N/A と表示されます。
  
  これは、Tez UI がプライマリノードのホスト名ではなく localhost を使用して YARN タイムラインサーバーにリクエストを行ったことが原因で発生します。回避策として、ブートストラップアクションまたはステップとしてスクリプトを実行できます。このスクリプトで、Tez configs.env ファイル内のホスト名を更新します。スクリプトの詳細と場所については、「Bootstrap Instructions」を参照してください。
Amazon EMR バージョン 5.19.0、5.20.0、および 5.21.0 では、YARN ノードラベルは HDFS ディレクトリに保存されます。状況によっては、このために、コアノードの起動が遅延し、クラスターのタイムアウトや起動エラーが発生します。Amazon EMR 5.22.0 以降、この問題は解決されています。YARN ノードラベルは各クラスターノードのローカルディスクに保存され、HDFS への依存が回避されています。
複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.20.0

次のリリースノートには、Amazon EMR リリース 5.20.0 に関する情報が含まれています。5.19.0 からの変更が含まれています。

初回リリース日: 2018 年 12 月 18 日

最終更新: 2019 年 1 月 22 日

アップグレード

Flink 1.6.2
HBase 1.4.8
Hive 2.3.4
Hue 4.3.0
MXNet 1.3.1
Presto 0.214
Spark 2.4.0
TensorFlow 1.12.0
Tez 0.9.1
AWS SDK for Java 1.11.461

新機能

(2019 年 1 月 22 日) Amazon EMR の Kerberos は、外部 KDC からのプリンシパルの認証をサポートするように改善されました。これにより、複数のクラスターが単一の外部 KDC を共有できるため、プリンシパル管理が集中化されます。さらに、外部 KDC は Active Directory ドメインとのクロス領域信頼を得られます。これにより、すべてのクラスターが Active Directory からプリンシパルを認証できます。詳しくは、「Amazon EMR 管理ガイド」の「Kerberos 認証を使用する」を参照してください。

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

Amazon EMR のデフォルトの Amazon Linux AMI
- Python3 パッケージが python 3.4 から 3.6 にアップグレードされました。
EMRFS S3 向けに最適化されたコミッター
- 現在、EMRFS S3 向けに最適化されたコミッターがデフォルトで有効になるため、書き込みパフォーマンスが向上します。詳細については、「EMRFS S3 向けに最適化されたコミッターを使用する」を参照してください。
[Hive]
- HIVE-16686 をバックポートしました。
Spark と Hive での Glue
- EMR 5.20.0 以降では、メタストアとして AWS Glue Data Catalog が使用されている場合、Spark と Hive に対して並列パーティションプルーニングが自動的に有効になります。この変更により、複数のリクエストを並列に実行してパーティションを取得できるため、クエリ計画時間が大幅に短縮されます。同時に実行できるセグメントの総数は、1～10 の範囲です。デフォルト値は 5 であり、これが推奨される設定です。hive-site 設定分類の aws.glue.partition.num.segments プロパティを指定すると、これを変更できます。スロットリングが発生した場合は、値を 1 に変更して機能をオフにすることができます。詳細については、「AWS Glue セグメント構造」を参照してください。

既知の問題

Hue (Amazon EMR リリース 5.24.0 で修正)
- Amazon EMR で実行される Hue では、Solr はサポートされません。Amazon EMR リリース 5.20.0 以降、誤設定の問題により Solr が有効になり、次のような無害なエラーメッセージが表示されます。
  
  Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))
  
  Solr のエラーメッセージが表示されないようにするには、以下の操作を行います。
  1. SSH を使用してプライマリノードのコマンドラインに接続します。
  2. テキストエディタを使用して、hue.ini ファイルを開きます。例:
    
    sudo vim /etc/hue/conf/hue.ini
  3. 語句 appblacklist を検索して、行を次のように変更します。
    
    appblacklist = search
  4. 変更を保存して、次の例に示すように Hue を再起動します。
    
    sudo stop hue; sudo start hue
Tez
- この問題は、Amazon EMR 5.22.0 で修正されています。
  
  クラスタープライマリノードへの SSH 接続を使用して http://MasterDNS:8080/tez-ui で Tez UI に接続すると、「Adapter operation failed - Timeline server (ATS) is out of reach。Either it is down, or CORS is not enabled」(アダプタの操作に失敗しました - タイムラインサーバー (ATS) に到達できません。停止しているか、または CORS が有効になっていません) というエラーが表示されるか、タスクで予期せずに N/A と表示されます。
  
  これは、Tez UI がプライマリノードのホスト名ではなく localhost を使用して YARN タイムラインサーバーにリクエストを行ったことが原因で発生します。回避策として、ブートストラップアクションまたはステップとしてスクリプトを実行できます。このスクリプトで、Tez configs.env ファイル内のホスト名を更新します。スクリプトの詳細と場所については、「Bootstrap Instructions」を参照してください。
Amazon EMR バージョン 5.19.0、5.20.0、および 5.21.0 では、YARN ノードラベルは HDFS ディレクトリに保存されます。状況によっては、このために、コアノードの起動が遅延し、クラスターのタイムアウトや起動エラーが発生します。Amazon EMR 5.22.0 以降、この問題は解決されています。YARN ノードラベルは各クラスターノードのローカルディスクに保存され、HDFS への依存が回避されています。
複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

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

回避方法:
- 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。
- 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。
```
kinit -kt <keytab_file> <principal>
```
  通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。
注記
この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

リリース 5.19.0

次のリリースノートには、Amazon EMR リリース 5.19.0 に関する情報が含まれています。5.18.0 からの変更が含まれています。

リリース日: 2018 年 11 月 7 日

最終更新日: 2018 年 11 月 19 日

アップグレード

Hadoop 2.8.5
Flink 1.6.1
JupyterHub 0.9.4
MXNet 1.3.0
Presto 0.212
TensorFlow 1.11.0
Zookeeper 3.4.13
AWS SDK for Java 1.11.433

新機能

(2018 年 11 月 19 日) EMR Notebooks は、Jupyter Notebook に基づいたマネージド環境です。PySpark、Spark SQL、Spark R、および Scala の Sparkmagic カーネルをサポートしています。EMR Notebooks は、Amazon EMR リリース 5.18.0 以降を使用して作成されたクラスターで使用できます。詳細については、「Amazon EMR 管理ガイド」の「EMR Notebooks の使用」を参照してください。
EMRFS S3 向けに最適化されたコミッターは、Spark と EMRFS を使用して Parquet ファイルを書き込むときに利用できます。このコミッターにより、書き込みパフォーマンスが向上します。詳細については、「EMRFS S3 向けに最適化されたコミッターを使用する」を参照してください。

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

YARN
- アプリケーションマスタープロセスをコアノードで実行するように制限するロジックを修正しました。現在、この機能では、yarn-site 設定分類および capacity-scheduler 設定分類の YARN ノードラベル機能とプロパティを使用しています。詳細については、「https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html#emr-plan-spot-YARN.」を参照してください。
Amazon EMR のデフォルトの Amazon Linux AMI
- ruby18、php56、および gcc48 は、デフォルトではインストールされなくなりました。必要に応じて、yum を使用してインストールできます。
- aws-sdk ruby gem は、デフォルトではインストールされなくなりました。必要に応じて、gem install aws-sdk を使用してインストールできます。特定のコンポーネントをインストールすることもできます。例えば、gem install aws-sdk-s3 です。

既知の問題

EMR Notebooks — 状況によっては、複数のノートブックエディタが開いているときに、ノートブックエディタがクラスターに接続できないように見えることがあります。このような場合は、ブラウザの Cookie をクリアしてから、ノートブックエディタを再度開きます。
CloudWatch ContainerPending メトリクスと自動スケーリング — (5.20.0 で修正) Amazon EMR は ContainerPending に負の値を出力する可能性があります。ContainerPending が自動スケーリングルールで使用されている場合、自動スケーリングは期待どおりに動作しません。ContainerPending を自動スケーリングで使用しないでください。
Amazon EMR バージョン 5.19.0、5.20.0、および 5.21.0 では、YARN ノードラベルは HDFS ディレクトリに保存されます。状況によっては、このために、コアノードの起動が遅延し、クラスターのタイムアウトや起動エラーが発生します。Amazon EMR 5.22.0 以降、この問題は解決されています。YARN ノードラベルは各クラスターノードのローカルディスクに保存され、HDFS への依存が回避されています。

リリース 5.18.0

次のリリースノートには、Amazon EMR リリース 5.18.0 に関する情報が含まれています。5.17.0 からの変更が含まれています。

初回リリース日: 2018 年 10 月 24 日

アップグレード

Flink 1.6.0
HBase 1.4.7
Presto 0.210
Spark 2.3.2
Zeppelin 0.8.0

新機能

Amazon EMR 5.18.0 以降では、Amazon EMR アーティファクトリポジトリを使用し、特定の Amazon EMR リリースで利用可能なライブラリおよび依存関係の正確なバージョンに対してジョブコードをビルドできます。詳細については、「Amazon EMR アーティファクトリポジトリを使用して依存関係を確認する」を参照してください。

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

[Hive]
- S3 Select のサポートが追加されました。詳細については、「S3 Select と Hive を使用してパフォーマンスを向上させる」を参照してください。
Presto
- S3 Select Pushdown のサポートが追加されました。詳細については、「S3 Select Pushdown と Presto を使用してパフォーマンスを向上させる」を参照してください。
Spark
- Spark のデフォルトの log4j 設定が、Spark ストリーミングジョブのコンテナログを毎時ロールするように変更されました。これにより、長時間実行されている Spark ストリーミングジョブのログが削除されるのを防ぐことができます。

リリース 5.17.1

次のリリースノートには、Amazon EMR リリース 5.17.1 に関する情報が含まれています。5.17.0 からの変更が含まれています。

初回リリース日: 2019 年 7 月 18 日

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

TCP SACK サービス拒否の問題 (AWS-2019-005) など、重要な Linux カーネルセキュリティ更新を含めるように、Amazon EMR のデフォルトの Amazon Linux AMI を更新しました。

リリース 5.17.0

次のリリースノートには、Amazon EMR リリース 5.17.0 に関する情報が含まれています。5.16.0 からの変更が含まれています。

初回リリース日: 2018 年 8 月 30 日

アップグレード

Flink 1.5.2
HBase 1.4.6
Presto 0.206

新機能

TensorFlow のサポートが追加されました。詳細については、「TensorFlow」を参照してください。

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

JupyterHub
- Amazon S3 でのノートブックの永続性のサポートが追加されました。詳細については、「Amazon S3 でノートブックの永続性を設定するには」を参照してください。
Spark
- S3 Select のサポートが追加されました。詳細については、「S3 Select と Spark を使用してクエリパフォーマンスを向上させる」を参照してください。
Amazon EMR バージョン 5.14.0、5.15.0、または 5.16.0 での Cloudwatch メトリクスと自動スケーリング機能に関する問題が解決されました。

既知の問題

Livy がインストールされた Kerberized クラスターを作成すると、Livy が失敗して、簡易認証が有効になっていないというエラーが表示されます。Livy サーバーを再起動すると、問題が解決されます。回避策として、クラスターの作成時に、プライマリノードで sudo restart livy-server を実行するステップを追加します。
作成日が 2018-08-11 の Amazon Linux AMI に基づくカスタム Amazon Linux AMI を使用すると、Oozie サーバーの起動に失敗します。Oozie を使用する場合は、作成日が異なる Amazon Linux AMI ID に基づいてカスタム AMI を作成します。次の AWS CLI コマンドを使用して、2018.03 バージョンのすべての HVM Amazon Linux AMI のイメージ ID とリリース日のリストを返し、ベースとして適切な Amazon Linux AMI を選択できます。MyRegion はリージョン ID (us-west-2 など) に置き換えます。
```
aws ec2 --region MyRegion describe-images --owner amazon --query 'Images[?Name!=`null`]|[?starts_with(Name, `amzn-ami-hvm-2018.03`) == `true`].[CreationDate,ImageId,Name]' --output text | sort -rk1
```

リリース 5.16.0

次のリリースノートには、Amazon EMR リリース 5.16.0 に関する情報が含まれています。5.15.0 からの変更が含まれています。

初回リリース日: 2018 年 7 月 19 日

アップグレード

Hadoop 2.8.4
Flink 1.5.0
Livy 0.5.0
MXNet 1.2.0
Phoenix 4.14.0
Presto 0.203
Spark 2.3.1
AWS SDK for Java 1.11.336
CUDA 9.2
Redshift JDBC ドライバー 1.2.15.1025

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

HBase
- HBASE-20723 をバックポートしました。
Presto
- LDAP 認証をサポートするための設定変更。詳細については、「Amazon EMR の Presto に LDAP 認証を使用する」を参照してください。
Spark
- Apache Spark バージョン 2.3.1 は Amazon EMR リリース 5.16.0 以降で利用でき、CVE-2018-8024 および CVE-2018-1334 に対処します。Spark の以前のバージョンを Spark バージョン 2.3.1 以降に移行することをお勧めします。

既知の問題

このリリースバージョンでは、c1.medium インスタンスタイプまたは m1.small インスタンスタイプはサポートされていません。これらのインスタンスタイプのいずれかを使用するクラスターは起動しません。回避策として、別のインスタンスタイプを指定するか、別のリリースバージョンを使用します。
Livy がインストールされた Kerberized クラスターを作成すると、Livy が失敗して、簡易認証が有効になっていないというエラーが表示されます。Livy サーバーを再起動すると、問題が解決されます。回避策として、クラスターの作成時に、プライマリノードで sudo restart livy-server を実行するステップを追加します。
プライマリノードの再起動後またはインスタンスコントローラーの再起動後に、Amazon EMR バージョン 5.14.0、5.15.0、または 5.16.0 で、CloudWatch メトリクスが収集されず、自動スケーリング機能が使用できなくなります。この問題は、Amazon EMR 5.17.0 で修正されています。

リリース 5.15.0

次のリリースノートには、Amazon EMR リリース 5.15.0 に関する情報が含まれています。5.14.0 からの変更が含まれています。

初回リリース日: 2018 年 6 月 21 日

アップグレード

HBase を 1.4.4 にアップグレードしました
Hive を 2.3.3 にアップグレードしました
Hue を 4.2.0 にアップグレードしました
Oozie を 5.0.0 にアップグレードしました
ZooKeeper を 3.4.12 にアップグレードしました
AWS SDK を 1.11.333 にアップグレードしました

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

[Hive]
- HIVE-18069 をバックポートしました。
Hue
- Kerberos が有効になっている場合に Livy で正しく認証されるように Hue を更新しました。Amazon EMR で Kerberos を使用する場合、Livy がサポートされるようになりました。
JupyterHub
- Amazon EMR がデフォルトで LDAP クライアントライブラリをインストールするように JupyterHub を更新しました。
- 自己署名証明書を生成するスクリプトのエラーを修正しました。

既知の問題

このリリースバージョンでは、c1.medium インスタンスタイプまたは m1.small インスタンスタイプはサポートされていません。これらのインスタンスタイプのいずれかを使用するクラスターは起動しません。回避策として、別のインスタンスタイプを指定するか、別のリリースバージョンを使用します。
プライマリノードの再起動後またはインスタンスコントローラーの再起動後に、Amazon EMR バージョン 5.14.0、5.15.0、または 5.16.0 で、CloudWatch メトリクスが収集されず、自動スケーリング機能が使用できなくなります。この問題は、Amazon EMR 5.17.0 で修正されています。

リリース 5.14.1

次のリリースノートには、Amazon EMR リリース 5.14.1 に関する情報が含まれています。5.14.0 からの変更が含まれています。

初回リリース日: 2018 年 10 月 17 日

潜在的なセキュリティ脆弱性に対処するために Amazon EMR のデフォルトの AMI を更新しました。

リリース 5.14.0

次のリリースノートには、Amazon EMR リリース 5.14.0 に関する情報が含まれています。5.13.0 からの変更が含まれています。

初回リリース日: 2018 年 6 月 4 日

アップグレード

Apache Flink を 1.4.2 にアップグレードしました
Apache MXNet を 1.1.0 にアップグレードしました
Apache Sqoop を 1.4.7 にアップグレードしました

新機能

JupyterHub のサポートを追加しました詳細については、「JupyterHub」を参照してください。

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

EMRFS
- Amazon S3 へのリクエスト内の UserAgent 文字列が、呼び出し元のプリンシパルのユーザーおよびグループの情報を含めるように更新されました。これを AWS CloudTrail ログと共に使用すると、より包括的なリクエスト追跡を行うことができます。
HBase
- HBASE-20447 が含まれました。これにより、特に分割されたリージョンで、キャッシュの問題を引き起こす可能性のある問題に対処します。
MXNet
- OpenCV ライブラリを追加しました。
Spark
- Spark が EMRFS を使用して Amazon S3 の場所に Parquet ファイルを書き込む場合、FileOutputCommitter アルゴリズムがバージョン 1 ではなくバージョン 2 を使用するように更新されました。これにより、名前変更の数が減り、アプリケーションのパフォーマンスが向上します。この変更は、以下には影響しません。
  - Spark 以外のアプリケーション。
  - HDFS などの他のファイルシステムに書き込むアプリケーション (FileOutputCommitter のバージョン 1 を引き続き使用している)。
  - テキストや csv など、EMRFS 直接書き込みを既に使用している、他の出力形式を使用するアプリケーション。

既知の問題

JupyterHub
- クラスターの作成時に、構成分類を使用して JupyterHub および個々の Jupyter Notebook をセットアップすることは、サポートされていません。各ユーザーの jupyterhub_config.py ファイルと jupyter_notebook_config.py ファイルを手動で編集します。詳細については、「JupyterHub の設定」を参照してください。
- JupyterHub がプライベートサブネット内のクラスターで起動できず、失敗してメッセージ Error: ENOENT: no such file or directory, open '/etc/jupyter/conf/server.crt' が表示されます。これは、自己署名証明書を生成するスクリプトのエラーが原因で発生します。次の回避策を使用して自己署名証明書を生成します。すべてのコマンドは、プライマリノードに接続している間に実行されます。
  1. 証明書生成スクリプトをコンテナからプライマリノードにコピーします。
    
    sudo docker cp jupyterhub:/tmp/gen_self_signed_cert.sh ./
  2. テキストエディタを使用して 23 行目を変更し、以下に示すようにパブリックホスト名をローカルホスト名に変更します。
    
    local hostname=$(curl -s $EC2_METADATA_SERVICE_URI/local-hostname)
  3. スクリプトを実行して、自己署名証明書を生成します。
    
    sudo bash ./gen_self_signed_cert.sh
  4. スクリプトによって生成される証明書ファイルを /etc/jupyter/conf/ ディレクトリに移動します。:
    
    sudo mv /tmp/server.crt /tmp/server.key /etc/jupyter/conf/
  jupyter.log ファイルに tail を実行して、JupyterHub が再起動しており、200 レスポンスコードを返していることを確認できます。例:
```
tail -f /var/log/jupyter/jupyter.log
```
  これで、次のようなレスポンスが返されます。
```
# [I 2018-06-14 18:56:51.356 JupyterHub app:1581] JupyterHub is now running at https://:9443/
# 19:01:51.359 - info: [ConfigProxy] 200 GET /api/routes 
```
プライマリノードの再起動後またはインスタンスコントローラーの再起動後に、Amazon EMR バージョン 5.14.0、5.15.0、または 5.16.0 で、CloudWatch メトリクスが収集されず、自動スケーリング機能が使用できなくなります。この問題は、Amazon EMR 5.17.0 で修正されています。

リリース 5.13.0

次のリリースノートには、Amazon EMR リリース 5.13.0 に関する情報が含まれています。5.12.0 からの変更が含まれています。

アップグレード

Spark を 2.3.0 にアップグレードしました
HBase を 1.4.2 にアップグレードしました
Presto を 0.194 にアップグレードしました
AWS SDK for Java を 1.11.297 にアップグレードしました

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

[Hive]
- HIVE-15436 をバックポートしました。ビューのみを返すように Hive API が拡張されました。

既知の問題

MXNet には現在 OpenCV ライブラリがありません。

リリース 5.12.2

次のリリースノートには、Amazon EMR リリース 5.12.2 に関する情報が含まれています。5.12.1 からの変更が含まれています。

初回リリース日: 2018 年 8 月 29 日

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

このリリースでは、潜在的なセキュリティ脆弱性に対処しています。

リリース 5.12.1

次のリリースノートには、Amazon EMR リリース 5.12.1 に関する情報が含まれています。5.12.0 からの変更が含まれています。

初回リリース日: 2018 年 3 月 29 日

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

潜在的な脆弱性に対処するために、Amazon EMR のデフォルトの Amazon Linux AMI の Amazon Linux カーネルを更新しました。

リリース 5.12.0

次のリリースノートには、Amazon EMR リリース 5.12.0 に関する情報が含まれています。5.11.1 からの変更が含まれています。

アップグレード

AWS SDK for Java 1.11.238 ⇒ 1.11.267。詳細については、GitHub の「AWS SDK for Java Change Log」を参照してください。
Hadoop 2.7.3 ⇒ 2.8.3。詳細については、「Apache Hadoop リリース」を参照してください。
Flink 1.3.2 ⇒ 1.4.0。詳細については、「Apache Flink 1.4.0 リリースに関するお知らせ」を参照してください。
HBase 1.3.1 ⇒ 1.4.0。詳細については、「HBase リリースに関するお知らせ」を参照してください。
Hue 4.0.1 ⇒ 4.1.0。詳細については、「リリースノート」を参照してください。
MxNet 0.12.0 ⇒ 1.0.0。詳細については、GitHub の「MXNet Change Log」を参照してください。
Presto 0.187 ⇒ 0.188。詳細については、「リリースノート」を参照してください。

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

Hadoop
- yarn.resourcemanager.decommissioning.timeout プロパティは yarn.resourcemanager.nodemanager-graceful-decommission-timeout-secs に変更されました。このプロパティを使用して、クラスターのスケールダウンをカスタマイズできます。詳細については、「Amazon EMR 管理ガイド」の「クラスターのスケールダウン」を参照してください。
- Hadoop CLI で、直接コピーを指定する -d オプションが cp (copy) コマンドに追加されました。これを使用すると、中間の .COPYING ファイルを作成しないようにできるため、Amazon S3 間でのデータのコピーが高速になります。詳細については、HADOOP-12384 を参照してください。
Pig
- Pig 環境プロパティの設定を簡素化する pig-env 構成分類が追加されました。詳細については、「アプリケーションの設定」を参照してください。
Presto
- Presto の presto-connector-redshift 設定ファイルで値を指定するために使用できる、redshift.properties 設定分類が追加されました。詳細については、Presto のドキュメントの「Redshift Connector」、および「アプリケーションの設定」を参照してください。
- EMRFS の Presto サポートが追加されました。これがデフォルト設定です。以前の Amazon EMR リリースでは PrestoS3FileSystem が使用されており、これが唯一のオプションでした。詳細については、「EMRFS と PrestoS3FileSystem の設定」を参照してください。
  
  注記
  Amazon EMR バージョン 5.12.0 を使用して Amazon S3 で基盤となるデータをクエリするときに、Presto エラーが発生することがあります。これは、Presto が emrfs-site.xml から設定分類値を取得できないためです。回避策として、usr/lib/presto/plugin/hive-hadoop2/ の下に emrfs サブディレクトリを作成し、既存の /usr/share/aws/emr/emrfs/conf/emrfs-site.xml ファイルへのシンボリックリンクを usr/lib/presto/plugin/hive-hadoop2/emrfs に作成します。次に presto-server プロセスを再起動します (sudo presto-server stop に続いて sudo presto-server start)。
Spark
- 「SPARK-22036: BigDecimal multiplication sometimes returns null」をバックポートしました。

既知の問題

MXNet には OpenCV ライブラリは含まれていません。
デフォルトでは R はクラスターノードにインストールされないため、カスタム AMI を使用して作成されたクラスターで SparkR を使用することはできません。

リリース 5.11.3

次のリリースノートには、Amazon EMR リリース 5.11.3 に関する情報が含まれています。5.11.2 からの変更が含まれています。

初回リリース日: 2019 年 7 月 18 日

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

TCP SACK サービス拒否の問題 (AWS-2019-005) など、重要な Linux カーネルセキュリティ更新を含めるように、Amazon EMR のデフォルトの Amazon Linux AMI を更新しました。

リリース 5.11.2

次のリリースノートには、Amazon EMR リリース 5.11.2 に関する情報が含まれています。5.11.1 からの変更が含まれています。

初回リリース日: 2018 年 8 月 29 日

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

このリリースでは、潜在的なセキュリティ脆弱性に対処しています。

リリース 5.11.1

次のリリースノートには、Amazon EMR バージョン 5.11.1 リリースに関する情報が含まれています。Amazon EMR 5.11.0 リリースからの変更が含まれています。

初回リリース日: 2018 年 1 月 22 日

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

投機的実行 (CVE-2017-5715、CVE-2017-5753、CVE-2017-5754) に関連する脆弱性に対処するために、Amazon EMR のデフォルトの Amazon Linux AMI の Amazon Linux カーネルを更新しました。詳細については、「https://aws.amazon.com/security/security-bulletins/AWS-2018-013/」を参照してください。

既知の問題

MXNet には OpenCV ライブラリは含まれていません。
Hive 2.3.2 では hive.compute.query.using.stats=true がデフォルト設定になっています。これにより、クエリではデータが直接ではなく既存の統計から取得されるため、混乱が生じる場合があります。たとえば、hive.compute.query.using.stats=true が設定されたテーブルの LOCATION に新しいファイルをアップロードした場合、テーブルに対して SELECT COUNT(*) クエリを実行すると、追加された行がカウントされずに、統計からカウントが返されます。

回避策として、ANALYZE TABLE コマンドを使用して新しい統計を収集するか、hive.compute.query.using.stats=false を設定します。詳細については、Apache Hive ドキュメントの「Statistics in Hive」を参照してください。

リリース 5.11.0

次のリリースノートには、Amazon EMR バージョン 5.11.0 リリースに関する情報が含まれています。Amazon EMR 5.10.0 リリースからの変更が含まれています。

アップグレード

このリリースでは、以下のアプリケーションおよびコンポーネントがアップグレードされ、以下のバージョンが含められています。

Hive 2.3.2
Spark 2.2.1
SDK for Java 1.11.238

新機能

Spark
- spark.decommissioning.timeout.threshold 設定が追加されました。スポットインスタンス使用時の Spark 廃棄の動作が向上します。詳細については、「ノード停止の動作設定」を参照してください。
- aws-sagemaker-spark-sdk コンポーネントが Spark に追加されました。Amazon SageMaker Spark および Spark の Amazon SageMaker との統合用の関連依存関係をインストールします。Amazon SageMaker Spark を使用して、Amazon SageMaker のステージを使用した Spark 機械学習 (ML) パイプラインを作成できます。詳細については、GitHub の「SageMaker Spark Readme」および「Amazon SageMaker デベロッパーガイド」の「Amazon SageMaker で Apache Spark を使用する」を参照してください。

既知の問題

MXNet には OpenCV ライブラリは含まれていません。
Hive 2.3.2 では hive.compute.query.using.stats=true がデフォルト設定になっています。これにより、クエリではデータが直接ではなく既存の統計から取得されるため、混乱が生じる場合があります。たとえば、hive.compute.query.using.stats=true が設定されたテーブルの LOCATION に新しいファイルをアップロードした場合、テーブルに対して SELECT COUNT(*) クエリを実行すると、追加された行がカウントされずに、統計からカウントが返されます。

回避策として、ANALYZE TABLE コマンドを使用して新しい統計を収集するか、hive.compute.query.using.stats=false を設定します。詳細については、Apache Hive ドキュメントの「Statistics in Hive」を参照してください。

リリース 5.10.0

次のリリースノートには、Amazon EMR バージョン 5.10.0 リリースに関する情報が含まれています。Amazon EMR 5.9.0 リリースからの変更が含まれています。

アップグレード

このリリースでは、以下のアプリケーションおよびコンポーネントがアップグレードされ、以下のバージョンが含められています。

AWS SDK for Java 1.11.221
Hive 2.3.1
Presto 0.187

新機能

Kerberos 認証のサポートが追加されました。詳しくは、「Amazon EMR 管理ガイド」の「Kerberos 認証を使用する」を参照してください。
Amazon S3 への EMRFS リクエストの IAM ロールのサポートを追加しました。詳細については、「Amazon EMR 管理ガイド」の「Amazon S3 への EMRFS リクエストの IAM ロールを設定する」を参照してください。
GPU ベースの P2 および P3 のインスタンスタイプのサポートが追加されました。詳細については、「Amazon EC2 P2 インスタンス」および「Amazon EC2 P3 インスタンス」を参照してください。これらのインスタンスタイプには、デフォルトで NVIDIA ドライバー 384.81 および CUDA ドライバー 9.0.176 がインストールされています。
Apache MXNet のサポートが追加されました。

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

Presto
- デフォルトの Hive メタストアとして AWS Glue Data Catalog が使用できるようになりました。詳細については、「AWS Glue Data Catalog での Presto の使用」を参照してください。
- 「地理空間機能」のサポートが追加されました。
- 結合で「ディスクに書き出す」ことができるようになりました。
- 「Redshift コネクター」のサポートが追加されました。
Spark
- 「SPARK-20640」をバックポートしました。これにより、spark.shuffle.registration.timeout プロパティおよび spark.shuffle.registration.maxAttempts プロパティを使用して、rpc タイムアウトや、シャッフル登録値の再試行回数が設定可能になりました。
- 「SPARK-21549」をバックポートしました。これにより、カスタムの OutputFormat を HDFS 以外の場所に書き出す際に発生するエラーが修正されます。
「Hadoop-13270」をバックポートしました。
Numpy、Scipy、Matplotlib の各ライブラリは、Amazon EMR の基本 AMI から削除されています。アプリケーションでこれらのライブラリが必要な場合、アプリケーションリポジトリで使用できるため、ブートストラップアクションで yum install を使用してすべてのノードにインストールすることができます。
Amazon EMR の基本 AMI にアプリケーションの RPM パッケージが含まれなくなったため、その RPM パッケージはクラスターノードに存在しなくなりました。カスタム AMI と Amazon EMR の基本 AMI で、Amazon S3 の RPM パッケージリポジトリを参照できるようになりました。
Amazon EC2 で 1 秒単位の請求が導入されたため、デフォルトの [スケールダウン動作] は [インスタンス時間で削除する] ではなく [タスク完了で削除する] になっています。詳細については、「クラスターのスケールダウンを設定する」を参照してください。

既知の問題

MXNet には OpenCV ライブラリは含まれていません。
Hive 2.3.1 では hive.compute.query.using.stats=true がデフォルト設定になっています。これにより、クエリではデータが直接ではなく既存の統計から取得されるため、混乱が生じる場合があります。たとえば、hive.compute.query.using.stats=true が設定されたテーブルの LOCATION に新しいファイルをアップロードした場合、テーブルに対して SELECT COUNT(*) クエリを実行すると、追加された行がカウントされずに、統計からカウントが返されます。

回避策として、ANALYZE TABLE コマンドを使用して新しい統計を収集するか、hive.compute.query.using.stats=false を設定します。詳細については、Apache Hive ドキュメントの「Statistics in Hive」を参照してください。

リリース 5.9.0

次のリリースノートには、Amazon EMR バージョン 5.9.0 リリースに関する情報が含まれています。Amazon EMR 5.8.0 リリースからの変更が含まれています。

リリース日: 2017 年 10 月 5 日

最新機能更新日: 2017 年 10 月 12 日

アップグレード

このリリースでは、以下のアプリケーションおよびコンポーネントがアップグレードされ、以下のバージョンが含められています。

AWS SDK for Java バージョン 1.11.183
Flink 1.3.2
Hue 4.0.1
Pig 0.17.0
Presto 0.184

新機能

Livy サポート (バージョン 0.4.0-incubating) を追加しました。詳細については、「Apache Livy」を参照してください。
Spark の Hue ノートブックのサポートを追加しました。
i3-シリーズ Amazon EC2 インスタンスのサポートを追加しました (2017 年 10 月 12 日)。

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

Spark
- 手動のサイズ変更または自動のスケーリングポリシーのリクエストによるノードの終了処理を、Spark がより適切に行う、新しい機能のセットを追加しました。詳細については、「ノード停止の動作設定」を参照してください。
- ブロック転送サービスの転送時の暗号化には 3DES に代わり SSL を使用します。これにより AES-NI で Amazon EC2 インスタンスタイプを使用する場合にパフォーマンスが向上します。
- SPARK-21494 を移植しました。
Zeppelin
- ZEPPELIN-2377 を移植しました。
HBase
- パッチ HBASE-18533 を追加しました。これにより、hbase-site 設定分類を使用して、HBase BucketCache 設定の値を追加できます。
Hue
- Hue の Hive クエリエディタでの AWS Glue Data Catalog のサポートを追加しました。
- デフォルトでは、Hue のスーパーユーザーは、Amazon EMR の IAM ロールがアクセスを許可されているすべてのファイルにアクセスできます。新しく作成されたユーザーには、Amazon S3 ファイルブラウザへのアクセス許可は自動的には付与されません。グループに対して filebrowser.s3_access アクセス許可を有効にする必要があります。
AWS Glue Data Catalog を使って作成された、基盤となる JSON データがアクセスできなくなる問題を解決しました。

既知の問題

すべてのアプリケーションがインストールされ、デフォルトの Amazon EBS ルートボリュームサイズが変更されていない場合、クラスターの起動は失敗します。回避策として、AWS CLI から aws emr create-cluster コマンドを使用し、より大きな --ebs-root-volume-size パラメータを指定します。
Hive 2.3.0 では hive.compute.query.using.stats=true がデフォルト設定になっています。これにより、クエリではデータが直接ではなく既存の統計から取得されるため、混乱が生じる場合があります。たとえば、hive.compute.query.using.stats=true が設定されたテーブルの LOCATION に新しいファイルをアップロードした場合、テーブルに対して SELECT COUNT(*) クエリを実行すると、追加された行がカウントされずに、統計からカウントが返されます。

回避策として、ANALYZE TABLE コマンドを使用して新しい統計を収集するか、hive.compute.query.using.stats=false を設定します。詳細については、Apache Hive ドキュメントの「Statistics in Hive」を参照してください。

リリース 5.8.2

次のリリースノートには、Amazon EMR リリース 5.8.2 に関する情報が含まれています。5.8.1 からの変更が含まれています。

初回リリース日: 2018 年 3 月 29 日

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

潜在的な脆弱性に対処するために、Amazon EMR のデフォルトの Amazon Linux AMI の Amazon Linux カーネルを更新しました。

リリース 5.8.1

次のリリースノートには、Amazon EMR バージョン 5.8.1 リリースに関する情報が含まれています。Amazon EMR 5.8.0 リリースからの変更が含まれています。

初回リリース日: 2018 年 1 月 22 日

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

投機的実行 (CVE-2017-5715、CVE-2017-5753、CVE-2017-5754) に関連する脆弱性に対処するために、Amazon EMR のデフォルトの Amazon Linux AMI の Amazon Linux カーネルを更新しました。詳細については、「https://aws.amazon.com/security/security-bulletins/AWS-2018-013/」を参照してください。

リリース 5.8.0

次のリリースノートには、Amazon EMR バージョン 5.8.0 リリースに関する情報が含まれています。Amazon EMR 5.7.0 リリースからの変更が含まれています。

初回リリース日: 2017 年 8 月 10 日

最新機能更新日: 2017 年 9 月 25 日

アップグレード

このリリースでは、以下のアプリケーションおよびコンポーネントがアップグレードされ、以下のバージョンが含められています。

AWS SDK 1.11.160
Flink 1.3.1
Hive 2.3.0。詳細については、Apache Hive サイトの「リリースノート」を参照してください。
Spark 2.2.0。詳細については、Apache Spark サイトの「リリースノート」を参照してください。

新機能

アプリケーション履歴の表示のサポートを追加しました (2017 年 9 月 25 日)。詳細については、「Amazon EMR 管理ガイド」の「アプリケーションの履歴を表示する」を参照してください。

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

AWS Glue Data Catalog との統合
- Hive および Spark SQL で AWS Glue Data Catalog を Hive メタデータストアとして使用する機能を追加しました。詳細については、Hive のメタストアとしての AWS Glue Data Catalog の使用および Spark SQL のメタストアとしての AWS Glue Data Catalog の使用を参照してください。
クラスター詳細の [Application history] を追加しました。これにより、YARN アプリケーションの履歴データや、Spark アプリケーションの追加の詳細を表示できます。詳細については、「Amazon EMR 管理ガイド」の「アプリケーションの履歴を表示する」を参照してください。
Oozie
- OOZIE-2748 をバックポートしました。
Hue
- HUE-5859 をバックポートしました。
HBase
- getMasterInitializedTime を使用して Java Management Extensions (JMX) 経由で HBase マスターサーバーの開始時間を公開するパッチを追加しました。
- クラスターの開始時間を改善するパッチを追加しました。

既知の問題

すべてのアプリケーションがインストールされ、デフォルトの Amazon EBS ルートボリュームサイズが変更されていない場合、クラスターの起動は失敗します。回避策として、AWS CLI から aws emr create-cluster コマンドを使用し、より大きな --ebs-root-volume-size パラメータを指定します。
Hive 2.3.0 では hive.compute.query.using.stats=true がデフォルト設定になっています。これにより、クエリではデータが直接ではなく既存の統計から取得されるため、混乱が生じる場合があります。たとえば、hive.compute.query.using.stats=true が設定されたテーブルの LOCATION に新しいファイルをアップロードした場合、テーブルに対して SELECT COUNT(*) クエリを実行すると、追加された行がカウントされずに、統計からカウントが返されます。

回避策として、ANALYZE TABLE コマンドを使用して新しい統計を収集するか、hive.compute.query.using.stats=false を設定します。詳細については、Apache Hive ドキュメントの「Statistics in Hive」を参照してください。
Spark - Spark を使用する場合、apppusher デーモンには、長時間実行されている Spark ジョブで数時間または数日後に発生する可能性があるファイルハンドラのリークの問題があります。この問題を修正するには、マスターノードに接続し、「sudo /etc/init.d/apppusher stop」と入力します。これにより、その apppusher デーモンが停止し、Amazon EMR がこのデーモンを自動的に再起動します。
アプリケーションの履歴
- Spark のデッドエグゼキュターの履歴データは利用できません。
- アプリケーション履歴は、セキュリティ設定を使用してインフライト暗号化を有効にするクラスターでは利用できません。

リリース 5.7.0

次のリリースノートには、Amazon EMR 5.7.0 に関する情報が含まれています。Amazon EMR 5.6.0 リリースからの変更が含まれています。

リリース日: 2017 年 7 月 13 日

アップグレード

Flink 1.3.0
Phoenix 4.11.0
Zeppelin 0.7.2

新機能

クラスターの作成時に、カスタム Amazon Linux AMI を指定する機能を追加しました。詳細については、「カスタム AMI の使用」を参照してください。

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

HBase
- HBase のリードレプリカクラスターを設定する機能を追加しました。詳細については、「リードレプリカクラスターの使用」を参照してください。
- 複数のバグ修正と機能強化
Presto – node.properties を設定する機能を追加しました。
YARN – container-log4j.properties を設定する機能を追加しました。
Sqoop – SQOOP-2880 をバックポートしました。Sqoop 一時ディレクトリを設定できる引数が導入されています。

リリース 5.6.0

次のリリースノートには、Amazon EMR 5.6.0 リリースに関する情報が含まれています。Amazon EMR 5.5.0 リリースからの変更が含まれています。

リリース日: 2017 年 6 月 5 日

アップグレード

Flink 1.2.1
HBase 1.3.1
Mahout 0.13.0。Amazon EMR バージョン 5.0 以降の Spark 2.x をサポートする最初のバージョンの Mahout です。
Spark 2.1.1

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

Presto
- セキュリティ設定を使って転送時の暗号化を有効にして、Presto ノード間で SSL/TLS を使った安全な通信を有効にする機能が追加されました。詳細については、「転送時のデータ暗号化」を参照してください。
- Presto 7661 を移植しました。これにより VERBOSE オプションを EXPLAIN ANALYZE ステートメントに追加し、クエリプランについての、より詳細なレポートと低レベルの統計を作成できます。

リリース 5.5.3

次のリリースノートには、Amazon EMR リリース 5.5.3 に関する情報が含まれています。5.5.2 からの変更が含まれています。

初回リリース日: 2018 年 8 月 29 日

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

このリリースでは、潜在的なセキュリティ脆弱性に対処しています。

リリース 5.5.2

次のリリースノートには、Amazon EMR リリース 5.5.2 に関する情報が含まれています。5.5.1 からの変更が含まれています。

初回リリース日: 2018 年 3 月 29 日

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

潜在的な脆弱性に対処するために、Amazon EMR のデフォルトの Amazon Linux AMI の Amazon Linux カーネルを更新しました。

リリース 5.5.1

次のリリースノートには、Amazon EMR 5.5.1 リリースに関する情報が含まれています。Amazon EMR 5.5.0 リリースからの変更が含まれています。

初回リリース日: 2018 年 1 月 22 日

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

投機的実行 (CVE-2017-5715、CVE-2017-5753、CVE-2017-5754) に関連する脆弱性に対処するために、Amazon EMR のデフォルトの Amazon Linux AMI の Amazon Linux カーネルを更新しました。詳細については、「https://aws.amazon.com/security/security-bulletins/AWS-2018-013/」を参照してください。

リリース 5.5.0

次のリリースノートには、Amazon EMR 5.5.0 リリースに関する情報が含まれています。Amazon EMR 5.4.0 リリースからの変更が含まれています。

リリース日: 2017 年 4 月 26 日

アップグレード

Hue 3.12
Presto 0.170
Zeppelin 0.7.1
ZooKeeper 3.4.10

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

Spark
- Spark のパッチ「(SPARK-20115) 外部シャッフルサービスが利用できない場合に、すべての失われたシャッフルブロックを再計算するように DAGScheduler を修正」を Spark バージョン 2.1.0 にバックポートしました。これはこのリリースに含まれています。
Flink
- Flink は Scala 2.11 で作成されるようになりました。プロジェクトで Scala API とライブラリを使用する場合は、Scala 2.11 を使用することをお勧めします。
- HADOOP_CONF_DIR と YARN_CONF_DIR のデフォルトが適切に設定されないため start-scala-shell.sh が機能しない問題に対応しました。さらに env.hadoop.conf.dir または env.yarn.conf.dir 設定分類の /etc/flink/conf/flink-conf.yaml と flink-conf を使って、これらの値を設定する機能を追加しました。
- EMR 固有の新しいコマンドで、flink-scala-shell のラッパーとなる start-scala-shell.sh を追加しました。start-scala-shell に代えて、このコマンドを使用することをお勧めします。新しいコマンドにより実行が簡素化されます。たとえば、flink-scala-shell -n 2 は、タスクの並行度 2 で、Flink Scala シェルを開始します。
- EMR 固有の新しいコマンドで、flink-yarn-session のラッパーとなる yarn-session.sh を追加しました。yarn-session に代えて、このコマンドを使用することをお勧めします。新しいコマンドにより実行が簡素化されます。たとえば、flink-yarn-session -d -n 2 は長時間稼働の Flink セッションを、デタッチ状態で、2 つのタスクマネージャを使って開始します。
- 「(FLINK-6125) Commons httpclient が Flink 1.2 でシェードされない」の問題に対応しました。
Presto
- LDAP 認証のサポートが追加されました。Amazon EMR の Presto で LDAP を使用する場合は、Presto コーディネーターの HTTPS アクセスを有効にする必要があります (config.properties の http-server.https.enabled=true)。設定の詳細については、Presto のドキュメントの「LDAP Authentication」を参照してください。
- SHOW GRANTS のサポートが追加されました。
Amazon EMR の基本 Linux AMI
- 現在、Amazon EMR リリースは Amazon Linux 2017.03 に基づいています。詳細については、「Amazon Linux AMI 2017.03 リリースノート」を参照してください。
- Python 2.6 は Amazon EMR の基本 Linux イメージから削除されました。Python 2.7 と 3.4 がデフォルトでインストールされます。必要な場合には Python 2.6 を手動でインストールできます。

リリース 5.4.0

次のリリースノートには、Amazon EMR 5.4.0 リリースに関する情報が含まれています。Amazon EMR 5.3.0 リリースからの変更が含まれています。

リリース日: 2017 年 3 月 8 日

アップグレード

このリリースでは、次のアップグレードを使用できます。

Flink 1.2.0 にアップグレードしました
Hbase 1.3.0　にアップグレード済み
Phoenix 4.9.0　にアップグレード済み

注記
古いバージョンの Amazon EMR から Amazon EMR バージョン 5.4.0 以降にアップグレードして、セカンダリインデックスを使用する場合、Apache Phoenix のドキュメントで説明されるようにローカルインデックスをアップグレードしてください。Amazon EMR は必要な設定を hbase-site 分類から削除しますが、インデックスはデータを再入力する必要があります。インデックスはオンラインとオフラインでアップグレードできます。オンラインのアップグレードがデフォルトです。これはバージョン4.8.0以降のPhoenixクライアントで初期する間にインデックスの値が再設定されることを意味します。オフラインアップグレードを指定するには、 phoenix.client.localIndexUpgrade 構成を phoenix-site 分類で　False　に設定してから、SSH　をマスターノードに設定して psql [zookeeper] -1を実行します。
Presto 0.166 にアップグレードしました
Zeppelin 0.7.0 にアップグレードしました

変更と機能強化

以下は、リリースラベル emr-5.4.0 の Amazon EMR リリースでの変更点です。

r4 インスタンスへのサポートを追加済み。「Amazon EC2 インスタンスタイプ」を参照してください。

リリース 5.3.1

次のリリースノートには、Amazon EMR 5.3.1 リリースに関する情報が含まれています。Amazon EMR 5.3.0 リリースからの変更が含まれています。

リリース日: 2017 年 2 月 7 日

Zeppelin パッチをバックポートして Amazon EMR のデフォルトの AMI を更新するための小さな変更。

リリース 5.3.0

次のリリースノートには、Amazon EMR 5.3.0 リリースに関する情報が含まれています。Amazon EMR 5.2.1 リリースからの変更が含まれています。

リリース日: 2017 年 1 月 26 日

アップグレード

このリリースでは、次のアップグレードを使用できます。

Hive 2.1.1 にアップグレードしました
Hue 3.11.0 にアップグレードしました
Spark 2.1.0 にアップグレードしました
Oozie 4.3.0 にアップグレードしました
Flink 1.1.4 にアップグレードしました

変更と機能強化

以下は、リリースラベル emr-5.3.0 の Amazon EMR リリースでの変更点です。

interpreters_shown_on_wheel ファイルでの順序にかかわらず、ノートブックの選択ホイールで最初に表示するインタープリタを指定する hue.ini 設定を使用できるようにするパッチを Hue に追加しました。
Hive の hive-parquet-logging ファイルで値を設定するために使用できる、parquet-logging.properties 設定分類を追加しました。

リリース 5.2.2

次のリリースノートには、Amazon EMR 5.2.2 リリースに関する情報が含まれています。Amazon EMR 5.2.1 リリースからの変更が含まれています。

リリース日: 2017 年 5 月 2 日

以前のリリースから解決された既知の問題

SPARK-194459 をしました。char/varchar の列を持つ ORC テーブルからの読み取りが失敗する問題に対応しました。

リリース 5.2.1

次のリリースノートには、Amazon EMR 5.2.1 リリースに関する情報が含まれています。Amazon EMR 5.2.0 リリースからの変更が含まれています。

リリース日: 2016 年 12 月 29 日

アップグレード

このリリースでは、次のアップグレードを使用できます。

Presto を 0.157.1 にアップグレードしました。詳細については、Presto のドキュメントの「Presto リリースノート」を参照してください。
ZooKeeper を 3.4.9 にアップグレードしました。詳細については、Apache ZooKeeper のドキュメントの「ZooKeeper リリースノート」を参照してください。

変更と機能強化

以下は、リリースラベル emr-5.2.1 の Amazon EMR リリースでの変更点です。

5.0.0、5.0.3、5.2.0 を除く Amazon EMR バージョン 4.8.3 以降の Amazon EC2 の m4.16xlarge インスタンスタイプのサポートが追加されました。
現在、Amazon EMR リリースは Amazon Linux 2016.09 に基づいています。詳細については、「https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/」を参照してください。
これで、Flink および YARN 設定パスの場所はデフォルトで /etc/default/flink に設定されましたので、Flink のジョブを起動するために FLINK_CONF_DIR または HADOOP_CONF_DIR ドライバースクリプトを実行するときに、環境変数 flink および yarn-session.sh を設定する必要はありません。
FlinkKinesisConsumer クラスのサポートを追加しました。

以前のリリースから解決された既知の問題

ReplicationMonitor のスレッドが大きなクラスターで同じファイルのレプリケーションと削除間の競合のために長時間スタックが生じる Hadoop の問題を修正しました。
ジョブのステータスが正常に更新されていないときに ControlledJob#toString が null ポインタ例外 (NPE) で失敗していた問題を修正しました。

リリース 5.2.0

次のリリースノートには、Amazon EMR 5.2.0 リリースに関する情報が含まれています。Amazon EMR 5.1.0 リリースからの変更が含まれています。

リリース日: 2016 年 11 月 21 日

変更と機能強化

このリリースでは、次の変更と機能強化を使用できます。

HBase の Amazon S3 ストレージモードを追加しました。
HBase ルートディレクトリの Amazon S3 ロケーションを指定できます。Amazon S3 の HBase の詳細については、「Amazon S3 の HBase」を参照してください。

アップグレード

このリリースでは、次のアップグレードを使用できます。

Spark 2.0.2 にアップグレードしました

以前のリリースから解決された既知の問題

EBS のみのインスタンスタイプで 2 TB に制約されていた /mnt に関する問題を修正。
通常の log4j-configured .log ファイルではなく、対応する .out ファイルに出力され、1 時間ごとにローテーションされていた、インスタンスコントローラーおよび logpusher ログに関する問題を修正。.out ファイルはローテーションしないため、最終的には /emr パーティションがいっぱいになります。この問題は、ハードウェア仮想マシン (HVM) のインスタンスタイプにのみ影響します。

リリース 5.1.0

次のリリースノートには、Amazon EMR 5.1.0 リリースに関する情報が含まれています。Amazon EMR 5.0.0 リリースからの変更が含まれています。

リリース日: 2016 年 11 月 3 日

変更と機能強化

このリリースでは、次の変更と機能強化を使用できます。

Flink 1.1.3 のサポートを追加。
Presto が、Hue のノートブックセクションでオプションとして追加。

アップグレード

このリリースでは、次のアップグレードを使用できます。

HBase 1.2.3 にアップグレードしました
Zeppelin 0.6.2 にアップグレードしました

以前のリリースから解決された既知の問題

以前の Amazon EMR 4.x バージョンと同じく、ORC ファイルがある Amazon S3 の Tez クエリが実行されない問題を修正しました。

リリース 5.0.3

次のリリースノートには、Amazon EMR 5.0.3 リリースに関する情報が含まれています。Amazon EMR 5.0.0 リリースからの変更が含まれています。

リリース日: 2016 年 10 月 24 日

アップグレード

このリリースでは、次のアップグレードを使用できます。

Hadoop 2.7.3 にアップグレードしました
Presto 0.152.3 にアップグレードします。このアップグレードには Presto ウェブインターフェイスのサポートが含まれています。Presto コーディネーターの Presto ウェブインターフェイスには、ポート 8889 を使用してアクセスできます。Presto ウェブインターフェイスの詳細については、Presto のドキュメントの「ウェブインターフェイス」を参照してください。
Spark 2.0.1 にアップグレードしました
現在、Amazon EMR リリースは Amazon Linux 2016.09 に基づいています。詳細については、「https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/」を参照してください。

リリース 5.0.0

リリース日: 2016 年 7 月 27 日

アップグレード

このリリースでは、次のアップグレードを使用できます。

Hive 2.1 にアップグレードしました
Presto 0.150 にアップグレードしました
Spark 2.0 にアップグレードしました
Hue 3.10.0 にアップグレードしました
Pig 0.16.0 にアップグレードしました
Tez 0.8.4 にアップグレードしました
Zeppelin 0.6.1 にアップグレードしました

変更と機能強化

以下は、リリースラベル emr-5.0.0 以降の Amazon EMR リリースでの変更点です。

Amazon EMR は Hive (バージョン 2.1)、Pig (バージョン 0.16.0) の最新のオープンソースバージョンをサポートします。以前に Amazon EMR で Hive または Pig を使用している場合、このことはいくつかのユースケースに影響を与える可能性があります。詳細については、「Hive」および「Pig」を参照してください。
現在の Hive および Pig のデフォルト実行エンジンは Tez です。これを変更するには、hive-site および pig-properties のそれぞれの設定分類の適切な値を編集します。
サービスが原因を識別できる場合にステップ障害の根本原因を表示できるようにするステップ、デバッグ機能が追加されました。詳細については、「Amazon EMR 管理ガイド」の「デバッグの詳細ステップ」を参照してください。

アプリケーションは以前「-Sandbox」で終了しましたが、そのサフィックスはもうありません。たとえば、これらのアプリケーションを使ってクラスターを起動するスクリプトを使用している場合、これによってオートメーションが中断する可能性があります。次の表は、Amazon EMR 4.7.2 と Amazon EMR 5.0.0 のアプリケーション名を示しています。

アプリケーション名変更
Amazon EMR 4.7.2	Amazon EMR 5.0.0
Oozie-Sandbox	Oozie
Presto-Sandbox	Presto
Sqoop-Sandbox	Sqoop
Zeppelin-Sandbox	Zeppelin
ZooKeeper-Sandbox	ZooKeeper

Spark は現在 Scala 2.11 向けにコンパイルされています。
現在のデフォルト JVM は Java 8 です。すべてのアプリケーションは Java 8 ランタイムを使用して動作します。アプリケーションのバイトコードターゲットには変更はありません。ほとんどのアプリケーションは、引き続き Java 7 を対象としています。
Zeppelin には、認証機能が組み込まれています。詳細については、「Zeppelin」を参照してください。
セキュリティ設定のサポートを追加しました。これにより、暗号化オプションをより簡単に作成、適用できます。詳細については、「データの暗号化」を参照してください。

リリース 4.9.5

次のリリースノートには、Amazon EMR リリース 4.9.5 に関する情報が含まれています。4.9.4 からの変更が含まれています。

初回リリース日: 2018 年 8 月 29 日

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

HBase
- このリリースでは、潜在的なセキュリティ脆弱性に対処しています。

リリース 4.9.4

次のリリースノートには、Amazon EMR リリース 4.9.4 に関する情報が含まれています。4.9.3 からの変更が含まれています。

初回リリース日: 2018 年 3 月 29 日

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

潜在的な脆弱性に対処するために、Amazon EMR のデフォルトの Amazon Linux AMI の Amazon Linux カーネルを更新しました。

リリース 4.9.3

次のリリースノートには、Amazon EMR 4.9.3 リリースに関する情報が含まれています。Amazon EMR 4.9.2 リリースからの変更が含まれています。

初回リリース日: 2018 年 1 月 22 日

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

投機的実行 (CVE-2017-5715、CVE-2017-5753、CVE-2017-5754) に関連する脆弱性に対処するために、Amazon EMR のデフォルトの Amazon Linux AMI の Amazon Linux カーネルを更新しました。詳細については、「https://aws.amazon.com/security/security-bulletins/AWS-2018-013/」を参照してください。

リリース 4.9.2

次のリリースノートには、Amazon EMR 4.9.2 リリースに関する情報が含まれています。Amazon EMR 4.9.1 リリースからの変更が含まれています。

リリース日: 2017 年 7 月 13 日

このリリースでは小さな変更、バグ修正、および機能強化が行われました。

リリース 4.9.1

次のリリースノートには、Amazon EMR 4.9.1 リリースに関する情報が含まれています。Amazon EMR 4.8.4 リリースからの変更が含まれています。

リリース日: 2017 年 4 月 10 日

以前のリリースから解決された既知の問題

HIVE-9976 および HIVE-10106 を移植しました。
多数のノード (2,000 以上) やコンテナ (5,000 以上) によって、"Exception in thread 'main' java.lang.OutOfMemoryError" などのメモリエラーが発生することがある、YARN の問題を修正しました。

変更と機能強化

以下は、リリースラベル emr-4.9.1 の Amazon EMR リリースでの変更点です。

現在、Amazon EMR リリースは Amazon Linux 2017.03 に基づいています。詳細については、「https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/」を参照してください。
Python 2.6 は Amazon EMR の基本 Linux イメージから削除されました。必要な場合には Python 2.6 を手動でインストールできます。

リリース 4.8.4

次のリリースノートには、Amazon EMR 4.8.4 リリースに関する情報が含まれています。Amazon EMR 4.8.3 リリースからの変更が含まれています。

リリース日: 2017 年 2 月 7 日

このリリースでは小さな変更、バグ修正、および機能強化が行われました。

リリース 4.8.3

次のリリースノートには、Amazon EMR 4.8.3 リリースに関する情報が含まれています。Amazon EMR 4.8.2 リリースからの変更が含まれています。

リリース日: 2016 年 12 月 29 日

アップグレード

このリリースでは、次のアップグレードを使用できます。

Presto を 0.157.1 にアップグレードしました。詳細については、Presto のドキュメントの「Presto リリースノート」を参照してください。
Spark を 1.6.3 にアップグレードしました。詳細については、Apache Spark のドキュメントの「Spark リリースノート」を参照してください。
ZooKeeper を 3.4.9 にアップグレードしました。詳細については、Apache ZooKeeper のドキュメントの「ZooKeeper リリースノート」を参照してください。

変更と機能強化

以下は、リリースラベル emr-4.8.3 の Amazon EMR リリースでの変更点です。

5.0.0、5.0.3、5.2.0 を除く Amazon EMR バージョン 4.8.3 以降の Amazon EC2 の m4.16xlarge インスタンスタイプのサポートが追加されました。
現在、Amazon EMR リリースは Amazon Linux 2016.09 に基づいています。詳細については、「https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/」を参照してください。

以前のリリースから解決された既知の問題

ReplicationMonitor のスレッドが大きなクラスターで同じファイルのレプリケーションと削除間の競合のために長時間スタックが生じる Hadoop の問題を修正しました。
ジョブのステータスが正常に更新されていないときに ControlledJob#toString が null ポインタ例外 (NPE) で失敗していた問題を修正しました。

リリース 4.8.2

次のリリースノートには、Amazon EMR 4.8.2 リリースに関する情報が含まれています。Amazon EMR 4.8.0 リリースからの変更が含まれています。

リリース日: 2016 年 10 月 24 日

アップグレード

このリリースでは、次のアップグレードを使用できます。

Hadoop 2.7.3 にアップグレードしました
Presto 0.152.3 にアップグレードします。このアップグレードには Presto ウェブインターフェイスのサポートが含まれています。Presto コーディネーターの Presto ウェブインターフェイスには、ポート 8889 を使用してアクセスできます。Presto ウェブインターフェイスの詳細については、Presto のドキュメントの「ウェブインターフェイス」を参照してください。
現在、Amazon EMR リリースは Amazon Linux 2016.09 に基づいています。詳細については、「https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/」を参照してください。

リリース 4.8.0

リリース日: 2016 年 9 月 7 日

アップグレード

このリリースでは、次のアップグレードを使用できます。

HBase 1.2.2 にアップグレードしました
Presto-Sandbox 0.151 にアップグレードしました
Tez 0.8.4 にアップグレードしました
Zeppelin-Sandbox 0.6.1 にアップグレードしました

変更と機能強化

以下は、リリースラベル emr-4.8.0 の Amazon EMR リリースでの変更点です。

インスタンスが削除されたため、存在していないコンテナを ApplicationMaster がクリーンアップしようとする YARN の問題を修正しました。
Oozie の例の Hive2 アクションの hive-server2 URL を修正しました。
さらに多くの Presto カタログのサポートを追加しました。
次のパッチを移植しました: HIVE-8948、HIVE-12679、HIVE-13405、PHOENIX-3116、HADOOP-12689
セキュリティ設定のサポートを追加しました。これにより、暗号化オプションをより簡単に作成、適用できます。詳細については、「データの暗号化」を参照してください。

リリース 4.7.2

以下のリリースノートには、Amazon EMR 4.7.2 に関する情報が含まれています。

リリース日: 2016 年 7 月 15 日

機能

このリリースでは、次の機能を使用できます。

Mahout 0.12.2 にアップグレードしました
Presto 0.148 にアップグレードしました
Spark 1.6.2 にアップグレードしました
パラメータとして URI を使用して EMRFS で使用する AWSCredentialsProvider を作成できるようになりました。詳細については、「EMRFS 用に AWSCredentialsProvider を作成する」を参照してください。
EMRFS では、ユーザーが emrfs-site.xml で fs.s3.consistent.dynamodb.endpoint プロパティを使用して、整合性のあるビューのメタデータのカスタム DynamoDB エンドポイントを設定できるようになりました。
/usr/bin に spark-example というスクリプトを追加しました。これにより /usr/lib/spark/spark/bin/run-example をラップし、例を直接実行できます。たとえば、Spark ディストリビューションに付属する SparkPi の例を実行するには、API のステップとしてコマンドラインから spark-example SparkPi 100 を実行するか、command-runner.jar を使用できます。

以前のリリースから解決された既知の問題

Oozie で、Spark もインストールされたときに spark-assembly.jar が正しい場所にないために、Oozie で Spark アプリケーションを起動できなくなる問題を解決しました。
YARN コンテナで Spark Log4j ベースのログインに関する問題を修正しました。

リリース 4.7.1

リリース日: 2016 年 6 月 10 日

以前のリリースから解決された既知の問題

プライベートサブネットを持つ VPC で起動されたクラスターの起動時間が長くなる問題を修正しました。このバグの影響があったのは、Amazon EMR 4.7.0 リリースで起動されたクラスターのみです。
Amazon EMR 4.7.0 リリースで起動されたクラスターに対する Amazon EMR でのファイルのリスト処理が不適切であった問題を修正しました。

リリース 4.7.0

重要

Amazon EMR 4.7.0 は廃止されています。代わりに Amazon EMR 4.7.1 以降を使用してください。

リリース日: 2016 年 6 月 2 日

機能

このリリースでは、次の機能を使用できます。

Apache Phoenix 4.7.0 を追加しました
Apache Tez 0.8.3 を追加しました
HBase 1.2.1 にアップグレードしました
Mahout 0.12.0 にアップグレードしました
Presto 0.147 にアップグレードしました
AWS SDK for Java が 1.10.75 にアップグレード
ユーザーがローカルモードで Pig を実行できるようにするため、最終的なフラグが mapreduce.cluster.local.dir の mapred-site.xml プロパティから削除されました。

Amazon Redshift JDBC ドライバーがクラスターで利用可能

Amazon Redshift JDBC ドライバーが /usr/share/aws/redshift/jdbc に含まれました。/usr/share/aws/redshift/jdbc/RedshiftJDBC41.jar は JDBC 4.1 互換の Amazon Redshift ドライバー、/usr/share/aws/redshift/jdbc/RedshiftJDBC4.jar は JDBC 4.0 互換の Amazon Redshift ドライバーです。詳細については、「Amazon Redshift 管理ガイド」の「JDBC 接続の設定」を参照してください。

Java 8

Presto を除き、OpenJDK 1.7 はすべてのアプリケーションに使用されるデフォルトの JDK です。ただし、OpenJDK 1.7 と 1.8 の両方がインストールされています。アプリケーションの JAVA_HOME を設定する方法については、「Java 8 を使用したアプリケーションの設定」を参照してください。

以前のリリースから解決された既知の問題

emr-4.6.0 で Amazon EMR 用のスループット最適化 HDD (st1) EBS ボリュームで著しくパフォーマンスに影響を与えていたカーネルの問題を修正しました。
アプリケーションとして Hadoop を選択せずに HDFS 暗号化ゾーンを指定した場合にクラスターが失敗する問題を修正しました。
デフォルトの HDFS 書き込みポリシーを RoundRobin から AvailableSpaceVolumeChoosingPolicy に変更しました。一部のボリュームは RoundRobin 設定で正しく利用されず、それによってコアノードが失敗し、HDFS の信頼性が低くなりました。
整合性のあるビューを実現するためにデフォルトの DynamoDB メタデータテーブルを作成するときに、例外が発生する原因となっていた EMRFS CLI に関する問題を修正しました。
マルチパートの名前の変更およびコピーオペレーション中に発生する可能性のあった、EMRFS のデッドロックの問題を修正しました。
CopyPart のサイズがデフォルトで 5 MB になる EMRFS の問題を修正しました。現在では、デフォルト値は 128 MB で適切に設定されます。
サービスを停止できなくなる可能性のある、Zeppelin upstart 設定の問題を修正しました。
s3a:// がそれぞれのクラスパスで適切にロードされていないために、/usr/lib/hadoop/hadoop-aws.jar URI スキームを使用できなくなる Spark および Zeppelin の問題を修正しました。
HUE-2484 を移植しました。
HBase ブラウザサンプルでの問題を修正するため、Hue 3.9.0 (JIRA が存在しない) から commit を移植しました。
HIVE-9073 を移植しました。

リリース 4.6.0

リリース日: 2016 年 4 月 21 日

機能

このリリースでは、次の機能を使用できます。

HBase 1.2.0 を追加しました
Zookeeper-Sandbox 3.4.8 を追加しました
Presto-Sandbox 0.143 にアップグレードしました
現在、Amazon EMR リリースは Amazon Linux 2016.03.0 に基づいています。詳細については、「https://aws.amazon.com/amazon-linux-ami/2016.03-release-notes/」を参照してください。

スループット最適化 HDD (st1) EBS ボリュームタイプに影響を及ぼす問題

Linux カーネルバージョン 4.2 以降の問題は、EMR 用のスループット最適化 HDD (st1) EBS ボリュームのパフォーマンスに大きな影響を及ぼします。このリリース (emr-4.6.0) ではカーネルバージョン 4.4.5 を使用するため、影響を受けます。したがって、st1 EBS ボリュームを使用する場合、emr-4.6.0 を使用しないことをお勧めします。emr-4.5.0 以前の Amazon EMR リリースと st1 であれば、影響を受けずに使用できます。これに加えて、将来のリリースで修正が提供されます。

Python のデフォルト値

現在、Python 3.4 がデフォルトでインストールされますが、Python 2.7 はシステムデフォルトのままです。いずれかのブートストラップアクションを使用してシステムデフォルトとして Python 3.4 を設定できます。PySpark で使用される Python のバージョンに影響を与えるため、設定 API を使用して /usr/bin/python3.4 分類で PYSPARK_PYTHON のエクスポート先を spark-env に設定できます。

Java 8

以前のリリースから解決された既知の問題

アプリケーションのプロビジョニングが、生成されたパスワードが原因でランダムに失敗する問題を修正しました。
以前は、mysqld がすべてのノードにインストールされました。現在では、選択されたアプリケーションにコンポーネントとして mysql-server が含まれている場合のみ、マスターインスタンスのみにインストールされます。現在、HCatalog、Hive、Hue、Presto-Sandbox、および Sqoop-Sandbox の各アプリケーションに、mysql-server コンポーネントが含まれています。
yarn.scheduler.maximum-allocation-vcores をデフォルトの 32 から 80 に変更しました。これにより、コアインスタンスタイプが、YARN vcores が 32 より高く設定されているいくつかのラージインスタンスタイプのいずれかであるクラスターで、maximizeResourceAllocation オプションを使用中に Spark で主に発生する、emr-4.4.0 での問題が修正されました。この問題の影響を受けていたのは、c4.8xlarge、cc2.8xlarge、hs1.8xlarge、i2.8xlarge、m2.4xlarge、r3.8xlarge、d2.8xlarge、または m4.10xlarge です。
現在では s3-dist-cp はすべての Amazon S3 候補に EMRFS を使用し、一時 HDFS ディレクトリにはステージングしません。
クライアント側の暗号化のマルチパートアップロードの例外処理に関する問題を修正しました。
ユーザーが Amazon S3 ストレージクラスを変更できるようにするオプションを追加しました。デフォルトでは、この設定は STANDARD です。emrfs-site 設定の分類設定は fs.s3.storageClass で、指定できる値は STANDARD、STANDARD_IA、REDUCED_REDUNDANCY です。ストレージクラスの詳細については、「Amazon Simple Storage Service ユーザーガイド」の「ストレージクラス」を参照してください。

リリース 4.5.0

リリース日: 2016 年 4 月 4 日

機能

このリリースでは、次の機能を使用できます。

Spark 1.6.1 にアップグレードしました
Hadoop 2.7.2 にアップグレードしました
Presto 0.140 にアップグレードしました
Amazon S3 サーバー側の暗号化のための AWS KMS のサポートを追加しました。

以前のリリースから解決された既知の問題

ノードが再起動された後に MySQL および Apache サーバーが起動しない問題を修正しました。
Amazon S3 に保存されているパーティション分割されていないテーブルで IMPORT が正しく機能しない問題を修正しました。
Hive テーブルに書き込むときに、ステージングディレクトリが /mnt/tmp ではなく /tmp であることが要求される Presto の問題を修正しました。

リリース 4.4.0

リリース日: 2016 年 3 月 14 日

機能

このリリースでは、次の機能を使用できます。

HCatalog 1.0.0 を追加しました
Sqoop-Sandbox 1.4.6 を追加しました
Presto 0.136 にアップグレードしました
Zeppelin 0.5.6 にアップグレードしました
Mahout 0.11.1 にアップグレードしました
デフォルトで dynamicResourceAllocation を有効にしました。
リリースのすべての設定分類の表を追加しました。詳細については、「アプリケーションの設定」の設定分類の表を参照してください。

以前のリリースから解決された既知の問題

maximizeResourceAllocation 設定で YARN ApplicationMaster デーモンに十分なメモリが予約されない問題を修正しました。
カスタム DNS で発生した問題を修正しました。resolve.conf のエントリが、提供されたカスタムエントリよりも前に指定されている場合、そのカスタムエントリは解決されません。この動作は、デフォルトの VPC ネームサーバーが resolve.conf のトップエントリとして挿入された VPC のクラスターによって影響を受けました。
デフォルトの Python がバージョン 2.7 に移行した場合に、そのバージョンに対して boto がインストールされなかった問題を修正しました。
YARN コンテナと Spark アプリケーションが独自の Ganglia ラウンドロビンデータベース (rrd) ファイルを生成し、それによりインスタンスにアタッチされた最初のディスクがいっぱいになる問題を修正しました。この修正によって、YARN コンテナレベルのメトリクスが無効になり、Spark アプリケーションレベルのメトリクスが無効になりました。
ログプッシャーですべての空のログフォルダーが削除される問題を修正しました。この問題により、ログプッシャーは user の空の /var/log/hive フォルダを削除したため、Hive CLI はログを記録できませんでした。
パーティション分割に影響し、インポート中にエラーを発生させた、Hive のインポートに影響を与える問題を修正しました。
EMRFS と s3-dist-cp が、ピリオドを含むバケット名を適切に処理しなかった問題を修正しました。
EMRFS の動作を変更し、バージョニングが有効なバケットで、_$folder$ マーカーファイルが連続して作成されないようにしました。これにより、バージョニングが有効なバケットでパフォーマンスが向上する可能性があります。
クライアント側の暗号化が有効になっている場合を除き、インストラクションファイルを使用しないよう EMRFS の動作を変更しました。クライアント側の暗号化を使用中にインストラクションファイルを削除する場合は、emrfs-site.xml プロパティの fs.s3.cse.cryptoStorageMode.deleteInstructionFiles.enabled を true に設定できます。
YARN ログの集計を変更し、集計先でログを 2 日間保持するようにしました。デフォルトの送信先はクラスターの HDFS ストレージです。この期間を変更する場合は、クラスターの作成時に yarn.log-aggregation.retain-seconds 設定分類を使用して yarn-site の値を変更します。これまでどおり、クラスターの作成時は、log-uri パラメータを使用して、Amazon S3 にアプリケーションログを保存できます。

適用されたパッチ

オープンソースのプロジェクトから、次のパッチがこのリリースで追加されました。

リリース 4.3.0

リリース日: 2016 年 1 月 19 日

機能

このリリースでは、次の機能を使用できます。

Hadoop 2.7.1 にアップグレードしました
Spark 1.6.0 にアップグレードしました
Ganglia を 3.7.2 にアップグレードしました
Presto を 0.130 にアップグレードしました

Amazon EMR を true に設定すると、spark.dynamicAllocation.enabled にいくつかの変更が加えられていました。デフォルトでは false です。true に設定すると、maximizeResourceAllocation 設定で定義されているデフォルト設定に影響を与えます。

spark.dynamicAllocation.enabled を true に設定した場合、spark.executor.instances は maximizeResourceAllocation によって設定されません。
spark.driver.memory 設定は、spark.executors.memory 設定と同様に、クラスター内のインスタンスタイプに基づいて定義されます。ただし、Spark ドライバーアプリケーションは、マスターインスタンスまたはいずれかのコアインスタンスで（たとえば、YARN クライアントモードとクラスターモードのそれぞれで）実行されるため、spark.driver.memory 設定は、これらの 2 つのインスタンスグループ間で、小さい方のインスタンスのインスタンスタイプに基づいて定義されます。
spark.default.parallelism 設定は、YARN コンテナに使用可能な CPU コアの数の 2 倍に定義されます。以前のリリースでは、半分の値に定義されていました。
Spark YARN プロセス用に予約されるメモリオーバーヘッドの計算精度が上がったため、Spark に使用可能なメモリの合計量（spark.executor.memory）がわずかに増えました。

以前のリリースから解決された既知の問題

現在、YARN ログの集計はデフォルトで有効になります。
YARN ログの集計が有効な場合に、クラスターの Amazon S3 ログバケットにログがプッシュされない問題を修正しました。
YARN コンテナサイズは、すべてのノードタイプで新たに最低 32 になりました。
大規模なクラスターのマスターノードで過剰なディスク I/O を発生させる Ganglia の問題を修正しました。
クラスターのシャットダウン時に Amazon S3 にアプリケーションログがプッシュされない問題を修正しました。
特定のコマンドを失敗させる EMRFS CLI の問題を修正しました。
基盤となる SparkContext に依存関係がロードされなくなる Zeppelin の問題を修正しました。
インスタンスの追加を試みるサイズ変更の発行によって発生する問題を修正しました。
CREATE TABLE AS SELECT が Amazon S3 への過剰なリスト呼び出しを行う Hive の問題を修正しました。
Hue、Oozie、および Ganglia がインストールされていると、大規模なクラスターが適切にプロビジョニングされない問題を修正しました。
エラーで失敗した場合でもゼロ終了コードを返す s3-dist-cp の問題を修正しました。

適用されたパッチ

オープンソースのプロジェクトから、次のパッチがこのリリースで追加されました。

リリース 4.2.0

リリース日: 2015 年 11 月 18 日

機能

このリリースでは、次の機能を使用できます。

Ganglia のサポートを追加しました
Spark 1.5.2 にアップグレードしました
Presto 0.125 にアップグレードしました
Oozie を 4.2.0 にアップグレードしました
Zeppelin を 0.5.5 にアップグレードしました
AWS SDK for Java が 1.10.27 にアップグレード

以前のリリースから解決された既知の問題

デフォルトのメタデータテーブル名を使用しない EMRFS CLI の問題を修正しました。
Amazon S3 で ORC-backed テーブルを使用するときに発生した問題を修正しました。
Spark 設定で Python バージョンが一致しない問題を修正しました。
VPC のクラスターでの DNS の問題により、YARN ノードのステータスが報告されない問題を修正しました。
YARN がノードを廃棄することが原因でアプリケーションがハングしたり、新しいアプリケーションを予定できなくなったりする問題を修正しました。
クラスターが TIMED_OUT_STARTING というステータスで終了するときに発生する問題を修正しました。
EMRFS Scala 依存関係を他のビルドに含める場合に発生する問題を修正しました。Scala 依存関係が削除されました。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

CVE-2021-44228 を軽減するためのアプローチ

アプリケーションの設定

Amazon EMR リリースノートのアーカイブ

リリース 6.14.0

新機能

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

リリース 6.13.0

新機能

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

リリース 6.12.0

新機能

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

リリース 6.11.1

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

リリース 6.11.0

新機能

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

注記

リリース 6.10.0

新機能

既知の問題点

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

注記

リリース 6.9.0

新機能

既知の問題点

変更、拡張、解決した問題

注記

リリース 6.8.0

新機能

既知の問題点

変更、拡張、解決した問題

注記

既知の問題点

リリース 6.7.0

新機能

既知の問題点

リリース 6.6.0

新機能

変更、拡張、解決した問題

既知の問題点

リリース 5.35.0

新機能

既知の問題

リリース 5.34.0

新機能

変更、拡張、解決した問題

既知の問題点

リリース 6.5.0

新機能

変更、拡張、解決した問題

既知の問題点

リリース 6.4.0

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

新機能

Hudi の同時実行制御

Hudi モニタリング: Hudi メトリクスをレポートするための Amazon CloudWatch の統合

Amazon EMR Hudi の設定のサポートと改善

Hudi Caveats

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

既知の問題

リリース 5.32.0

アップグレード

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

新機能

既知の問題

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

重要

リリース 6.2.0

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

新機能

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

既知の問題

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

重要

重要

注記

リリース 5.31.0

アップグレード

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

新機能

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