# Athena ACID トランザクションを使用する
<a name="acid-transactions"></a>

「ACID トランザクション」という用語は、データベーストランザクションにおけるデータの整合性を保証する一連のプロパティ ([アトミック性](https://en.wikipedia.org/wiki/Atomicity_(database_systems))、[整合性](https://en.wikipedia.org/wiki/Consistency_(database_systems))、[分離性](https://en.wikipedia.org/wiki/Isolation_(database_systems))、および[耐久性](https://en.wikipedia.org/wiki/Durability_(database_systems))) を指します。ACID トランザクションを使用すると、データレイクに対するクエリにおいて読み込みの整合性を維持することで、既存のクエリを分離しながら、複数のユーザーがアトミックな方法で Amazon S3 オブジェクトを同時に確実に追加および削除できます。Athena ACID トランザクションは、Athena SQL データ操作言語 (DML) による挿入、削除、更新、およびタイムトラベルオペレーションのための、単一テーブルのサポートを追加します。お客様ならびに同時に実行している複数のユーザーは、Athena ACID トランザクションを使用することで、Amazon S3 の行レベルのデータ対して信頼性の高い変更を行うことができます。Athena トランザクションにより、ロックのセマンティクスと調整が自動的に処理されます。カスタムのレコードロックソリューションは必要ありません。

使い慣れた SQL 構文で Athena ACID トランザクションを行うことで、ビジネスや規制に関するデータの更新が簡素化されます。たとえば、データの消去リクエストに応答する場合は、SQL の `DELETE` オペレーションを実行します。手動によるレコードの修正には、単一の `UPDATE` ステートメントを使用します。また、最近削除されたデータを回復する場合は、`SELECT` ステートメントにより、タイムトラベルクエリを発行します。

Athena ACID トランザクションは共有テーブルフォーマット上に構築されるため、[Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html) や [Apache Spark](https://spark.apache.org/) など、同じく共有テーブル形式をサポートしている他のサービスやエンジンとの互換性を持ちます。

Athena トランザクションは、Athena コンソール、API オペレーション、ODBC および JDBC ドライバを介して利用できます。

**Topics**
+ [Linux Foundation Delta Lake テーブルをクエリする](delta-lake-tables.md)
+ [Apache Hudi データセットをクエリする](querying-hudi.md)
+ [Apache Iceberg テーブルをクエリする](querying-iceberg.md)

# Linux Foundation Delta Lake テーブルをクエリする
<a name="delta-lake-tables"></a>

Linux Foundation [Delta Lake](https://delta.io/) は、ビッグデータ分析用のテーブル形式です。Amazon Athena を使用すると、マニフェストファイルを生成したり、`MSCK REPAIR` ステートメントを実行したりすることなく、Amazon S3 に保存されている Delta Lake テーブルを直接読み込むことができます。

Delta Lake 形式には、各データファイルの列ごとの最小値と最大値が格納されます。Athena の実装では、この情報を利用して述語でのファイルスキップが可能になり、不要なファイルが考慮対象から除外されます。

## 考慮事項と制限事項
<a name="delta-lake-tables-considerations-and-limitations"></a>

Athena の Delta Lake サポートには、次の考慮事項と制限があります。
+ **[AWS Glue カタログ付きのテーブルのみ]** - Delta Lake のネイティブサポートは、AWS Glue に登録されたテーブルでのみサポートされます。別のメタストアに登録されている Delta Lake テーブルがある場合でも、それを保持してプライマリのメタストアとして扱うことができます。Delta Lake のメタデータはメタストアではなくファイルシステム (Amazon S3 など) に保存されるため、Athena では Delta Lake テーブルから読み込むには AWS Glue にある場所プロパティのみが必要です。
+ **[V3 engine only]** (V3 エンジンのみ) - Delta Lake クエリは Athena エンジンバージョン 3 でのみサポートされます。作成するワークグループが Athena エンジンバージョン 3 を使用するように設定する必要があります。
+ **[No time travel support]** (タイムトラベルのサポートなし) - Delta Lake のタイムトラベル機能を使用するクエリはサポートされていません。
+ **[Read only]** (読み込み専用) - `UPDATE`、`INSERT` または `DELETE` のような DML ステートメントの記述はサポートされていません。
+ **Lake Formation サポート** — Lake Formation の統合は、AWS Glueと同期したスキーマの Delta Lake テーブルに利用できます。詳細については、「*AWS Lake Formation デベロッパーガイド*」の「[Amazon Athena での AWS Lake Formation の使用](https://docs.aws.amazon.com/lake-formation/latest/dg/athena-lf.html)」および「[Delta Lake テーブルのアクセス許可をセットアップする](https://docs.aws.amazon.com/lake-formation/latest/dg/set-up-delta-table.html)」を参照してください。
+ **[Limited DDL support]** (限定的な DDL サポート) - 次の DDL ステートメントは以下の `CREATE EXTERNAL TABLE`、`SHOW COLUMNS`、`SHOW TBLPROPERTIES`、`SHOW PARTITIONS`、`SHOW CREATE TABLE`、および `DESCRIBE` をサポートしています。`CREATE EXTERNAL TABLE` ステートメントの使用方法については、「[Delta Lake テーブルの使用を開始する](delta-lake-tables-getting-started.md)」のセクションを参照してください。
+ **Amazon Glacier オブジェクトのスキップはサポートされていません** – Linux Foundation Delta Lake テーブルのオブジェクトが Amazon Glacier ストレージクラスにある場合、`read_restored_glacier_objects` テーブルプロパティを `false` に設定しても効果はありません。

  例えば、次のコマンドを実行したとします。

  ```
  ALTER TABLE table_name SET TBLPROPERTIES ('read_restored_glacier_objects' = 'false')
  ```

  Iceberg および Delta Lake テーブルでは、コマンドは「サポートされていないテーブルプロパティキー: read\$1restored\$1glacier\$1objects」というエラーを生成します。Hudi テーブルでは、`ALTER TABLE` コマンドはエラーを発生しませんが、Amazon Glacier オブジェクトはまだスキップされません。`ALTER TABLE` コマンドの後に `SELECT` クエリを実行すると、引き続きすべてのオブジェクトが返されます。
+ **暗号化されたテーブル** – Athena は、CSE-KMS で暗号化された Delta Lake テーブルの読み取りをネイティブではサポートしていません。これには、SELECT ステートメントと DDL ステートメントが含まれます。

### Delta Lake のバージョニングと Athena
<a name="delta-lake-tables-versioning"></a>

Athena は、Delta Lake ドキュメントに記載されている[バージョニング](https://docs.delta.io/latest/releases.html)を使用しません。Delta Lake テーブルが Athena と互換性があるかどうかを判断するには、次の 2 つの特性を考慮します。
+ **リーダーバージョン ** – すべての Delta Lake テーブルにはリーダーバージョンがあります。現在、これは 1～3 の数値です。Athena がサポートしていないリーダーバージョンのテーブルを含むクエリは失敗します。
+ **テーブル機能 ** – すべての Delta Lake テーブルは、リーダー/ライター機能のセットを宣言することもできます。Athena による Delta Lake のサポートは読み取り専用であるため、テーブルライター機能の互換性は適用されません。ただし、サポートされていないテーブルリーダー機能を持つテーブルに対するクエリは失敗します。

次の表は、Athena がサポートする Delta Lake リーダーのバージョンと Delta Lake テーブルリーダーの機能を示しています。


****  

| クエリタイプ | サポートされるリーダーのバージョン | サポートされているリーダー機能 | 
| --- | --- | --- | 
| DQL (SELECT ステートメント） | <= 3 | [列マッピング](https://docs.delta.io/latest/delta-column-mapping.html)、[timestampNtz](https://github.com/delta-io/delta/blob/master/PROTOCOL.md#timestamp-without-timezone-timestampntz)、[削除ベクトル](https://docs.delta.io/latest/delta-deletion-vectors.html) | 
| DDL | <= 1 | 該当なし。リーダー機能は、リーダーバージョンが 2 以上のテーブルでのみ宣言できます。 | 
+ Delta Lake テーブル機能のリストについては、GitHub.com の「[テーブル機能の有効な機能名](https://github.com/delta-io/delta/blob/master/PROTOCOL.md#valid-feature-names-in-table-features)」を参照してください。
+ プロトコルバージョン別の Delta Lake 機能のリストについては、GitHub.com の[「プロトコルバージョン別の機能](https://docs.delta.io/latest/versioning.html#features-by-protocol-version)」を参照してください。

Athena でリーダーバージョンが 1 より大きい Delta Lake テーブルを作成するには、「[Delta Lake メタデータを同期する](delta-lake-tables-syncing-metadata.md)」を参照してください。

**Topics**
+ [考慮事項と制限事項](#delta-lake-tables-considerations-and-limitations)
+ [サポートされている列のデータ型](delta-lake-tables-supported-data-types-columns.md)
+ [Delta Lake テーブルの使用を開始する](delta-lake-tables-getting-started.md)
+ [SQL を使用して Delta Lake テーブルをクエリする](delta-lake-tables-querying.md)
+ [Delta Lake メタデータを同期する](delta-lake-tables-syncing-metadata.md)
+ [その他のリソース](delta-lake-tables-additional-resources.md)

# サポートされている列のデータ型
<a name="delta-lake-tables-supported-data-types-columns"></a>

このセクションでは、非パーティション列とパーティション列でサポートされているデータ型について説明します。

## サポートされる非パーティション列のデータ型
<a name="delta-lake-tables-supported-data-types-non-partition-columns"></a>

非パーティション列では、Athena がサポートしている `CHAR` 以外のデータ型をすべてのデータ型がサポートされます (`CHAR` は Delta Lake プロトコル自体ではサポートされていません)。サポートされているデータ型は次のとおりです。

```
boolean
tinyint
smallint
integer
bigint
double
float
decimal
varchar
string
binary
date
timestamp
array
map
struct
```

## サポートされているパーティション列のデータ型
<a name="delta-lake-tables-supported-data-types-partition-columns"></a>

Athena は、パーティション列で次のデータ型を持つテーブルをサポートしています。

```
boolean
integer
smallint
tinyint
bigint
decimal
float
double
date
timestamp
varchar
```

Athena でのデータ型についての詳細は、「[Amazon Athena のデータ型](data-types.md)」を参照してください。

# Delta Lake テーブルの使用を開始する
<a name="delta-lake-tables-getting-started"></a>

クエリを実行するには、Delta Lake テーブルが AWS Glue に存在している必要があります。テーブルが Amazon S3 にあるものの AWS Glue にはない場合には、次の構文を使用して `CREATE EXTERNAL TABLE` ステートメントを実行します。テーブルがすでに AWS Glue に存在する場合 (たとえば、Apache Spark や AWS Glue で他のエンジンを使用している場合)、この手順は省略できます。列定義、SerDe ライブラリ、およびその他のテーブルプロパティが省略されていることに注意してください。従来の Hive テーブルとは異なり、Delta Lake テーブルのメタデータは Delta Lake のトランザクションログから推測され、AWS Glue に直接同期されます。

```
CREATE EXTERNAL TABLE
  [db_name.]table_name
  LOCATION 's3://amzn-s3-demo-bucket/your-folder/'
  TBLPROPERTIES ('table_type' = 'DELTA')
```

**注記**  
このステートメントは、リクエスタ支払いが有効になっている S3 バケットと互換性がありません。リクエスタ支払いが有効になっている S3 バケットに対して Delta Lake テーブルを作成する場合は、「[Delta Lake メタデータを同期する](delta-lake-tables-syncing-metadata.md)」の手順と DDL ステートメントに従ってください。
Delta Lake テーブルでは、`LOCATION` および `table_type` 以外のプロパティを含む `CREATE TABLE` ステートメントは使用できません。

# SQL を使用して Delta Lake テーブルをクエリする
<a name="delta-lake-tables-querying"></a>

Delta Lake テーブルをクエリするには、次の標準 SQL `SELECT` 構文を使用します。

```
[ WITH with_query [, ...] ]SELECT [ ALL | DISTINCT ] select_expression [, ...]
[ FROM from_item [, ...] ]
[ WHERE condition ]
[ GROUP BY [ ALL | DISTINCT ] grouping_element [, ...] ]
[ HAVING condition ]
[ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] select ]
[ ORDER BY expression [ ASC | DESC ] [ NULLS FIRST | NULLS LAST] [, ...] ]
[ OFFSET count [ ROW | ROWS ] ]
[ LIMIT [ count | ALL ] ]
```

`SELECT` 構文の詳細については、Athena ドキュメントの「[SELECT](select.md)」を参照してください。

Delta Lake 形式には、各データファイルの列ごとの最小値と最大値が格納されます。Athena では、この情報を利用して述語でのファイルスキップが可能になり、不要なファイルが考慮対象から除外されます。

# Delta Lake メタデータを同期する
<a name="delta-lake-tables-syncing-metadata"></a>

Athena を使用して Delta Lake テーブルを作成する場合、Athena はスキーマ、パーティション列、およびテーブルプロパティなどのテーブルメタデータを含むテーブルメタデータを AWS Glue に同期します。時間が経過すると、このメタデータは、トランザクションログ内の基になるテーブルメタデータとの同期を失う可能性があります。テーブルを最新の状態に保つには、以下のいずれかのオプションを選択できます。
+ Delta Lake テーブルの AWS Glue クローラーを使用する。詳細については、「*AWS Big Data Blog*」の「[Introducing native Delta Lake table support with AWS Glue crawlers](https://aws.amazon.com/blogs/big-data/introducing-native-delta-lake-table-support-with-aws-glue-crawlers/)」と「AWS Glue 開発者ガイド」の「[AWS Glue クローラーのスケジュール](https://docs.aws.amazon.com/glue/latest/dg/schedule-crawler.html)」を参照してください。
+ Athena にテーブルをドロップして再作成する。
+ SDK、CLI、または AWS Glue コンソールを使用して、AWS Glue のスキーマを手動で更新する。

以下の機能を使用するには、AWS Glue スキーマがトランザクションログと常に同じスキーマである必要があることに注意してください。
+ Lake Formation
+ ビュー
+ 行フィルターと列フィルター

この機能がワークフローで必要なく、この互換性を維持しない場合は、Athena で `CREATE TABLE` DDL を使用し、AWS Glue で Amazon S3 パスを SerDe パラメータとして追加できます。

## Athena と AWS Glue コンソールを使用して Delta Lake テーブルを作成する
<a name="delta-lake-tables-syncing-metadata-console"></a>

次の手順を使用して、Athena と AWS Glue コンソールで Delta Lake テーブルを作成できます。

**Athena と AWS Glue コンソールを使用して Delta Lake テーブルを作成するには**

1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。

1. Athena クエリエディタで、次の DDL を使用して Delta Lake テーブルを作成します。この方法を使用する場合、`TBLPROPERTIES` は `'table_type' = 'delta'` ではなく `'spark.sql.sources.provider' = 'delta'`の値はである必要があります。

   Apache Spark (Athena for Apache Spark) または他のほとんどのエンジンを使用してテーブルを作成すると、(タイプ `array<string>` の `col` という名前の単一の列を含む) この同じスキーマが挿入されることに注意してください。

   ```
   CREATE EXTERNAL TABLE
      [db_name.]table_name(col array<string>)
      LOCATION 's3://amzn-s3-demo-bucket/your-folder/'
      TBLPROPERTIES ('spark.sql.sources.provider' = 'delta')
   ```

1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/) で AWS Glue コンソール を開きます。

1. ナビゲーションペインで、**[データカタログ]**、**[テーブル]** を選択します。

1. テーブルのリストで、目的のテーブルのリンクを選択します。

1. テーブルのページで、**[アクション]**、**[テーブルの編集]** を選択します。

1. **[Serde パラメータ]** セクションで、値 **s3://amzn-s3-demo-bucket/*your-folder*/** を含むキー **path** を追加します。

1. **[保存]** を選択します。

## AWS CLI を使用して Delta Lake テーブルを作成する
<a name="delta-lake-tables-syncing-metadata-cli"></a>

AWS CLI を使用して Delta Lake テーブルを作成するには、次のようにコマンドを入力します。

```
aws glue create-table --database-name dbname \
    --table-input '{"Name" : "tablename", "StorageDescriptor":{
            "Columns" : [
                {
                    "Name": "col",
                    "Type": "array<string>"
                }
            ],
            "Location" : "s3://amzn-s3-demo-bucket/<prefix>/",
            "SerdeInfo" : {
                "Parameters" : {
                    "serialization.format" : "1",
                    "path" : "s3://amzn-s3-demo-bucket/<prefix>/"
                }
            }
        },
        "PartitionKeys": [],
        "TableType": "EXTERNAL_TABLE",
        "Parameters": {
            "EXTERNAL": "TRUE",
            "spark.sql.sources.provider": "delta"
        }
    }'
```

# その他のリソース
<a name="delta-lake-tables-additional-resources"></a>

AWS Glue での Delta Lake テーブルの使用および Athena でのそれらのクエリの説明については、「*AWS Big Data Blog*」の「[Handle UPSERT data operations using open-source Delta Lake and AWS Glue](https://aws.amazon.com/blogs/big-data/handle-upsert-data-operations-using-open-source-delta-lake-and-aws-glue/)」を参照してください。

# Apache Hudi データセットをクエリする
<a name="querying-hudi"></a>

[https://hudi.incubator.apache.org/](https://hudi.incubator.apache.org/) は、増分データ処理を簡素化するオープンソースのデータ管理フレームワークです。レコードレベルの挿入、更新、upsert、および削除アクションは、はるかに細かく処理され、オーバーヘッドを軽減します。`Upsert` は、レコードがまだ存在しない場合は既存のデータセットに挿入し、存在する場合はレコードを更新する機能のことです。

Hudi は、分析のパフォーマンス問題を引き起こす可能性のある小さなファイルを多数作成することなく、データの挿入と更新イベントを処理します。Apache Hudi は自動的に変更を追跡し、ファイルをマージして、最適なサイズを維持します。これにより、多数の小さなファイルをモニタリングし、より少ない数の大きなファイルに書き換えるカスタムソリューションを構築する必要がなくなります。

Hudi データセットは、次のユースケースに適しています。
+ [一般データ保護規則](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) (GDPR) や[カリフォルニア州消費者プライバシー法](https://en.wikipedia.org/wiki/California_Consumer_Privacy_Act) (CCPA) など、個人情報を削除したり、個人データの使用方法を変更したりする権利を実施するプライバシー規制を遵守する。
+ 特定のデータの挿入および更新イベントを必要とするセンサーやその他のモノのインターネット (IoT) デバイスからのストリーミングデータを操作する。
+ [変更データキャプチャ (CDC) システム](https://en.wikipedia.org/wiki/Change_data_capture)の実装

Hudi データセットは、次のタイプのいずれかになります。
+ **書き込み時コピー (CoW)** – データは列形式 (Parquet) で保存され、更新ごとに書き込み中にファイルの新しいバージョンが作成されます。
+ **読み取り時マージ (MoR)** – データは、列形式 (Parquet) 形式と行形式 (Avro) の組み合わせを使用して保存されます。更新は、行形式の `delta` ファイルに記録され、必要に応じて圧縮されて、新しいバージョンの列形式のファイルが作成されます。

CoW データセットでは、レコードが更新されるたびに、そのレコードを含むファイルが更新された値で書き換えられます。MoR データセットでは、更新があるたびに、Hudi によって変更されたレコードの行のみが書き込まれます。MoR は、読み取りが少なく書き込みまたは変更が多いワークロードに適しています。CoW は、頻繁に変更されないデータの読み取りが多いワークロードに適しています。

Hudi にはデータにアクセスするためのクエリタイプが 3 種類用意されています。
+ **スナップショットクエリ** – 指定されたコミットまたは圧縮アクションの時点で最新のテーブルスナップショットを参照するクエリです。MoR テーブルの場合、スナップショットクエリは、クエリ時に最新のファイルスライスのベースファイルとデルタファイルをマージして、テーブルの最新の状態を提示します。
+ **増分クエリ** – クエリは、指定されたコミット/圧縮以降にテーブルに書き込まれた新しいデータのみを参照します。これにより、増分データパイプラインを有効にするための変更ストリームが効果的に提供されます。
+ **読み取り最適化クエリ** – MoR テーブルの場合、クエリは圧縮された最新のデータを参照します。CoW テーブルの場合、クエリはコミットされた最新のデータを参照します。

次の表は、各テーブルタイプに対して実行できる Hudi クエリタイプを示しています。


| テーブルタイプ | 使用可能な Hudi クエリタイプ | 
| --- | --- | 
| 書き込み時にコピー | スナップショット、増分 | 
| 読み取り時にマージ | スナップショット、増分、読み取り最適化 | 

テーブルとクエリタイプ間でのトレードオフの詳細については、Apache Hudi ドキュメントの「[テーブルとクエリのタイプ](https://hudi.apache.org/docs/table_types/)」を参照してください。

## Hudi 用語の変更: ビューはクエリに変更されました
<a name="querying-hudi-hudi-dataset-table-types-terminology"></a>

Apache Hudi リリースバージョン 0.5.1 以降、以前はビューと呼ばれていたものがクエリと呼ばれるようになりました。次の表は、新旧用語の変更をまとめたものです。


| 旧用語 | 新用語 | 
| --- | --- | 
|  CoW: 読み取り最適化ビュー MoR: リアルタイムビュー  |  スナップショットクエリ  | 
| 増分ビュー | 増分クエリ | 
| MoR 読み取り最適化ビュー | 読み取り最適化クエリ | 

**Topics**
+ [Hudi 用語の変更: ビューはクエリに変更されました](#querying-hudi-hudi-dataset-table-types-terminology)
+ [考慮事項と制限事項](querying-hudi-in-athena-considerations-and-limitations.md)
+ [書き込み時コピー (CoW) テーブル作成の例](querying-hudi-copy-on-write-create-table-examples.md)
+ [読み取り時マージ (MOR) テーブル作成の例](querying-hudi-merge-on-read-create-table-examples.md)
+ [Hudi メタデータを使用してパフォーマンスを改善する](querying-hudi-metadata-table.md)
+ [その他のリソース](querying-hudi-additional-resources.md)

# 考慮事項と制限事項
<a name="querying-hudi-in-athena-considerations-and-limitations"></a>

Athena を利用して Apache Hudi テーブルを読み取る際には、次の点を考慮してください。
+ **読み取り/書き込みオペレーション** – Athena では、圧縮された Hudi データセットの読み取りはできますが、Hudi データの書き込みはできません。
+ **Hudi バージョン** – Athena は Hudi バージョン 0.14.0（デフォルト）と 0.15.0 をサポートしています。Athena は、Hudi のそれ以降のバージョンで作成されたテーブルとの読み取り互換性は保証できません。Hudi の機能とバージョニングの詳細については、Apache ウェブサイトの「[Hudi ドキュメント](https://hudi.apache.org/)」を参照してください。Athena の Hudi コネクタのバージョン 0.15.0 はブートストラップされたテーブルをサポートしていないことに注意してください。Hudi コネクタの 0.15.0 を使用するには、次のテーブルプロパティを設定します。

  ```
  ALTER TABLE table_name SET TBLPROPERTIES ('athena_enable_native_hudi_connector_implementation' = 'true')
  ```
+ **クロスアカウントクエリ** – Hudi コネクタのバージョン 0.15.0 は、クロスアカウントクエリをサポートしていません。
+ **クエリタイプ** – 現在、Athena はスナップショットクエリと読み取り最適化クエリをサポートしていますが、増分クエリはサポートしていません。MoR テーブルでは、すべての 読み取り最適化クエリに対して提示されるデータは圧縮されています。これにより、パフォーマンスは向上しますが、最新のデルタコミットは含まれていません。Snapshot クエリには、最も新しいデータが含まれています。しかし、いくつかの計算オーバーヘッドが生じ、これらのクエリのパフォーマンスが低下します。テーブルとクエリタイプ間でのトレードオフの詳細については、Apache Hudi ドキュメントの「[テーブルとクエリのタイプ](https://hudi.apache.org/docs/table_types/)」を参照してください。
+ **増分クエリ** – Athena は増分クエリをサポートしていません。
+ **CTAS** – Athena は、Hudi データで [CTAS](ctas.md) または [INSERT INTO](insert-into.md) をサポートしていません。Athena による Hudi データセットへの書き込みのサポートをご希望の場合は、athena-feedback@amazon.com までフィードバックをお送りください。

  Hudi データの記述の詳細については、次のリソースを参照してください。
  + 「[Amazon EMR リリースガイド](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/)」の「[Hudi データセットの操作](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hudi-work-with-dataset.html)」。
  + Apache Hudi ドキュメントの「[Writing Data](https://hudi.apache.org/docs/0.8.0/writing_data.html)」。
+ **MSCK REPAIR TABLE** – Athena での Hudi テーブルに対する MSCK REPAIR TABLE の使用はサポートされていません。AWS Glue 以外で作成された Hudi テーブルをロードする必要がある場合は、[ALTER TABLE ADD PARTITION](alter-table-add-partition.md) を使用してください。
+ **Amazon Glacier オブジェクトのスキップはサポートされていません** – Apache Hudi テーブル内のオブジェクトが Amazon Glacier ストレージクラスにある場合、`read_restored_glacier_objects` テーブルプロパティを `false` に設定しても効果はありません。

  例えば、次のコマンドを実行したとします。

  ```
  ALTER TABLE table_name SET TBLPROPERTIES ('read_restored_glacier_objects' = 'false')
  ```

  Iceberg および Delta Lake テーブルでは、コマンドは「サポートされていないテーブルプロパティキー: read\$1restored\$1glacier\$1objects」というエラーを生成します。Hudi テーブルでは、`ALTER TABLE` コマンドはエラーを発生しませんが、Amazon Glacier オブジェクトはまだスキップされません。`ALTER TABLE` コマンドの後に `SELECT` クエリを実行すると、引き続きすべてのオブジェクトが返されます。
+ **タイムスタンプクエリ** – 現在、Hudi リアルタイムテーブルのタイムスタンプ列の読み取りを試みるクエリは、失敗するか、または空の結果を生成します。この制限は、タイムスタンプ列を読み取るクエリにのみ適用されます。同じテーブルのタイムスタンプ以外の列のみを含むクエリは成功します。

  失敗したクエリは、次のようなメッセージを返します: 

  GENERIC\$1INTERNAL\$1ERROR: クラス org.apache.hadoop.io.ArrayWritable をクラス org.apache.hadoop.hive.serde2.io.TimestampWritableV2 にキャストできません (org.apache.hadoop.io.ArrayWritable と org.apache.hadoop.hive.serde2.io.TimestampWritableV2 は、ローダー io.trino.server.PluginClassLoader @75c67992 の名前のないモジュール内にあります)
+ **0.15.0 Hudi Connector での Lake Formation アクセス許可** – この制限は、テーブルプロパティ `athena_enable_native_hudi_connector_implementation` を `true` に設定してネイティブ Hudi コネクタ (バージョン 0.15.0) の使用にオプトインする場合にのみ適用されます。デフォルトでは、Athena は Hudi コネクタバージョン 0.14.0 を使用しますが、この追加のアクセス許可は必要ありません。Lake Formation で保護されたテーブルをクエリするには、テーブルのデータロケーションと `.hoodie` メタデータディレクトリの両方に Lake Formation アクセス許可を付与する必要があります。たとえば、Hudi テーブルが `s3://bucket/hudi-table/` にある場合は、Lake Formation で `s3://bucket/hudi-table/` と `s3://bucket/hudi-table/.hoodie/` の両方を登録してそれらにアクセス許可を付与する必要があります。`.hoodie` ディレクトリには、クエリ計画中に Athena が読み取る必要があるメタデータファイル (`hoodie.properties` など) が含まれています。`.hoodie` ディレクトリへのアクセス許可がない場合、クエリはアクセス許可拒否エラーで失敗します。

# 書き込み時コピー (CoW) テーブル作成の例
<a name="querying-hudi-copy-on-write-create-table-examples"></a>

AWS Glue で既に Hudi テーブルを作成している場合は、Athena でそれらを直接クエリできます。Athena でパーティション化された Hudi テーブルを作成するときは、クエリを実行する前に、`ALTER TABLE ADD PARTITION` を実行して Hudi データをロードする必要があります。

## パーティション化されていない CoW テーブル
<a name="querying-hudi-nonpartitioned-cow-table"></a>

以下の例は、Athena でパーティション分割されていない CoW テーブルを作成します。

```
CREATE EXTERNAL TABLE `non_partition_cow`(
  `_hoodie_commit_time` string,
  `_hoodie_commit_seqno` string,
  `_hoodie_record_key` string,
  `_hoodie_partition_path` string,
  `_hoodie_file_name` string,
  `event_id` string,
  `event_time` string,
  `event_name` string,
  `event_guests` int,
  `event_type` string)
ROW FORMAT SERDE
  'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT
  'org.apache.hudi.hadoop.HoodieParquetInputFormat'
OUTPUTFORMAT
  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
  's3://amzn-s3-demo-bucket/folder/non_partition_cow/'
```

## パーティション化された CoW テーブル
<a name="querying-hudi-partitioned-cow-table"></a>

以下の例は、Athena でパーティション分割された CoW テーブルを作成します。

```
CREATE EXTERNAL TABLE `partition_cow`(
  `_hoodie_commit_time` string, 
  `_hoodie_commit_seqno` string, 
  `_hoodie_record_key` string, 
  `_hoodie_partition_path` string, 
  `_hoodie_file_name` string, 
  `event_id` string, 
  `event_time` string, 
  `event_name` string, 
  `event_guests` int)
PARTITIONED BY ( 
  `event_type` string)
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT 
  'org.apache.hudi.hadoop.HoodieParquetInputFormat' 
OUTPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' 
LOCATION
  's3://amzn-s3-demo-bucket/folder/partition_cow/'
```

次の `ALTER TABLE ADD PARTITION` の例では、サンプル `partition_cow` テーブルに 2 つのパーティションを追加します。

```
ALTER TABLE partition_cow ADD
  PARTITION (event_type = 'one') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_cow/one/' 
  PARTITION (event_type = 'two') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_cow/two/'
```

# 読み取り時マージ (MOR) テーブル作成の例
<a name="querying-hudi-merge-on-read-create-table-examples"></a>

Hudi は、MoR のメタストアに 2 つのテーブルを作成します。1 つはスナップショットクエリ用のテーブルで、もう 1 つは読み取り最適化クエリ用のテーブルです。両方のテーブルがクエリ可能です。0.5.1 より前の Hudi バージョンでは、読み取り最適化クエリのテーブルには、テーブルの作成時に指定した名前がありました。Hudi バージョン 0.5.1 以降、デフォルトでテーブル名の末尾に `_ro` が付きます。スナップショットクエリのテーブルの名前は、指定した名前に `_rt` が付きます。

## パーティション化されていない読み取り時マージ (MOR) テーブル
<a name="querying-hudi-nonpartitioned-merge-on-read-table"></a>

次の例では、読み取り最適化クエリのために、Athena でパーティション分割されていない MoR テーブルを作成します。読み取り最適化クエリでは、入力形式 `HoodieParquetInputFormat` を使用することに注意してください。

```
CREATE EXTERNAL TABLE `nonpartition_mor`(
  `_hoodie_commit_time` string, 
  `_hoodie_commit_seqno` string, 
  `_hoodie_record_key` string, 
  `_hoodie_partition_path` string, 
  `_hoodie_file_name` string, 
  `event_id` string, 
  `event_time` string, 
  `event_name` string, 
  `event_guests` int, 
  `event_type` string)
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT 
  'org.apache.hudi.hadoop.HoodieParquetInputFormat' 
OUTPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' 
LOCATION
  's3://amzn-s3-demo-bucket/folder/nonpartition_mor/'
```

次の例では、スナップショットクエリのために、Athena でパーティション分割されていない MoR テーブルを作成します。スナップショットクエリの場合は、入力形式 `HoodieParquetRealtimeInputFormat` を使用します。

```
CREATE EXTERNAL TABLE `nonpartition_mor_rt`(
  `_hoodie_commit_time` string, 
  `_hoodie_commit_seqno` string, 
  `_hoodie_record_key` string, 
  `_hoodie_partition_path` string, 
  `_hoodie_file_name` string, 
  `event_id` string, 
  `event_time` string, 
  `event_name` string, 
  `event_guests` int, 
  `event_type` string)
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT 
  'org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat' 
OUTPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' 
LOCATION
  's3://amzn-s3-demo-bucket/folder/nonpartition_mor/'
```

## パーティション化された読み取り時マージ (MOR) テーブル
<a name="querying-hudi-partitioned-merge-on-read-table"></a>

次の例では、読み取り最適化クエリのために、Athena でパーティション分割された MoR テーブルを作成します。

```
CREATE EXTERNAL TABLE `partition_mor`(
  `_hoodie_commit_time` string, 
  `_hoodie_commit_seqno` string, 
  `_hoodie_record_key` string, 
  `_hoodie_partition_path` string, 
  `_hoodie_file_name` string, 
  `event_id` string, 
  `event_time` string, 
  `event_name` string, 
  `event_guests` int)
PARTITIONED BY ( 
  `event_type` string)
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT 
  'org.apache.hudi.hadoop.HoodieParquetInputFormat' 
OUTPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
  's3://amzn-s3-demo-bucket/folder/partition_mor/'
```

次の `ALTER TABLE ADD PARTITION` の例では、サンプル `partition_mor` テーブルに 2 つのパーティションを追加します。

```
ALTER TABLE partition_mor ADD
  PARTITION (event_type = 'one') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/one/'
  PARTITION (event_type = 'two') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/two/'
```

次の例では、スナップショットクエリのために、Athena でパーティション分割された MoR テーブルを作成します。

```
CREATE EXTERNAL TABLE `partition_mor_rt`(
  `_hoodie_commit_time` string, 
  `_hoodie_commit_seqno` string, 
  `_hoodie_record_key` string, 
  `_hoodie_partition_path` string, 
  `_hoodie_file_name` string, 
  `event_id` string, 
  `event_time` string, 
  `event_name` string, 
  `event_guests` int)
PARTITIONED BY ( 
  `event_type` string)
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT 
  'org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat'
OUTPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
  's3://amzn-s3-demo-bucket/folder/partition_mor/'
```

同様に、次の `ALTER TABLE ADD PARTITION` の例では、サンプル `partition_mor_rt` テーブルに 2 つのパーティションを追加します。

```
ALTER TABLE partition_mor_rt ADD
  PARTITION (event_type = 'one') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/one/'
  PARTITION (event_type = 'two') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/two/'
```

# Hudi メタデータを使用してパフォーマンスを改善する
<a name="querying-hudi-metadata-table"></a>

Apache Hudi には、ファイルの一覧表示、列統計を使用したデータのスキップ、ブルームフィルターベースのインデックスなど、パフォーマンスを改善するためのインデックス機能を含む[メタデータテーブル](https://hudi.apache.org/docs/next/metadata/)があります。

これらの機能のうち、Athena は現在、ファイルリストインデックスのみをサポートしています。ファイルリストインデックスは、ファイルに対するパーティションのマッピングを維持するインデックスから情報を取得することにより、「ファイルのリスト」などのファイルシステム呼び出しを排除します。これにより、ファイルシステムのビューを取得するために、テーブルパスの下のすべてのパーティションを再帰的にリストする必要がなくなります。大規模なデータセットを扱う場合、このインデックス作成により、書き込みやクエリ中にファイルのリストを取得するときに発生するレイテンシーが大幅に低減されます。また、Amazon S3 `LIST` 呼び出しでのリクエスト制限のスロットリングなどのボトルネックも回避できます。

**注記**  
現時点では、Athena はデータスキップやブルームフィルターインデックス作成をサポートしていません。

## Hudi メタデータテーブルの有効化
<a name="querying-hudi-metadata-table-enabling-the-hudi-metadata-table"></a>

メタデータテーブルベースのファイルリストはデフォルトでは無効になっています。Hudi メタデータテーブルと関連ファイルのリスト機能を有効にするには、`hudi.metadata-listing-enabled` テーブルプロパティを `TRUE` に設定します。

**例**  
次の`ALTER TABLE SET TBLPROPERTIES` の例では、サンプル `partition_cow` テーブルでメタデータテーブルを有効にします。

```
ALTER TABLE partition_cow SET TBLPROPERTIES('hudi.metadata-listing-enabled'='TRUE')
```

## ブートストラップ生成メタデータを使用する
<a name="querying-hudi-hudi-dataset-table-types-bootstrap"></a>

Apache Hudi バージョン 0.6.0 以降では、ブートストラップ操作機能によって、既存の Parquet データセットのパフォーマンスが向上します。ブートストラップ操作では、データセットを書き換える代わりに、メタデータのみを生成し、データセットはそのまま残すことができます。

Athena を使用して、Amazon S3 のデータに基づいて他のテーブルと同様に、ブートストラップ操作からテーブルをクエリできます。`CREATE TABLE` ステートメントで、`LOCATION` 句で Hudi テーブルのパスを指定します。

Amazon EMR で、ブートストラップオペレーションを使用して Hudi テーブルを作成する方法の詳細については、「AWS ビッグデータブログ」の記事「[New features from Apache Hudi available in Amazon EMR](https://aws.amazon.com/blogs/big-data/new-features-from-apache-hudi-available-in-amazon-emr/)」(Amazon EMR で利用可能な Apache Hudi の新機能) を参照してください。

# その他のリソース
<a name="querying-hudi-additional-resources"></a>

Athena での Apache Hudi の使用に関するその他のリソースについては、以下のリソースを参照してください。

## 動画
<a name="querying-hudi-videos"></a>

次の動画では、Amazon Athena を使用して、Amazon S3 ベースのデータレイクにある Apache Hudi データセットの読み取り最適化クエリをする方法が紹介されています。

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/TVcreqxBaGA/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/TVcreqxBaGA)


## ブログ記事
<a name="querying-hudi-big-data-blogs"></a>

次の AWS Big Data Blog 記事では、Athena で Apache Hudi を使用する方法を解説しています。
+ [AWS Data Exchange を使用して Apache Hudi データセットをシームレスに共有する](https://aws.amazon.com/blogs/big-data/use-aws-data-exchange-to-seamlessly-share-apache-hudi-datasets/) 
+ [AWS DMS、Amazon Kinesis、AWS Glue ストリーミング ETL、Quick を使用したデータ視覚化を使用して、Apache Hudi ベースのほぼリアルタイムのトランザクションデータレイクを作成する](https://aws.amazon.com/blogs/big-data/create-an-apache-hudi-based-near-real-time-transactional-data-lake-using-aws-dms-amazon-kinesis-aws-glue-streaming-etl-and-data-visualization-using-amazon-quicksight/) 
+ AWS Glue カスタムコネクタと AWS Glue 2.0 ジョブを使用して、Athena でクエリできる Apache Hudi テーブルを作成する方法については、「[Writing to Apache Hudi tables using AWS Glue custom connector](https://aws.amazon.com/blogs/big-data/writing-to-apache-hudi-tables-using-aws-glue-connector/)」を参照してください。
+ データレイクのデータ処理フレームワークを構築するための Apache Hudi、AWS Glue、および Amazon Athena の使用に関する記事については、「[Simplify operational data processing in data lakes using AWS Glue and Apache Hudi](https://aws.amazon.com/blogs/big-data/simplify-operational-data-processing-in-data-lakes-using-aws-glue-and-apache-hudi/)」を参照してください。

# Apache Iceberg テーブルをクエリする
<a name="querying-iceberg"></a>

Athena を利用して、Apache Iceberg テーブルに対して読み取り、タイムトラベル、書き込み、DDL クエリを実行できます。

[Apache Iceberg](https://iceberg.apache.org/) は、非常に大規模な分析データセット用のオープンテーブル形式です。Iceberg は、大量のファイルのコレクションをテーブルとして管理し、レコードレベルの挿入、更新、削除、タイムトラベルクエリなどの最新の分析データレイクオペレーションをサポートします。Iceberg の仕様では、スキーマやパーティションの進化などのテーブル進化をシームレスに行うことが可能であり、Amazon S3 での使用に最適化して設計されています。Iceberg は、同時書き込みシナリオでのデータの正確性の保証にも役立ちます。

Apache Iceberg の詳細については、[https://iceberg.apache.org/](https://iceberg.apache.org/) を参照してください。

## 考慮事項と制限事項
<a name="querying-iceberg-considerations-and-limitations"></a>

Iceberg テーブルに対する Athena のサポートには、次の考慮事項と制限があります。
+ **Iceberg バージョンのサポート** – Athena は Apache Iceberg バージョン 1.4.2 をサポートします。
+ **Lake Formation に登録されたテーブル** – Athena は現在、Lake Formation に登録された Iceberg テーブルでの DDL 操作をサポートしていません。
+ **情報スキーマに対するクエリ** – Iceberg テーブルの情報スキーマをクエリする場合、Athena は列メタデータの信頼できるソースとして S3 メタデータを使用します。つまり、列情報はカタログメタデータからではなく、基盤となる S3 ファイルから取得されます。この動作は、カタログメタデータが列情報の主要なソースである可能性がある他のテーブル形式とは異なります。
+ **AWS Glue カタログのテーブルのみ** – [オープンソースの Glue カタログの実装](https://iceberg.apache.org/docs/latest/aws/#glue-catalog)で定義されている仕様に基づく AWS Glue カタログに対して作成された Iceberg テーブルのみが Athena でサポートされています。
+ **AWS Glue によるテーブルロックのサポートのみ** – オープンソースの Glue カタログ実装はプラグインのカスタムロックをサポートしますが、Athena は AWS Glue オプティミスティックロックのみをサポートします。Athena を使用して他のロックが実装されている Iceberg テーブルを変更すると、データが失われ、トランザクションが中断する可能性があります。
+ **サポートされているファイル形式** – Athena エンジンバージョン 3 は、以下の Iceberg ファイル形式をサポートします。
  + Parquet
  + ORC
  + Avro
+ **Iceberg の制限付きメタデータ** – Lake Formation は Iceberg メタデータテーブルを評価しません。したがって、Iceberg メタデータテーブルは、ベーステーブルに Lake Formation の行もしくはセルフィルターが存在する場合、またはベーステーブル内のすべての列を表示するアクセス許可がない場合、制限されます。このような場合、`$partitions`、`$files`、`$manifests`、`$snapshots` Iceberg メタデータテーブルをクエリすると、失敗し、`AccessDeniedException` エラーが発生します。さらに、メタデータ列 `$path` には同じ Lake Formation の制限があり、クエリによって選択されると失敗します。Lake Formation フィルターに関係なく、他のすべてのメタデータテーブルをクエリできます。詳細については、「[メタデータテーブル](https://trino.io/docs/current/connector/iceberg.html#metadata-tables)」を参照してください。
+ **Iceberg v2 テーブル** – Athena は、Iceberg v2 テーブルを作成し、操作します。v1 テーブルと v2 テーブルの違いについては、Apache Iceberg ドキュメントの「[形式バージョンの変更](https://iceberg.apache.org/spec/#appendix-e-format-version-changes)」を参照してください。
+ **タイムゾーンのない時刻型の表示** – タイムゾーンのない時刻型とタイムスタンプ型は UTC で表示されます。時刻の列のフィルター式でタイムゾーンが指定されていない場合は、UTC が使用されます。
+ **タイムスタンプ関連のデータの精度** – Iceberg はタイムスタンプデータ型について、マイクロ秒精度をサポートしていますが、Athena は読み込みと書き込みの両方でタイムスタンプに対してミリ秒の精度しかサポートしていません。手動圧縮オペレーション中に書き換えられるデータについて、Athena は、時間関連の列でミリ秒の精度しか保持しません。
+ **サポートされていないオペレーション** - Iceberg テーブルに対して次の Athena オペレーションはサポートされていません。
  + [ALTER TABLE SET LOCATION](alter-table-set-location.md)
+ **ビュー** - [ビューを使用する](views.md) で説明されているように Athena ビューを作成する場合に `CREATE VIEW` を使用します。[Iceberg ビュー仕様](https://github.com/apache/iceberg/blob/master/format/view-spec.md)を使用してビューを作成することに興味がある場合は、[athena-feedback@amazon.com](mailto:athena-feedback@amazon.com) までご連絡ください。
+ **AWS Lake Formation でサポートされていない TTF 管理コマンド** — Lake Formation を使用して Apache Iceberg、Apache Hudi、Linux Foundation Delta Lake などのトランザクションテーブル形式 (TTF) の読み取りアクセス権限を管理できますが、Lake Formation を使用して `VACUUM`、`MERGE`、`UPDATE`、`OPTIMIZE` など、これらのテーブル形式を使用する操作の権限を管理することはできません。Lake Formation と Athena の統合の詳細については、「*AWS Lake Formation 開発者ガイド*」の「[Amazon Athena での AWS Lake Formation の使用](https://docs.aws.amazon.com/lake-formation/latest/dg/athena-lf.html)」を参照してください。
+ **ネストされたフィールドによるパーティション分割** — ネストされたフィールドによるパーティション分割はサポートされていません。*これを実行しようとすると、「 NOT\$1SUPPORTED: Partitioning by nested field is unsupported: column\$1name*.*nested\$1field\$1name*」(未サポート: ネストされたフィールドによるパーティション分割はサポートされていません: column\$1name.nested\$1field\$1name) というメッセージが表示されます。
+ **Amazon Glacier オブジェクトのスキップはサポートされていません** – Apache Iceberg テーブル内のオブジェクトが Amazon Glacier ストレージクラスにある場合、`read_restored_glacier_objects` テーブルプロパティを `false` に設定しても効果はありません。

  例えば、次のコマンドを実行したとします。

  ```
  ALTER TABLE table_name SET TBLPROPERTIES ('read_restored_glacier_objects' = 'false')
  ```

  Iceberg および Delta Lake テーブルでは、コマンドは「サポートされていないテーブルプロパティキー: read\$1restored\$1glacier\$1objects」というエラーを生成します。Hudi テーブルでは、`ALTER TABLE` コマンドはエラーを発生しませんが、Amazon Glacier オブジェクトはまだスキップされません。`ALTER TABLE` コマンドの後に `SELECT` クエリを実行すると、引き続きすべてのオブジェクトが返されます。

Athena でサポートしてほしい機能につきましては、[athena-feedback@amazon.com](mailto:athena-feedback@amazon.com) までご意見をお寄せください。

**Topics**
+ [考慮事項と制限事項](#querying-iceberg-considerations-and-limitations)
+ [Iceberg テーブルを作成する](querying-iceberg-creating-tables.md)
+ [Iceberg テーブルデータをクエリする](querying-iceberg-table-data.md)
+ [タイムトラベルとバージョントラベルのクエリを実行する](querying-iceberg-time-travel-and-version-travel-queries.md)
+ [Iceberg テーブルデータを更新する](querying-iceberg-updating-iceberg-table-data.md)
+ [Iceberg テーブルを管理する](querying-iceberg-managing-tables.md)
+ [Iceberg テーブルスキーマを進化させる](querying-iceberg-evolving-table-schema.md)
+ [Iceberg テーブルに対して他の DDL オペレーションを実行する](querying-iceberg-additional-operations.md)
+ [Iceberg テーブルを最適化する](querying-iceberg-data-optimization.md)
+ [AWS Glue Data Catalog マテリアライズドビューをクエリする](querying-iceberg-gdc-mv.md)
+ [Athena の Iceberg テーブルでサポートされているデータ型](querying-iceberg-supported-data-types.md)
+ [追加リソース](querying-iceberg-additional-resources.md)

# Iceberg テーブルを作成する
<a name="querying-iceberg-creating-tables"></a>

Athena で使用する Iceberg テーブルを作成するには、このページに記載されている `CREATE TABLE` ステートメントまたは AWS Glue クローラーを使用できます。

## CREATE TABLE ステートメントを使用する
<a name="querying-iceberg-creating-tables-query-editor"></a>

Athena は Iceberg v2 テーブルを作成します。v1 テーブルと v2 テーブルの違いについては、Apache Iceberg ドキュメントの「[形式バージョンの変更](https://iceberg.apache.org/spec/#appendix-e-format-version-changes)」を参照してください。

Athena `CREATE TABLE` は、データを含めずに Iceberg テーブルを作成します。テーブルで [Iceberg オープンソース Glue カタログ](https://iceberg.apache.org/docs/latest/aws/#glue-catalog)が使用されている場合は、Apache Spark などの外部システムからテーブルを直接クエリできます。外部テーブルを作成する必要はありません。

**警告**  
`CREATE EXTERNAL TABLE` を実行すると、「External keyword not supported for table type ICEBERG」(テーブルタイプ ICEBERG では外部キーワードはサポートされていません) というエラーメッセージが表示されます。

Athena から Iceberg テーブルを作成するには、次に示す構文の概要のように、テーブルプロパティの `'table_type'` を `TBLPROPERTIES` 句の `'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] )
```

Iceberg テーブルでクエリできるデータ型の詳細については、「[Athena の Iceberg テーブルでサポートされているデータ型](querying-iceberg-supported-data-types.md)」を参照してください。

### パーティションを使用する
<a name="querying-iceberg-partitioning"></a>

パーティションを持つ Iceberg テーブルを作成するには、`PARTITIONED BY` 構文を使用します。パーティション化に使用される列は、最初に列宣言で指定する必要があります。`PARTITIONED BY` 句には、列の型を含めることはできません。`CREATE TABLE` 構文に[パーティション変換](https://iceberg.apache.org/spec/#partition-transforms)を定義することもできます。パーティション化に複数の列を指定するには、次の例のように、列をカンマ (`,`) 文字で区切ります。

```
CREATE TABLE iceberg_table (id bigint, data string, category string)
  PARTITIONED BY (category, bucket(16, id))
  LOCATION 's3://amzn-s3-demo-bucket/your-folder/'
  TBLPROPERTIES ( 'table_type' = 'ICEBERG' )
```

次の表に、使用できるパーティション変換関数を示します。


****  

| 関数 | 説明 | サポートされている型 | 
| --- | --- | --- | 
| year(ts) | 年によるパーティション | date, timestamp | 
| month(ts) | 月によるパーティション | date, timestamp | 
| day(ts)  | 日によるパーティション | date, timestamp | 
| hour(ts) | 時間によるパーティション | timestamp | 
| bucket(N, col) | ハッシュ値 mod N のバケットによるパーティション これは、Hive テーブルのハッシュバケット作成と同じ概念です。 | int, long, decimal, date, timestamp, string, binary  | 
| truncate(L, col) | L に切り捨てられた値によるパーティション | int, long, decimal, string | 

Athena は Iceberg の隠しパーティション化をサポートしています。詳細については、「Apache Iceberg ドキュメント」の「[Iceberg's hidden partitioning](https://iceberg.apache.org/docs/latest/partitioning/#icebergs-hidden-partitioning)」(Iceberg の隠しパーティション化) を参照してください。

### テーブルプロパティを指定する
<a name="querying-iceberg-table-properties"></a>

このセクションでは、`CREATE TABLE` ステートメントの `TBLPROPERTIES` 句でキーと値のペアとして指定できるテーブルプロパティについて説明します。Athena では、Iceberg テーブルを作成または変更するために、テーブルプロパティで事前定義されたキーと値のペアのリストのみが使用できます。次の表に、指定可能なテーブルプロパティを示します。圧縮オプションの詳細については、このドキュメントの「[Iceberg テーブルを最適化する](querying-iceberg-data-optimization.md)」を参照してください。Athena による、特定のオープンソーステーブル設定プロパティのサポートをご希望の場合は、[athena-feedback@amazon.com](mailto:athena-feedback@amazon.com) までフィードバックをお送りください。

***format***


****  

|  |  | 
| --- |--- |
| 説明 | ファイルデータ形式 | 
| 使用できるプロパティ値 | サポートされるファイル形式と圧縮の組み合わせは、Athena エンジンのバージョンによって異なります。詳細については、「[Iceberg テーブル圧縮を使用する](compression-support-iceberg.md)」を参照してください。 | 
| デフォルト値: | parquet | 

***write\$1compression***


****  

|  |  | 
| --- |--- |
| 説明 | ファイル圧縮コーデック | 
| 使用できるプロパティ値 | サポートされるファイル形式と圧縮の組み合わせは、Athena エンジンのバージョンによって異なります。詳細については、「[Iceberg テーブル圧縮を使用する](compression-support-iceberg.md)」を参照してください。 | 
| デフォルト値: |  デフォルトの書き込み圧縮は Athena エンジンのバージョンによって異なります。詳細については、「[Iceberg テーブル圧縮を使用する](compression-support-iceberg.md)」を参照してください。  | 

***optimize\$1rewrite\$1data\$1file\$1threshold***


****  

|  |  | 
| --- |--- |
| 説明 | データ最適化固有の設定。最適化が必要なデータファイルの数が指定されたしきい値より少ない場合、データファイルは書き換えられません。これにより、蓄積するデータファイルの数を増やしてターゲットサイズに近いファイルを生成し、不要な計算をスキップしてコストを削減できます。 | 
| 使用できるプロパティ値 | 正数。50 未満にする必要があります。 | 
| デフォルト値: | 5 | 

***optimize\$1rewrite\$1delete\$1file\$1threshold***


****  

|  |  | 
| --- |--- |
| 説明 | データ最適化固有の設定。データファイルに関連付けられた削除ファイルの数がしきい値より少ない場合、データファイルは書き換えられません。これにより、データファイルごとに蓄積する削除ファイルの数を増やしてコストを削減できます。 | 
| 使用できるプロパティ値 | 正数。50 未満にする必要があります。 | 
| デフォルト値: | 2 | 

***vacuum\$1min\$1snapshots\$1to\$1keep***


****  

|  |  | 
| --- |--- |
| 説明 |  テーブルのメインブランチに保持するスナップショットの最小数。 この値は `vacuum_max_snapshot_age_seconds` プロパティよりも優先されます。残りの最小スナップショット数が `vacuum_max_snapshot_age_seconds` で指定した経過日数よりも古い場合、そのスナップショットは保持され、`vacuum_max_snapshot_age_seconds` の値は無視されます。  | 
| 使用できるプロパティ値 | 正数。 | 
| デフォルト値: | 1 | 

***vacuum\$1max\$1snapshot\$1age\$1seconds***


****  

|  |  | 
| --- |--- |
| 説明 | メインブランチに保持するスナップショットの最大保存期間。vacuum\$1min\$1snapshots\$1to\$1keep で指定された残りの最小スナップショットが指定された経過日数よりも古い場合、この値は無視されます。このテーブル動作プロパティは、Apache Iceberg 設定の history.expire.max-snapshot-age-ms プロパティに対応しています。 | 
| 使用できるプロパティ値 | 正数。 | 
| デフォルト値: | 432,000 秒 (5 日間) | 

***vacuum\$1max\$1metadata\$1files\$1to\$1keep***


****  

|  |  | 
| --- |--- |
| 説明 | 以前のメタデータファイルで、テーブルのメインブランチに保持するものの最大数。 | 
| 使用できるプロパティ値 | 正数。 | 
| デフォルト値: | 100 | 

***write\$1data\$1path\$1enabled***


****  

|  |  | 
| --- |--- |
| 説明 | true に設定すると、Iceberg テーブルは廃止された write.object-storage.path プロパティではなく write.data.path プロパティで作成されます。このオプションを使用して、廃止されたプロパティをサポートしなくなった Iceberg 1.9.0 以降との互換性を確保します。 | 
| 使用できるプロパティ値 | true, false | 
| デフォルト値: | false | 

### CREATE TABLE ステートメントの例
<a name="querying-iceberg-example-create-table-statement"></a>

次の例では、3 つの列を持つ Iceberg テーブルを作成します。

```
CREATE TABLE iceberg_table (
  id int,
  data string,
  category string) 
PARTITIONED BY (category, bucket(16,id)) 
LOCATION 's3://amzn-s3-demo-bucket/iceberg-folder' 
TBLPROPERTIES (
  'table_type'='ICEBERG',
  'format'='parquet',
  'write_compression'='snappy',
  'optimize_rewrite_delete_file_threshold'='10'
)
```

## CREATE TABLE AS SELECT (CTAS) を使用する
<a name="querying-iceberg-creating-tables-ctas"></a>

この `CREATE TABLE AS` ステートメントを使用して Iceberg テーブルを作成する詳細については、[CTAS テーブルのプロパティ](create-table-as.md#ctas-table-properties) セクションに特に注目して「[CREATE TABLE AS](create-table-as.md)」を参照してください。

## AWS Glue クローラーを使用する
<a name="querying-iceberg-creating-tables-crawler"></a>

AWS Glue クローラーを使用すると、Iceberg テーブルを AWS Glue Data Catalog に自動的に登録できます。別の Iceberg カタログから移行する場合は、AWS Glue クローラーを作成してスケジュールし、Iceberg テーブルが配置されている Amazon S3 パスを指定できます。AWS Glue クローラーがトラバースできる Amazon S3 パスの最大の階層の深さを指定できます。クローラーをスケジュールすると、AWS Glue クローラーは実行するたびにスキーマ情報を抽出し、スキーマの変更で AWS Glue Data Catalog を更新します。AWS Glue クローラーは、複数のスナップショット間でスキーマのマージをサポートし、AWS Glue Data Catalog 内の最新のメタデータファイルの場所を更新します。詳細については、「[AWS Glue のデータカタログとクローラー](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)」を参照してください。

# Iceberg テーブルデータをクエリする
<a name="querying-iceberg-table-data"></a>

Iceberg データセットをクエリするには、次のような標準の `SELECT` ステートメントを使用します。クエリは Apache Iceberg [format v2 spec](https://iceberg.apache.org/spec/#format-versioning) に従い、位置と等価削除の両方の merge-on-read を実行します。

```
SELECT * FROM [db_name.]table_name [WHERE predicate]
```

クエリ時間を最適化するために、すべての述語がデータが存在する場所にプッシュダウンされます。

タイムトラベルとバージョントラベルのクエリについては、「[タイムトラベルとバージョントラベルのクエリを実行する](querying-iceberg-time-travel-and-version-travel-queries.md)」を参照してください。

## Iceberg テーブルでビューを作成およびクエリする
<a name="querying-iceberg-views"></a>

Iceberg テーブルで Athena ビューを作成してクエリするには、[ビューを使用する](views.md) で説明されている `CREATE VIEW` ビューを使用します。

例:

```
CREATE VIEW view1 AS SELECT * FROM iceberg_table
```

```
SELECT * FROM view1 
```

[Iceberg ビュー仕様](https://github.com/apache/iceberg/blob/master/format/view-spec.md)を使用してビューを作成することに興味がある場合は、[athena-feedback@amazon.com](mailto:athena-feedback@amazon.com) までご連絡ください。

## Iceberg テーブルデータをクエリする
<a name="querying-iceberg-table-metadata"></a>

`SELECT` クエリでは、*table\$1name* の後に次のプロパティを使用して Iceberg テーブルメタデータをクエリできます。
+ **\$1files** — テーブルの現在のデータファイルを表示します。
+ **\$1manifests** — テーブルの現在のファイルマニフェストを表示します。
+ **\$1history** — テーブルの履歴を表示します。
+ **\$1partitions** — テーブルの現在のパーティションを表示します。
+ **\$1snapshots** — テーブルのスナップショットを表示します。
+ **\$1refs** — テーブルのリファレンスを表示します。

### 例
<a name="querying-iceberg-table-metadata-syntax"></a>

次のステートメントは、Iceberg テーブルのファイルを一覧表示します。

```
SELECT * FROM "dbname"."tablename$files"
```

次のステートメントは、Iceberg テーブルのマニフェストを一覧表示します。

```
SELECT * FROM "dbname"."tablename$manifests" 
```

次のステートメントは、Iceberg テーブルの履歴を一覧表示します。

```
SELECT * FROM "dbname"."tablename$history"
```

以下は、Iceberg テーブルのパーティションを表示する例です。

```
SELECT * FROM "dbname"."tablename$partitions" 
```

以下は、Iceberg テーブルのスナップショットをリストする例です。

```
SELECT * FROM "dbname"."tablename$snapshots" 
```

以下は、Iceberg テーブルのリファレンスを表示する例です。

```
SELECT * FROM "dbname"."tablename$refs" 
```

## Lake Formation のきめ細かなアクセスコントロールを使用する
<a name="querying-iceberg-working-with-lf-fgac"></a>

Athena エンジンのバージョン 3 は、列レベルと行レベルのセキュリティアクセス制御を含む、Iceberg テーブルによる Lake Formation のきめ細かいアクセス制御をサポートしています。このアクセス制御は、タイムトラベルクエリやスキーマの進化を行ったテーブルを使用して機能します。詳細については、「[Lake Formation のきめ細かなアクセス制御と Athena ワークグループ](lf-athena-limitations.md#lf-athena-limitations-fine-grained-access-control)」を参照してください。

Athena 以外で Iceberg テーブルを作成した場合は、[Apache Iceberg SDK](https://iceberg.apache.org/releases/) バージョン 0.13.0 以降を使用して、Iceberg テーブルの列情報が AWS Glue Data Catalog に入力されるようにします。AWS Glue のIceberg テーブルに列情報が含まれていない場合は、Athena [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) ステートメントまたは最新の Iceberg SDK を使用してテーブルを修正し、AWS Glue の列情報を更新できます。

# タイムトラベルとバージョントラベルのクエリを実行する
<a name="querying-iceberg-time-travel-and-version-travel-queries"></a>

各 Apache Iceberg テーブルは、それが含まれている Simple Storage Service (Amazon S3) オブジェクトのバージョン管理されたマニフェストを維持します。以前のバージョンのマニフェストを、タイムトラベルおよびバージョントラベルのクエリに使用できます。

Athena でのタイムトラベルクエリは、Amazon S3 での指定された日付と時刻における、一貫したスナップショットからの履歴データをクエリします。Athena でのバージョントラベルクエリは、Amazon S3 において指定されたスナップショット ID に関する履歴データをクエリします。

## タイムトラベルクエリ
<a name="querying-iceberg-time-travel-queries"></a>

タイムトラベルクエリを実行するには、次の例のように、`SELECT` ステートメントのテーブル名の後に `FOR TIMESTAMP AS OF timestamp` を使用します。

```
SELECT * FROM iceberg_table FOR TIMESTAMP AS OF timestamp
```

タイムトラベルで指定されるシステム時刻は、タイムスタンプか、タイムゾーン付きタイムスタンプのいずれかです。これを指定しない場合、Athena は値を UTC 時間のタイムスタンプと見なします。

次のタイムトラベルクエリの例では、指定された日時の CloudTrail データを選択します。

```
SELECT * FROM iceberg_table FOR TIMESTAMP AS OF TIMESTAMP '2020-01-01 10:00:00 UTC'
```

```
SELECT * FROM iceberg_table FOR TIMESTAMP AS OF (current_timestamp - interval '1' day)
```

## バージョントラベルクエリ
<a name="querying-iceberg-version-travel-queries"></a>

バージョントラベルクエリを実行する (つまり、指定したバージョンで一貫したスナップショットを表示する) には、次の例のように、`SELECT` ステートメントのテーブル名の後に `FOR VERSION AS OF version` を使用します。

```
SELECT * FROM [db_name.]table_name FOR VERSION AS OF version         
```

*version* パラメータは Iceberg テーブルバージョンに関連付けられている `bigint` スナップショット ID です。

次の例では、バージョントラベルクエリが、指定したバージョンのデータを選択しています。

```
SELECT * FROM iceberg_table FOR VERSION AS OF 949530903748831860
```

**注記**  
Athena エンジンのバージョン 2 で `FOR SYSTEM_TIME AS OF` および `FOR SYSTEM_VERSION AS OF` の句は、Athena エンジンバージョン 3 の `FOR TIMESTAMP AS OF` および `FOR VERSION AS OF` の句に置き換えられました。

### スナップショット ID を取得する
<a name="querying-iceberg-table-snapshot-id"></a>

以下の例にあるように、Iceberg が提供する Java [SnapshotUtil](https://iceberg.apache.org/javadoc/1.6.0/org/apache/iceberg/util/SnapshotUtil.html) クラスを使用して、Iceberg スナップショット ID を取得することができます。

```
import org.apache.iceberg.Table;
import org.apache.iceberg.aws.glue.GlueCatalog;
import org.apache.iceberg.catalog.TableIdentifier;
import org.apache.iceberg.util.SnapshotUtil;

import java.text.SimpleDateFormat;
import java.util.Date;

Catalog catalog = new GlueCatalog();

Map<String, String> properties = new HashMap<String, String>();
properties.put("warehouse", "s3://amzn-s3-demo-bucket/my-folder");
catalog.initialize("my_catalog", properties);

Date date = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss").parse("2022/01/01 00:00:00");
long millis = date.getTime();

TableIdentifier name = TableIdentifier.of("db", "table");
Table table = catalog.loadTable(name);
long oldestSnapshotIdAfter2022 = SnapshotUtil.oldestAncestorAfter(table, millis);
```

## タイムおよびバージョントラベルを組み合わせる
<a name="querying-iceberg-combining-time-and-version-travel"></a>

次の例のように、同じクエリでタイムトラベルとバージョントラベルの構文を使用することで、時間とバージョニングに対し異なる条件を指定できます。

```
SELECT table1.*, table2.* FROM 
  [db_name.]table_name FOR TIMESTAMP AS OF (current_timestamp - interval '1' day) AS table1 
  FULL JOIN 
  [db_name.]table_name FOR VERSION AS OF 5487432386996890161 AS table2 
  ON table1.ts = table2.ts 
  WHERE (table1.id IS NULL OR table2.id IS NULL)
```

# Iceberg テーブルデータを更新する
<a name="querying-iceberg-updating-iceberg-table-data"></a>

`INSERT`、`UPDATE`、`DELETE` クエリを使用して、Athena で Iceberg テーブルデータを直接管理できます。データ管理トランザクションごとに新しいスナップショットが生成され、タイムトラベルを使用してクエリできます。`UPDATE` および `DELETE` ステートメントは、Iceberg 形式 v2 の行レベル [position delete](https://iceberg.apache.org/spec/#position-delete-files) 仕様に従い、スナップショットを分離します。

**注記**  
Athena SQL は現在、コピーオンライトアプローチをサポートしていません。`UPDATE`、`MERGE INTO`、および `DELETE FROM` オペレーションでは、指定したテーブルプロパティに関係なく、位置削除で常にマージオンリードアプローチを使用します。`write.update.mode`、`write.merge.mode`、`write.delete.mode` などのテーブルプロパティを設定してコピーオンライトを使用する場合、Athena はそれらを無視してマージオンリードを引き続き使用するため、クエリは失敗しません。

次のコマンドを使用して、Iceberg テーブルでデータ管理オペレーションを実行します。

**Topics**
+ [INSERT INTO](querying-iceberg-insert-into.md)
+ [DELETE](querying-iceberg-delete.md)
+ [UPDATE](querying-iceberg-update.md)
+ [MERGE INTO](querying-iceberg-merge-into.md)

# INSERT INTO
<a name="querying-iceberg-insert-into"></a>

Iceberg テーブルにデータを挿入します。Athena Iceberg `INSERT INTO` は、現在の `INSERT INTO` が外部 Hive テーブルに対してクエリする場合と同じく、スキャンしたデータ量の分だけ課金されます。Iceberg テーブルにデータを挿入するには、次の構文を使用します。*query* は `VALUES (val1, val2, ...)` または `SELECT (col1, col2, …) FROM [db_name.]table_name WHERE predicate` のいずれかです。SQL 構文とセマンティクスの詳細については、「[INSERT INTO](insert-into.md)」を参照してください。

```
INSERT INTO [db_name.]table_name [(col1, col2, …)] query
```

次の例では、テーブル `iceberg_table` に値を挿入します。

```
INSERT INTO iceberg_table VALUES (1,'a','c1')
```

```
INSERT INTO iceberg_table (col1, col2, ...) VALUES (val1, val2, ...)
```

```
INSERT INTO iceberg_table SELECT * FROM another_table
```

# DELETE
<a name="querying-iceberg-delete"></a>

Athena Iceberg `DELETE` は、Iceberg 位置削除ファイルをテーブルに書き込みます。これは、読み込み時マージ削除と呼ばれます。コピーオンライト削除とは対照的に、ファイルデータを書き換えないため、読み込み時マージ削除のほうが効率的です。Athena は、Iceberg データを読み込むときに、Iceberg 位置削除ファイルをデータファイルとマージして、テーブルの最新のビューを生成します。こうした位置削除ファイルを削除するには、[REWRITE DATA 圧縮アクション](querying-iceberg-data-optimization.md#querying-iceberg-data-optimization-rewrite-data-action)を実行します。`DELETE` オペレーションは、スキャンしたデータ量の分だけ課金されます。構文については、「[DELETE](delete-statement.md)」を参照してください。

次の例では、`category` の値が `c3` の `iceberg_table` から行を削除します。

```
DELETE FROM iceberg_table WHERE category='c3'
```

# UPDATE
<a name="querying-iceberg-update"></a>

Athena Iceberg `UPDATE` は、Iceberg 位置削除ファイルと新しく更新された行を同じトランザクション内のデータファイルとして書き込みます。`UPDATE` は、`INSERT INTO` と `DELETE` を組み合わせたものと考えることができます。`UPDATE` オペレーションは、スキャンしたデータ量の分だけ課金されます。構文については、「[UPDATE](update-statement.md)」を参照してください。

次の例では、テーブル `iceberg_table` の指定された値を更新します。

```
UPDATE iceberg_table SET category='c2' WHERE category='c1'
```

# MERGE INTO
<a name="querying-iceberg-merge-into"></a>

条件付きで Iceberg テーブルに行を更新、削除、または挿入します。単一のステートメントで、更新、削除、挿入のアクションを組み合わせることができます。構文については、「[MERGE INTO](merge-into-statement.md)」を参照してください。

**注記**  
`MERGE INTO` はトランザクションで、Athena エンジンバージョン 3 の Apache Iceberg テーブルでのみサポートされています。

次の例では、ソーステーブル `s` にあるテーブル `t` からすべての顧客を削除します。

```
MERGE INTO accounts t USING monthly_accounts_update s
ON t.customer = s.customer
WHEN MATCHED
THEN DELETE
```

次の例では、ソーステーブル `s` の顧客情報でターゲットテーブル `t` を更新します。テーブル `s` 内の顧客の行が一致する顧客行が `t` にある場合、この例ではテーブル t の購入をインクリメントします。テーブル `t` がテーブル `s` 内の顧客の行と一致しない場合、この例では、顧客の行をテーブル `s` からテーブル `t` に挿入します。

```
MERGE INTO accounts t USING monthly_accounts_update s
    ON (t.customer = s.customer)
    WHEN MATCHED
        THEN UPDATE SET purchases = s.purchases + t.purchases
    WHEN NOT MATCHED
        THEN INSERT (customer, purchases, address)
              VALUES(s.customer, s.purchases, s.address)
```

次の例では、ソーステーブル `s` の情報でターゲットテーブル `t` を条件付きで更新します。この例では、送信元アドレスが Centreville である一致するターゲット行をすべて削除します。一致するすべての行について、この例では送信元購入を追加し、ターゲットアドレスを送信元アドレスに設定します。ターゲットテーブルに一致するものがない場合、この例では送信元テーブルから行を挿入します。

```
MERGE INTO accounts t USING monthly_accounts_update s
    ON (t.customer = s.customer)
    WHEN MATCHED AND s.address = 'Centreville'
        THEN DELETE
    WHEN MATCHED
        THEN UPDATE
            SET purchases = s.purchases + t.purchases, address = s.address
    WHEN NOT MATCHED
        THEN INSERT (customer, purchases, address)
              VALUES(s.customer, s.purchases, s.address)
```

# Iceberg テーブルを管理する
<a name="querying-iceberg-managing-tables"></a>

Athena は、Iceberg テーブルに対して次のテーブル DDL オペレーションをサポートしています。

**Topics**
+ [ALTER TABLE RENAME](querying-iceberg-alter-table-rename.md)
+ [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md)
+ [ALTER TABLE UNSET TBLPROPERTIES](querying-iceberg-alter-table-unset-properties.md)
+ [DESCRIBE](querying-iceberg-describe-table.md)
+ [DROP TABLE](querying-iceberg-drop-table.md)
+ [SHOW CREATE TABLE](querying-iceberg-show-create-table.md)
+ [SHOW TBLPROPERTIES](querying-iceberg-show-table-properties.md)

# ALTER TABLE RENAME
<a name="querying-iceberg-alter-table-rename"></a>

テーブル名を変更します。

Iceberg テーブルのテーブルメタデータが Simple Storage Service (Amazon S3) に保存されるため、基礎となるテーブル情報に影響を与えることなく、Iceberg マネージドテーブルのデータベース名とテーブル名を更新できます。

## 概要
<a name="querying-iceberg-alter-table-rename-synopsis"></a>

```
ALTER TABLE [db_name.]table_name RENAME TO [new_db_name.]new_table_name
```

## 例
<a name="querying-iceberg-alter-table-rename-example"></a>

```
ALTER TABLE my_db.my_table RENAME TO my_db2.my_table2
```

# ALTER TABLE SET TBLPROPERTIES
<a name="querying-iceberg-alter-table-set-properties"></a>

プロパティを Iceberg テーブルに追加し、割り当てられた値を設定します。

[Iceberg 仕様](https://iceberg.apache.org/#spec/#table-metadata-fields)に従って、テーブルプロパティは、AWS Glue ではなく、Iceberg テーブルメタデータファイルに保存されます。Athena はカスタムテーブルプロパティを受け入れません。使用できるキーと値のペアついては、「[テーブルプロパティを指定する](querying-iceberg-creating-tables.md#querying-iceberg-table-properties)」セクションを参照してください。`ALTER TABLE SET TBLPROPERTIES` および `ALTER TABLE UNSET TBLPROPERTIES` を使用して、`write.data.path` および `write.object-storage.path` Iceberg テーブルのプロパティを設定または削除することもできます。Athena による、特定のオープンソーステーブル設定プロパティのサポートをご希望の場合は、[athena-feedback@amazon.com](mailto:athena-feedback@amazon.com) までフィードバックをお送りください。

## 概要
<a name="querying-iceberg-alter-table-set-properties-synopsis"></a>

```
ALTER TABLE [db_name.]table_name SET TBLPROPERTIES ('property_name' = 'property_value' [ , ... ])
```

## 例
<a name="querying-iceberg-alter-table-set-properties-example"></a>

```
ALTER TABLE iceberg_table SET TBLPROPERTIES (
  'format'='parquet',
  'write_compression'='snappy',
  'optimize_rewrite_delete_file_threshold'='10'
)
```

次の例では、既存の Iceberg テーブルに `write.data.path` プロパティを設定します。

```
ALTER TABLE iceberg_table SET TBLPROPERTIES (
  'write.data.path'='s3://amzn-s3-demo-bucket/your-folder/data'
)
```

# ALTER TABLE UNSET TBLPROPERTIES
<a name="querying-iceberg-alter-table-unset-properties"></a>

Iceberg テーブルから既存のプロパティを削除します。

## 概要
<a name="querying-iceberg-alter-table-unset-properties-synopsis"></a>

```
ALTER TABLE [db_name.]table_name UNSET TBLPROPERTIES ('property_name' [ , ... ])
```

## 例
<a name="querying-iceberg-alter-table-unset-properties-example"></a>

```
ALTER TABLE iceberg_table UNSET TBLPROPERTIES ('write_compression')
```

次の例では、Iceberg テーブルから `write.data.path` プロパティを削除します。

```
ALTER TABLE iceberg_table UNSET TBLPROPERTIES ('write.data.path')
```

# DESCRIBE
<a name="querying-iceberg-describe-table"></a>

テーブル情報の説明です。

## 概要
<a name="querying-iceberg-describe-table-synopsis"></a>

```
DESCRIBE [FORMATTED] [db_name.]table_name
```

`FORMATTED` オプションを指定すると、テーブルの場所やプロパティなどの追加情報が出力に表示されます。

## 例
<a name="querying-iceberg-describe-table-example"></a>

```
DESCRIBE iceberg_table
```

# DROP TABLE
<a name="querying-iceberg-drop-table"></a>

Iceberg テーブルを削除します。

**警告**  
Athena では Iceberg テーブルがマネージドテーブルと見なされるため、Iceberg テーブルを削除すると、テーブル内のデータもすべて削除されます。

## 概要
<a name="querying-iceberg-drop-table-synopsis"></a>

```
DROP TABLE [IF EXISTS] [db_name.]table_name
```

## 例
<a name="querying-iceberg-drop-table-example"></a>

```
DROP TABLE iceberg_table
```

# SHOW CREATE TABLE
<a name="querying-iceberg-show-create-table"></a>

`CREATE TABLE` DDL ステートメントを表示します。Athena で Iceberg テーブルを再作成するために使用できます。Athena がテーブル構造を再現できない場合 (たとえば、テーブルにカスタムテーブルプロパティが指定されているため)、「UNSUPPORTED」(サポートされていません) というエラーがスローされます。

## 概要
<a name="querying-iceberg-show-create-table-synopsis"></a>

```
SHOW CREATE TABLE [db_name.]table_name
```

## 例
<a name="querying-iceberg-show-create-table-example"></a>

```
SHOW CREATE TABLE iceberg_table
```

# SHOW TBLPROPERTIES
<a name="querying-iceberg-show-table-properties"></a>

Iceberg テーブルのテーブルプロパティを 1 つ以上表示します。Athena でサポートされているテーブルプロパティのみが表示されます。

## 概要
<a name="querying-iceberg-show-table-properties-synopsis"></a>

```
SHOW TBLPROPERTIES [db_name.]table_name [('property_name')]
```

## 例
<a name="querying-iceberg-show-table-properties-example"></a>

```
SHOW TBLPROPERTIES iceberg_table
```

# Iceberg テーブルスキーマを進化させる
<a name="querying-iceberg-evolving-table-schema"></a>

Iceberg スキーマの更新は、メタデータのみの変更です。スキーマの更新を実行しても、データファイルは変更されません。

Iceberg 形式では、次のスキーマ進化の変更がサポートされています。
+ **Add** – 新しい列をテーブルまたはネストされた `struct` に追加します。
+ **Drop** – 既存の列をテーブルまたはネストされた `struct` から削除します。
+ **Rename** – 既存の列またはネストされた `struct` のフィールドの名前を変更します。
+ **順序変更** - 列の順序を変更します。
+  **型昇格** – 列、`struct` フィールド、`map` キー、`map` 値、または `list` 要素の型を広げます。Iceberg テーブルでは、現時点で次のケースがサポートされています。
  + 整数から大きな整数
  + 浮動小数点から倍精度浮動小数点
  + 10 進数型の精度を上げる

このセクションの DDL ステートメントを使用して Iceberg テーブルスキーマを変更できます。

**Topics**
+ [ALTER TABLE ADD COLUMNS](querying-iceberg-alter-table-add-columns.md)
+ [ALTER TABLE DROP COLUMN](querying-iceberg-alter-table-drop-column.md)
+ [ALTER TABLE CHANGE COLUMN](querying-iceberg-alter-table-change-column.md)
+ [SHOW COLUMNS](querying-iceberg-show-columns.md)

# ALTER TABLE ADD COLUMNS
<a name="querying-iceberg-alter-table-add-columns"></a>

既存の Iceberg テーブルに 1 つまたは複数の列を追加します。

## 概要
<a name="querying-iceberg-alter-table-add-columns-synopsis"></a>

```
ALTER TABLE [db_name.]table_name ADD COLUMNS (col_name data_type [,...])
```

## 例
<a name="querying-iceberg-alter-table-add-columns-example"></a>

次の例では、`string` 型の `comment` 列を Iceberg テーブルに追加しています。

```
ALTER TABLE iceberg_table ADD COLUMNS (comment string)
```

次の例では、`struct` 型の `point` 列を Iceberg テーブルに追加しています。

```
ALTER TABLE iceberg_table 
ADD COLUMNS (point struct<x: double, y: double>)
```

次の例では、構造体の配列である `points` 列を Iceberg テーブルに追加しています。

```
ALTER TABLE iceberg_table 
ADD COLUMNS (points array<struct<x: double, y: double>>)
```

# ALTER TABLE DROP COLUMN
<a name="querying-iceberg-alter-table-drop-column"></a>

既存の Iceberg テーブルから列を削除します。

## 概要
<a name="querying-iceberg-alter-table-drop-column-synopsis"></a>

```
ALTER TABLE [db_name.]table_name DROP COLUMN col_name
```

## 例
<a name="querying-iceberg-alter-table-drop-column-example"></a>

```
ALTER TABLE iceberg_table DROP COLUMN userid
```

# ALTER TABLE CHANGE COLUMN
<a name="querying-iceberg-alter-table-change-column"></a>

Iceberg テーブルの列の名前、タイプ、順序、またはコメントを変更します。

**注記**  
`ALTER TABLE REPLACE COLUMNS` はサポートされていません。`REPLACE COLUMNS` は、すべての列を削除してから新しい列を追加するため、Iceberg ではサポートされていません。`CHANGE COLUMN` は、スキーマ進化に推奨される構文です。

## 概要
<a name="querying-iceberg-alter-table-change-column-synopsis"></a>

```
ALTER TABLE [db_name.]table_name
  CHANGE [COLUMN] col_old_name col_new_name column_type 
  [COMMENT col_comment] [FIRST|AFTER column_name]
```

## 例
<a name="querying-iceberg-alter-table-change-column-example"></a>

```
ALTER TABLE iceberg_table CHANGE comment blog_comment string AFTER id
```

# SHOW COLUMNS
<a name="querying-iceberg-show-columns"></a>

テーブル内の列を表示します。

## 概要
<a name="querying-iceberg-show-columns-synopsis"></a>

```
SHOW COLUMNS (FROM|IN) [db_name.]table_name
```

## 例
<a name="querying-iceberg-alter-table-change-column-example"></a>

```
SHOW COLUMNS FROM iceberg_table
```

# Iceberg テーブルに対して他の DDL オペレーションを実行する
<a name="querying-iceberg-additional-operations"></a>

[Iceberg テーブルスキーマを進化させる](querying-iceberg-evolving-table-schema.md) で説明されているスキーマ進化オペレーションに加えて、Athena の Apache Iceberg テーブルに対して次の DDL オペレーションを実行することもできます。

## データベースレベルのオペレーション
<a name="querying-iceberg-additional-operations-database-level-operations"></a>

`CASCADE` オプションを指定して [DROP DATABASE](drop-database.md) を使用すると、Iceberg テーブルデータも削除されます。次の DDL オペレーションは、Iceberg テーブルには影響しません。
+ [CREATE DATABASE](create-database.md)
+ [ALTER DATABASE SET DBPROPERTIES](alter-database-set-dbproperties.md)
+ [SHOW DATABASES](show-databases.md)
+ [SHOW TABLES](show-tables.md)
+ [SHOW VIEWS](show-views.md)

## パーティション関連のオペレーション
<a name="querying-iceberg-additional-operations-partition-related-operations"></a>

Iceberg テーブルでは[隠しパーティション化](https://iceberg.apache.org/docs/latest/partitioning/#icebergs-hidden-partitioning)が使用されるため、物理パーティションを直接操作する必要はありません。そのため、Athena の Iceberg テーブルでは、次のパーティション関連の DDL オペレーションがサポートされていません。
+ [SHOW PARTITIONS](show-partitions.md)
+ [ALTER TABLE ADD PARTITION](alter-table-add-partition.md)
+ [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md)
+ [ALTER TABLE RENAME PARTITION](alter-table-rename-partition.md)

Athena での Iceberg [パーティションの進化](https://iceberg.apache.org/docs/latest/evolution/#partition-evolution)についてご意見がございましたら、[athena-feedback@amazon.com](mailto:athena-feedback@amazon.com) までお寄せください。

## Iceberg テーブルをアンロードする
<a name="querying-iceberg-additional-operations-unload-iceberg-table"></a>

Iceberg テーブルは、Simple Storage Service (Amazon S3) のフォルダ内のファイルにアンロードできます。詳細については、「[UNLOAD](unload.md)」を参照してください。

## MSCK REPAIR
<a name="querying-iceberg-additional-operations-msck-repair"></a>

Iceberg テーブルではテーブルレイアウト情報が追跡されるため、Hive テーブルの場合のような [MSCK REPAIR TABLE](msck-repair-table.md) の実行は必要なく、サポートもされていません。

# Iceberg テーブルを最適化する
<a name="querying-iceberg-data-optimization"></a>

Athena には、Apache Iceberg テーブルのクエリパフォーマンスを向上させるための最適化機能がいくつか用意されています。データが蓄積されると、ファイル処理のオーバーヘッドが増加し、Iceberg 削除ファイルに保存されている行レベルの削除を適用する際の計算コストが高くなるため、クエリの効率が低下する可能性があります。これらの課題に対応するため、Athena はテーブル構造を最適化するための手動の圧縮演算子と真空演算子をサポートしています。また、Athena は Iceberg 統計と連携すると、クエリ実行中の正確なデータプルーニングを目的としたコストベースのクエリ最適化と Parquet 列インデックス作成も実行できます。これらの機能は連携して、クエリの実行時間を短縮し、データスキャンを最小限に抑え、コストを削減します。このトピックでは、これらの最適化機能を使用して Iceberg テーブルで高性能クエリを維持する方法について説明します。

## OPTIMIZE
<a name="querying-iceberg-data-optimization-rewrite-data-action"></a>

`OPTIMIZE table REWRITE DATA` 圧縮アクションは、関連する削除ファイルのサイズと数に基づいて、データファイルをより最適化されたレイアウトに書き換えます。構文とテーブルプロパティの詳細については、「[OPTIMIZE](optimize-statement.md)」を参照してください。

### 例
<a name="querying-iceberg-data-optimization-example"></a>

次の例では、削除ファイルをデータファイルにマージし、ターゲットファイルサイズに近いファイルを生成します。ここでは、`category` の値が `c1` です。

```
OPTIMIZE iceberg_table REWRITE DATA USING BIN_PACK
  WHERE category = 'c1'
```

## VACUUM
<a name="querying-iceberg-vacuum"></a>

`VACUUM` は[スナップショットの有効期限切れ](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots)と[孤立ファイルの削除](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files)を行います。これらのアクションにより、メタデータのサイズが小さくなり、現在のテーブル状態にないファイルのうち、テーブル用に指定された保持期間よりも古いファイルが削除されます。構文の詳細については、「[VACUUM](vacuum-statement.md)」を参照してください。

### 例
<a name="querying-iceberg-vacuum-example"></a>

次の例では、テーブルプロパティを使用して過去 3 日間のデータを保持するようにテーブル `iceberg_table` を設定し、`VACUUM` を使用して古いスナップショットを期限切れにし、孤立ファイルをテーブルから削除します。

```
ALTER TABLE iceberg_table SET TBLPROPERTIES (
  'vacuum_max_snapshot_age_seconds'='259200'
)

VACUUM iceberg_table
```

## Iceberg テーブル統計を使用する
<a name="querying-iceberg-data-optimization-statistics"></a>

Athena のコストベースのオプティマイザは Iceberg 統計を使用して最適なクエリプランを作成します。Iceberg テーブルの統計が生成されると、Athena はこの情報を自動的に使用して、結合の順序、フィルター、集約動作に関するインテリジェントな決定を行い、それによって多くの場合、クエリのパフォーマンスを向上させ、コストを削減します。

S3 Tables を使用すると、Iceberg 統計はデフォルトで有効になります。他の Iceberg テーブルの場合、Athena はテーブルプロパティ `use_iceberg_statistics` を使用して、コストベースの最適化に統計を活用するかどうかを決定します。開始するには、「*AWS Glue ユーザーガイド*」の「[列統計を使用したクエリパフォーマンスの最適化](https://docs.aws.amazon.com//glue/latest/dg/column-statistics.html)」を参照するか、[Athena コンソール](https://docs.aws.amazon.com/athena/latest/ug/cost-based-optimizer.html)を使用して Iceberg テーブルでオンデマンド統計を生成します。

## Parquet 列インデックス作成を使用する
<a name="querying-iceberg-data-optimization-parquet-column-indexing"></a>

Parquet 列インデックス作成を使用すると、Athena は行グループレベルの統計に加えてページレベルの最小/最大統計を活用することで、クエリの実行中により正確なデータプルーニングを実行できます。これにより、Athena は行グループ内の不要なページをスキップできるようになり、スキャンされるデータ量が大幅に削減され、クエリのパフォーマンスが向上します。ソートされた列に選択的フィルター述語があるクエリに最適です。Athena が Amazon S3 から読み取る必要があるデータの量を減らすと同時に、実行時間とデータスキャン効率の両方を向上させます。

基盤となる Parquet ファイルに列インデックスが存在する場合、Athena はデフォルトで S3 Tables とともに Parquet 列インデックスを使用します。他の Iceberg テーブルの場合、Athena は `use_iceberg_parquet_column_index` プロパティを使用して、Parquet ファイル内の列インデックスを使用するかどうかを決定します。AWS Glue コンソールまたは `UpdateTable` API を使用して、このテーブルプロパティを設定します。

# AWS Glue Data Catalog マテリアライズドビューをクエリする
<a name="querying-iceberg-gdc-mv"></a>

Athena では、AWS Glue Data Catalog マテリアライズドビューをクエリできます。Glue Data Catalog のマテリアライズドビューには、SQL クエリの事前計算された結果が Apache Iceberg テーブルとして保存されます。

Amazon EMR または AWS Glue で Apache Spark を使用して Glue Data Catalog マテリアライズドビューを作成すると、ビュー定義とメタデータが AWS Glue Data Catalog に保存されます。事前計算された結果は、Apache Iceberg テーブルとして Amazon S3 に保存されます。通常の Iceberg テーブルをクエリする場合と同様に、標準の SQL `SELECT` ステートメントを使用して Athena からこれらのマテリアライズドビューをクエリできます。

## 前提条件
<a name="querying-iceberg-gdc-mv-prerequisites"></a>

Athena でマテリアライズドビューをクエリする前に、以下を確認してください。
+ マテリアライズドビューは AWS Glue データカタログに存在しており、Apache Spark (Amazon EMR リリース 7.12.0 以降、または AWS Glue バージョン 5.1 以降) を使用して作成されている
+ Athena でマテリアライズドビューをクエリするために必要な AWS Lake Formation 許可：
  + マテリアライズドビューにおける `SELECT` 許可
  + マテリアライズドビューにおける `DESCRIBE` 許可
  + マテリアライズドビューのデータが保存されており基盤となっている Amazon S3 の場所へのアクセス許可
+ マテリアライズドビューの基本的なデータは、Amazon S3 Table バケットまたは Amazon S3 汎用バケットに保存される
+ マテリアライズドビューを含む AWS Glue Data Catalog データベースへのアクセス許可がある
+ Amazon S3 Tables バケットに保存されているマテリアライズドビューの場合、S3 Tables カタログにアクセスするために必要な許可が自身の IAM ロールにある

## 考慮事項と制限事項
<a name="querying-iceberg-gdc-mv-considerations"></a>
+ Athena は、マテリアライズドビューでのオペレーション (`ALTER`、`CREATE MATERIALIZED VIEW`、`REFRESH MATERIALIZED VIEW`、`DROP`、`INSERT`、`UPDATE`、`MERGE`、`DELETE`、`OPTIMIZE`、`VACUUM`) をサポートしません。マテリアライズドビューを作成するには、Amazon EMR または AWS Glue で Apache Spark を使用してください。リフレッシュオペレーションは、AWS Glue Data Catalog API または Apache Spark を使用して実行する必要があります。Apache Spark を使用してマテリアライズドビューに変更を加えます。

## マテリアライズドビューのクエリ
<a name="querying-iceberg-gdc-mv-operations"></a>

Athena は、マテリアライズドビューを読み取りオペレーション用の標準 Iceberg テーブルとして扱い、特別な構文や設定変更を必要とすることなく、事前に計算されたデータにアクセスできます。

Athena でマテリアライズドビューをクエリするには、標準的な `SELECT` ステートメントを使用します。

```
SELECT * FROM my_database.sales_summary_mv;
```

通常のテーブルと同様に、フィルター、集計、結合を適用できます。

```
SELECT
  region,
  SUM(total_sales) as sales_total
FROM my_database.sales_summary_mv
WHERE year = 2025
GROUP BY region
ORDER BY sales_total DESC;
```

## サポートされているオペレーション
<a name="querying-iceberg-gdc-mv-supported"></a>

Athena は、マテリアライズドビューでの次のオペレーションをサポートしています。
+ `SELECT` クエリ - 標準 SQL `SELECT` ステートメントを使用してマテリアライズドビューからデータを読み取る
+ `DESCRIBE` - マテリアライズドビューのスキーマとメタデータを表示する
+ `SHOW TABLES` - データベース内の他のテーブルとともにマテリアライズドビューを一覧表示する
+ `JOIN` オペレーション - マテリアライズドビューを他のテーブルまたはビューに結合する
+ フィルタリングと集計 - `WHERE` 句、`GROUP BY`、集計関数を適用する

# Athena の Iceberg テーブルでサポートされているデータ型
<a name="querying-iceberg-supported-data-types"></a>

Athena は、次のデータ型が含まれている Iceberg テーブルをクエリできます。

```
binary
boolean
date
decimal
double
float
int
list
long
map
string
struct
timestamp without time zone
```

Iceberg テーブル型の詳細については、Apache のドキュメントの [Iceberg の「Schemas」ページ](https://iceberg.apache.org/docs/latest/schemas/)を参照してください。

次の表に、Athena のデータ型と Iceberg のテーブルデータ型の関係を示します。


****  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/querying-iceberg-supported-data-types.html)

Athena でのデータ型の詳細については、「[Amazon Athena のデータ型](data-types.md)」を参照してください。

# 追加リソース
<a name="querying-iceberg-additional-resources"></a>

次の記事は、AWS 規範的ガイダンスのドキュメントに記載されています。
+ [Working with Apache Iceberg tables by using Amazon Athena SQL](https://docs.aws.amazon.com/prescriptive-guidance/latest/apache-iceberg-on-aws/iceberg-athena.html) 

Apache Iceberg テーブルで Athena を使用する方法の詳細記事については、「AWS Big Data Blog」の以下の投稿を参照してください。
+ [Implement a serverless CDC process with Apache Iceberg using Amazon DynamoDB and Amazon Athena](https://aws.amazon.com/blogs/big-data/implement-a-serverless-cdc-process-with-apache-iceberg-using-amazon-dynamodb-and-amazon-athena/) 
+ [Accelerate data science feature engineering on transactional data lakes using Amazon Athena with Apache Iceberg](https://aws.amazon.com/blogs/big-data/accelerate-data-science-feature-engineering-on-transactional-data-lakes-using-amazon-athena-with-apache-iceberg/) 
+ [Amazon Athena、Amazon EMR、および AWS Glue を使用した Apache Iceberg データレイクの構築](https://aws.amazon.com/blogs/big-data/build-an-apache-iceberg-data-lake-using-amazon-athena-amazon-emr-and-aws-glue/) 
+ [Perform upserts in a data lake using Amazon Athena and Apache Iceberg](https://aws.amazon.com/blogs/big-data/perform-upserts-in-a-data-lake-using-amazon-athena-and-apache-iceberg/) 
+ [Build a transactional data lake using Apache Iceberg, AWS Glue, and cross-account data shares using AWS Lake Formation and Amazon Athena](https://aws.amazon.com/blogs/big-data/build-a-transactional-data-lake-using-apache-iceberg-aws-glue-and-cross-account-data-shares-using-aws-lake-formation-and-amazon-athena/) 
+ [Use Apache Iceberg in a data lake to support incremental data processing](https://aws.amazon.com/blogs/big-data/use-apache-iceberg-in-a-data-lake-to-support-incremental-data-processing/) 
+ [Build a real-time GDPR-aligned Apache Iceberg data lake](https://aws.amazon.com/blogs/big-data/build-a-real-time-gdpr-aligned-apache-iceberg-data-lake/) 
+ [Automate replication of relational sources into a transactional data lake with Apache Iceberg and AWS Glue](https://aws.amazon.com/blogs/big-data/automate-replication-of-relational-sources-into-a-transactional-data-lake-with-apache-iceberg-and-aws-glue/) 
+ [Interact with Apache Iceberg tables using Amazon Athena and cross account fine-grained permissions using AWS Lake Formation](https://aws.amazon.com/blogs/big-data/interact-with-apache-iceberg-tables-using-amazon-athena-and-cross-account-fine-grained-permissions-using-aws-lake-formation/) 
+ [Build a serverless transactional data lake with Apache Iceberg, Amazon EMR Serverless, and Amazon Athena](https://aws.amazon.com/blogs/big-data/build-a-serverless-transactional-data-lake-with-apache-iceberg-amazon-emr-serverless-and-amazon-athena/)