翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Trino Trino は、幅広いデータソースでのインタラクティブなクエリ用に設計されたオープンソースのクエリエンジンです。これには、リレーショナルデータベース、ファイルベースのデータ、HDFS データなどが含まれます。Amazon EMR を使用した Trino の最も一般的な目的は、Amazon S3 に保存されている大規模なデータセットに対して複雑な SQL クエリを実行することです。また、ANSI SQL に準拠しているため、SQL に精通しているデータベースエンジニア、データアナリスト、データサイエンティストが使い慣れています。 **注記** 2020 年 12 月に、PrestoSQL は Trino に名前変更されました。Amazon EMR バージョン 6.4.0 以降は一般的に [Trino](https://trino.io/) を参照し、以前のリリースバージョンは PrestoSQL を参照します。 **重要** Trino の以前のバージョンである PrestoSQL は、Amazon EMR で引き続き使用できます。ただし今後は、Amazon EMR で Trino を使用することを強くお勧めします。また、Trino と PrestoSQL を同じクラスターで同時に実行できません。 次の表は、Amazon EMR 7.x の最新リリースに含まれている Trino のバージョンと、Amazon EMR で Trino と共にインストールされるコンポーネントを示しています。このリリースで Trino と共にインストールされるコンポーネントのバージョンについては、[「リリース 7.12.0 コンポーネントバージョン](emr-7120-release.md)」を参照してください。 **emr-7.12.0 の Trino (PrestoSQL) バージョン情報** | Amazon EMR リリースラベル | Trino (PrestoSQL) バージョン | Trino (PrestoSQL) でインストールされるコンポーネント | | --- | --- | --- | | emr-7.12.0 | trino-prestosql 476-amzn-1 | emrfs, emr-goodies, hadoop-client, hadoop-hdfs-datanode, hadoop-hdfs-library, hadoop-hdfs-namenode, hadoop-hdfs-zkfc, hadoop-kms-server, hadoop-yarn-nodemanager, hadoop-yarn-resourcemanager, hadoop-yarn-timeline-server, hive-client, hudi, hudi-trino, hcatalog-server, mariadb-server, trino-coordinator, trino-worker | **Topics** + [Trino の履歴と設計](emr-trino-intro-history.md) + [Trino の使用開始](emr-trino-getting-started.md) + [Amazon EMR での Trino の設定](emr-trino-config.md) + [Amazon EMR の Trino ベストプラクティス](emr-trino-advanced.md) + [Trino に関する考慮事項](Trino-considerations.md) + [Trino リリース履歴](Trino-release-history.md) # Trino の履歴と設計 Trino は、さまざまなソースからの大規模なデータセットのクエリに特化しています。Trino は、従来のビッグデータユースケースで HDFS にアクセスしてクエリを実行できますが、リレーショナルデータベースや NoSQL データベースなどの追加のソースをクエリすることもできます。Trino は、2019 年に Presto クエリエンジンのフォークとして開始されました。それ以来、Presto コードベースとは独立して開発されています。 Trino クエリエンジンとその使用方法の詳細については、[Trino ウェブサイト](https://trino.io/)を参照してください。Trino のソースドキュメントを読むには、「[Trino Overview](https://trino.io/docs/current/overview.html)」を参照してください。 ## アーキテクチャの概念 Trino はクラスター全体でデータを並行して処理するため、迅速かつ効率的なクエリを実行できます。これは、データレイクのクエリを念頭に置いて設計されています。これは、通常、Hadoop と HDFS を含むユースケースにおける、大規模なデータボリュームに対するクエリに特化しているためです。ただし、従来のリレーショナルデータベースをクエリすることもできます。詳細については、「*Trino Documentation*」の「[Architecture](https://trino.io/docs/current/overview/concepts.html#architecture)」を参照してください。 ### Trino のコンポーネント Trino には、クエリの実行を高速化するために連携する主要なアーキテクチャコンポーネントがいくつかあります。パフォーマンスを向上させるためにクラスターを微調整することにより、これらに関する実用的な知識が得られます: + **コーディネーター**はクエリオーケストレーションを担当します。受信 SQL クエリの解析と最適化、実行計画の生成、ワーカーノードへのタスクの割り当て、クエリ結果の収集とアセンブルを行います。さらに、リソースの使用状況を監視し、ワーカーノードのステータスを追跡します。詳細については、「*Trino documentation*」の「[Coordinator](https://trino.io/docs/current/overview/concepts.html#coordinator)」を参照してください。 + **ワーカーノード**はクエリに対するデータ処理を担当します。コーディネーターがタスクを割り当てると、ワーカーはデータを取得し、結合や集計などの必要な操作を実行し、中間データを他のワーカーと交換します。詳細については、「*Trino documentation*」の「[Worker](https://trino.io/docs/current/overview/concepts.html#worker)」を参照してください。 + **コネクタ**は、Trino がさまざまなデータソースに接続してクエリできるようにするプラグインです。各コネクタは、Amazon S3、Apache Hive、リレーショナルデータベースなど、ソースからデータにアクセスして取得する方法を知っています。これらのコネクタは、ソースデータを Trino のスキーマ構造にマッピングします。 + **カタログ**は、特定のコネクタに関連付けられたスキーマとテーブルの論理コレクションです。コーディネーターで定義されるカタログにより、Trino はさまざまなデータソースを単一の名前空間として扱うことができます。これにより、ユーザーは同じクエリで統合された方法で Hive や MySQL などの複数のソースを一緒にクエリできます。 + Trino CLI などの**クライアント**は、JDBC および ODBC ドライバーを使用して Trino コーディネーターに接続し、SQL クエリを送信します。コーディネーターはクエリのライフサイクルを管理し、さらなる分析やレポート作成のために結果をクライアントに提供します。 ### クエリの実行 Trino が SQL ステートメントを受け取り、クエリとして実行する方法については、「*Trino Documentation*」の「[Trino concepts](https://trino.io/docs/current/overview/concepts.html#query-execution-model)」を参照してください。 # Trino の使用開始 このセクションの手順では、Trino を使用してメタストアデータソースをクエリするために Amazon EMR クラスターをセットアップする方法を示します。 AWS Glue データカタログを含むこれらのメタストアは、メタデータとデータベースオブジェクトを保存し、アクセス許可を管理します。この手順では、前提条件、推奨構成設定、コネクタの作成、メタストアテーブルでのクエリの実行について説明します。 **Topics** + [Trino で Amazon EMR を使用するための前提条件ステップを完了する](emr-trino-getting-started-pre.md) + [Trino での Amazon EMR クラスターを起動する](emr-trino-getting-started-launch.md) + [Amazon EMR クラスターのプライマリノードに接続してクエリを実行する](emr-trino-getting-started-connect.md) # Trino で Amazon EMR を使用するための前提条件ステップを完了する を使用していない場合 AWS、または Amazon EMR クラスターを作成していない場合は、Trino で Amazon EMR クラスターを作成する前に、以下の前提条件ステップを完了してください。 ## AWS 環境のセットアップ まだ AWS アカウントを設定していない場合は、以下の手順を実行します。 1. AWS アカウントをまだお持ちでない場合は、サインアップしてください。詳細については、[「 AWS アカウント管理リファレンスガイド」の「アカウントの作成](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html)」を参照してください。 *AWS * 1. 管理者としてご自身のアカウントにサインインします。 1. グループを作成し、ユーザーを割り当てます。 1. Amazon EC2 キーペアを作成します。これは後で SSH を使用してリソース間の通信を保護するために使用できます。このステップは、プライマリノードに接続してタスクを実行する場合に必要です。詳細については、「[Connect to the Amazon EMR cluster primary node using SSH](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html)」を参照してください。 # Trino での Amazon EMR クラスターを起動する Trino でクラスターを作成する際の正しい設定選択肢を以下に示します。 ## Hive コネクタを使用してデータをクエリ可能にする クラスターからメタストアデータをクエリする目的で、Hive メタストアの Trino コネクタを設定できます。メタストアは、ファイルベースのコンテンツまたはデータをテーブルとして利用できる抽象化レイヤーであるので、クエリが容易です。Hive メタストアテーブルをクラスターで使用できるように、Amazon EMR でコネクタを設定しなければなりません。以下の手順は、その方法を示しています: 1. コンソールで AWS Glue を選択し、Amazon S3 のソースデータに基づいてテーブルを作成します。 AWS Glue データカタログのテーブルは、データのメタデータ定義です。このコンテキストでは、ソースデータからテーブルを手動で作成し、必要に応じて列を作成するのが理にかなっています。Amazon S3 の半構造化データから AWS Glue でテーブルを作成する方法の詳細については、*AWS 「 Glue ユーザーガイド*」の[「コンソールを使用したテーブルの作成](https://docs.aws.amazon.com/glue/latest/dg/tables-described.html#console-tables)」を参照してください。 1. クラスター作成の一部として設定を行います。**[設定]** タブを選択します。設定は、クラスターのオプション仕様です。設定を入力するときは、次のサンプルのような JSON を追加します。このサンプルは、テーブルメタデータの外部 Hive メタストアとして AWS Glue データカタログを使用するように Trino に指示します。 ``` { "classification": "trino-connector-hive", "properties": { "hive.metastore": "glue" } } ``` または、クラスターの作成時に **[ソフトウェア設定]** セクションで設定を適用することもできます。 さらに、Apache Iceberg との接続など、他のコネクタタイプを設定することもできます。詳細については、「*Amazon EMR リリースガイド*」の「[Trino で Iceberg クラスターを使用する](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-iceberg-use-trino-cluster.html)」を参照してください。追加の設定はオプションです。 開始手順を続けるには、「[Amazon EMR クラスターのプライマリノードに接続してクエリを実行する](emr-trino-getting-started-connect.md)」を参照してください。 ## Trino を使用してクラスターを作成する 以下は、Trinoで使用するクラスターを作成する際の正しい構成オプションについて説明します。 **重要** クラスターを作成する前に、Hive メタストアとして AWS Glue データカタログ設定を完了してください。開始するには、この設定をお勧めします。詳細については、「[Hive コネクタを使用してデータをクエリ可能にする](#emr-trino-getting-started-connect-hive)」を参照してください。 1. AWS コンソールで、 サービスから Amazon EMR を選択します。Amazon EMR を選択することにより、既存のクラスターがある場合、**[EC2 クラスター上の EMR]** が一覧表示されます。 1. **[クラスターを作成]** を選択します。ここから、クラスターを構築するプロセスを開始します。 1. クラスターに名前を付け、**[Amazon EMR リリース]** を選択します。チュートリアルの最新のリリースを選択できます。 1. **[Trino]** バンドルを選択します。このバンドルには Trino アプリケーションが事前に選択されています。バンドルは、クラスターの目的が事前にわかっている場合に便利です。それ以外の場合は、Trino のチェックボックスをオンにするだけです。 1. **[クラスターの設定]** で **[Uniform インスタンスグループ]** を選択します。追加のインスタンスグループを削除してください。 1. **[インスタンスタイプ]** を選択します。一般的に、メモリが 16 GiB 以上のインスタンスタイプを選択することをお勧めします。また、**[クラスターのスケーリングとプロビジョニング]** では、**[クラスターサイズを手動で設定]** を選択します。 1. この時点で、Hive メタストア設定を AWS Glue を指すように設定します。詳細については、「[Hive コネクタを使用してデータをクエリ可能にする](#emr-trino-getting-started-connect-hive)」セクションを参照してください。クラスターを構築する前に、これを完了してください。 1. **[クラスターを作成]** を選択します。これには数分かかることがあります。 ここでのステップでは、すべての設定ステップについて詳しく説明しているわけではありません。クラスターの設定の詳細については、「[Plan, configure and launch Amazon EMR clusters](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan.html)」を参照してください。 **注記** 同じクラスターで使用する Presto と Trino の両方を選択しないでください。これらを一緒に実行することはサポートされていません。Trino を実行する場合は、Spark など、クラスター上で他のアプリケーションを実行しないことをお勧めします。 # Amazon EMR クラスターのプライマリノードに接続してクエリを実行する ## テストデータのプロビジョニングとアクセス許可の設定 Glue Data Catalog とその Hive メタストアを使用して、Trino AWS で Amazon EMR をテストできます。これらの前提条件ステップでは、テストデータを設定していない場合の設定方法について説明します: 1. 通信暗号化に使用する SSH キーをまだ作成していない場合は、作成します。 1. 複数のファイルシステムから選択して、データとログファイルを保存できます。開始するには、Amazon S3 バケットを作成します。バケットに一意の名前を付けます。作成時に、作成した暗号化キーを指定します。 **注記** 同じリージョンを選択して、ストレージバケットと Amazon EMR クラスターの両方を作成します。 1. 作成したバケットを選択します。**[フォルダを作成]** を選択し、フォルダに記憶に残る名前を付けます。フォルダを作成するときは、セキュリティ設定を選択します。親のセキュリティ設定を選択するか、セキュリティ設定をより専門にすることができます。 1. テストデータを フォルダに追加します。このチュートリアルでは、カンマ区切りレコードの .csv を使用することにより、このユースケースを完了するのに適しています。 1. Amazon S3 バケットにデータを追加したら、データをクエリするための抽象化レイヤーを提供するように AWS Glue でテーブルを設定します。 ## クエリを接続し実行する 以下に、Trino を実行しているクラスターに接続してクエリを実行する方法について説明します。これを行う前に、前の手順で説明した Hive メタストアコネクタを設定し、メタストアテーブルが表示されるようにしてください。 1. EC2 Instance Connect は安全な接続を提供するため、クラスターへの接続には EC2 Instance Connect を使用することをお勧めします。クラスターの概要から **[SSH を使用してプライマリノードに接続]** を選択します。接続では、セキュリティグループに、サブネット内のクライアントへのポート 22 経由の接続を許可するインバウンドルールが必要です。また、接続時にユーザー **[hadoop]** を使用する必要があります。 1. `trino-cli` を実行して Trino CLI を起動します。これにより、Trino でコマンドを実行し、データをクエリできます。 1. `show catalogs;` を実行します。**Hive** カタログが一覧表示されていることを確認します。これにより、データストアまたはシステム設定を含む利用可能なカタログのリストが提供されます。 1. 使用可能なスキーマを表示するには、`show schemas in hive;` を実行します。ここから、`use schema-name;` を実行し、スキーマの名前を含めることができます。その後、`show tables;` を実行してテーブルを一覧表示できます。 1. スキーマ内のテーブルの名前を使用して、`SELECT * FROM table-name` などのコマンドを実行してテーブルをクエリします。`USE` ステートメントを実行して特定のスキーマに接続している場合は、*schema*.*table* などの 2 つの部分からなる表記を使用する必要はありません。 # Amazon EMR での Trino の設定 **Topics** + [Trino のコネクタの設定](#emr-trino-config-connector) + [モニタリング](#emr-trino-monitoring) ## Trino のコネクタの設定 ### Hive メタストアとして AWS Glue に接続する Trino でクエリを実行するときは、 Glue Data Catalog AWS を Hive メタストアとして設定できることを理解することが重要です。Hive メタストアでクラスターを設定する手順などの詳細については、[「Hive のメタストアとして AWS Glue データカタログを使用する](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html)」を参照してください。 EMR on EKS と Glue AWS の統合については、以下のベストプラクティス[「EMR Containers integration with AWS Glue](https://aws.github.io/aws-emr-containers-best-practices/metastore-integrations/docs/aws-glue/)」を参照してください。 ### Amazon EMR で Trino を使用する場合の Iceberg テーブルへの接続 Iceberg は、分析テーブル用のオープンテーブル形式です。これは、Spark や Trino などのエンジンが SQL クエリを使用して同じテーブルからビッグデータをクエリするために作成されました。これには、データの読み取りと書き込みの分離などの機能が含まれているため、リーダーは部分的に更新されたデータのクエリを回避できます。また、スナップショットなどの状態機能もサポートしています。メタデータとマニフェストファイルを使用して抽象化レイヤーを提供します。これらはテーブルスキーマを記述し、データのフォーマットや整理方法の詳細を多く知ることなく、データのクエリを容易にします。接続することにより、テーブルからデータを読み取ることも、基になるファイルに新しいデータを書き込むこともできます。 Amazon EMR と Glue で Iceberg AWS テーブルを設定する方法を示すワークショップがあります。詳細については、「[ Analytics Workshop - Set Up and Use Apache Iceberg Tables on Your Data Lake](https://youtu.be/SZDYmWIStUo?si=sW35AjSWIcHu5x_p)」を参照してください。 ### クライアントとの接続 使用可能な JDBC ドライバーを使用して Trino に接続できます。詳細については、「*Trino Documentation*」の「[JDBC driver](https://trino.io/docs/current/client/jdbc.html)」を参照してください。 ## モニタリング を使用して Amazon EMR クラスターをモニタリングできます AWS マネジメントコンソール。詳細については、「[View and monitor an Amazon EMR cluster as it performs work](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-view.html)」を参照してください。Amazon EMR は、モニタリングメトリクスも Amazon CloudWatchに送信します。Amazon EMR クラスターのモニタリングの詳細については、「[Amazon CloudWatch events and metrics from Amazon EMR]()」を参照してください。 # Amazon EMR の Trino ベストプラクティス Trino のアーキテクチャは、コーディネーターワーカーモデルに従って、複数のデータソースにまたがる大規模なデータセットに対して高速で分散された SQL クエリを実行するように設計されています。コーディネーターワーカーモデルでは、各コンポーネントにクエリ実行における特殊な役割があります。Trino を実行している Amazon EMR クラスターを最高のパフォーマンスのために設定するために、いくつかの領域またはカテゴリに集中できます。これには以下が含まれます。 + メモリ最適化のためのクラスター構成設定の調整。 + データパーティショニングとデータ分散の設定を最適化します。 + 動的フィルタリングを使用してクエリ結果の数を減らします。 これらの設定の一部は、Amazon EMR で Trino を使用すると自動的に調整されます。その他は、コンソールまたは CLI コマンドを使用して手動で設定できます。このセクションのトピックは、データとクラスターを最適に設定するのに役立ちます。 **Topics** + [パフォーマンス向上の主な重点分野](emr-trino-performance-areas.md) + [テーブル統計を収集して使用する](emr-trino-performance-areas-collect-stats.md) + [Trino ワークロードをスケーリングする際の一般的な課題](emr-trino-common-issues.md) # パフォーマンス向上の主な重点分野 Trino は、クエリの並列性とメモリの最適化を最大化します。このアーキテクチャは、効率的にスケーリングしながら、複数のさまざまなデータソースをクエリできるようにすることで、柔軟性を提供します。Trino のパフォーマンス向上の主な分野には、以下が含まれます。 ## メモリの最適化 Trino でのメモリ管理は、特に大規模で複雑なクエリを実行する場合に、高パフォーマンスと安定性を達成するために不可欠です。Trino は分散メモリモデルを使用します。このモデルでは、タスク、集約、結合、およびその他のオペレーションを処理するために、ワーカーノード間でメモリが割り当てられます。以下のリストでは、これらの設定のコレクションを紹介します: + **query.max-memory** – クラスター全体で 1 つのクエリに使用できる最大メモリを設定します。これはハード制限です。クエリがこのメモリを超えると失敗します。 + **query.max-memory-per-node** – クエリが各ワーカーノードで消費できる最大メモリを定義します。これを設定することにより、単一のクエリがワーカーのリソースを独占することはありません。 + **JVM ヒープサイズ** – JVM レベルで設定され、各ノードの Trino サーバープロセスの最大ヒープサイズを設定します。この値は、通常、JVM レベルでシステムがメモリ不足にならないように、Trino のメモリ関連の設定 (**max-memory-per-node** と **memory.heap-headroom-per-node** の合計) よりも大きくする必要があります。 + **memory.heap-headroom-per-node** – 非クエリオペレーションのために JVM ヒープサイズから残すメモリのバッファ量を指定します。これは、内部オペレーションとガベージコレクションに十分なオーバーヘッドを確保するために不可欠です。 ## 動的フィルタリング Trino の動的フィルタリングは、特に結合中に処理されるデータ量を減らすことでクエリのパフォーマンスを向上させる最適化手法です。フィルタ条件を動的に適用して、結合の一方の側でスキャンされたデータを、もう一方の側で見られるデータに基づいて制限します。これは、結合の一方の側が非常に選択的である (つまり、データの小さなサブセットを含む) クエリで特に便利です。Amazon EMR ではデフォルトで有効になっています。以下はクエリの例です。 ``` SELECT orders.order_id, orders.total_amount FROM orders JOIN customers ON orders.customer_id = customers.customer_id WHERE customers.country = 'France'; ``` 動的フィルタリングがない場合、Trino は、少数の顧客 (フランスからの顧客) のサブセットのみが関連している場合でも、結合で注文テーブル全体をスキャンします。このアプローチは、**注文**テーブルのすべての行を読み取るため、I/O と処理コストが高くなります。動的フィルタリングでは、Trino は最初に小さな**顧客**テーブルをスキャンし、フランスから顧客のみの customer\$1id 値を取得し、このサブセットを注文のフィルターとして適用します。つまり、フィルタリングされたサブセットに一致する customer\$1id を持つ**注文**の関連する行のみがスキャンされ、処理されるレコードが大幅に削減されます。 ## スピルからディスクへ Trino では、ディスクのスピルにより、中間クエリ結果をディスクにオフロードできるので、メモリを大量に消費するクエリは、`query_max_memory` または `query_max_memory_per_node` によって設定されたメモリ制限を超えた場合でも完了できます。デフォルトでは、Trino はこれらの制限を適用して、公平なメモリ割り当てを確保し、クラスターのデッドロックを防ぎます。ただし、大きなクエリがこれらの制限を超えると、終了のリスクがあります。ディスクのスピリングでは、`revocable memory` を使用してこれに対処します。これにより、リソースが他の場所で必要になった場合に取り消すことができる追加のメモリをクエリで借用できます。メモリが取り消されると、中間データがディスクにスピルされるため、クエリはメモリ制限を超えることなく処理を継続できます。ディスクに強制的にスピルされるクエリの実行時間が長くなる可能性があるので、デフォルトでは無効になっていることに注意してください。Amazon EMR でスピルを有効にするには、以下の設定を使用します: + `spill-enabled=true` – メモリ使用量が使用可能なしきい値を超えた場合にディスクのスピルを有効にします。 + `spill-paths` – 流出したデータが保存されるディレクトリ `spill-paths=/mnt/spill` を定義します。 # テーブル統計を収集して使用する テーブル統計を収集することで、Trino のコストベースのオプティマイザは結合順序、フィルタープッシュダウン、パーティションプルーニングについて情報に基づいた意思決定を行うことができ、パフォーマンスが向上します。 `ANALYZE` コマンドを使用して、Hive または Iceberg テーブルの統計を収集できます: ``` ANALYZE sales; ``` このコマンドはテーブルの現在の統計を表示し、統計が最新かどうかを確認できます。結合、フィルター、またはグループ化オペレーションで使用される列のサブセットを指定することをお勧めします。 これはもう 1 つの便利なコマンドです。テーブルの現在の統計が表示され、統計が最新かどうかを確認します。 ``` show stats for table_name; ``` # Trino ワークロードをスケーリングする際の一般的な課題 Trino で Amazon S3 を使用する主な利点は、S3 が大規模なデータボリュームに合わせてスケールできることと、S3 のコスト効率です。ただし、大量のデータボリュームをクエリすると、関連するパフォーマンスの問題が発生することがあります。これらは、データの保存方法、良好なパフォーマンスを制限する構成設定、またはその他の理由で発生する可能性があります。 これらの問題が発生した場合、問題を回避または軽減するために実行できる効果的なステップがあります。 このセクションでは、大規模なデータボリュームのクエリパフォーマンスを向上させるために実装できる一般的な最適化のリストから始めます。その後、一般的な問題が詳細に説明され、それぞれに緩和策が提供されています。 このトピックは、次のカンファレンスプレゼンテーションから入手できます:「[Accelerate performance at scale: Best practices for Trino with Amazon S3](https://www.youtube.com/watch?v=cjUUcHlUKxQ)」。 ## 大規模なデータセットのデータレイアウトの最適化 大規模なデータセットをクエリする場合、パフォーマンスのボトルネックはまれではありません。ただし、Trino を使用して Amazon S3 のデータをクエリする際に、有利なスタートを切るために実装できるベストプラクティスがあります。これには以下が含まれます。 + **パーティショニング** – パーティショニングとは、階層にデータを整理し、関連する属性に基づいて関連するデータを一緒に保存することを意味します。パーティション化により、クエリが無関係なデータをスキャンする必要がなくなり、クエリのパフォーマンスが向上します。ソースデータをプレフィックスで配置する、特に日付範囲、リージョン、またはその他の属性で配置するなど、さまざまなパーティショニング戦略を使用できます。パフォーマンスを向上させるために Amazon S3 でデータをパーティション化する方法の詳細については、ブログ記事「Get [started managing partitions for Amazon S3 tables backed by the AWS Glue Data Catalog](https://aws.amazon.com/blogs/big-data/get-started-managing-partitions-for-amazon-s3-tables-backed-by-the-aws-glue-data-catalog/)」または記事[「Top 10 Performance Tuning Tips for Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/)」を参照してください。 + **バケット化** – バケット化とは、関連するデータを共通のファイルにグループ化することです。たとえば、州などの地理的リージョンに従ってデータをクエリする場合、同じファイルまたはファイルのグループ内の特定の州のすべてのデータをグループ化することで、クエリのパフォーマンスを向上させることができます。これを最適に機能させるには、例えば州や都道府県など、カーディナリティの高いデータ属性に基づいてバケットを作成します。また、クエリパターンを考慮することもできます。クエリが通常、これらの州からデータを読み取る場合、この例としては、カリフォルニアとオレゴンのデータをグループ化することが考えられます。 + **S3 プレフィックスの管理** – Amazon S3 プレフィックスを使用してパーティショニング戦略を実装できます。例えば、特定の日付などの Amazon S3 バケットに 1 つのプレフィックスのみを使用することにより、リクエスト数が多くなり、HTTP 503 エラーが発生する可能性があります。プレフィックスを使用して条件を追加し、ソースデータをより効果的に整理することをお勧めします。詳細については、「Amazon S3 ユーザーガイド」の「[プレフィックスを使用してオブジェクトを整理する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html)」を参照してください。次の簡単な例は、リクエストスループットを向上させるプレフィックス を示しています: `s3://bucket/country=US/dt=2024-06-13`。このサンプルでは、国と日付の両方がプレフィックスに含まれているため、プレフィックスに日付のみが含まれている場合よりも読み取りが少なくなります。 HTTP 503 エラーの軽減については、このトピックで後述する *HTTP スローダウン*セクションで詳しく説明します。 + **データサイズの最適化** – OPTIMIZE コマンドを実行して、パフォーマンスが向上するクエリに役立つ設定を行うことができます。Hive 外部テーブルに対してこれを実行するには、以下の手順に従います: + `OPTIMIZE` を使って以下のパラメータを使用します:`hive.non-managed-table-writes-enabled=true` 。このプロパティの詳細については、「[Hive general configuration properties](https://trino.io/docs/current/connector/hive.html#hive-general-configuration-properties)」を参照してください。 + 次のパラメータを設定します: `SET SESSION` `catalog.non_transactional_optimize_enabled=true` + `OPTIMIZE` コマンドを実行します: `ALTER TABLE catalog.schema.table EXECUTE optimize(file_size_threshold => '128MB')`。この場合、`file_size_threshold` はデフォルトで 100MB です。このしきい値を上げると、サンプルに示すように、128MB 未満のファイルがマージされます。 + **再試行の設定** – 再試行制限を引き上げることで、HTTP 503 エラーの可能性を軽減できます: `s3.max-error-retries`。これは、TrinoFileSystem API および Trino 449 バージョン以降を使用する場合に適用されます。一方、Trino で Amazon EMR を使用している場合は、EMRFS を使用して Amazon S3 にアクセスします。EMRFS では、`fs.s3.maxRetries` パラメータを変更することで廃止回数を増やすことができます。 + **Amazon S3 ストレージクラスの選択** – ライフサイクルのさまざまな時点でデータに適したストレージクラスを選択すると、特定のデータ収集の要件に基づいて、パフォーマンスとコストの両方に役立ちます。詳細については、「Amazon S3 ドキュメント」の「[Amazon S3 ストレージクラスの理解と管理](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.htm)」を参照してください。 + **Iceberg への移行** – 特に小さなファイルでのクエリの実行に関するパフォーマンスの問題を軽減するためのもう 1 つの解決策は、Iceberg テーブルへの移行です。Iceberg には、小さなファイルをうまく処理する機能があります。 + **自動データ圧縮を使用する** – Iceberg テーブルを使用する場合、 AWS Glue データカタログによる自動データ圧縮はデータサイズを最適化し、クエリパフォーマンスを向上させることができます。 ## 大規模なデータセットをクエリする際の一般的な課題 このセクションでは、Amazon S3 に大規模なデータセットを蓄積し、Trino でクエリを実行する時に発生する可能性がある一般的な問題のコレクションを一覧表示します。各セクションでは、問題を解決する方法、またはクエリへの影響を減らす方法を示します。以下のセクションで説明する各問題は、Hive コネクタを使用して再現およびテストされています。 ### 大規模データスキャン クエリで大規模なデータセットをスキャンする必要がある場合、クエリのパフォーマンスが低下し、ストレージコストが高くなるなどの問題が発生する可能性があります。大規模なデータボリュームは、データの急速な増加や、適切な期間内にレガシーデータを移動しない計画によって発生する可能性があります。これにより、クエリが遅くなる可能性があります。 大規模なデータセットのスキャンによるパフォーマンスのヒットを軽減するには、パーティショニングとバケット化を使用することをお勧めします: + パーティション分割は、属性に基づいて関連データをグループ化します。パーティショニングを効果的に使用することにより、クエリのパフォーマンスが大幅に向上します。 + バケット化とは、特定の関連データ列に従ってファイルまたはバケットにデータをグループ化することを指します。バケット化は通常、関連するソースデータファイルを物理的にまとめることを意味します。 大規模なデータスキャンで緩和がどのように機能するかを説明するために、カリフォルニアまたはアラスカに割り当てることができる状態属性を持つレコードを持つデータを保存してクエリするとします。この状態属性はクエリ条件の 1 つです。各状態のデータを別の S3 バケットに保存するか、S3 プレフィックスを使用して状態に基づいてデータをパーティション化することで、クエリのパフォーマンスを向上させることができます。このパーティショニングとバケット化は、例えば日付属性などの追加の列に基づいている場合にも、パフォーマンスの向上につながる可能性があります。 **注記** 列のカーディナリティが高く、それを使用してデータをグループ化する場合は、バケット化を使用することをお勧めします。一方、通常、パーティションキーのカーディナリティは低くしなければなりません。 **さまざまな S3 ストレージタイプの使用** 一般的に、ワークロードのパフォーマンス、データアクセス、耐障害性、コスト要件に基づいてストレージタイプを選択します。コストとパフォーマンスの間にはトレードオフが生じる可能性があります。データアクセスパターンに一致する適切な Amazon S3 ストレージクラスを選択することが重要です。主なアクセスパターンは 2 つあります: + 既知または予測可能な方法でアクセスされるデータ。一般的に、アクセス頻度の低いデータがある場合、コスト削減に役立つため、S3 標準 IA が適しています。頻繁にデータにアクセスしている場合、S3 Standard は Amazon EMR と Trino によるアクセスに最適です。 + 不明または予測不可能な方法でアクセスされるデータ。これは、他の Amazon S3 ストレージクラスの使用を呼び出すことができます。S3 ストレージクラス間にはトレードオフがあります。これには、レイテンシー、ストレージコスト、可用性が含まれます。ワークロードとアクセスパターンに基づいて、適切な S3 ストレージタイプを選択できます。各クラスの利点の詳細については、「[Amazon S3 ストレージクラス]()」を参照してください。 **圧縮の使用** Iceberg テーブルを使用することにより、Iceberg 自動圧縮を使用することもできます。これにより、ファイルサイズが最適になり、クエリ効率が向上します。詳細については、「[AWS Glue データカタログが Apache Iceberg テーブルの自動コンパクションをサポートするようになった](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/)」を参照してください。 ### HTTP スローダウンエラー これは、リクエストレートが Amazon S3 プレフィックスで事前設定されたしきい値を超えた場合に発生します。この状態に達したときに最も一般的に発生する HTTP エラーは、**Error 503: Please reduce your request rate** です。この問題のソースは、データを読み取るために作成する必要がある*分割*の数が多いため、多数の小さなファイルが存在する場合に根付くことができます。この問題を軽減するには、いくつかの方法があります。 + Trino で Amazon S3 リクエストの再試行制限を引き上げます。これは、Trino 449 で `fs.s3.maxretries` を使用する EMRFS に設定されます。 + ファイルサイズを最適化し、リクエストレートを下げることもできます。 Trino がクエリするデータセットの分割数を決定する方法の詳細については、Hive コネクタドキュメントの「[Performance tuning configuration properties](https://trino.io/docs/current/connector/hive.html#performance-tuning-configuration-properties)」を参照してください。 ### 小さなファイルのクエリが困難 多くの小さなファイルをクエリすることにより、GET および LIST リクエストの数が多いため、I/O オーバーヘッドが大きくなり、クエリのパフォーマンスに悪影響を及ぼす可能性があります。ファイルサイズを最適化することにより、クエリのパフォーマンスが向上します。これを行う方法はいくつかあります: + より少ないサイズのファイルにデータを統合します。(通常、ファイルサイズは約 128 MB にすることをお勧めします。) これは、ETL パイプラインなどのデータを取り込むときにツールで実行することも、データを手動で統合することもできます。これらのソリューションが利用できない場合は、残りのオプションが適している可能性があります。 + `OPTIMIZE` コマンドを実行します。 + `SESSION` パラメータを設定します。 Iceberg には、小さなファイルを自動圧縮である大きなファイルにマージできる機能があることに注意してください。 AWS Glue データカタログで管理されるファイルで動作します。詳細については、「[AWS Glue データカタログが Apache Iceberg テーブルの自動コンパクションをサポートするようになった](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/)」を参照してください。 ### 不要なデータを含むクエリ データが大きくなるのは一般的です。そのため、データアクセスパターンを追跡し、古くなったり無関係になったりしたときにデータを適切に移動することが不可欠です。これは、データが大きくなると、クエリのパフォーマンスが時間の経過とともに低下する可能性があるためです。主に、クエリの実行時にスキャンする大量のデータが原因です。Amazon S3 およびその他の サービスは、データライフサイクル移行のガイダンスを提供します。これは、データがコールドになったときにさまざまなストレージロケーションに移動するための戦略を示しています。これを行うと、ストレージコストにも利点があります。 データ移行に加えて、実行中のクエリに関連しないソースデータの削除など、他の戦略を使用することもできます。これには、ソースデータスキーマの変更を意味する可能性があるので、多少の作業が必要になる場合があります。しかし、その肯定的な結果は、データ量を減らし、クエリを高速化することです。詳細については、「[オブジェクトのライフサイクルの管理](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)」を参照してください。 # Trino に関する考慮事項 Amazon EMR で Trino を実行するときは、以下について検討します。 ## 設定不可能な Trino デプロイプロパティ 次の表に、Trino `properties` ファイルのさまざまな設定オプションを示します。 | システム | 設定可能 | | --- | --- | | `log.properties` | Trino: Amazon EMR バージョン 6.1.0 以降で設定可能です。`prestosql-log` または `trino-log` 設定分類を使用します。 | | `config.properties` | Trino: Amazon EMR バージョン 6.1.0 以降で設定可能です。`prestosql-config` または `trino-config` 設定分類を使用します。 | | `hive.properties` | Trino: Amazon EMR バージョン 6.1.0 以降で設定可能です。`prestosql-connector-hive` または `trino-connector-hive` 設定分類を使用します。 | | `node.properties` | Trino: Amazon EMR バージョン 6.1.0 以降で設定可能です。`prestosql-node` または `trino-node` 設定分類を使用します。 | | `jvm.config` | 設定可能ではありません。 | ## その他の考慮事項 + EMR バージョン 6.1.0 以降の Trino では、Amazon EMR はクラスターノード間のセキュアな内部通信用に共有秘密キーを自動的に設定します。このセキュリティ機能を有効にするために追加の設定を行う必要はなく、独自の秘密キーを使用して設定をオーバーライドできます。Trino 内部認証の詳細については、[Trino 353 ドキュメントの「Secure internal communication」](https://trino.io/docs/current/security/internal-communication.html)を参照してください。 # Trino リリース履歴 リリースノートセクションでは、Amazon EMR での Trino の特定のバージョンの変更と更新について詳しく説明します。 ## Trino リリースノート (バージョン別) + [Amazon EMR 7.6.0 - Trino リリースノート](Trino-release-history-760.md) + [Amazon EMR 7.3.0 - Trino リリースノート](Trino-release-history-730.md) + [Amazon EMR 6.9.0 - Trino リリースノート](Trino-release-history-690.md) # Amazon EMR 7.6.0 - Trino リリースノート ## Amazon EMR 7.6.0 - Trino の新機能 + 長時間実行されるクエリをサポートするため、Trino には耐障害性実行メカニズムが組み込まれました。耐障害性実行では、失敗したクエリやそのコンポーネントタスクを再試行することで、クエリの失敗を軽減します。 ## Amazon EMR 7.6.0 - Trino の変更 **Amazon EMR 7.6.0 - Trino の変更** | 型 | 説明 | | --- | --- | | アップグレード | Trino の 457 へのアップグレード | # Amazon EMR 7.3.0 - Trino リリースノート ## Amazon EMR 7.3.0 - Trino の変更 + このリリースでは、Trino をバージョン 436 から 442 にアップグレードします。 + このリリースでは、Hudi クエリを新しい Hudi 修正子にリダイレクトします。古い Hive コネクタは Hudi テーブルを読み取ることができなくなります。メモ + このリリースでは、Rubix モジュールがオープンソースから非推奨になったため、Amazon EMR から Rubix モジュールを削除します。 + このリリースでは、`hive.security` プロパティの[レガシーモードが削除されます](https://github.com/trinodb/trino/pull/21013)。現在のデフォルトは `allow-all` になります。 # Amazon EMR 6.9.0 - Trino リリースノート ## Amazon EMR 6.9.0 - Trino の新機能 + 長時間実行されるクエリをサポートするため、Trino には耐障害性実行メカニズムが組み込まれました。耐障害性実行では、失敗したクエリやそのコンポーネントタスクを再試行することで、クエリの失敗を軽減します。 ## Amazon EMR 6.9.0 - Trino の変更 **Amazon EMR 6.9.0 - Trino の変更** | 型 | 説明 | | --- | --- | | アップグレード | Trino の 398 へのアップグレード | | アップグレード | Hadoop 3.3.3 をサポート | | 機能 | Tardigrade のサポート: HDFS と Amazon S3 での交換スプーリングのサポートを追加しました。 | | バグ修正 | Trino Iceberg を使用していて、Glue カタログが有効になっている場合は、メタストア URI を `iceberg.properties.` に追加しません | ## Amazon EMR 6.9.0 - Trino の既知の問題 + Amazon EMR リリース 6.9.0 では、Apache Ranger が有効になっているクラスターでは Trino は動作しません。Ranger で Trino を使用する必要がある場合は、[サポート](https://console.aws.amazon.com/support/home#/) にお問い合わせください。