Apache Iceberg Integration With Analytics Accelerator#
用語 Hybrid ManagerHMは、環境全体でPostgres、分析、AIをプロビジョニングおよび操作するためのEDBのコントロールプレーンです。アナリティクスアクセラレータPGAAは、レイクハウス、階層化、およびベクトル化クエリ機能を使用してPostgresを拡張するEDBの分析機能を指します。
Apache Icebergとは#
Apache Icebergは、オブジェクトストレージに構築されたデータレイクにデータベースのような信頼性をもたらすオープンテーブル形式です。従来のファイルベースのアプローチとは異なり、Icebergは、ParquetやORCなどの標準フォーマットとの互換性を維持しながら、ACIDトランザクション、スキーマの進化、およびタイムトラベル機能を提供します。 Analytics Accelerator PGAAは、Icebergを活用して、オブジェクトストレージからデータを移動せずに、ペタバイト規模のデータレイクに対するPostgreSQLクエリーを有効にします。
このページは、Analytics Hubの一部です。完全なナビゲーションについては、次をご覧ください Analytics Hub — Analytics Accelerator Concepts — How-Tos (Runbook-Aligned)
Icebergの統合を使用する人#
データエンジニア は、スキーマの進化と同時の読み取り/書き込み操作を必要とする信頼性の高いデータパイプラインのためにIcebergテーブルを実装します。彼らは、クエリの一貫性を維持しながらストリーミング取り込みを処理するIcebergの機能を評価しています。
データアナリスト は、使い慣れたSQL構文を使用して、アナリティクスアクセラレーターを介してIcebergテーブルを照会し、基になるストレージの複雑さを理解せずにタイムトラベルクエリを介して履歴データにアクセスします。
プラットフォームチーム は、Spark、Trino、およびPostgreSQLが同じデータセットに一貫してアクセスする必要があるマルチエンジン分析環境の基盤としてIcebergを展開します。
データサイエンティスト は、Icebergのバージョニング機能を活用して実験を再現し、特定の時点でトレーニングデータにアクセスし、モデルの再現性を保証します。
アナリティクスアクセラレーターでIcebergを使用する方法#
基本的なセットアップ#
Analytics AcceleratorをIcebergカタログに接続して、既存のテーブルを検出および照会します。
- - Add Iceberg catalog
SELECT pgaa.add_catalog(
data_lake,
iceberg-rest,
{"url": "https://catalog.company.com",
"warehouse": "analytics",
"token": "auth_token"}
);
- - Attach catalog for querying
SELECT pgaa.attach_catalog(data_lake);
- - Query Iceberg tables directly
SELECT * FROM data_lake.sales.transactions
WHERE transaction_date >= 2024-01-01;
外部テーブルの作成#
Icebergデータを参照するPostgreSQLテーブルを定義します。
CREATE TABLE customer_events () USING PGAA
WITH (
pgaa.format = iceberg,
pgaa.managed_by = data_lake,
pgaa.catalog_namespace = events,
pgaa.catalog_table = customer_activity
);
タイムトラベルクエリ#
別のコピーを維持せずに履歴データにアクセスします。
- - Query data as of specific timestamp
SELECT COUNT(*) FROM sales_facts
FOR SYSTEM_TIME AS OF 2024-12-31 23:59:59;
- - Compare current with historical state
SELECT
current.product_id,
current.price as current_price,
historical.price as year_end_price
FROM sales_facts current
JOIN sales_facts FOR SYSTEM_TIME AS OF 2024-12-31 historical
ON current.product_id = historical.product_id
WHERE current.price != historical.price;
Icebergアーキテクチャを理解する#
メタデータ構造#
Icebergは、大規模なパフォーマンスを維持しながら高度な機能を有効にする3層メタデータアーキテクチャを実装しています。
メタデータファイル は、スキーマ、パーティショニング、スナップショット履歴を含む現在のテーブルの状態を追跡します。テーブルを変更するたびに、新しいメタデータファイルが作成され、タイムトラベル用に以前のバージョンが保存されます。
マニフェストリスト は、パーティションプルーニングの統計を使用してデータファイルのコレクションを編成します。アナリティクスアクセラレーターはこれらの統計を使用して、クエリの実行が開始される前に不必要なファイルのスキャンを排除します。
マニフェストファイル には、個々のデータファイルの列レベルの統計が含まれています。これらの統計により、述語のプッシュダウンが有効になり、アナリティクスアクセラレーターは、一致する行を含めることができないファイルをスキップできます。
隠しパーティション#
Icebergは、非表示のパーティショニングを介してユーザーからパーティションの複雑さを抽象化します。クエリーは自然な列値を使用しますが、Icebergはこれらをパーティションフィルターに自動的に変換します。
- - User writes simple query
SELECT * FROM orders WHERE order_date = 2024-03-15;
- - Iceberg automatically prunes to day=2024-03-15 partition
- - without user knowing partitioning scheme
この抽象化により、クエリを変更せずにパーティションの進化が可能になります。組織は、既存のアプリケーションを中断せずに、データ量の増加に応じてパーティショニング戦略を調整できます。
トランザクションモデル#
Icebergは、スナップショット分離を使用してオプティミスティック同時実行制御を実装します。ライターは、アトミックに可視になる新しいスナップショットを作成し、リーダーが同時変更にもかかわらず一貫したテーブル状態を観察できるようにします。
Analytics Acceleratorは、このモデルを活用して、反復可能なクエリ結果を提供します。ストリーミングシステムが新しいデータを書き込む場合でも、長時間実行される分析クエリーはスナップショットにアクセスし続け、読み取り-書き込みの競合を排除します。
スキーマ進化機能#
Icebergは、アナリティクスアクセラレーターの標準SQLコマンドを介して公開される、データを書き換えることのない包括的なスキーマの変更をサポートしています。
安全なスキーマの変更#
データファイルに手を加えずに列を追加、名前変更、またはドロップします。
- - Add column (instant operation)
ALTER TABLE customer_events ADD COLUMN region VARCHAR;
- - Rename column (metadata only)
ALTER TABLE customer_events RENAME COLUMN usr_id TO user_id;
- - Drop column (marks as deleted, data retained)
ALTER TABLE customer_events DROP COLUMN deprecated_field;
タイププロモーション#
要件の進化に応じて、データ型を安全に拡張します。
- - Promote int to bigint
ALTER TABLE transactions ALTER COLUMN amount TYPE BIGINT;
- - Promote float to double
ALTER TABLE metrics ALTER COLUMN value TYPE DOUBLE PRECISION;
カタログ統合パターン#
Analytics Acceleratorは、それぞれが異なる運用要件に適した複数のIcebergカタログ実装をサポートしています。
RESTカタログ#
RESTカタログは、HTTPプロトコルを介してベンダーニュートラルな統合を提供します。 AWS Glue、Tabular、およびカスタム実装は、標準化されたREST APIを介してIcebergテーブルを公開します。
SELECT pgaa.add_catalog(
aws_catalog,
iceberg-rest,
{"url": "https://glue.us-east-1.amazonaws.com",
"warehouse": "production",
"credential": "aws_iam"}
);
AWS S3テーブル#
AWS S3テーブルとのネイティブ統合により、サーバーレスのIcebergカタログ機能が提供されます。
SELECT pgaa.add_catalog(
s3_tables,
iceberg-s3tables,
{"arn": "arn:aws:s3tables:us-east-1:123456:bucket/analytics",
"region": "us-east-1"}
);
プロジェクトネッシー#
Nessieは、Gitのような分岐をIcebergテーブルに追加し、実験的分析を可能にします。
- - Query production branch
SELECT * FROM catalog.main.sales_facts;
- - Query experimental branch
SELECT * FROM catalog.experiment_branch.sales_facts;
パフォーマンス最適化戦略#
ファイル構成#
最適なファイルサイズにより、並列処理とI/O効率のバランスが取れます。通常の圧縮を介して128〜512 MBのParquetファイルをターゲットにします。
- - Compact small files for better performance
CALL pgaa.compact_table(catalog.schema.table,
target_file_size => 256MB);
ソートの最適化#
ファイル内のデータを並べ替えると、圧縮が向上し、効率的なスキップが可能になります。
- - Z-order by frequently filtered columns
CALL pgaa.zorder_table(catalog.schema.table,
columns => ARRAY[customer_id, order_date]);
メタデータ管理#
定期的なメンテナンスにより、メタデータの効率が維持されます。
- - Expire old snapshots
CALL pgaa.expire_snapshots(catalog.schema.table,
older_than => CURRENT_TIMESTAMP - INTERVAL 30 days);
- - Remove orphan files
CALL pgaa.remove_orphan_files(catalog.schema.table);
一般的な統合パターン#
階層化ストレージアーキテクチャ#
PostgreSQLの運用データとIcebergの履歴データを組み合わせます。
- - Unified view across tiers
CREATE VIEW sales_unified AS
SELECT * FROM postgres.sales_current
UNION ALL
SELECT * FROM iceberg.sales_historical;
マルチエンジンプロセッシング#
Icebergのオープンフォーマットにより、ツールの特化が可能になります。
Apache Spark 複雑なETL変換
アナリティクスアクセラレーター 対話型SQLクエリー
Trino システム全体のフェデレーションクエリー
Flink ストリーム処理とリアルタイム分析
ストリーミングデータの統合#
一貫したスナップショットを使用してストリーミングデータを処理します。
- - Query latest streaming data
SELECT COUNT(*) FROM events
WHERE event_time >= CURRENT_TIMESTAMP - INTERVAL 1 hour;
- - Streaming platforms write continuously
- - Analytics Accelerator queries see consistent snapshots
運用上の考慮事項#
モニタリング要件#
最適なパフォーマンスのために主要なメトリックを追跡します。
スナップショット数 メタデータの増加を示します
パーティションごとのファイル数 圧縮ニーズを特定します
メタデータ操作のレイテンシー カタログパフォーマンスを明らかにします
クエリプルーニングの有効性 パーティショニング戦略を検証します
キャパシティプランニング#
Icebergはストレージをコンピューティングから分離し、独立したスケーリングを有効にします。
ストレージ データ量とスナップショットの保持に応じて増加します
コンピューティング 同時クエリの負荷に応じてスケーリング
メタデータ テーブルの進化に応じて定期的なメンテナンスが必要
移行戦略#
Icebergを段階的に採用して、リスクを最小限に抑えます。
パイロットフェーズ 検証のために非クリティカルデータセットを変換する
プロダクション移行 高価値の分析テーブルを移動する
完全な採用 すべての分析データをIcebergで標準化する