背景・目的
先日、下記のイベントに参加しIcebergについていろいろな機能が増えていることに気づきました。
また、そもそもIcebergについて基本をあまりわかっていないので基本的な知識を整理したいと思います。
まとめ
下記に特徴を整理します。
| 特徴 | 説明 |
|---|---|
| Iceberg | 大規模な分析データセット向けのオープン テーブルフォーマット SQLテーブルと同様に動作する高性能なテーブル形式を使用して、各コンピューティングエンジンにテーブルを追加する |
| User experience | Icebergは、予期せぬ事態を回避する Schema evolutionは適切に機能し、誤ってデータを復元することはない ユーザーはパーティショニングについて意識することなく、高速なクエリを実行できる |
| Reliability and performance | Icebergは巨大なテーブル向けに構築された Icebergは、単一のテーブルに数十ペタバイトのデータが含まれるような本番環境で使用され、このような巨大なテーブルであっても分散SQLエンジンなしで読み取ることができる |
| Branching and Tagging | Icebergのテーブルメタデータは、テーブルに適用された変更を表すスナップショットログを保持する ライフサイクルは、ブランチおよびタグ レベルの保持ポリシーによって制御される |
| ユースケース | GDPR要件への対応や、監査のための重要な履歴スナップショットの保持に活用できる |
概要
Documentation
下記を基に整理します
- Icebergは、大規模な分析データセット向けのオープン テーブルフォーマット
- SQLテーブルと同様に動作する高性能なテーブル形式を使用して、下記のようなコンピューティングエンジンにテーブルを追加する
- Spark
- Trino
- PrestDB
- Flink
- Hive
- Impalaなどの
User experience
- Icebergは、予期せぬ事態を回避する
- Schema evolutionは適切に機能し、誤ってデータを復元することはない
- ユーザーはパーティショニングについて意識することなく、高速なクエリを実行できる
- 下記に特徴を整理します
- Schema evolution
- 追加、削除、更新、名前の変更をサポートし、副作用はない
- Hidden partitioning
- ユーザーのミスによる誤った結果や極端に遅いクエリの発生を防止
- Partition layout evolution
- データ量やクエリパターンの変化に応じてテーブルのレイアウトを更新できる
- Time travel
- 全く同じテーブルスナップショットを使用した再現可能なクエリが可能になり、ユーザーは変更を簡単に調べることができる
- Version rollback
- ユーザーはテーブルを正常な状態にリセットすることで問題を迅速に修正できる
- Schema evolution
Reliability and performance
- Icebergは巨大なテーブル向けに構築された
- Icebergは、単一のテーブルに数十ペタバイトのデータが含まれるような本番環境で使用され、このような巨大なテーブルであっても分散SQLエンジンなしで読み取ることができる
- Scan planning is fast
- テーブルを読み込んだりファイルを検索したりするのに分散SQLは不要
- Advanced filtering
- テーブル メタデータを使用して、パーティションおよび列レベルの統計情報でデータ ファイルが整理ｓれる
- Scan planning is fast
- Iceberg は、最終的に一貫性のあるクラウド オブジェクト ストアの正確性の問題を解決するために設計された
- あらゆるクラウドストアで動作し、HDFS でのリスト作成や名前変更を回避することで NN の混雑を軽減する
- 直列化可能な分離
- テーブルの変更はアトミックであり、読者は部分的またはコミットされていない変更を見ることはない
- 複数の同時書き込みは楽観的同時実行を使用し、書き込みが競合した場合でも互換性のある更新が成功するように再試行する
Open standard
- Iceberg は、言語や実装間の互換性を確保する仕様を備えたオープン コミュニティ スタンダードとなるように設計および開発された
考察
今回は、Introductionをまとめました。今後、詳細を継続して学んでいきたいと思います。
参考