# ワークロード管理 Athena のワークグループ、キャパシティ管理、パフォーマンスチューニング、圧縮サポート、タグ、サービスクォータ機能を使用してワークロードを管理できます。 **Topics** + [ワークグループを使用してクエリのアクセスとコストを制御する](workgroups-manage-queries-control-costs.md) + [クエリ処理キャパシティを管理する](capacity-management.md) + [Athena のパフォーマンスを最適化する](performance-tuning.md) + [Athena で圧縮を使用する](compression-formats.md) + [Athena リソースにタグ付けする](tags.md) + [サービスクォータ](service-limits.md) # ワークグループを使用してクエリのアクセスとコストを制御する Athena ワークグループを使用して、ワークロードの分離、チームアクセスの制御、設定の強制、クエリメトリクスの追跡、コストの制御を行えます。 **ワークロードを分離する** ワークグループを使用してワークロードを分離できます。たとえば、2 つの独立したワークグループを、1 つはレポート生成などの自動スケジュールされたアプリケーションのため、もう 1 つはアナリストによるアドホック使用のために作成できます。 **チームによるアクセスの制御** ワークグループは IAM リソースとして機能するため、リソースレベルのアイデンティティベースのポリシーを使用して、ワークグループにアクセスしてクエリを実行できるユーザーを制御できます。組織内の 2 つの異なるチームのクエリを分離するには、チームごとに個別のワークグループを作成します。各ワークグループには、アカウント内のすべてのクエリではなく、そのワークグループ内のクエリについて独自のクエリ履歴と保存されたクエリのリストがあります。詳細については、「[IAM ポリシーを使用してワークグループのアクセスを制御する](workgroups-iam-policy.md)」を参照してください。 **設定を強制する** オプションで、ワークグループで実行されるすべてのクエリに対して、同じワークグループ全体の設定を適用できます。これらの設定には、Simple Storage Service (Amazon S3) にあるクエリ結果、予測されるバケット所有者、暗号化、クエリ結果バケットに書き込まれたオブジェクトのコントロールが含まれます。詳細については、「[[Override client-side settings (クライアント側設定の上書き)]](workgroups-settings-override.md)」を参照してください。 **クエリメトリクスの追跡、クエリイベント、コストの管理** 各 Athena ワークグループのクエリメトリクス、クエリイベント、コストを追跡するには、次の機能を使用できます。 + **クエリメトリクスの発行** — ワークグループのクエリメトリクスを CloudWatch に発行します。Athena コンソールでは、各ワークグループのクエリメトリクスを表示できます。CloudWatch では、カスタムダッシュボードを作成して、これらのメトリクスにしきい値およびアラームを設定できます。詳細については、「[Athena で CloudWatch クエリメトリクスを有効にする](athena-cloudwatch-metrics-enable.md)」および「[CloudWatch による Athena クエリメトリクスのモニタリング](query-metrics-viewing.md)」を参照してください。 + **Athena 使用状況メトリクスのモニタリング** – CloudWatch グラフとダッシュボードで現在のサービス使用状況を表示し、アカウントのリソースをどのように使用しているかを確認します。詳細については、「[CloudWatch による Athena 使用状況メトリクスのモニタリング](monitoring-athena-usage-metrics.md)」を参照してください。 + **クエリイベントのモニタリング** – Amazon EventBridge を使用して、クエリの状態に関するリアルタイムの通知を受信します。詳細については、「[EventBridge を使用して Athena クエリ イベントをモニタリングする](athena-events.md)」を参照してください。 + **データ使用量制御の設定** – Athena では、クエリごとおよびワークグループごとのデータ使用量の制御を設定できます。Athena は、クエリが指定されたしきい値を超えたときにクエリをキャンセルするか、ワークグループのしきい値を超えたときに Amazon SNS アラームをアクティブ化します。詳細については、「[クエリごとおよびワークグループごとのデータ使用量の制御を設定する](workgroups-setting-control-limits-cloudwatch.md)」を参照してください。 + **コスト配分タグの使用** – 請求およびコストマネジメントコンソールを使用して、ワークグループにコスト配分タグを付けます。ワークグループでのクエリの実行に関連するコストが、対応するコスト配分タグによりコストと使用状況レポートに表示されます。詳細については、「*AWS Billingユーザーガイド*」の「[Using user-defined cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)」をご参照ください。 + **キャパシティ予約の使用** – 指定したデータ処理ユニットの数でキャパシティ予約を作成し、1 つ以上のワークグループを予約に追加できます。詳細については、「[クエリ処理キャパシティを管理する](capacity-management.md)」を参照してください。 AWS ビッグデータブログ投稿「[Amazon Athena ワークグループを使用したクエリの分離とコストの管理](https://aws.amazon.com/blogs/big-data/separating-queries-and-managing-costs-using-amazon-athena-workgroups/)」も参照してください。この記事では、Athena ワークグループを使用してワークロードを分離し、ユーザーアクセスを制御し、クエリの使用量とコストを管理する方法が紹介されています。 **注記** Amazon Athena リソースに Amazon SageMaker Unified Studio (プレビュー) 内でアクセスできるようになりました。これにより、組織のデータにアクセスし、最適なツールで対処することができます。保存されたクエリの Athena ワークグループから SageMaker Unified Studio プロジェクトへの移行、既存の Athena ワークグループでのプロジェクトの設定、IAM ロールの更新を介した必要なアクセス許可の維持が可能です。詳細については、「[Migrating Amazon Athena resources to Amazon SageMaker Unified Studio (プレビュー)](https://github.com/aws/Unified-Studio-for-Amazon-Sagemaker/tree/main/migration/athena)」を参照してください。 ## 考慮事項と制限事項 Athena でワークグループを使用するときは、次の点に注意してください。 + 各アカウントにはプライマリワークグループがあります。デフォルトでは、ワークグループを作成していない場合、アカウントのすべてのクエリはプライマリワークグループで実行されます。プライマリワークグループは削除できません。デフォルトのアクセス許可では、認証されたすべてのユーザーがこのワークグループにアクセスできます。 + ワークグループにアクセスすると、そのワークグループの設定、メトリクス、およびデータ使用量の制御制限を表示できます。設定およびデータ使用量の制御制限を編集できる追加のアクセス許可を持つことができます。 + クエリを実行すると、現在のワークグループでクエリが実行されます。コンソールのワークグループでクエリを実行するか、JDBC または ODBC ドライバーを介して API オペレーション、コマンドラインインターフェイス、またはクライアントアプリケーションを使用してクエリを実行できます。 + Athena コンソールのクエリエディタでは、各ワークグループ内で最大 10 個のクエリタブを開くことができます。ワークグループを切り替えると、クエリタブは最大 3 つのワークグループに対して開いたままになります。 + アカウントのAWS リージョンあたり最大 1000 個のワークグループを作成できます。 + ワークグループを無効にできます。ワークグループを無効にすると、ワークグループを再度有効にするまで、ワークグループ内でクエリが実行されなくなります。 + 保存されたクエリを含むワークグループを削除しようとすると、Athena が警告を表示します。他のユーザーがアクセスできるワークグループを削除する前に、そのユーザーがクエリの実行に使用できる別のワークグループにアクセスできることを確認してください。 **Topics** + [考慮事項と制限事項](#workgroups-considerations-limitations) + [ワークグループの作成](creating-workgroups.md) + [ワークグループを管理する](workgroups-create-update-delete.md) + [CloudWatch と EventBridge を使用してクエリをモニタリングする](workgroups-control-limits.md) + [Athena ワークグループ API を使用する](workgroups-api-list.md) + [ワークグループのトラブルシューティング](workgroups-troubleshooting.md) # ワークグループの作成 ワークグループを作成するには、`CreateWorkgroup` API アクションへのアクセス権限が必要です。「[ワークグループとタグへのアクセスを構成する](workgroups-access.md)」および「[IAM ポリシーを使用してワークグループのアクセスを制御する](workgroups-iam-policy.md)」を参照してください。タグを追加している場合は、`TagResource` にアクセス権限を追加する必要もあります。「[ワークグループのタグポリシーの例](tags-access-control.md#tag-policy-examples-workgroups)」を参照してください。 次の手順では、 Athena コンソールを使用してパラメータグループを編集する方法を示します。Athena API を使用してワークグループを作成するには、「[CreateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateWorkGroup.html)」を参照してください。 **Athena コンソールでワークグループを作成するには** 1. 作成するワークグループを決定します。以下のような考慮すべき点があります。 + 各ワークグループでクエリを実行できるユーザー、およびワークグループ設定を所有しているユーザー。IAM ポリシーを使用してワークグループのアクセス許可を適用します。詳細については、「[IAM ポリシーを使用してワークグループのアクセスを制御する](workgroups-iam-policy.md)」を参照してください。 + ワークグループのクエリ結果に使用する Amazon S3 内の場所。ワークグループを使用するすべてのユーザーが、この場所にアクセスできる必要があります。 + ワークグループのクエリ結果を暗号化する必要があるかどうか。暗号化はワークグループごと (クエリごとではない) であるため、暗号化されたクエリ結果と暗号化されていないクエリ結果に対して別々のワークグループを作成する必要があります。詳細については、「[Amazon S3 に保存された Athena クエリ結果を暗号化する](encrypting-query-results-stored-in-s3.md)」を参照してください。 1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。 ![\[展開メニューを選択します。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/nav-pane-expansion.png) 1. Athena コンソールのナビゲーションペインで、**[Workgroups]** (ワークグループ) をクリックします。 1. **[Workgroups]** (ワークグループ) ページで、**[Create workgroup]** (ワークグループを作成する) をクリックします。 1. **[Create workgroup]** (ワークグループを作成する) ページで、次のようにフィールドに入力します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/creating-workgroups.html) 1. **[Create workgroup]** (ワークグループの作成) を選択します。ワークグループが **[Workgroups]** (ワークグループ) ページのリストに表示されます。 クエリエディターでは、Athena がコンソールの右上にある **[Workgroup]** (ワークグループ) オプションに、現在のワークグループを表示します。このオプションを使用して、ワークグループを切り替えることができます。クエリを実行すると、現在のワークグループでクエリが実行されます。 1. ユーザー、グループ、またはロール用の IAM ポリシーを作成して、それらがワークグループにアクセスできるようにします。ポリシーは、ワークグループメンバーシップおよび `workgroup` リソースのアクションへのアクセスを確立します。詳細については、「[IAM ポリシーを使用してワークグループのアクセスを制御する](workgroups-iam-policy.md)」を参照してください。JSON ポリシーの例については、「[ワークグループとタグへのアクセスを構成する](workgroups-access.md)」を参照してください。 1. (オプション) ワークグループ全体の暗号化がクライアント側設定のオーバーライドによって強制されない場合、ワークグループからのすべてのクエリ結果に対して Amazon S3 で最小レベルの暗号化を設定します。この機能を使用すると、クエリ結果が暗号化されていない状態で Amazon S3 バケットに保存されないようにすることができます。詳細については、「[ワークグループの最低限の暗号化を設定する](workgroups-minimum-encryption.md)」を参照してください。 1. (オプション) Amazon CloudWatch と Amazon EventBridge を使用して、ワークグループのクエリをモニタリングし、コストを管理できます。詳細については、「[CloudWatch と EventBridge を使用してクエリをモニタリングし、コストを管理する](workgroups-control-limits.md)」を参照してください。 1. (オプション) 請求およびコストマネジメントコンソールを使用して、ワークグループにコスト配分タグを付けます。詳細については、「*AWS Billingユーザーガイド*」の「[Using user-defined cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)」をご参照ください。 1. (オプション) ワークグループ内のクエリ専用の処理キャパシティを取得するには、キャパシティ予約にワークグループを追加します。1 つ以上のワークグループを予約に割り当てることができます。詳細については、「[クエリ処理キャパシティを管理する](capacity-management.md)」を参照してください。 # [Override client-side settings (クライアント側設定の上書き)] ワークグループを作成または編集するときに、**クライアント側設定の上書き** オプションを選択できます。このオプションはデフォルトで選択されていません。選択したかどうかに応じて、Athena が以下を実行します。 + **[クライアント側設定の上書き]** が選択されていない場合、ワークグループ設定はクライアントレベルで強制されません。ワークグループでクライアント側の設定を上書きするオプションが選択されていない場合、Athena はワークグループで実行されるすべてのクエリに、クエリ結果の場所、予想されるバケット所有者、暗号化、およびクエリ結果のバケットに書き込むオブジェクトの制御に関する設定を含む、クライアント側の設定を使用します。各ユーザーは、コンソールの **[設定]** メニューで自分の設定を指定できます。クライアント側の設定がされていない場合は、ワークグループ全体の設定が適用されます。AWS CLI、API アクション、または JDBC および ODBC ドライバーを使用して、クライアント側の設定を上書きしないワークグループでクエリを実行する場合、クエリにはクエリで指定した設定が使用されます。 + **[クライアント側の設定の上書き]** を選択した場合、ワークグループ設定はワークグループのすべてのクライアントにワークグループレベルで実施されます。ワークグループでクライアント側の設定を上書きするオプションを選択すると、Athena はワークグループで実行されるすべてのクエリにワークグループの設定を使用します。これには、クエリ結果の場所、予想バケット所有者、暗号化、クエリ結果バケットに書き込むオブジェクトの制御に関する設定が含まれます。ワークグループ設定は、コンソール、API アクション、または JDBC または ODBC ドライバーを使用するときにクエリに指定したクライアント側の設定よりも優先されます。ワークグループ設定がクライアント側の設定をオーバーライドするように設定された後は、ドライバーまたは API でクライアント側の設定の指定を省略できます。 クライアント側の設定を上書きした場合、次にお客様または他のワークグループユーザーが Athena コンソールを開くと、Athena はワークグループのクエリでワークグループの設定を使用することが通知され、この変更を確認するよう求められます。 **注記** クライアント側の設定を上書きすると、任意の Amazon S3 バケットでの結果の可用性に基づくカスタムオートメーションが中断される可能性があるため、上書きする前にユーザーに通知することをお勧めします。 **重要** API アクション、AWS CLI、または JDBC ドライバーと ODBC ドライバーを使用して、クライアント側の設定を上書きするワークグループ内のクエリを実行する場合は、クエリのクライアント側の設定を省略するか、ワークグループの設定と一致するように更新ることを確認します。 クエリでクライアント側の設定を指定し、その設定を上書きするワークグループで実行した場合、クエリは実行されますが、ワークグループの設定が使用されます。ワークグループの設定の表示に関する詳細は、「[ワークグループの詳細の表示](viewing-details-workgroups.md)」を参照してください。 # ワークグループを管理する Athena コンソール ([https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home)) では、次のタスクを実行できます。 | ステートメント | 説明 | | --- | --- | | [ワークグループの作成](creating-workgroups.md) | 新しいワークグループを作成します。 | | [ワークグループの詳細の表示](viewing-details-workgroups.md) | 名前、説明、データ使用量の制限、クエリ結果の場所、予想されるクエリ結果のバケット所有者、暗号化、クエリ結果バケットに書き込まれるオブジェクトのコントロールなど、ワークグループの詳細が表示されます。[Override client-side settings (クライアント側設定の上書き)] がオンになっている場合、このワークグループがその設定を強制しているかどうかも確認できます。 | | [クエリのワークグループを指定する](specify-wkgroup-to-athena-in-which-to-run-queries.md) | クエリを実行する前に、使用するワークグループを Athena に指定する必要があります。ワークグループに対するアクセス権限が必要です。 | | [ワークグループの切り替え](switching-workgroups.md) | アクセス権があるワークグループを切り替えます。 | | [ワークグループの編集](editing-workgroups.md) | ワークグループを編集して設定を変更します。ワークグループの名前を変更することはできませんが、同じ設定と別の名前で新しいワークグループを作成することはできます。 | | [ワークグループを有効または無効にします。](workgroups-enabled-disabled.md) | ワークグループを有効または無効にします。ワークグループを無効にすると、そのユーザーはクエリを実行したり、新しい名前付きクエリを作成したりできません。アクセスできる場合でも、メトリクス、データ使用制限コントロール、ワークグループの設定、クエリ履歴、保存されたクエリを表示できます。 | | [ワークグループ間で保存されたクエリのコピー](copy-a-query-between-workgroups.md) | ワークグループ間で保存されたクエリをコピーします。これは、例えばプレビューワークグループでクエリを作成し、それを非プレビューワークグループで使用できるようにしたい場合などに実行できます。 | | [ワークグループの削除](deleting-workgroups.md) | ワークグループを削除します。ワークグループ、クエリ履歴、保存されたクエリを削除すると、ワークグループの設定とクエリごとのデータ制限コントロールが削除されます。ワークグループ全体のデータ制限制御は CloudWatch で保持され、個別に削除することができます。 プライマリワークグループは削除できません。 | | [IAM ポリシーを使用してワークグループのアクセスを制御する](workgroups-iam-policy.md) | IAM ポリシーを使用してワークグループのアクセスを制御します。ワークグループ ポリシーの例については、「[ワークグループのポリシーの例](example-policies-workgroup.md)」を参照してください。 | | [IAM アイデンティティセンター認証を使用する Athena ワークグループを作成する](workgroups-identity-center.md) | Athena で IAM アイデンティティセンター ID を使用するには、IAM アイデンティティセンターが有効なワークグループを作成する必要があります。ワークグループを作成したら、IAM アイデンティティセンターのコンソールまたは API を使用して IAM アイデンティティセンターのユーザーまたはグループをワークグループに割り当てることができます。 | | [ワークグループの最低限の暗号化を設定する](workgroups-minimum-encryption.md) | ワークグループからのすべてのクエリ結果に対して、Amazon S3 で最小限の暗号化レベルを適用します。この機能を使用すると、クエリ結果が暗号化されていない状態で Amazon S3 バケットに保存されないようにします。 | # ワークグループの詳細の表示 各ワークグループの詳細を表示できます。詳細には、ワークグループの名前、説明、有効になっているか無効になっているか、ワークグループで実行されるクエリに使用される設定 (クエリ結果の場所や予想されるバケット所有者、暗号化、クエリ結果バケットに書き込まれるオブジェクトのコントロールなど) が含まれます。ワークグループにデータ使用量の制限がある場合は、それらも表示されます。 **ワークグループの詳細を表示するには** 1. Athena コンソールのナビゲーションペインで、**[Workgroups]** (ワークグループ) をクリックします。 1. **[Workgroups]** (ワークグループ) ページで、表示するワークグループのリンクを選択します。ワークグループの **[Overview Details]** (概要の詳細) ページが表示されます。 # クエリのワークグループを指定する 使用するワークグループを指定するには、ワークグループに対するアクセス許可が必要です。 **使用するワークグループを指定するには** 1. 使用する予定のワークグループでクエリを実行できるアクセス権限であることを確認します。詳細については、「[IAM ポリシーを使用してワークグループのアクセスを制御する](workgroups-iam-policy.md)」を参照してください。 1. ワークグループを指定するには、次のいずれかのオプションを使用してください。 + Athena コンソールを使用している場合は、[ワークグループを切り替え](switching-workgroups.md)てワークグループを設定します。 + Athena API オペレーションを使用している場合は、API アクションにワークグループ名を指定します。例えば、以下のように [StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html) でワークグループ名を設定できます。 ``` StartQueryExecutionRequest startQueryExecutionRequest = new StartQueryExecutionRequest() .withQueryString(ExampleConstants.ATHENA_SAMPLE_QUERY) .withQueryExecutionContext(queryExecutionContext) .withWorkGroup(WorkgroupName) ``` + JDBC または ODBC ドライバーを使用している場合、`Workgroup` 設定パラメータを使用して接続文字列にワークグループ名を設定します。ドライバーがワークグループ名を Athena に渡します。次の例のように、接続文字列にワークグループパラメータを指定します。 ``` jdbc:awsathena://AwsRegion=;UID=; PWD=;S3OutputLocation=s3://amzn-s3-demo-bucket/-/; Workgroup=; ``` # ワークグループの切り替え 両方のワークグループにアクセス権限がある場合は、あるワークグループから別のワークグループに切り替えることができます。 各ワークグループで最大 10 個のクエリタブを開くことができます。ワークグループを切り替えると、クエリタブは最大 3 つのワークグループに対して開いたままになります。 **ワークグループを切り替えるには** 1. Athena コンソールで、右上の **[Workgroups]** (ワークグループ) オプションを使用して、ワークグループを選択します。 1. **[Workgroup *workgroup-name* setting]** (ワークグループ (ワークグループ名) の設定) ダイアログボックスが表示されたら、**[Acknowledge]** (承認する) を選択します。 **[Workgroup]** (ワークグループ) オプションには、切り替えたワークグループの名前が表示されます。これで、このワークグループでクエリを実行できます。 # ワークグループの編集 ワークグループを編集するには、`UpdateWorkgroup` API オペレーションへのアクセス権限が必要です。「[ワークグループとタグへのアクセスを構成する](workgroups-access.md)」および「[IAM ポリシーを使用してワークグループのアクセスを制御する](workgroups-iam-policy.md)」を参照してください。タグを追加または編集している場合、`TagResource` へのアクセス権限も必要です。「[ワークグループのタグポリシーの例](tags-access-control.md#tag-policy-examples-workgroups)」を参照してください。 **コンソールでワークグループを編集するには** 1. Athena コンソールのナビゲーションペインで、**[Workgroups]** (ワークグループ) をクリックします。 1. **[Workgroups]** (ワークグループ) ページで、編集するワークグループのボタンを選択します。 1. **[Actions]**、**[Edit]** の順に選択します。 1. 必要に応じて、フィールドの値を変更します。フィールドのリストについては、「[ワークグループの作成](creating-workgroups.md)」を参照してください。ワークグループの名前を除くすべてのフィールドを変更できます。名前を変更する必要がある場合は、新しい名前と同じ設定で別のワークグループを作成してください。 1. **[Save changes]** (変更の保存) を選択します。更新されたワークグループが **[Workgroups]** (ワークグループ) ページのリストに表示されます。 # ワークグループを有効または無効にします。 アクセス権限がある場合は、API オペレーションを使用するか、JDBC および ODBC ドライバーを使用して、コンソールでワークグループを有効化または無効化できます。 **ワークグループを有効化または無効化するには** 1. Athena コンソールのナビゲーションペインで、**[Workgroups]** (ワークグループ) をクリックします。 1. **[Workgroup]** (ワークグループ) ページで、ワークグループのリンクを選択します。 1. 右上の **[Enable workgroup]** (ワークグループの有効化) または **[Disable workgroup]** (ワークグループの無効化) を選択します。 1. 確認プロンプトで、**[Enable]** (有効化) または **[Disable]** (無効化) を選択します。ワークグループを無効にすると、そのユーザーはその中でクエリを実行したり、新しい名前付きクエリを作成したりできません。ワークグループを有効にした場合、ユーザーはそれを使用してクエリを実行できます。 # ワークグループ間で保存されたクエリのコピー 現在、Athena コンソールには、保存されたクエリを 1 つのワークグループから別のワークグループに直接コピーするオプションはありませんが、以下の手順を使用することで、同じタスクを手動で実行することができます。 **ワークグループ間で保存されたクエリをコピーする** 1. Athena コンソールで、クエリをコピーするワークグループから、[**Saved queries**] (保存されたクエリ) タブをクリックします。 1. コピーする保存されたクエリのリンクを選択します。Athena により、クエリエディタでクエリが開かれます。 1. クエリエディタで、クエリテキストを選択してから **Ctrl\$1C** を押してそれをコピーします。 1. 宛先ワークグループに[切り替える](switching-workgroups.md)か、[ワークグループを作成](creating-workgroups.md)してから、それに切り替えます。 1. クエリエディタで新しいタブを開き、**Ctrl\$1V** を押して新しいタブにテキストを貼り付けます。 1. クエリエディタで **[Save as]** (名前を付けて保存) をクリックして、クエリを宛先のワークグループに保存します。 1. [**Choose name**] (名前の選択) ダイアログボックスで、クエリの名前とオプションの説明を入力します。 1. **[Save]** (保存) を選択します。 # ワークグループの削除 アクセス権限がある場合は、ワークグループを削除できます。プライマリワークグループは削除できません。 アクセス権限がある場合は、いつでも空のワークグループを削除できます。保存したクエリが含まれているワークグループを削除することもできます。この場合、ワークグループの削除に進む前に、保存されたクエリが削除されることを Athena が警告します。 ワークグループにいる間にワークグループを削除した場合、コンソールは焦点をプライマリワークグループに切り替えます。アクセスできる場合は、クエリを実行して設定を表示します。 ワークグループを削除すると、その設定とクエリごとのデータ制限コントロールは削除されます。ワークグループ全体のデータ制限制御は CloudWatch で保持され、そこで必要に応じて削除することができます。 **重要** ワークグループを削除する前に、そのユーザーが引き続きクエリを実行できる他のワークグループに属していることを確認してください。ユーザーの IAM ポリシーが、ユーザーにこのワークグループ*のみ*でクエリの実行を許可していた場合にそのワークグループを削除すると、ユーザーはクエリを実行する許可を失います。詳細については、「[Example policy for running queries in the primary workgroup](example-policies-workgroup.md#example4-run-in-primary-access)」を参照してください。 **コンソールでワークグループを削除するには** 1. Athena コンソールのナビゲーションペインで、**[Workgroups]** (ワークグループ) をクリックします。 1. **[Workgroups]** (ワークグループ) ページで、削除するワークグループのボタンを選択します。 1. **[アクション]**、**[削除]** の順に選択します。 1. **[Delete workgroup]** (ワークグループを削除する) の確認プロンプトで、ワークグループの名前と入力し、**[Delete]** (削除) を選択します。 API オペレーションでワークグループを削除するには、`DeleteWorkGroup` アクションを使用します。 # CloudWatch と EventBridge を使用してクエリをモニタリングし、コストを管理する ワークグループは、クエリまたはワークグループごとにデータ使用状況の管理制限を設定し、これらの制限を超えたときのアラームをセットアップして、クエリメトリクスを CloudWatch に発行することを可能にします。 各ワークグループに、以下を行えます。 + クエリごとおよびワークグループごとに [**Data usage controls (データ使用量の制御)**] を設定し、クエリがしきい値を超えた場合に実行されるアクションを設定する。 + クエリメトリクスを表示して分析し、それらを CloudWatch に発行する。コンソールでワークグループを作成すると、メトリクスを CloudWatch に発行するための設定が選択されます。API オペレーションを使用する場合は、[メトリクスの発行を有効にする](athena-cloudwatch-metrics-enable.md)必要があります。メトリクスが発行されると、それらが [**Workgroups**] (ワークグループ) パネルの [**Metrics**] (メトリクス) タブに表示されます。プライマリワークグループでは、メトリクスはデフォルトで無効になっています。 ## 動画 以下のビデオは、CloudWatch でカスタムダッシュボードを作成し、メトリクスにアラームとトリガーを設定する方法を説明しています。Athena コンソールから、事前入力されているダッシュボードを直接使用して、これらのクエリメトリクスを取り込むことができます。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/x1V_lhkdKCg/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/x1V_lhkdKCg) **Topics** + [動画](#athena-cloudwatch-metrics-video) + [クエリメトリクスを有効にする](athena-cloudwatch-metrics-enable.md) + [CloudWatch によるクエリメトリクスのモニタリング](query-metrics-viewing.md) + [CloudWatch による使用状況メトリクスのモニタリング](monitoring-athena-usage-metrics.md) + [EventBridge でクエリイベントをモニタリングする](athena-events.md) + [データ使用量の制御を設定する](workgroups-setting-control-limits-cloudwatch.md) # Athena で CloudWatch クエリメトリクスを有効にする クエリメトリクスを CloudWatch に発行するための設定は、コンソールでワークグループを作成するときにデフォルトで選択されます。 **Athena コンソールでワークグループのクエリメトリクスを有効または無効にする** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。 ![\[展開メニューを選択します。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/nav-pane-expansion.png) 1. ナビゲーションペインで、[**Global networks (グローバルネットワーク)**] を選択します。 1. 変更するワークグループのリンクを選択します。 1. ワークグループの詳細ページで、**[Edit]** (編集) を選択します。 1. **[設定]** セクションで、**[AWS CloudWatch にクエリメトリクスを発行]** を選択または解除します。 API オペレーション、コマンドラインインターフェイス、または JDBC ドライバーでクライアントアプリケーションを使用してワークグループを作成する場合にクエリメトリクスの発行を有効にするには、[WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html) で `PublishCloudWatchMetricsEnabled` を `true` に設定します。次の例では、メトリクス設定のみを示し、その他の設定は省略しています。 ``` "WorkGroupConfiguration": { "PublishCloudWatchMetricsEnabled": "true" .... } ``` # CloudWatch による Athena クエリメトリクスのモニタリング Athena は、[[publish query metrics to CloudWatch]](athena-cloudwatch-metrics-enable.md) (CloudWatch にクエリメトリクスを投稿する) オプションが選択されている場合に、クエリ関連のメトリクスを Amazon CloudWatch に発行します。CloudWatch でカスタムダッシュボードを作成し、メトリクスのアラームとトリガーを設定する、または Athena コンソールから事前入力されているダッシュボードを直接使用することができます。 ワークグループでのクエリにクエリメトリクスを有効にすると、そのメトリクスが各ワークグループごとに、Athena コンソールにある **[Workgroups]** (ワークグループ) パネルの **[Metrics]** (メトリクス) タブに表示されます。 Athena は、以下のメトリクスを CloudWatch コンソールに発行します。 + `DPUAllocated` — クエリを実行するためにキャパシティ予約にプロビジョニングされた DPU (データ処理ユニット) の総数。 + `DPUConsumed` — 予約の特定の時間に、`RUNNING` 状態のクエリによってアクティブに消費される DPU 数。ワークグループがキャパシティ予約に関連付けられている場合にのみ発行される指標であり、予約に関連付けられているすべてのワークグループが含まれます。 + `DPUCount` — クエリによって消費される DPU の最大数は、クエリの完了時に 1 回だけ発行されます。 + `EngineExecutionTime` — クエリの実行にかかったミリ秒数。 + `ProcessedBytes` — Athena が DML クエリごとにスキャンしたバイト数。 + `QueryPlanningTime` — Athena がクエリ処理フローの計画にかかったミリ秒数。 + `QueryQueueTime` — クエリがリソースを待ってキューに並んでいたミリ秒数。 + `ServicePreProcessingTime` — クエリエンジンにクエリを送信する前に Athena がクエリを前処理するためにかかったミリ秒数。 + `ServiceProcessingTime` — クエリエンジンがクエリの実行を終了した後に Athena がクエリ結果を処理するためにかかったミリ秒数。 + `TotalExecutionTime` — Athena が DDL クエリまたは DML クエリの実行にかかったミリ秒数。 詳細については、このドキュメントで後述される「[Athena 向けの CloudWatch メトリクスとディメンションのリスト](#athena-cloudwatch-metrics-table)」を参照してください。 これらのメトリクスには、以下のディメンションがあります。 + `CapacityReservation` — クエリの実行に使用されたキャパシティ予約の名前 (該当する場合)。 + `QueryState` - `SUCCEEDED`、`FAILED`、または `CANCELED` + `QueryType` - `DML`、`DDL`、または `UTILITY` + `WorkGroup` – ワークグループの名前 Athena は、次のメトリクスを `AmazonAthenaForApacheSpark` 名前空間で CloudWatch コンソールに発行します。 + `DPUCount` - 計算を実行するために、セッション中に消費された DPU の数。 このメトリクスには、次のディメンションがあります。 + `SessionId` - 計算が送信されるセッションの ID。 + `WorkGroup` - ワークグループの名前。 詳細については、このトピックで後述する「[Athena 向けの CloudWatch メトリクスとディメンションのリスト](#athena-cloudwatch-metrics-table)」を参照してください。Athena の使用状況のメトリクスについては、「[CloudWatch による Athena 使用状況メトリクスのモニタリング](monitoring-athena-usage-metrics.md)」を参照してください。 クエリメトリクスは、Athena コンソールまたは CloudWatch コンソールで表示できます。 ## Athena コンソールでクエリメトリクスを表示する **ワークグループのクエリメトリクスを Athena コンソールに表示するには** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。 ![\[展開メニューを選択します。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/nav-pane-expansion.png) 1. ナビゲーションペインで、[**Global networks (グローバルネットワーク)**] を選択します。 1. リストから目的のワークグループを選択し、**[Metrics]** (メトリクス) タブを選択します。 メトリクスダッシュボードが表示されます。 **注記** ワークグループのメトリクスを最近有効にした場合や、最近のクエリアクティビティがない場合は、ダッシュボードのグラフが空になる可能性があります。クエリアクティビティは、次のステップで指定する間隔に応じて CloudWatch から取得されます。 1. **[Metrics]** (メトリクス) セクションで、CloudWatch からクエリメトリクスをフェッチするために Athena が使用するメトリクス間隔を選択するか、カスタム間隔を指定します。 ![\[Athena コンソールでワークグループのメトリクス取得間隔を指定します。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/wg-custom-interval.png) 1. 表示されたメトリクスを更新するには、更新アイコンをクリックします。 ![\[更新アイコンを選択します。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/wg-refresh-metrics.png) 1. 更新アイコンの横にある矢印をクリックして、メトリクス表示の更新頻度を選択します。 ![\[Athena コンソールのワークグループメトリクス表示に対する更新間隔を選択します。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/wg-choose-refresh-interval.png) ## CloudWatch コンソールでクエリメトリクスを表示する **Amazon CloudWatch コンソールでメトリクスを表示する** 1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。 1. ナビゲーションペインで、[**Metrics**]、[**All metrics**] を選択します。 1. **AWS/Athena** 名前空間を選択します。 ## AWS CLI でクエリメトリクスを表示する **AWS CLI を使用してメトリクスを表示するには** + 次のいずれかを行います。 + Athena のメトリクスを一覧表示するには、コマンドプロンプトを開き、次のコマンドを使用します。 ``` aws cloudwatch list-metrics --namespace "AWS/Athena" ``` + すべての使用可能なメトリクスのリストを表示するには、次のコマンドを使用します。 ``` aws cloudwatch list-metrics" ``` ## Athena 向けの CloudWatch メトリクスとディメンションのリスト Athena で CloudWatch メトリクスを有効にしている場合、Athena がワークグループごとに以下のメトリクスを CloudWatch に送信します。次のメトリクスは `AWS/Athena` 名前空間を使用します。 | メトリクス名 | 説明 | | --- | --- | | DPUAllocated | クエリを実行するためにキャパシティ予約にプロビジョニングされた DPU (データ処理ユニット) の総数。 | | DPUConsumed | 予約の特定の時間に、RUNNING 状態のクエリによってアクティブに消費される DPU の数。このメトリックはワークグループがキャパシティ予約に関連付けられている場合にのみ発行され、予約に関連付けられているすべてのワークグループが含まれます。ワークグループをある予約から別の予約に移動した場合、指標にはそのワークグループが最初の予約に属していた時点のデータが含まれます。キャパシティ予約の詳細については、「[クエリ処理キャパシティを管理する](capacity-management.md)」を参照してください。 | | DPUCount | クエリによって消費される DPU の最大数は、クエリの完了時に 1 回だけ発行されます。この指標は、キャパシティ予約に関連付けられているワークグループにのみ発行されます。 | | EngineExecutionTime | クエリの実行にかかったミリ秒数。 | | ProcessedBytes | Athena が DML クエリごとにスキャンしたバイト数。(ユーザーによって、または制限に達した場合は自動的に) キャンセルされたクエリの場合、キャンセル前にスキャンされたデータの量も含まれます。このメトリクスは、DDL クエリではレポートされません。 | | QueryPlanningTime | Athena でクエリ処理フローの計画にかかったミリ秒数。これには、データソースからテーブルパーティションを取得するためにかかった時間も含まれます。クエリエンジンがクエリの計画を実行するため、クエリの計画時間は EngineExecutionTime のサブセットであることに注意してください。 | | QueryQueueTime | クエリがリソースを待ってキューに並んでいたミリ秒数。一時的なエラーが発生した場合は、クエリを自動的にキューに追加し直すことができます。 | | ServicePreProcessingTime | クエリエンジンにクエリを送信する前に Athena がクエリを前処理するためにかかったミリ秒数。 | | ServiceProcessingTime | クエリエンジンがクエリの実行を終了した後に Athena がクエリ結果を処理するためにかかったミリ秒数。 | | TotalExecutionTime | Athena が DDL クエリまたは DML クエリの実行にかかったミリ秒数。TotalExecutionTime には、QueryQueueTime、QueryPlanningTime、EngineExecutionTime、ServiceProcessingTime が含まれます。 | これらの Athena 用メトリクスには、以下のディメンションがあります。 | ディメンション | 説明 | | --- | --- | | CapacityReservation | クエリの実行に使用されたキャパシティ予約の名前 (該当する場合)。キャパシティ予約が使用されていないとき、このディメンションはデータを返しません。 | | QueryState | クエリの状態。 有効な統計: SUCCEEDED、FAILED、CANCELED。 | | QueryType | クエリタイプ。 有効な統計: `DDL`、`DML` または `UTILITY`。実行されたクエリステートメントのタイプ。`DDL` は DDL (データ定義言語) クエリステートメントを示します。`DML` は、`CREATE TABLE AS SELECT` などの DML (データ操作言語) クエリステートメントを示します。`UTILITY`は、`SHOW CREATE TABLE`、または `DESCRIBE TABLE` などの DDL と DML 以外のクエリステートメントを示します。 | | WorkGroup | ワークグループの名前。 | # CloudWatch による Athena 使用状況メトリクスのモニタリング CloudWatch の使用状況メトリクスにより、CloudWatch グラフやダッシュボード上に現在のサービスの使用状況を表示することで、アカウントがどのようにリソースを使用しているかを可視化できます。 Athena での使用可能性に関するメトリクスは、Athena の AWS のサービス クォータと対応しています。使用量がサービスクォータに近づいたときに警告するアラームを設定することもできます。Athena でのサービスクォータの詳細については、「[サービスクォータ](service-limits.md)」を参照してください。AWS の使用状況メトリクスの詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[AWS 使用状況メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Service-Quota-Integration.html)」を参照してください。 Athena は、以下のメトリクスを `AWS/Usage` 名前空間に公開します。 | メトリクス名 | 説明 | | --- | --- | | `ResourceCount` | クエリタイプ (DML または DDL) で分けられた、各アカウントの AWS リージョンごとのキュー登録されたクエリと実行中クエリすべての合計数。このメトリクスでは、最大数のみが有用な統計情報です。 このメトリクスは、1 分ごとに定期的に発行されます。実行するクエリがない場合、このメトリクスではレポートを何も (0 すらも) 返しません。このメトリクスは、それ自体が取得された時点でアクティブなクエリが実行されている場合にのみ公開されます。 | 以下のディメンションは、Athena によって発行された使用状況メトリクスを絞り込むために使用されます。 | ディメンション | 説明 | | --- | --- | | `Service` | リソースを含む AWS のサービス の名前。Athena では、このディメンションの値は `Athena` になります。 | | `Resource` | 実行中のリソースタイプ。Athena クエリの使用状況に関するリソース値は `ActiveQueryCount` です。 | | `Type` | 報告されるエンティティのタイプ。現在、Athena 使用状況メトリクスで有効な値は `Resource` のみです。 | | `Class` | 追跡されているリソースのクラス。Athena の場合、`Class` は `DML` または `DDL` となります。 | ## CloudWatch コンソールでの Athena リソースの使用状況メトリクスを表示する CloudWatch コンソールでは、Athena の使用状況メトリクスのグラフを表示したり、使用量がサービスクォータに近づいた場合に警告するためのアラームを設定したりできます。 **Athena リソースの使用状況メトリクスを表示するには** 1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。 1. ナビゲーションペインで、[**Metrics**]、[**All metrics**] を選択します。 1. **[使用]**を選択し、**[AWS リソース別]**を選択します。 サービスクォータ使用状況メトリクスのリストが表示されます。 1. **[Athena]** と **[ActiveQueryCount]** の横にあるチェックボックスをオンにします。 1. **[グラフ化したメトリクス]** タブを選択します。 その上のグラフに、その AWS リソースの現在の使用状況が表示されます。 サービスクォータをグラフに追加し、サービスクォータに近づいた場合に通知を行うアラームを設定する方法については、「*Amazon CloudWatch ユーザーガイド*」の「[Visualizing your service quotas and setting alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html)」(サービスクォータの可視化とアラームの設定) を参照してください。ワークグループごとの使用制限の設定については、「[クエリごとおよびワークグループごとのデータ使用量の制御を設定する](workgroups-setting-control-limits-cloudwatch.md)」を参照してください。 # EventBridge を使用して Athena クエリ イベントをモニタリングする Amazon Athena を Amazon EventBridge と使用し、クエリの状態に関するリアルタイムの通知を受け取ることができます。送信したクエリの状態が推移すると、Athena がそのクエリ状態の推移に関する情報が含まれたイベントを EventBridge に発行します。関心のあるイベントのシンプルなルールを作成し、イベントがルールに一致したときに自動化されたアクションが実行されるようにできます。たとえば、クエリが最終状態に達したときに AWS Lambda 関数を呼び出すルールを作成できます。イベントは、ベストエフォートベースで出力されます。 Athena のイベントルールを作成する前に、以下を実行する必要があります。 + EventBridge のイベント、ルール、ターゲットに精通しておいてください。詳細については、「[Amazon EventBridge とは?](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)」を参照してください。ルールの設定方法に関する詳細については、「[Amazon EventBridge の開始方法](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)」を参照してください。 + イベントのルールで使用するターゲットを作成する。 **注記** Athena では、現在 Athena Query State Change という 1 つのイベントタイプを提供していますが、他のタイプのイベントと詳細が追加する場合があります。イベントの JSON データをプログラムで逆シリアル化する場合は、不明なプロパティが追加されているときにアプリケーションで対応する準備ができていることを確認してください。 ## Athena イベントの形式 以下は、Amazon Athena イベントの基本的なパターンです。 ``` { "source":[ "aws.athena" ], "detail-type":[ "Athena Query State Change" ], "detail":{ "currentState":[ "SUCCEEDED" ] } } ``` ## Athena Query State Change イベント 次の例は、`currentState` の値が `SUCCEEDED` の Athena Query State Change イベントを示しています。 ``` { "version":"0", "id":"abcdef00-1234-5678-9abc-def012345678", "detail-type":"Athena Query State Change", "source":"aws.athena", "account":"123456789012", "time":"2019-10-06T09:30:10Z", "region":"us-east-1", "resources":[ ], "detail":{ "versionId":"0", "currentState":"SUCCEEDED", "previousState":"RUNNING", "statementType":"DDL", "queryExecutionId":"01234567-0123-0123-0123-012345678901", "workgroupName":"primary", "sequenceNumber":"3" } } ``` 次の例は、`currentState` の値が `FAILED` の Athena Query State Change イベントを示しています。`athenaError` ブロックは、`currentState` が `FAILED` の場合のみ表示されます。`errorCategory`、および `errorType` の値についての詳細は、「[Athena エラーカタログ](error-reference.md)」を参照してください。 ``` { "version":"0", "id":"abcdef00-1234-5678-9abc-def012345678", "detail-type":"Athena Query State Change", "source":"aws.athena", "account":"123456789012", "time":"2019-10-06T09:30:10Z", "region":"us-east-1", "resources":[ ], "detail":{ "athenaError": { "errorCategory": 2.0, //Value depends on nature of exception "errorType": 1306.0, //Type depends on nature of exception "errorMessage": "Amazon S3 bucket not found", //Message depends on nature of exception "retryable":false //Retryable value depends on nature of exception }, "versionId":"0", "currentState": "FAILED", "previousState": "RUNNING", "statementType":"DML", "queryExecutionId":"01234567-0123-0123-0123-012345678901", "workgroupName":"primary", "sequenceNumber":"3" } } ``` ### 出力プロパティ JSON 出力には、以下のプロパティが含まれます。 **** | プロパティ | 説明 | | --- | --- | | athenaError | currentState が FAILED の場合にのみ表示されます。エラーカテゴリ、エラータイプ、エラーメッセージ、およびエラーの原因となったアクションを再試行できるかどうかなど、発生したエラーに関する情報が含まれます。これらのフィールドそれぞれの値は、エラーの性質によって異なります。errorCategory、および errorType の値についての詳細は、「[Athena エラーカタログ](error-reference.md)」を参照してください。 | | versionId | 詳細オブジェクトのスキーマのバージョン番号。 | | currentState | イベント発生時のクエリの移行後の状態。 | | previousState | イベント発生時のクエリの移行前の状態。 | | statementType | 実行されたクエリステートメントのタイプ。 | | queryExecutionId | 実行されたクエリの一意の識別子。 | | workgroupName | クエリが実行されたワークグループの名前。 | | sequenceNumber | 実行された単一のクエリが関与する受信イベントの重複排除と順序付けを可能にする単調増加数。同じ状態移行に対して重複するイベントが発行された場合、sequenceNumber 値は同じです。再キューイングがまれに発生するクエリなど、状態移行が複数回発生するクエリの場合は、sequenceNumber を使用して、currentState および previousState 値が同じイベントを順序付けできます。 | ## 例 以下の例は、サブスクライブした Amazon SNS トピックにイベントを発行します。Athena がクエリされると、E メールを受信します。この例は、Amazon SNS トピックが存在し、そのトピックにサブスクライブしていることを前提としています。 **Athena イベントを Amazon SNS トピックに発行する** 1. Amazon SNS トピックのターゲットを作成します。次の例のように、EventBridge イベントが Amazon SNS トピックに発行するため、サービスプリンシパルの `events.amazonaws.com` 許可を付与します。 ``` { "Effect":"Allow", "Principal":{ "Service":"events.amazonaws.com" }, "Action":"sns:Publish", "Resource":"arn:aws:sns:us-east-1:111111111111:your-sns-topic" } ``` 1. 以下の例にあるように、AWS CLI `events put-rule` コマンドを使用して Athena イベントのルールを作成します。 ``` aws events put-rule --name {ruleName} --event-pattern '{"source": ["aws.athena"]}' ``` 1. 以下の例にあるように、AWS CLI `events put-targets` コマンドを使用して Amazon SNS トピックのターゲットをルールにアタッチします。 ``` aws events put-targets --rule {ruleName} --targets Id=1,Arn=arn:aws:sns:us-east-1:111111111111:your-sns-topic ``` 1. Athena をクエリして、呼び出されるターゲットを確認します。Amazon SNS トピックから対応する E メールを受信します。 ## Amazon Athena で AWS User Notifications を使用する [AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html) を使用して配信チャネルを設定して、Amazon Athena イベントに関する通知を受け取ることができます。指定したルールにイベントが一致すると、通知を受け取ります。イベントの通知は、Eメール、[チャットアプリケーション内の Amazon Q Developer](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html)のチャット通知、[AWS Console Mobile Application](https://docs.aws.amazon.com/consolemobileapp/latest/userguide/what-is-consolemobileapp.html)のプッシュ通知などの複数のチャネルで受け取ることができます。また、[コンソール通知センター](https://console.aws.amazon.com/notifications/)の通知を確認することもできます。User Notifications は集約をサポートしているため、特定のイベント中に受け取る通知の数を減らすことができます。 詳細については、「[https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html](https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html)」を参照してください。 # クエリごとおよびワークグループごとのデータ使用量の制御を設定する Athena では、クエリごとの制限とワークグループごとの制限の 2 つのタイプのコスト制御を設定できます。ワークグループごとに、クエリごとの制限を 1 つとワークグループごとの制限を複数設定できます。 + **クエリごとの制御制限**は、クエリごとにスキャンされるデータの合計量を指定します。ワークグループで実行されるクエリが制限を超えると、キャンセルされます。ワークグループに作成できるクエリごとの制御制限は 1 つだけであり、その中で実行される各クエリに適用されます。変更する必要がある場合は、制限を編集します。詳細なステップについては、「[クエリごとにデータ使用量の制御を作成するには](#configure-control-limit-per-query)」を参照してください。 + **ワークグループ全体のデータ使用量の制御制限**は、指定された期間中にこのワークグループで実行されるすべてのクエリに対してスキャンされるデータの合計量を指定します。ワークグループごとに複数の制限を作成できます。ワークグループ全体のクエリ制限を使用すると、ワークグループで実行されているクエリによってスキャンされたデータの時間単位または日単位の集計に複数のしきい値を設定できます。 スキャンされたデータの合計量がしきい値を超えた場合に、Amazon SNS トピックに通知をプッシュできます。これを実行するには、制限を超えたときに管理者が通知を受けるように、Amazon SNS アラームと Athena コンソールでのアクションを設定します。詳細なステップについては、「[ワークグループごとにデータ使用量の制御を作成するには](#configure-control-limit-per-workgroup)」を参照してください。Athena が CloudWatch コンソールから発行する任意のメトリクスに対してアラームとアクションを作成することもできます。たとえば、失敗した多くのクエリに対してアラートを設定できます。このアラートは、数が特定のしきい値を超えた場合に管理者への E メールをトリガーできます。制限を超えた場合、アクションが指定されたユーザーに Amazon SNS アラーム通知を送信します。 実行できるその他のアクションは、以下のとおりです。 + Lambda 関数を呼び出す。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」で「[Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda-as-subscriber.html)」を参照してください。 + ワークグループを無効にして、さらにクエリが実行されないようにする。この手順については、「[ワークグループを有効または無効にします。](workgroups-enabled-disabled.md)」を参照してください。 クエリごと、ワークグループごとの制限は相互に独立しています。指定したどちらかの制限を超えた場合にアクションが実行されます。複数のユーザーが同じワークグループで同時にクエリを実行した場合、各クエリは指定された制限を超えないものの、スキャンされたデータの合計がワークグループごとのデータ使用制限を超える可能性があります。この場合、Amazon SNS アラームがユーザーに送信されます。 ## クエリごとのデータ使用量の制御を作成する **クエリごとのデータ使用量の制御を作成するには** クエリごとの制御制限は、クエリごとにスキャンされるデータの合計量を指定します。ワークグループで実行されるクエリが制限を超えると、キャンセルされます。キャンセルされたクエリの料金は、[Amazon Athena の料金表](https://aws.amazon.com/athena/pricing/)に従って請求されます。 **注記** キャンセルされた、または失敗したクエリの場合、Athena が既に部分的な結果を Amazon S3 に書き込んでいる可能性があります。このような場合、Athena は結果が保存されている Amazon S3 プレフィックスから部分的な結果を削除しません。部分的な結果がある Amazon S3 プレフィックスを削除する必要があります。Athena は、Amazon S3 マルチパートアップロードを使用して Amazon S3 データを書き込みます。クエリが失敗した場合にはマルチパートアップロードを中止するように、バケットライフサイクルポリシーを設定することが推奨されます。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[マルチパートアップロードを使用したオブジェクトのアップロードとコピー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html#mpu-abort-incomplete-mpu-lifecycle-config)」を参照してください。 特定の条件下では、Athena がクエリ実行を自動的に再試行することがあります。ほとんどの場合、これらのクエリは正常に完了し、クエリ ID は `Completed` とマークされます。これらのクエリは、最初の試行時に既に部分的な結果を書き込んでいる可能性があり、不完全なマルチパートアップロードになる恐れがあります。 ワークグループに作成できるクエリごとの制御制限は 1 つだけであり、その中で実行される各クエリに適用されます。変更する必要がある場合は、制限を編集します。 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. ナビゲーションペインで、**[Global networks (グローバルネットワーク)]** を選択します。 1. リストからワークグループ名を選択します。 1. **[実行コントロール]** タブで、**[コントロールの編集]** を選択します。 1. **[データスキャン制限]**の値を編集します。 + 10 MB (最小) から 7 EB (最大) までの範囲で値を指定します。 + ドロップダウンリストから単位の値（**Kilobytes KB** や **Exabytes EB** など）を選択します。 **注記** デフォルトのアクションでは、制限を超えた場合はクエリをキャンセルします。この設定は変更できません。 1. 変更を今すぐ適用するには **[保存]** を選択します。 ## ワークグループごとのデータ使用量アラートを作成または編集する **ワークグループごとのデータ使用量アラートを作成または編集するには** ワークグループで実行されているクエリが特定の期間内に指定された量のデータをスキャンする際、複数のアラートしきい値を設定できます。アラートは Amazon CloudWatch アラームを使用して実装され、ワークグループ内のすべてのクエリに適用されます。しきい値に達すると、Amazon SNS から指定したユーザーに E メールを送信できます。しきい値に達した場合でも、クエリは自動的にキャンセルされません。 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。 1. ナビゲーションペインで、**[Global networks]** (グローバルネットワーク) を選択します。 1. リストからワークグループ名を選択します。 1. **[Edit]** (編集) を選択して、ワークグループの設定を編集します。 1. 下にある **[Workgroup data usage alerts - optional]** (ワークグループのデータ使用量アラート - オプション) までスクロールし、展開します。 1. **[Add alert]** (アラートの追加) を選択します。 1. **[Data usage threshold configuration]** (データ使用量のしきい値の設定) については、次のように値を指定します。 + **[Data threshold]** (データのしきい値) については、数値を指定し、ドロップダウンリストから単位の値を選択します。 + **[Time period] (期間) については**、ドロップダウンリストから期間を選択します。 + **[SNS topic selection]** (SNS トピックの選択) については、ドロップダウンリストから Amazon SNS トピックを選択します。または、**[Create SNS topic]** (SNS トピックの作成) を選択して [Amazon SNS コンソール](https://console.aws.amazon.com/sns/v2/home)に直接移動し、Amazon SNS トピックを作成して、Athena アカウントのユーザーの 1 人にサブスクリプションをセットアップします。詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の使用開始](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)」を参照してください。 1. 新しいアラートを作成する場合は **[Add alert]** (アラートを追加) を選択し、既存のアラートを保存する場合は **[Save]** (保存) を選択します。 # Athena ワークグループ API を使用する 以下は、Athena ワークグループに使用される REST API オペレーションの一部です。`ListWorkGroups` を除く次のすべてのオペレーションで、ワークグループを指定する必要があります。`StartQueryExecution` のような他のオペレーションでは、ワークグループパラメータはオプションであり、オペレーションはここには一覧表示されません。オペレーションの完全なリストについては、「[Amazon Athena API リファレンス](https://docs.aws.amazon.com/athena/latest/APIReference/)」を参照してください。 + [CreateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateWorkGroup.html) + [DeleteWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_DeleteWorkGroup.html) + [GetWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetWorkGroup.html) + [ListWorkGroups](https://docs.aws.amazon.com/athena/latest/APIReference/API_ListWorkGroups.html) + [UpdateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_UpdateWorkGroup.html) # ワークグループエラーのトラブルシューティング ワークグループのトラブルシューティングを行うには、以下のヒントを参考にしてください。 + アカウントの個々のユーザーのアクセス権限を確認します。それらは、クエリ結果の場所、およびクエリを実行するワークグループへのアクセス権を持っている必要があります。ワークグループを切り替える場合は、両方のワークグループに対するアクセス権限も必要です。詳細については、「[IAM ポリシーを使用してワークグループのアクセスを制御する](workgroups-iam-policy.md)」を参照してください。 + Athena コンソールの内容に注目して、どのワークグループでクエリを実行するのかを確認します。ドライバーを使用する場合は、ワークグループを必要なものに設定する必要があります。詳細については、[クエリのワークグループを指定する](specify-wkgroup-to-athena-in-which-to-run-queries.md) を参照してください。 + API またはドライバーを使用してクエリを実行する場合は、次の方法のいずれかを使用してクエリ結果の場所を指定する必要があります。個々のクエリについては [OutputLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_ResultConfiguration.html#athena-Type-ResultConfiguration-OutputLocation) (クライアント側) を使用します。ワークグループでは [WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html) を使用します。場所がどちらの方法でも指定されていない場合、Athena はクエリランタイムでエラーを発行します。 + クライアント側の設定をワークグループの設定で上書きすると、クエリ結果の場所でエラーが発生する可能性があります。例えば、ワークグループのユーザーに、クエリ結果を保存するための Amazon S3 内のワークグループの場所に対する許可がない場合があります。この場合は、必要な許可を追加します。 + ワークグループは、API オペレーションの動作に変更を加えます。以下の既存の API オペレーションの呼び出しには、アカウントのユーザーが、呼び出しを行うワークグループに対して IAM にリソースベースの許可を持っている必要があります。ワークグループ、およびワークグループのアクションに対するアクセス許可がない場合は、**CreateNamedQuery**、**DeleteNamedQuery**、**GetNamedQuery**、**ListNamedQueries**、**StartQueryExecution**、**StopQueryExecution**、**ListQueryExecutions**、**GetQueryExecution**、**GetQueryResults**、**GetQueryResultsStream** (この API アクションはドライバーでの使用のみに利用でき、一般的な使用には利用できません) の API アクションが `AccessDeniedException` をスローします。詳細については、「*サービス承認リファレンス*」の「[Amazon Athena のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html)」を参照してください。 **BatchGetQueryExecution** および **BatchGetNamedQuery** API オペレーションの呼び出しは、ユーザーがアクセス権を持つワークグループで実行されるクエリに関する情報しか返しません。ユーザがワークグループにアクセスできない場合、これらの API オペレーションは未処理の ID リストの一部として未承認クエリ ID を返します。詳細については、「[Athena ワークグループ API を使用する](workgroups-api-list.md)」を参照してください。 + クエリが実行されるワークグループが[強制されたクエリ結果の場所](workgroups-settings-override.md)で設定されている場合は、CTAS クエリに `external_location` を指定しないでください。この場合、Athena がエラーを発行して、`external_location` を指定するクエリを失敗させます。たとえば、クエリ結果の場所に関するクライアント側の設定を上書きし、ワークグループに独自の場所を使用するように強制すると、次のクエリは失敗します。`CREATE TABLE . WITH (format='Parquet', external_location='s3://amzn-s3-demo-bucket/test/') AS SELECT * FROM . LIMIT 10;` 次のエラーが表示されることがあります。この表は、ワークグループに関連したエラーのリストを提供し、ソリューションを提案します。 **ワークグループのエラー** | エラー | 表示される場合 | | --- | --- | | 「query state CANCELED.」(クエリの状態がキャンセルされました) 「Bytes scanned limit was exceeded.」(スキャンされたバイト数が制限を超えました) | クエリがクエリごとのデータ制限に達し、キャンセルされました。読み込むデータを少なくするためにクエリを書き換えることを検討するか、アカウント管理者に連絡してください。 | | 「User: arn:aws:iam::123456789012:user/abc is not authorized to perform: athena:StartQueryExecution on resource: arn:aws:athena:us-east-1:123456789012:workgroup/workgroupname」(ユーザー: arn:aws:iam::123456789012:user/abc には実行する権限がありません: リソースでの athena:StartQueryExecution: arn:aws:athena:us-east-1:123456789012:workgroup/workgroupname) | ユーザーがワークグループでクエリを実行しましたが、アクセスできません。ワークグループにアクセスできるようにポリシーを更新してください。 | | INVALID\$1INPUT. 「WorkGroup is disabled.」(WorkGroup は無効です) | ユーザーがワークグループでクエリを実行しましたが、そのワークグループが無効になっています。ワークグループは管理者によって無効にされている可能性があります。また、アクセス権限がない可能性もあります。いずれの場合も、ワークグループを変更するアクセス権限を持つ管理者に連絡してください。 | | INVALID\$1INPUT. 「WorkGroup is not found.」(WorkGroup が見つかりません) | ユーザーがワークグループでクエリを実行しましたが、そのワークグループが存在しません。ワークグループが削除された場合、このエラーが発生する可能性があります。別のワークグループに切り替えてクエリを実行してください。 | | 「InvalidRequestException: when calling the StartQueryExecution operation: No output location provided.」(InvalidRequestException: StartQueryExecution オペレーションを呼び出す場合: 出力場所が指定されていません) 「An output location is required either through the Workgroup result configuration setting or as an API input.」(出力場所は、ワークグループ結果構成設定を使用するか、API 入力として指定する必要があります) | ユーザーがクエリ結果の場所を指定せずに API を使用してクエリを実行しました。2 つの方法のいずれかを使用して、クエリ結果の出力場所を設定する必要があります。個別のクエリの場合は「[OutputLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_ResultConfiguration.html#athena-Type-ResultConfiguration-OutputLocation)」 (クライアント側) を使用するか、ワークグループの場合は「[WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html)」を使用するかのいずれかです。 | | 「The Create Table As Select query failed because it was submitted with an 'external\$1location' property to an Athena Workgroup that enforces a centralized output location for all queries.」(Create Table As Select クエリは、すべてのクエリに対して集中管理された出力場所を強制する Athena ワークグループに 'external\$1location' プロパティを指定して送信されたため、失敗しました) 「Please remove the 'external\$1location' property and resubmit the query.」('external\$1location' プロパティを削除して、クエリを再送信してください) | クエリが実行されるワークグループに、[強制されたクエリ結果の場所](workgroups-settings-override.md)が設定されていて、CTAS クエリに external\$1location を指定しました。この場合、external\$1location を削除し、クエリを再実行します。 | | 「Cannot create prepared statement prepared\$1statement\$1name.」(準備済みステートメントの prepared\$1statement\$1name を作成できません) このワークグループ内の準備済みステートメントの数が上限の 1,000 を超えています。 | ワークグループに含まれる準備済みステートメントの数が制限の 1,000 を超えています。この問題を回避するには、[DEALLOCATE PREPARE](sql-deallocate-prepare.md) を使用してワークグループから 1 つ以上の準備済みステートメントを削除します。または、新しいワークグループを作成します。 | # クエリ処理キャパシティを管理する キャパシティ予約を使用して、Athena で実行するクエリ専用のサーバーレス処理キャパシティを確保することができます。キャパシティ予約を使用することで、ワークロード管理機能で重要なワークロードの優先順位付け、制御、スケーリングを簡単に行えます。例えば、キャパシティを追加して同時に実行できるクエリの数を増やしたり、そのキャパシティを使用できるワークロードを選択したり、ワークロード間でキャパシティを共有したりすることができます。キャパシティはサーバーレスで、 Athena によって完全に管理され、必要な限り長く維持されます。セットアップは簡単で、SQL クエリを変更する必要はありません。 クエリの処理キャパシティを確保するには、キャパシティ予約を作成し、必要なデータ処理ユニット (DPU) の数を指定し、予約に 1 つ以上のワークグループを割り当てます。 キャパシティ予約を使用する際に、ワークグループは重要な役割を果たします。ワークグループによって、クエリを論理的グルーピングやユースケースにまとめることができます。キャパシティ予約によって、キャパシティをワークグループに選択的に割り当て、各ワークグループのクエリの動作と請求方法を制御できます。ワークグループの詳細については、「[ワークグループを使用してクエリのアクセスとコストを制御する](workgroups-manage-queries-control-costs.md)」を参照してください。 ワークグループをキャパシティ予約に割り当てると、リザーブドキャパシティで実行されて DDL と DML のクエリクォータにはカウントされないため、これらのクエリを優先できます。例えば、時間的制約のある財務報告クエリに使用されるワークグループにキャパシティを割り当てて、それらのクエリを別のワークグループ内の重要度の低いクエリから隔離することができます。これにより、重要なワークロードに対するクエリ実行が予測可能になり、他のワークロードは独立して実行できます。 キャパシティ予約とワークグループを組み合わせて使用すると、さまざまな要件に対応することができます。例としていくつかのシナリオを次に挙げます。 + **重要なクエリを分離** – 重要なワークロードに必要なキャパシティを必要なときに確保するには、キャパシティ予約を作成し、そのワークグループをキャパシティ予約に割り当てます。割り当てたワークグループのクエリのみが、そのキャパシティ予約の処理容量を使用します。例えば、運用アプリケーションをサポートするクエリの実行の信頼性を確保するには、それらのクエリの運用ワークグループをキャパシティ予約に割り当てます。クエリを開発するときには、予約に関連付けられていない別個のワークグループを使用し、準備が整ったら運用ワークグループにクエリを移動させます。 + **同様のワークロード間でキャパシティを共有** – 1 つの予約のキャパシティを複数のワークロードで共有できます。これにより、これらのワークロードの予測可能なコストを達成し、それらの同時実行を制御できます。例えば、クエリ実行開始時刻の遅延に耐えられるようにワークロードをスケジュールした場合、それらのワークグループを 1 つの予約に割り当てることができます。これにより、同じアカウントで実行されるインタラクティブクエリの DDL クエリクォータと DML クエリクォータが解放され、これらのクエリが最小限の遅延で開始されます。 ## DPU を理解する キャパシティはデータ処理ユニット (DPU) で測定されます。DPU は、Athena がユーザーに代わってデータにアクセスして処理するために使用するサーバーレスのコンピューティングリソースとメモリリソースです。通常は、1 つの DPU で 4 個の vCPU と 16 GB のメモリを使用できます。保持している DPU の数によって、同時に実行できるクエリ数が決まります。例えば、DPU 256 個の予約では、DPU 128 個の予約の約 2 倍の同時クエリ数に対応できます。 キャパシティ要件の見積もりについては、「[キャパシティ要件を決定する](capacity-management-requirements.md)」を参照してください。料金については、「[Amazon Athena の料金](https://aws.amazon.com/athena/pricing/)」を参照してください。 ## 考慮事項と制限事項 + スキャンされたデータに基づいて、キャパシティ予約とクエリ単位の請求を同じアカウントで同時に使用できます。 + キャパシティ予約で実行されるクエリは、DDL クエリクォータと DML クエリクォータにはカウントされません。 + キャパシティが他のクエリの処理でビジー状態になっている場合、新たに送信されたクエリはキャパシティが利用可能になるまでキューに入れられます。キューの最大許容時間は 10 時間です。 + 1 つのキャパシティ予約に一度に割り当てることができるワークグループは 1 個です。1 つの予約に合計 20 個のワークグループを割り当てることができます。予約に複数のワークグループを割り当てると、キャパシティはワークグループ間で共有され、送信順序に基づいてクエリに割り当てられます。Athena がクエリにキャパシティを動的に割り当てる方法では、それが原因で実行順序にばらつきが生じる場合があります。 + Athena は、複雑さに基づいて DML クエリに 4～124 個の DPU を自動的に割り当てます。DDL クエリはそれぞれ 4 個の DPU を消費します。詳細については、次のトピックを参照してください。 + [キャパシティ要件を決定する](capacity-management-requirements.md) + [キャパシティ使用量を制御する](capacity-management-control-capacity-usage.md) + 各キャパシティ予約に必要な最小限の DPU 数は 4 個です。料金については、「[Amazon Athena の料金](https://aws.amazon.com/athena/pricing/)」を参照してください。 + アカウントとリージョンごとに、最大合計 1,000 個の DPU で最大 100 個のキャパシティ予約を作成できます。ユースケースに 1,000 個を超える DPU が必要な場合は、[athena-feedback@amazon.com](mailto:athena-feedback@amazon.com?subject=Athena Provisioned Capacity DPU Limit Request) までご連絡ください。 + キャパシティのリクエストは保証されないため、完了するまでに最大 30 分かかる場合があります。キャパシティを別のキャパシティ予約、AWS アカウント、または AWS リージョン に転送することはできません。 + `DPUConsumed` CloudWatch メトリクスは予約ごとではなく、ワークグループごとに対応します。そのため、ワークグループをある予約から別の予約に移動すると、そのワークグループが最初の予約に属していたときのデータが `DPUConsumed` メトリクスに含まれます。Athena の CloudWatch メトリクスの使用に関する詳細については、「[CloudWatch による Athena クエリメトリクスのモニタリング](query-metrics-viewing.md)」を参照してください。 + 予約に割り当てられているワークグループを削除するには、まず予約からワークグループを削除します。 + Apache Spark を使用するように設定されたワークグループはサポートされていません。 + キャパシティ予約は次の商用 AWS リージョン で利用できます。 + イスラエル (テルアビブ) + 中東 (アラブ首長国連邦) + 中東 (バーレーン) + アジアパシフィック (ニュージーランド) **Topics** + [DPU を理解する](#capacity-management-understanding-dpus) + [考慮事項と制限事項](#capacity-management-considerations-limitations) + [キャパシティ要件を決定する](capacity-management-requirements.md) + [キャパシティ予約を作成する](capacity-management-creating-capacity-reservations.md) + [キャパシティ使用量を制御する](capacity-management-control-capacity-usage.md) + [キャパシティを自動で調整する](capacity-management-automatically-adjust-capacity.md) + [予約を管理する](capacity-management-managing-reservations.md) + [キャパシティ予約の IAM ポリシー](capacity-reservations-iam-policy.md) + [Athena キャパシティ予約 API](capacity-management-api-list.md) # キャパシティ要件を決定する キャパシティ予約を作成する前に、必要なキャパシティを見積もることで、正しい数の DPU を割り当てることができます。また、予約の使用後は、予約のキャパシティが不足していないか、超過していないかを確認するとよいでしょう。このトピックでは、これらの見積もりに使用できる手法について説明し、使用状況とコストを評価するためのいくつかの AWS ツールについても説明します。 **Topics** + [必要なキャパシティを見積もる](#capacity-management-requirements-estimating) + [より多くのキャパシティが必要であることを示す兆候](#capacity-management-requirements-insufficient-capacity) + [アイドル状態のキャパシティを確認する](#capacity-management-requirements-idle-capacity) + [DPU 消費量のモニタリング](#capacity-management-requirements-monitoring-dpu-consumption) ## 必要なキャパシティを見積もる キャパシティ要件を見積もるときは、特定のクエリに必要なキャパシティと、一般的に必要なキャパシティという 2 つの観点を考慮すると効果的です。 ### クエリごとのキャパシティ要件を見積もる クエリで必要な DPU の数を判断するには、次のガイドラインを使用します。 + DDL クエリは 4 個の DPU を消費します。 + DML クエリは 4〜124 個の DPU を消費します。 Athena は、クエリが送信されるときに DML クエリに必要な DPU の数を決定します。この数は、データサイズ、ストレージ形式、クエリ構造、およびその他の要因によって変わります。通常、Athena は最も少なく、最も効率的な DPU 数を選択しようとします。Athena は、クエリを正常に完了するためにより多くの計算能力が必要であると判断した場合、クエリに割り当てられる DPU の数を増やします。 ### ワークロード固有のキャパシティ要件を見積もる 複数のクエリを同時に実行するために必要な容量を判断するには、次の表にある一般ガイドラインを考慮してください。 **** | 同時クエリ | 必要な DPU | | --- | --- | | 10 | 40 またはそれ以上 | | 20 | 96 以上 | | 30 またはそれ以上 | 240 以上 | 実際に必要な DPU の数は、目標と分析パターンによって異なることに注意してください。たとえば、クエリをキューに入れずにすぐに開始したい場合は、ピーク時の同時クエリ需要を判断し、それに応じて DPU の数をプロビジョニングします。 プロビジョニングする DPU の数は、ピーク需要よりも少なくても構いませんが、ピーク需要が発生するとキューイングが発生する可能性があります。キューイングが発生すると、Athena はクエリをキューに保持し、キャパシティが利用可能になるとクエリを実行します。 固定予算内でクエリを実行することが目標であれば、「[AWS 料金計算ツール](https://calculator.aws/#/addService/Athena)」を使って予算に合う DPU 数を特定できます。 最後に、データサイズ、ストレージ形式、およびクエリの記述方法が、クエリに必要な DPU に影響することを覚えておいてください。データを圧縮または分割したり、列形式に変換したりすることで、クエリのパフォーマンスを向上させることができます。詳細については、「[Athena のパフォーマンスを最適化する](performance-tuning.md)」を参照してください。 ## より多くのキャパシティが必要であることを示す兆候 割り当てられたキャパシティが不十分であることの 2 つの兆候として、キャパシティ不足のエラーメッセージとクエリキューイングがあります キャパシティ不足のエラーメッセージが表示されてクエリが失敗した場合、クエリに対してキャパシティ予約の DPU 数が少なすぎる可能性があります。たとえば、DPU 24 個の予約があり、24 個よりも多い DPU を必要とするクエリを実行すると、クエリは失敗します。Athena の [EventBridge イベント](athena-events.md)を使用してこのクエリエラーを監視することができます。DPU をさらに追加してクエリを再実行してみてください。 多くのクエリがキューに入っている場合は、キャパシティがすべて他のクエリに使用されていることを意味します。キューを減らすには、次のいずれかの操作を行います。 + 予約に DPU を追加して、クエリの同時実行性を向上させます。 + 予約からワークグループを削除して、他のクエリに使えるキャパシティを増やします。 キャパシティ予約内のワークグループ内で Athena クエリキュー時間の [CloudWatch メトリック](query-metrics-viewing.md)を使用して、クエリキューイングが過剰になっていないかどうかを確認します。値が希望のしきい値を超える場合は、キャパシティ予約に DPU を追加します。 ## アイドル状態のキャパシティを確認する アイドル状態のキャパシティを確認するには、予約内の DPU の数を減らすか、ワークロードを増やしてから結果を確認します。 **アイドル状態のキャパシティを確認するには** 1. 次のいずれかを行います。 + 予約内の DPU の数を減らします (利用可能なリソースを減らす)。 + 予約にワークグループを追加します (ワークロードを増やす)。 1. [CloudWatch](query-metrics-viewing.md) を使用してクエリキュー時間を測定します。 1. キュー時間が望ましいレベルを超えて増加した場合は、次のいずれかの操作を行います。 + ワークグループを削除します。 + キャパシティ予約に DPU を追加します。 1. 変更のたびに、パフォーマンスとクエリキュー時間を確認します。 1. 引き続きワークロードや DPU 数を調整して、望ましいバランスをとってください。 望ましい時間を超えるキャパシティを維持したくない場合は、予約を[キャンセル](capacity-management-cancelling-a-capacity-reservation.md)して後で別の予約を作成します。ただし、最近別の予約からキャパシティをキャンセルしていたとしても、新しいキャパシティのリクエストが保証されるわけではなく、新しい予約の作成には時間がかかります。 ## DPU 消費量のモニタリング クエリの実行後、クエリによって消費される DPU を表示して、容量の見積もりを絞り込むことができます。Athena は、コンソール、API オペレーション、CloudWatch を通じて DPU 消費メトリクスを提供します。この情報から、リソースの消費量が予想よりも多いクエリや少ないクエリを特定し、実際のデータに基づいて容量の割り当てを最適化することができます。DPU の消費量の表示と追跡の詳細については、「[DPU 使用をモニタリングする](capacity-management-control-capacity-usage.md#capacity-management-monitor-dpu-usage)」を参照してください。 ## キャパシティ要件とコストを評価するためのツール AWS の以下のサービスと機能を使用して、Athena の使用状況とコストを測定できます。 ### CloudWatch メトリクス クエリ関連のメトリックスをワークグループレベルで Amazon CloudWatch に公開するように Athena を設定できます。ワークグループのメトリックスを有効にすると、ワークグループのクエリに関するメトリックスがワークグループの詳細ページの Athena コンソールに表示されます。 CloudWatch に公開される Athena メトリックスとそのディメンションについては、「[CloudWatch による Athena クエリメトリクスのモニタリング](query-metrics-viewing.md)」を参照してください。 ### CloudWatch の使用状況メトリクス CloudWatch の使用状況メトリクスにより、CloudWatch グラフやダッシュボード上に現在のサービスの使用状況を表示することで、アカウントがどのようにリソースを使用しているかを可視化できます。Athena での使用可能性に関するメトリクスは、Athena の AWS[Service Quotas](service-limits.md) と対応しています。使用量がサービスクォータに近づいたときに警告するアラームを設定することもできます。 詳細については、「[CloudWatch による Athena 使用状況メトリクスのモニタリング](monitoring-athena-usage-metrics.md)」を参照してください。 ### Amazon EventBridge イベント Amazon Athena を Amazon EventBridge と使用し、クエリの状態に関するリアルタイムの通知を受け取ることができます。送信したクエリの状態が変更されると、Athena がそのクエリの状態推移に関する情報が含まれるイベントを EventBridge に発行します。関心のあるイベントのシンプルなルールを作成し、イベントがルールに一致したときに自動化されたアクションが実行されるようにできます。 詳細については、以下のリソースを参照してください。 + [EventBridge を使用して Athena クエリ イベントをモニタリングする](athena-events.md) + [Amazon EventBridge とは](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) + [Amazon EventBridge イベント](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html) ### タグ Athena では、キャパシティ予約がタグをサポートしています。タグは、キーと値から構成されています。Athena でコストを追跡するには、AWS 生成のコスト配分タグを使用できます。AWS はコスト配分タグを使用し、[[コストと使用状況のレポート]](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) でリソースのコストを整理します。これにより、AWS コストを簡単に分類して追跡できるようになります。Athena のコスト配分タグを有効にするには、[AWS Billing and Cost Management コンソール](https://console.aws.amazon.com/billing/)を使用します。 詳細については、以下のリソースを参照してください。 + [Athena リソースにタグ付けする](tags.md) + [AWS 生成のコスト配分タグをアクティブ化する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activate-built-in-tags.html) + [AWS コスト配分タグを使用する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) # キャパシティ予約を作成する まず、必要な数の DPU を含むキャパシティ予約を作成し、そのキャパシティをクエリに使用する 1 つ以上のワークグループを割り当てます。安定したパフォーマンスの提供や、コスト管理改善のために、必要に応じて後からキャパシティを調整できます。キャパシティ要件の見積もりについては、「[キャパシティ要件を決定する](capacity-management-requirements.md)」を参照してください。 **重要** キャパシティのリクエストは保証されないため、完了するまでに最大 30 分かかる場合があります。 **キャパシティ予約を作成するには** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。 1. **[管理]**、**[キャパシティ予約]** を選択します。 1. **[キャパシティ予約を作成]** を選択します。 1. **[キャパシティ予約を作成]** ページの **[キャパシティ予約名]** に名称を入力します。名称は一意でなくてはならず、1～128 文字で、a～z、A～Z、0～9、\$1 (アンダースコア)、. (ピリオド)、- (ハイフン)が使用できます。予約作成後に名称を変更することはできません。 1. **DPU** では、必要なデータ処理ユニット (DPU) の数を 4 個単位で選択または入力します。詳細については、「[DPU を理解する](capacity-management.md#capacity-management-understanding-dpus)」を参照してください。 1. (オプション) **[タグ]** オプションを展開し、**[新しいタグを追加]** を選択し、キャパシティ予約リソースに関連付ける 1 つ以上のカスタムキー/値ペアを追加します。詳細については、「[Athena リソースにタグ付けする](tags.md)」を参照してください。 1. **[Review]** (レビュー) を選択します。 1. **[キャパシティ予約の作成を確認]** プロンプトで、DPU の数、AWS リージョン、その他の情報を確認します。 q 問題がなければ、**[送信]** を選択します。 詳細ページでは、キャパシティ予約の **[ステータス]** は **[保留中]** と表示されます。予約キャパシティでクエリを実行できる場合、そのステータスは **[アクティブ]** と表示されます。 この時点で、1 つ以上のワークグループを予約に追加する準備が整っています。手順については、「[予約にワークグループを追加する](capacity-management-adding-workgroups-to-a-reservation.md)」を参照してください。 # キャパシティ使用量を制御する Athena がクエリに割り当てる DPU の数は、最大または最小の DPU コントロールを設定することで制御できます。すべてのクエリのベースラインコントロールを確立する場合はワークグループレベルでこれらを設定でき、きめ細かなコントロールを求める場合は個々のクエリレベルで設定できます。これにより、クエリのパフォーマンス、ワークロードの同時実行数、コストを直接制御できます。 + DPU 数を最大に設定すると、クエリによるキャパシティ消費量が指定した量を超えません。これにより、コストとワークロードの同時実行を簡単に制御できます。例えば、キャパシティ予約に DPU が 200 個ある場合、クエリ 1 件あたりの最大 DPU 数を 8 に設定すると、25 件のクエリを同時に実行できます。予約の DPU を 400 に増やすと、50 件のクエリを同時に実行できます。 + DPU 数を最小に設定すると、希望する最小数の DPU でクエリが実行されます。これは、クエリの一般的なキャパシティ使用プロファイルを事前に把握している場合に役立ちます。 **注記** DPU 使用コントロールは、キャパシティ予約で実行されるクエリにのみ適用されます。 **注記** すべてのクエリに同じ数の DPU を使用するには、最小 DPU と最大 DPU に同じ値を使用します。 ## ワークグループレベルで DPU コントロールを設定する DPU コントロールをワークグループレベルで設定して、コストを管理し、選択したワークグループのワークロードパフォーマンスを制御します。ワークグループレベルで設定された DPU コントロールは、**[クライアント側設定の上書き]** が有効になっている場合、すべてのクエリに適用されます。 **コンソールを使用して DPU コントロールを設定する方法** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. ナビゲーションペインで、**[Global networks (グローバルネットワーク)]** を選択します。 1. キャパシティ予約を使用するワークグループを選択します。 1. **[実行コントロール]** タブで、**[コントロールの編集]** を選択します。 1. 次を設定します。 + **[クエリあたりの最小 DPU]** では、4～124 の範囲内の値を 4 単位で入力します。 + **[クエリあたりの最大 DPU]** では、4～124 の範囲内の値を 4 単位で入力します。 1. **[保存]** を選択します。 1. （オプション）**[クライアント側設定の上書き]** を選択してこれらの設定を適用し、クエリレベルの DPU 設定を無視します。 **AWS CLI を使用して DPU コントロールを設定する方法** + `update-work-group` コマンドを使用してワークグループの DPU コントロールを設定します。 ``` aws athena update-work-group \ --work-group my_workgroup \ --configuration-updates '{ "EngineConfiguration": { "Classifications": [ { "Name": "athena-query-engine-properties", "Properties": { "max-dpu-count" : "24", "min-dpu-count" : "12" } } ] }}' ``` `EnforceWorkGroupConfiguration` を `true` に設定すると、ワークグループ設定は、[StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html) 経由で送信したときにクエリレベルで指定された DPU コントロールを上書きします。これにより、ワークグループ内のすべてのクエリにおけるリソース割り当ての一貫性が確保されます。 ## 個々のクエリで DPU コントロールを設定する クエリにさまざまなリソース要件があってきめ細かな制御が必要である場合は、クエリレベルの DPU コントロールを設定します。ワークグループで **[クライアント側設定の上書き]** が有効になっていない限り、クエリレベルの DPU コントロールはワークグループレベルの設定よりも優先されます。 **コンソールを使用してクエリの DPU コントロールを設定する方法** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. ナビゲーションペイン内で **[クエリエディタ]** を選択します。 1. キャパシティ予約を使用するワークグループを選択します。 1. **[クエリ設定]** タブを選択します。 1. **[実行コントロール]** セクションで、**[コントロールの編集]** を選択します。 1. 次を設定します。 + **[クエリあたりの最小 DPU]** では、4～124 の範囲内の値を 4 単位で入力します。 + **[クエリあたりの最大 DPU]** では、4～124 の範囲内の値を 4 単位で入力します。 1. **[保存]** を選択します。 **AWS CLI を使用してクエリの DPU コントロールを設定する方法** + `engine-configuration` パラメータがある `start-query-execution` コマンドを使用します。 ``` aws athena start-query-execution \ --query-string "SELECT * FROM my_table LIMIT 10" \ --work-group "my_workgroup" \ --engine-configuration '{ "Classifications": [ { "Name": "athena-query-engine-properties", "Properties": { "max-dpu-count" : "32", "min-dpu-count" : "8" } } ]}' ``` クエリレベルとワークグループレベルの DPU 設定の関係は、ワークグループ設定によって異なります。 + **[クライアント側設定の上書き]** が有効になっている場合、ワークグループレベルの DPU コントロールは、クエリレベルの設定よりも優先されます。これにより、指定したワークグループ内のすべてのクエリにおけるリソース使用の一貫性が確保されます。 + **[クライアント側設定の上書き]** が有効になっていない場合、クエリレベルの DPU コントロールがワークグループレベルの設定よりも優先されます。これにより、個々のクエリを柔軟に最適化できます。 どちらのレベルでも DPU コントロールを指定しない場合、Athena がクエリの複雑さに基づいてキャパシティを自動的に割り当てます。 **注記** DDL クエリの場合、最小 DPU の最大値は 4 です。DDL クエリの最小値を大きめに設定するとエラーが発生します。 ## DPU 使用をモニタリングする クエリが完了したら、DPU の使用状況を表示できます。Athena は、コンソール、API オペレーション、CloudWatch を通じて DPU 使用メトリクスを提供します。 **コンソールで DPU 消費量を表示する方法** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. ナビゲーションペイン内で **[クエリエディタ]** を選択します。 1. クエリが完了したら、クエリ結果コンテナで **[消費された DPU]** 値を表示します。 1. 過去のクエリの DPU 消費量を表示する方法 1. ナビゲーションペインで **[最近のクエリ]** を選択します。 1. **[消費された DPU]** 列がテーブルにまだ表示されていない場合は、設定アイコンを選択してその列を追加します。 1. 完了した各クエリの DPU 消費量を確認します。 1. 必要に応じて、**[クエリエディタ]** から **[クエリ統計]** タブを選択し、**[消費された DPU]** を確認します。 **API を使用して DPU 消費量を取得する方法** 1. 次の API オペレーションを使用して、DPU 消費量をプログラムで取得します。 + `GetQueryExecution` - 特定のクエリの実行の詳細情報を返す + `BatchGetQueryExecution` - 複数のクエリの実行の詳細情報を返す 1. AWS CLI を使用する例: ``` aws athena get-query-execution \ --query-execution-id "123e4567-e89b-12d3-a456-426614174000" ``` 応答には `Statistics` オブジェクトの `DpuCount` フィールドが含まれます。 ``` { "QueryExecution": { "Statistics": { "DpuCount": 8 } } } ``` **CloudWatch で DPU 使用をモニタリングする方法** + Athena は、キャパシティ使用率などのパフォーマンスデータのモニタリングに役立つクエリ関連メトリクスを CloudWatch に発行します。詳細については「[CloudWatch による Athena クエリメトリクスのモニタリング](query-metrics-viewing.md)」を参照してください。 # キャパシティを自動で調整する Athena の自動スケーリングソリューションを使用すれば、ワークロード使用率に応じて予約のキャパシティを自動で調整できます。使用率が設定したしきい値を超えると自動的に容量が追加され、使用率が低い間は容量を削除してコストを削減します。さまざまな使用率しきい値、最小 DPU 量と最大 DPU 量、スケーリング増分、使用率評価頻度を設定することで、動作をカスタマイズできます。これにより、パフォーマンス要件とコスト最適化のバランスを取りながら、手動で容量を調整する必要がなくなります。 CloudFormation テンプレートを使用してこのサーバーレスソリューションをデプロイします。使用率メトリクスをモニタリングしてスケーリングを決定する Step Functions ステートマシンが作成されます。テンプレートまたはステートマシンは、特定のニーズに合わせてさらにカスタマイズすることができます。 開始するには、Athena コンソールを使用して、キャパシティ予約の詳細ページで **[自動スケーリングの設定]** を選択します。これにより、あらかじめテンプレートがロードされている CloudFormation にリダイレクトされます。または、以下の手順に従います。 ## 前提条件 + アクティブなキャパシティ予約が必要 + CloudFormation スタックのデプロイと Step Functions リソースの作成に必要な IAM 許可 ## CloudFormation スタックを起動する この自動 CloudFormation テンプレートによって、Athena キャパシティ予約の自動スケーリングソリューションがデプロイされます。スタックを起動する前に、[前提条件](#capacity-management-auto-scaling-prerequisites) で該当するステップを完了する必要があります。 [https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?&templateURL=https:%2F%2Fathena-downloads.s3.us-east-1.amazonaws.com%2F%2Ftemplates%2F%2Fcapacity-reservation-scaling%2F%2Fstate-machine%2F%2Fathena-capacity-reservation-scaling-template-v1.1.yaml](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?&templateURL=https:%2F%2Fathena-downloads.s3.us-east-1.amazonaws.com%2F%2Ftemplates%2F%2Fcapacity-reservation-scaling%2F%2Fstate-machine%2F%2Fathena-capacity-reservation-scaling-template-v1.1.yaml) **自動スケーリングソリューションを起動する方法** 1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)にサインインして、`AWSAccelerator-InstallerStack` CloudFormation テンプレートを起動するボタンを選択します。 1. テンプレートはデフォルトで米国東部 (バージニア北部) で起動します。別の AWS リージョンでこのソリューションを起動するには、コンソールのナビゲーションバーのリージョンセレクターを使用します。 1. **[スタックの作成]** ページで、テンプレート URL が **[Amazon S3 URL]** テキストボックスに表示されていることを確認し、**[次へ]** を選択します。 1. **[スタックの詳細を指定]** ページで、ソリューションのスタックに名前を割り当てます。 1. **[パラメータ]** で、このソリューションのテンプレートパラメータを確認し、必要に応じて変更します。このソリューションでは、次のデフォルト値を使用します。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/capacity-management-automatically-adjust-capacity.html) **注記** Athena のキャパシティ予約要件に合わせるために、すべての DPU 値を 4 の倍数にする必要があります。 1. **[次へ]** を選択します。 1. **[スタックオプションの設定]** ページで、**[次へ]** を選択します。 1. **[確認および作成]** ページで、設定を確認して確定します。テンプレートによって IAM のリソースが作成されることを承認するチェックボックスをオンにします。 1. **[送信]** を選択してスタックをデプロイします。 スタックのステータスは、CloudFormation コンソールの **[ステータス]** 列で確認できます。数分で `CREATE_COMPLETE` ステータスが表示されます。 # 予約を管理する **[キャパシティ予約]** ページでは、キャパシティ予約を表示および管理できます。DPU の追加や削減、ワークグループ割り当ての変更、予約のタグ付けやキャンセルなどの管理タスクを実行できます。 **キャパシティ予約の表示および管理** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。 1. **[管理]**、**[キャパシティ予約]** を選択します。 1. [キャパシティ予約] ページでは、次のタスクを実行できます。 + キャパシティ予約を作成するには、**[キャパシティ予約を作成]** を選択します。 + 検索ボックスを使用して、予約を名前または DPU の数でフィルタリングします。 + ステータスドロップダウンメニューを選択して、キャパシティ予約ステータス (**[アクティブ]**、**[キャンセル済み]** など) でフィルタリングします。予約ステータスについては、「[予約ステータスを把握する](#capacity-management-understanding-reservation-status)」を参照してください。 + キャパシティ予約の詳細を表示するには、予約のリンクを選択します。予約の詳細ページには、[[キャパシティの編集](capacity-management-editing-capacity-reservations.md)]、[[ワークグループの追加](capacity-management-adding-workgroups-to-a-reservation.md)]、[[ワークグループの削除](capacity-management-removing-a-workgroup-from-a-reservation.md)]、[[予約のキャンセル](capacity-management-cancelling-a-capacity-reservation.md)] のオプションがあります。 + 予約を編集 (DPU を追加または削除するなど) するには、その予約のボタンを選択し、**[編集]** を選択します。 + 予約をキャンセルするには、その予約のボタンを選択し、**[キャンセル]** を選択します。 ## 予約ステータスを把握する キャパシティ予約の取りうるステータス値は、次の表のとおりです。 **** | ステータス | 説明 | | --- | --- | | [保留中] | Athena はキャパシティリクエストを処理中です。キャパシティはクエリを実行する準備ができていません。 | | アクティブ | クエリを実行するためのキャパシティがあります。 | | 失敗 | キャパシティのリクエストは正常に完了しませんでした。キャパシティの充足は保証されないことに注意してください。予約に失敗した場合、アカウントの DPU 制限にカウントされます。利用状況を解放するには、予約をキャンセルする必要があります。 | | [更新保留中] | Athena は予約の変更を処理中です。例えば、予約を編集して DPU を追加または削除すると、このステータスが表示されます。 | | [キャンセル中] | Athena は予約のキャンセルリクエストを処理中です。予約を使用していたワークグループでまだ実行中のクエリは完了できますが、ワークグループ内の他のクエリはオンデマンド (プロビジョニングされていない) キャパシティを使用します。 | | キャンセル済み | キャパシティ予約のキャンセルが完了しました。キャンセルされた予約は、45 日間コンソールに残ります。45 日後、Athena は予約を削除します。この 45 日間は、その予約の編集や再使用はできませんが、過去の参照用に予約のタグを参照したり、詳細を確認したりすることはできます。 キャンセルされたキャパシティが後日再予約可能になる保証はありません。キャパシティを別の予約、AWS アカウント、AWS リージョン に移すことはできません。 | ## アクティブ DPU とターゲット DPU を理解する Athena コンソールのキャパシティ予約のリストで、予約には 2 つの DPU 値 (**[アクティブ DPU]** と **[ターゲット DPU]**) が表示されます。 + **[アクティブ DPU]** — 予約内でクエリを実行できる DPU の数。例えば、DPU 100 個をリクエストし、そのリクエストが受理された場合、**[アクティブ DPU]** には **100** と表示されます。 + **[ターゲット DPU]** — 予約の移行先の DPU の数。予約の作成中、または DPU 数の増減が保留中の場合、**[ターゲット DPU]** には **[アクティブ DPU]** とは異なる値が表示されます。 例えば、DPU 24 個の予約を作成するリクエストを送信すると、**[ステータス]** は **[保留中]** になり、**[アクティブ DPU]** は **0**、**[ターゲット DPU]** は **24** になります。 DPU 100 個の予約があり、予約を編集して DPU 20 個の増加をリクエストした場合、**[ステータス]** は**[更新保留中]** になり、**[アクティブ DPU]** は **100**、**[ターゲット DPU]** は **120** になります。 DPU 100 個の予約があり、予約を編集して DPU 20 個の削減をリクエストした場合、**[ステータス]** は**[更新保留中]** になり、**[アクティブ DPU]** は **100**、**[ターゲット DPU]** は **80** になります。 これらの移行中、Athena はリクエストに応じて DPU の取得または削減を能動的に行っています。**[アクティブ DPU]** が **[ターゲット DPU]** と等しい時は、目標数に達しており、保留中の変更はありません。 これらの値をプログラムで取得するには、[GetCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityReservation.html) API アクションを呼び出します。API では、**[アクティブ DPU]** および **[ターゲット DPU]** をそれぞれ、`AllocatedDpus` および `TargetDpus` と呼びます。 **Topics** + [予約ステータスを把握する](#capacity-management-understanding-reservation-status) + [アクティブ DPU とターゲット DPU を理解する](#capacity-management-understanding-dpu-status) + [キャパシティ予約を編集する](capacity-management-editing-capacity-reservations.md) + [予約にワークグループを追加する](capacity-management-adding-workgroups-to-a-reservation.md) + [予約からワークグループを削除する](capacity-management-removing-a-workgroup-from-a-reservation.md) + [キャパシティ予約をキャンセルする](capacity-management-cancelling-a-capacity-reservation.md) + [キャパシティ予約を削除する](capacity-management-deleting-a-capacity-reservation.md) # キャパシティ予約を編集する キャパシティ予約を作成したら、DPU の数を調整したり、カスタムタグを追加または削除したりできます。 **キャパシティ予約を編集するには** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。 1. **[管理]**、**[キャパシティ予約]** を選択します。 1. キャパシティ予約のリストで、次のいずれかを実行します。 + 予約の横にあるボタンを選択し、**[編集]** を選択します。 + 予約リンクを選択し、**[編集]** を選択します。 1. **DPU** の場合は、必要なデータ処理ユニットの数を選択または入力します。詳細については、「[DPU を理解する](capacity-management.md#capacity-management-understanding-dpus)」を参照してください。 **注記** DPU はアクティブなキャパシティ予約にいつでも追加できます。 予約がアクティブになってから 1 分が経過したとき、または DPU が最後に追加されたときは、アクティブなキャパシティ予約から DPU を減らすようにリクエストできます。 DPU の削減をリクエストすると、Athena はアクティブな DPU よりもアイドル状態の DPU の削除を優先します。削除対象としてマークされた DPU をクエリが消費している場合、Athena は クエリが完了するまで待機してから、DPU を削除します。 1. (オプション) **[タグ]** で、**[削除]** を選択してタグを削除するか、**[タグの追加]** を選択して新しいタグを追加します。 1. **[送信]** を選択します。予約の詳細ページには、更新された構成が表示されます。 # 予約にワークグループを追加する キャパシティ予約を作成すると、予約に最大 20 のワークグループを追加できます。予約にワークグループを追加すると、リザーブドキャパシティでどのクエリを実行すべきかを Athena に伝えます。予約に関連付けられていないワークグループからのクエリは、引き続きテラバイト (TB) ごとのスキャン済みデフォルト価格モデルを使用して実行されます。 予約に 2 つ以上のワークグループがある場合、それらのワークグループからのクエリはリザーブドキャパシティを使用できます。ワークグループの追加と削除は随時行うことができます。ワークグループを追加または削除しても、実行中のクエリは中断されません。 予約が保留中ステータスの場合、追加したワークグループからのクエリは、予約がアクティブになるまで、引き続きテラバイト (TB) ごとのスキャン済みデフォルト価格モデルを使用して実行されます。 **キャパシティ予約に 1 つ以上のワークグループを追加するには** 1. [キャパシティ予約] の詳細ページで、**[ワークグループの追加]** を選択します。 1. **[ワークグループの追加]** ページで、追加するワークグループを選択し、**[ワークグループの追加]** を選択します。1 つのワークグループを複数の予約に割り当てることはできません。 [キャパシティ予約] の詳細ページに、追加したワークグループが表示されます。これらのワークグループで実行されるクエリは、予約がアクティブなときに、予約したキャパシティを使用します。 # 予約からワークグループを削除する ワークグループ専用のキャパシティが不要になった場合や、ワークグループを専用の予約に移動したい場合は、いつでも削除できます。予約からワークグループを削除するプロセスは簡単です。予約からワークグループを削除すると、削除されたワークグループからのクエリはオンデマンドキャパシティの使用に戻り、スキャンされたテラバイト（TB）に基づいて請求されます。 **予約から 1 つ以上のワークグループを削除するには** 1. キャパシティ予約の詳細ページで、削除するワークグループを選択します。 1. **[ワークグループを削除]** を選択します。**[ワークグループを削除しますか？]** のプロンプトが表示され、ワークグループを予約から削除する前に、現在アクティブなクエリがすべて終了することを通知します。 1. **[**を削除] を選択します。キャパシティ予約の詳細ページには、削除されたワークグループがもう存在しないことが表示されます。 # キャパシティ予約をキャンセルする キャパシティ予約が不要になった場合は、キャンセルすることができます。予約を使用していたワークグループでまだ実行中のクエリは完了できますが、ワークグループ内の他のクエリは予約を使用しなくなります。 **注記** キャンセルされたキャパシティが後日再予約可能になる保証はありません。キャパシティを別の予約、AWS アカウント、AWS リージョン に移すことはできません。 **キャパシティ予約をキャンセルするには** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。 1. **[管理]**、**[キャパシティ予約]** を選択します。 1. キャパシティ予約のリストで、次のいずれかを実行します。 + 予約の横にあるボタンを選択し、**[キャンセル]** を選択します。 + [予約リンク] を選択してから、**[キャパシティ予約のキャンセル]** を選択します。 1. **[キャパシティ予約をキャンセルしますか？]** プロンプトで **[キャンセル]** を入力し、**[キャパシティ予約のキャンセル]** を選択します。 予約のステータスが **[キャンセル中]** に変わり、キャンセルが進行中であることを知らせる進行状況バナーが表示されます。 キャンセルが完了すると、キャパシティ予約はそのまま残りますが、ステータスは **[キャンセル済み]** と表示されます。予約はキャンセル後 45 日で削除されます。この 45 日間は、キャンセルされた予約を編集したり再利用したりすることはできませんが、タグを参照、表示して、過去の履歴を参照することはできます。 # キャパシティ予約を削除する キャンセルされたキャパシティ予約への参照をすべて削除したい場合は、予約を削除できます。予約は削除する前にキャンセルする必要があります。削除された予約はアカウントから直ちに削除され、参照できなくなります (ARN を使用する場合を含む)。 **キャパシティ予約を削除するには** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。 1. **[管理]**、**[キャパシティ予約]** を選択します。 1. キャパシティ予約のリストで、次のいずれかを実行します。 + キャンセルされた予約の横にあるボタンを選択し、**[アクション]**、**[削除]** の順に選択します。 + 予約リンクを選択し、**[削除]** を選択します。 1. **[キャパシティ予約を削除しますか?]** プロンプトが表示されたら、**[削除]** を選択します。 バナーは、キャパシティ予約が正常に削除されたことを通知します。削除された予約は、キャパシティ予約のリストに表示されなくなります。 # キャパシティ予約の IAM ポリシー キャパシティ予約へのアクセスを制御するには、リソースレベルの IAM 許可、またはアイデンティティベースの IAM ポリシーを使用します。IAM ポリシーを使用するときは、常に IAM のベストプラクティスに従うようにしてください。詳細については、*IAM ユーザーガイド*の「[IAM でのセキュリティベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 以下の手順は、Athena に固有の手順です。 IAM 固有の情報については、このセクションの最後に表示されているリンク先を参照してください。JSON キャパシティ予約ポリシーの例についての情報は、「[キャパシティ予約ポリシーの例](example-policies-capacity-reservations.md)」を参照してください。 **IAM コンソールのビジュアルエディタを使用してキャパシティ予約ポリシーを作成するには** 1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. 左側のナビゲーションペインで、[**Policies**] (ポリシー)、[**Create policy**] (ポリシーの作成) の順にクリックします。 1. [**Visual editor**] (ビジュアルエディタ) タブで、[**Choose a service**] (サービスの選択) をクリックします。次に、ポリシーに追加する Athena を選択します。 1. **[Select actions]** (アクションの選択) を選択し、ポリシーに追加するアクションを選択します。ビジュアルエディタが Athena で利用できるアクションを表示します。詳細については、「*サービス承認リファレンス*」の「[Amazon Athena のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html)」を参照してください。 1. **[アクションの追加]** を選択して特定のアクションを入力、またはワイルドカード文字 (\$1) を使用して複数のアクションを指定します。 デフォルトでは、作成しているポリシーが選択するアクションを許可します。Athena 内の `capacity-reservation` リソースに対するリソースレベルのアクセス許可をサポートするアクションを 1 つ、または複数選択すると、エディタが `capacity-reservation` リソースをリストします。 1. **[リソース]** を選択し、ポリシーに関する特定のキャパシティ予約を指定します。JSON キャパシティ予約ポリシーの例については、「[キャパシティ予約ポリシーの例](example-policies-capacity-reservations.md)」を参照してください。 1. 以下のように `capacity-reservation` リソースを指定します。 ``` arn:aws:athena:::capacity-reservation/ ``` 1. **[Review policy]** (ポリシーの確認) をクリックして、作成するポリシーの **[Name]** (名前) と **[Description**] (説明) (オプション) を入力します。ポリシー概要を確認して、意図したアクセス許可を付与したことを確認します。 1. **[Create Policy]** (ポリシーの作成) をクリックして、新しいポリシーを保存します。 1. このアイデンティティベースのポリシーをユーザー、グループ、またはロールにアタッチします。 詳細については、「*サービス認可リファレンス*」と「*IAM ユーザーガイド*」で以下のトピックを参照してください。 + [Amazon Athena のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html) + [ビジュアルエディタでのポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-visual-editor) + [IAM ポリシーの追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) + [リソースへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-resources) JSON キャパシティ予約ポリシーの例については、「[キャパシティ予約ポリシーの例](example-policies-capacity-reservations.md)」を参照してください。 Amazon Athena アクションの完全なリストについては、「[Amazon Athena API リファレンス](https://docs.aws.amazon.com/athena/latest/APIReference/)」の API アクション名を参照してください。 # キャパシティ予約ポリシーの例 このセクションには、キャパシティ予約に対するさまざまなアクションを有効にするために使用できるポリシーの例が含まれています。IAM ポリシーを使用するときは、常に IAM のベストプラクティスに従うようにしてください。詳細については、「*IAM ユーザーガイド*」の「[IAM でのセキュリティベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 キャパシティ予約は、Athena で管理されている IAM リソースです。そのため、キャパシティ予約ポリシーで `capacity-reservation` を入力として取るアクションを使用する場合、キャパシティ予約の ARN を次のように指定する必要があります: ``` "Resource": [arn:aws:athena:::capacity-reservation/] ``` `` の場所はキャパシティ予約の名前です。たとえば、`test_capacity_reservation` という名前のキャパシティ予約の場合は、次のようにリソースとして指定します: ``` "Resource": ["arn:aws:athena:us-east-1:123456789012:capacity-reservation/test_capacity_reservation"] ``` Amazon Athena アクションの完全なリストについては、「[Amazon Athena API リファレンス](https://docs.aws.amazon.com/athena/latest/APIReference/)」の API アクション名を参照してください。IAM ポリシーの詳細については、「*IAM ユーザーガイド*」で「[ビジュアルエディタでのポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-visual-editor)」を参照してください。 **Example キャパシティ予約を一覧表示するポリシーの例** 次のポリシーによって、すべてのユーザーがすべてのキャパシティ予約を一覧表示できるようになります。 **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListCapacityReservations" ], "Resource": "*" } ] } ``` **Example 管理オペレーションに関するポリシーの例** 次のポリシーによって、ユーザーはキャパシティ予約 `test_capacity_reservation` を作成、キャンセル、更新、その詳細を取得できます。また、このポリシーによって、ユーザーは `workgroupA` と`workgroupB` を`test_capacity_reservation` に割り当てられます。 **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect": "Allow", "Action": [ "athena:CreateCapacityReservation", "athena:GetCapacityReservation", "athena:CancelCapacityReservation", "athena:UpdateCapacityReservation", "athena:GetCapacityAssignmentConfiguration", "athena:PutCapacityAssignmentConfiguration" ], "Resource": [ "arn:aws:athena:us-east-1:123456789012:capacity-reservation/test_capacity_reservation", "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA", "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupB" ] } ] } ``` # Athena キャパシティ予約 API 次のリストには、Athena キャパシティ予約 API アクションへの参照リンクが含まれています。データ構造とその他の Athena API アクションについては、「[Amazon Athena API リファレンス](https://docs.aws.amazon.com/athena/latest/APIReference/)」を参照してください。 + [CancelCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_CancelCapacityReservation.html) + [CreateCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateCapacityReservation.html) + [DeleteCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_DeleteCapacityReservation.html) + [GetCapacityAssignmentConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityAssignmentConfiguration.html) + [GetCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityReservation.html) + [ListCapacityReservations](https://docs.aws.amazon.com/athena/latest/APIReference/API_ListCapacityReservations.html) + [PutCapacityAssignmentConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_PutCapacityAssignmentConfiguration.html) + [UpdateCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_UpdateCapacityReservation.html) # Athena のパフォーマンスを最適化する このトピックでは、Athena クエリのパフォーマンスを向上させるための一般的な情報と具体的な提案、および制限やリソース使用量に関連するエラーの回避方法について説明します。 大まかには、最適化は、サービス、クエリ、データ構造のカテゴリにグループ化できます。サービスレベルで行われた決定、クエリの記述方法に関する決定、データとテーブルの構造に関する決定はすべてパフォーマンスに影響を及ぼす可能性があります。 **Topics** + [サービスの利用を最適化する](performance-tuning-service-level-considerations.md) + [クエリを最適化する](performance-tuning-query-optimization-techniques.md) + [データを最適化する](performance-tuning-data-optimization-techniques.md) + [列指向ストレージ形式を使用する](columnar-storage.md) + [パーティショニングとバケット化を使用する](ctas-partitioning-and-bucketing.md) + [データのパーティション化](partitions.md) + [Amazon Athena でパーティション射影を使用する](partition-projection.md) + [Amazon S3 のスロットリングを防ぐ](performance-tuning-s3-throttling.md) + [追加リソース](performance-tuning-additional-resources.md) # サービスの利用を最適化する サービスレベルに関する考慮事項には、アカウントごとに実行するワークロードの数、Athena だけでなくサービス全体でのサービスクォータ、「リソース不足」エラーを減らす方法の検討が含まれます。 **Topics** + [同じアカウント内で複数のワークロードを運用する](#performance-tuning-service-quotas) + [「リソース不足」エラーを減らす](#performance-tuning-resource-limits) ## 同じアカウント内で複数のワークロードを運用する Athena はクォータを使用して、クエリの同時実行率と API リクエスト率をアカウントレベルで制限します。これらのクォータを超えると、実行中または送信時にクエリが失敗する可能性があります。これらのクォータの詳細については、「[サービスクォータ](service-limits.md)」を参照してください。 同じ AWS アカウント内で複数のワークロードを実行している場合、ワークロードは同じアカウントレベルのクォータで競合します。例えば、1 つのワークロードで予期しないクエリのバーストが発生した場合、同じアカウントで実行されている別のワークロードでキュー時間が長くなったり、最悪のケースではスロットリングによってクエリ送信が失敗したりする可能性があります。 CloudWatch を使用して、グラフやダッシュボードを使ってサービスの使用状況をモニタリングすることをお勧めします。また、同時クエリのサービスクォータに使用量が近づいたときに警告する CloudWatch アラームを設定して、クォータ制限に達する前にアクションを実行することもできます。詳細については、「[CloudWatch による Athena 使用状況メトリクスのモニタリング](monitoring-athena-usage-metrics.md)」を参照してください。 クエリの同時実行を制御し、アカウント内のワークロードを分離するには、キャパシティ予約を使用します。キャパシティ予約は、単一のアカウント内で専用のクエリ処理キャパシティを提供します。キャパシティはデータ処理ユニット (DPU) で測定され、それぞれ追加または削除してクエリの同時実行数を増減できます。キャパシティ予約を使用すると、1 つ以上のワークグループにキャパシティを割り当てることで、アカウント内のワークロードを相互に分離できます。詳細については、「[クエリ処理キャパシティを管理する](capacity-management.md)」を参照してください。 関連しないワークロードは異なる AWS アカウントに分離すべきですが (開発環境と本番環境を分離するなど)、この方法ではクエリの同時実行性をスケーラブルに向上させることはできません。代わりに、キャパシティ予約を使用して、1 つのアカウント内でクエリ処理の管理とスケーリングが可能になります。 ### 他のサービスのクォータを検討する Athena がクエリを実行すると、クォータを適用する他のサービスを呼び出せます。クエリの実行中に、Athena は AWS Glue Data Catalog、Amazon S3、および IAM や AWS KMS などその他の AWS サービスなどに API 呼び出しを行えます。[フェデレーションクエリ](federated-queries.md)を使用する場合、Athena は AWS Lambda に呼び出しも行います。これらのサービスにはすべて、超過できる独自の制限と割り当てがあります。クエリ実行でこれらのサービスからエラーが発生すると、ソースサービスからのエラーも含めて失敗します。復元可能なエラーは再試行されますが、問題が時間内に解決されない場合、クエリが失敗する可能性があります。エラーメッセージをよく読んで、Athena からのものか別のサービスからのものかを判断してください。関連するエラーの一部については、このパフォーマンスチューニングに関するセクションで説明します。 Amazon S3 サービスクォータに起因するエラーの回避方法の詳細については、このドキュメントの後半の「[ファイルが多すぎにならないようにする](performance-tuning-data-optimization-techniques.md#performance-tuning-avoid-having-too-many-files)」を参照してください。Amazon S3 のパフォーマンスの最適化の詳細については、「*Amazon S3 ユーザーガイド*」の「[ベストプラクティスの設計パターン: Amazon S3 パフォーマンスの最適化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)」を参照してください。 ## 「リソース不足」エラーを減らす Athena は分散クエリエンジンでクエリを実行します。クエリを送信すると、Athena エンジンのクエリプランナーはクエリを実行するのに必要な計算能力を見積もり、それに応じて計算ノードのクラスターを準備します。DDL クエリなどの一部のクエリは、1 つのノードでのみ実行されます。大規模なデータセットに対する複雑なクエリでは、はるかに大きなクラスターで実行されます。ノードは均一であり、メモリ、CPU、およびディスク構成は同じです。Athena は、より要求の厳しいクエリを処理するためにスケールアップするのではなく、スケールアウトします。 クエリの要求は、クエリを実行するクラスターで使用可能なリソースを超えることがあります。この場合にはクエリは失敗し、「このスケールファクターでリソースを使い果たしました」というエラーが表示されます。 最も一般的に消費されるリソースはメモリですが、まれにディスク容量になる場合もあります。メモリエラーは通常、エンジンが結合またはウィンドウ関数を実行するときに発生しますが、カウントや集計が異なる場合もあります。 クエリが「リソース不足」エラーで一度失敗した場合でも、もう一度実行すると成功する可能性があります。クエリの実行は確定的ではありません。データの読み込みにかかる時間や中間データセットがノードにどのように分散されるかなどの要因により、リソースの使用量が異なる場合があります。たとえば、2 つのテーブルを結合するクエリで、結合条件の値の分布に大きな偏りがあるとします。このようなクエリはほぼ成功しますが、最も一般的な値が同じノードで処理されてしまうと失敗することがあります。 クエリが利用可能なリソースを超えないようにするには、このドキュメントに記載されているパフォーマンスチューニングのヒントを参考にしてください。特に、使用可能なリソースを使い果たすクエリを最適化する方法のヒントについては、「[結合を最適化する](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-joins)」、「[ウィンドウ関数の範囲を縮小したり、削除したりする](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-window-functions)」、および「[近似値を使用してクエリを最適化する](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-queries-by-using-approximations)」を参照してください # クエリを最適化する このセクションで説明するクエリ最適化手法を使用して、クエリの実行を高速化したり、Athena のリソース制限を超えるクエリの回避策として使用します。 ## 結合を最適化する 分散クエリエンジンで結合を実行するには、さまざまな方法があります。最も一般的なのは、分散ハッシュ結合と複雑な結合条件のクエリの 2 つです。 ### 分散ハッシュ結合では、大きなテーブルを左側に配置し、小さなテーブルを右側に配置します 最も一般的なタイプの結合では、結合条件として等価比較を使用します。Athena はこのタイプの結合を分散ハッシュ結合として実行します。 分散型ハッシュ結合では、エンジンは結合の片側からルックアップテーブル (ハッシュテーブル) を作成します。この側は*ビルド側*と呼ばれます。ビルド側のレコードはノード全体に分散されます。各ノードは、そのサブセットのルックアップテーブルを作成します。結合のもう一方の側 (*プローブ側*と呼ばれる) がノードを介してストリーミングされます。プローブ側のレコードは、ビルド側と同じ方法でノードに分散されます。これにより、各ノードは独自の検索テーブルで一致するレコードを検索して結合を実行できます。 結合のビルド側から作成されたルックアップテーブルがメモリに収まらない場合、クエリが失敗する可能性があります。ビルド側の合計サイズが利用可能なメモリよりも小さい場合でも、レコードの分布に大きな偏りがあると、クエリが失敗する可能性があります。極端なケースでは、すべてのレコードの結合条件の値が同じで、1 つのノードのメモリに収まる必要がある場合があります。スキューの少ないクエリでも、値のセットが同じノードに送信され、その値の合計が使用可能なメモリを超えると、失敗する可能性があります。ノードにはレコードをディスクにスピルする機能がありますが、スピルするとクエリの実行が遅くなり、クエリの失敗を防ぐには不十分である場合があります。 Athena は、大きい方のリレーションをプローブ側に、小さい方のリレーションをビルド側として使用するように結合の順序を変更しようとします。ただし、Athena はテーブル内のデータを管理しないため、情報が限られており、多くの場合、最初のテーブルが大きく、2 番目のテーブルが小さいと想定する必要があります。 等価ベースの結合条件で結合を記述する場合、`JOIN` キーワードの左側の表がプローブ側、右側の表がビルド側であると仮定します。正しいテーブル (ビルド側) がテーブルのうち小さい方であることを確認してください。結合のビルド側をメモリに収まるほど小さくできない場合は、ビルドテーブルのサブセットを結合する複数のクエリを実行することを検討してください。 ### EXPLAIN を使用して複雑な結合を持つクエリを分析する 結合条件が複雑なクエリ (`LIKE`、`>`、または他の演算子を使用するクエリなど) では、多くの場合、計算負荷が高くなります。最悪の場合には、結合の片側のすべてのレコードを、結合の反対側のすべてのレコードと比較する必要があります。実行時間はレコード数の 2 乗に比例して長くなるため、このようなクエリには最大実行時間を超えるリスクがあります。 Athena がクエリをどのように実行するかを事前に確認するには、`EXPLAIN` ステートメントを使用できます。詳細については、「[Athena での EXPLAIN および EXPLAIN ANALYZE の使用](athena-explain-statement.md)」および「[Athena EXPLAIN ステートメントの結果を理解する](athena-explain-statement-understanding.md)」を参照してください。 ## ウィンドウ関数の範囲を縮小したり、削除したりする ウィンドウ関数はリソースを大量に消費する操作であるため、クエリの実行が遅くなったり、「このスケールファクターではリソースを使い果たしました」というメッセージが表示され、クエリが失敗したりする可能性があります。ウィンドウ関数は、結果を計算するために操作したすべてのレコードをメモリに保持します。ウィンドウが非常に大きい場合、ウィンドウ関数のメモリが不足する可能性があります。 クエリが使用可能なメモリ制限内で実行されるように、ウィンドウ関数が処理するウィンドウのサイズを小さくしてください。そのようにするためには、`PARTITIONED BY` 句を追加するか、既存の分割節の範囲を絞り込めます。 ### ウィンドウ以外の関数を使用する ウィンドウ関数を含むクエリは、ウィンドウ関数なしで書き直せる場合があります。たとえば、`row_number` を使用して上位 `N` レコードを検索する代わりに、`ORDER BY` および `LIMIT` を使用できます。`row_number` または `rank` を使用してレコードの重複排除を行う代わりに、[max\$1by](https://trino.io/docs/current/functions/aggregate.html#max_by)、[min\$1by](https://trino.io/docs/current/functions/aggregate.html#min_by)、[任意](https://trino.io/docs/current/functions/aggregate.html#arbitrary) などの集計関数を使用できます。 たとえば、センサーからの更新を含むデータセットがあるとします。センサーは定期的にバッテリーの状態を報告し、位置情報などのメタデータを含みます。各センサーの最新のバッテリー状態とその位置を知りたい場合は、次のクエリを使用できます。 ``` SELECT sensor_id, arbitrary(location) AS location, max_by(battery_status, updated_at) AS battery_status FROM sensor_readings GROUP BY sensor_id ``` 位置などのメタデータはすべてのレコードで同じなので、`arbitrary` 関数を使用してグループから任意の値を選択できます。 `max_by` 関数を使用すると、最新のバッテリー状態を取得できます。`max_by` 関数は、別の列の最大値が見つかったレコードから列の値を選択します。この場合、グループ内の最終更新時刻を含むレコードのバッテリーステータスを返します。このクエリは、ウィンドウ関数を使用する同等のクエリよりも実行速度が速く、メモリ使用量も少なくて済みます。 ## 集計を最適化する Athena が集約を実行すると、`GROUP BY` 句内の列を使用してレコードがワーカーノード全体に分散されます。レコードをグループと照合するタスクを可能な限り効率的に行うために、ノードはレコードをメモリに保持し、必要に応じてディスクに書き出そうとします。 `GROUP BY` 句に重複する列を含めないようにするのも良い考えです。列の数が少ないと必要なメモリも少なくなるため、使用する列の数が少ないグループを記述するクエリの方が効率的です。また、数値列は文字列よりもメモリ使用量が少なくなります。たとえば、数値のカテゴリ ID とカテゴリ名の両方を持つデータセットを集約する場合、`GROUP BY` 句にはカテゴリ ID 列のみを使用してください。 場合によっては、列が `GROUP BY` 句または集計式の一部である必要があるという事実を回避するために、クエリの `GROUP BY` 句に列が含まれることがあります。このルールに従わない場合、次のようなエラーメッセージが表示されることがあります。 EXPRESSION\$1NOT\$1AGGREGATE: 1:8 行目:「カテゴリ」は集合式であるか、GROUP BY 句に含まれている必要があります `GROUP BY` 句に余分な列を追加しなくても済むように、次の例のように[任意](https://trino.io/docs/current/functions/aggregate.html#arbitrary)の関数を使用できます。 ``` SELECT country_id, arbitrary(country_name) AS country_name, COUNT(*) AS city_count FROM world_cities GROUP BY country_id ``` `ARBITRARY` 関数はグループから任意の値を返します。この関数は、グループ内のすべてのレコードが 1 つの列に対して同じ値を持つことは把握しているがその値がグループを識別できない場合に便利です。 ## 上位 N 個のクエリを最適化する `ORDER BY` 句は、クエリの結果をソートされた順序で返します。Athena は分散ソートを使用して、ソート操作を複数のノードで並行して実行します。 結果を厳密にソートする必要がない場合は、`ORDER BY` 句を追加しないでください。また、必ずしも必要ではない場合は、内部クエリへの `ORDER BY` の追加は避けてください。多くの場合、クエリプランナーは冗長なソートを削除できますが、これは保証されていません。このルールの例外は、内部クエリが上位 `N` の操作 (最新の `N` の値、または最も一般的な `N`の値を検索するなど) を実行している場合です。 Athena が `ORDER BY` を `LIMIT` を使用して見た場合、実行されている `N` クエリが上位のクエリであることを認識し、それに応じて専用の操作を行います。 **注記** Athena では、上位の `N` を使用する `row_number` のようなウィンドウ関数も多くの場合検出できますが、`ORDER BY` と `LIMIT` を使用するより単純なバージョンをお勧めします。詳細については、「[ウィンドウ関数の範囲を縮小したり、削除したりする](#performance-tuning-optimizing-window-functions)」を参照してください。 ## 必要な列のみを含める 列が必ずしも必要ではない場合は、クエリに含めないでください。クエリが処理しなければならないデータが少ないほど、実行速度は速くなります。これにより、必要なメモリ量と、ノード間で送信する必要のあるデータ量の両方が削減されます。列形式のファイル形式を使用している場合、列の数を減らすと、Amazon S3 から読み取られるデータの量も減ります。 Athena には結果の列数に特別な制限はありませんが、クエリの実行方法によって、可能な列の合計サイズが制限されます。列を合わせたサイズには、名前とタイプが含まれます。 たとえば、次のエラーは、リレーションがリレーション記述子のサイズ制限を超えるために発生します。 GENERIC\$1INTERNAL\$1ERROR: io.airlift.bytecode.CompilationException この問題を回避するには、クエリ内の列の数を減らす、またはサブクエリを作成して、より少ない量のデータを取得する `JOIN` を使用します。一番外側のクエリで `SELECT *` を実行するクエリがある場合は、`*` を必要な列のみのリストに変更する必要があります。 ## 近似値を使用してクエリを最適化する Athena では、[近似集計関数](https://trino.io/docs/current/functions/aggregate.html#appro)をサポートしており、個別値、最も頻度の高い値、パーセンタイル (近似中央値を含む) のカウント、およびヒストグラムの作成を行えます。これらの関数は、正確な値が不要な場合に使用してください。 `COUNT(DISTINCT col)` 操作とは異なり、[approx\$1distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct) はメモリ使用量がはるかに少なく、実行速度も速くなります。同様に、ヒストグラムの代わりに [numeric\$1histogram](https://trino.io/docs/current/functions/aggregate.html#numeric_histogram) を使用すると、[近似法](https://trino.io/docs/current/functions/aggregate.html#histogram)を使用するため、メモリ使用量が少なくなります。 ## LIKE を最適化する `LIKE` を使用して一致する文字列を検索できますが、文字列が長い場合は計算量が多くなります。[regexp\$1like](https://trino.io/docs/current/functions/regexp.html#regexp_like) 関数は、ほとんどの場合、より高速な代替手段であり、柔軟性にも優れています。 多くの場合、探している部分的な文字列を固定することで検索を最適化できます。たとえば、プレフィックスを探している場合は、'*% substr*%' の代わりに '*substr* %' を使用する方がはるかに優れています。または `regexp_like`、「^ *substr*」を使用している場合。 ## UNION の代わりに UNION ALL を使用する `UNION ALL` と `UNION` は、2 つのクエリの結果を 1 つの結果にまとめる 2 つの方法です。 `UNION ALL` は最初のクエリのレコードを 2 番目のクエリと連結し、`UNION` は同じ処理を実行しますが、重複も削除します。`UNION` ではすべてのレコードを処理して重複を見つける必要があり、メモリと計算を大量に消費しますが、`UNION ALL` は比較的高速な操作です。レコードの重複排除が必要でない限り、`UNION ALL` はベストパフォーマンスを実現するために使用してください。 ## 大きな結果セットには UNLOAD を使用する クエリの結果が大きくなることが予想される場合 (たとえば、数万行以上など)、UNLOAD を使用して結果をエクスポートします。ほとんどの場合、これは通常のクエリを実行するよりも高速です。また、`UNLOAD` を使用すると、出力をより細かく制御できます。 クエリの実行が終了すると、Athena は結果を 1 つの非圧縮 CSV ファイルとして Amazon S3 に保存します。結果が圧縮されないだけでなく、操作を並列化できないため、`UNLOAD` よりも時間がかかります。これとは対照的に、`UNLOAD` は結果をワーカーノードから直接書き込み、計算クラスターの並列処理を最大限に活用します。さらに、結果を圧縮形式や JSON や Parquet などの他のファイル形式で書き込むように `UNLOAD` を構成できます。 詳細については、「[UNLOAD](unload.md)」を参照してください。 ## CTAS または Glue ETL を使用して、頻繁に使用する集計をマテリアライズする クエリの「マテリアライズ」とは、事前に計算された複雑なクエリ結果 (集計や結合など) を保存して後続のクエリで再利用することで、クエリのパフォーマンスを向上させる方法です。 クエリの多くに同じ結合や集計が含まれている場合は、共通のサブクエリを新しいテーブルとして作成し、そのテーブルに対してクエリを実行できます。[クエリ結果からテーブルを作成する (CTAS)](ctas.md)、または [Glue ETL](https://aws.amazon.com/glue) などの専用 ETL ツールを使用して新しいテーブルを作成できます。 たとえば、オーダーデータセットのさまざまな側面を表示するウィジェットを含むダッシュボードがあるとします。各ウィジェットには独自のクエリがありますが、クエリはすべて同じ結合とフィルターを共有します。注文テーブルは品目テーブルと結合され、過去 3 か月のみ表示するフィルターがあります。これらのクエリに共通する機能がわかれば、ウィジェットが使用できる新しいテーブルを作成できます。これにより、重複が減り、パフォーマンスが向上します。欠点は、新しいテーブルを最新の状態に保つ必要があることです。 ## クエリ結果の再利用 同じクエリが短期間に複数回実行されることはよくあります。たとえば、複数のユーザーが同じデータダッシュボードを開いたときに発生する可能性があります。クエリを実行するときに、以前に計算した結果を再利用するよう Athena に指示できます。再利用できる結果の最大保管期間を指定します。同じクエリがその時間枠内で以前に実行された場合、Athena はクエリを再実行する代わりにそれらの結果を返します。詳細については、「*Amazon Athena ユーザーガイド*」の [Athena でクエリ結果を再利用する](reusing-query-results.md)、「*AWS ビッグデータブログ*」の「[Amazon Athena クエリ結果の再利用によるコスト削減とクエリパフォーマンスの向上](https://aws.amazon.com/blogs/big-data/reduce-cost-and-improve-query-performance-with-amazon-athena-query-result-reuse/)」を参照してください。 # データを最適化する パフォーマンスはクエリだけでなく、データセットの構成方法や使用するファイル形式と圧縮にも大きく依存します。 ## データのパーティション化 パーティショニングを行うと、テーブルが複数部分に分割され、日付、国、地域などのプロパティに基づいて関連データがまとめられます。パーティションキーは仮想列として機能します。パーティションキーはテーブルの作成時に定義し、クエリのフィルタリングに使用します。パーティションキー列をフィルタリングすると、一致するパーティションのデータのみが読み取られます。たとえば、データセットが日付で分割されていて、クエリに先週のみ一致するフィルターが設定されている場合、先週のデータのみが読み取られます。パーティショニングについての詳細は、「[データのパーティション化](partitions.md)」を参照してください。 ## クエリをサポートするパーティションキーを選択する パーティショニングはクエリのパフォーマンスに大きな影響を与えるため、データセットとテーブルを設計するときは、パーティションの分割方法を慎重に検討してください。パーティションキーが多すぎると、データセットが断片化し、ファイルが多すぎたり、ファイルが小さすぎたりする可能性があります。逆に、パーティションキーが少なすぎたり、パーティショニングがまったく行われなかったりすると、クエリが必要以上に多くのデータをスキャンすることになります。 ### まれなクエリの最適化は避ける 最もよく使われるクエリを最適化し、まれであるクエリには最適化しないようにするのが良い戦略です。たとえば、クエリが日単位の期間を対象としている場合は、一部のクエリがそのレベルに絞り込まれていても、時間単位で分割しないでください。データに詳細なタイムスタンプ列がある場合、時間別にフィルタリングするまれなクエリではタイムスタンプ列を使用できます。まれなケースで必要以上のデータをスキャンしたとしても、まれなケースという理由で全体的なパフォーマンスを低下させることは、通常は良いトレードオフとは言えません。 クエリでスキャンするデータ量を減らしてパフォーマンスを向上させるには、列指向のファイル形式を使用し、レコードをソートしたままにしてください。時間ごとに分割する代わりに、レコードをタイムスタンプでソートしておきます。短い時間枠でのクエリでは、タイムスタンプによるソートは、時間ごとの分割とほぼ同じくらい効率的です。さらに、通常はタイムスタンプでソートしても、日単位でカウントされたタイムウィンドウでのクエリのパフォーマンスが低下することはありません。詳細については、「[列指向ファイルフォーマットを使用する](#performance-tuning-use-columnar-file-formats)」を参照してください。 数万のパーティションを含むテーブルでのクエリは、すべてのパーティションキーに述語がある方がパフォーマンスが向上することに注意してください。これが、最も一般的なクエリ用にパーティションスキームを設計するもう一つの理由です。詳細については、「[等式によるパーティションのクエリ](#performance-tuning-query-partitions-by-equality)」を参照してください。 ## パーティション射影を使用する パーティション射影は Athena の機能の 1 つであり、パーティション情報を AWS Glue Data Catalog には格納せず、AWS Glue のテーブルのプロパティにルールとして格納します。Athena は、パーティション射影が設定されたテーブルに対してクエリを計画する際、テーブルのパーティション射影ルールを読み取ります。Athena は、AWS Glue Data Catalog でパーティションを検索する代わりに、クエリとルールに基づいてメモリに読み込むパーティションを計算します。 パーティション射影は、パーティション管理を簡素化するだけでなく、多数のパーティションを持つデータセットのパフォーマンスを向上させることができます。クエリにパーティションキーの特定の値の代わりに範囲が含まれている場合、カタログで一致するパーティションを検索すると、パーティションの数が多いほど時間がかかります。パーティション射影を使用すると、カタログにアクセスせずにフィルターをメモリ内で計算でき、はるかに高速になります。 特定の状況では、パーティション射影によってパフォーマンスが低下する可能性があります。一例として、テーブルが「スパースな」場合が挙げられます。スパーステーブルには、パーティション射影の設定で記述されたパーティションキー値のすべての順列に関するデータはありません。スパーステーブルでは、クエリから計算されたパーティションセットとパーティションプロジェクション設定は、データがない場合でもすべて Amazon S3 に一覧表示されます。 パーティション射影を使用する場合は、必ずすべてのパーティションキーに述語を含めてください。Amazon S3 の一覧表示が不要にならないように、指定できる値の範囲を絞り込んでください。100 万の値の範囲を持つパーティションキーと、そのパーティションキーにフィルターがないクエリを想像してください。クエリを実行するには、Athena は少なくとも 100 万回の Amazon S3 リストオペレーションを実行する必要があります。パーティション射影を使用するか、カタログにパーティション情報を保管するかに関係なく、特定の値に対してクエリを実行すると、クエリは最も速くなります。詳細については、「[等式によるパーティションのクエリ](#performance-tuning-query-partitions-by-equality)」を参照してください。 パーティション射影用のテーブルを設定するときは、指定する範囲が適切であることを確認してください。クエリにパーティションキーの述語が含まれていない場合は、そのキーの範囲内のすべての値が使用されます。データセットが特定の日付に作成された場合は、その日付を任意の日付範囲の開始点として使用します。終了日の範囲として `NOW` を使用します。値の数が多い数値範囲は避け、代わりに[注入された](partition-projection-dynamic-id-partitioning.md#partition-projection-injection)型の使用を検討してください。 パーティション射影の詳細については、「[Amazon Athena でパーティション射影を使用する](partition-projection.md)」を参照してください。 ## パーティションインデックスの使用 パーティションインデックスは、多数のパーティションを持つテーブルのパーティションルックアップのパフォーマンスを向上させる AWS Glue Data Catalog の機能です。 カタログ内のパーティションのリストは、リレーショナルデータベースのテーブルのようなものです。このテーブルには、パーティションキー用の列と、パーティションの場所用の別の列があります。分割テーブルをクエリすると、このテーブルをスキャンしてパーティションの場所が検索されます。 リレーショナルデータベースと同様に、インデックスを追加することでクエリのパフォーマンスを向上できます。複数のインデックスを追加して、さまざまなクエリパターンをサポートできます。AWS Glue Data Catalog パーティションインデックスは、`>`、`>=` などの等価演算子と比較演算子の両方をサポートし、`<` は `AND` 演算子を結合します。詳細については、「*AWS Glue 開発者ガイド*」の「[AWS Glue でのパーティションインデックスの使用](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html)」と、「*AWS Big Data Blog*」の「[Improve Amazon Athena query performance using AWS Glue Data Catalog partition indexes](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/)」を参照してください。 ## パーティションキーのタイプとして常に STRING を使用する パーティションキーをクエリする場合、Athena ではパーティションフィルタリングを AWS Glue にプッシュダウンするためにパーティションキーのタイプ `STRING` が必要であることを覚えておいてください。パーティションの数が少なくない場合は、他のタイプを使用するとパフォーマンスが低下する可能性があります。パーティションキーの値が日付型または数値型の場合は、クエリ内の適切な型にキャストしてください。 ## 古いパーティションや空のパーティションを削除する Amazon S3 のパーティションから (Amazon S3 [ライフサイクル](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)を使用するなどして) データを削除する場合は、AWS Glue Data Catalog からそのパーティションエントリも削除する必要があります。クエリのプランニング中、クエリに一致するパーティションはすべて Amazon S3 に一覧表示されます。空のパーティションが多数ある場合、それらのパーティションを一覧表示することによるオーバーヘッドは悪影響をおよぼす可能性があります。 また、パーティションが何千もある場合は、不要になった古いデータのパーティションメタデータを削除することを検討してください。たとえば、クエリで 1 年以上前のデータが検索されない場合、古いパーティションのパーティションメタデータを定期的に削除できます。パーティションの数が数万に増えた場合、未使用のパーティションを削除すると、すべてのパーティションキーに述語が含まれていないクエリを高速化できます。クエリにすべてのパーティションキーに述語を含める方法については、「[等式によるパーティションのクエリ](#performance-tuning-query-partitions-by-equality)」を参照してください。 ## 等式によるパーティションのクエリ すべてのパーティションキーに等価述語を含むクエリでは、パーティションメタデータを直接読み込めるため、実行速度が速くなります。1 つ以上のパーティションキーに述語がない場合や、述語で値の範囲を選択するクエリは避けてください。このようなクエリでは、すべてのパーティションのリストをフィルタリングして、一致する値を見つける必要があります。ほとんどのテーブルではオーバーヘッドは最小限ですが、パーティションが数万以上あるテーブルではオーバーヘッドが大きくなる可能性があります。 クエリを書き直してパーティションを等値でフィルタリングできない場合は、パーティション射影を試してみてください。詳細については、「[パーティション射影を使用する](#performance-tuning-use-partition-projection)」を参照してください。 ## パーティションのメンテナンスに MSCK REPAIR TABLE を使用しないでください `MSCK REPAIR TABLE` は実行に時間がかかる場合があり、新しいパーティションを追加するだけで、古いパーティションは削除されないため、パーティションを管理する効率的な方法ではありません (「[考慮事項と制限事項](msck-repair-table.md#msck-repair-table-considerations)」を参照)。 パーティションは、[AWS Glue Data Catalog API](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog.html)、[ALTER TABLE ADD PARTITION](alter-table-add-partition.md) または[AWS Glueクローラー](https://docs.aws.amazon.com/glue/latest/dg/crawler-running.html)を使用して手動で管理する方が適切です。別の方法として、パーティション射影を使用できます。これにより、パーティションを完全に管理する必要がなくなります。詳細については、「[Amazon Athena でパーティション射影を使用する](partition-projection.md)」を参照してください。 ## クエリがパーティションスキームと互換性があることを確認してください。 クエリがどのパーティションをスキャンするかは、[`EXPLAIN`](athena-explain-statement.md) ステートメントを使用して事前に確認できます。クエリの前に `EXPLAIN` キーワードを付けてから、`EXPLAIN` 出力の下部にある各テーブルのソースフラグメント（たとえば、`Fragment 2 [SOURCE]`）を探します。右側がパーティションキーとして定義されている割り当てを探してください。下の行には、クエリの実行時にスキャンされるパーティションキーのすべての値のリストが含まれています。 たとえば、`dt` パーティションキーを含むテーブルに対してクエリを実行し、`EXPLAIN` のクエリのプレフィックスを付けたとします。クエリ内の値が日付で、フィルターで 3 日間の範囲を選択した場合、`EXPLAIN` 出力は次のようになります。 ``` dt := dt:string:PARTITION_KEY :: [[2023-06-11], [2023-06-12], [2023-06-13]] ``` `EXPLAIN` 出力は、プランナーがクエリと一致するこのパーティションキーの値を 3 つ見つけたことを示しています。また、それらの値が何であるかも表示されます。`EXPLAIN` の使用の詳細については、「[Athena での EXPLAIN および EXPLAIN ANALYZE の使用](athena-explain-statement.md)」と「[Athena EXPLAIN ステートメントの結果を理解する](athena-explain-statement-understanding.md)」を参照してください。 ## 列指向ファイルフォーマットを使用する Parquet や ORC のような列指向のファイル形式は、分散分析ワークロード向けに設計されています。データを行別ではなく列別に整理します。データを列形式で整理することには、次のような利点があります。 + クエリに必要な列のみが読み込まれる + ロードする必要のあるデータの総量が減る + 列の値はまとめて保存されるため、データを効率的に圧縮できる + ファイルには、エンジンが不要なデータのロードをスキップできるようにするメタデータを含められる ファイルメタデータの使用方法の例として、ファイルメタデータには、データページの最小値と最大値に関する情報を含められます。クエリされた値がメタデータに記載されている範囲にない場合は、ページをスキップできます。 このメタデータを使用してパフォーマンスを向上させる方法の 1 つは、ファイル内のデータを確実にソートすることです。たとえば、`created_at` エントリが短期間にあるレコードを検索するクエリがあるとします。`created_at` データが列でソートされている場合、Athena はファイルメタデータの最小値と最大値を使用して、データファイルの不要な部分をスキップできます。 列指向のファイル形式を使用する場合は、ファイルが小さすぎないことを確認してください。[ファイルが多すぎにならないようにする](#performance-tuning-avoid-having-too-many-files) で説明したように、小さなファイルが多いデータセットはパフォーマンスの問題を引き起こします。これは特に列指向ファイル形式の場合に当てはまります。小さなファイルの場合、列指向ファイル形式のオーバーヘッドの方がメリットよりも重要です。 Parquet と ORC は内部的には行グループ (Parquet) とストライプ (ORC) で整理されていることに注意してください。行グループのデフォルトサイズは 128 MB、デフォルトのストライプサイズは 64 MB です。列が多い場合は、行グループとストライプサイズを大きくしてパフォーマンスを向上できます。行グループまたはストライプサイズをデフォルト値より小さくすることはお勧めしません。 他のデータ形式を Parquet または ORC に変換するには、AWS Glue ETL または Athena を使用できます。詳細については、「[列形式に変換する](columnar-storage.md#convert-to-columnar)」を参照してください。 ## データを圧縮する Athena は幅広い圧縮形式をサポートしています。圧縮データのクエリは、解凍前にスキャンされたバイト数に応じて支払われるため、高速かつ安価です。 [gzip](https://www.gnu.org/software/gzip/) 形式は圧縮率が高く、他のツールやサービスを幅広くサポートしています。[zstd](https://facebook.github.io/zstd/) (Zstandard) 形式は、パフォーマンスと圧縮率のバランスが取れた新しい圧縮形式です。 JSON や CSV データなどのテキストファイルを圧縮するときは、ファイル数とファイルサイズのバランスをとるようにしてください。ほとんどの圧縮形式では、リーダーはファイルを最初から読み取る必要があります。つまり、圧縮されたテキストファイルは一般的に並行して処理できません。大きな非圧縮ファイルは、クエリ処理中の並列性を高めるためにワーカー間で分割されることがよくありますが、これはほとんどの圧縮形式では不可能です。 [ファイルが多すぎにならないようにする](#performance-tuning-avoid-having-too-many-files) で説明したように、ファイルが多すぎたり少なすぎたりしない方がよいでしょう。ファイル数によってクエリを処理できるワーカーの数が制限されるため、このルールは圧縮ファイルの場合に特に当てはまります。 Athena での圧縮の使用の詳細については、「[Athena で圧縮を使用する](compression-formats.md)」を参照してください。 ## カーディナリティが高いキーの検索にはバケットを使用する バケット処理とは、いずれかの列の値に基づいてレコードを個別のファイルに分散する手法です。これにより、同じ値を持つすべてのレコードが同じファイルにあることが保証されます。バケット化は、カーディナリティの高いキーがあり、クエリの多くがそのキーの特定の値を検索する場合に役立ちます。 たとえば、特定のユーザーのレコードセットをクエリするとします。データがユーザー ID 別にまとめられている場合、Athena は特定の ID のレコードを含むファイルと含まないファイルを事前に把握します。これにより、Athena はその ID を含められるファイルのみを読み取れるため、読み取るデータ量を大幅に削減できます。また、特定の ID のデータを検索するために必要となる計算時間も短縮されます。 ### クエリが列内の複数の値を頻繁に検索する場合は、バケット化を避ける クエリでデータがバケット化されている列で複数の値を頻繁に検索する場合、バケット化の価値は低くなります。クエリする値が多いほど、すべて、またはほとんどのファイルを読み取らなければならない可能性が高くなります。たとえば、バケットが 3 つあり、クエリが 3 つの異なる値を検索する場合、すべてのファイルを読み取る必要がある場合があります。バケット処理は、クエリが単一の値を検索するときに最も効果的です。 詳細については、「[パーティショニングとバケット化を使用する](ctas-partitioning-and-bucketing.md)」を参照してください。 ## ファイルが多すぎにならないようにする データセットが多数の小さなファイルで構成されていると、全体的なクエリパフォーマンスが低下します。Athena がクエリを計画すると、すべてのパーティションの場所が一覧表示されるため、時間がかかります。各ファイルの処理と要求には、計算上のオーバーヘッドもあります。したがって、Amazon S3 から 1 つの大きなファイルをロードする方が、多数の小さいファイルから同じレコードをロードするよりも高速です。 極端なケースでは、Amazon S3 のサービス制限が発生する可能性があります。Amazon S3 は、1 つのインデックスパーティションに対して 1 秒あたり最大 5,500 の要求をサポートします。最初は、バケットは単一のインデックスパーティションとして扱われますが、リクエストの負荷が増えると、複数のインデックスパーティションに分割できます。 Amazon S3 はリクエストパターンを調べ、キープレフィックスに基づいて分割します。データセットが何千ものファイルで構成されている場合、Athena からのリクエストはリクエストクォータを超える可能性があります。ファイルが少なくても、同じデータセットに対して複数のクエリを同時に実行すると、クォータを超える可能性があります。同じファイルにアクセスする他のアプリケーションが、リクエストの総数に影響する可能性があります。 リクエストレート `limit` を超えると、Amazon S3 は次のエラーを返します。このエラーは Athena のクエリのステータス情報に含まれています。 SlowDown: リクエスト率を下げてください トラブルシューティングを行うには、まず、エラーの原因が単一のクエリなのか、同じファイルを読み取る複数のクエリなのかを判断します。後者の場合は、同時に実行されないようにクエリの実行を調整します。これを実現するには、アプリケーションにキューイングメカニズムを追加するか、リトライを行う必要があります。 1 つのクエリを実行してもエラーが発生する場合は、データファイルを組み合わせるか、クエリを変更して読み込むファイルの数を減らしてみてください。小さなファイルを結合する最適なタイミングは、ファイルが書き込まれる前です。そのためには、以下の方法を検討してください。 + ファイルを書き込むプロセスを変更して、より大きなファイルを書き込んでください。たとえば、レコードが書き込まれる前にレコードを長時間バッファリングできます。 + Amazon S3 上の場所にファイルを置き、Glue ETL などのツールを使用してファイルをより大きなファイルにまとめます。次に、サイズの大きいファイルをテーブルが指す場所に移動します。詳細については、「*AWS Glue デベロッパーガイド*」の「[大きなグループの入力ファイルの読み込み](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html)」か、および「*AWS re:Post ナレッジセンター*」の「[より大きなファイルを出力するように AWS Glue ETL ジョブを構成するには](https://repost.aws/knowledge-center/glue-job-output-large-files)」を参照してください。 + パーティションキーの数を減らしてください。パーティションキーが多すぎると、各パーティションのレコード数が少なくなり、小さなファイルが多すぎることがあります。作成するパーティションの決定については、「[クエリをサポートするパーティションキーを選択する](#performance-tuning-pick-partition-keys-that-will-support-your-queries)」を参照してください。 ## パーティションの外部にストレージ階層を追加することは避けてください クエリプランニングのオーバーヘッドを回避するには、ファイルを各パーティションの場所にフラット構造で格納します。追加のディレクトリ階層は使用しないでください。 Athena がクエリを計画すると、クエリに一致するすべてのパーティション内のすべてのファイルが一覧表示されます。Amazon S3 自体にはディレクトリはありませんが、慣例として `/` スラッシュはディレクトリ区切り文字として解釈されます。Athena がパーティションの場所を一覧表示すると、見つかったすべてのディレクトリが再帰的に一覧表示されます。パーティション内のファイルを 1 つの階層にまとめると、リストが複数回表示されます。 すべてのファイルが直接パーティションの場所にある場合は、ほとんどの場合、リスト操作を 1 回実行するのみで済みます。ただし、Amazon S3 はリストオペレーションごとに 1000 個のオブジェクトしか返さないため、パーティションに 1000 を超えるファイルがある場合は、複数の連続リストオペレーションが必要です。また、1 つのパーティションに 1000 個を超えるファイルがあると、さらに深刻なパフォーマンスの問題が発生する可能性があります。詳細については、「[ファイルが多すぎにならないようにする](#performance-tuning-avoid-having-too-many-files)」を参照してください。 ## SymlinkTextInputFormat は必要な場合にのみ使用する [https://athena.guide/articles/stitching-tables-with-symlinktextinputformat](https://athena.guide/articles/stitching-tables-with-symlinktextinputformat) テクニックを使用すると、テーブルのファイルがパーティションにきちんと整理されていない状況を回避できます。たとえば、シンボリックリンクは、すべてのファイルが同じプレフィックスにある場合や、スキーマの異なるファイルが同じ場所にある場合に役立ちます。 ただし、シンボリックリンクを使用すると、クエリ実行に間接的なレベルが追加されます。これらのレベルのインダイレクションは、全体的なパフォーマンスに影響します。シンボリックリンク ファイルを読み取り、ファイルが定義する場所をリストする必要があります。これにより、通常の Hive テーブルでは不要な複数のラウンドトリップが Amazon S3 に追加されます。結論として、ファイルの再編成などのより適切なオプションが利用できない場合にのみ `SymlinkTextInputFormat` を使用してください。 # 列指向ストレージ形式を使用する [Apache Parquet](https://parquet.apache.org) や [ORC](https://orc.apache.org/) は、データを高速に取得できるように最適化された、AWS 分析アプリケーションで使用されている、列指向ストレージ形式です。 列指向ストレージ形式には以下の特性があるため、Athena での使用に適しています。 + 列のデータ型に合わせて選択された圧縮アルゴリズムによる列ごとの圧縮で、Amazon S3 のストレージ領域を節約し、ディスク容量とクエリの処理中における I/O を削減します。 + Parquet および ORC での述語プッシュダウンにより、Athena クエリが必要なブロックのみを取得できるようになり、クエリパフォーマンスが向上します。Athena クエリがデータから特定の列値を取得すると、データブロック述語からの統計 (最大値や最小値など) を使用して、そのブロックを読み取るかスキップするかを判断します。 + Parquet および ORC での*データの分割*により、Athena がデータの読み取りを複数のリーダーに分割して、クエリ処理時における並列化を向上させることが可能になります。 既存の raw データを他のストレージ形式から Parquet または ORC に変換するには、Athena で [CREATE TABLE AS SELECT (CTAS)](ctas.md) クエリを実行してデータストレージ形式を Parquet もしくは ORC として指定する、または AWS Glue クローラを使用することができます。 ## Parquet または ORC のどちらかを選択する ORC（最適化された列指向）または Parquet のどちらを選択するかは、特定の使用要件によって異なります。 Apache Parquet は効率的なデータ圧縮とエンコーディングスキームを提供しており、複雑なクエリの実行や大量データの処理に最適です。Parquet は [Apache Arrow ](https://arrow.apache.org/) での使用に最適化されているため、Arrow 関連ツールを使用する場合に便利です。 ORC は Hive データを効率的に保存する方法を提供します。ORC ファイルは Parquet ファイルよりも小さいことが多く、ORC インデックスを使用するとクエリを高速化できます。さらに、ORC は構造体、マップ、リストなどの複雑な型をサポートしています。 Parquet または ORC のいずれかを選択するには、以下の点を考慮してください。 **クエリのパフォーマンス** — Parquet はより幅広い種類のクエリをサポートしているため、複雑なクエリを実行する場合は、Parquet の方が適している場合があります。 **複雑なデータ型** — 複雑なデータ型を使用している場合は、ORC の方が幅広い複合データ型をサポートしているので、より適している場合があります。 **ファイルサイズ** — ディスク容量が懸念される場合、通常、ORC を使用するとファイルが小さくなり、ストレージコストを低減できます。 **圧縮** — Parquet と ORC はどちらも優れた圧縮機能を備えていますが、最適な形式は特定のユースケースによって異なります。 **進化** — Parquet と ORC はどちらもスキーマの進化をサポートしています。つまり、時間の経過とともに列を追加、削除、または変更できます。 Parquet と ORC はどちらもビッグデータアプリケーションに適していますが、選択する前にシナリオの要件を検討してください。データとクエリに対してベンチマークを実行して、どの形式がユースケースに適したパフォーマンスを発揮するかを確認することをお勧めします。 ## 列形式に変換する JSON や CSV などのソースデータを列指向形式に簡単に変換するためのオプションには、[CREATE TABLE AS](ctas.md) クエリや、AWS Glue でのジョブの実行などがあります。 + `CREATE TABLE AS` (CTAS) クエリを使用すると、データを Parquet または ORC に 1 ステップで変換できます。例については、「[CTAS クエリの例](ctas-examples.md)」ページの「[例: クエリ結果を異なる形式で書き込む](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-format)」を参照してください。 + ETL に Athena を利用して CSV から Parquet にデータを変換する方法については、「[ETL およびデータ分析での CTAS および INSERT INTO を使用する](ctas-insert-into-etl.md)」を参照してください。 + CSV データを Parquet に変換する AWS Glue ジョブの実行については、AWS Big Data ブログの記事「[AWS Glue と Amazon S3 を使用してデータレイクの基礎を構築する](https://aws.amazon.com/blogs/big-data/build-a-data-lake-foundation-with-aws-glue-and-amazon-s3/)」の「データを CSV 形式から Parquet 形式に変換する」を参照してください。AWS Glue では CSV データの ORC への変換、あるいは JSON データの Parquet または ORC への変換にも同じ手法を使用できます。 # パーティショニングとバケット化を使用する クエリを実行する際に Athena がスキャンする必要があるデータ量を減らすための 2 つの方法として、パーティション化とバケット化があります。パーティション化とバケット化は補完的な機能で、併用できます。スキャンするデータ量を減らすことは、パフォーマンスの向上とコストの削減につながります。Athena クエリのパフォーマンスに関する一般的なガイドラインについては、「[Amazon Athena のパフォーマンスチューニング Tips トップ 10](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/)」を参照してください。 **Topics** + [パーティション化とは](ctas-partitioning-and-bucketing-what-is-partitioning.md) + [バケット化とは](ctas-partitioning-and-bucketing-what-is-bucketing.md) + [その他のリソース](ctas-partitioning-and-bucketing-additional-resources.md) # パーティション化とは パーティション化とは、データの特定のプロパティに基づいて Amazon S3 上にあるディレクトリ (または「プレフィックス」) にデータを整理することを意味します。このようなプロパティはパーティションキーと呼ばれます。一般的なパーティションキーは、日付またはその他の時間単位 (年や月など) です。ただし、データセットは複数のキーでパーティション化できます。たとえば、製品の売上に関するデータは、日付、製品カテゴリ、市場ごとにパーティション化できます。 ## パーティション化する方法の決定 パーティションキーに適しているのは、クエリで常にまたは頻繁に使用され、カーディナリティが低いプロパティです。パーティションの数が多すぎる/少なすぎることについては、それぞれの欠点があります。パーティションが多すぎると、ファイル数が増えるとオーバーヘッドが発生します。また、パーティション自体をフィルタリングすることによるオーバーヘッドもあります。パーティションが少なすぎると、クエリがより多くのデータをスキャンする必要性が多発します。 ## パーティショニングされたテーブルを作成する データセットをパーティション化すると、Athena でパーティションテーブルを作成できます。パーティションテーブルは、パーティションキーを含むテーブルです。`CREATE TABLE` を使用すると、テーブルにパーティションを追加します。`CREATE TABLE AS` を使用すると、Amazon S3 上で作成されたパーティションがテーブルに自動で追加されます。 `CREATE TABLE` ステートメントでは、`PARTITIONED BY (column_name data_type)` 句にパーティションキーを指定します。`CREATE TABLE AS` ステートメントでは、`WITH (partitioned_by = ARRAY['partition_key'])` 句に、または Iceberg テーブルの `WITH (partitioning = ARRAY['partition_key'])` にパーティションキーを指定します。パフォーマンス上の理由から、パーティションキーは常に `STRING` タイプにする必要があります。詳細については、「[パーティションキーのデータ型として文字列を使用](data-types-timestamps.md#data-types-timestamps-partition-key-types)」を参照してください。 その他の `CREATE TABLE` および `CREATE TABLE AS` 構文の詳細については、「[CREATE TABLE](create-table.md)」と「[CTAS テーブルのプロパティ](create-table-as.md#ctas-table-properties)」を参照してください。 ## パーティショニングされたテーブルをクエリする パーティションテーブルをクエリすると、Athena はクエリ内の述語を使用してパーティションのリストをフィルタリングします。次に、一致するパーティションの場所を使用して、見つかったファイルを処理します。単純に、クエリ述語と一致しないパーティションのデータを読み取らないようにすることで、Athena がスキャンするデータ量を効率的に減らせます。 ### 例 テーブルを `sales_date` と `product_category` でパーティション化していて、特定のカテゴリにおける 1 週間の総収益を知りたいとします。次の例のように、Athena がスキャンするデータ量が最小限になるように、`sales_date` 列と `product_category` 列に述語を含めます。 ``` SELECT SUM(amount) AS total_revenue FROM sales WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' AND product_category = 'Toys' ``` 日付別にパーティション化されているが詳細なタイムスタンプも含むデータセットがあるとします。 Iceberg テーブルではパーティションキーを宣言して列に関係を構築できますが、Hive テーブルではクエリエンジンは列とパーティションキーの関係に関するデータを持っていません。。このため、クエリが必要以上に多くのデータをスキャンしないように、クエリにある列とパーティションキーの両方に述語を含める必要があります。 たとえば、前の例における `sales` テーブルにも `TIMESTAMP` データ型の `sold_at` 列があるとします。特定の時間範囲の収益のみを求める場合は、クエリを次のように記述します: ``` SELECT SUM(amount) AS total_revenue FROM sales WHERE sales_date = '2023-02-28' AND sold_at BETWEEN TIMESTAMP '2023-02-28 10:00:00' AND TIMESTAMP '2023-02-28 12:00:00' AND product_category = 'Toys' ``` Hive テーブルと Iceberg テーブルのクエリの違いに関する詳細については、「[同じく時間分割されているタイムスタンプフィールドのクエリを作成する方法](data-types-timestamps.md#data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned)」を参照してください。 # バケット化とは バケット化は、データセットのレコードをバケットと呼ばれるカテゴリに整理する方法です。 この意味におけるバケットとバケット化は Amazon S3 バケットとは異なるため、混同しないでください。データバケットでは、プロパティと同じ値を含むレコードが同じバケットに入ります。レコードはバケット間で可能な限り均等に分散されるため、各バケットにはほぼ同じ量のデータが含まれます。 実際には、バケットはファイルであり、ハッシュ関数がレコードが入るバケットを決定します。バケット化されたデータセットには、パーティション/バケットごとに 1 つ以上のファイルがあります。ファイルが属するバケットはファイル名でエンコードされます。 ## バケット化のメリット バケット化は、データセットが特定のプロパティによってバケット化されており、そのプロパティに特定の値があるレコードを取得する際に役立ちます。データはバケット化されているので、Athena は検索するファイルを決定する値を使用できます。たとえば、データセットが `customer_id` 別にバケット化されていて、特定の顧客に関するすべてのレコードを検索したいとします。Athena はそれらのレコードを含むバケットを特定し、そのバケット内にあるファイルのみを読み取ります。 高基数 (つまり異なる値が多い) 列が均一に分散していて特定の値を頻繁にクエリする列がある際に、バケット化に適している対象が見つかります。 **注記** Athena は、`INSERT INTO` を使用してバケットテーブルに新しいレコードを追加する機能はサポートしていません。 ## バケット化された列でのフィルタリングでサポートされるデータ型 特定のデータ型を持つバケット列にフィルターを追加できます。Athena は、次のデータ型を持つバケット化された列に対してフィルタリングをサポートしています: + BOOLEAN + BYTE + DATE + DOUBLE + FLOAT + INT + LONG + SHORT + STRING + VARCHAR ## Hive と Spark のサポート Athena エンジンバージョン 2 は Hive バケットアルゴリズムを使用するバケット化されたデータセットをサポートし、Athena エンジンバージョン 3 は Apache Spark バケットアルゴリズムもサポートしています。Hive バケット化はデフォルトです。データセットが Spark アルゴリズムを使用してバケット化されている場合は、`TBLPROPERTIES` 句を使用して `bucketing_format` プロパティの値を `spark` に設定します。 **注記** Athena では、`CREATE TABLE AS SELECT` ([CTAS](ctas.md)) クエリ内のパーティション数は 100 個に制限されています。同様に、[INSERT INTO](insert-into.md) ステートメントを使用すると、宛先テーブルに最大 100 個のパーティションのみを追加できます。 この制限を超えると、HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS: Exceeded limit of 100 open writers for partitions/buckets (HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS: パーティション/バケットのオープンライターの制限である 100 を超えました) エラーメッセージが表示されることがあります。これらの制限を回避するには、CTAS ステートメントと、それぞれ最大 100 個のパーティションを作成または挿入する一連の `INSERT INTO` ステートメントを使用できます。詳細については、「[CTAS および INSERT INTO を使用して 100 パーティションの制限を回避する](ctas-insert-into.md)」を参照してください。 ## CREATE TABLE のバケット化に関する例 既存のバケット化されたデータセット用のテーブルを作成するには、`CLUSTERED BY (column)` 句の後に `INTO N BUCKETS` 句を続けて使用します。`INTO N BUCKETS` 句は、データをバケット化する先のバケットの数を指定します。 次の `CREATE TABLE` の例では、`sales` データセットは `customer_id` 別に、Spark アルゴリズムを使用して 8 つのバケットにバケット化されています。この `CREATE TABLE` ステートメントでは、`CLUSTERED BY` 句と `TBLPROPERTIES` 句を使用してプロパティをそれぞれ設定します。 ``` CREATE EXTERNAL TABLE sales (...) ... CLUSTERED BY (`customer_id`) INTO 8 BUCKETS ... TBLPROPERTIES ( 'bucketing_format' = 'spark' ) ``` ## CREATE TABLE AS (CTAS) のバケット化に関する例 `CREATE TABLE AS` のバケット化を指定するには、`bucketed_by` パラメータと `bucket_count` パラメータを次の例のように使用します。 ``` CREATE TABLE sales WITH ( ... bucketed_by = ARRAY['customer_id'], bucket_count = 8 ) AS SELECT ... ``` ## クエリのバケット化に関する例 次のクエリ例では、特定の顧客が 1 週間を通じて購入した製品の名前を検索します。 ``` SELECT DISTINCT product_name FROM sales WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' AND customer_id = 'c123' ``` このテーブルを `sales_date` 別にパーティション化して `customer_id` 別にバケット化すると、Athena は顧客レコードが入っているバケットを計算できます。Athena が読み込めるのは 1 パーティションにつき 1 ファイルまでです。 # その他のリソース + バケット化されたテーブルとパーティション化されたテーブルの両方を作成する `CREATE TABLE AS` の例については、「[例: バケット化およびパーティションされたテーブルを作成する](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-bucketed)」を参照してください。 + Athena CTAS ステートメント、AWS Glue for Apache Spark の使用、Apache Iceberg テーブル用バケット化など、AWS データレイクへのバケット化の実装については、AWS Big Data Blog 記事「[Optimize data layout by bucketing with Amazon Athena and AWS Glue to accelerate downstream queries](https://aws.amazon.com/blogs/big-data/optimize-data-layout-by-bucketing-with-amazon-athena-and-aws-glue-to-accelerate-downstream-queries/)」を参照してください。 # データのパーティション化 データをパーティションすることで、各クエリによってスキャンされるデータの量を制限できるようになるため、パフォーマンスが向上し、コストが削減されます。任意のキーでデータをパーティションに分割することができます。一般的な方法では、時間に基づいてデータをパーティションします。これにより、通常、複数レベルのパーティション構成となります。たとえば、1 時間ごとに配信されるデータを年、月、日、時間でパーティションできます。別の例として、データが配信されるソースが多数に分かれているものの、それらのロードは 1 日 1 回だけ行われる場合には、データソースと日付によるパーティションを行います。 Athena では Apache Hive スタイルのパーティションを使用できます。このパーティションのデータパスには、等号で連結されたキーと値のペア (例えば `country=us/...` または `year=2021/month=01/day=26/...`) が含まれています。つまり、それぞれのパスにより、パーティションのキーと値、両方の名前が表されます。新しい Hive パーティションをパーティションされたテーブルにロードするには、(Hive スタイルのパーティションのみで機能する) [MSCK REPAIR TABLE](msck-repair-table.md) コマンドを使用します。 Athena では、Hive 以外のスタイルのパーティション化スキームを使用することも可能です。たとえば、CloudTrail ログと Firehose 配信ストリームは、`data/2021/01/26/us/6fc7845e.json` など、日付部分に個別のパスコンポーネントを使用します。これらの Hive スタイルではないパーティションの場合、[ALTER TABLE ADD PARTITION](alter-table-add-partition.md) を使用して手動でパーティションを追加します。 ## 考慮事項と制限事項 パーティションを使用する場合は、次の点に注意してください。 + パーティションされたテーブルをクエリし、`WHERE` 句でパーティションを指定する場合、Athena はそのパーティションからのデータしかスキャンしません。 + 多数のオブジェクトがあり、データがパーティションされていない Amazon S3 バケットに対してクエリを発行する場合、このようなクエリは Amazon S3 の `GET` リクエストレート制限に影響を及ぼし、Amazon S3 例外を引き起こす可能性があります。エラーを防ぐには、データをパーティションします。また、Amazon S3 のリクエストレートをチューニングすることも検討してください。詳細については、「[設計パターンのベストプラクティス: Simple Storage Service (Amazon S3) のパフォーマンスの最適化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/request-rate-perf-considerations.html)」を参照してください。 + Athena で使用されるパーティションの場所は、`s3` プロトコル (`s3://amzn-s3-demo-bucket/folder/` など) を使用する必要があります。Athena では、他のプロトコル (`s3a://amzn-s3-demo-bucket/folder/` など) を使用する場所は、そこにあるテーブルに対して `MSCK REPAIR TABLE` クエリを実行する場合にクエリが失敗する原因になります。 + Simple Storage Service (Amazon S3) パスがキャメルケースではなく小文字になっていることを確認します (例えば、`userId` ではなく `userid`)。S3 パスがキャメルケースの場合、`MSCK REPAIR TABLE` は AWS Glue Data Catalog にパーティションを追加しません。詳細については、「[MSCK REPAIR TABLE](msck-repair-table.md)」を参照してください。 + `MSCK REPAIR TABLE` がフォルダとそのサブフォルダの両方をスキャンして一致するパーティションスキームを検索するため、別個のテーブルのデータは別個のフォルダ階層に保存するようにしてください。例えば、テーブル 1 のデータが `s3://amzn-s3-demo-bucket1` にあり、テーブル 2 のデータが `s3://amzn-s3-demo-bucket1/table-2-data` にあるとします。両方のテーブルが文字列でパーティション分割されている場合、`MSCK REPAIR TABLE` はテーブル 2 のパーティションをテーブル 1 に追加します。これを回避するには、この代わりに `s3://amzn-s3-demo-bucket2` や `s3://amzn-s3-demo-bucket1` といった別個のフォルダ構造を使用します。この動作は、Amazon EMR および Apache Hive と同じであることに注意してください。 + Athena で AWS Glue Data Catalog を使用している場合は、「[AWS Glue エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/glue.html)」を参照し、アカウントごとおよびテーブルごとのパーティションに関するサービスクォータをご確認ください。 + Athena では、1,000 万のパーティションを持つ AWS Glue テーブルへのクエリがサポートされていますが、1 回のスキャンで読み取れるのは、100 万のパーティションまでです。このようなシナリオでは、パーティションのインデックス作成が役立ちます。詳細については、「AWS Big Data Blog」の記事「[Improve Amazon Athena query performance using AWS Glue Data Catalog partition indexes](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/)」を参照してください。 + AWS Glue Data Catalog を使用している場合にパーティションのクォータの引き上げをリクエストするには、[AWS Glue の Service Quotas コンソール](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/glue/quotas) を参照してください。 ## パーティショニングされたデータを含むテーブルを作成およびロードする パーティションを使用するテーブルを作成するには、[CREATE TABLE](create-table.md) ステートメントの中で `PARTITIONED BY` 句を使用します。次の例のように、`PARTITIONED BY` はデータのパーティションに使用するキーを定義します。`LOCATION` 句では、パーティションされたデータのルートロケーションを指定します。 ``` CREATE EXTERNAL TABLE users ( first string, last string, username string ) PARTITIONED BY (id string) STORED AS parquet LOCATION 's3://amzn-s3-demo-bucket' ``` テーブルを作成した後、クエリ用にパーティションにデータをロードします。Hive スタイルのパーティションでは、[MSCK REPAIR TABLE](msck-repair-table.md) を実行します。Hive スタイルではないパーティションの場合、[ALTER TABLE ADD PARTITION](alter-table-add-partition.md) を使用して手動でパーティションを追加します。 ## クエリのために Hive スタイルと非 Hive スタイルのデータを準備する 以下のセクションでは、Hive スタイルおよび非 Hive スタイルのデータを、Athena でのクエリ向けに準備する方法について説明します。 ### シナリオ 1: Amazon S3 に Hive 形式で保存されているデータの場合 このシナリオでは、パーティションは Amazon S3 内で別々のフォルダに保存されています。例として、[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html) コマンドが出力した、サンプル広告のインプレッションに関するリスティングの一部を以下に示します。指定されたプレフィックスの下に、S3 オブジェクトがリストされています。 ``` aws s3 ls s3://elasticmapreduce/samples/hive-ads/tables/impressions/ PRE dt=2009-04-12-13-00/ PRE dt=2009-04-12-13-05/ PRE dt=2009-04-12-13-10/ PRE dt=2009-04-12-13-15/ PRE dt=2009-04-12-13-20/ PRE dt=2009-04-12-14-00/ PRE dt=2009-04-12-14-05/ PRE dt=2009-04-12-14-10/ PRE dt=2009-04-12-14-15/ PRE dt=2009-04-12-14-20/ PRE dt=2009-04-12-15-00/ PRE dt=2009-04-12-15-05/ ``` この例では、ログを保存する列名 (dt) が日付、時、分の増分と等しくなるように設定されています。親フォルダの場所、スキーマ、およびパーティション分割された列の名前を指定して DDL を提供すると、Athena はこれらのサブフォルダのデータをクエリできます。 #### テーブルを作成する このデータからテーブルを作成するには、以下の Athena DDL ステートメントにあるように、「dt」を使用してパーティションを作成します。 ``` CREATE EXTERNAL TABLE impressions ( requestBeginTime string, adId string, impressionId string, referrer string, userAgent string, userCookie string, ip string, number string, processId string, browserCookie string, requestEndTime string, timers struct, threadId string, hostname string, sessionId string) PARTITIONED BY (dt string) ROW FORMAT serde 'org.apache.hive.hcatalog.data.JsonSerDe' LOCATION 's3://elasticmapreduce/samples/hive-ads/tables/impressions/' ; ``` このテーブルは、Hive のネイティブ JSON シリアライザー/デシリアライザーを使用して Amazon S3 に保存された JSON データを読み込みます。サポートされる形式の詳細については、「[データ用に SerDe を選択する](supported-serdes.md)」を参照してください。 #### MSCK REPAIR TABLE を実行する `CREATE TABLE` クエリの実行後、以下の例のように Athena クエリエディタで `MSCK REPAIR TABLE` コマンドを実行し、パーティションをロードします。 ``` MSCK REPAIR TABLE impressions ``` このコマンドを実行すると、データにクエリするための準備が整います。 #### データのクエリ パーティション列を使用して、インプレッションテーブルのデータをクエリします。例を示します。 ``` SELECT dt,impressionid FROM impressions WHERE dt<'2009-04-12-14-00' and dt>='2009-04-12-13-00' ORDER BY dt DESC LIMIT 100 ``` このクエリにより、次のような結果が表示されます。 ``` 2009-04-12-13-20 ap3HcVKAWfXtgIPu6WpuUfAfL0DQEc 2009-04-12-13-20 17uchtodoS9kdeQP1x0XThKl5IuRsV 2009-04-12-13-20 JOUf1SCtRwviGw8sVcghqE5h0nkgtp 2009-04-12-13-20 NQ2XP0J0dvVbCXJ0pb4XvqJ5A4QxxH 2009-04-12-13-20 fFAItiBMsgqro9kRdIwbeX60SROaxr 2009-04-12-13-20 V4og4R9W6G3QjHHwF7gI1cSqig5D1G 2009-04-12-13-20 hPEPtBwk45msmwWTxPVVo1kVu4v11b 2009-04-12-13-20 v0SkfxegheD90gp31UCr6FplnKpx6i 2009-04-12-13-20 1iD9odVgOIi4QWkwHMcOhmwTkWDKfj 2009-04-12-13-20 b31tJiIA25CK8eDHQrHnbcknfSndUk ``` ### シナリオ 2: データが Hive 形式でパーティション化されない 次の例では `aws s3 ls` コマンドにより、Amazon S3 に保存されている [ELB](elasticloadbalancer-classic-logs.md) ログを表示します。このデータレイアウトでは `key=value` ペアを使用しておらず、つまり、Hive 形式ではないという点に注意してください。(`aws s3 ls` コマンドの `--recursive` オプションは、指定したディレクトリまたはプレフィックスに含まれる、すべてのファイルまたはオブジェクトを一覧表示するように指定します。) ``` aws s3 ls s3://athena-examples-myregion/elb/plaintext/ --recursive 2016-11-23 17:54:46 11789573 elb/plaintext/2015/01/01/part-r-00000-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 8776899 elb/plaintext/2015/01/01/part-r-00001-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 9309800 elb/plaintext/2015/01/01/part-r-00002-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 9412570 elb/plaintext/2015/01/01/part-r-00003-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 10725938 elb/plaintext/2015/01/01/part-r-00004-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 9439710 elb/plaintext/2015/01/01/part-r-00005-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 0 elb/plaintext/2015/01/01_$folder$ 2016-11-23 17:54:47 9012723 elb/plaintext/2015/01/02/part-r-00006-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 7571816 elb/plaintext/2015/01/02/part-r-00007-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 9673393 elb/plaintext/2015/01/02/part-r-00008-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 11979218 elb/plaintext/2015/01/02/part-r-00009-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 9546833 elb/plaintext/2015/01/02/part-r-00010-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 10960865 elb/plaintext/2015/01/02/part-r-00011-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 0 elb/plaintext/2015/01/02_$folder$ 2016-11-23 17:54:48 11360522 elb/plaintext/2015/01/03/part-r-00012-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 11211291 elb/plaintext/2015/01/03/part-r-00013-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 8633768 elb/plaintext/2015/01/03/part-r-00014-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 11891626 elb/plaintext/2015/01/03/part-r-00015-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 9173813 elb/plaintext/2015/01/03/part-r-00016-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 11899582 elb/plaintext/2015/01/03/part-r-00017-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 0 elb/plaintext/2015/01/03_$folder$ 2016-11-23 17:54:50 8612843 elb/plaintext/2015/01/04/part-r-00018-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 10731284 elb/plaintext/2015/01/04/part-r-00019-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 9984735 elb/plaintext/2015/01/04/part-r-00020-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 9290089 elb/plaintext/2015/01/04/part-r-00021-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 7896339 elb/plaintext/2015/01/04/part-r-00022-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8321364 elb/plaintext/2015/01/04/part-r-00023-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 0 elb/plaintext/2015/01/04_$folder$ 2016-11-23 17:54:51 7641062 elb/plaintext/2015/01/05/part-r-00024-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 10253377 elb/plaintext/2015/01/05/part-r-00025-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8502765 elb/plaintext/2015/01/05/part-r-00026-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 11518464 elb/plaintext/2015/01/05/part-r-00027-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 7945189 elb/plaintext/2015/01/05/part-r-00028-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 7864475 elb/plaintext/2015/01/05/part-r-00029-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 0 elb/plaintext/2015/01/05_$folder$ 2016-11-23 17:54:51 11342140 elb/plaintext/2015/01/06/part-r-00030-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8063755 elb/plaintext/2015/01/06/part-r-00031-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9387508 elb/plaintext/2015/01/06/part-r-00032-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9732343 elb/plaintext/2015/01/06/part-r-00033-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 11510326 elb/plaintext/2015/01/06/part-r-00034-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9148117 elb/plaintext/2015/01/06/part-r-00035-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 0 elb/plaintext/2015/01/06_$folder$ 2016-11-23 17:54:52 8402024 elb/plaintext/2015/01/07/part-r-00036-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 8282860 elb/plaintext/2015/01/07/part-r-00037-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 11575283 elb/plaintext/2015/01/07/part-r-00038-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 8149059 elb/plaintext/2015/01/07/part-r-00039-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 10037269 elb/plaintext/2015/01/07/part-r-00040-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 10019678 elb/plaintext/2015/01/07/part-r-00041-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 0 elb/plaintext/2015/01/07_$folder$ 2016-11-23 17:54:53 0 elb/plaintext/2015/01_$folder$ 2016-11-23 17:54:53 0 elb/plaintext/2015_$folder$ ``` #### ALTER TABLE ADD PARTITION を実行する ここでのデータは Hive 形式ではないため、パーティションの作成後に、テーブルにパーティションを追加するために `MSCK REPAIR TABLE` コマンドを使用することはできません。代わりに [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) コマンドを使用することで、各パーティションを手動で追加できます。例えば、s3://athena-examples-*myregion*/elb/plaintext/2015/01/01/ のデータをロードするには、次のクエリを実行します。Amazon S3 フォルダごとに個別のパーティション列は必要ないこと、およびパーティションキーの値が Amazon S3 キーと同じではない場合があることに注意してください。 ``` ALTER TABLE elb_logs_raw_native_part ADD PARTITION (dt='2015-01-01') location 's3://athena-examples-us-west-1/elb/plaintext/2015/01/01/' ``` パーティションが既に存在する場合は、Partition already exists というエラーが表示されます。このエラーを回避するには、`IF NOT EXISTS` 句を使用することができます。詳細については、「[ALTER TABLE ADD PARTITION](alter-table-add-partition.md)」を参照してください。パーティションを削除する場合は、[ALTER TABLE DROP PARTITION](alter-table-drop-partition.md) を使用します。 ## パーティション射影を検討する パーティション射影を使用すると、自分自身でのパーティション管理の必要性を回避できます。パーティション射影は、高度にパーティション化されていて、その構造が既知のテーブルで使用できるオプションです。パーティション射影では、パーティションの値と場所はメタデータリポジトリから読み取られるのではなく、テーブルのプロパティ設定を基に算出されます。メモリ内での計算処理は、リモートルックアップよりも高速であるため、パーティション射影を使用することでクエリランタイムが大幅に短縮されます。 詳細については、「[Amazon Athena でパーティション射影を使用する](partition-projection.md)」を参照してください。 ## その他のリソース + Firehose データのパーティショニングオプションについては、「[Amazon Data Firehose 例](partition-projection-kinesis-firehose-example.md)」を参照してください。 + [JDBC ドライバー](connect-with-jdbc.md)を使用して、パーティションの追加を自動化できます。 + CTAS と INSERT INTO を使用して、データセットをパーティションできます。詳細については、「[ETL およびデータ分析での CTAS および INSERT INTO を使用する](ctas-insert-into-etl.md)」を参照してください。 # Amazon Athena でパーティション射影を使用する Athena では、高度にパーティションされたテーブルのクエリ処理を高速化し、パーティション管理を自動化するためにパーティション射影を使用できます。 パーティション射影では、Athena は AWS Glue のテーブルに直接設定したテーブルプロパティを使用してパーティション値と場所を計算します。テーブルプロパティにより、Athena は AWS Glue Data Catalogで時間をかけてメタデータを検索しなくても、必要なパーティション情報を「射影」または決定できます。多くの場合、インメモリオペレーションはリモートオペレーションよりも高速であるため、パーティション射影は高度にパーティションされたテーブルに対するクエリの実行時間を短縮できます。クエリおよび基盤となるデータの特定の特性によっては、パーティション射影によって、パーティションメタデータの取得時に制限されているクエリのクエリランタイムが大幅に短縮されます。 ## パーティションプルーニングとパーティション射影を理解する パーティションプルーニングは、メタデータを収集し、クエリに適用されるパーティションのみに「プルーニング」します。多くの場合、これによってクエリが高速化されます。Athena は、パーティション射影用に設定されたテーブルなどのパーティション列があるすべてのテーブルに対してパーティションプルーニングを使用します。 通常、クエリを処理する場合、Athena はパーティションプルーニングを実行する前に AWS Glue Data Catalog に対して `GetPartitions` 呼び出しを行います。テーブルに多数のパーティションがある場合、`GetPartitions` を使用すると、パフォーマンスに悪影響が及ぶ可能性があります。これを回避するには、パーティション射影を使用します。パーティション射影を設定すると、Athena が独自にパーティションを構築するために必要なすべての情報を得ることができるため、`GetPartitions` を呼び出す必要がなくなります。 ## パーティション射影の使用方法 パーティション射影を使用するには、AWS Glue Data Catalog または [外部 Hive メタストア](connect-to-data-source-hive.md)のテーブルプロパティで、各パーティション列のパーティション値と射影型の範囲を指定します。テーブル上のこれらのカスタムプロパティは、Athena がテーブルでクエリを実行するときに、どのパーティションパターンを期待すべきかを把握できるようにします。クエリの実行中、Athena は、この情報を使用して、パーティション値を射影します。AWS Glue Data Catalog または外部 Hive メタストアから取得するのではありません。これにより、クエリの実行時間が短縮されるだけでなく、Athena、AWS Glue、または外部の Hive メタストアでパーティションを手動で作成する必要がなくなるため、パーティション管理も自動化されます。 **重要** テーブルでパーティション射影を有効にすると、AWS Glue Data Catalog または Hive メタストア内のテーブルに登録されているパーティションメタデータが Athena によりすべて無視されます。 ## 一部のユースケース パーティション射影が役立つシナリオには、次のようなものがあります。 + 高度にパーティション化されたテーブルに対するクエリが、思ったほどすぐに完了しない。 + データに新しい日付または時刻パーティションが作成されたとき、定期的にパーティションをテーブルに追加する。パーティション射影で、新しいデータが到着したときに使用できる相対日付範囲を設定している。 + Amazon S3 に高度にパーティションされたデータがある。データは、AWS Glue Data Catalog または Hive メタストア内のモデルに対して実用的ではなく、クエリがそのごく一部のみを読み込む。 ### 射影可能なパーティション構造 パーティション射影は、パーティションが次のような予測可能なパターン (ただし、これに限りません) に従う場合に最も簡単に設定できます。 + **整数** – `[1, 2, 3, 4, ..., 1000]` または `[0500, 0550, 0600, ..., 2500]` などの整数の連続的なシーケンス。 + **日付** – `[20200101, 20200102, ..., 20201231]` または `[1-1-2020 00:00:00, 1-1-2020 01:00:00, ..., 12-31-2020 23:00:00]` などの日付や日時の連続的なシーケンス。 + **列挙値** – 空港コードや AWS リージョン など、列挙値の有限集合。 + **AWS のサービス ログ** – AWS のサービス ログは通常、AWS Glue で指定できるので Athena がパーティション射影に使用できるパーティションスキームを持つ既知の構造になっています。 ### パーティションパステンプレートをカスタマイズする方法 デフォルトで、Athena はフォーム `s3://amzn-s3-demo-bucket//partition-col-1=/partition-col-2=/` を使用してパーティションの場所を構築しますが、データの編成が異なる場合、Athena はこのパステンプレートをカスタマイズするためのメカニズムを提供します。手順については、「[カスタム S3 ストレージの場所を指定する方法](partition-projection-setting-up.md#partition-projection-specifying-custom-s3-storage-locations)」を参照してください。 ## 考慮事項と制限事項 以下の考慮事項に注意してください。 + パーティション射影により、AWS Glue または外部 Hive メタストアでパーティションを手動で指定する必要がなくなります。 + テーブルでパーティション射影を有効にすると、そのテーブルについては、Athena は AWS Glue Data Catalog 内または外部 Hive メタストア内のパーティションメタデータを無視します。 + 射影されたパーティションが Amazon S3 に存在しない場合でも、Athena はそのパーティションを射影します。Athena はエラーをスローし、データを返しません。ただし、空のパーティションが多すぎる場合、従来の AWS Glue パーティションに比べてパフォーマンスが低下する可能性があります。射影パーティションの半分以上が空の場合は、従来のパーティションを使用することをお勧めします。 + パーティション射影に定義された範囲境界を超える値のクエリは、エラーを返しません。その代わりに、クエリが実行されても行は返されません。たとえば、2020 年に開始される時間関連データがあり、`'projection.timestamp.range'='2020/01/01,NOW'` として定義されている場合、`SELECT * FROM table-name WHERE timestamp = '2019/02/02'` のようなクエリは正常に完了しますが、行は返されません。 + パーティション射影は、テーブルが Athena を通じてクエリされる場合以外は使用できません。同じテーブルが Amazon Redshift Spectrum、Athena for Spark、Amazon EMR などの別のサービスを介して読み取られる場合、標準のパーティションメタデータが使用されます。 + パーティション射影は DML 限定の機能であるため、`SHOW PARTITIONS` は、Athena によって射影されていても、AWS Glue カタログまたは外部の Hive メタストアには登録されていないパーティションをリストしません。 + Athena は、パーティションの射影の設定としてビューのテーブルプロパティを使用しません。この制限を回避するには、ビューが参照するテーブルのテーブルプロパティでパーティション射影を構成して有効にします。 ## 動画 以下の動画は、パーティション射影を使用して Athena でのクエリのパフォーマンスを向上させる方法を紹介するものです。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/iUD5pPpcyZk/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/iUD5pPpcyZk) **Topics** + [パーティションプルーニングとパーティション射影を理解する](#partition-projection-pruning-vs-projection) + [パーティション射影の使用方法](#partition-projection-using) + [一部のユースケース](#partition-projection-use-cases) + [考慮事項と制限事項](#partition-projection-considerations-and-limitations) + [動画](#partition-projection-video) + [パーティション射影を設定する](partition-projection-setting-up.md) + [パーティション射影用にサポートされている型](partition-projection-supported-types.md) + [動的な ID パーティショニングを使用する](partition-projection-dynamic-id-partitioning.md) + [Amazon Data Firehose 例](partition-projection-kinesis-firehose-example.md) # パーティション射影を設定する テーブルのプロパティでのパーティション射影のセットアップは、次の 2 つのステップで行います。 1. 各パーティション列のデータ範囲と関連するパターンを指定するか、カスタムテンプレートを使用します。 1. テーブルのパーティション射影を有効にします。 **注記** パーティション射影プロパティを既存のテーブルに追加する前に、パーティション射影プロパティをセットアップするパーティションの列がテーブルスキーマにすでに存在している必要があります。パーティション列がまだ存在しない場合、既存のテーブルに手動でパーティション列を追加する必要があります。AWS Glue では、この手順を自動的に実行しません。 このセクションでは、AWS Glue にテーブルプロパティを設定する方法について説明します。これらを設定するには、AWS Glue コンソール、Athena [CREATE TABLE](create-table.md) クエリ、または [AWS Glue API](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api.html) オペレーションを使用できます。次の手順は、AWS Glue コンソールでプロパティを設定する方法を示しています。 **AWS Glue コンソールを使用してパーティション射影を設定して有効化する** 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. [**Tables**] (テーブル) タブを選択します。 **[Tables]** (テーブル) タブでは、既存のテーブルを編集する、または **[Add tables]** (テーブルの追加) を選択して新しいテーブルを作成できます。テーブルを手動またはクローラで追加する方法については、「AWS Glue デベロッパーガイド」の「[AWS Glue コンソールでのテーブルの使用](https://docs.aws.amazon.com/glue/latest/dg/console-tables.html)」を参照してください。 1. テーブルのリストで、編集するテーブルのリンクを選択します。 ![\[AWS Glue コンソールで、編集するテーブルを選択します。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/partition-projection-1.png) 1. **[Actions]** (アクション)、**[Edit table]** (テーブルの編集) の順に選択します。 1. **[Edit table]** (テーブルの編集) ページの **[Table properties]** (テーブルプロパティ) セクションで、パーティション化された列ごとに以下のキーと値のペアを追加します。 1. **[Key]** (キー)に、`projection.columnName.type` を追加します。 1. [**値**] に、サポートされている型 (`enum`、`integer`、`date`、`injected`) のいずれかを追加します。詳細については、「[パーティション射影用にサポートされている型](partition-projection-supported-types.md)」(パーティション射影に対応した型) を参照してください。 1. 「[パーティション射影用にサポートされている型](partition-projection-supported-types.md)」のガイダンスに従って、設定要件に従って追加のキーと値のペアを追加します。 次のテーブル設定例では、パーティション射影用に `year` 列を設定し、返すことのできる値を 2010～2016 の範囲に制限します。 ![\[AWS Glue コンソールのテーブルプロパティでパーティション列のパーティション射影を構成。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/partition-projection-3.png) 1. キーと値のペアを追加して、パーティション射影を有効にします。[**Key**] (キー) には `projection.enabled` と入力し、その [**Value**] (値) には `true` と入力します。 **注記** `projection.enabled` を `false` に設定することで、このテーブルのパーティション射影をいつでも無効にできます。 1. 完了したら、[**Save **] を選択します。 1. Athena クエリエディタで、テーブル用に設定した列でのクエリをテストします。 次のクエリ例では、`SELECT DISTINCT` を使用して、`year` 列から一意の値を返します。データベースには 1987 年から 2016 年のデータが含まれていますが、`projection.year.range` プロパティで返される値が 2010 年から 2016 年に制限されています。 ![\[パーティション射影を使用する列のクエリ。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/partition-projection-5.png) **注記** `projection.enabled` を `true` に設定したが、1 つ以上のパーティション列を設定できない場合は、次のようなエラーメッセージが表示されます。 `HIVE_METASTORE_ERROR: Table database_name.table_name is configured for partition projection, but the following partition columns are missing projection configuration: [column_name] (table database_name.table_name)`. ## カスタム S3 ストレージの場所を指定する方法 AWS Glue でテーブルプロパティを編集するときは、射影されたパーティションのカスタム Amazon S3 パステンプレートを指定することもできます。カスタムテンプレートは、Athena が通常の `.../column=value/...` パターンに従わないカスタム Amazon S3 ファイルの場所に、パーティション値を適切にマッピングすることを可能にします。 カスタムテンプレートの使用はオプションです。ただし、カスタムテンプレートを使用する場合、各パーティション列のプレースホルダをテンプレートに含める必要があります。テンプレート化された場所は、パーティション化されたデータファイルがパーティションごとの「フォルダ」に格納されるように、スラッシュで終わる必要があります。 **カスタムパーティションの場所のテンプレートを指定するには** 1. 手順に従って、[AWS Glue コンソールを使用して、パーティション射影の設定と有効化を行い](#partition-projection-setting-up-procedure)、次のようにカスタムテンプレートを指定するキーと値のペアを追加します。 1. [**キー**] に「`storage.location.template`」と入力します。 1. [**値**] で、すべてのパーティション列のプレースホルダを含む場所を指定します。各プレースホルダ (および S3 パス自体) が 1 つのスラッシュで終了していることを確認します。 次のテンプレート値の例では、パーティション列 `a`、`b`、`c` があるテーブルを想定しています。 ``` s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/${c}/ ``` ``` s3://amzn-s3-demo-bucket/table_root/c=${c}/${b}/some_static_subdirectory/${a}/${b}/${c}/${c}/ ``` 同じテーブルの場合、次のテンプレート値の例は、列 `c` のプレースホルダが含まれていないため無効です。 ``` s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/ ``` 1. [**Apply**] を選択します。 # パーティション射影用にサポートされている型 テーブルには、`enum`、`integer`、`date,`、または `injected` パーティション列の型の任意の組み合わせを使用できます。 ## 列挙型 値が列挙セット (空港コードや AWS リージョン など) のメンバーであるパーティション列には、`enum` 型を使用します。 テーブルでパーティションプロパティを次のように定義します。 **** | プロパティ名 | 値の例 | 説明 | | --- | --- | --- | | projection.columnName.type | `enum` | 必須。列 columnName に使用する射影型です。列挙型の使用を通知するには、値を enum (大文字と小文字を区別しない) にする必要があります。先頭と末尾に空白文字を使用できます。 | | projection.columnName.values | `A,B,C,D,E,F,G,Unknown` | 必須。列 columnName に対する列挙されたパーティション値のカンマ区切りリスト。空白は列挙値の一部とみなされます。 | **注記** ベストプラクティスとして、`enum` ベースのパーティション射影の使用は数 10 個以下に制限することが推奨されます。`enum` 射影に固有の制限はありませんが、テーブルのメタデータを gzip に圧縮するときには、合計サイズが約 1MB という AWS Glue の制限を超えることはできません。この制限は、列名、場所、およびストレージ形式といったテーブルの主要部分全体で共有されることに注意してください。`enum` 射影で使用している一意の ID が数十個ある場合は、サロゲートフィールドにバケット化する一意の値を少なくするなど別のアプローチを検討してください。カーディナリティをトレードオフすることで、`enum` フィールドの一意の値の数を制御できます。 ## 整数型 使用できる値が定義された範囲内の整数として解釈可能なパーティション列には、整数型を使用します。射影整数列は現在、Java 符号付き長整数値 (-263 ～ 263-1。両端の値を含みます) の範囲に制限されています。 **** | プロパティ名 | 値の例 | 説明 | | --- | --- | --- | | projection.columnName.type | `integer` | 必須。列 columnName に使用する射影型です。整数型の使用を通知するには、値を integer (大文字と小文字を区別しない) にする必要があります。先頭と末尾に空白文字を使用できます。 | | projection.columnName.range | `0,10` `-1,8675309` `0001,9999` | 必須。columnName 列のクエリによって返される最小値と最大値の範囲を示す 2 要素カンマ区切りリスト。値はハイフンではなくカンマで区切る必要があることに注意してください。両端の値が含まれ、負の値でもかまいません。また、先頭をゼロにすることもできます。先頭と末尾に空白文字を使用できます。 | | projection.columnName.interval | `1` `5` | オプション。列 columnName の連続するパーティション値の間隔を指定する正の整数。たとえば、range 値が「1,3」で、interval 値が「1」の場合、値 1、2、3 が生成されます。range 値が同じで interval が「2」の場合、値 1 と 3 が生成され、2 はスキップされます。先頭と末尾に空白文字を使用できます。デフォルトは 1 です。 | | projection.columnName.digits | `1` `5` | オプション。列 columnName のパーティション値の最終表現に含める桁数を指定する正の整数。たとえば、range 値が「1,3」で digits 値が「1」の場合、値 1、2、3 が生成されます。range 値が同じで digits 値が「2」の場合、値 01、02、03 が生成されます。先頭と末尾に空白文字を使用できます。デフォルトでは、静的な桁数も先頭のゼロもありません。 | ## 日付型 定義された範囲内の日付 (オプションで時刻を含む) として解釈可能な値を持つパーティション列には、日付型を使用します。 **重要** 射影される日付列は、クエリの実行時に協定世界時 (UTC) で生成されます。 **** | プロパティ名 | 値の例 | 説明 | | --- | --- | --- | | projection.columnName.type | `date` | 必須。列 columnName に使用する射影型です。日付タイプの使用を通知するには、値を date (大文字と小文字を区別しない) にする必要があります。先頭と末尾に空白文字を使用できます。 | | projection.columnName.range | `201701,201812` `01-01-2010,12-31-2018` `NOW-3YEARS,NOW` `201801,NOW+1MONTH` | 必須。*columnName* 列の最小および最大 `range` 値を提供する、2 要素のカンマ区切りのリストです。両端の値が含まれ、Java の `java.time.*` 日付型と互換性のある任意の形式を使用できます。最小値と最大値のどちらも同じ形式を使用する必要があります。`.format` プロパティで指定する形式は、これらの値に使用される形式にする必要があります。 この列には、次の正規表現パターンの形式で相対日付文字列を含めることもできます。 `\s*NOW\s*(([\+\-])\s*([0-9]+)\s*(YEARS?\|MONTHS?\|WEEKS?\|DAYS?\|HOURS?\|MINUTES?\|SECONDS?)\s*)?` 空白は使用できますが、日付リテラルは日付文字列自体の一部と見なされます。 | | projection.columnName.format | `yyyyMM` `dd-MM-yyyy` `dd-MM-yyyy-HH-mm-ss` | 必須。Java の日付フォーマット [DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) に基づく日付形式文字列。サポートされている任意の Java.time.\$1 型を使用できます。 | | projection.columnName.interval | `1` `5` | 列 *columnName*の連続するパーティション値の間隔を指定する正の整数。たとえば、`range` 値が `2017-01,2018-12`、`interval` 値が `1`、`interval.unit` 値が `MONTHS` の場合、2017-01、2017-02、2017-03 というように値が生成されます。`range` 値が同じで `interval` 値が `2`、`interval.unit` 値が `MONTHS` の場合、2017-01、2017-03、2017-05 というように値が生成されます。先頭と末尾に空白文字を使用できます。 指定された日付が単一日または単一月の精度である場合、`interval` はオプションであり、デフォルトではそれぞれ 1 日または 1 か月です。それ以外の場合、`interval` が必要です。 | | projection.columnName.interval.unit | `YEARS` `MONTHS` `WEEKS` `DAYS` `HOURS` `MINUTES` `SECONDS` `MILLIS` | [ChronoUnit](https://docs.oracle.com/javase/8/docs/api/java/time/temporal/ChronoUnit.html) のシリアル化された形式を表す時間単位の単語。使用できる値は `YEARS`、`MONTHS`、`WEEKS`、`DAYS`、`HOURS`、`MINUTES`、`SECONDS`、`MILLIS` です。これらの値の大文字と小文字は区別されません。 指定された日付が単一日または単一月の精度である場合、`interval.unit` はオプションであり、デフォルトではそれぞれ 1 日または 1 か月です。それ以外の場合は、`interval.unit` が必要です。 | **Example – 月によるパーティション** 次のテーブル設定例では、2015 年から現在までのデータを月ごとにパーティション化しています。 ``` 'projection.month.type'='date', 'projection.month.format'='yyyy-MM', 'projection.month.interval'='1', 'projection.month.interval.unit'='MONTHS', 'projection.month.range'='2015-01,NOW', ... ``` ## 挿入型 使用できる値をいくつかの論理範囲内で手動で生成することができないが、クエリの `WHERE` 句で単一の値として指定されるパーティション列には、挿入型を使用します。 次の点に留意することが重要です。 + 挿入列ごとにフィルタ式が指定されていない場合、挿入列でのクエリは失敗します。 + 挿入された列のフィルター式に複数の値を持つクエリは、値が論理和である場合にのみ成功します。 + `string` 型の列のみがサポートされています。 + 挿入されたパーティション列で `WHERE IN` 句を使用する場合、`IN` リストで指定できる値は 1,000 個に制限されます。挿入された列のパーティションが 1,000 個を超えるデータセットをクエリするには、クエリを複数の小さなクエリに分割し、それぞれ `WHERE IN` 句に最大 1,000 個の値を指定して結果を集計します。 **** | プロパティ名 | 値 | 説明 | | --- | --- | --- | | projection.columnName.type | `injected` | 必須。列 columnName に使用する射影型です。string 型のみがサポートされています。値 injected (大文字と小文字は区別されません) を指定する必要があります。先頭と末尾に空白文字を使用できます。 | 詳細については、「[`injected` 射影タイプを使用すべき場合](partition-projection-dynamic-id-partitioning.md#partition-projection-injection)」を参照してください。 # 動的な ID パーティショニングを使用する カーディナリティの高いプロパティによってデータが分割されている場合や、値が事前にわからない場合は、`injected` 射影型を使用できます。このようなプロパティの例としては、ユーザー名、デバイスや製品の ID などがあります。`injected` 射影型を使用してパーティションキーを設定すると、Athena はクエリ自体の値を使用して、読み取られるパーティションのセットを計算します。 Athena が `injected` プロジェクションタイプで設定されたパーティションキーを持つテーブルでクエリを実行できるようにするには、以下が満たされている必要があります。 + クエリには、パーティションキーの値が少なくとも 1 つ含まれている必要があります。 + 値は、データを読み取らなくても評価できるリテラルまたは式でなければなりません。 これらの基準のいずれかが満たされない場合、クエリは次のエラーで失敗します。 CONSTRAINT\$1VIOLATION: injected 射影型のパーティション列 *column\$1name* では、WHERE 句に静的な等号条件のみが含まれており、このような条件が少なくとも 1 つ存在する必要があります。 ## `injected` 射影タイプを使用すべき場合 IoT デバイスからのイベントで構成され、デバイスの ID で分割されたデータセットがあるとします。このデータセットには次の特徴があります。 + デバイス ID はランダムに生成されています。 + 新しいデバイスは頻繁にプロビジョニングされます。 + 現在、数十万台のデバイスがあり、今後は数百万台になる見込みです。 このデータセットを従来のメタストアで管理するのは容易ではありません。データストレージとメタストア間でパーティションを同期させることは難しく、クエリ計画中はパーティションのフィルタリングに時間がかかることがあります。ただし、パーティションプロジェクションを使用するようにテーブルを設定し、`injected` 射影型を使用する場合には、メタストア内のパーティションを管理する必要がないことと、クエリでパーティションメタデータを検索する必要がないことの 2 つの利点があります。 次の `CREATE TABLE` の例では、先ほど説明したデバイスイベントデータセットのテーブルを作成します。このテーブルでは、injected 射影型を使用しています。 ``` CREATE EXTERNAL TABLE device_events ( event_time TIMESTAMP, data STRING, battery_level INT ) PARTITIONED BY ( device_id STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.device_id.type" = "injected", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${device_id}" ) ``` 次のクエリ例では、特定の 3 つのデバイスから 12 時間にわたって受信したイベントの数を調べます。 ``` SELECT device_id, COUNT(*) AS events FROM device_events WHERE device_id IN ( '4a770164-0392-4a41-8565-40ed8cec737e', 'f71d12cf-f01f-4877-875d-128c23cbde17', '763421d8-b005-47c3-ba32-cc747ab32f9a' ) AND event_time BETWEEN TIMESTAMP '2023-11-01 20:00' AND TIMESTAMP '2023-11-02 08:00' GROUP BY device_id ``` このクエリを実行すると、Athena は `device_id` パーティションキーの 3 つの値を確認し、それらを使用してパーティションの場所を計算します。Athena は `storage.location.template` プロパティの値を使用して以下の場所を生成します。 + `s3://amzn-s3-demo-bucket/prefix/4a770164-0392-4a41-8565-40ed8cec737e` + `s3://amzn-s3-demo-bucket/prefix/f71d12cf-f01f-4877-875d-128c23cbde17` + `s3://amzn-s3-demo-bucket/prefix/763421d8-b005-47c3-ba32-cc747ab32f9a` パーティションの射影設定から `storage.location.template` プロパティを除外した場合、Athena は Hive 形式のパーティション分割を使用して、`LOCATION` の値 (例: `s3://amzn-s3-demo-bucket/prefix/device_id=4a770164-0392-4a41-8565-40ed8cec737e`) に基づいてパーティションの場所を射影します。 # Amazon Data Firehose 例 Firehose を使用して Amazon S3 にデータを配信する場合、デフォルト設定は、次の例にあるようなキーを持つオブジェクトを書き込みます。 ``` s3://amzn-s3-demo-bucket/prefix/yyyy/MM/dd/HH/file.extension ``` 新しいデータが到着したときにパーティションを AWS Glue Data Catalog に追加する必要なく、クエリ時にパーティションを自動的に検索する Athena テーブルを作成するには、パーティション射影を使用できます。 以下の `CREATE TABLE` 例は、デフォルトの Firehose 設定を使用しています。 ``` CREATE EXTERNAL TABLE my_ingested_data ( ... ) ... PARTITIONED BY ( datehour STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.datehour.type" = "date", "projection.datehour.format" = "yyyy/MM/dd/HH", "projection.datehour.range" = "2021/01/01/00,NOW", "projection.datehour.interval" = "1", "projection.datehour.interval.unit" = "HOURS", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${datehour}/" ) ``` `CREATE TABLE` ステートメントの `TBLPROPERTIES` 句は、Athena に次のように指定します。 + テーブルのクエリ時にパーティション射影を使用する + パーティションキー `datehour` は `date` 型である (オプションで時刻を含む) + 日付の書式設定方法 + 日付時刻の範囲。値はハイフンではなくカンマで区切る必要があることに注意してください。 + Amazon S3 でのデータの検索先。 テーブルをクエリすると、Athena は `datehour` の値を計算し、ストレージロケーションテンプレートを使用して、パーティションの場所のリストを生成します。 **Topics** + [`date` タイプの使用方法](partition-projection-kinesis-firehose-example-using-the-date-type.md) + [パーティションキーの選択方法](partition-projection-kinesis-firehose-example-choosing-partition-keys.md) + [カスタムプレフィックスと動的パーティショニングの使用方法](partition-projection-kinesis-firehose-example-using-custom-prefixes-and-dynamic-partitioning.md) # `date` タイプの使用方法 射影パーティションキーに `date` 型を使用する場合、範囲を指定する必要があります。Firehose 配信ストリームが作成される前の日付に関するデータがないため、作成日を開始点として使用できます。また、将来の日付のデータがないため、最後として `NOW` という特別なトークンを使用できます。 `CREATE TABLE` の例では、開始日は 2021 年 1 月 1 日 UTC 午前 0 時と指定されています。 **注記** Athena が既存のパーティションのみを検索できるように、可能な限りデータと一致する範囲を設定します。 サンプルテーブルでクエリを実行すると、Athena は、`datehour`パーティションキーの条件を、値を生成する範囲と組み合わせて使用します。次のクエリについて考えます。 ``` SELECT * FROM my_ingested_data WHERE datehour >= '2020/12/15/00' AND datehour < '2021/02/03/15' ``` `SELECT` クエリの最初の条件では、`CREATE TABLE` ステートメントで指定された日付範囲の開始前の日付を使用しています。パーティション射影の設定では 2021 年 1 月 1 日より前の日付にはパーティションが指定されていないため、Athena は次の場所でのみデータを検索し、クエリ内のそれ以前の日付を無視します。 ``` s3://amzn-s3-demo-bucket/prefix/2021/01/01/00/ s3://amzn-s3-demo-bucket/prefix/2021/01/01/01/ s3://amzn-s3-demo-bucket/prefix/2021/01/01/02/ ... s3://amzn-s3-demo-bucket/prefix/2021/02/03/12/ s3://amzn-s3-demo-bucket/prefix/2021/02/03/13/ s3://amzn-s3-demo-bucket/prefix/2021/02/03/14/ ``` 同様に、クエリが 2021 年 2 月 3 日 15:00 より前の日付と時刻で実行された場合、最後のパーティションに反映されているのは、クエリ条件の日時ではなく、現在の日付と時刻です。 最新のデータをクエリする場合は、Athena が将来の日付を生成しないという事実を活用し、次の例のように、開始 `datehour` のみを指定することができます。 ``` SELECT * FROM my_ingested_data WHERE datehour >= '2021/11/09/00' ``` # パーティションキーの選択方法 パーティション射影でパーティションの場所をパーティションキーにマッピングする方法を指定できます。前のセクションの `CREATE TABLE` の例では、日付と時刻を datehour という 1 つのパーティションキーにまとめましたが、他のスキームも可能です。例えば、パーティションキーを year、month、day、hour に分けてテーブルを構成することもできます。 ただし、日付を年、月、日に分割すると、`date` パーティション投影タイプは使用できなくなります。別の方法として、日付と時間を分離して `date` パーティション投影タイプを引き続き活用する方法がありますが、時間の範囲を指定するクエリは読みやすくします。 それを考慮して、次の `CREATE TABLE` の例では、日付と hour を分けています。`date` は SQL の予約語であるため、この例では日付を表すパーティションキーの名前として `day` を使用します。 ``` CREATE EXTERNAL TABLE my_ingested_data2 ( ... ) ... PARTITIONED BY ( day STRING, hour INT ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.format" = "yyyy/MM/dd", "projection.day.range" = "2021/01/01,NOW", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "projection.hour.type" = "integer", "projection.hour.range" = "0,23", "projection.hour.digits" = "2", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${hour}/" ) ``` `CREATE TABLE` ステートメントの例では、hour は独立したパーティションキーで、整数に設定されています。hour パーティションキーの設定では、0～23 の範囲が指定され、Athena がパーティションの場所を生成するときに、hour を 2 桁でフォーマットする必要があります。 `my_ingested_data2` テーブルのクエリは次の例のようになります。 ``` SELECT * FROM my_ingested_data2 WHERE day = '2021/11/09' AND hour > 3 ``` ## パーティションキーとパーティション射影データ型を理解する 最初の `CREATE TABLE` の例の `datehour` キーは、パーティション射影の設定では `date` として設定されていますが、パーティションキーの型は `string` なので、注意してください。2 番目の例の `day` についても同様です。パーティション射影に設定されている型は、Athena がパーティションの場所を生成するときの値のフォーマット方法のみを指示します。指定する型によって、パーティションキーの型は変更されません。クエリでは、`datehour` と `day` は `string` 型です。 クエリに `day = '2021/11/09'` のような条件が含まれている場合、Athena はパーティション射影設定で指定された日付形式を使用して、式の右辺の文字列を解析します。Athena は、日付が設定された範囲内であることを確認した後、日付形式を再び使用して日付を文字列として保存場所テンプレートに挿入します。 同様に、`day > '2021/11/09'` のようなクエリ条件の場合、Athena は右辺を解析し、設定された範囲内で一致するすべての日付のリストを生成します。次に、日付形式を使用して各日付を保存場所テンプレートに挿入し、パーティションの場所のリストを作成します。 `day > '2021-11-09'` や `day > DATE '2021-11-09'` と同じ条件を書くと動作しません。最初のケースでは、日付形式が一致せず (スラッシュではなくハイフンになっていることに注意してください)、2 番目のケースでは、データ型が一致しません。 # カスタムプレフィックスと動的パーティショニングの使用方法 Firehose は、[カスタムプレフィックス](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html)と[動的パーティショニング](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html)を使用して設定できます。これらの機能を使用して、Amazon S3 キーを設定し、ユースケースをより適切にサポートするパーティション化スキームを設定できます。また、これらのパーティション化スキームでパーティション射影を使用し、それに応じて設定することもできます。 例えば、カスタムプレフィックス機能を使用して、デフォルトの `yyyy/MM/dd/HH` スキームではなく、ISO 形式の日付を持つ Amazon S3 キーを取得できます。 以下の例にあるように、カスタムプレフィックスと動的パーティショニングを組み合わせて、Firehose メッセージから `customer_id` のようなプロパティを抽出することもできます。 ``` prefix/!{timestamp:yyyy}-!{timestamp:MM}-!{timestamp:dd}/!{partitionKeyFromQuery:customer_id}/ ``` Amazon S3 プレフィックスを使用すると、Firehose 配信ストリームは、`s3://amzn-s3-demo-bucket/prefix/2021-11-01/customer-1234/file.extension` などのキーにオブジェクトを書き込みます。`customer_id` のようなプロパティの場合、事前に値が分かっていない場合もあるので、パーティション射影型 `injected` を使用し、次のような `CREATE TABLE` ステートメントを使用できます。 ``` CREATE EXTERNAL TABLE my_ingested_data3 ( ... ) ... PARTITIONED BY ( day STRING, customer_id STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.format" = "yyyy-MM-dd", "projection.day.range" = "2021-01-01,NOW", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "projection.customer_id.type" = "injected", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${customer_id}/" ) ``` `injected` 型のパーティションキーを持つテーブルに対してクエリを実行する場合、クエリにそのパーティションキーの値を含める必要があります。`my_ingested_data3` テーブルのクエリは次の例のようになります。 ``` SELECT * FROM my_ingested_data3 WHERE day BETWEEN '2021-11-01' AND '2021-11-30' AND customer_id = 'customer-1234' ``` ## day パーティションキーに DATE タイプを使用する `day` パーティションキーの値は ISO フォーマットされているので、次の例のように、day パーティションキーに、`STRING` ではなく、`DATE` 型を使用することもできます。 ``` PARTITIONED BY (day DATE, customer_id STRING) ``` クエリを実行するとき、この戦略では、次の例のように、解析やキャストを行わずに、パーティションキーで日付関数を使用できます。 ``` SELECT * FROM my_ingested_data3 WHERE day > CURRENT_DATE - INTERVAL '7' DAY AND customer_id = 'customer-1234' ``` **注記** `DATE` 型のパーティションキーを指定するには、[カスタムプレフィックス](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html)機能を使用して ISO 形式の日付を含む Amazon S3 キーを作成したことを前提としています。デフォルトの Firehose 形式、`yyyy/MM/dd/HH` を使用している場合は、以下の例にあるように、対応するテーブルプロパティが `date` 型であっても、パーティションキーを `string` 型として指定する必要があります。 ``` PARTITIONED BY ( `mydate` string) TBLPROPERTIES ( 'projection.enabled'='true', ... 'projection.mydate.type'='date', 'storage.location.template'='s3://amzn-s3-demo-bucket/prefix/${mydate}') ``` # Amazon S3 のスロットリングを防ぐ スロットリングは、サービス、アプリケーション、またはシステムを使用する速度を制限するプロセスです。AWS では、スロットリングを使用して Amazon S3 サービスの過剰使用を防ぎ、すべてのユーザーの Amazon S3 の可用性と応答性を高めることができます。ただし、スロットリングによって Amazon S3 との間でデータを送受信できる速度が制限されるため、インタラクションが制限されるのを防ぐことを検討することが重要です。 [パフォーマンスチューニング](performance-tuning.md)の章で説明したように、最適化は、サービスレベルの決定、テーブルとデータの構造、クエリの記述方法によって異なります。 **Topics** + [サービスレベルでのスロットリングを軽減](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md) + [テーブルを最適化する](performance-tuning-s3-throttling-optimizing-your-tables.md) + [クエリを最適化する](performance-tuning-s3-throttling-optimizing-queries.md) # サービスレベルでのスロットリングを軽減 サービスレベルでの Amazon S3 スロットリングを回避するには、使用状況を監視して [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3) を調整するか、パーティション化などの特定の手法を使用します。スロットリングの原因となる可能性があるいくつかの条件は、以下の通りです。 + **[アカウントの API リクエスト制限の超過]** — Amazon S3 には、アカウントタイプと使用状況に基づくデフォルトの API リクエスト制限があります。1 つのプレフィックスの 1 秒あたりの最大リクエスト数を超えると、Amazon S3 サービスの過負荷を防ぐためにリクエストがスロットリングされることがあります。 + **[データのパーティション分割が不十分]** — データを適切に分割せずに大量のデータを転送すると、Amazon S3 がリクエストを制限する場合があります。パーティション分割の詳細については、このドキュメントの「[パーティション分割を使用する](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning)」セクションを参照してください。 + **[多数の小さいオブジェクト]** — 可能であれば、小さいファイルを多数使用することを避けてください。Amazon S3 には パーティション化されたプレフィックスごとに 1 秒あたり [5,500 件の GET リクエスト](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) という制限があり、Athena のクエリにもこれと同じ制限があります。単一のクエリで何百万もの小さなオブジェクトをスキャンする必要がある場合は、クエリが Amazon S3 によって制限される可能性が高くなります。 過度のスキャンを避けるには、AWS Glue ETL を使用してファイルを定期的に圧縮する、またはテーブルをパーティション化してパーティションキーフィルターを追加します。詳細については、以下のリソースを参照してください。 + [より大きなファイルを出力するように AWS Glue ETL ジョブを設定する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/)(AWS ナレッジセンター) + [大規模なグループでの入力ファイルの読み込み](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) (AWS Glue 開発者ガイド) # テーブルを最適化する スロットリングの問題が発生した場合は、データを構造化することが重要です。Amazon S3 は大量のデータを処理できますが、データの構造が原因でスロットリングが発生することがあります。 以下のセクションでは、スロットリングの問題を回避するために Amazon S3 でデータを構造化するいくつかの方法について提案します。 ## パーティション分割を使用する パーティション分割を使用すると、いつでもアクセスする必要があるデータ量を制限することで、スロットリングを減らすことができます。特定の列のデータをパーティション分割することで、複数のオブジェクトにリクエストを均等に分散し、1 つのオブジェクトに対するリクエスト数を減らすことができます。スキャンする必要のあるデータ量を減らすことは、クエリのパフォーマンスの向上とコストの削減につながります。 テーブルを作成するときに、仮想列として機能するパーティションを定義できます。`CREATE TABLE` ステートメント内にパーティションを含むテーブルを作成するには、`PARTITIONED BY (column_name data_type)` 句を使用してデータを分割するキーを定義します。 クエリによってスキャンされるパーティションを制限するには、クエリの `WHERE` 句にそれらを述語として指定できます。したがって、フィルターとして頻繁に使用される列はパーティション分割に適しています。一般的な方法では、時間間隔に基づいてデータをパーティション化します。これにより、通常、複数レベルのパーティション構成となります。 パーティション分割にはコストもかかることに注意してください。テーブル内のパーティション数を増やすと、パーティションメタデータの取得と処理に必要な時間も長くなります。そのため、パーティション分割が過剰になると、より計画的にパーティション分割を行うことで得られるメリットが得られない可能性があります。データが 1 つのパーティション値に大きく偏っていて、ほとんどのクエリがその値を使用している場合は、追加のオーバーヘッドが発生する可能性があります。 Athena でのパーティション分割の詳細については、「[パーティション化とは](ctas-partitioning-and-bucketing-what-is-partitioning.md)」を参照してください。 ## データのバケット化 データを分割するもう 1 つの方法は、データを 1 つのパーティションにバケット化することです。バケット化するには、グループ化する行を含む 1 つまたは複数の列を指定します。次に、それらの行を複数のバケットに入れます。この方法では、読み取りが必要なバケットのみをクエリできるため、スキャンする必要のあるデータ行の数が減ります。 バケット化に使用する列を選択する際に、カーディナリティが高く (つまり、多数の異なる値があり)、均一に分布していて、データのフィルタリングによく使用する列を選択します。バケット化に適した列の例としては、ID 列などのプライマリキーがあります。 Athena でのバケット化の詳細については、「[バケット化とは](ctas-partitioning-and-bucketing-what-is-bucketing.md)」を参照してください。 ## AWS Glue パーティションインデックスの使用 AWS Glue パーティションインデックスを使用すると、1 つ以上のパーティション値に基づくテーブル内のデータを整理できます。AWS Glue パーティションインデックスを使用すると、データ転送回数、データ処理量、およびクエリの処理時間を削減できます。 AWS Glue パーティションインデックスは、パーティションキーとその値など、テーブル内のパーティションに関する情報を含むメタデータファイルです。パーティションインデックスは Amazon S3 バケットに保存され、新しいパーティションがテーブルに追加されると AWS Glue によって自動的に更新されます。 AWS Glue パーティションインデックスが存在する場合は。クエリでは、テーブル内のすべてのパーティションをロードするのではなく、パーティションのサブセットを取得しようとします。クエリは、クエリに関連するデータのサブセットでのみ実行されます。 AWS Glue でテーブルを作成する際は、テーブルで定義されたパーティションキーの任意の組み合わせに対して、パーティションインデックスを作成できます。テーブルに 1 つ以上のパーティションインデックスを作成したら、パーティションフィルタリングを有効にするプロパティをテーブルに追加する必要があります。その後、Athena からテーブルにクエリを実行できます。 AWS Glue でのパーティションインデックス作成のステップについては、「AWS Glue デベロッパーガイド」の「[AWS Glue でパーティションインデックスを使用する](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html)」を参照してください。テーブルプロパティを追加してパーティションフィルタリングを有効にする方法については、「[AWS Glue パーティションのインデックス作成とフィルタリングでクエリを最適化する](glue-best-practices-partition-index.md)」を参照してください。 ## データ圧縮とファイル分割の使用 ファイルが最適なサイズである場合や、ファイルを論理グループに分割できる場合は、データ圧縮によりクエリを大幅に高速化できます。一般に、圧縮率が高いほど、データを圧縮および解凍するためにより多くの CPU サイクルが必要になります。Athena の場合は、デフォルトでデータを圧縮する Apache Parquet または Apache ORC のいずれかを使用することをお勧めします。Athena でのデータ圧縮の詳細については、「[Athena で圧縮を使用する](compression-formats.md)」を参照してください。 ファイルを分割すると、Athena は 1 つのファイルを読み取るタスクを複数のリーダーに分散できるため、並列処理が向上します。1 つのファイルを分割できない場合、他のリーダーがアイドル状態のときに 1 つのリーダーだけがファイルを読み取ることができます。Apache Parquet と Apache ORC は分割可能なファイルもサポートしています。 ## 最適化された列指向データストアを使用する データを列指向形式に変換すると、Athena クエリのパフォーマンスが大幅に向上します。列指向ファイルを生成する場合、検討すべき最適化手法の 1 つは、パーティションキーに基づいてデータを順序付けることです。 Apache Parquet と Apache ORC は、オープンソースの列指向データストアとしてよく使用されています。既存の Amazon S3 データソースをこれらの形式のいずれかに変換する方法については、「[列形式に変換する](columnar-storage.md#convert-to-columnar)」を参照してください。 ### 大きい Parquet ブロックサイズまたは ORC ストライプサイズの使用 Parquet と ORC には、調整して最適化できるデータストレージパラメータがあります。Parquet では、ブロックサイズを最適化できます。ORC では、ストライプサイズを最適化できます。ブロックまたはストライプが大きいほど、それぞれに保存できる行が多くなります。デフォルトでは、Parquet のブロックサイズは 128 MB で、ORC のストライプサイズは 64 MB です。 ORC ストライプが 8 MB (`hive.orc.max_buffer_size` のデフォルト値) 未満の場合、Athena は ORC ストライプ全体を読み取ります。これは、ストライプが小さい場合に、列の選択性と 1 秒あたりの入出力操作の間で Athena が行うトレードオフです。 列数が非常に多いテーブルがある場合、ブロックまたはストライプのサイズが小さいと、必要以上に多くのデータがスキャンされる可能性があります。このような場合は、ブロックサイズを大きくするほうが効率的です。 ### 複合型で ORC を使用する Parquet に保存されている複雑なデータ型 (例: `array`、`map`、`struct`) の列に対してクエリを実行する場合、現行では、Athena は指定された列のみを選択して読み取るのではなく、データの列全体を読み込みます。これは Athena における既知の問題です。回避策として、ORC の使用を検討してください。 ### 圧縮アルゴリズムの選択 設定できるもう 1 つのパラメータは、データブロックの圧縮アルゴリズムです。Athena において、Parquet と ORC でサポートされている圧縮アルゴリズムについては、「[Athena 圧縮サポート](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)」を参照してください。 Athena での列指向ストレージ形式の最適化の詳細については、AWS ビッグデータのブログ記事「[Amazon Athena のパフォーマンスチューニング Tips トップ 10](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/)」の「列指向データストア生成の最適化」セクションを参照してください。 ## Iceberg テーブル Apache Iceberg は、Amazon S3 で最適に使用できるように設計された、非常に大規模な分析データセット用のオープンテーブル形式です。Iceberg テーブルを使用すると、Amazon S3 のスロットリングを減らすことができます。 Iceberg テーブルには次のような利点があります。 + Iceberg テーブルは、1 つまたは複数の列でパーティション化できます。これにより、データアクセスが最適化され、クエリでスキャンする必要のあるデータ量が減ります。 + Iceberg オブジェクトストレージモードでは Iceberg テーブルが Amazon S3 と連携するように最適化されるため、大量のデータや大量のクエリワークロードを処理できます。 + オブジェクトストレージモードの Iceberg テーブルは、スケーラブルで耐障害性および耐久性があり、スロットリングを減らすのに役立ちます。 + ACID トランザクションがサポートされているため、複数のユーザーがアトミックな方法で Amazon S3 オブジェクトを追加および削除できます。 Apache Iceberg の詳細については、「[Apache Iceberg](https://iceberg.apache.org/)」を参照してください。Athena で Apache Iceberg テーブルを使用する方法については、「[Iceberg テーブルの使用](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html)」を参照してください。 # クエリを最適化する このセクションでは、Athena の SQL クエリを最適化する方法を提案しています。 ## LIMIT に ORDER BY 句を使用する `ORDER BY` 句は、データをソートされた順序で返します。これには、Athena がすべてのデータ行を 1 つのワーカーノードに送信し、行をソートする必要があります。このタイプのクエリは、長時間実行される場合もあれば、失敗する場合もあります。 クエリの効率を上げるには、上位または下位の *N* 個の値を確認してから、`LIMIT` 句も使用してください。これにより、ソートと制限の両方を単一のワーカーノードではなく個々のワーカーノードにプッシュすることで、ソートのコストが大幅に削減されます。 ## JOIN 句の最適化 2 つのテーブルを結合すると、Athena は右側のテーブルをワーカーノードに配布し、左側のテーブルをストリーミングして結合を実行します。 このため、結合の左側には大きいテーブルを指定し、結合の右側に小さいテーブルを指定します。これにより、Athena はメモリの使用量を抑え、クエリの実行待ち時間を短縮できます。 また、以下の点に注意してください。 + 複数の `JOIN` コマンドを使用する場合は、テーブルを最大のものから最小のものまでの範囲で指定してください。 + クエリで必要でない限り、クロス結合は避けてください。 ## GROUP BY 句の最適化 `GROUP BY` オペレータは、`GROUP BY` 列に基づいて行をワーカーノードに分配します。これらの列はメモリ内で参照され、行が取り込まれると値が比較されます。`GROUP BY` 列が一致すると、値はまとめて集計されます。この処理の仕組みを考慮すると、列のカーディナリティが最も高いものから低いものの順に並べることをお勧めします。 ## 文字列の代わりに数値を使用する 数値は文字列に比べてメモリ使用量が少なく、処理も速いため、可能な場合は文字列の代わりに数値を使用してください。 ## 列の数を制限する データを保存するのに必要なメモリの総量を減らすには、`SELECT` ステートメントで指定する列数を制限してください。 ## LIKE の代わりに正規表現を使用する 大規模な文字列に `LIKE '%string%'` 句などを含むクエリを使うと、計算量が非常に多くなる可能性があります。文字列の列で複数の値をフィルタリングする場合は、代わりに [regexp\$1like()](https://trino.io/docs/current/functions/regexp.html#regexp_like) 関数や正規表現を使用します。これは、多数の値リストを比較する場合に特に便利です。 ## LIMIT 句の使用 クエリを実行する際に、すべての列を選択するのではなく、`LIMIT` 句を使用して必要な列のみを返します。これにより、クエリ実行パイプラインで処理されるデータセットのサイズが小さくなります。`LIMIT` 句は、文字列ベースの列数が多いテーブルをクエリする場合に便利です。`LIMIT` 句は、クエリに対して複数の結合や集計を実行するときにも役立ちます。 # 追加リソース Athena でのパフォーマンスチューニングの詳細については、次のリソースを参照してください。 + AWS ビッグデータのブログ記事: [Top 10 performance tuning tips for Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/)。 + AWS ビッグデータのブログ記事: AWS ビッグデータのブログの「[Run queries 3x faster with up to 70% cost savings on the latest Amazon Athena engine](https://aws.amazon.com/blogs/big-data/run-queries-3x-faster-with-up-to-70-cost-savings-on-the-latest-amazon-athena-engine/)」。 + AWS ビッグデータのブログ記事:「[Improve federated queries with predicate pushdown in Amazon Athena](https://aws.amazon.com/blogs/big-data/improve-federated-queries-with-predicate-pushdown-in-amazon-athena/)」。 + Amazon Simple Storage Service ユーザーガイド:「[設計パターンのベストプラクティス: Amazon S3 のパフォーマンスの最適化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)」。 + [AWS ビッグデータブログの Athena に関する他の記事](https://aws.amazon.com/blogs/big-data/tag/amazon-athena/)。 + **Amazon Athena** タグを使用して、[AWS re: Post](https://repost.aws/tags/TA78iVOM7gR62_QqDe2-CmiA/amazon-athena) について質問します。 + [AWS ナレッジセンターの Athena に関するトピック](https://aws.amazon.com/premiumsupport/knowledge-center/#Amazon_Athena)を参照してください。 + 連絡先 AWS サポート (AWS マネジメントコンソール で、[**サポート**]、[**サポートセンター**] の順にクリック) # Athena で圧縮を使用する Athena は、複数の圧縮形式を使用するテーブルからの読み込みなど、データの読み書きのためのさまざまな圧縮形式をサポートしています。例えば、一部の Parquet ファイルが Snappy で圧縮されており、他の Parquet ファイルは GZIP で圧縮されているといった、Parquet ファイル形式を使用するテーブル内のデータも、Athena は正常に読み込むことができます。同様なことが ORC、テキストファイル、および JSON のストレージ形式に対しても当てはまります。 ## サポートされている圧縮形式 Athena は以下の圧縮形式をサポートしています。 + **BZIP2** – Burrows-Wheeler アルゴリズムを使用する形式。 + **DEFLATE** – [LZSS](https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski) および [Huffman コーディング](https://en.wikipedia.org/wiki/Huffman_coding)をベースにした圧縮アルゴリズム。[DEFLATE](https://en.wikipedia.org/wiki/Deflate) が適しているのは Avro ファイル形式のみです。 + **GZIP** – DEFLATE をベースにした圧縮アルゴリズム。Athena エンジンバージョン 2 および 3 の Hive テーブル、および Athena エンジンバージョン 2 の Iceberg テーブルの場合、GZIP は、Parquet およびテキストファイルストレージ形式のファイルのデフォルトの書き込み圧縮形式です。`tar.gz` 形式を使用するファイルはサポートされていません。 + **LZ4** – データの最大圧縮率ではなく、圧縮と解凍速度に焦点を当てた、Lempel-Ziv 77 (LZ7) ファミリーのメンバー。LZ4 には以下のフレーミングフォーマットがあります。 + **LZ4 Raw/Unframed** – LZ4 ブロック圧縮形式のフレームを使用しない標準的な実装。詳細については、GitHub の「[LZ4 Block Format Description](https://github.com/lz4/lz4/blob/dev/doc/lz4_Block_format.md)」(LZ4 ブロック形式の説明) を参照してください。 + **LZ4 Framed** – LZ4 の一般的なフレーミング実装。詳細については、GitHub の「[LZ4 Frame Format Description](https://github.com/lz4/lz4/blob/dev/doc/lz4_Frame_format.md)」(LZ4 フレームフォーマットの説明) を参照してください。 + **LZ4 Hadoop-Compatible** – LZ4 の Apache Hadoop 向け実装。この実装は、LZ4 圧縮を [BlockCompressorStream.java](https://github.com/apache/hadoop/blob/f67237cbe7bc48a1b9088e990800b37529f1db2a/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/compress/BlockCompressorStream.java) クラスでラップします。 + **LZO** – Lempel–Ziv–Oberhumer アルゴリズムを使用する形式。これは、データの最大圧縮率ではなく、圧縮と解凍の高速化に焦点を当てています。LZO には以下の 2 つの実装があります。 + **Standard LZO** – 詳細については、Oberhumer ウェブサイトで LZO の「[abstract](http://www.oberhumer.com/opensource/lzo/#abstract)」(抽象化) を参照してください。 + **LZO Hadoop-Compatible** – LZO アルゴリズムを [BlockCompressorStream.java](https://github.com/apache/hadoop/blob/f67237cbe7bc48a1b9088e990800b37529f1db2a/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/compress/BlockCompressorStream.java) クラスでラップした実装。 + **SNAPPY** – Lempel-Ziv 77 (LZ7) ファミリー内の圧縮アルゴリズムの一部。SNAPPY は、データの最大圧縮率ではなく、圧縮と解凍の高速化に焦点を当てています。 + **ZLIB** – ORC データストレージ形式のファイルで、書き込み圧縮にデフォルトで使用する、DEFLATE をベースにした圧縮形式 詳細については、GitHub の「[zlib](https://github.com/madler/zlib)」ページを参照してください。 + **ZSTD** – [Zstandard real-time data compression algorithm](http://facebook.github.io/zstd/) は、高い圧縮率を実現する高速圧縮アルゴリズムです。Zstandard (ZSTD) ライブラリは、BSD ライセンスにより、オープンソースソフトウェアとして提供されています。ZSTD は Iceberg テーブル用のデフォルトの圧縮です。ZSTD 圧縮データの書き込み時、Athena はディフォルトで ZSTD 圧縮レベル 3 を使用します。Athena での ZSTD 圧縮レベルの使用の詳細については、「[ZSTD 圧縮レベルを使用する](compression-support-zstd-levels.md)」を参照してください。 **注記** Athena は、LZ4 形式または LZO 形式で圧縮された Parquet ファイルの書き込みをサポートしていません。これらの圧縮形式の読み取りはサポートされています。 ## 圧縮形式を指定する CREATE TABLE または CTAS ステートメントを記述する際に圧縮プロパティを指定することで、Athena がこれらのテーブルへの書き込みに使用する圧縮タイプを指定できます。 + CTAS については、「[CTAS テーブルのプロパティ](create-table-as.md#ctas-table-properties)」を参照してください。例については「[CTAS クエリの例](ctas-examples.md)」を参照してください。 + CREATE TABLE については、「[ALTER TABLE SET TBLPROPERTIES](alter-table-set-tblproperties.md)」で圧縮テーブルのプロパティ一覧を参照してください。 ## 圧縮なしを指定する CREATE TABLE 文は、非圧縮ファイルの書き込みをサポートします。非圧縮ファイルを書き込むには、次の構文を使用します。 + CREATE TABLE (テキストファイルまたは JSON) – `TBLPROPERTIES` で、`write.compression = NONE` を指定します。 + CREATE TABLE (Parquet) – `TBLPROPERTIES` で、`parquet.compression = UNCOMPRESSED` を指定します。 + CREATE TABLE (ORC) – `TBLPROPERTIES` で、`orc.compress = NONE` を指定します。 ## 注意事項とリソース + 現在、大文字のファイル拡張子 (`.GZ` または `.BZIP2` など) は、Athena では認識されません。大文字のファイル拡張子を持つデータセットを使用しないようにするか、データファイルの拡張子を小文字に変更します。 + CSV、TSV、および JSON のデータについては、Athena がファイル拡張子から圧縮タイプを判断します。ファイル拡張子がない場合、Athena はデータを非圧縮のプレーンテキストとして扱います。データが圧縮されている場合は、ファイル名に圧縮の拡張子 (`gz` など) が含まれていることを確認します。 + ZIP ファイル形式はサポートされていません。 + Athena からの Amazon Data Firehose ログのクエリでサポートされる形式には、GZIP 圧縮、または SNAPPY 圧縮を使用する ORC ファイルが含まれます。 + 圧縮の使用の詳細については、「AWS Big·Data·ブログ」の記事「[Amazon Athena のパフォーマンスチューニング Tips トップ 10](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/)」のセクション 3「ファイルを圧縮・分割する」 を参照してください。 **Topics** + [圧縮形式を指定する](#compression-support-specifying-compression-formats) + [圧縮なしを指定する](#compression-support-specifying-no-compression) + [注意事項とリソース](#compression-support-notes-and-resources) + [Hive テーブル圧縮](compression-support-hive.md) + [Iceberg テーブル圧縮](compression-support-iceberg.md) + [ZSTD 圧縮レベル](compression-support-zstd-levels.md) # Hive テーブル圧縮を使用する Athena の Hive テーブルの圧縮オプションは、エンジンバージョンとファイル形式によって異なります。 ## Athena エンジンバージョン 3 での Hive 圧縮サポート 次の表に、Apache Hive 内のストレージファイル形式に対して Athena エンジンバージョン 3 でサポートされる、圧縮形式の概要を示します。テキストファイル形式には、TSV、CSV、JSON、およびテキスト用のカスタム SerDes が含まれます。セル内の「はい」または「いいえ」は、特に記載がない限り、読み込みオペレーションと書き込みオペレーションに等しく適用されます。このテーブルでは、CREATE TABLE、CTAS、INSERT INTO は書き込みオペレーションとみなされます。Athena での ZSTD 圧縮レベルの使用の詳細については、「[ZSTD 圧縮レベルを使用する](compression-support-zstd-levels.md)」を参照してください。 **** | | Avro | Ion | ORC | Parquet | テキストファイル | | --- | --- | --- | --- | --- | --- | | BZIP2 | あり | あり | なし | なし | あり | | DEFLATE | はい | なし | なし | なし | いいえ | | GZIP | いいえ | あり | なし | はい | はい | | LZ4 | いいえ | はい | はい | 書き込む - いいえ 読み込む - はい | はい | | LZO | いいえ | 書き込む - いいえ 読み込む - はい | いいえ | 書き込む - いいえ 読み込む - はい | 書き込む - いいえ 読み込む - はい | | SNAPPY | あり | はい | はい | はい | はい | | ZLIB | いいえ | なし | あり | なし | いいえ | | ZSTD | あり | はい | はい | はい | はい | | なし | はい | はい | はい | はい | はい | # Iceberg テーブル圧縮を使用する Athena の Iceberg テーブルの圧縮オプションは、エンジンバージョンとファイル形式によって異なります。 ## Athena エンジンバージョン 3 での Iceberg 圧縮サポート 次の表に、Apache Iceberg 内のストレージファイル形式に対して Athena エンジンバージョン 3 でサポートされる、圧縮形式の概要を示します。セル内の「はい」または「いいえ」は、特に記載がない限り、読み込みオペレーションと書き込みオペレーションに等しく適用されます。このテーブルでは、CREATE TABLE、CTAS、INSERT INTO は書き込みオペレーションとみなされます。Athena エンジンバージョン 3 における Iceberg のデフォルトのストレージ形式は Parquet です。Athena エンジンバージョン 3 における Iceberg のデフォルトの圧縮形式は ZSTD です。Athena での ZSTD 圧縮レベルの使用の詳細については、「[ZSTD 圧縮レベルを使用する](compression-support-zstd-levels.md)」を参照してください。 **** | | Avro | ORC | Parquet (デフォルト) | | --- | --- | --- | --- | | BZIP2 | いいえ | なし | いいえ | | GZIP | はい | なし | あり | | LZ4 | いいえ | あり | なし | | SNAPPY | あり | はい | はい | | ZLIB | いいえ | あり | なし | | ZSTD | あり | はい | はい (デフォルト) | | なし | はい (None または Deflate を指定) | はい | はい (None または Uncompressed を指定) | # ZSTD 圧縮レベルを使用する [Zstandard リアルタイムデータ圧縮アルゴリズム](http://facebook.github.io/zstd/)は、高い圧縮率を実現する高速圧縮アルゴリズムです。Zstandard (ZSTD) ライブラリは、オープンソースソフトウェアであり、BSD ライセンスを使用します。Athena は、ZSTD で圧縮された ORC、Parquet、およびテキストファイルでの、データの読み取りと書き込みをサポートしています。 ZSTD 圧縮レベルを使用すると、要件に応じて圧縮率や速度を調整できます。ZSTD ライブラリは、1 から 22 までの圧縮レベルをサポートします。Athena はデフォルトで ZSTD 圧縮レベル 3 を使用しています。 圧縮レベルは、圧縮速度や達成された圧縮量の間の細かいトレードオフを提供します。圧縮レベルが低くなるほど速度は速くなりますが、ファイルサイズは大きくなります。たとえば、速度が最も重要である場合にはレベル 1 を使用し、サイズが最も重要な場合はレベル 22 を使用できます。レベル 3 は多数のユースケースに適しており、デフォルトです。19 以上のレベルは、より多くのメモリを必要とするため、注意してご使用ください。また、ZSTD ライブラリには、圧縮速度と圧縮率の範囲を広げる負の圧縮レベルも用意されています。詳細については、「[Zstandard Compression RFC](https://datatracker.ietf.org/doc/html/rfc8478)」(Zstandard 圧縮 RFC) を参照してください。 豊富な圧縮レベルにより、大幅に微調整できる機会が増えます。ただし、圧縮レベルを決定する際には、必ずデータを測定し、そのトレードオフを考慮してください。圧縮速度と圧縮データ サイズの間の合理的なトレードオフのためには、デフォルトレベルである 3 または 6～9 の範囲のレベルを使用することをお勧めします。サイズが最も重要で、圧縮速度が問題にならない場合は、レベル 20 以上を確保します。 ## 考慮事項と制限事項 Athena で ZSTD 圧縮レベルを使用する際は、以下の点を考慮してください。 + ZTSD `compression_level` プロパティは、Athena エンジンバージョン 3 でのみサポートされます。 + ZSTD `compression_level` プロパティは、`ALTER TABLE`、`CREATE TABLE`、`CREATE TABLE AS` (CTAS)、および `UNLOAD` ステートメントでサポートされています。 + `compression_level` プロパティはオプションです。 + `compression_level` プロパティは ZSTD 圧縮でのみサポートされます。 + 可能な圧縮レベルは 1～22 です。 + デフォルトの圧縮レベルは 3 です。 Athena での Apache Hive ZSTD 圧縮サポートの詳細については、「[Hive テーブル圧縮を使用する](compression-support-hive.md)」を参照してください。Athena での Apache Iceberg ZSTD 圧縮のサポートに関する詳細については、「[Iceberg テーブル圧縮を使用する](compression-support-iceberg.md)」を参照してください。 ## ZSTD 圧縮レベルを指定する `ALTER TABLE`、`CREATE TABLE`、`CREATE TABLE AS`、および `UNLOAD` ステートメントの ZSTD 圧縮レベルを指定するには、`compression_level` プロパティを使用します。ZSTD 圧縮自体を指定するには、ステートメントの構文が使用する個別の圧縮プロパティを使用する必要があります。 ### ALTER TABLE SET TBLPROPERTIES [ALTER TABLE SET TBLPROPERTIES](alter-table-set-tblproperties.md) ステートメントの `SET TBLPROPERTIES` 句では、`'write.compression' = ' ZSTD'` または `'parquet.compression' = 'ZSTD'` を使用して ZSTD 圧縮を指定します。次に、`compression_level` プロパティを使用して 1 から 22 までの値を指定します (例: `compression_level' = '5'`)。圧縮レベルプロパティを指定しない場合、圧縮レベルはデフォルトで 3 に設定されます。 #### 例 次の例では、テーブル `existing_table` を変更して、ZSTD 圧縮および ZSTD 圧縮レベル 4 の Parquet ファイル形式を使用します。`TBLPROPERTIES` 句では、圧縮レベルの値は整数ではなく文字列として入力する必要があるため、一重引用符または二重引用符で囲む必要があることに留意してください。 ``` ALTER TABLE existing_table SET TBLPROPERTIES ('parquet.compression' = 'ZSTD', 'compression_level' = '4') ``` ### CREATE TABLE [CREATE TABLE](create-table.md) ステートメントの `TBLPROPERTIES` 句では、`write.compression' = 'ZSTD'` または `'parquet.compression' = 'ZSTD'` を指定してから `compression_level = compression_level` を使用して、文字列として 1 から 22 までの値を指定します。`compression_level` プロパティを指定しない場合、デフォルトの圧縮レベルは 3 です。 #### 例 次の例では、ZSTD 圧縮と ZSTD 圧縮レベル 4 を使用して Parquet ファイル形式でテーブルを作成します。 ``` CREATE EXTERNAL TABLE new_table ( `col0` string COMMENT '', `col1` string COMMENT '' ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/' TBLPROPERTIES ('write.compression' = 'ZSTD', 'compression_level' = '4') ``` ### CREATE TABLE AS (CTAS) [CREATE TABLE AS](create-table-as.md) ステートメントの `WITH` 句では、`write_compression = 'ZSTD'` または `parquet_compression = 'ZSTD'` を指定してから `compression_level = compression_level` を使用して、文字列として 1 から 22 までの値を指定します。`compression_level` プロパティを指定しない場合、デフォルトの圧縮レベルは 3 です。 #### 例 次の CTAS の例では、圧縮レベル 4 の ZSTD 圧縮を使用して、Parquet をファイル形式として指定しています。`WITH` 句では、圧縮レベルの値は文字列としてではなく整数として指定する必要があることに留意してください。 ``` CREATE TABLE new_table WITH ( format = 'PARQUET', write_compression = 'ZSTD', compression_level = 4) AS SELECT * FROM old_table ``` ### UNLOAD [UNLOAD](unload.md) ステートメントの `WITH` 句では、`compression = 'ZSTD'` を指定してから `compression_level = compression_level` を使用して、文字列として 1 から 22 までの値を指定します。`compression_level` プロパティを指定しない場合、デフォルトの圧縮レベルは 3 です。 #### 例 次の例では、Parquet ファイル形式、ZSTD 圧縮、および ZSTD 圧縮レベル 4 を使用して、クエリ結果を指定された場所にアンロードします。 ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/' WITH (format = 'PARQUET', compression = 'ZSTD', compression_level = 4) ``` # Athena リソースにタグ付けする タグは、1 つのキーと 1 つの値で構成されており、どちらもお客様側が定義します。Athena リソースにタグを付けるときは、それにカスタムメタデータを割り当てます。タグを使用すると、AWS リソースを目的、所有者、環境などさまざまな方法で分類することができます。Athena では、ワークグループ、データカタログ、キャパシティ予約などのリソースはタグ付け可能なリソースです。たとえば、アカウントにワークグループの一連のタグを作成して、ワークグループの所有者を追跡したり、目的によってワークグループを識別したりできます。また、Billing and Cost Management コンソールでタグをコスト配分タグとして有効にすると、クエリの実行に関連するコストがそのコスト配分タグとともにコストと使用状況レポートに表示されます。AWS [タグ付けのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)を使用して、組織の要件に適合する一連の一貫したタグを作成することをお勧めします。 タグでの作業には、Athena コンソール、または API オペレーションを使用できます。 **Topics** + [タグの基本](#tag-basics) + [タグの制限](#tag-restrictions) + [ワークグループのタグを使用する](tags-console.md) + [API および AWS CLI タグオペレーションを使用する](tags-operations.md) + [タグベースの IAM アクセスコントロールポリシーを使用する](tags-access-control.md) ## タグの基本 タグとは、Athena リソースに割り当てるラベルです。タグはそれぞれ、1 つのキーとオプションの 1 つの値で構成されており、どちらもお客様側が定義します。 タグを使用すると、さまざまな方法で AWS リソースを分類できます。たとえば、各ワークグループの所有者または目的を追跡しやすくするため、アカウントのワークグループに対して一連のタグを定義できます。 新しい Athena ワークグループまたはデータカタログを作成するときにタグを追加する、またはそれらに対してタグを追加、編集、または削除することができます。タグは、コンソールで編集できます。API オペレーションを使用してタグを編集するには、古いタグを削除して新しいタグを追加します。リソースを削除すると、リソースのタグも削除されます。 Athena は、リソースに自動でタグを割り当てません。タグのキーと値は編集でき、タグはリソースからいつでも削除できます。タグの値を空の文字列に設定することはできますが、タグの値を null に設定することはできません。同じリソースに重複したタグキーを追加しないでください。そのようにした場合には、Athena はエラーメッセージを発行します。**TagResource** アクションを使用して、既存のタグキーを使用してリソースにタグを付けると、新しいタグ値によって古い値が上書きされます。 IAM では、Amazon Web Services アカウント内のどのユーザーがタグを作成、編集、削除、またはリストする許可を持つかを制御できます。詳細については、「[タグベースの IAM アクセスコントロールポリシーを使用する](tags-access-control.md)」を参照してください。 Amazon Athena タグアクションの完全なリストについては、「[Amazon Athena API リファレンス](https://docs.aws.amazon.com/athena/latest/APIReference/)」で API アクション名を参照してください。 タグは請求に使用できます。詳細については、「*AWS Billing and Cost Management ユーザーガイド*」の「[請求へのタグの使用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)」を参照してください。 詳細については、「[タグの制限](#tag-restrictions)」を参照してください。 ## タグの制限 タグには、次の制約があります。 + Athena では、ワークグループ、データカタログ、およびキャパシティ予約にタグを付けることができます。クエリにタグを付けることはできません。 + リソースあたりのタグの最大数は 50 です。制限内に収まるようにするには、未使用のタグを確認して削除します。 + タグキーは、リソースごとにそれぞれ一意である必要があります。また、各タグキーに設定できる値は 1 つのみです。同じリソースに重複したタグキーを同時に追加しないでください。そのようにした場合には、Athena はエラーメッセージを発行します。別の `TagResource` アクションで既存のタグキーを使用してリソースにタグを付けると、新しいタグ値によって古い値が上書きされます。 + タグキーの長さは、1～128 文字 (Unicode) (UTF-8) です。 + タグ値の長さは、0～256 文字 (Unicode) (UTF-8) です。 タグの追加、編集、削除、一覧表示などのタグ付けオペレーションでは、ワークグループリソースの ARN を指定する必要があります。 + Athena では、文字、数字、UTF-8 で表現されたスペース、および \$1 - = . \$1 : / @ の文字を使用できます。 + タグのキーと値は大文字と小文字が区別されます。 + タグキーの `"aws:"` プレフィックスは、AWS 用に予約されています。このプレフィックスが含まれるタグキーを編集したり削除することはできません。このプレフィックスを持つタグは、リソースあたりのタグ数の制限時には計算されません。 + 割り当てたタグは、お客様の Amazon Web Services アカウントだけに使用できます。 # ワークグループのタグを使用する Athena コンソールを使用すると、アカウントの各ワークグループでどのタグが使用されているかを確認できます。ワークグループでのみタグを表示できます。また、Athena コンソールを使用して、一度に 1 つのワークグループに対してタグの適用、編集、または削除を行うことができます。 作成したタグを使用してワークグループを検索できます。 **Topics** + [個々のワークグループのタグを表示する](#tags-display) + [個々のワークグループにタグを追加および削除する](#tags-add-delete) ## 個々のワークグループのタグを表示する **Athena コンソールで個々のワークグループのタグを表示するには** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。 ![\[展開メニューを選択します。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/nav-pane-expansion.png) 1. ナビゲーションメニューで、**[Workgroups]** (ワークグループ) 選択し、ワークグループを選択します。 1. 次のいずれかを行います。 + **[タグ]** タブを選択します。タグのリストが長い場合は、検索ボックスを使用します。 + **[Edit]** (編集) を選択し、**[Tags]** (タグ) セクションまで下にスクロールします。 ## 個々のワークグループにタグを追加および削除する [**Workgroups (ワークグループ)**] タブから、個々のワークグループのタグを直接管理できます。 **注記** ユーザーがコンソールでワークグループを作成するときにタグを追加する、または **CreateWorkGroup** アクションを使用するときにタグを渡すことができるようにするには、そのユーザーに **TagResource** アクションと **CreateWorkGroup** アクションへの IAM 許可を付与するようにしてください。 **新しいワークグループを作成する際にタグを追加するには** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. ナビゲーションメニューで、**[Workgroups]** (ワークグループ) を選択します。 1. **[Create workgroup]** (ワークグループを作成する) をクリックして、必要に応じて値を入力します。詳細なステップについては、「[ワークグループの作成](creating-workgroups.md)」を参照してください。 1. **[Tags]** (タグ) セクションで、キーと値を指定して、1 つ以上のタグを追加します。同じワークグループに重複したタグキーを同時に追加しないでください。そのようにした場合には、Athena はエラーメッセージを発行します。詳細については、「[タグの制限](tags.md#tag-restrictions)」を参照してください 1. 終了したら、**[Create workgroup]** (ワークグループを作成する) をクリックします。 **既存のワークグループにタグを追加または編集する** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. ナビゲーションペインで、[**Global networks (グローバルネットワーク)**] を選択します。 1. 変更するワークグループを選択します。 1. 次のいずれかを行います。 + **[タグ]** タブを選択し、**[タグ管理]** を選択します。 + **[Edit]** (編集) を選択し、**[Tags]** (タグ) セクションまで下にスクロールします。 1. タグごとにキーと値を指定します。詳細については、「[タグの制限](tags.md#tag-restrictions)」を参照してください。 1. **[保存]** を選択します。 **個々のワークグループからタグを削除する** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. ナビゲーションペインで、[**Global networks (グローバルネットワーク)**] を選択します。 1. 変更するワークグループを選択します。 1. 次のいずれかを行います。 + **[タグ]** タブを選択し、**[タグ管理]** を選択します。 + **[Edit]** (編集) を選択し、**[Tags]** (タグ) セクションまで下にスクロールします。 1. タグのリストで、削除するタグの **[Remove]** (削除) ボタンをクリックし、**[Save]** (保存) を選択します。 # API および AWS CLI タグオペレーションを使用する 次のタグオペレーションを使用して、リソースのタグを追加、削除、または一覧表示します。 **** | API | CLI | アクションの説明 | | --- | --- | --- | | TagResource | tag-resource | 指定した ARN を持つリソースの 1 つ以上のタグを追加または上書きします。 | | UntagResource | untag-resource | 指定した ARN を持つリソースから 1 つ以上のタグを削除します。 | | ListTagsForResource | list‑tags‑for‑resource | 指定した ARN を持つリソースの 1 つ以上のタグを一覧表示します。 | **リソースを作成する際にタグを追加する** ワークグループまたはデータカタログの作成時にタグを追加するには、`tags` パラメータを `CreateWorkGroup` または `CreateDataCatalog` API オペレーション、あるいは AWS CLI の `create-work-group` または `create-data-catalog` コマンドで使用します。 ## API アクションを使用してタグを管理する 次の例は、タグ API アクションを使用して、ワークグループおよびデータカタログのタグを管理する方法を示しています。例は、Java プログラミング言語で記述されています。 ### 例 – TagResource 次の例では、ワークグループ `workgroupA` に 2 つのタグを追加します。 ``` List tags = new ArrayList<>(); tags.add(new Tag().withKey("tagKey1").withValue("tagValue1")); tags.add(new Tag().withKey("tagKey2").withValue("tagValue2")); TagResourceRequest request = new TagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA") .withTags(tags); client.tagResource(request); ``` 次の例では、データカタログ `datacatalogA` に 2 つのタグを追加します。 ``` List tags = new ArrayList<>(); tags.add(new Tag().withKey("tagKey1").withValue("tagValue1")); tags.add(new Tag().withKey("tagKey2").withValue("tagValue2")); TagResourceRequest request = new TagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA") .withTags(tags); client.tagResource(request); ``` **注記** 同じリソースに重複したタグキーを追加しないでください。そのようにした場合には、Athena はエラーメッセージを発行します。別の `TagResource` アクションで既存のタグキーを使用してリソースにタグを付けると、新しいタグ値によって古い値が上書きされます。 ### 例 – UntagResource 次の例では、ワークグループ `tagKey2` から `workgroupA` を削除します。 ``` List tagKeys = new ArrayList<>(); tagKeys.add("tagKey2"); UntagResourceRequest request = new UntagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA") .withTagKeys(tagKeys); client.untagResource(request); ``` 次の例では、データカタログ `tagKey2` から `datacatalogA` を削除します。 ``` List tagKeys = new ArrayList<>(); tagKeys.add("tagKey2"); UntagResourceRequest request = new UntagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA") .withTagKeys(tagKeys); client.untagResource(request); ``` ### 例 – ListTagsForResource 次の例では、ワークグループ `workgroupA` のタグを一覧表示します。 ``` ListTagsForResourceRequest request = new ListTagsForResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA"); ListTagsForResourceResult result = client.listTagsForResource(request); List resultTags = result.getTags(); ``` 次の例では、データカタログ `datacatalogA` のタグを一覧表示します。 ``` ListTagsForResourceRequest request = new ListTagsForResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA"); ListTagsForResourceResult result = client.listTagsForResource(request); List resultTags = result.getTags(); ``` ## AWS CLI を使用してタグを管理する 次の例では、AWS CLI を使用してデータカタログのタグを作成および管理する方法を示します。 ### リソースにタグを追加する: tag-resource `tag-resource` コマンドは、指定されたリソースに 1 つ以上のタグを追加します。 **構文** `aws athena tag-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name --tags Key=string,Value=string Key=string,Value=string` `--resource-arn` パラメータは、タグを追加するリソースを指定します。`--tags` パラメータは、リソースにタグとして追加するスペース区切りのキーと値のペアのリストを指定します。 **Example** 次の例では、`mydatacatalog` データカタログにタグを追加します。 ``` aws athena tag-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog --tags Key=Color,Value=Orange Key=Time,Value=Now ``` 結果を表示するには、`list-tags-for-resource` コマンドを使用します。 `create-data-catalog` コマンドを使用する際にタグを追加する方法については、「[カタログの登録: Create-data-catalog](datastores-hive-cli.md#datastores-hive-cli-registering-a-catalog)」(カタログを登録する: Create-data-catalog) を参照してください。 ### リソースのタグを一覧表示する: list-tags-for-resource `list-tags-for-resource` コマンドは、指定されたリソースのタグを一覧表示します。 **構文** `aws athena list-tags-for-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name` `--resource-arn` パラメータは、タグを一覧表示するリソースを指定します。 次の例では、`mydatacatalog` データカタログのタグを一覧表示します。 ``` aws athena list-tags-for-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog ``` 次のサンプル結果は JSON 形式です。 ``` { "Tags": [ { "Key": "Time", "Value": "Now" }, { "Key": "Color", "Value": "Orange" } ] } ``` ### リソースからタグを削除する: untag-resource `untag-resource` コマンドは、指定されたタグキーとその関連値を、指定されたリソースから削除します。 **構文** `aws athena untag-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name --tag-keys key_name [key_name ...]` `--resource-arn` パラメータは、タグを削除するリソースを指定します。`--tag-keys` パラメータは、キー名のスペース区切りリストを取ります。`untag-resource` コマンドは、指定されたキー名ごとに、キーとその値の両方を削除します。 次の例では、`Color` カタログリソースから `Time` および `mydatacatalog` キーとそれぞれの値を削除します。 ``` aws athena untag-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog --tag-keys Color Time ``` # タグベースの IAM アクセスコントロールポリシーを使用する タグがあると、リソースのタグに基づいてそのリソースへのアクセスを制御する `Condition` ブロックが含まれた IAM ポリシーを作成できます。このセクションでは、ワークグループとデータカタログリソースのタグポリシーの例を示します。 ## ワークグループのタグポリシーの例 ### 例 - 基本的なタグ付けポリシー 以下の IAM ポリシーは、`workgroupA` という名前のワークグループのタグでクエリを実行し、それらとやり取りすることを可能にします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListWorkGroups", "athena:ListEngineVersions", "athena:ListDataCatalogs", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "athena:GetWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery", "athena:CreatePreparedStatement", "athena:GetPreparedStatement", "athena:ListPreparedStatements", "athena:UpdatePreparedStatement", "athena:DeletePreparedStatement" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA" } ] } ``` ------ ### 例 – タグキーとタグ値のペアに基づいてワークグループに対するアクションを拒否するポリシーブロック ワークグループなどのリソースに関連付けられたタグは、リソースタグと呼ばれます。リソースタグを使用すると、`stack`、`production` などのキーと値のペアでタグ付けされたワークグループに対してリストされているアクションを拒否する、次のようなポリシーブロックを作成できます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "athena:GetWorkGroup", "athena:UpdateWorkGroup", "athena:DeleteWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery", "athena:CreatePreparedStatement", "athena:GetPreparedStatement", "athena:ListPreparedStatements", "athena:UpdatePreparedStatement", "athena:DeletePreparedStatement" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/*", "Condition": { "StringEquals": { "aws:ResourceTag/stack": "production" } } } ] } ``` ------ ### 例 – タグ変更アクションリクエストを指定されたタグに制限するポリシーブロック タグを変更するオペレーション (`TagResource`、`UntagResource`、タグを指定した `CreateWorkGroup` など) にパラメータとして渡されるタグは、リクエストタグと呼ばれます。次のポリシーブロックの例では、渡されたタグのいずれかがキー `CreateWorkGroup` と値 `costcenter`、`1`、または `2` を持つ場合にのみ、`3` オペレーションを許可します。 **注記** `CreateWorkGroup` オペレーションの一環としてタグを渡すことを IAM ロールに許可する場合は、そのロールに `TagResource` アクションと `CreateWorkGroup` アクションへの許可を付与するようにしてください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:CreateWorkGroup", "athena:TagResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/*", "Condition": { "StringEquals": { "aws:RequestTag/costcenter": [ "1", "2", "3" ] } } } ] } ``` ------ ## データカタログのタグポリシーの例 ### 例 - 基本的なタグ付けポリシー 以下の IAM ポリシーは、`datacatalogA` という名前のデータカタログのタグとやり取りを可能にします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListWorkGroups", "athena:ListEngineVersions", "athena:ListDataCatalogs", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "athena:GetWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery" ], "Resource": [ "arn:aws:athena:us-east-1:123456789012:workgroup/*" ] }, { "Effect": "Allow", "Action": [ "athena:CreateDataCatalog", "athena:GetDataCatalog", "athena:UpdateDataCatalog", "athena:DeleteDataCatalog", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA" } ] } ``` ------ ### 例 – タグキーとタグ値のペアに基づいてデータカタログに対するアクションを拒否するポリシーブロック リソースタグを使用すると、特定のタグのキーと値のペアでタグ付けされたデータカタログに対して特定のアクションを拒否するポリシーブロックを作成できます。次のポリシーの例では、タグのキーと値のペア `stack`、`production` を持つデータカタログに対するアクションを拒否します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "athena:CreateDataCatalog", "athena:GetDataCatalog", "athena:UpdateDataCatalog", "athena:DeleteDataCatalog", "athena:GetDatabase", "athena:ListDatabases", "athena:GetTableMetadata", "athena:ListTableMetadata", "athena:StartQueryExecution", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/*", "Condition": { "StringEquals": { "aws:ResourceTag/stack": "production" } } } ] } ``` ------ ### 例 – タグ変更アクションリクエストを指定されたタグに制限するポリシーブロック タグを変更するオペレーション (`TagResource`、`UntagResource`、タグを指定した `CreateDataCatalog` など) にパラメータとして渡されるタグは、リクエストタグと呼ばれます。次のポリシーブロックの例では、渡されたタグのいずれかがキー `CreateDataCatalog` と値 `costcenter`、`1`、または `2` を持つ場合にのみ、`3` オペレーションを許可します。 **注記** `CreateDataCatalog` オペレーションの一環としてタグを渡すことを IAM ロールに許可する場合は、そのロールに `TagResource` アクションと `CreateDataCatalog` アクションへの許可を付与するようにしてください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:CreateDataCatalog", "athena:TagResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/*", "Condition": { "StringEquals": { "aws:RequestTag/costcenter": [ "1", "2", "3" ] } } } ] } ``` ------ # サービスクォータ **注記** Service Quotas コンソールには、Amazon Athena のクォータに関する情報が提供されています。Service Quotas コンソールを使用して、調整可能なクォータに関して[クォータの増加をリクエスト](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas)することもできます。スキーマの制限に関する AWS Glue の詳細は、「[AWS Glue エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/glue.html)」のページを参照してください。AWS サービスクォータの概要については、「AWS 全般のリファレンス」の「[AWS サービスクォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照してください。 ## クエリ アカウントには、Amazon Athena のクエリに関し以下のクォータが設定されています。詳細については、AWS 全般のリファレンス の「[Amazon Athena エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/athena.html#amazon-athena-limits)」ページを参照してください。 + **アクティブな DDL クエリ** – アクティブな DDL クエリの数。DDL クエリには、`CREATE TABLE` クエリと `ALTER TABLE ADD PARTITION` クエリが含まれます。 + **DDL クエリのタイムアウト** – DDL クエリが、キャンセルされずに実行可能な最大時間 (分単位)。 + **アクティブな DML クエリ** – アクティブな DML クエリの数。DML クエリには、`SELECT`、`CREATE TABLE AS` (CTAS)、および `INSERT INTO` クエリが含まれます。特定のクォータは、AWS リージョンによって変化します。 + **DML クエリのタイムアウト** – DML クエリが、キャンセルされずに実行可能な最大時間 (分単位) このタイムアウトは、最大 240 分まで延長するようリクエストできます。 クォータの引き上げをリクエストするには、[Athena Service Quotas](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas) コンソールを使用できます。 Athena は、全体的なサービス負荷と受信するリクエストの数に基づいてリソースを割り当てることによって、クエリを処理します。クエリは、一時的にキューに登録されてから実行される場合があります。アカウント設定によって許可されている場合に限り、非同期プロセスが物理リソースが使用可能になり次第キューからクエリを取り出して、それらを物理リソース上で実行します。 アクティブな DML クエリとアクティブな DDL クエリのクォータには、実行中のクエリとキューに入れられたクエリの両方が含まれます。例えば、アクティブな DML クエリのクォータが 25 で、実行中のクエリとキューに登録されたクエリの合計が 26 になった場合、26 番目のクエリは TooManyRequestsException エラーを引き起こします。 **注記** Athena で実行するクエリに対して同時実行を直接制御したい場合は、キャパシティ予約を使用できます。詳細については、「[クエリ処理キャパシティを管理する](capacity-management.md)」を参照してください。 ### クエリ文字列の長さ 許容される最大クエリ文字列の長さは、262144 バイトです。文字列は UTF-8 でエンコードされます。これは調整可能なクォータではありません。ただし、長いクエリを複数の小さなクエリに分割することで、この制限を回避することができます。詳細については、AWS ナレッジセンターの「[Athena でクエリ文字列の最大長を増やすにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/athena-query-string-length/)」を参照してください。 ## ワークグループ Athena ワークグループを使用する場合は、以下の点に注意してください。 + Athena のサービスクォータは、アカウント内のすべてのワークグループで共有されます。 + アカウントでリージョンごとに作成できるワークグループの最大数は 1000 です。 + ワークグループ内の準備済みステートメントの最大数は 1,000 です。 + ワークグループあたりのタグの最大数は 50 です。詳細については、「[タグの制限](tags.md#tag-restrictions)」を参照してください。 ## データベース、テーブル、パーティション Athena は AWS Glue Data Catalog を使用します。テーブル、データベース、およびパーティションのサービスクォータ (アカウントあたりのデータベースまたはテーブルの最大数など) については、「[AWS Glue エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/glue.html)」を参照してください。Athena では、1,000 万のパーティションを持つ AWS Glue テーブルへのクエリがサポートされていますが、1 回のスキャンで読み取れるのは、100 万のパーティションまでであることに留意してください。 ## Amazon S3 バケット Amazon S3 バケットを使用する場合は、以下の点に注意してください。 + Amazon S3 には、アカウントあたり 10,000 バケットのデフォルトサービスクォータがあります。 + Athena では、結果をログするための個別のバケットが必要です。 + AWS アカウントごとに Amazon S3 バケットのクォータ引き上げを最大 100 万個までリクエストできます。 ## アカウントあたりの API コールのクォータ Athena API では、(クエリあたりではなく) アカウントあたりの API へのコール数にデフォルトクォータがあります。デフォルトのクォータの完全なリストについては、 AWS 全般のリファレンス ガイドの「[Service Quotas](https://docs.aws.amazon.com/general/latest/gr/athena.html#amazon-athena-limits)」の表を参照してください。 これらの API のいずれかを使用しており、1 秒あたりのコール数のデフォルトクォータ、またはアカウントのバーストキャパシティを超過した場合、Athena API は「ClientError: An error occurred (ThrottlingException) when calling the ** operation: Rate exceeded.」に類似したエラーを発行します。1 秒あたりの呼び出し数、またはこのアカウントの API のバーストキャパシティーを減らしてください。 アカウント API コールごとの Athena クォータは、[Athena Service Quotas コンソール](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas)で変更できます。