Amazon Redshift で Apache Iceberg データをクエリするためのベストプラクティス

本記事は 2025 年 12 月 17 日に公開された「Best practices for querying Apache Iceberg data with Amazon Redshift」を翻訳したものです。

Apache Iceberg は、データウェアハウスとデータレイクアーキテクチャの両方の利点を組み合わせることで、データの保存とアクセス方法に選択肢と柔軟性を提供するオープンテーブル形式です。AWS Analytics サービスを使用して Apache Iceberg データを管理する詳細については、AWS での Apache Iceberg の使用をご覧ください。Amazon Redshift は、Amazon S3 Tables を使用してフルマネージドにされているか、Amazon S3 でセルフマネージドにされているかに関わらず、Iceberg テーブルを直接クエリすることをサポートしています。Redshift で Iceberg テーブルを設計、データ保存、クエリする方法のベストプラクティスを理解することで、分析ワークロードのコストとパフォーマンスの目標を達成できます。

この記事では、Amazon Redshift で Apache Iceberg のデータをクエリする際のベストプラクティスについて説明します。

1. テーブル設計のベストプラクティスに従う

Iceberg テーブルに適切なデータ型を選択することは、効率的なクエリパフォーマンスとデータ整合性の維持に重要です。汎用的または過度に広範なデータ型を使用するのではなく、列のデータ型を格納するデータの性質に合わせることが重要です。

なぜテーブル設計のベストプラクティスに従うのか？

ストレージとパフォーマンスの最適化: 最も適切なデータ型を使用することで、テーブルに必要なストレージ量を削減し、クエリパフォーマンスを向上させることができます。例えば、日付列に STRING 型や TIMESTAMP 型ではなく DATE データ型を使用することで、ストレージフットプリントを削減し、日付ベースの操作の効率を向上させることができます。
結合のパフォーマンス向上: 結合される列に使用されるデータ型は、クエリパフォーマンスに影響を与える可能性があります。数値型 (INTEGER、BIGINT、DECIMAL など) などの特定のデータ型は、文字列ベースの型 (VARCHAR、TEXT など) と比較して、より効率的に結合操作を行えます。これは数値型が簡単に比較およびソートでき、より効率的なハッシュベースの結合アルゴリズムにつながるためです。
データ整合性と一貫性: 正しいデータ型を選択することで、適切な制約とバリデーションが強制されデータ整合性の維持に役立ちます。これにより、特に複数のソースからデータが取り込まれる場合に、データ破損や予期しない動作のリスクが軽減されます。

テーブル設計のベストプラクティスに従う方法は？

Iceberg のデータ型マッピングを活用する: Iceberg には、異なるデータソースと Iceberg テーブルのスキーマ間で変換する組み込みの型マッピングがあります。Iceberg が型変換をどのように処理するかを理解し、この知識を利用してユースケースに最適なデータ型を定義します。
データに対応できる最小のデータ型を選択します。例えば、値が整数範囲内に収まる場合は BIGINT の代わりに INT を使用し、さらに小さい範囲に収まる場合は SMALLINT を使用します。
データ長が一貫している場合は、固定長データ型を利用します。これは予測可能で高速なパフォーマンスの実現に役立ちます。
テキストには VARCHAR や TEXT などの文字型を選択し、効率性のために適切な長さの VARCHAR を優先します。スペースを無駄にし操作を遅くする可能性があるため、VARCHAR の長さの過度な割り当てを避けます。
実際の要件に数値精度を合わせます。不必要に高い精度 (通貨に DECIMAL(10,2) の代わりに DECIMAL(38,20) など) を使用すると、より多くのストレージと処理が必要になり、計算と比較のクエリ実行時間が遅くなります。
日付をテキストや数値として保存するのではなく、日付と時刻のデータ型 (DATE、TIMESTAMP など) を使用します。これによりストレージが最適化され、効率的な時間フィルタリングと操作が可能になります。
true/false 状態を表すために整数を使用するのではなく、ブール値 (BOOLEAN など) を選択します。これにより領域が節約され、処理速度が向上する可能性があります。
列が結合操作で使用される場合は、一般的にインデックス作成に使用されるデータ型を優先します。整数と日付/時刻型は、一般的に VARCHAR(MAX) などのより大きく効率の悪い型よりも高速な検索とソートを可能にします。

2. フィルタで最も頻繁に使用される列で Apache Iceberg テーブルをパーティション化する

Amazon Redshift と組み合わせて Apache Iceberg テーブルを操作する場合、クエリパフォーマンスを最適化する最も効果的な方法の 1 つは、データを戦略的にパーティション化することです。重要な原則は、クエリフィルタで最も頻繁に使用される列に基づいて Iceberg テーブルをパーティション化することです。このアプローチはクエリ効率を大幅に向上させ、スキャンされるデータ量を削減し、クエリ実行の高速化とコストの削減につながります。

Iceberg テーブルのパーティション化が重要な理由は？

クエリパフォーマンスの向上: WHERE 句で一般的に使用される列でパーティション化すると、Amazon Redshift は無関係なパーティションを排除でき、スキャンする必要があるデータ量を削減できます。例えば、日付でパーティション化された売上テーブルがあり、2024 年 1 月の売上データを分析するクエリを実行する場合、Amazon Redshift はテーブル全体ではなく 2024 年 1 月のパーティションのみをスキャンします。このパーティションプルーニングにより、クエリパフォーマンスを劇的に向上させることができます。このシナリオでは、5 年分の売上データがある場合、1 か月だけをスキャンすることは、総データの 1.67% のみを調べることを意味し、クエリ実行時間を数分から数秒に短縮できる可能性があります。
スキャンコストの削減: スキャンするデータが少なくなることで、必要な計算リソースを削減でき、その結果、関連するコストを削減できます。
より良いデータ編成: 論理的なパーティション化により、一般的なクエリパターンに合わせてデータを編成し、データ取得をより直感的かつ効率的にします。

Iceberg テーブルをパーティション化する方法は？

ワークロードを分析して、フィルタ条件で最も頻繁に使用される列を特定します。例えば、常に過去 6 か月間のデータをフィルタリングする場合、その日付が適切なパーティションキーになります。
カーディナリティが高いが、小さなパーティションを作成しすぎないように高すぎない列を選択します。適切な候補には次のものが挙げられます:
- 日付またはタイムスタンプ列 (年、月、日など)
- 適度な数の個別値を持つカテゴリ列 (地域、製品カテゴリなど)
パーティション戦略を定義する: Iceberg のパーティション化機能を使用して戦略を定義します。例えば、Amazon Athena を使用してパーティション化された Iceberg テーブルを作成する場合、次の構文を使用できます。

CREATE TABLE [db_name.]table_name (col_name data_type [COMMENT col_comment] [, …]
[PARTITIONED BY (col_name | transform, … )]
LOCATION 's3://amzn-s3-demo-bucket/your-folder/'
TBLPROPERTIES ( 'table_type' = 'ICEBERG' [, property_name=property_value] )

例

CREATE TABLE iceberg_db.my_table ( id INT, date DATE, region STRING, sales DECIMAL(10,2) )
PARTITIONED BY (date, region)
LOCATION 's3://amzn-s3-demo-bucket/your-folder/'
TBLPROPERTIES ( 'table_type' = 'ICEBERG' )

可能な限り WHERE 句にパーティションキーを含めることで、Redshift クエリがパーティションスキームを活用できるようにします。

サンプルユースケースのウォークスルー

ベストプラクティスに従って最適なパーティションキーを選択する方法を理解するために、例を見てみましょう。Amazon Redshift で Apache Iceberg テーブルを使用し売上データ分析を最適化しようとしている e コマース企業を考えてみましょう。同社は sales_transactions というテーブルをメンテナンスしており、4 つの地域 (North America, Europe, Asia, and Australia) にわたる 5 年分のデータと、5 つの製品カテゴリ (Electronics, Clothing, Home & Garden, Books, and Toys) があります。データセットには、transaction_id、transaction_date、customer_id、product_id、product_category、region、sale_amount などの主要な列が含まれています。

データサイエンスチームは、transaction_date と region 列をフィルタで頻繁に使用し、product_category はあまり頻繁に使用されません。transaction_date 列は高いカーディナリティ (1 日あたり 1 つの値) を持ち、region は低いカーディナリティ (4 つの個別値のみ) を持ち、product_category は中程度のカーディナリティ (5 つの個別値) を持ちます。

この分析に基づくと、効果的なパーティション戦略は、transaction_date から年と月、そして region でパーティション化することです。これにより、最も一般的なクエリパターンを改善しながら、管理可能な数のパーティションが作成されます。Amazon Athena を使用してこの戦略を実装する方法は次のとおりです:

CREATE TABLE iceberg_db.sales_transactions ( transaction_id STRING, transaction_date DATE, customer_id STRING, product_id STRING, product_category STRING, region STRING, sale_amount DECIMAL(10,2))
PARTITIONED BY (transaction_date, region)
LOCATION 's3://athena-371178653860-22hcl401/sales-data/'
TBLPROPERTIES ('table_type' = 'ICEBERG');

3. クエリに必要な列のみを選択して最適化する

Iceberg テーブルを操作するもう 1 つのベストプラクティスは、特定のクエリに必要な列のみを選択し、SELECT * 構文の使用を避けることです。

なぜ必要な列のみを選択すべきなのか？

クエリパフォーマンスの向上: 分析ワークロードでは、ユーザーは通常、データのサブセットを分析し、大規模な集計やトレンド分析を実行します。これらの操作を最適化するために、分析ストレージシステムとファイル形式は、効率的な列ベースの読み取り用に設計されています。例として、Apache Parquet などの列指向オープンファイル形式や Amazon Redshift などの列指向データベースが含まれます。クエリで必要な列のみを選択するという重要なベストプラクティスにより、クエリエンジンは処理、スキャン、返却する必要があるデータ量を削減できます。これにより、特に大きなテーブルでクエリ実行時間を大幅に短縮できます。
リソース使用率の削減: 不要な列を取得すると、CPU、メモリ、ネットワーク帯域幅などの追加のシステムリソースが消費されます。選択する列を制限することでリソース使用率を最適化し、データ処理パイプラインの全体的な効率を向上させることができます。
データ転送コストの削減: クラウドストレージ (Amazon S3 など) に保存された Iceberg テーブルをクエリする場合、ストレージサービスからクエリエンジンに転送されるデータ量は、データ転送コストに直接影響する可能性があります。必要な列のみを選択することで、これらのコストを最小限に抑えることができます。
より良いデータ局所性: Iceberg は、パーティションキーの値に基づいてデータをパーティション化します。必要な列のみを選択することで、クエリエンジンはパーティションスキームをより良く活用してデータ局所性を向上させ、スキャンする必要があるデータ量を削減できます。

必要な列のみを選択する方法は？

必要な列を特定する: 各クエリの要件を慎重に分析し、クエリの目的を満たすために必要な最小限の列セットを決定します。
選択的な列名を使用する: SQL クエリの SELECT 句で、SELECT * を使用するのではなく、必要な列名を明示的にリストします。

4. AWS Glue データカタログの列レベル統計を生成する

テーブル統計は、Amazon Redshift などのコストベースオプティマイザー (CBO) を利用するデータベースシステムで重要な役割を果たします。これらは、CBO がクエリ実行プランについて情報に基づいた決定を下すのに役立ちます。クエリが Amazon Redshift に送信されると CBO は複数の可能な実行プランを評価し、それらのコストを推定します。これらのコスト推定は次のようなデータに関する正確な統計に大きく依存します: テーブルサイズ (行数)、列値分布、列内の個別値の数、データスキュー情報など。

AWS Glue データカタログは、Apache Iceberg を含むデータレイクに保存されたデータの統計生成をサポートしています。統計には、最小値、最大値、null 値の総数、個別値の総数、値の平均長、true 値の総出現数など、テーブル内の列に関するメタデータが含まれます。これらの列レベル統計は、Apache Iceberg テーブルを操作する際にクエリパフォーマンスを最適化し、コスト効率を向上させるのに役立つ貴重なメタデータを提供します。

AWS Glue 統計の生成が重要な理由は？

Amazon Redshift は列統計を使用してより良いクエリプランを生成でき、それにより最適化された結合順序、より良い述語プッシュダウン、より正確なリソース割り当てによりクエリのパフォーマンスを向上させます。
コストが最適化されます。より良い実行プランにより、データスキャンの削減、より効率的なリソース使用率、全体的なクエリコストの削減につながります。

AWS Glue 統計を生成する方法は？

Sagemaker Lakehouse Catalog を使用すると、1度カタログ設定することで更新および作成されたテーブルの統計を自動的に生成できます。新しいテーブルが作成されると、Iceberg テーブルの個別値数 (NDV) が収集されます。デフォルトでは、データカタログは週単位でテーブル内のすべての列の列統計を生成および更新します。このジョブは、統計を計算するためにテーブル内のレコードの 50% を分析します。

Lake Formation コンソールで、ナビゲーションペインの Catalogs を選択します。
設定するカタログを選択し、Actions メニューで Edit を選択します。
Enable automatic statistics generation for the tables of the catalog を選択し、IAM ロールを選択します。必要な権限については、列統計を生成するための前提条件を参照してください。
Submit を選択します。

デフォルトを上書きして、特定のニーズを満たすためにテーブルレベルで統計収集をカスタマイズできます。頻繁に更新されるテーブルの場合、統計を週単位よりも頻繁に更新できます。また、最も一般的にクエリされる列に焦点を当てるために、ターゲット列を指定することもできます。統計を計算する際に使用するテーブルレコードの割合を設定できます。したがって、より正確な統計が必要なテーブルではこの割合を増やし、より小さなサンプルで十分なテーブルではコストと統計生成パフォーマンスを最適化するために減らすことができます。これらのテーブルレベル設定は、前述のカタログレベル設定を上書きできます。

詳細については、ブログ AWS Glue Data Catalog のテーブル統計自動収集機能の紹介 – Amazon Redshift と Amazon Athena のクエリパフォーマンス向上をご覧ください。

5. 最適なパフォーマンスのためのテーブルメンテナンス戦略を実装する

時間が経つにつれて、Apache Iceberg テーブルはクエリパフォーマンスとストレージ効率に影響を与えるさまざまなタイプのメタデータとファイルアーティファクトを蓄積する可能性があります。これらのアーティファクトを理解し管理することは、データレイクの最適なパフォーマンスを維持するために重要です。Iceberg テーブルを使用すると、3 つの主要なタイプのアーティファクトが蓄積されます:

小さなファイル: データが Iceberg テーブルに取り込まれる場合、特にストリーミングや頻繁なマイクロバッチによる更新では、各書き込み操作は既存のファイルに追加するのではなく新しいファイルを作成するため、多くの小さなファイルが蓄積される可能性があります。
削除されたデータアーティファクト: Iceberg は更新と削除にコピーオンライトを使用します。レコードが削除されると、Iceberg はデータをすぐに削除するのではなく、「削除マーカー」を作成します。これらのマーカーは、削除されたレコードをフィルタリングするために読み取り中に処理されます。
スナップショット: テーブルに変更を加える (データの挿入、更新、削除) たびに、Iceberg は新しいスナップショット (基本的にはテーブルの特定時点のビュー) を作成します。履歴を維持するのに価値がある一方で、これらのスナップショットは時間の経過とともにメタデータサイズを増加させ、クエリプランニングと実行に影響を与えます。
参照されていないファイル: これらは、ストレージに存在するが、現在のテーブルスナップショットにリンクされていないファイルです。これらは2つの主要なシナリオで発生します:
1. 古いスナップショットが期限切れになると、それらのスナップショットによって排他的に参照されていたファイルが参照されなくなります
2. 書き込み操作が中断されたり、途中で失敗したりすると、どのスナップショットにも適切にリンクされていないデータファイルが作成されます

テーブルメンテナンスが重要な理由は？

定期的なテーブルメンテナンスは、いくつかの重要な利点をもたらします:

クエリパフォーマンスの向上: 小さなファイルを統合することでクエリ中に必要なファイル操作の数が削減され、過剰なスナップショットと削除マーカーを削除することでメタデータ処理が合理化されます。これらの最適化により、クエリエンジンはデータにより効率的にアクセスし、処理できます。
ストレージ使用率の最適化: 古いスナップショットを期限切れにし、参照されていないファイルを削除することで、貴重なストレージ領域が解放され、データレイクが成長する中でコスト効率的なストレージ使用率を維持できます。
リソース効率の向上: 最適化されたファイルサイズとクリーンなメタデータを持つ適切に維持されたテーブルは、クエリ実行においてより少ない計算リソースを必要とし、分析ワークロードをより高速かつ効率的に実行できます。
より良いスケーラビリティ: 適切に維持されたテーブルは、データボリュームが増加してもより効果的にスケールし、データレイクが拡張されても一貫したパフォーマンス特性を維持します。

テーブルメンテナンスを実行する方法は？

3 つの主要なメンテナンス操作が Iceberg テーブルの最適化に役立ちます:

コンパクション: 小さなファイルをより大きなファイルに結合し、削除ファイルをデータファイルとマージして、合理化されたデータアクセスパターンとクエリパフォーマンスの向上をもたらします。
スナップショットの期限切れ: 設定可能な履歴ウィンドウをメンテナンスし、不要になった古いスナップショットを削除します。
参照されていないファイルの削除: どのスナップショットからも参照されなくなったファイルを特定して削除し、ストレージ領域を回収し、システムが追跡する必要があるオブジェクトの総数を削減します。

AWS は、テーブルメンテナンスを自動的に処理する S3 tables と呼ばれるフルマネージド Apache Iceberg データレイクソリューションを提供しています:

自動コンパクション: S3 Tables は、複数の小さなオブジェクトを少数の大きなオブジェクトに結合することで自動的にコンパクションを実行し、Apache Iceberg クエリパフォーマンスを向上させます。オブジェクトを結合する際、コンパクションはテーブル内の行レベル削除の効果も適用します。設定可能なテーブルレベルプロパティに基づいてコンパクションプロセスを管理できます。
- targetFileSizeMB: デフォルトは 512 MB です。64 MiB から 512 MiB の間の値に設定できます。

Apache Iceberg は、データをコンパクトするために Binpack, Sort, Z-order などのさまざまな方法を提供しています。デフォルトでは、Amazon S3 はテーブルのソート順序に基づいて、これら 3 つのコンパクション戦略の中から最適なものを自動的に選択します。

自動スナップショット管理: S3 Tables は、設定可能なテーブルレベルプロパティに基づいて古いスナップショットを自動的に期限切れにします
- MinimumSnapshots (デフォルトで 1): S3 Tables が保持するテーブルスナップショットの最小数
- MaximumSnapshotAge (デフォルトで 120 時間): このパラメータは、保持するスナップショットの保持期限を時間単位で決定します
参照されていないファイルの削除: 設定可能なバケットレベルプロパティに基づいて、テーブルスナップショットによって参照されていないオブジェクトを自動的に特定して削除します:
- unreferencedDays (デフォルトで 3 日): この期間参照されていないオブジェクトは Noncurrent としてマークされます
- nonCurrentDays (デフォルトで 10 日): Noncurrent オブジェクトはこの期間後に削除されます

注意: Noncurrent オブジェクトの削除は永続的であり、これらのオブジェクトを復元する方法はありません。

Iceberg テーブルを自分で管理している場合は、これらのメンテナンスタスクを実装する必要があります:

Athena を使用する場合:

次の構文を使用して OPTIMIZE コマンドを実行します:
```
OPTIMIZE [database_name.]<table_name>;
```
このコマンドは、ビンパッキングアルゴリズムを利用して小さなデータファイルをより大きなファイルにグループ化するコンパクションプロセスをトリガーします。また、削除ファイルを既存のデータファイルとマージし、テーブルを効果的にクリーンアップしてその構造を改善します。
iceberg テーブル作成時に次のテーブルプロパティを設定します: vacuum_min_snapshots_to_keep (デフォルト 1): 保持する最小スナップショット数 vacuum_max_snapshot_age_seconds (デフォルト 432000 秒または 5 日)
古いスナップショットを期限切れにし、参照されていないファイルを削除するために定期的に VACUUM コマンドを実行します。iceberg テーブルでマージなどの操作を実行した後に推奨されます。構文: VACUUM [database_name.]target_table。VACUUM はスナップショットの期限切れと孤立ファイルの削除を実行します

Spark SQL を使用する場合:

Iceberg のファイル書き換えアクションで定期的なコンパクションジョブをスケジュールします
expireSnapshots 操作を使用して古いスナップショットを削除します
deleteOrphanFiles 操作を実行して参照されていないファイルをクリーンアップします
書き込みパターンに基づいてメンテナンススケジュールを確立します (時間単位、日単位、週単位)
これらの操作を順番に実行します。通常、コンパクションの後にスナップショットの期限切れと参照されていないファイルの削除の順序で行います
大規模な取り込みジョブ、大量の削除操作、または上書き操作の後にこれらの操作を実行することが特に重要です

6. リアルタイムダッシュボードクエリのパフォーマンスを向上させるために、Redshift で Apache Iceberg テーブルに増分マテリアライズドビューを作成する

業界を問わず組織では、売上トレンド、製品パフォーマンス、地域比較、在庫率などのリアルタイム指標のためにデータレイク駆動のダッシュボードを利用しています。基盤となる Iceberg テーブルに数十億のレコードが含まれ、毎日数百万ずつ増加している状況で、各ダッシュボード更新時にメトリクスをゼロから再計算することは、大幅な遅延を生み出し、ユーザーエクスペリエンスを低下させます。

Apache Iceberg と Amazon Redshift の統合により、Iceberg テーブルに増分マテリアライズドビューを作成してダッシュボードクエリパフォーマンスを最適化できます。これらのビューは次の方法で効率を向上させます:

複雑なクエリ結果を事前計算して保存する
増分メンテナンスを使用して、最後の更新以降の最近の変更のみを処理する
完全な再計算と比較して計算とストレージコストを削減する

Iceberg テーブルの増分マテリアライズドビューが重要な理由は？

パフォーマンス最適化: 事前計算されたマテリアライズドビューは、特に大規模な Iceberg テーブルにアクセスする際に、ダッシュボードクエリを大幅に高速化します
コスト効率: Amazon Redshift による増分メンテナンスは直近の変更のみを処理し、高コストな全体再計算のサイクルを回避します
カスタマイズ: ビューは特定のダッシュボード要件に合わせて調整でき、データアクセスパターンを最適化し、処理オーバーヘッドを削減します

増分マテリアライズドビューを作成する方法は？

リアルタイムダッシュボードクエリの主要なデータソースとなる Iceberg テーブルを特定します。
CREATE MATERIALIZED VIEW ステートメントを使用して、Iceberg テーブルにマテリアライズドビューを定義します。マテリアライズドビュー定義に必要な列と適用可能な集計または変換のみが含まれていることを確認します。
増分更新の対象となるすべての演算子を使用している場合、Amazon Redshift は自動的に増分更新可能なマテリアライズドビューを作成します。増分更新の対象とならない操作については、増分更新の制限を参照してください
REFRESH MATERIALIZED VIEW コマンドを使用してマテリアライズドビューを定期的に更新します

7. ビジネスロジックをカプセル化するために Iceberg テーブルにレイトバインディングビュー (LBV) を作成する

Apache Iceberg テーブルを含む外部テーブルでの Amazon Redshift のレイトバインディングビューのサポートにより、ビュー定義内でビジネスロジックをカプセル化できます。このベストプラクティスは、Redshift で Iceberg テーブルを操作する際にいくつかの利点を提供します。

なぜ LBV を作成するのか？

集約されたビジネスロジック: ビューでビジネスロジックを定義することで、ビューを参照するすべてのクエリで変換、集計、その他の処理ステップが一貫して適用されることを保証できます。これにより、コードの再利用と保守性が促進されます。
基盤となるデータからの抽象化: レイトバインディングビューは、ビュー定義を基盤となる Iceberg テーブル構造から分離します。これにより、列の追加や削除など Iceberg テーブルに変更を加えても、テーブルに依存するビュー定義を更新する必要がありません。
クエリパフォーマンスの向上: Redshift は、述語プッシュダウンやパーティションプルーニングなどの技術を利用して、処理する必要があるデータ量を最小限に抑え、レイトバインディングビューに対するクエリの実行を最適化できます。
データセキュリティの強化: ビューレベルでアクセス制御と権限を定義することで、ユーザーに必要なデータと機能のみへのアクセスを許可し、データ環境の全体的なセキュリティを向上させることができます。

LBV を作成する方法は？

適切な Apache Iceberg テーブルを特定する: ビジネスロジックとレポート要件の主要なデータソースである Iceberg テーブルを特定します。
レイトバインディングビュー (LBV) を作成する: CREATE VIEW ステートメントを使用し、外部 Iceberg テーブルにレイトバインディングビューを定義します。ビュー定義内に必要な変換、集計、その他のビジネスロジックを組み込みます。
例:
```
CREATE VIEW my_iceberg_view AS
SELECT col1,col2,SUM(col3) AS total_col3
GROUP BY col1, col2
WITH NO SCHEMA BINDING;
```
ビュー権限を付与する: ビューに適切な権限を割り当て、カプセル化されたビジネスロジックへのアクセスが必要なユーザーまたはロールにアクセスを許可します。

まとめ

この記事では、Amazon Redshift を使用して Apache Iceberg テーブルをクエリするためのベストプラクティスを、基本的な設計判断に焦点を当てて説明しました。重要なトピックの1つはテーブル設計とデータ型の選択であり、これはストレージサイズとクエリパフォーマンスに最大の影響を与える可能性があります。さらに、Amazon S3 Tables を使用してフルマネージドテーブルを持つことで、コンパクション、スナップショット管理、バキューム操作などの重要なメンテナンスタスクを自動的に処理し、分析アプリケーションの構築に集中できます。

Amazon Redshift と Apache Iceberg テーブルを使用するワークフローを構築する際は、ワークロードの目標を達成するために次のベストプラクティスを検討してください:

自動管理機能を活用するために、新しい実装では Amazon S3 Tables を採用する
最適化の機会を特定するために既存のテーブル設計を監査する
実際のクエリパターンに基づいて明確なパーティション化戦略を開発する
Amazon S3 でセルフマネージドされた Apache Iceberg テーブルの場合、統計生成とコンパクションのための自動メンテナンス処理を実装する

著者について

Anusha Challa Anusha は、Amazon Redshift に焦点を当てたシニアアナリティクススペシャリストソリューションアーキテクトです。彼女は、クラウドとオンプレミスで大規模な分析ソリューションを構築する数百の顧客を支援してきました。彼女はデータ分析、データサイエンス、AI に情熱を注いでいます。

Mohammed Alkateb Mohammed は、Amazon Redshift のエンジニアリングマネージャーです。Mohammed は 18 の米国特許を持ち、EDBT、ICDE、SIGMOD、VLDB を含む主要なデータベース会議の研究および産業トラックで出版物があります。Mohammed は、バーモント大学でコンピュータサイエンスの博士号、カイロ大学で情報システムの修士号と学士号を取得しています。

Jonathan Katz Jonathan は、オープンソース PostgreSQL プロジェクトのコアチームメンバーであり、アクティブなオープンソースコントリビューターです。

この記事は Kiro が翻訳を担当し、Solutions Architect の Shintaro Watanabe がレビューしました。

Amazon Web Services ブログ