Apache Icebergについて整理した

# 背景・目的
先日、下記のイベントに参加しIcebergについていろいろな機能が増えていることに気づきました。

https://aws.amazon.com/startups/events/apache-iceberg-on-aws?lang=ja

また、そもそもIcebergについて基本をあまりわかっていないので基本的な知識を整理したいと思います。

# まとめ
下記に特徴を整理します。

|特徴|説明|
|:--|:--|
|Iceberg| 大規模な分析データセット向けのオープン テーブルフォーマット<BR>SQLテーブルと同様に動作する高性能なテーブル形式を使用して、各コンピューティングエンジンにテーブルを追加する|
|User experience|Icebergは、予期せぬ事態を回避する<BR>Schema evolutionは適切に機能し、誤ってデータを復元することはない<BR>ユーザーはパーティショニングについて意識することなく、高速なクエリを実行できる|
|Reliability and performance|Icebergは巨大なテーブル向けに構築された<BR>Icebergは、単一のテーブルに数十ペタバイトのデータが含まれるような本番環境で使用され、このような巨大なテーブルであっても分散SQLエンジンなしで読み取ることができる|
|Branching and Tagging|Icebergのテーブルメタデータは、テーブルに適用された変更を表すスナップショットログを保持する<BR>ライフサイクルは、ブランチおよびタグ レベルの保持ポリシーによって制御される|
|ユースケース|GDPR要件への対応や、監査のための重要な履歴スナップショットの保持に活用できる|

# 概要
## Documentation
下記を基に整理します

https://iceberg.apache.org/docs/latest/

- Icebergは、大規模な分析データセット向けのオープン テーブルフォーマット
- SQLテーブルと同様に動作する高性能なテーブル形式を使用して、下記のようなコンピューティングエンジンにテーブルを追加する
    - Spark
    - Trino
    - PrestDB
    - Flink
    - Hive
    - Impalaなどの


### User experience
- Icebergは、予期せぬ事態を回避する
- Schema evolutionは適切に機能し、誤ってデータを復元することはない
- ユーザーはパーティショニングについて意識することなく、高速なクエリを実行できる
- 下記に特徴を整理します
    - Schema evolution 
        - 追加、削除、更新、名前の変更をサポートし、副作用はない
    - Hidden partitioning
        - ユーザーのミスによる誤った結果や極端に遅いクエリの発生を防止
    - Partition layout evolution
        - データ量やクエリパターンの変化に応じてテーブルのレイアウトを更新できる
    - Time travel 
        - 全く同じテーブルスナップショットを使用した再現可能なクエリが可能になり、ユーザーは変更を簡単に調べることができる
    - Version rollback
        - ユーザーはテーブルを正常な状態にリセットすることで問題を迅速に修正できる

### Reliability and performance
- Icebergは巨大なテーブル向けに構築された
- Icebergは、単一のテーブルに数十ペタバイトのデータが含まれるような本番環境で使用され、このような巨大なテーブルであっても分散SQLエンジンなしで読み取ることができる
    - Scan planning is fast
        - テーブルを読み込んだりファイルを検索したりするのに分散SQLは不要
    - Advanced filtering
        - テーブル メタデータを使用して、パーティションおよび列レベルの統計情報でデータ ファイルが整理ｓれる
- Iceberg は、最終的に一貫性のあるクラウド オブジェクト ストアの正確性の問題を解決するために設計された
    - あらゆるクラウドストアで動作し、HDFS でのリスト作成や名前変更を回避することで NN の混雑を軽減する
    - 直列化可能な分離
        - テーブルの変更はアトミックであり、読者は部分的またはコミットされていない変更を見ることはない
    - 複数の同時書き込みは楽観的同時実行を使用し、書き込みが競合した場合でも互換性のある更新が成功するように再試行する

### Open standard
- Iceberg は、言語や実装間の互換性を確保する仕様を備えたオープン コミュニティ スタンダードとなるように設計および開発された

<!--
## Table
### Branching and Tagging
- Icebergのテーブルメタデータは、テーブルに適用された変更を表すスナップショットログを保持する
- スナップショットは、読み取り分離とタイムトラベルクエリの基盤となるため、Icebergにとって不可欠な要素
- メタデータのサイズとストレージコストを制御するために、Icebergは、テーブルスナップexpire_snapshotsショットの保持プロパティに基づいて、使用されていないスナップショットや不要になったデータファイルを削除するなど、スナップショットライフサイクル管理手順を提供する

- より洗練されたスナップショットのライフサイクル管理のために、Iceberg は、独自の独立したライフサイクルを持つスナップショットへの名前付き参照であるブランチとタグをサポートしている
    - このライフサイクルは、ブランチおよびタグ レベルの保持ポリシーによって制御される
    - ブランチはスナップショットの独立した系統であり、系統の先頭を指す
    - ブランチとタグには、スナップショット自体への参照の有効期限を制御する最大参照期間プロパティがある
    - ブランチには、ブランチで保持するスナップショットの最小数と、ブランチで保持する個々のスナップショットの最大期間を定義する保持プロパティがある
    - これらのプロパティは、expireSnapshots プロシージャの実行時に使用される

#### ユースケース
- ブランチとタグ付けは、GDPR要件への対応や、監査のための重要な履歴スナップショットの保持に活用できる
- また、ブランチはデータエンジニアリングワークフローの一部としても活用でき、新しいジョブのテストと検証のための実験的なブランチを作成することもできる
- ブランチとタグ付けがこれらのユースケースをどのように促進するかについては、下記を参照

##### Historical Tags
タグは、監査の目的で重要な履歴スナップショットを保持するために使用できる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/37000e12-11f4-430b-abae-0b1663a286c4.png)

[出典：Iceberg > Historical Tags](https://iceberg.apache.org/docs/latest/branching/#historical-tags)

-->

# 考察
今回は、Introductionをまとめました。今後、詳細を継続して学んでいきたいと思います。

# 参考
https://iceberg.apache.org/

https://github.com/apache/iceberg

https://aws.amazon.com/jp/what-is/apache-iceberg/

https://iceberg.apache.org/docs/latest/

https://aws.amazon.com/startups/events/apache-iceberg-on-aws?lang=ja