DEA / ドメイン2 データストア管理
重要な内容
オープンテーブルフォーマットと Amazon S3 Tables
に ファイルを置くだけのは、行の更新や削除、同時書き込みが苦手です。 などのは、ファイルの上に「テーブルの状態を記録するメタデータ」を重ね、データレイクでもデータベースのような更新・削除・を可能にします。 は、Iceberg テーブルの保管と保守を S3 が肩代わりするストレージです。DEA-C01 では、オープンテーブルフォーマットの管理 (スキル 2.1.7) として、Iceberg の機能と、S3 Tables・・・・ からの使い方が問われます。
Point
- オープンテーブルフォーマット (OTF): 特定の製品に縛られない公開仕様のテーブル形式です。Apache Iceberg、Apache Hudi、Delta Lake が代表です。
- ACID: Atomicity (原子性)、Consistency (一貫性)、Isolation (分離性)、Durability (永続性) の頭文字です。トランザクションが「全部成功か全部失敗か」になり、途中の状態が他から見えないことを表します。
- タイムトラベル: 過去のある時点のテーブルの状態を問い合わせる機能です。
概要
は、データファイル ( など) と、それを束ねるメタデータの階層でテーブルを表します。書き込みのたびに新しい (その時点のテーブルの状態) が作られ、読み手は常に完結したスナップショットを読みます。
| できること | Parquet を置くだけのテーブル | Iceberg テーブル |
|---|---|---|
| 行の更新・削除 (UPDATE、DELETE、) | ファイルを丸ごと書き直す処理を自作する | でできる |
| 同時書き込み | 結果が壊れることがある | 楽観的ロックで整合性を保つ |
| 過去の状態の参照 | できない | スナップショットでできる |
| 列の追加・名前変更 | 読み手と食い違いやすい | メタデータの変更だけで安全にできる |
| パーティションの変更 | データを置き直す | 既存データを書き直さずに変えられる |
試験では、「で行単位の更新・削除をしたい」「過去の時点のデータを再現したい」「の保守を減らしたい」という要件から、Iceberg と を選べるかが問われます。
主要技術
①Apache Iceberg の主な機能 ⚠️ 頻出
| 機能 | 内容 | 使いどころ |
|---|---|---|
| ACID トランザクション | 書き込みは単位で全部か無か。読み手は書き込み途中を見ない | 取り込みと読み取りが同時に走るテーブル |
| 行レベルの更新・削除 | 、UPDATE、DELETE | の反映 (upsert)、削除要求への対応 |
FOR TIMESTAMP AS OF や FOR VERSION AS OF で過去を読む | 監査、誤った更新前の再現、ML のの再現 | |
| ロールバック | 過去のスナップショットへ戻す | 誤ったバッチ書き込みの取り消し |
| スキーマの進化 | 列の追加・削除・名前変更・並べ替え、型の拡大をメタデータだけで行う | 上流のスキーマ変更への追従 |
| 隠れたパーティション (hidden partitioning) | 列の値から日付などを変換してパーティションにする。利用者はパーティション列を意識せずに WHERE を書ける | 利用者がパーティション列を指定し忘れても絞り込みが効く |
| パーティションの進化 | 日単位から時間単位へなど、仕様を途中で変えられる。既存データは書き直さない | データ量の増加に合わせた設計変更 |
-- Athena で Iceberg テーブルに CDC を反映する例
MERGE INTO curated.customers t
USING staging.customer_changes s
ON t.customer_id = s.customer_id
WHEN MATCHED AND s.op = 'D' THEN DELETE
WHEN MATCHED THEN UPDATE SET name = s.name, email = s.email
WHEN NOT MATCHED THEN INSERT (customer_id, name, email) VALUES (s.customer_id, s.name, s.email);
②更新の方式と保守 (コンパクションとスナップショットの整理)
行の更新・削除には2つの書き方があります。
| 方式 | 書き込み | 読み取り | 向くケース |
|---|---|---|---|
| コピーオンライト (copy-on-write) | 変更のあったファイルを丸ごと書き直す (遅い) | そのまま読める (速い) | 更新が少なく読み取りが多い |
| マージオンリード (merge-on-read) | 削除ファイルを追加するだけ (速い) | 読むときに削除ファイルと突き合わせる (遅くなる) | 更新が頻繁 (ストリーミングの ) |
の テーブルへの DELETE はマージオンリードで、位置削除ファイルを書くだけです。クエリの結果からは行が消えますが、元のデータファイルには行が残ります。削除の依頼に応じて 上からも物理的に消すには、OPTIMIZE ... REWRITE DATA で削除を反映したファイルに書き直し、VACUUM で古いを期限切れにして参照されなくなったファイルを消します。
Iceberg テーブルは使い続けると、、削除ファイル、古いスナップショット、どこからも参照されないファイルがたまり、読み取りが遅くなり保管料金も増えます。定期的な保守が必要です。
| 保守 | 内容 | 方法の例 |
|---|---|---|
| 小さいファイルをまとめ、削除ファイルを反映して書き直す | Athena の OPTIMIZE ... REWRITE DATA、 の rewrite_data_files、 Data Catalog のテーブル最適化 | |
| スナップショットの期限切れ | 古いスナップショットを消す (できる範囲が短くなる) | Athena の VACUUM、Glue Data Catalog のスナップショット保持 |
| 孤立ファイルの削除 | どのスナップショットからも参照されないファイルを消す | Glue Data Catalog の孤立ファイル削除、 の自動保守 |
Glue Data Catalog は、汎用に置いた Iceberg テーブルに対して、コンパクション・スナップショット保持・孤立ファイル削除を自動で行うテーブル最適化の機能を持ちます。S3 Tables はこれらを標準で自動実行します。
③Amazon S3 Tables ⚠️ 頻出
は、表形式のデータの保管に特化した のストレージです。テーブルという新しい種類のバケットに、 形式のテーブルをサブリソースとして置きます。
| 構成要素 | 内容 |
|---|---|
| テーブルバケット | テーブルを入れるバケット。ブロックパブリックアクセスは常に有効で外せない |
| 名前空間 (namespace) | テーブルをまとめる論理的な入れ物 (データベースに相当) |
| テーブル | Iceberg 形式のテーブル。 ポリシーで個別に権限を付けられる |
| 特徴 | 内容 |
|---|---|
| 自動の保守 | 、の管理、参照されないファイルの削除を S3 が継続して行う。設定はテーブルごと・バケットごとに変えられる |
| 性能 | 汎用バケットに自分で置く Iceberg テーブルより、高いトランザクション数と読み取りを出せる |
| 権限 | s3tables という別の名前空間の IAM アクションで、テーブルバケット・名前空間・テーブル単位に権限を付ける |
| 分析サービスとの統合 | Data Catalog に s3tablescatalog としてで登録し、・・・Glue・Quick などから読む |
| コスト | Intelligent-Tiering のを使える |
分析サービスとの統合は、既定では IAM の権限で制御します。表・列・行の単位で細かく制御したい場合は、 による制御を選べます (「AWS Lake Formation」の章)。テーブル名や列名に大文字を使うと、Glue Data Catalog と Lake Formation で扱えず、Athena などから見えなくなるため、すべて小文字にします。
| 比べるもの | 汎用バケット + 自分で管理する Iceberg | S3 Tables |
|---|---|---|
| 保守の手間 | コンパクションなどを自分で計画する (Glue のテーブル最適化で自動化も可) | S3 が自動で行う |
| 柔軟性 | 置き場所やカタログを自由に選べる | テーブルバケットと S3 Tables のカタログに従う |
| 向くケース | 既存のの構成を活かしたい | 新しく Iceberg のテーブルを作り、運用を任せたい |
④AWS の分析サービスからの利用
| サービス | でできること |
|---|---|
| CREATE TABLE、SELECT、INSERT、、UPDATE、DELETE、、OPTIMIZE、 | |
| ( ジョブ) | 大量データの書き込み、MERGE、保守の実行。Glue Data Catalog をカタログに使う |
| (Spark、、 など) | 大規模な読み書き、ストリーミングからの書き込み |
| Glue Data Catalog に登録した Iceberg テーブルを問い合わせ、Redshift のテーブルと結合する | |
| ストリームのレコードを Iceberg テーブルへ配信する ( も配信先にできる) |
1つのテーブルを複数のエンジンで読み書きできるため、データを Redshift 用・Athena 用とコピーする必要が減ります。
⑤Iceberg・Hudi・Delta Lake の比較
| 形式 | 生まれ | 特徴 | AWS での位置づけ |
|---|---|---|---|
| Netflix | エンジンに依存しない仕様、隠れたパーティション、パーティションの進化 | の形式。・・・・ が幅広く対応 | |
| Uber | レコード単位の と増分取り込みに強い | Glue・EMR・Athena (読み取り) が対応 | |
| Databricks | との結びつきが強い | Glue・EMR・Athena (読み取り) が対応 |
試験では、AWS のサービスを広く組み合わせるなら Iceberg を選ぶのが基本です。
試験対策
①判断マトリクス
| 問題文のキーワード | 選ぶもの |
|---|---|
| で行の更新・削除、 | の MERGE INTO / UPDATE / DELETE |
| 過去の時点のデータでレポートを再現 | Iceberg の |
| 誤ったバッチ書き込みを取り消したい | Iceberg のへのロールバック |
| 列の追加や名前変更でデータを書き直したくない | Iceberg のスキーマの進化 |
| パーティションの粒度を途中で変えたい | Iceberg のパーティションの進化 |
| とスナップショットの保守を任せたい | (自動の保守) |
| 既存の汎用の Iceberg を自動で最適化 | Data Catalog のテーブル最適化 |
| ストリームを Iceberg テーブルへ直接配信 | |
| 更新が頻繁でストリーミングの upsert | マージオンリード + 定期的な |
②よくある誤答
- を置いた通常のテーブルで、行の削除要求に対応しようとしてファイル全体を書き直す処理を作ること。 の DELETE を使います。
- を無期限に残すこと。保管料金が増え、メタデータが重くなります。に必要な期間だけ残します。
- のテーブルや列に大文字の名前を付けること。分析サービスから見えなくなります。
- Iceberg のタイムトラベルを、 のと同じものと考えること。タイムトラベルはテーブル単位のスナップショット、バージョニングはオブジェクト単位の版です。