Amazon EMR のよくある質問

Q: Amazon EMR とは何ですか?

Amazon EMR とは、Apache Spark、Apache Hive、Presto などのオープンソースフレームワークを使用して、データ処理、相互分析、機械学習を行なう業界をリードするクラウドビッグデータプラットフォームです。EMR では、従来のオンプレミスソリューションの半分以下のコスト、標準的な Apache Spark の 1.7 倍以上の速さで、ペタバイト規模の分析を実行できます。

Q: Amazon EMR を使用する利点は何ですか?

Amazon EMR によって、コンピューティング性能やオープンソースアプリケーションを管理する心配なく、データ変換と分析に重点を置くことができ、お金を節約することができます。EMR を使用すると、Amazon EC2 で必要なだけの容量を即座にプロビジョニングし、変化するコンピューティング需要を管理するスケーリングルールを設定できます。CloudWatch アラートを設定して、インフラストラクチャの変更の通知を受け取り、すばやく対応することができます。Kubernetes を使用する場合、 EMR を使用して、ワークロードを Amazon EKS クラスターに送信することもできます。EC2 または EKS のどちらを使用しても、分析速度を上げ、時間とお金の両方を節約する EMR の最適化ランタイムからメリットを得ます。

Q: Amazon EMR をデプロイして管理する方法を教えてください。

Amazon EC2、Amazon Elastic Kubernetes Service (EKS)、またはオンプレミス AWS Outposts を使用して、EMR にワークロードをデプロイできます。EMR コンソール、API、SDK または CLI を使ってワークロードを実行して管理し、Amazon Managed Workflows for Apache Airflow (MWAA) または AWS Step Functions を使用して調整することができます。インタラクティブな体験をするには、EMR Studio または SageMaker Studio を使用できます。

Q: Amazon EMR の使用を開始する方法を教えてください。

Q: コードサンプルはどこにありますか?

これらの記事とチュートリアルにあるサンプルコードを確認してください。EMR Studio を使用する場合、ノートブックの例一式を使用して、機能を確認できます。

Q: データ処理アプリケーションの開発方法について教えてください。

Amazon EMR Studio にある R、Python、Scala、PySpark で記述されたデータエンジニアリングおよびデータサイエンスアプリケーションを簡単に開発、視覚化、デバッグできます。また、例えば、Eclipse、Spyder、PyCharm、または RStudio を使用して、デスクトップでデータ処理ジョブを開発し、Amazon EMR で実行することもできます。さらに、新しいクラスターを起動するときにソフトウェア設定で JupyterHub または Zeppelin を選択し、1 つ以上のインスタンスを使用して Amazon EMR でアプリケーションを開発できます。

Q: コマンドラインツールまたは API を使用する場合と、AWS マネジメントコンソールを使用する場合のそれぞれの利点は何ですか?

コマンドラインツールまたは API は、プログラムでクラスターを起動し、実行中のクラスターの進行度を監視する能力を提供しており、クラスターに関連する追加のカスタム機 (複数の処理ステップ、スケジューリング、ワークフロー、モニタリングなど) の作成や、その他の Amazon EMR お客様向けの付加価値のあるツールもしくはアプリケーションの構築を行うことができます。対照的に、AWS マネジメントコンソールは使いやすいグラフィカルインターフェイスを提供しており、ウェブブラウザから直接クラスターを起動したり、モニタリングしたりすることができます。

Q: 既に実行中のクラスターにステップを加えることができますか?

はい。ジョブが実行中になっている場合、AddJobFlowSteps API を使って、オプションでステップを追加することができます。AddJobFlowSteps API は、現在のステップシーケンスの終わりに新しいステップを追加します。クラスターやデバッグで条件付きロジックを実装するために、この API を使用したい場合があるかもしれません。

Q: クラスターの完了時に通知を受けることはできますか?

Amazon SNS に登録して、クラスターが終了したときに SNS トピックに投稿されるようにすることができます。また、AWS マネジメントコンソールでクラスターの進行度を確認したり、コマンドライン、SDK、または API を使用してクラスターの状態を取得したりすることもできます。

Q: 必要なステップが完了したクラスターを終了させることはできますか?

はい。auto-terminate フラグをオンにしておくことで、すべてのステップが完了した時点で、クラスターが自動的に終了されるようにできます。

Q: Amazon EMR でサポートされている OS のバージョンは何ですか?

Amazon EMR 5.30.0 以降、Amazon EMR 6.x シリーズは、Amazon Linux 2 に基づいています。別の方法として、Amazon Linux 2 を基に作成したカスタム AMI を指定することもできます。こうすることで、事実上どのようなアプリケーションにも、高度な事前設定を実行できます。詳細については、カスタム AMI の使用を参照してください。

Q: Amazon EMR ではサードパーティのソフトウェアパッケージがサポートされていますか?

はい。 お客様のクラスターにサードパーティのソフトウェアパッケージをインストールするには、ブートストラップアクションを使用することです。また、Hadoop 分散キャッシュメカニズムを使用して、静的にコンパイルした実行可能ファイルをアップロードすることもできます。EMR 6.x では、Hadoop 3 がサポートされており、YARN の NodeManager によるコンテナの起動を、EMR クラスターホスト上で直接、あるいは、Docker コンテナの中で行わせることができます。詳細については、ドキュメントを参照してください。

Q: デバッグに利用できるツールにはどのようなものがありますか?

クラスターからの情報を集め、発生した問題についてお客様が判断するために使用できる、いくつかのツールをご用意しています。Amazon EMR Studio を使用する場合は、Spark UI や YARN Timeline Service のようなツールを起動して、デバッグを簡素化できます。Amazon EMR コンソール内ですべての YARN アプリケーションに対し、クラスターを介さずにアクセスするための、いくつかのオプションが用意されています。アクセス可能なのは、Apache Spark 用の永続的アプリケーションでのユーザーインターフェース、Tez UI と YARN のタイムラインサーバー、クラスター上にあるアプリケーションユーザーインターフェースのいくつか、さらに、アプリケーション履歴の概要表示などです。SSH を使用してマスターノードに接続し、ウェブインターフェイスを介してクラスターインスタンスを確認することもできます。詳細については、ドキュメントを参照してください。

Q: EMR Studio とは何ですか?

EMR Studio は、R、Python、Scala、PySparkで記述されたデータエンジニアリングおよびデータサイエンスアプリケーションを、データサイエンティストやデータエンジニアが簡単に開発、視覚化、デバッグできるようにした統合開発環境 (IDE) です。

EMR Studio は、フルマネージド型のアプリケーションで、シングルサインオン、フルマネージド型の Jupyter Notebooks、インフラストラクチャの自動プロビジョニングなどの機能がそなわっています。また、AWS コンソールもしくはクラスターにログインする必要なく、ジョブをデバッグすることも可能です。データサイエンティストとアナリストは、カスタムのカーネルやライブラリのインストール、および、GitHub や BitBucket などのコードリポジトリを使用した同僚との共同作業が行えます。あるいは、スケジュールしたワークフローの内部で、パラメータ化されたノートブックを実行するために、Apache Airflow、AWS Step Functions、および Apache Airflow 用の Amazon マネージドワークフローなどのオーケストレーションサービスを使用できます。 詳細については、Amazon MWAA を使用した Amazon EMR ノートブックでのオーケストレーション分析ジョブをお読みください。EMR Studio カーネルとアプリケーションは EMR クラスターで実行されるため、パフォーマンスに最適化された Apache Spark 用 の Amazon EMR ランタイムを使用して、分散データ処理のメリットを得ることができます。管理者による EMR Studio のセットアップにより、アナリストは、アプリケーションを実行する際に既存の EMR クラスターを使用するのか、あるいは、EMR 用に事前定義された AWS CloudFormation テンプレートを使用して新しいクラスターを作成し使用するのかを選択できます。

Q: EMR Studio では何を実行できますか?

EMR Studio をご利用になるお客様は、AWS コンソールにログインすることなく、企業の認証情報を使用しながら、完全マネージドの Jupyter ノートブックに直接ログインできるようになります。ノートブックの開始は数秒ででき、サンプルのノートブックによりオンボーディングを行った後、データの探査を開始することができます。また、ノートブックからカスタムのカーネルや Python のライブラリをロードすれば、環境をカスタマイズできます。EMR Studio カーネルとアプリケーションは EMR クラスターで実行されるため、パフォーマンスに最適化された Apache Spark 用 の Amazon EMR ランタイムを使用して、分散データ処理のメリットを得ることができます。同僚との共同作業のためには、GitHub や他のレポジトリ経由でノートブックを共有します。ノートブックを継続的インテグレーションおよびデプロイパイプラインとして直接実行することもできます。ノートブックには、さまざまなパラメータ値を渡すことが可能です。また、ノートブックをチェーンしたり、Apache Airflow のようなワークフローオーケストレーションサービスを使用して、ノートブックをスケジュールされたワークフローの中に統合したりできます。さらに、クラスターやジョブのデバッグは数クリックだけで開始できます。これにより、Spark UI や YARN Timeline サービスのような、ネイティブアプリケーションのインターフェースと同じ利便性が得られます。

Q: EMR Studio と EMR Notebooks の相違点を教えてください。

相違点は大きく 5 つあります。

1. EMR Studio の使用には AWS マネジメントコンソールへのアクセスは必要ありません。EMR Studio のホスティングは、AWS マネジメントコンソールの外部で行われています。これは、データサイエンティストやデータエンジニアに対し、AWS マネジメントコンソールへのアクセス権を付与しない場合に便利です。
2. EMR Studio へのログインには、AWS IAM アイデンティティセンター (AWS SSO の後継) を使用して、ID プロバイダーから提供される、企業内の認証情報を使用できます。 
3. EMR Studio により、ノートブックファーストな作業環境が実現します。EMR Studio カーネルとアプリケーションは EMR クラスターで実行されるため、パフォーマンスに最適化された Apache Spark 用 の Amazon EMR ランタイムを使用して、分散データ処理のメリットを得ることができます。クラスターでのコードの実行は、ノートブックを既存の、あるいは、新たにプロビジョニングしたクラスターに、アタッチするのと同じくらいシンプルです。
   
4. EMR Studio では、シンプルなユーザーインターフェースを使用しながら、ハードウェア構成を抽象化することができます。例えば、一度セットアップしたクラスターテンプレートを、新たに他のクラスターを開始する際にも使用できます。 
5. EMR Studio でのデバッグ作業はシンプルです。ユーザーは単一の場所から、必要な数クリックだけで、ネイティブアプリケーションのユーザーインターフェースにアクセスできます。

Q: EMR Studio と SageMaker Studio の相違点を教えてください。

EMR Studio と SageMaker Studio の両方を Amazon EMR で使用できます。EMR Studio は、R、Python、Scala、PySparkで記述されたデータエンジニアリングおよびデータサイエンスアプリケーションを簡単に開発、視覚化、デバッグできるようにした統合開発環境 (IDE) を提供します。Amazon SageMaker Studio では、機械学習に関するすべての開発手順を実行できる、一元的な、ウェブベースのビジュアルインターフェイスが提供されます。SageMaker Studio をご利用のお客様には、モデルの構築、トレーニング、デプロイに必要な各ステップにおいて、完全なアクセスと管理の手法、ならびに可視性が提供されます。データのアップロード、新規ノートブックの作成、モデルのトレーニングと調整、ステップ間での移動などを迅速にこなし、さまざまな試みを調整したり、結果を比較したり、本番環境にモデルをデプロイするといった処理をすべて 1 か所から実行でき、生産性を飛躍的に向上できます。 

Q: EMR Studio の使用を開始する方法を教えてください。

まず、管理者が EMR Studio をセットアップする必要があります。その後、ユーザーに管理者から、Amazon EMR Studio へのサインオン用の固有な URL が届きます。ユーザーは企業で使用している認証情報を使用して、この URL に直接ログインすることができます。

Q: EMR Studio を使用するためにAWS マネジメントコンソールにログインする必要がありますか?

いいえ。管理者が EMR Studio をセットアップし、アクセス用の URL を発行した後は、作業チームは企業での認証情報を使用して EMR Studio にログインできるようになります。AWS マネジメントコンソールには、一切ログインする必要はありません。EMR Studio を使用するチームは、管理者によって設定されたタスクを実行し、リソースにアクセスします。

Q: EMR Studio でのシングルサインオン機能をサポートしている ID プロバイダーを教えてください。

IAM アイデンティティセンター (AWS SSO の後継) は、EMR Studio のシングルサインオンサービスプロバイダーです。AWS IAM によりサポートされている ID プロバイダーの一覧は、こちらのドキュメントでご確認いただけます。

Q: EMR Studio での WorkSpace とは何ですか?

WorkSpace は、Jupyter ノートブックを整理するために使用します。WorkSpace 内にあるすべてのノートブックは、Amazon S3 の同一のロケーションに保存され、同じクラスター上で実行されます。また、WorkSpace 内のすべてのノートブックには、GitHub などのコードレポジトリからリンクすることもできます。WorkSpace の作成や設定は、それをクラスターにアタッチする前に行えます。ただし、その WorkSpace は、ノートブックを実行する前にクラスターに接続しておく必要があります。

Q: EMR Studio ではクラスターがない状態で WorkSpace を作成したりオープンしたりはできますか?

はい。クラスターにアタッチしない状態でも、WorkSpace を作成したりオープンしたりできます。実行しようとするときのみ、それらの WorkSpace をクラスターに接続する必要が生じます。EMR Studio カーネルとアプリケーションは EMR クラスターで実行されます。したがって、パフォーマンスに最適化された Apache Spark 用 の Amazon EMR ランタイムを使用することで、分散データ処理のメリットを得られます。

Q: ノートブックコードで使用するためのカスタムライブラリをインストールできますか?

すべての Spark クエリは EMR クラスターで実行されるため、Spark アプリケーションがクラスターで使用するすべてのランタイムライブラリをインストールする必要があります。ノートブックセル内でノートブックに範囲が制限されたライブラリを簡単にインストールできます。クラスターマスターノードの Jupyter Notebook カーネルまたは Python ライブラリを、ノートブックセル内、もしくは SSH を使用してクラスターのマスターノードに接続しながら、インストールすることもできます。詳細については、ドキュメントを参照してください。さらにクラスターの作成時に、ブートストラップアクション、またはカスタム AMI を使用して必要なライブラリをインストールすることができます。詳細については、Amazon EMR 管理ガイドで「追加のソフトウェアをインストールするためのブートストラップアクションの作成」および「カスタム AMI の使用」を参照してください。

Q: ノートブックはどこに保存されますか?

ワークスペース内のノートブックファイルはワークスペースと合わせて、ノートブック作成時に指定した Amazon S3 の場所に、ipynb ファイルのフォーマットで定期的に自動保存されます。ノートブックファイルには、Amazon EMR Studio のノートブックと同じ名前が付いています。

Q: ノートブックでバージョンコントロールを使う方法を教えてください。 GitHub のようなリポジトリを使用できますか?

Git ベースのリポジトリを Amazon EMR Studio ノートブックに関連付けて、バージョン管理された環境でノートブックを保存できます。

Q: EMR Studio 内でノートブックを実行できるコンピューティングリソースを教えてください。

EMR Studio を使用すると、Amazon Elastic Compute Cloud (Amazon EC2) で実行されている Amazon EMR または Amazon Elastic Kubernetes Service (Amazon EKS) の Amazon EMR でノートブックコードを実行できます。ノートブックのアタッチは、既存または新規のクラスターの両方で可能です。EMR Studio での EMR クラスターの作成には、2 つの方法があります。その第 1 は、事前定義済みのクラスターテンプレートを AWS Service Catalog 経由で使用する方法です。第 2 は、名称、インスタンスの数、およびインスタンスタイプを指定してクラスターを作成する方法です。

Q: EMR Studio で1 つの WorkSpace を異なるコンピューティングリソースを使用しながら再アタッチすることはできますか?

はい、以下の要領で行えます。まず WorkSpace を開き、左側にある [EMR クラスター] アイコンをクリックします。次に、[デタッチ] ボタンをクリックし、[クラスターを選択] のドロップダウンリストからクラスターを選択します。その後に [アタッチ] ボタンをクリックします。

Q: EMR Studio 内のすべての WorkSpace を見るにはどうしたらよいですか?

EMR Studio の左側にある [WorkSpace] タブを開くと、ご自身や、同じ AWS アカウントの他のユーザーが作成した WorkSpace を、表示することができます。

Q: EMR Studio の使用に必要な IAM ポリシーは何ですか?

各 EMR studio には、他の AWS のサービスとの相互運用のためにアクセス許可が必要です。EMR Studios に所望のアクセス許可を付与するためには、管理者が、提供されたポリシーを使用しながら、EMR Studio のサービスロールを作成する必要があります。同時に管理者は、EMR Studio レベルのアクセス許可を定義するために、ユーザーロールも指定します。AWS IAM アイデンティティセンター (AWS SSO の後継) から EMR Studio にユーザーやグループを追加する場合、管理者は、セッションポリシーをそのユーザーもしくはグループに割り当てることで、きめの細かいアクセスコントロールを適用することができます。セッションポリシーを使用することで、管理者は、複数の IAM ロールを作成せずに、ユーザーに対してより細やかなアクセス許可を与えられるようになります。セッションポリシーの詳細については、AWS Identity and Access Management ユーザーガイドの、ポリシーとアクセス許可を参照してください。

Q: EMR Studio 内で WorkSpace を EMR クラスターにアタッチする際に何か制限はありますか?

はい。高可用性 (マルチマスター) クラスター、Kerberos 対応のクラスター、および AWS Lake Formation クラスターは、現在サポートされていません。

Q: Amazon EMR Studio を使用するためのコストを教えてください。

Amazon EMR Studio は、追加料金なしでご利用いただけます。EMR Studio を使用する場合、Amazon Simple Storage Service ストレージおよび Amazon EMR クラスターに適用される料金が適用されます。価格設定オプションと詳細については、Amazon EMR の価格設定を参照してください。

Q: EMR Notebooks とは何ですか?

新規のお客様には、EMR Notebooks ではなく、Amazon EMR Studio を使用することをお勧めいたします。EMR Notebooks は、Jupyter Notebook に基づくマネージド環境を提供し、データサイエンティスト、アナリスト、および開発者が EMR クラスターを使用してデータを準備して可視化し、同業者と共同作業を行い、アプリケーションを構築して、インタラクティブな分析を実行できるようにします。新規のお客様には EMR Studio をお勧めしますが、互換性のために EMR Notebooks がサポートされています。

Q: EMR Notebooks では何を実行できますか?

EMR Notebooks は、最小限の工数で EMR クラスターに Apache Spark アプリケーションをビルドし、インタラクティブなクエリを実行するために使用できます。複数のユーザーが、コンソールから直接サーバーレスノートブックを作成し、それらを既存の共有 EMR クラスターにアタッチするか、クラスターをコンソールから直接プロビジョニングして、Spark を使った実験を直ちに開始することが可能です。ノートブックをデタッチした後、それらを新しいクラスターにアタッチし直すこともできます。ノートブックは自動で S3 バケットに保存され、保存されたノートブックをコンソールから取得して作業を再開することができます。EMR ノートブックには、Anaconda レジストリにあるライブラリがあらかじめ同梱されているため、これらのライブラリをノートブックコードにインポートして使用し、それらを使ってデータの操作と結果の可視化を行うことが可能になります。さらに、EMR ノートブックには Spark モニタリング機能が統合されています。この機能は、Spark ジョブの進捗状況を監視し、ノートブック内からコードをデバッグするために使用できます。

Q: EMR ノートブックの使用を開始する方法を教えてください。

EMR ノートブックの使用を開始するには、EMR コンソールを開き、ナビゲーションペインで [Notebooks] を選択します。そこから、[ノートブックの作成] 選択します。ノートブックの名前を入力して、EMR クラスターを選択 (または新規クラスターを即時に作成)、次にノートブックが使用するサービスロールを提供して、ノートブックファイルを保存する S3 バケットを選択した後、[ノートブックの作成] をクリックします。ノートブックのステータスが準備完了になったら、[オープン] をクリックしてノートブックエディタを起動します。

Q: EMR Notebooks はどの EMR リリースバージョンをサポートしていますか?

EMR Notebooks は、EMR のリリース 5.18.0 以降を実行する EMR クラスターにアタッチできます。

Q: EMR Notebooks を使用するためのコストを教えてください。

EMR Notebooks は、追加料金なしでご利用いただけます。アカウント内でアタッチされた EMR クラスターについては、通常通りに課金されます。お使いのクラスターの料金設定に関する詳細については、https://aws.amazon.com/emr/pricing/ をご覧ください   

Q: Amazon S3 へのデータの格納はどのように行えばよいですか?

Amazon EMR では、いくつかの方法でクラスターにデータを格納できます。最も一般的な方法では、まずデータを Amazon S3 にアップロードし、Amazon EMR の組み込み済み機能を使用しながら、そのデータをクラスターに移動します。分散ファイルシステムからローカルのファイルシステムにファイルを移動するには、Hadoop の分散キャッシュ機能が利用できます。詳細については、ドキュメントを参照してください。別のケースとして、オンプレミスからクラウドにデータを移行している場合には、AWS が提供するクラウドデータ移行サービスの中の 1 つを使用することもできます。

Q: 終了したクラスターのログはどのように取得するのですか?

Hadoop のシステムログおよびユーザーログが、クラスターの作成時に指定した Amazon S3 バケットに保存されます。永続アプリケーションの UIは、クラスター外で実行されています。Spark History Server、Tez UI および YARN タイムラインサーバーのログは、アプリケーション終了後、30 日間参照することができます。

Q: ログは圧縮されますか?

今回、ログは Amazon S3 に移動されるため、Amazon EMR はそれらの圧縮を行いません。

Q: インターネットまたは Amazon S3 以外の場所から自分のデータを読み込むことができますか?

はい。AWS Direct Connect を使用して、AWS へのプライベートな専用のネットワーク接続を確立できます。データの規模が大きい場合は、AWS Import/Export を使用します。詳細については、ドキュメントを参照してください。

Q: Amazon EMR で入力データの処理時間を見積もることはできますか?

いいえ。クラスターおよび入力データはそれぞれ異なっているため、当社はお客様のジョブに要する時間を見積もることはできません。

Q: Amazon EMR の費用はいくらですか?

Amazon EMR の料金は予測がしやすくシンプルです。1 分間の最小課金時間があり、その後、使用量に対し 1 秒ごとに課金されます。請求額は、AWS Pricing Calculator を使用して見積ることができます。Amazon EC2 を含め、その他のアマゾン ウェブ サービスの使用料金は、Amazon EMR とは別に請求されます。

Q: Amazon EMR クラスターの請求対象期間はいつからいつまでですか?

Amazon EMR に関する課金は、クラスターでステップを実行する準備ができた時点から開始されます。クラスターのシャットダウンをリクエストすると、Amazon EMR への課金は終了します。Amazon EC2 が課金を開始と終了するタイミングの詳細については、Amazon EC2 の請求に関するよくある質問を参照してください。

Q: Amazon EMR、Amazon EC2、および Amazon S3 の使用量の追跡はどこで行えますか?

請求とコスト管理コンソールで、これらの使用量を追跡できます。

Q: コンソールに表示される正規化インスタンス時間はどのように計算されますか?

AWS マネジメントコンソールで、各クラスターには正規化インスタンス時間の欄があります。ここにはクラスターが使用したコンピューティング時間の概数が切り上げて表示されます。

正規化インスタンス時間とはコンピューティングに利用した時間で、m1.small の 1 時間の使用を 1 標準処理時間として計算されます。各インスタンスファミリーでの異なるサイズ、および、それらに対応した 1 時間ごとの正規化ファクターの一覧は、こちらのドキュメントでご確認いただけます。

例えば、10 ノードの r3.8xlarge クラスターを 1 時間実行した場合、コンソールに表示される正規化インスタンス時間の合計数は 640 (10 (ノード数) x 64 (正規化係数) x 1 (クラスターを実行した時間数) = 640) となります。

これは概算値であり、請求目的で使用されるものではありません。請求の対象となる Amazon EMR の使用量については、請求とコスト管理コンソールをご覧ください。

Q: Amazon EMR では、Amazon EC2 のオンデマンドインスタンス、スポットインスタンス、リザーブドインスタンスはサポートされていますか?

はい。Amazon EMR は、オンデマンド、スポット、リザーブドの各インスタンスをシームレスにサポートしています。Amazon EC2 リザーブドインスタンスの詳細については、ここをクリックしてください。Amazon EC2 スポットインスタンスの詳細については、ここをクリックしてください。Amazon EC2 のキャパシティー予約については、ここをクリックしてください。

Q: 料金は税込み価格ですか?

別途記載がない限り、表示される料金には付加価値税、売上税など、一切の税金等および関税は含まれません。日本の居住者であるお客様が AWS サービスをご利用になった場合には、料金とあわせて別途消費税をご請求させていただきます。詳細はこちら。 

Q: クラスターの実行中に、自分のデータが他の人に閲覧されないようにするにはどうすればよいですか?

Amazon EMR は、インスタンスを 2 つの Amazon EC2 セキュリティグループで開始します。1 つはマスターであり、もう 1 つは別のクラスターノードです。マスターセキュリティグループには通信用に開いたポートがあり、これを使ってサービスを行っています。また SSH ポートが開いており、起動時に指定されたキーを使用して、SSH をインスタンスに対して許可することができます。別のノードは別のセキュリティグループで開始します。これらはマスターのインスタンスとのやりとりのみを許可します。デフォルトでは、両セキュリティグループ共に、他のお客様に所属する Amazon EC2 インスタンスなど、外部ソースからのアクセスを許可しないように設定されています。お客様のアカウント内にセキュリティグループが存在するため、標準 EC2 ツールまたはダッシュボードを使用して、それらの再設定を行うことができます。EC2 のセキュリティグループの詳細については、こちらをクリックしてください。さらに、例外リストに追加しないポートでパブリックアクセスが許可されるルールがある場合、クラスターの作成を防ぐために使用する各リージョンで Amazon EMR ブロックパブリックアクセスを設定できます。

Q: データはどれほど安全ですか?

Amazon S3 は、保存されているデータを未許可のアクセスから保護する認証メカニズムを提供しています。データをアップロード中のお客様が他者を指定しない限り、そのお客様のみがデータにアクセスすることができます。Amazon EMR のお客様は、安全な送信のために HTTPS プロトコルを使用して、Amazon S3 にデータを送信することもできます。さらに、Amazon EMR は常に HTTPS を使用して、Amazon S3 と Amazon EC2 の間でデータのやりとりを行います。セキュリティを強化するには、Amazon S3 にアップロードを行う前に、一般的なデータ暗号化ツールを用いて、入力データの暗号化を行うことができます。その後 Amazon EMR がデータを Amazon S3 から取得する際、そのクラスターを開始するために、復号のステップを追加する必要があります。

Q: セキュリティまたはコンプライアンス監査のために、自分のアカウントで実行したすべての EMR API コールの履歴を取得することはできますか?

はい。AWS CloudTrail は、アカウントに対する AWS API コールを記録し、ログファイルを配信するウェブサービスです。CloudTrail で生成される AWS API の呼び出し履歴を利用して、セキュリティ分析、リソース変更の追跡、およびコンプライアンスの監査を行うことができます。CloudTrail の詳細については、AWS CloudTrail の詳細ページを参照してください。CloudTrail を有効にするには、CloudTrail の AWS マネジメントコンソールにアクセスしてください。

Q: Amazon S3 で EMR ユーザーがアクセスできるものを管理するにはどうすればよいですか。

デフォルトでは、Amazon EMR アプリケーションプロセスは他の AWS サービスを呼び出すときに EC2 インスタンスプロファイルを使用します。マルチテナントクラスターの場合、Amazon EMR は、Amazon S3 データへのユーザーアクセスを管理するための 3 つのオプションを提供します。

1. AWS Lake Formation との統合により、AWS Lake Formation で詳細な承認ポリシーを定義および管理して、AWS Glue Data Catalog のデータベース、テーブル、および列にアクセスできます。インタラクティブな EMR Spark ワークロードに対して Amazon EMR Notebooks および Apache Zeppelin を介して送信されたジョブに承認ポリシーを適用し、監査イベントを AWS CloudTrail に送信できます。この統合を有効にすることで、Security Assertion Markup Language (SAML) 2.0 と互換性のあるエンタープライズ ID システムから EMR Notebooks または Apache Zeppelin へのフェデレーション Single Sign-On も有効になります。
   
2. Apache Ranger とのネイティブ統合により、新規または既存の Apache Ranger サーバーをセットアップして、ユーザーが Hive Metastore 経由で Amazon S3 データのデータベース、テーブル、および列にアクセスするための詳細な承認ポリシーを定義および管理できます。Apache Ranger は、Hadoop プラットフォーム全体の包括的なデータセキュリティを有効化、モニタ、および管理するオープンソースツールです。
   
   このネイティブ統合により、Apache Ranger ポリシー管理サーバーで 3 種類の認証ポリシーを定義できます。Hive でテーブル、および列レベルの認証に対してテーブル、列、および行レベルの認証を設定できます。Spark では、テーブルおよび列レベルの認証を定義できます。そして、Amazon S3 にはプレフィックスとオブジェクトレベルの認証を定義できます。Amazon EMR は、対応する Apache Ranger プラグインをクラスターに自動的にインストールして構成します。Ranger プラグインはポリシー管理サーバーとの間で認証ポリシーを同期し、データアクセス制御を適用して、監査イベントを Amazon CloudWatch Logs に送信します。
   
3. Amazon EMR User Role Mapper を使用すれば、AWS IAM アクセス許可を利用して AWS リソースへのアクセスを管理できます。ユーザー (またはグループ) とカスタム IAM ロール間のマッピングを作成できます。ユーザーまたはグループは、カスタム IAM ロールによって許可されたデータにのみアクセスできます。この機能は現在、AWS ラボからご利用いただけます。

Q: Amazon EMR ではどのようにアベイラビリティーゾーンが使用されますか?

Amazon EMR は、同一の Amazon EC2 アベイラビリティーゾーン内において付与される 1 クラスターのためにすべてのノードを起動します。同一のゾーン内でクラスターを実行することにより、ジョブフローのパフォーマンスが改善されます。デフォルトでは、Amazon EMR はクラスターを実行するために最も利用性の高いリソースを持つアベイラビリティーゾーンを選択するようになっています。ただし必要ならば、別のアベイラビリティーゾーンを指定することもできます。また、最低価格のオンデマンドインスタンス、最適なスポットキャパシティの割り当てを最適化するか、オンデマンドキャパシティ予約を使用するオプションもあります。

Q: どのリージョンでこの Amazon EMR を利用できますか?

サポートされる Amazon EMR AWS リージョンのリストについては、すべての AWS グローバルインフラストラクチャの AWS リージョン表を参照してください。

Q: Amazon EMR は AWS Local Zones でサポートされていますか?

EMR はロサンゼルスの AWS Local Zone の起動クラスターをサポートしています。米国西部 (オレゴン) リージョンでロサンゼルスの AWS Local Zone に関連付けられたサブネットにクラスターを起動する際に EMR を使用できます。

Q: クラスターを実行するためにどのリージョンを選択する必要がありますか?

通常、クラスターを作成する場合、お客様のデータが存在しているリージョンを選択する必要があります。

Q: 米国リージョンで実行中のクラスターにおいて欧州のデータを使用する、またはその逆を行うことができますか?

はい、できます。データを 1 つのリージョンから他のリージョンへ転送する場合、回線料金が課金されます。回線料金情報については、EC2 詳細ページの料金セクションを参照してください。

Q: AWS GovCloud (米国) リージョンは何が違いますか?

AWS GovCloud (米国) リージョンは米国政府関連機関とその顧客向けに設計されています。このリージョンは US ITAR の要件に準拠しています。GovCloud では、EMR はスポットインスタンスとデバッグ有効化機能をサポートしません。また、EMR マネジメントコンソールも、GovCloud では現在ご利用いただけません。

Q: Amazon EMR クラスターとは何ですか?
クラスターに、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを増やします。クラスターの各インスタンスはノードと呼ばれ、ノードタイプと呼ばれるクラスター内で役割を持っています。また、Amazon EMR は、ノードタイプごとに異なるソフトウェアコンポーネントをインストールして、Apache Hadoop などの分散アプリケーションで各ノードに役割を与えます。どのクラスターもすべて、「j-」で始まる一意の識別子を持っています。

Q: クラスター内のノードタイプとは何ですか?
Amazon EMR クラスターには、3 タイプのノードがあります:

1. マスターノード: ソフトウェアコンポーネントを実行してクラスターを管理し、他のノード間にあるデータやタスクの分散を調整して処理するノード。マスターノードは、タスクのステータスを追跡し、クラスターの状態を監視します。各クラスターにはマスターノードがあり、マスターノードだけで、単一ノードクラスターを作成することができます。
2. コアノード: タスクを実行し、クラスターの Hadoop Distributed File System (HDFS) にデータを格納するソフトウェアコンポーネントを備えたノード。マルチノードクラスターには、最低 1 つのコアノードがあります。
3. タスクノード: タスクを実行するのみの、HDFS にデータを保存しないソフトウェアコンポーネントを備えたノード。タスクノードはオプションです。
   
   

Q: クラスターのステップとは何ですか?
クラスターのステップはユーザー定義の処理単位で、データを操作する 1 つのアルゴリズムに対しておおまかにマッピングを行います。ステップとは、Java jar として、または Java、Ruby、Perl、Python、PHP、R、もしくは C++ で書かれたストリーミングプログラムとして実装された Hadoop MapReduce アプリケーションです。例えば、単語が文書に登場する頻度をカウントし、頻度数ごとにそれらを並び替えて出力するために、最初のステップは、各単語の出現回数をカウントする MapReduce アプリケーションとなります。2 つめのステップは、カウント数を基にして、最初のステップからの出力を並び替える MapReduce アプリケーションとなります。

Q: クラスターの各状態について教えてください。
STARTING – クラスターは EC2 インスタンスを設定しすることから開始されます。
BOOTSTRAPPING – クラスターでブートストラップアクションを実行します。
RUNNING – クラスターの 1 ステップが現在実行中です。
WAITING – クラスターは現在アクティブですが、実行中のステップがありません。
TERMINATING – クラスターはシャットダウンの途中です。
TERMINATED – クラスターは正常にシャットダウンされました。
TERMINATED_WITH_ERRORS – クラスターはシャットダウンされましたが、エラーが発生しました。

Q: ステップの各状態について教えてください。
PENDING – ステップが実行待ちの状態です。
RUNNING – ステップが現在実行中です。
COMPLETED – ステップが正しく完了しています。
CANCELLED – ステップが実行前にキャンセルされています。前のステップが失敗しているか、またはクラスターが実行可能となる前に終了したためです。
FAILED – ステップを実行中に失敗しました。

Q: クラスターの起動方法について教えてください。
簡単なクラスターの申請フォームに入力することにより、AWS マネジメントコンソールを通じて、クラスターを起動することができます。申請フォームでは、クラスター名、入力データの Amazon S3 内の場所、処理アプリケーション、希望するデータの出力場所、および使用したい Amazon EC2 インスタンスの数とタイプを指定します。オプションで、クラスターログファイルと SSH キーを保存する場所を指定して、稼働中にクラスターにログインできます。あるいは、RunJobFlow API またはコマンドラインツールの [Create] コマンドを使用して、クラスターを起動できます。EMR Studio を使ったクラスター起動については、上記の EMR Studio のセクションをご覧ください。

Q: クラスターの終了方法を教えてください。
AWS マネジメントコンソールでクラスターを選択し、[終了] ボタンをクリックすることによって、いつでもクラスターを終了することができます。あるいは、TerminateJobFlows API を使用することができます。実行中のクラスターを終了する場合、Amazon S3 に存在していない結果は失われ、すべての Amazon EC2 インスタンスはシャットダウンします。

Q: Amazon EMR では多重同時クラスターがサポートされますか?
クラスターは好きな数だけ開始できます。インスタンスの数は、使用しているクラスター全体で最大 20 に制限されています。さらに多くのインスタンスが必要な場合は、Amazon EC2 インスタンス申請フォームをご記入ください。お客様の Amazon EC2 上限数が引き上げられると、その上限値が Amazon EMR クラスターに自動的に適用されます。

Q: Amazon EMR では、Amazon EC2 と Amazon S3 はどのように使用されますか?

まず、お客様は、入力データとデータ処理アプリケーションを Amazon S3 にアップロードします。その後 Amazon EMR は、お客様に指定されたいくつかの Amazon EC2 インスタンスを起動します。サービスは、S3 の URI スキームを使用して、起動された Amazon EC2 インスタンスに Amazon S3 からの入力データをプルしながら、クラスターの実行を開始します。クラスターが終了した後、Amazon EMR は出力データを Amazon S3 に転送します。そのデータは、お客様が取得したり、あるいは、別のクラスターの入力として使用したりできます。

Q: Amazon EMR では計算はどのように行われますか?

Amazon EMR は Hadoop データ処理エンジンを使用して、MapReduce プログラミングモデルで実行される計算を行うことができます。お客様は、map() および reduce() 関数に関するアルゴリズムを実装します。1 つのマスターと複数の他のノードから構成された、お客様が指定する数の Amazon EC2 インスタンスをサービスが開始します。Amazon EMR はこれらのインスタンス上で Hadoop ソフトウェアを実行します。マスターノードは入力データをブロックに分割し、ブロックの処理を別のノードに分配します。その後各ノードは、それに配分されたデータ上でマップ関数を実行し、中間データを生成します。中間データは並び替えられて分割され、ノードでローカルにリデューサー関数を適用するプロセスへと送信されます。最終的に、reducer タスクからの出力がファイル中で収集されます。単一の「クラスター」には、このような MapReduce の一連のステップを必要とする場合があります。

Q: Amazon EMR でサポートされる、Amazon EC2 のインスタンスタイプを教えてください。

各リージョンで利用可能なインスタンスタイプと料金の最新の詳細については、EMR 料金表のページを参照してください。

Q: クラスターを実行するのに要する時間はどれくらいですか?

クラスターの実行に要する時間は、クラスターのタイプ、入力データの分量、クラスターのために選択される Amazon EC2 インスタンスの数とタイプなど、いくつかの要因によって異なります。

Q: クラスターのマスターノードが故障した場合、Amazon EMR によりそれを回復させることができますか?

はい。3 つのマスターノードがある EMR クラスター (バージョン 5.23 以降) を起動して、YARN Resource Manager、HDFS Name Node、Spark、Hive、Ganglia などのアプリケーションの高可用性を向上させることができます。プライマリマスターノードに障害が発生した場合、または Resource Manager や Name Node などの重要なプロセスがクラッシュした場合、Amazon EMR は自動的にスタンバイマスターノードにフェイルオーバーします。マスターノードが単一障害点となることはないため、長寿命の EMR クラスターを中断することなく実行できます。フェイルオーバーが発生した場合、Amazon EMR は障害が発生したマスターノードを新しいマスターノードに自動的に置き換えます。新しいマスターノードの設定およびブートストラップアクションも自動的に引き継がれます。 

Q: クラスター内の別のノードが失敗した場合、Amazon EMR によりそれを回復させることができますか?

はい。Amazon EMR はノードの障害に対して耐障害性を備えており、ノードが失敗した場合でもジョブの実行を継続します。また、Amazon EMR は、コアノードに障害が発生した場合に新しいノードをプロビジョニングします。ただし、クラスター内のすべてのノードが失われた場合、Amazon EMR はノードを置き換えません。

Q: クラスターノードに SSH で接続することができますか?

はい。SSH をクラスターノード上に配置して、Hadoop コマンドをそこから直接実行することができます。SSH を特定のノードに配置する必要がある場合、SSH を最初にマスターノードに配置してから、次に SSH を目的のノードに配置する必要があります。

Q: Amazon EMR ブートストラップアクションとは何ですか?

ブートストラップアクションとは、クラスターの実行前に、ユーザーにカスタムセットアップを実行する手段を提供する、Amazon EMR の機能です。ブートストラップアクションは、クラスターの実行前に、ソフトウェアのインストールまたはインスタンスの設定のために使用することができます。EMR のデベロッパーガイドで、ブートストラップアクションに関する詳細な説明がご覧になれます。

Q: ブートストラップアクションはどのように使用できますか?

Bash、Perl、Python、Ruby、C++、または Java など、クラスターインスタンスに既にインストールされている言語で、ブートストラップアクションのスクリプトを記述できます。いくつかの利用可能な、あらかじめ定義されたブートストラップアクションがあります。記述されたスクリプトは、Amazon S3 にアップロードする必要があります。クラスターの開始時には、このスクリプトのロケーションを参照します。ブートストラップアクションの使用方法の詳細については、デベロッパーガイドを参照してください。

Q: クラスターに対する Hadoop 設定はどのように行いますか?

EMR のデフォルト Hadoop 設定はほとんどのワークロードに適しています。ただし、クラスター特有のメモリと処理の要件により、設定の調整が必要な場合があります。例えば、クラスタータスクがメモリを大量に使用する場合、コア別に使うタスクの数を減らしてジョブ追跡のヒープサイズを減らすことができます。この場合、あらかじめ設定されているブートストラップアクションを使って、クラスターの開始を設定します。設定の詳細と使用方法については、開発者ガイドのメモリを大量に使用するブートストラップアクションをご覧ください。クラスターの設定を任意の値にカスタマイズできる別の定義済みブートストラップアクションも利用できます。使い方については、開発者ガイドの Hadoop ブートストラップアクションの設定をご覧ください。

Q: 実行中のクラスターでノードの数を変更できますか?

はい。ノードには次の 2 種類があります。(1) Hadoop Distributed File System (HDFS) と Hadoop タスクの実行を使ってデータをホストする「コアノード」と (2) Hadoop タスクでのみ実行される「タスクノード」です。クラスターの実行中に、コアノードの数を増やしたり、タスクノードの数を増減したりすることができます。これは、API、Java SDK、またはコマンドラインクライアントで実行します。実行中のクラスターのサイズを変更する方法の詳細については、デベロッパーガイドで実行中のクラスターのサイズ変更のセクションを参照してください。また、EMR マネージドスケーリングをご使用いただくこともできます。

Q: コアノードとタスクノードはどのような場合に使用しますか?

コアノードは、HDFS の永続データをホストするため、削除できません。コアノードは、クラスターが完了するまで、その容量を確保する必要があります。タスクノードは、追加または削除することができ、HDFS を含んでいません。このノードは、一時的にのみ使用される容量に適しています。タスクインスタンスフリートをスポットインスタンスで起動すれば、コストを最小化しながら容量を増やすことも可能です。

Q: 実行中のクラスターにあるノードの数はどのような場合に変更しますか?

実行中のクラスターのノードの数を変更する状況はいくつかあります。クラスターの処理速度が予測より遅い場合、またはタイミング要件が変更されたときに、コアノードの数を増やしてクラスターのパフォーマンスを高めることができます。クラスターの段階によって必要な容量が異なる場合は、少ない数のコアノードから始めた後に、タスクノードの数を増減させながら、クラスターでのそれぞれの容量要件に合わせ調整します。 また、EMR マネージドスケーリングをご使用いただくこともできます。

Q: クラスターの各ステップ間でノードの数を自動で変更できますか?

はい。あらかじめ定義されたステップをワークフローに含めて、異なる容量ニーズがあるステップ間のクラスターのサイズを自動的に調整するようにできます。すべてのステップは順次実行されます。これにより、指定のクラスターステップを実行するノードの数を設定することができます。

Q: 自分のクラスターに他の IAM ユーザーがアクセスするのを許可する方法を教えてください。

EMR CLI 内で、すべての IAM ユーザーに表示されるクラスターを新たに作成するには、クラスターの作成時に「--visible-to-all-users」フラグを追加します。例: elastic-mapreduce --create --visible-to-all-users。マネジメントコンソールで、クラスターの作成ウィザードの [詳細オプション] ペインにある [Visible to all IAM Users] を選択します。

既存のクラスターをすべての IAM ユーザーに表示されるようにするには、EMR CLI を使用する必要があります。--set-visible-to-all-users を使用し、クラスター ID を指定します例: elastic-mapreduce --set-visible-to-all-users true --jobflow j-xxxxxxx。これは、クラスターの作成者のみ行うことができます。

詳細については、EMR デベロッパーガイドの、ユーザー許可の設定のセクションをご覧ください。

Q: どの Amazon EMR リソースにタグ付けできますか?

アクティブな Amazon EMR クラスターにタグを付けることができます。Amazon EMR クラスターは Amazon EC2 インスタンスで構成され、Amazon EMR クラスターに付けられたタグはそのクラスター内のアクティブなすべての Amazon EC2 インスタンスに反映されます。アクティブなクラスターに含まれていたが終了したクラスターや終了した Amazon EC2 インスタンスでは、タグを追加、編集、または削除することはできません。

Q: Amazon EMR へのタグ付けでは IAM ユーザーへのリソースベースのアクセス許可をサポートしていますか?

いいえ、Amazon EMR では、タグによるリソースベースのアクセス許可をサポートしていません。ただし、Amazon EC2 インスタンスに反映されたタグが通常の Amazon EC2 タグと同様に動作することに注意する必要があります。このため、Amazon EMR から反映されたタグが Amazon EC2 用の IAM ポリシーの条件を満たす場合には、そのポリシーはタグに作用します。

Q: リソースには何個のタグを付けることができますか?

Amazon EMR クラスターには最大 10 個のタグを付けることができます。

Q: クラスターに付けた Amazon EMR タグはそのクラスターの Amazon EC2 インスタンスごとに表示されますか? Amazon EMR クラスターからタグを削除した場合、そのタグは関連する各 EC2 インスタンスから自動的に削除されますか?

はい、Amazon EMR はクラスターに付けられたタグをそのクラスターを構成する EC2 インスタンスに反映します。Amazon EMR クラスターにタグを付けた場合、そのタグは関連する Amazon EC2 インスタンスにも表示されます。同様に、Amazon EMR クラスターからタグを削除した場合、そのタグは関連する Amazon EC2 インスタンスからも削除されます。ただし、Amazon EC2 用に IAM ポリシーを使用していて、Amazon EMR のタグ付け機能を使用する場合は、Amazon EC2 タグ付け API、CreateTags および DeleteTags を使用するアクセス許可が付与されていることを確認する必要があります。

Q: コストを分割するため、請求明細にタグを表示するにはどうすればよいですか?

AWS 請求レポートで使用したいタグをここで選択します。そして、組み合わせたリソースのコストを確認するには、同じタグキー値を持つリソースに基づいて請求情報を整理できます。

Q: どの Amazon EC2 インスタンスが Amazon EMR クラスターに含まれるかを識別するにはどうすればよいですか?

Amazon EMR クラスターに関連する Amazon EC2 インスタンスには、2 つのシステムタグが付けられています。

• aws:elasticmapreduce:instance-group-role=CORE
  • Key = instance-group role ; Value = [CORE or TASK];
• aws:elasticmapreduce:job-flow-id=j-12345678
  • Key = job-flow-id ; Value = [JobFlowID]

Q: 直接 Amazon EC2 インスタンスでタグを編集できますか?

はい、Amazon EMR クラスターに含まれている Amazon EC2 インスタンスで直接、タグを追加または削除することができます。しかし、そのようにすることはお勧めできません。その理由は、Amazon EMR のタグ付けシステムは関連する Amazon EC2 インスタンスで直接行った変更と同期しないためです。クラスターと、それに関連する Amazon EC2 インスタンスへの正しいタグ付けを保証するために、Amazon EMR クラスターのタグの追加および削除には、Amazon EMR コンソール、CLI、または API をご使用になることをお勧めします。

Q: Amazon EMR Serverless とは何ですか?

Amazon EMR Serverless は Amazon EMR の新しいデプロイオプションで、Apache Spark や Apache Hive などのビッグデータフレームワークを、クラスターの設定、管理、スケーリングなしで実行することができます。

Q: EMR Serverless は誰が使用できますか?

データエンジニア、アナリスト、科学者は、Apache Spark や Apache Hive などのオープンソースのフレームワークを使用してアプリケーションを構築するために EMR Serverless を使用できます。これらのフレームワークを使用して、データの変換、インタラクティブな SQL クエリの実行、機械学習ワークロードの実行が可能です。

Q: EMR Serverless の使用を開始する方法を教えてください。

EMR Studio、AWS CLI、または API を使用して、ジョブの送信、ジョブのステータスの追跡、および EMR Serverless で実行するデータパイプラインの構築を行うことができます。EMR Studio を使い始めるには、AWS マネジメントコンソールにサインインし、Analytics カテゴリで Amazon EMR に移動し、Amazon EMR Serverless を選択します。AWS マネジメントコンソールの指示に従って、Analytics カテゴリの下にある Amazon EMR に移動し、Amazon EMR Serverless を選択します。 開始方法のガイドの指示に従い、EMR Serverless アプリケーションを作成し、ジョブを送信します。CLI を使用してアプリケーションを起動し、ジョブを送信するには、AWS CLI でアプリケーションと対話するページを参照することができます。また、GitHub リポジトリで EMR Serverless の例とサンプルコードを見つけることができます。

Q: EMR Serverless がサポートしているオープンソースのフレームワークは何ですか?

EMR Serverless は現在、Apache Spark と Apache Hive のエンジンをサポートしています。Apache Presto や Apache Flink などの追加フレームワークのサポートが必要な場合は、emr-feedback@amazon.com までリクエストをお送りください。

Q: EMR Serverless はどのリージョンで利用可能ですか?

EMR Serverlessは、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (ストックホルム)、南米 (サンパウロ)、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、および米国西部 (オレゴン) の各 AWS リージョンで利用できます。

Q: Amazon EMR Serverless、EC2 での Amazon EMR、AWS Outposts での Amazon EMR、EKS での Amazon EMR の違いは何ですか?

Amazon EMR は、EC2 ベースのクラスター、EKS クラスター、Outposts、または Serverless 上でアプリケーションを実行するオプションを提供します。EC2 クラスター上の EMR は、アプリケーションの実行に関して最大限の制御と柔軟性を必要とするお客様に適しています。EC2 クラスター上の EMR では、アプリケーション固有のパフォーマンスニーズに合わせて EC2 インスタンスタイプを選択し、Linux AMI のカスタマイズ、EC2 インスタンス設定のカスタマイズ、オープンソースフレームワークのカスタマイズと拡張、および追加のカスタムソフトウェアのクラスターインスタンスへのインストールを行うことができます。EKS での Amazon EMR は、アプリケーション間でクラスターを管理するために EKS を標準化したいお客様や、同じクラスターでオープンソースのフレームワークの異なるバージョンを使用したいお客様に適しています。AWS Outposts での Amazon EMR は、Outpost 内で、よりデータセンターに近い場所で EMR を実行したいお客様向けです。EMR Serverless は、クラスターの管理や運用を避け、オープンソースのフレームワークを使ってアプリケーションを実行したいお客様に適しています。

Q: EMR Serverless と EC2 での Amazon EMR の機能の違いは何ですか?

Q: EMR Serverless でサポートされている EMR のリリースは何ですか?

EMR Serverless は、EMR のリリースラベル 6.6 以降をサポートしています。EMR Serverless では、他の EMR デプロイオプションで利用できるのと同じパフォーマンス最適化された EMR ランタイムを利用でき、標準的なオープンソースフレームワークと 100% の API 互換性があります。

Q.事前に初期化されたキャパシティの料金は、BilledResourceUtilization に含まれていますか?

BilledResourceUtilization では、事前に初期化された容量がジョブに使用されていた期間のみが考慮され、そのような容量のアイドル時間は考慮されません。

Q: BilledResourceUtilization と TotalResourceUtilization の違いは何ですか?

ワーカーのランタイムが 60 秒未満の場合、BilledResourceUtilization は 60 秒としてカウントされますが、TotalResourceUtilization では最も近い秒に切り上げられます。さらに、BilledResourceUtilization では、20 GB の空きストレージが計算から除外されます。

Q: アプリケーションとは何ですか、またどのように作成するのですか?

Amazon EMR Serverless では、オープンソースの分析フレームワークを使用する 1 つまたは複数の EMR Serverless アプリケーションを作成することができます。アプリケーションを作成するには、次の属性を指定する必要があります。1) 使用したいオープンソースフレームワークバージョンの Amazon EMR リリースバージョン、2) アプリケーションで使用したい特定の分析エンジン (Apache Spark 3.1 または Apache Hive 3.0 など)。アプリケーションを作成したら、データ処理ジョブやアプリケーションへの対話型リクエストの実行を開始することができます。

Q: ワーカーとは何ですか?

EMR サーバーレスアプリケーションは、内部的にワーカーを使用してワークロードを実行します。ジョブが送信されると、EMR Serverless はそのジョブに必要なリソースをコンピューティングし、ワーカーをスケジュールします。EMR Serverless はワークロードをタスクに分解し、オープンソースのフレームワークでワーカーをプロビジョニングしてセットアップし、ジョブが完了したらワーカーをデコミッションします。EMR Serverless は、ジョブの各段階で必要となるワークロードと並列性に応じてワーカーを自動的にスケールアップまたはダウンさせるため、ワークロードの実行に必要なワーカーの数を見積もる必要がありません。これらのワーカーのデフォルトのサイズは、アプリケーションの種類と Amazon EMR のリリースバージョンに基づきます。ジョブ実行のスケジューリング時に、これらのサイズをオーバーライドすることができます。

Q: 自分のジョブが使用できるワーカーの最小数と最大数を指定できますか?

EMR Serverless では、同時実行ワーカーの最小数と最大数、ワーカーの vCPU とメモリ設定を指定することができます。また、アプリケーションのリソースの最大容量制限を設定することで、コストを抑制することも可能です。

Q: どのような場合に複数のアプリケーションを作成する必要がありますか?

次のいずれかを行う場合、複数のアプリケーションを作成することを検討してください。

1. 異なるオープンソースフレームワークを使用する
2. 異なるユースケースに異なるバージョンのオープンソースフレームワークを使用する
3. あるバージョンから別のバージョンにアップグレードする際の A/B テストの実施する
4. テストシナリオと本番シナリオのために、別々の論理環境を維持する
5. 独立したコスト管理と使用状況の追跡が可能な、異なるチーム用の別々の論理環境を提供する
6. 異なるラインオブビジネスアプリケーションを分離する

Q: EMR Serverless アプリケーションを作成した後、デフォルトのプロパティを変更することはできますか?

はい、EMR Studio または update-application API/CLI コールを使用して、初期容量、最大容量制限、ネットワーク設定などのアプリケーションのプロパティを変更することができます。

Q: ワーカーのプールを事前に初期化したアプリケーションは、いつ作成すればよいですか?

ワーカーを事前に初期化していない EMR Serverless アプリケーションは、必要なリソースを決定してプロビジョニングするのに最大で 120 秒かかります。EMR Serverless は、ワーカーを数秒で初期化して応答できるようにするオプション機能を提供し、アプリケーションのためのワーカーのオンコールプールを効果的に作成します。この機能は事前初期化容量と呼ばれ、アプリケーションの initial-capacity パラメータを設定することでアプリケーションごとに設定することができます。

事前初期化容量では、ジョブをすぐに開始できるため、時間的制約のあるジョブの実装に最適です。EMR Serverless アプリケーションの起動時に、事前に初期化するワーカーの数を指定できます。その後、ユーザーがジョブを送信すると、事前に初期化したワーカーを使用してジョブをすぐに開始することができます。ジョブが事前初期化を選択した数以上のワーカーを必要とする場合、EMR Serverless は自動的にワーカーを追加します (指定した最大同時実行数を上限とします)。ジョブが終了すると、EMR Serverless は自動的に指定した事前に初期化したワーカーのメンテナンスに戻されます。ワーカーは、15 分間アイドル状態が続くと自動的にシャットダウンします。updateApplication API または EMR Studio を使用して、アプリケーションのデフォルトのアイドルタイムアウトを変更することができます。

Q: EMR Serverless でジョブを送信および管理するにはどうすればよいですか?

EMR Serverless のジョブは、EMR Studio、SDK/CLI、または私たちの Apache Airflow コネクタを使用して送信および管理することができます。

Q: EMR Serverless で実行したいジョブの依存関係をどのように含めることができますか?

PySpark の場合、virtualenv を使用して Python の依存関係をパッケージ化し、--archives オプションでアーカイブファイルを渡せば、ジョブ実行中にワーカーが依存関係を使用できるようになります。Scala や Java の場合は、依存関係を jar としてパッケージ化し、Amazon S3 にアップロードして、EMR Serverless のジョブ実行時に --jars または --packages オプションを使用して渡すことができます。

Q: EMR Serverless Spark と Hive アプリケーションは、ユーザー定義関数 (UDF) をサポートしていますか?

EMR Serverless は、Java ベースの UDF をサポートしています。jar としてパッケージ化し、S3 にアップロードして、Spark や HiveQL のスクリプトで使用することができます。

Q: EMR Serverless はどのようなワーカー設定をサポートしていますか?

詳しくはサポート対象ワーカー設定をご参照ください。

Q: EMR Serverless のジョブが予定より長く実行されている場合、キャンセルすることはできますか?

はい、EMR Studio から、または cancelJobRun API/CLI を呼び出して、実行中の EMR Serverless ジョブをキャンセルすることができます。

Q: ワーカーにストレージを追加することはできますか?

EMR Serverless 内のワーカーには、ジョブの送信中に適切なストレージオプションを選択することでストレージを追加できます。EMR Serverless は、次の 2 つのエフェメラルストレージオプションを提供しています。

• 標準ストレージ: このオプションには、デフォルトでワーカーあたり 20 GB のエフェメラルストレージが含まれています。ジョブの送信中にこの設定をカスタマイズして、ストレージ容量をワーカーあたり 20 GB から最大 200 GB に増やすことができます。
• シャッフル最適化ディスクストレージ: このオプションは、シャッフル集約型ワークロードに最適化されたエフェメラルストレージをワーカーあたり最大 2 TB 提供します。

Q: コードサンプルはどこにありますか?

EMR Serverless のコードサンプルは、GitHub リポジトリでご覧いただけます。

Q: EMR Serverless で利用できるワーカーオプションにはどのようなものがありますか?

EMR Serverless には、オンデマンドワーカーと事前初期化ワーカーの 2 つのオプションがワーカーに提供されます。

オンデマンドワーカーは、ジョブに必要な場合にのみ起動され、ジョブが完了すると自動的にリリースされます。これにより、使用したリソースに対してのみ支払いが発生し、アイドル状態のキャパシティに追加コストがかからないため、コストを節約できます。オンデマンドワーカーはワークロードに基づいてアプリケーションをスケールアップまたはスケールダウンするので、リソースの過剰や不足を心配する必要はありません。

事前初期化ワーカーは、ワーカーが数秒で応答できるようにしておくことができるオプション機能です。これにより、アプリケーションのワーカーのウォームプールが効果的に作成され、ジョブを即座に開始できるため、反復的なアプリケーションや時間に制約のあるジョブに最適です。

Q: EMR Serverless アプリケーションを複数のアベイラビリティーゾーン (AZ) に設定できますか?

はい。EMR Serverless アプリケーションを複数の AZ にわたって構成できます。複数の AZ を設定するプロセスは、使用するワーカーのタイプによって異なります。

オンデマンドワーカーのみを使用する場合、EMR Serverless はデフォルトでジョブを複数の AZ に分散しますが、各ジョブは 1 つの AZ でのみ実行されます。サブネットを AZ に関連付けることで、どの AZ を使用するかを選択できます。AZ に障害が発生した場合、EMR Serverless は自動的に別の正常な AZ でジョブを実行します。

事前初期化ワーカーを使用する場合、EMR Serverless は指定したサブネットから正常な AZ を選択します。応募を停止するまで、ジョブはその AZ に送信されます。AZ に障害が発生した場合は、アプリケーションを再起動して別の正常な AZ に切り替えることができます。

Q: 別のリージョンのデータストアに接続できますか?

EMR Serverless は、VPC 接続なしで設定されている場合、同じリージョンの特定の AWS リソースにのみアクセスできます。考慮事項をご覧ください。別のリージョンの AWS リソースや AWS 以外のリソースにアクセスするには、VPC アクセスと NAT ゲートウェイを設定して、AWS リソースのパブリックエンドポイントにルーティングする必要があります。

Q: Amazon EMR Serverless のアプリケーションとジョブの実行をモニタリングするにはどうすればよいですか?

Amazon EMR Serverless のアプリケーションとジョブレベルのメトリクスは、Amazon CloudWatch に 30 秒ごとに公開されます。

Q: EMR Serverless で Spark UI と Tez UI を起動するにはどうすればいいですか?

EMR Studio から、実行中または完了した EMR Serverless ジョブを選択し、Spark UI または Tez UI ボタンをクリックして起動することができます。

Q: Amazon 仮想プライベートクラウド (VPC) 内のリソースにアクセスできますか?

はい、Amazon EMR Serverless アプリケーションを設定して、ご自身の VPC 内のリソースにアクセスすることができます。詳しくはドキュメントの VPC アクセスの設定セクションをご覧ください。 

Q: EMR Serverless アプリケーションでは、どのような分離が可能ですか?

各 EMR Serverless アプリケーションは、他のアプリケーションから分離され、安全な Amazon VPC 上で実行されます。

Q:Amazon EMR Serverless Service Quotas で何が変わりますか?
Amazon EMR Serverless では、アカウントあたりの最大同時 vCPU 数という新しいサービスクォータを導入します。この vCPU ベースのクォータにより、アプリケーションがリージョン内でスケールアップできる vCPU の合計最大数を設定できます。既存のアプリケーションレベルのワーカーベースのクォータ (最大アクティブワーカー数) は、2023 年 2 月 1 日にサポートが終了します。

Q:アカウントの vCPU 割り当てはどこで確認および管理できますか?
AWS Service Quotas 管理コンソールでクォータの増加を表示、管理、リクエストできます。詳細については、Service Quotas ユーザーガイドの「クォータの緩和のリクエスト」をご覧ください。

Q:アカウントレベルの vCPU クォータとアプリケーションレベルの MaximumCapacity プロパティにはどのような違いがありますか?
EMR サーバーレスには 2 つのコスト管理があります。 - 1/ アカウントあたりの同時実行可能な vCPU の最大クォータは、アカウントのリージョンにあるすべての EMR サーバーレスアプリケーションに適用されます。2/ MaximumCapacity パラメーターは、特定の EMR サーバーレスアプリケーションの vCPU を制限します。vCPU ベースのクォータを使用して、リージョン内のすべてのアプリケーションが使用する同時実行仮想 CPU の最大数を制限し、MaximumCapacity プロパティを使用して特定のアプリケーションが使用するリソースを制限する必要があります。例えば、アプリケーションが 5 つあり、各アプリケーションで 1000 vCPU までスケールアップできる場合は、各アプリケーションの最大容量プロパティを 1000 vCPU に設定し、アカウントレベルの vCPU ベースのクォータを 5 x 1000 = 5000 vCPU に設定するように設定します。

Q. vCPU ベースのアカウントクォータに達したかどうかはどうすればわかりますか?
アカウントレベルの vCPU クォータを超えると、EMR Serverless では新しいキャパシティのプロビジョニングを停止します。クォータを超えた後に新しいアプリケーションを作成しようとすると、アプリケーションの作成に失敗し、次のエラーメッセージが表示されます。「アカウントあたりの最大同時 vCPU サービスクォータを超えているため、アプリケーションを作成できませんでした。AWS Service Quotas コンソールを使用してサービスクォータを表示および管理できます」 クォータを超えた後に新しいジョブを送信すると、ジョブは失敗し、次のエラーメッセージが表示されます。「アカウントあたりの最大同時 vCPU サービスクォータを超えたため、ジョブが失敗しました。AWS Service Quotas コンソールを使用してサービスクォータを表示および管理できます」 詳細については、「ドキュメント」を参照してください。

Q: Amazon EMR Serverless は、どのようにビッグデータデプロイのコストを削減するのに役立ちますか?

Amazon EMR Serverless がコスト削減に貢献する方法は 3 つあります。まず、クラスターの管理、安全確保、スケーリングといった運用上のオーバーヘッドが発生しません。2 つ目は、EMR Serverless がジョブの処理段階ごとにワーカーを自動的にスケールアップし、不要になったらスケールダウンすることです。ワーカーの実行を開始してから終了するまでに使用した vCPU、メモリ、およびストレージリソースの合計に対して課金が行われ、最小 1 分単位で最も近い秒に切り上げられます。例えば、ジョブの処理に最初の 10 分間は 10 人のワーカー、次の 5 分間は 50 人のワーカーが必要な場合があります。きめ細かい自動スケーリングでは、10 分間で 10 人のワーカー、5 分間で 50 人のワーカーにかかるコストのみが発生します。その結果、使用率の低いリソースにお金を払う必要がなくなります。3 つ目に、EMR Serverless には、Apache Spark と Apache Hive、および Presto のためにパフォーマンスが最適化された Amazon EMR ランタイムが含まれています。Amazon EMR ランタイムは API 互換性があり、標準的なオープンソースの分析エンジンと比べて 2 倍以上速いため、ジョブの実行が速く、コンピューティングコストが少なくて済みます。

Q: EMR Serverless のコストは、EC2 スポットインスタンスでの Amazon EMR と同等ですか?

現在の EC2 クラスター上の EMR の使用率に依存します。EC2 オンデマンドインスタンスを使用して EMR クラスターを実行している場合、現在のクラスター使用率が 70% 未満であれば、EMR Serverless の方が総保有コスト (TCO) を低く抑えることができます。EC2 Savings Plans を使用している場合、現在のクラスター使用率が 50% 未満であれば、EMR Serverless はより低い TCO を提供します。また、EC2 スポットインスタンスをご利用の場合は、EC2 での Amazon EMR や EKS での Amazon EMR の方が引き続きコスト効率が高いです。

Q: 事前に初期化したワーカーは、ジョブが完了した後でも課金されますか?

はい、ジョブ終了後にワーカーを停止しない場合、事前に初期化したワーカーに課金されます。

Q.質問、コメント、機能リクエストはどこに連絡すればよいですか?

EMR Serverless に関するお問い合わせや貴重なご意見は、emr-feedback@amazon.com まで E メールでお送りください。

Q: Amazon EMR on Amazon EKS とは何ですか?
Amazon EMR on Amazon EKS は、Amazon EMR のデプロイモデルの 1 つです。このモデルをご使用になるお客さまは、非常に大規模なデータを、簡単かつコスト効率よく処理できるようになります。このサービスでは、コンテナ内の Amazon EKS が提供する柔軟なマネージド型サービスで実行される、ホストされた分析フレームワークを活用しています。同時に、Amazon Elastic Compute Cloud (Amazon EC2) 、AWS Fargate、および Amazon Simple Storage Service (Amazon S3) による、ウェブ規模のインフラストラクチャも利用します。

Q: Amazon EMR on Amazon EKS を使用する利点について教えてください。
Amazon EMR on Amazon EKS でな、コンテナベースのアプローチを使用することで、分析ジョブを、他のジョブが処理されているサービスやインフラストラクチャから分離できます。EMR on EKS では、ジョブにおけるコンピューティングやメモリの要件、およびアプリケーションの依存関係に基づき、インフラストラクチャが動的に構成されるので、お客様は、インフラストラクチャの運用作業を減らしながら、アプリケーションの開発により集中できるようになります。インフラストラクチャチームは、共通のコンピューティングプラットフォームを一元的に管理することで、EMR ワークロードを他のコンテナベースのアプリケーションと統合できます。複数のチーム、組織、あるいはビジネスユニットが、共有したインフラストラクチャの上で、分析処理を同時に、あるいは個別に実行することができます。この場合も、Amazon EKS と AWS Identity and Access Management (IAM) により提供された処理の分離は維持されます。

Q: Amazon EKSで Apache Spark を既に実行中のユーザーにもメリットがありますか?
現在、Amazon EKSで Apache Spark を実行されているお客様も、Amazon EMR のすべてのメリットを享受していただけます。自動的なプロビジョニングとスケーリングや、オープンソースの完全マネージド型ビッグデータ解析フレームワークの最新バージョンを使用していただけます。Apache Spark に最適化された EMR ランタイムはオープンソースの Apache Spark を EKS で使用する場合に比べ 3 倍高速に実行できます。さらに、EMR Studio と Apache Spark UI によるサーバーレスのデータサイエンス機能や、きめの細かいアクセスコントロール、そしてデータの暗号化などの機能もご利用いただけます。

Q: この機能では他の AWS のサービスとどのように関連付けや連携が行われていますか?
Amazon EKS をご使用になるお客様は、AWS で Kubernetes を実行するためのマネージド型の環境がご利用になれます。コンピューティング能力の追加には、EKS マネージドのノードグループもしくは AWS Fargate を使用できます。EKS 上で EMR ジョブを実行する際には、Amazon S3 にあるデータにアクセスが可能です。同時に、モニタリングとログ記録の処理は、Amazon CloudWatch と統合することができます。AWS Identity and Access Management (IAM) を使用すれば、ジョブ、あるいは依存関係のある AWS のサービスに対して、ロールベースのアクセスコントロールを実施できます。

Q: Amazon EMR on Amazon EKS はどのように機能するのですか?
まず、EKS クラスターを Amazon EMR に登録します。その後、CLI、SDK、もしくは EMR Studio を使用しながら、Spark ジョブを EMR に送ります。EMR は、ポッドをスケジュールするために、EKS 上の Kubernetes スケジューラにリクエストを送ります。実行される個々のジョブのために、EMR on EKS がコンテナを作成します。このコンテナには、セキュリティアップデートが実施済みの Amazon Linux 2 ベースイメージや、Spark を実行する Apache Spark とその依存関係、さらに、アプリケーション固有の依存関係などが格納されています。それぞれのジョブはポッド内で実行されます。コンテナは、ポッドによりダウンロードされ実行が開始されます。コンテナイメージが、ノードに対し既にデプロイ済みである場合は、キャッシュされたイメージが使用され、ダウンロードの処理はバイパスされます。ログやメトリクスのフォワーダーなどのサイドカーコンテナーも、ポッドでデプロイすることができます。ジョブが終了されると、ポッドも終了します。ジョブの終了後も、Spark UI を使用してデバッグを継続することができます。

Q: Amazon EMR on EKS で使用できる AWS のコンピューティングサービスを教えてください。
Amazon EMR for EKS では、Amazon Elastic Compute Cloud (EC2) インスタンスを使用してカスタマイズ用の広範なオプションをサポートすることや、サーバーレスの AWS Fargate により、EC2 インスタンスのプロビジョニングと管理を行わずに分析処理を行うことが可能です。複数の AWS アベイラビリティーゾーン間で分析ジョブを展開すると、アプリケーションの可用性が自動的に改善されます。

Q: EMR on EKS の使用開始方法を教えてください。
使用開始には、まず Amazon EKS クラスターを Amazon EMR に登録します。 実行する EMR にワークロードを送信することで、登録したクラスターを (アプリケーションの依存関係とフレームワークのパラメータが記述されている) ジョブ定義の中から参照させます。EMR on EKS では、さまざまなオープンソースのビッグデータ分析フレームワークや、そのバージョンが利用できます。また、この EKS クラスター上で実行される分析アプリケーションのための各種の構成も使用が可能です。 詳細については、こちらのドキュメントを参照してださい。

Q: EMR クラスターと EKS 上で実行しているアプリケーションの間で同一リリースの EMR を使用できますか?

はい。EMR クラスターで実行しているアプリケーションと、EKS で実行しているアプリケーションでは、同じリリースの EMR をご使用いただけます。

Q: 分析アプリケーションのトラブルシューティング法を教えてください。
Spark アプリケーションの診断とトラブルシューティングには、Amazon EMR Spark UI が使用できます。EMR では、すべての分析アプリケーションについて、それが完了後最大 30 日間、アプリケーションの詳細や、関連するログとメトリクスへのアクセスが提供されます。個別のジョブは、Amazon S3 のロケーションもしくは Amazon CloudWatch に対して、ログを送信するように設定できます。

Q: EKS 内の EMR アプリケーションを見ることはできまか?
はい。EMR アプリケーションは、Kubernetes ジョブやデプロイ結果と同様に、EKS コンソールの中に表示されます。

Q: 同一の EKS クラスター上で複数のジョブやアプリケーションを相互に分離することは可能ですか?
はい。Kubernetes では、ジョブの分離機能がネイティブに提供されています。加えて、各ジョブでは個別の実行ロールを設定することで、実行時にアクセスできる AWS リソースに制限を加えられます。

Q: EMR on EKS によりコストを削減する方法を教えてください。
EMR on EKS では、専用クラスターを実行する必要性がなく、コストが削減されます。異なるバージョンのオープンソースビッグデータ分析フレームワークで使用する分析アプリケーションを、共有された共通の EKS クラスターにより実行できます。また、コンテナ化された別々の非 EMR アプリケーションを、同一の EKS クラスターの上で実行することも可能です。

Q: EMR on EKS にはどのように課金されますか?
Amazon EMR on EKS の利用料金は、ジョブを実行しているポッドに割り当てられた vCPU とメモリリソースに基づき、1 分間単位で計算されています。料金情報については、Amazon EMR の料金ページでご確認ください。

Q: EMR on EKS と EMR on EC2 の間にはどのような違いがありますか?

Q: AWS Outposts とは何ですか?

AWS Outposts により、ネイティブの AWS のサービス、インフラストラクチャ、運用モデルをほぼすべてのデータセンター、コロケーションスペース、オンプレミスの施設で利用できるようになります。EMR on Outposts を使用すると、オンプレミスの EMR クラスターのデプロイ、管理、スケーリングをクラウド上と同じように行えます。

Q: EMR on Outposts はどんなときに使いますか?

オンプレミスの Apache Hadoop デプロイをお持ちで、ピーク時に使用するキャパシティーのデマンドの対応に苦慮されている場合には、EMR on Outposts を使用すると、処理キャパシティーをクラウドにデータを移行することなく拡大できます。EMR on Outposts ではオンプレミスで新規 EMR クラスターをわずか数分で起動し、オンプレミスの HDFS ストレージ内の既存のデータセットに接続して、こういったデマンドに対処し、SLA を維持することが可能です。

ガバナンスやコンプライアンスなどの理由でオンプレミスに残すべきデータを処理する必要がある場合は、EMR on Outposts を使用するとオンプレミスで Apache Hadoop や Apache Spark のようなアプリケーションをお持ちのデータに近接してデプロイ、実行できます。それにより、大量のオンプレミスデータをクラウドへ移行させる必要がなくなり、データの処理にかかる合計時間を減らすことができます。

データや Apache Hadoop のワークロードをクラウドへ移行させている途中で、移行の完了前に EMR を使用したいとお考えの場合、AWS Outposts を使えば、既存のオンプレミス HDFS ストレージに接続している EMR クラスターを起動することができます。次に、データを Amazon S3 に少しずつ移行させていきます。これによって、次第にクラウドアーキテクチャへと進化していくことになります。

Q: EMR on Outposts はどの EMR バージョンをサポートしていますか?

サポートの最低要件は、Amazon EMR リリース 5.28.0 です。

Q: Outposts の使用中に利用できる EMR アプリケーションはありますか?

EMR リリース 5.28.0 以降のすべてのアプリケーションがサポート対象です。EMR アプリケーションの一覧は、リリースノートでご覧ください。

Q: EMR on Outposts でサポートされない EMR 機能はありますか?

• EC2 スポットインスタンスは、AWS Outposts ではご利用になれません。クラスター作成時に、EC2 オンデマンドインスタンスを選択する必要があります。
• EC2 インスタンスタイプのサブセットは、AWS Outposts でご利用になれます。EMR および Outposts がサポートするインスタンスタイプのリストは、ドキュメントでご覧になれます。
• Amazon EBS ボリュームをインスタンスに追加しているときには、AWS Outposts でサポートされるのは汎用 SSD (GP2) ストレージのみです。

Q: EMR クラスターは、Outpost で既存のオンプレミス Apache Hadoop クラスターからのデータ読み取りに使用できますか?

Outpost で EMR を実行中のワークロードでは既存の HDFS ストレージ内のデータの読み書きができるため、既存のオンプレミス Apache Hadoop デプロイと簡単に統合できます。このため、EMR によってデータ処理のニーズを拡大できますが、データ移行の必要はありません。

Q: データの保存場所は選べますか?

EMR クラスターが Outpost で起動されると、コンピューティングリソースおよびデータストレージリソースはすべて Outpost にデプロイされます。EMR クラスターにローカルで書き込まれたデータは、Outpost 内のローカル EBS ボリュームに保存されます。Apache Hive、Apache Spark、Presto などの EMR アプリケーションのようなツールはそれぞれ、Outpost 内にローカルで既存の HDFS インストールや Amazon S3 のような外部ファイルシステムにデータを書き込めるように設定できます。EMR on Outposts を使用すると、Amazon S3 内または Outpost 内でローカルのデータ保存を完全制御できることになります。

Q: S3 にデータのアップロードが必要な EMR 機能はありますか?

EMR クラスターを Outpost で起動すると、ロギングを有効にするオプションが使用できます。ロギングが有効になると、ユーザー指定の S3 バケットにクラスターログがアップロードされます。このログにより、クラスター終了後のデバッグがシンプルになります。無効になっているときは、ログは S3 にアップロードされません。

Q: Outpost がキャパシティーをオーバーしたら、どうなりますか?

クラスターを Outpost で起動すると、EMR ではユーザーがリクエストした数とタイプの EC2 オンデマンドインスタンスを起動しようとします。Outpost に十分なキャパシティーがない場合は、EMR にキャパシティー不足の通知が届きます。EMR ではしばらくのあいだは再試行を繰り返しますが、キャパシティー不足が続く場合にはクラスターの起動が失敗します。クラスターのサイズを変更したときも同じプロセスです。リクエストされたインスタンスタイプでは Outpost がキャパシティー不足の場合、EMR はクラスターのスケールアップを行えません。Outposts のキャパシティー使用量をモニタリングするには、Amazon CloudWatch アラートの簡単設定によって、ユーザーが望むしきい値をインスタンスキャパシティーが下回ったときにはアラートが届くようになります。

Q: Outpost と AWS 間のネットワーク接続が中断したら、どうなりますか?

Outpost とその AWS リージョン間のネットワーク接続がダウンした場合は、Outposts 内のクラスターは実行を継続しますが、接続が回復するまでは使用できないアクションがあります。クラスターの新規作成や既存クラスターに新たにアクションを起こすことは、接続が回復するまでできません。インスタンスに不具合が起こっても、インスタンスは自動的には置き換えられません。また、実行中のクラスターへのステップ追加、ステップ実行ステータスのチェック、CloudWatch メトリクスおよびイベントの送信などのアクションは、接続が回復するまで延期されます。

Outpost と AWS リージョン間のネットワーク接続には、高い信頼性と可用性を確保していただけるようにお願いいたします。Outpost と AWS リージョン間のネットワーク接続がダウンした状態が数時間以上続く場合は、終了保護が有効になっているクラスターは実行が継続されますが、終了保護が無効になっているクラスターは終了します。メンテナンス業務などのため、ネットワーク接続が日常的に影響を受ける場合は、事前に終了保護を有効にしておくことをお勧めします。

Q: 以前はできなかったことで、新たにできるようになったことはありますか?

大部分の EC2 インスタンスは、「インスタンスストア」と呼ばれる、インスタンスにアタッチされた固定容量のストレージを備えています。Amazon EMR クラスターで EBS ボリュームをインスタンスに追加して、インスタンスのストレージをカスタマイズできるようになりました。この機能により、M4 や C4 など EBS のみのインスタンスファミリーで、Amazon EMR クラスターも実行できます。

Q: Amazon EMR で実行中のインスタンスに EBS ボリュームを追加するメリットは何ですか?

以下のシナリオでは、EBS ボリュームをインスタンスに追加することによるメリットがあります。

1. 処理要件として、現在インスタンスで利用可能な大容量の HDFS (またはローカル) ストレージが必要とされる場合。EBS ボリュームのサポートにより、インスタンスが提供するコンピューティング性能と比較して、インスタンスのストレージキャパシティーのカスタマイズが可能。インスタンスのストレージを最適化することでコストの節約が可能。
2. 旧世代のインスタンスファミリー (M1 および M2 ファミリーなど) で運用中であり、現行世代のインスタンスファミリーに移行する希望があるが、次世代のインスタンスタイプではノードごとに利用可能なストレージが小さい。すべての新しい世代のインスタンスタイプを利用できるようになり、また EBS ボリュームを追加してストレージを最適化できるようになりました。内部ベンチマークでは、旧世代のインスタンスファミリー (M1 また M2) から新しい世代 (M4、C4、R3) に移行することで、コストを節約しパフォーマンスを向上できることが示されています。Amazon EMR チームは、アプリケーションが適切な結果を得られるように動作させることを推奨しています。
3. 次世代 EBS のみの M4 および C4 ファミリーを使用、またはそれらに移行することを希望しています。

Q: クラスターが終了した後も、EBS ボリュームのデータを維持できますか?

現在、Amazon EMR ではクラスターが終了するとボリュームが削除されます。クラスターのライフサイクルを超えてデータを維持したい場合、データストレージとして Amazon S3 の使用を考慮してください。

Q: どの種類の EBS ボリュームをインスタンスにアタッチできますか?

Amazon EMR では、汎用 SSD (GP2)、マグネティック、プロビジョンド IOPS (SSD) の異なる EBS ボリュームタイプが利用できます。

Q: クラスターを終了すると、EBS ボリュームはどうなりますか?

Amazon EMR では EMR クラスターが終了するとボリュームが削除されます。

Q: インスタンスストアのあるインスタンスで EBS を利用できますか?

はい。インスタンスストアのあるインスタンスに、EBS ボリュームを追加することができます。

Q: 実行中のクラスターに EBS ボリュームをアタッチすることは可能ですか?

いいえ、現在 EBS ボリュームを追加できるのはクラスターの起動時のみです。

Q: クラスターからボリュームのスナップショットを作成できますか?

EBS API では、クラスターのスナップショットを作成できます。ただし現在 Amazon EMR では、スナップショットからリストアすることは許可されていません。

Q: 暗号化された EBS ボリュームは使用できますか?

AWS KMS をキープロバイダーに使用することで、EBS のルートデバイスとストレージボリュームを暗号化することができます。詳細については、ローカルディスク暗号化を参照してください。

Q: 実行中のクラスターからアタッチ済みのボリュームを削除するとどうなりますか?

動作中のクラスターからアタッチされているボリュームを削除すると、ノードのエラーとして扱われます。Amazon EMR は、ノードと EBS ボリュームをそれぞれ同等のものに置き換えます。

Q: Apache Spark とは何ですか?

Apache Spark^TM は、ビッグデータのワークロード処理に使用されているオープンソースの分散処理システムです。インメモリキャッシュを使用し、どのようなサイズのデータにも高速な分析クエリを実行できるよう最適化されています。Amazon EMR は、クラウド内に Apache Spark をデプロイするのに最適です。商用 Spark ディストリビューションの統合、そして厳格なテストなどを、クラウドの持つスケール、シンプルさ、コスト効率の高さに組み合わせることができます。Spark クラスターの起動は数分で完了し、ノードのプロビジョニング、クラスターのセットアップ、Spark の設定、クラスターのチューニングはいずれも不要です。EMR では、Apache Spark 用の Amazon EMR ランタイムもご利用になれます。これは、Apache Spark でのパフォーマンスに最適化されたランタイム環境で、Amazon EMR クラスターではデフォルトでアクティブ化されています。Apache Spark 用の Amazon EMR ランタイムは、これを使用しないクラスターと比較して、3 倍以上高速に動作します。API は標準の Apache Spark と 100% の互換性を持っています。Spark と Amazon EMR での Spark の詳細についてご覧ください。

Q: Presto とは何ですか?

Presto は、どのようなサイズのデータにも高速な分析クエリを実行できるよう、ゼロから設計された、オープンソースの分散型 SQL クエリエンジンです。Amazon EMR なら、Presto クラスターを数分で起動でき、ノードのプロビジョニング、クラスターのセットアップ、Presto の設定、クラスターのチューニングはいずれも不要です。EMR により、単体から数百あるいは数千におよぶコンピューティングインスタンスを、数分の内にプロビジョニングできるようになります。Presto には、PrestoDB と PrestoSQL という、2 つのコミュニティプロジェクトがあります。Amazon EMR では、これらのプロジェクトの両方がサポートされています。Presto と Amazon EMR での Presto の詳細をご確認ください。

Q: Apache Hive とは何ですか?

Hive はオープンソースのデータウェアハウスであり、Hadoop の上で稼働する分析パッケージです。Hive の操作には、Hive QL と呼ばれる SQL ベースの言語を使用します。これによってユーザーは、Amazon S3 に保存されているデータソースの構築、要約、クエリを行うことができます。Hive QL は標準的な SQL を超えるものであり、map/reduce 関数や、Json や Thrift といった複雑で拡張可能なユーザー定義のデータタイプのために、第一級のサポートを行います。この能力により、テキスト文書やログファイルといった、複雑で構造化されていないデータソースの処理が可能となります。Hive により、Java で書かれ、Amazon S3 のストレージにデプロイされたユーザー定義の関数を利用した、ユーザーによる拡張が可能となります。Apache Hive の詳細はこちらを参照してください。

Q: Amazon EMR で稼働する Hive でできることは何ですか?

Amazon EMR で Hive を使用すれば、おなじみの SQL と似た言語を持つ洗練されたデータ処理アプリケーションと、Amazon EMR で利用できる使いやすいツールを実装することができます。Amazon EMR を使用すれば、Hive アプリケーションを信頼性の高いデータウェアハウスにして、データ分析、モニタリング、ビジネスインテリジェンスなどのタスクを実行することができます。

Q: Hive は従来の RDBMS システムとはどのように異なりますか?

伝統的な RDBMS システムは、トランザクションの意味と ACID プロパティを提供しています。これらはまたテーブルのインデックス化とキャッシュ化を可能とするため、小さな分量のデータでは非常にすばやい検索を行うことができます。これらは小さな分量のデータの高速アップデート、参照整合性制約を実行します。一般的に、これらは単一の大規模なマシン上で稼働し、テーブル上で map や reduce 関数の実行をサポートしません。また一般的には複雑なユーザー定義のデータタイプをサポートしません。

対照的に、Hive は MapReduce を使用して、SQL に似たクエリを実行します。結果的に、マシンのクラスター上で稼働させることにより、完全なテーブルスキャンの実行を最適化することができます。そのため、莫大なデータ量を処理することができます。Hive は分割されたテーブルを提供します。これによって、実行中のクエリにとって適切な場合は、テーブル全体ではなくてテーブルの一部をスキャンすることができます。

伝統的な RDBMS システムは、トランザクションに意味があり、参照整合性が必要で、さらに頻繁に小さな更新が行われる場合には最適です。Hive は大規模なデータセットのオフラインでのレポート、変換、分析に最適です。例えば大型のウェブサイトのクリックストリーム分析、またはウェブサイトの収集などです。

一般的によく行なわれていることの 1 つに、RDBMS システムから Amazon S3 へのデータのエクスポートがあります。この場合 Hive を実行中の Amazon EMR のクラスターを使用して、オフラインの分析を行なうことができます。

Q: Amazon EMR で稼働する Hive を開始するにはどうすればよいですか?

こちらのドキュメントをご覧になるのが最も良い方法です。

Q: Amazon EMR に固有の Hive の新機能はありますか?

はい。詳細については、ドキュメントを参照してください。

• EMR クラスターを複数のマスターノードで起動することにより、Apache Hive で高可用性をサポートさせることができます。プライマリマスターノードに障害が発生した場合、または Resource Manager や Name Node などの重要なプロセスがクラッシュした場合、Amazon EMR は自動的にスタンバイマスターノードにフェイルオーバーします。この機能により、EMR クラスター上の Apache Hive は、中断を生じることなく実行することが可能です。
• Amazon EMR では、EMR マネージドスケーリングを定義して、Apache Hive クラスターでのリソースの使用量を最適化できます。EMR マネージドスケーリングを使用することで、可能な限り最小のコストで最良のパフォーマンスを発揮するように、クラスターのサイズを自動的に変更できます。EMR マネージドスケーリングで、コンピューティングに関する最小と最大の制限をクラスターに指定すると、最適なリソース使用量で最良のパフォーマンスとなるように、クラスターのサイズが Amazon EMR により自動的に変更されます。クラスター上で実行中のワークロードに関連する主要なメトリクスが、EMR マネージドスケーリングにより継続的にサンプリングされます。
• Amazon EMR 6.0.0 では、Hive LLAP のサポートが追加されており、EMR 5.29 と比較した場合、平均の処理速度が 2 倍にアップしています。詳細については、こちらを参照してください。
• Amazon EMR は、複雑な Apache Hive クエリでの高速パフォーマンスも実現します。EMR では、デフォルトで Apache Tez が使用されるので、Apache MapReduce より大幅に高速化されます。Apache MapReduce では、複数のフェーズで処理が行われるので、複雑な Apache Hive クエリは、4 ないし 5 のジョブに分割されています。Apache Tez は、複雑なクエリ向けに設計されており、Apache Tez 上のいくつかのジョブが 1 体的に実行されます。この構成により、Apache MapReduce と比較して、大幅な高速化を実現しています。
  
• Amazon EMR では、メタストアをローカルに配置するか、外部に配置するかのオプションもあります。EMR は、AWS Glue Data Catalog、Amazon Aurora、Amazon RDS、および AWS Lake Formation と統合できます。Amazon EMR では、メタストアーに格納するための情報を、Glue もしくは Lake Formation から、直接引き出すことが可能です。
• テーブルのパーティションは、Amazon S3 から自動的に読み込めます。以前は、パーティショニングされたテーブルをインポートするためには、テーブル内の個別のパーティションそれぞれに対して、別々のテーブル変換命令文が必要でした。Amazon EMR は現在、Hive 言語のための新しい命令文タイプとして「alter table recover partitions」を含んでいます。 この命令文によって、共有されたメタデータストアを維持することなく、数多くのクラスターのために複数のテーブルを同時に、簡単にインポートすることができます。例えばログファイルのように、外部プロセスがテーブルに対してデータを保存している場合には、テーブルからの読み込みにこの機能を使用します。
• データは直接、Amazon S3 に書込めます。Amazon S3 のテーブルにデータを書き込む際、Amazon EMR にインストールされた Hive のこのバージョンは、一時ファイルを使用することなく、Amazon S3 に直接書き込みを行います。これにより、パフォーマンスが著しく改善されます。しかしこれは、HDFS および Hive パースペクティブからの S3 が異なる振る舞いをすることを意味します。テーブルが Amazon S3 内にある場合、同じテーブルに対して同じ命令文内で読み書きを行うことはできません。S3 にあるテーブルを更新したい場合、クラスターのローカル HDFS ファイルシステム内で一時ファイルを作成し、結果をそのテーブルに書き込んだ後、それらを Amazon S3 にコピーします。
• Amazon S3 にあるリソースにアクセスできます。Amazon EMR にインストールされた Hive のこのバージョンによって、Hive スクリプト内 (例えば、add jar s3://elasticmapreduce/samples/hive-ads/libs/jsonserde.jar) から直接、カスタムマップ用のスクリプトを参照したり、Amazon S3 内のオペレーションや追加ライブラリなどのリソースを削減することができます。
  
  

Q: どのようなタイプの Hive クラスターがサポートされていますか?

Hive では、インタラクティブとバッチという 2 種類のクラスターがサポートされています。インタラクティブモードでは、お客様はクラスターを開始し、マスターノードで直接インタラクティブに Hive スクリプトを実行することができます。一般的に、このモードはアドホックなデータ分析やアプリケーション開発のために使用されます。バッチモードでは、Hive スクリプトは Amazon S3 に保存され、クラスターの開始時に参照されます。一般的に、バッチモードはレポート生成などの繰り返し可能な実行のために使用されます。

Q: Hive クラスターの起動方法について教えてください。

バッチとインタラクティブ両方のクラスターは、AWS マネジメントコンソール、EMR コマンドラインクライアント、または API から開始可能です。Hive クラスターの起動のしかたの詳細については、リリースガイドの Hive のセクションを参照してください。

Q: Hive とPIG はそれぞれどのような場合に使用すべきですか?

Hive および PIG は両方とも、ハイレベルのデータ処理言語に、大規模なデータセットで稼働する複雑なデータタイプのサポートを提供するものです。Hive 言語は SQL の変異形であり、既に SQL やリレーショナルデータベースになじみのある人々にとって使いやすいものとなっています。Hive は分割されたテーブルをサポートしているため、Amazon EMR のクラスターは、テーブル全体のスキャンを行うのではなく、実行されるクエリに関連したテーブルの一部だけを取得することができます。PIG および Hive は両方とも、クエリプランの最適化を行います。PIG はスクリプト全体を通じて最適化可能ですが、Hive クエリは命令文レベルで最適化されます。

最終的に、Hive または PIG のどちらを使用すべきかの選択は、アプリケーションドメインの正確な要件、および実装者やクエリ記述者の好みに委ねられています。

Q: Amazon EMR でサポートされるのは、Hive のどのバージョンですか?

Amazon EMR で使用できる Hive の最新バージョンについては、ドキュメントを参照してください。

Q: 2 つのクラスターから 1 つのテーブルに同時に書き込みを行うことはできますか?

いいえ。Hive はテーブルへの同時書き込みをサポートしていません。同一のテーブルに対する同時書き込み、または書き込みを行っているテーブルからの読み取りは避けるようにしてください。読み取りと書き込み、または書き込みと書き込みを同時に行おうとすると、Hive は非決定的な振る舞いをします。

Q: クラスター間でデータを共有できますか?

はい。スクリプト上部に「create external table」という命令文を記述することにより、Hive スクリプト内で Amazon S3 のデータの読み込みを行うことができます。お客様がアクセスする各外部リソースのために、テーブルステートメントを 1 つ作成する必要があります。

Q: 大規模なクラスターを 1 つ実行してそれを多くのユーザー間で共有すべきですか。それとも多くのより小さなクラスターを実行すべきですか?

Amazon EMR はお客様が両方の方法を使用できるようユニークな機能を提供しています。例えば、1 つの大規模なクラスターは、定期的なバッチ作業を処理するためにより効率的かもしれません。その一方では、アドホックなクエリ問い合わせや、所要時間が多岐にわたる作業が必要な場合は、Amazon S3 で保存される特定のタスク共有データソースに合わせた、いくつかの別々のクラスターの作成が有効かもしれません。 リソースの使用量を最適化するためには、EMR マネージドスケーリングが使用できます。

Q: 自分のローカルファイルシステムにあるスクリプトまたは jar リソースにアクセスすることはできますか?

いいえ。参照できるようにするためには、スクリプトまたは jar を、Amazon S3 またはクラスターのマスターノードにアップロードする必要があります。Amazon S3 にアップロードするために、s3cmd、jets3t、または S3Organizer などのツールを使用することができます。

Q: 複数の Hive クエリを実行する持続的なクラスターを実行できますか?

はい。クラスターを手動終了モードで実行し、Hive ステップ間で終了しないようにすることができます。データロスのリスクを削減するために、Amazon S3 にある重要なデータのすべてを、定期的に持続させることが推奨されています。お客様の作業を定期的に新しいクラスターに転送して、マスターノードの故障から回復するプロセスをテストすることは良い方法です。

Q: 同一のソースデータ上について、複数のユーザーが Hive のステップを実行することができますか?

はい。別々のクラスターで複数のユーザーによって実行されている Hive スクリプトには、Amazon S3 に存在するソースデータを同時にインポートする「create external table」命令文が含まれている可能性があります。

Q: 同一のクラスターで、複数のユーザーがクエリを実行できますか?

はい。バッチモードでは、ステップはシリアライズ化されています。複数のユーザーが、Hive ステップを同一のクラスターに追加することができまが、ステップは順番に実行されます。インタラクティブモードでは、複数のユーザーが同一のクラスターにログオンし、Hive 命令文を同時に実行することが可能です。

Q: 複数の AWS ユーザー間でデータを共有できますか?

はい。こちらで説明されている標準 Amazon S3 共有メカニズムを用いて、データを共有することができます。

Q: Hive は JDBC からのアクセスをサポートしますか?

はい。Hive は JDBC ドライブを提供しています。これはプログラム的に Hive の命令文を実行するために使用することができます。クラスターで JDBC サービスを開始するには、Amazon EMR にあるコマンドラインクライアントにおいて、オプションのパラメータを記述する必要があります。またセキュリティグループが外部接続を許可しないため、SSH トンネルを確立する必要もあります。

Q: EMR AMI でパッケージを更新する手順はどのようなものですか?

EMR 用 Amazon Linux AMI では、初回起動時に Amazon Linux AMI yum リポジトリに接続してセキュリティ更新がインストールされます。カスタム AMI を使用する場合はこの機能を無効にできますが、セキュリティの観点から、無効にすることは推奨しません。

Q: EMR クラスターで自分自身のパッケージを更新できますか?

はい。ブートストラップアクションを使用して、お客様のクラスターのパッケージに対する更新をインストールできます。

Q: Hive を利用して DynamoDB のデータを処理できますか?

はい。DynamoDB テーブルに基づいて、外部 Hive テーブルを定義するだけです。その後、Hive を利用して DynamoDB に保管されたデータを解析し、結果を DynamoDB に読み込むか、または Amazon S3 でアーカイブすることができます。詳細については「デベロッパーガイド」をご参照ください。

Q: Apache Hudi とは何ですか?

Apache Hudi は、増分データ処理とデータパイプラインの開発を簡素化するための、オープンソースのデータ管理フレームワークです。Apache Hudi を使用すると、Amazon S3 のレコードレベルでデータを管理し、変更データキャプチャ (CDC) とストリーミングデータの取り込みを簡素化できます。また、レコードレベルの更新と削除が必要なデータプライバシーのユースケースを処理するフレームワークが提供されます。Apache Hudi が管理するデータは、オープンストレージ形式を使って S3 内に保存されます。また、Presto、Apache Hive、Apache Spark、AWS Glue Data Catalog と統合することで、他の普及したツールを使っての、更新データへのリアルタイムアクセスが可能になります。

Q: どのような場合に Apache Hudi を使用すればよいですか?

Apache Hudi は、S3 でのレコードレベルのデータ管理が必要なユースケースに役立ちます。この機能からメリットが得られる一般的なユースケースとしては、次の 5 つが挙げられます。

1. ユーザーが自身のデータの利用法についての設定を変更した時点で、組織がそのユーザーのデータの削除もしくは更新を行うことを義務付けている、個人情報関連法に準拠しています。Apache Hudi では、S3 に保存されたデータに対するレコードレベルでの挿入、更新、削除処理を、Apache Parquet や Apache Avro といったオープンソースのデータ形式を使用して行えます。
2. リアルタイムのデータストリームを取り込み、エンタープライズシステムからの変更データキャプチャログを適用します。多くの組織では、Apache Hive や Presto のような SQL エンジンが処理や分析の目的でアクセスできるよう、エンタープライズデータウェアハウス (EDW) やオペレーショナルデータストア (ODS) 内のデータには、Amazon S3 での可用性も求めています。Apache Hudi では、変更ログの適用が簡単に行えると同時に、ほぼリアルタイムのデータアクセスが可能です。
3. 到着遅延もしくは間違ったデータの復帰到着が遅れた、もしくは間違っているデータには復帰処理が行われ、既存のデータセットは新規もしくは更新されたレコードを組み入れて更新される必要があります。Apache Hudi では、レコードの既存データセットへの「upsert」を、現状でデータセットが挿入や更新に使用しているフレームワークに則り行うことができます。
4. データセットの変更トラッキングと変更点ロールバック機能の提供Apache Hudi では、データセットへの変更はそれが行われる時点ですべてトラッキングされ、それらは容易にロールバックができます。データセットへの特定の変更を発見し、それを「undo」することが可能です。
5. S3 での管理を簡素化します。各データファイルに効率的なサイズを配置するためには、多数の小さなファイルをモニタリングし、少数の大きなファイルへと書き直すカスタムソリューションを構築する必要があります。Apache Hudi での S3 内データファイルの管理においては、ユーザーが保存に使用したい最適なファイルサイズを定義するだけで、効率的なサイズのファイルへのマージが、Hudi により自動的に行われます。
6. ターゲット Hudi データセットに差分を書き込みます。Hudi のデータセットは段階的にプルされます。つまり、特定の時点移行に更新および作成された行のみ (そしてそのすべて) を取得することが可能です。

Q: Apache Hudi のデータセットの作成はどのように行いますか?

Apache Hudi でのデータセットは Apache Spark を使用して作成します。Apache Spark DataFrame を記述するのと同じ簡単さでデータセットの作成ができます。Apache Hudi データセットは、AWS Glue Data Catalog か Hive メタストアに保存することで、データ抽出や Apache Hive と Presto との統合を容易にすることも可能です。

Q: Apache Hudi はどのようにデータ管理を行っていますか?

Apache Hudi を使いデータセットを作成する際に、そのデータセットがどのようなタイプのアクセスパターンに最適化されるかを選択します。読み出しの回数が特に多いユースケースでは、データ管理戦略に “Copy on Write” を選択することで、データセットに対する頻度の読み出に最適化できます。この戦略では、データの編成に列指向ストレージ形式を使用して、データに更新が書き込まれた時点で既存のものと更新内容をマージします。書き込みの回数が特に多いワークロードに対しては、Apache Hudi の “Merge on Read” データ管理戦略を使用します。この戦略では、列指向と行指向のストレージ形式が組合せて使用されます。更新は行ベースのストレージ形式によりファイル内に添付され、既存データとのマージは読み出し時に実行することで、最終的な結果が出力されます。

Q: Apache Hudi データセットへの書き込み方法を教えてください

Apache Hudi データセットの変更には Apache Spark を使用します。Apache Spark により、Apache Hudi のデータセットの操作に Spark DataSource API を使用して、書き込みと読み出しが行えるようになります。新たに追加されたデータ、もしくは更新された既存データを保持している DataFrame にも、同様の DataSource API を使用して書き込むことができます。また、お客様は、Hudi DeltaStreamer ユーティリティもご利用になれます。

Q: Apache Hudi データセットからの読み出し方法を教えてください

データの読み出しには、Apache Spark、Apache Hive、Presto、Amazon Redshift Spectrum、もしくは Amazon Athena のいずれかを使用します。データセット作成時のオプションとして、そのデータセットのメタデータの公開先に、AWS Glue Data Catalog か Hive メタストアのどちらかを選択できます。メタデータ公開先にメタストアを選択した場合、データセットは通常のテーブルのようになり、Apache Hive や Presto からクエリできるようになります。

Q: Apache Hudi を使用する上でどのような考慮事項と制限がありますか?

Apache Hudi on Amazon EMR を使う上での、考慮すべき点と制限事項に関する詳細については、Amazon EMR ドキュメントをご参照ください。

Q: 既存データは Apache Hudi でどのように機能しますか?

既存のデータを Apache Hudi で管理する必要が生じた場合でも、Apache Parquet データであれば Apache Hudi on Amazon EMR が提供するインポートツールにより、簡単に Apache Hudi データセットに変換できます。あるいは、Hudi DeltaStreamer ユーティリティか Apache Spark を使用して、既存データを Apache Hudi に書き換えることも可能です。

Q: Impala とは何ですか?

Impala は SQL 構文を使用したインタラクティブなアドホッククエリを行う Hadoop エコシステムのオープンソースツールです。このツールでは、MapReduce の代わりに、従来のリレーショナルデータベース管理システム (RDBMS) で用いられる超並列処理 (MPP) エンジンに類似した MPP が活用されます。このアーキテクチャでは、HDFS または HBase テーブルのデータを非常にすばやくクエリできるほか、多様なデータ型を処理するだけでなく実行時にスキーマを提供する Hadoop の機能を活用することができます。このため、Impala を利用して、インタラクティブでレイテンシーが短い分析を行うことができます。また、Impala は Hive メタストアを使用して、パーティション名およびデータ型などの入力データに関する情報を保管します。さらに、Amazon EMR で Impala を使用するには、AMI で Hadoop 2.x 以降を実行する必要があります。Impala の詳細については、ここをクリックしてください。

Q: Amazon EMR で稼働する Impala でできることは何ですか?

Amazon EMR と Hive を併用する場合と同様に、Amazon EMR と Impala を併用すると、SQL 構文を使用した、洗練されたデータ処理アプリケーションを実装できます。ただし、Impala は、一部のユースケースで、より高速に実行されるよう作成されています (下記を参照)。Amazon EMR を使用すれば、Impala を信頼性の高いデータウェアハウスとして使用して、データ分析、モニタリング、ビジネスインテリジェンスなどのタスクを実行することができます。ユースケースには以下の 3 つがあります。

• アドホッククエリを実行するために、長期間稼働するクラスターで Hive の代わりに Impala を使用する場合。Impala はインタラクティブクエリを数秒に短縮するので、高速な調査を行うための優れたツールです。バッチの MapReduce ワークフローと同じクラスターで Impala を実行したり、Hive および Pig とともに長時間稼働する分析クラスターで Impala を使用したり、あるいは Impala のクエリ用に特別に調整されたクラスターを作成することができます。
• 一時的な Amazon EMR クラスターでバッチ ETL ジョブ用に Hive の代わりに Impala を使用する場合。Impala は、Hive よりも、多くのクエリで高速であり、それらのワークロードに対してより高いパフォーマンスを提供します。Hive と同様に Impala も SQL を使用しているため、クエリを Hive から Impala に簡単に変更できます。
• サードパーティ製のビジネスインテリジェンスツールと一緒に Impala を使用する場合。クライアントの ODBC または JDBC ドライバーをクラスターと接続し、パワフルな可視化ツールおよびダッシュボードのエンジンとして Impala を使用します。

バッチ Impala クラスターもインタラクティブな Impala クラスターも Amazon EMR で作成できます。例えば、長時間実行する Amazon EMR クラスターで、アドホックでインタラクティブなクエリのために Impala を実行することも、高速の ETL ワークフローのために一時的な Impala クラスターを使用することもできます。

Q: Impala は従来の RDBMS とどのように異なりますか?

従来のリレーショナルデータベースシステムは、トランザクションの意味とデータベースのアトミック性、整合性、分離、および堅牢性 (ACID) の各特性を提供してきました。また、テーブルをインデックス化およびキャッシュして少量のデータを非常に高速に読み出したり、少量データをすばやく更新したり、あるいは参照整合性制約を適用することができます。通常、従来のリレーショナルデータベースシステムは単一の大規模マシンで稼働し、ユーザー定義された複雑なデータ型に対する処理まではサポートしません。Impala は RDBMS にあるのと似た分散クエリシステムを使用しますが、HDFS に保存されているデータをクエリし、Hive メタストアを使用して入力データに関する情報を保管します。Hive の場合と同様に、クエリのスキーマは実行時に提供されるため、簡単にスキーマ変更を行うことができます。また、Impala はさまざまな複合データ型もクエリできるほか、ユーザー定義関数も実行できます。ただし、Impala はメモリ内でデータを処理するため、クラスターのハードウェア制限を理解し、クエリのパフォーマンスを最適化する必要があります。

Q: Impala は Hive とどのように異なりますか?

Impala が超並列処理 (MPP) エンジンを使用して SQL クエリを実行するのに対し、Hive は MapReduce を使用して SQL クエリを実行します。Impala では、Hive と違って MapReduce ジョブを作成するオーバーヘッドがかからないため、Hive よりクエリ時間が短縮されます。ただし、Impala は大量のメモリリソースを使用するため、クラスターで利用可能なメモリによって、クエリに使用できるメモリ量が制約されます。Hive はこのようには制限されていないため、同じハードウェアでより多くのデータセットを問題なく処理することができます。一般に、高速のインタラクティブなクエリには Impala の使用が適するのに対し、Hive は大規模なデータセットに対する ETL ワークロードに適しています。Impala は時間短縮を目的として開発されているためアドホックの調査には最も適していますが、負荷の大きいクエリを実行する場合、つまり非常に大きなデータセットを処理する場合には大量のメモリを必要とします。このような制限があるため、完了することの方が時間短縮よりも先決であるワークロードの場合には Hive を使用することをお勧めします。Impala と Hive の間のパフォーマンスベンチマークについては、ここをクリックしてください。

Q: Hadoop 1 を使用できますか?

いいえ、Impala には Hadoop 2 が必要であり、AMI が Hadoop 1.x を稼働しているクラスターでは稼働しません。

Q: Impala クラスターにはどのインスタンスタイプを使用する必要がありますか?

Impala を使用して最良の結果を得るには、クラスターにはメモリが最適化されたインスタンスを使用することをお勧めします。ただし、スタンダードインスタンスタイプも使用する場合は、Hive よりも高いパフォーマンスが示されることを私たちは示してきました。データセット型とクエリタイプに対してクラスターで必要となるメモリリソースを適切に見積もるには、Amazon EMR 開発者ガイドの「Performance Testing and Query Optimization」セクションをお読みになることをお勧めします。圧縮タイプ、パーティション、およびクエリ自体 (結合の数、結果サイズなど) はすべて、必要となるメモリの構成要素をなります。Impala クエリに必要となるメモリなどのリソースは、EXPLAIN ステートメントを使用して見積もることができます。

Q: クエリでメモリが不足したらどうなりますか?

メモリが不足した場合、クエリは失敗し、影響を受けるノードにインストールされている Impala デーモンはシャットダウンします。続いて、Amazon EMR がそのノードでデーモンを再開し、Impala が別のクエリを実行できるようにします。シャットダウンしたのはノード全体でなく、ノードで稼働していたデーモンのみであるため、ノードの HDFS のデータは依然として利用可能です。Impala を使用したアドホック分析の場合、クエリ時間は通常 1 分未満の値として測定できます。このため、クエリが失敗した場合でも、問題をすみやかに発見し、すぐに新しいクエリを送信できます。

Q: Impala はユーザー定義関数をサポートしていますか?

はい、Impala はユーザー定義関数 (UDF) をサポートしています。Impala 固有の UDF は Java または C++ で記述できます。Hive 用に作成された UDF やユーザー定義集計関数に Impala 用の変更を加えることもできます。Hive UDF の詳細については、ここをクリックしてください。

Q: Impala がクエリするデータはどこに保存されていますか?

Impala では、HDFS テーブルや HBase テーブルでデータのクエリが行われます。

Q: クラスターで Impala と MapReduce を同時に実行できますか?

はい、Impala と MapReduce を同時に実行できるマルチテナントクラスターをセットアップすることができます。ただし、各アプリケーションには、Hadoop 2.x で YARN を使用してリソース (メモリ、ディスク、および CPU) を割り当てる必要があります。割り当てるリソースは、各アプリケーションで実行を予定しているジョブのニーズによって決定する必要があります。

Q: Impala では ODBC や JDBC のドライバーがサポートされていますか?

Impala は、ODBC ドライバーを実行できるだけでなく、JDBC によって接続されるサードパーティ製ツールにも有効なエンジンです。Impala クライアントの JDBC ドライバーは、http://elasticmapreduce.s3.amazonaws.com/libs/impala/1.2.1/impala-jdbc-1.2.1.zip からダウンロードおよびインストールすることができます。ビジネスインテリジェンスツールをインストールしたクライアントコンピュータのポート 21050 で SSH または VPN を使用して、Impala クラスターのマスターノードに JDBC ドライバーを接続します。詳細については、Open an SSH Tunnel to the Master Node を参照してください。

Q: Apache Pig とは何ですか?

Pig は Hadoop 上で稼働するオープンソースの分析パッケージです。Pig は Pig Latin と呼ばれる SQL に似た言語によって操作されます。これにより、ユーザーは Amazon S3 に保存されているデータソースの構築、要約、クエリを行うことができます。SQL に類似した操作と同様、Pig Latin もまた、map/reduce 関数および複雑で拡張可能なユーザー定義のデータタイプのために、第一級のサポートを行います。この能力により、テキスト文書やログファイルといった、複雑で構造化されていないデータソースの処理が可能となります。Pig により、Java で書かれ、Amazon S3 のストレージに配置されたユーザー定義の関数を利用した、ユーザーによる拡張が可能となります。

Q: Amazon EMR で稼働する Pig でできることは何ですか?

Amazon EMR で Pig を使用すれば、おなじみの SQL と似た言語を持つ洗練されたデータ処理アプリケーションと、Amazon EMR で利用できる使いやすいツールを実装することができます。Amazon EMR を使用すれば、Pig アプリケーションを信頼性の高いデータウェアハウスにして、データ分析、モニタリング、ビジネスインテリジェンスなどのタスクを実行することができます。

Q: Amazon EMR で稼働する Pig を開始するにはどうすればよいですか?

こちらのドキュメントをご覧になるのが最も良い方法です。

Q: Amazon EMR に固有の Pig の新機能はありますか?

はい。Amazon EMR と共に使用すれば Pig をさらに強力にする 3 つの新機能があります。これは次のとおりです。

a/ 複数のファイルシステムへのアクセス。デフォルトでは、入力、出力、一時データのために、HDFS ストアまたは S3 バケットである、1 つのリモートファイルシステムのみに対して、Pig のジョブはアクセスすることができます。EMR では、拡張された Pig を使用して各ジョブから、常に必要なだけ多くのファイルシステムにアクセスが可能です。この利点の 1 つは、一時的な内部ジョブのデータが、常にローカルの HDFS に保存されるようになり、パフォーマンスの改善につながるということです。

b/ S3 からのリソースの読み込み。例えば「REGISTER s3:///my-bucket/piggybank.jar」のように、S3 ファイルシステムからカスタムの JAR やスクリプトが取得できるように、Amazon EMR は Pig を拡張しました。

c/ 文字列と日付時間処理のための追加 Piggybank 関数。

Q: どのようなタイプの Pig クラスターがサポートされていますか?

Pig では、インタラクティブとバッチという 2 種類のクラスターがサポートされています。インタラクティブモードでは、お客様はクラスターを開始し、マスターノード上で直接インタラクティブに Pig スクリプトを実行することができます。一般的に、このモードはアドホックなデータ分析やアプリケーション開発のために使用されます。バッチモードでは、Pig スクリプトは Amazon S3 に保存され、クラスターの開始時に参照されます。一般的に、バッチモードはレポート生成などの繰り返し可能な実行のために使用されます。

Q: Pig クラスターの起動方法について教えてください。

バッチとインタラクティブ両方のクラスターは、AWS マネジメントコンソール、EMR コマンドラインクライアント、または API から開始可能です。

Q: Amazon EMR でサポートされているのは Pig のどのバージョンですか?

Amazon EMR では複数のバージョンの Pig がサポートされています。

Q: 2 つのクラスターから同時に S3 バケットに書き込みを行うことはできますか?

はい。2 つの同時発生しているクラスターから、同一のバケットに書き込みを行うことができます。

Q: クラスター間で S3 の入力データを共有できますか?

はい。2 つの同時発生しているクラスターから、S3 の同一データを読み込むことができます。

Q: 複数の AWS ユーザー間でデータを共有できますか?

はい。ここ http://docs.amazonwebservices.com/AmazonS3/latest/index.html?S3_ACLs.html で説明されている標準 Amazon S3 共有メカニズムを用いて、データを共有することができます。

Q: 大規模なクラスターを 1 つ実行してそれを多くのユーザー間で共有すべきですか。それとも多くのより小さなクラスターを実行すべきですか?

Amazon EMR はお客様が両方の方法を使用できるようユニークな機能を提供しています。例えば、1 つの大規模なクラスターは、定期的なバッチ作業を処理するためにより効率的かもしれません。その一方では、アドホックなクエリ問い合わせや、所要時間が多岐にわたる作業が必要な場合は、Amazon S3 で保存される特定のタスク共有データソースに合わせた、いくつかの別々のクラスターの作成が有効かもしれません。

Q: 自分のローカルファイルシステムにあるスクリプトまたは jar リソースにアクセスすることはできますか?

いいえ。参照できるようにするためには、スクリプトまたは jar を、Amazon S3 またはクラスターのマスターノードにアップロードする必要があります。Amazon S3 にアップロードするために、s3cmd、jets3t、または S3Organizer などのツールを使用することができます。

Q: 複数の Pig クエリを実行する持続的なクラスターを実行できますか?

はい。クラスターを手動終了モードで実行し、Pig ステップ間で終了しないようにすることができます。データロスのリスクを削減するために、Amazon S3 にある重要なデータのすべてを、定期的に持続させることが推奨されています。お客様の作業を定期的に新しいクラスターに転送して、マスターノードの故障から回復するプロセスをテストすることは良い方法です。

Q: Pig は JDBC からのアクセスをサポートしますか?

Pig は JDBC 経由のアクセスをサポートしません。 

Q: Apache HBase とは何ですか?

HBase は、Google の BigTable に基づいて設計されたオープンソースのリレーショナルでない分散データベースです。Apache Software Foundation の Hadoop プロジェクトの一部として開発され、Hadoop Distributed File System (HDFS) 上で動作し、Hadoop に BigTable のような機能を提供します。HBase では、列ベースの圧縮と保存を使用することにより、耐障害性に優れた効率的な方法で大量の疎データを保存できます。さらに、HBase ではデータがディスクではなくメモリ内にキャッシュされるため、高速なデータの参照が可能になっています。HBase は、シーケンシャル書き込み操作用に最適化されており、バッチ挿入、更新、および削除処理も非常に効率的です。HBase は Hadoop とシームレスに連携し、ファイルシステムを共有し、Hadoop ジョブへの直接入出力として機能します。また、HBase は Apache Hive と統合されており、HBase テーブルでの SQL のようなクエリ、Hive ベースのテーブルとの結合、Java Database Connectivity (JDBC) もサポートします。Apache HBase の詳細はこちらを参照してください。

Q: Amazon EMR に固有の HBase の新機能はありますか?

Amazon EMR では、HBase on Amazon S3 を使用して、クラスターの HBase ルートディレクトリとメタデータを Amazon S3 に直接保存できます。同時に、リードレプリカとスナップショットを作成することも可能です。詳細については、ドキュメントを参照してください。

Q: HBase のどのバージョンが Amazon EMR でサポートされていますか?

Amazon EMR でサポートされる最新の HBase バージョンについては、こちらを参照してください。

Q: Kinesis 用 EMR コネクタは何ができますか?

このコネクタにより、EMR は Kinesis ストリームから直接データの読み取りとクエリを実行できるようになります。Hive、Pig、MapReduce、Hadoop Streaming、Cascading といった既存の Hadoop エコシステムツールを使用して Kinesis ストリームのバッチ処理を実行できます。

Q: Kinesis 用 EMR コネクタによって、以前は不可能だったどのようなことが実現可能になりますか?

Kinesis ストリームからのデータの読み取りと処理には、独立したストリーム処理アプリケーションの作成、デプロイおよびメンテナンスが必要でした。これには時間と労力が必要です。しかし、このコネクタを使用すると、簡単な Hive または Pig スクリプトを書くだけで Kinesis ストリームの読み取りと分析を開始できます。つまり、SQL を使用して Kinesis ストリームを分析できます。 当然ながら、他の Hadoop エコシステムツールも使用できます。新たな一連の処理アプリケーションを開発またはメンテナンスする必要はありません。

Q: この機能はどのようなユーザーにとって便利ですか?

この統合は次のようなタイプのユーザーにとって便利です。

• 包括的な Hadoop エコシステムツールセットを利用して Kinesis ストリームを分析することに関心がある Hadoop ユーザー。
  
• Kinesis データのストリーム処理と ETL の稼働開始のための簡単な方法を探している Kinesis ユーザー。
  
• SQL (Hive 経由) のような使い慣れたツールや、Pig のようなスクリプト言語を使用した、Kinesis ストリームのデータに対するアドホックな分析の実行を希望するビジネスアナリストおよび IT 専門職。
  

Q: この統合のユースケースにはどのようなものがありますか?

この統合で可能になる代表的なユースケースを次に示します。

• ストリーミングログ分析: ストリーミングのウェブログを分析して、リージョン別、ブラウザ別、およびアクセスドメイン別に、数分ごとの上位 10 件のエラータイプのリストを生成できます。
  
• 複雑なデータ処理ワークフロー: Kinesis ストリームと、S3、Dynamo DB テーブル、および HDFS に保存したデータを結合できます。Kinesis のクリックストリームデータと DynamoDB テーブルに保存されている広告キャンペーン情報を結合するクエリを作成し、特定のウェブサイトに表示される最も効果的な広告カテゴリを特定できます。
  
• アドホッククエリ: Kinesis から HDFS に定期的にデータを読み込み、ローカルの Impala テーブルとして使用可能にすることで、高速かつインタラクティブな分析クエリを実行できます。
  

Q: このコネクタを使用するために必要な EMR AMI のバージョンは何ですか?

EMR の AMI バージョン 3.0.4 以降をご使用ください。

Q: このコネクタはスタンドアロン型のツールですか?

いいえ。これは、Hadoop の Amazon ディストリビューションの組み込みコンポーネントであり、EMR AMI バージョン 3.0.4 以降に含まれます。お客様は AMI バージョン 3.0.4 以降を含むクラスターを起動するだけで、この機能を使い始めることができます。

Q: EMR が Kinesis ストリームから読み取りを行うために必要なデータフォーマットは何ですか?

EMR Kinesis 統合はデータフォーマットに固有のものではありません。任意のフォーマットのデータを読み取ることができます。個別の Kinesis レコードは、任意の Hadoop MapReduce フレークワークを使用して読み取ることができるスタンダードレコードとして Hadoop に渡されます。Hive、Pig、Cascading のような個別のフレームワークには、シリアル化と逆シリアル化に役立つ組み込みコンポーネントがあり、開発者はカスタムコードを実装することなくさまざまなフォーマットのデータに対するクエリを簡単に実行できます。たとえば Hive では、テーブル定義時に適切な Hive SerDe を指定することにより、JSON ファイル、XML ファイルおよび SEQ ファイルからデータを読み取ることができます。Pig には Loadfunc/Evalfunc と呼ばれる同様のコンポーネントがあり、Cascading には Tap と呼ばれる同様のコンポーネントがあります。Hadoop のユーザーは、フォーマット固有のコードを作成する必要なしで、Hadoop アダプタの包括的なエコシステムを活用できます。これらのいずれかのツールでドメイン固有のデータを読み取るために、カスタマイズした逆シリアル化フォーマットを実装することもできます。

Q: EMR で Hive を使用して Kinesis ストリームを分析するには、どうすればよいですか?

Kinesis ストリームを参照するテーブルを作成します。その後、Hive の他のテーブルと同じようにそのテーブルを分析できます。詳細については、チュートリアルのページを参照してください。

Q: Hive を使用して、Kinesis ストリームデータと他のデータソースを結合するクエリを作成する方法を教えてください。

最初に、Kinesis ストリームを参照するテーブルを作成します。Hive テーブルを作成した後、そのテーブルを、Amazon S3、Amazon Dynamo DB、HDFS などの他のデータソースにマッピングしているテーブルに結合します。これにより、実質的に Kinesis ストリームのデータが他のデータソースに結合されます。

Q: この統合を使用できるのは Hive だけですか?

いいえ。Hive、Pig、MapReduce、Hadoop Streaming、および Cascading を使用できます。

Q: Kinesis ストリームで実行するスケジュールを設定したジョブをセットアップするにはどうすればよいですか?

EMR Kinesis 入力コネクタには、Cron などの従来のスケジュール管理エンジンでスケジュールを設定した定期的なジョブの設定、管理に役立つ機能があります。例えば、N 分間隔で実行される Hive スクリプトを開発できます。ジョブの設定パラメータで、ジョブの論理名を指定できます。論理名は、ジョブの個々のインスタンスが同じ定期スケジュールのメンバーであることを EMR Kinesis 入力コネクタに知らせるラベルです。論理名を使用することでプロセスは反復計算を活用できます。反復計算についてはこの後に説明します。

MapReduce はバッチ処理フレームワークであるため、EMR を使用して Kinesis ストリームを分析するには、連続ストリームを複数のバッチに分割します。各バッチは反復計算と呼ばれます。各反復計算には 0 から始まる番号が付されます。各反復計算の境界は、開始シーケンス番号と終了シーケンス番号によって定義されます。反復計算は EMR によって順次処理されます。

いずれかの処理の試行が失敗した場合、EMR Kinesis 入力コネクタは論理名の範囲内で反復計算の既知の開始シーケンス番号から反復計算を再試行します。この機能は、同一の反復計算で連続して試行が失敗した場合、Kinesis ストリームから前回の試行と正確に同じ入力レコードを受け取るようにします。これにより、Kinesis ストリームのべき等 (整合性のある) 処理が保証されます。

論理名と反復計算は、それぞれの Hadoop ツールで実行時パラメータとして指定できます。たとえば、チュートリアルの「Running queries with checkpoints」のセクションで、コード例はスケジュールが設定された Hive クエリを示しています。このクエリは、クエリの論理名を指定し、連続するジョブ実行に合わせて反復計算を増分します。

さらに、サンプルの cron スケジュール設定スクリプトがチュートリアルで提供されています。

Q: 論理名と反復計算のメタデータはどこに保存されていますか?

EMR Kinesis 入力コネクタがスケジュール設定された定期ワークフローで動作するためのメタデータは、Amazon DynamoDB に保存されています。Amazon Dynamo DB テーブルをプロビジョニングし、そのテーブルを Hadoop ジョブの入力パラメータとして指定する必要があります。この統合を有効にするために、テーブルに対して適切な IOPS を設定することが重要です。Amazon Dynamo DB テーブルの設定の詳細については、ご利用開始にあたってのチュートリアルを参照してください。

Q: 反復計算処理が失敗した場合、どうなりますか?

反復計算識別子はユーザーが指定する値で、Kinesis ストリーム内の特定の境界 (開始シーケンス番号と終了シーケンス番号) にマップされます。これらの境界に対応したデータが、MapReduce ジョブの Map フェーズに読み込まれます。このフェーズはフレームワークによって管理され、ジョブが失敗した場合は自動的に再実行されます (デフォルトでは 3 回)。この再試行がすべて失敗した場合でも、正常に終了した最後のデータ境界または過去のデータ境界から処理を再試行するためのオプションがあります。この動作は、処理中に kinesis.checkpoint.iteration.no パラメータを指定することによって制御します。Hadoop エコシステムのさまざまなツールでこの値を設定する方法についての詳細は、ご利用開始にあたってのチュートリアルを参照してください。

Q: 1 つの反復計算で複数のクエリを実行できますか?

はい。後続の処理で kinesis.checkpoint.iteration.no パラメータを設定することによって、以前に実行した反復計算を指定できます。実装により、同一の反復計算での後続クエリの実行に、Kinesis ストリームから以前の実行と正確に同じ入力レコードが渡されることが保証されます。

Q: 反復計算で Kinesis ストリームからのレコードが有効期限切れになった場合、どうなりますか?

反復計算の開始シーケンス番号または終了シーケンス番号あるいはその両方が、Kinesis ストリームで有効期限切れになっているレコードに属している場合、Hadoop ジョブは失敗します。別の論理名を使用して、Kinesis ストリームの先頭からデータを処理することが必要になります。

Q: EMR から Kinesis ストリームにデータをプッシュできますか?

いいえ。EMR Kinesis コネクタは現在のところ Kinesis ストリームへのデータの書き戻しをサポートしていません。

Q: Kinesis 用 EMR Hadoop 入力コネクタで連続ストリーム処理は可能ですか?

Hadoop MapReduce フレームワークはバッチ処理システムです。したがって、連続クエリはサポートされていません。ただし、Twitter Storm や Spark Streaming のような Hadoop エコシステムフレームワークが出現してきており、開発者はそれらを使用して連続ストリーム処理のためのアプリケーションを構築できます。Kinesis 用 Storm コネクタは GitHub でこちらから利用できます。また、Spark Streaming を EMR にセットアップして連続クエリを実行する方法を説明したチュートリアルをこちらから参照できます。

さらに、開発者は Kinesis クライアントライブラリを使用してリアルタイムのストリーム処理アプリケーションを開発できます。カスタム Kinesis アプリケーションの開発に関する詳細情報については、こちらから Kinesis ドキュメントを参照してください。

Q: 別の AWS アカウントで管理されている Kinesis ストリームを読み取るためのアクセス認証情報を指定できますか?

はい。Kinesis ストリームを所有しているアカウントの適切なアクセス認証情報を指定することにより、別の AWS アカウントからストリームを読み取ることができます。デフォルトでは、Kinesis コネクタはクラスター作成時に指定されたユーザー提供のアクセス認証情報を使用します。その認証情報を無効にして、他の AWS アカウントのストリームにアクセスすることができます。そのためには、kinesis.accessKey および kinesis.secretKey パラメータを設定します。次の例は、Hive および Pig で kinesis.accessKey および kinesis.secretKey パラメータを設定する方法を示しています。

Hive のコード例:
...
STORED BY
'com.amazon.emr.kinesis.hive.KinesisStorageHandler'
TBLPROPERTIES(
"kinesis.accessKey"="AwsAccessKey",
"kinesis.secretKey"="AwsSecretKey",
);

Pig のコード例:
…
raw_logs = LOAD 'AccessLogStream' USING com.amazon.emr.kinesis.pig.Kin
esisStreamLoader('kinesis.accessKey=AwsAccessKey', 'kinesis.secretKey=AwsSecretKey'
) AS (line:chararray);

Q: 単一の Kinesis ストリームで複数の並行クエリを実行できますか? パフォーマンスへの影響はありますか?

はい。各クエリに別々の論理名を使用することで、同じストリームで複数の並行クエリを実行できます。ただし、Kinesis ストリーム内のシャードからの読み取りは、2 MB/秒の速度制限の対象になります。そのため、同じストリームで N 個の並行クエリを実行している場合、各クエリはストリーム上のシャードごとに約 (2/N) MB/秒の送信速度になります。これにより、処理速度が低下することがあり、場合によってはクエリが失敗する可能性もあります。

Q: EMR で複数の Kinesis ストリームを結合して分析できますか?

はい。例えば Hive で、2 つの異なる Kinesis ストリームにマッピングしている 2 つのテーブルを作成し、それらのテーブル間に結合を作成することができます。

Q: EMR Kinesis コネクタは、マージイベントや分割イベントのような Kinesis スケーリングイベントを処理しますか?

はい。実装により分割イベントとマージイベントが処理されます。Kinesis コネクタは個々の Kinesis シャード (Kinesis ストリーム内の論理的なスケール単位) を Hadoop MapReduce マップタスクに関連付けます。反復計算の論理的な期間中にストリーム内に存在する個々の一意のシャードは、厳密に 1 個のマップタスクになります。シャードの分割イベントまたはマージイベントにおいて、Kinesis が新しい一意のシャード ID をプロビジョニングします。その結果、MapReduce フレームワークは、より多くのマップタスクを Kinesis から読み取るようにプロビジョニングします。このすべてがユーザーには透過的に行われます。

Q: ストリームに「無音」の期間があった場合はどうなりますか?

実装では、kinesis.nodata.timeout というパラメータを設定できます。例えば、kinesis.nodata.timeout が 2 分に設定されていて、Hive クエリを 10 分間隔で実行するシナリオを考えてみます。また、前回の反復計算 (10 分前) 以降にデータがストリームに書き込まれているとします。ただし、現時点で新しいレコードは着信していません。つまり、ストリームに無音が存在します。この場合、クエリの現在の反復計算が呼び出されると、Kinesis コネクタは新しいレコードが着信していないことを認識します。コネクタは 2 分間ストリームへのポーリングを続け、その間にレコードが着信しない場合は、ポーリングを停止して、ストリームの現在のバッチで既に読み取られているレコードのみを処理します。ただし、kinesis.nodata.timeout の間隔がタイムアウトする前に新しいレコードが到着し始めた場合、コネクタは kinesis.iteration.timeout というパラメータに対応する間隔だけ続けて待機します。これらのパラメータの設定方法については、チュートリアルを参照してください。

Q: 反復計算ごとに連続して失敗するクエリをデバッグするには、どうすればよいですか?

処理エラーの場合は、Hadoop ジョブのデバッグに現在使用されているのと同じツールを使用できます。Amazon EMR ウェブコンソールも、エラーログを特定してアクセスするのに役立ちます。EMR ジョブのデバッグの詳細については、こちらを参照してください。

Q: アクセス権がない DynamoDB テーブルを指定すると、どうなりますか?

ジョブは失敗し、ジョブのエラーログに例外が表示されます。

Q: ジョブにエラーが発生していなくても DynamoDB に対するチェックポイントの取得が失敗した場合は、どうなりますか?

ジョブは失敗し、ジョブのエラーログに例外が表示されます。

Q: Kinesis ストリームから EMR への読み取りのスループットを最大化するには、どうすればよいですか?

Kinesis ストリームのスループットは、使用するインスタンスサイズおよび Kinesis ストリームのレコードサイズが大きいほど、大きくなります。この機能を使用するためには、マスターノードおよびコアノードの両方に m1.xlarge 以上を使用することをお勧めします。 

Q: Amazon EMR のサービスレベルアグリーメントとな何ですか?

サービスレベルアグリーメントを参照してください。

Q: Amazon EMR サービスレベルアグリーメントでは何が保証されますか?