EDB Postgres Lakehouse Architecture

EDB Postgres Lakehouse Architecture#

EDB Postgres Lakehouseとは#

EDB Postgres Lakehouseは、 PostgreSQLの分析機能を拡張してデータレイクストレージで直接動作し、従来のデータベースの信頼性と最新のオブジェクトストレージのスケーラビリティとコスト効率を組み合わせます。このアーキテクチャにより、組織は、高価な分析データベースにデータを移動せずに、S3、Azure Blob Storage、またはGoogle Cloud Storageに保存されているペタバイト規模のデータセットに対して複雑なSQL分析を実行できます。

このページは、Analytics Hubの一部です。完全なナビゲーションについては、次をご覧ください Analytics Hub — Analytics Accelerator Concepts — How-Tos (Runbook-Aligned)

レイクハウスアプローチは、データウェアハウスとデータレイク間の従来の分離を排除します。アナリティクスアクセラレーターPGAAは、システム全体で重複データを維持するのではなく、Apache IcebergやDelta Lakeのようなオープンテーブルフォーマットを使用して、データが存在する場所を直接照会し、オブジェクトストレージでのACIDトランザクション、スキーマの適用、およびタイムトラベル機能を提供します。

レイクハウスアーキテクチャから恩恵を受ける人#

データベース管理者 は、レイクハウス機能を活用して、費用対効果の高い階層化ストレージ戦略を実装し、完全なクエリアクセスを維持しながら、高価なPostgreSQLストレージからオブジェクトストレージに履歴データを自動的にオフロードします。

データエンジニア は、オブジェクトストレージに1回だけ書き込む簡素化されたデータパイプラインを構築し、運用システムと分析システム間の複雑なETLプロセスを排除します。レイクハウスアーキテクチャは、統一されたテーブル形式を介してバッチとストリーミングワークロードの両方をサポートします。

データアナリスト は、使い慣れたSQLインターフェイスを介してすべての組織データにアクセスし、基になるストレージの複雑性を理解せずに、オペレーションのPostgreSQLデータと履歴レイクハウステーブルの両方を照会します。

プラットフォームチーム は、マルチプルのコンピューティングエンジンをサポートする統合分析アーキテクチャを実装します。 Sparkは複雑な変換を処理し、Analytics Acceleratorはインタラクティブクエリを提供し、すべてが同じ基になるデータにアクセスします。

Lakehouseアーキテクチャを展開する方法#

基本的な展開パターン#

ハイブリッドマネージャーまたは自己管理インストールを介して専用のLakehouseノードを展開します。

- - Configure storage location for lakehouse data
SELECT pgfs.create_storage_location(
  lakehouse_storage,
  s3://analytics-bucket/lakehouse,
  {"region": "us-east-1"}
);

- - Create external table over Iceberg data
CREATE TABLE sales_history () USING PGAA
WITH (
  pgaa.format = iceberg,
  pgaa.storage_location = lakehouse_storage,
  pgaa.path = warehouse/sales.db/transactions
);

- - Query seamlessly across storage tiers
SELECT
  DATE_TRUNC(month, sale_date) as month,
  SUM(amount) as revenue
FROM sales_history
WHERE sale_date >= 2024-01-01
GROUP BY 1;

統合OLTP + OLAPアーキテクチャ#

運用ワークロードと分析ワークロードを単一のプラットフォームに結合します。

- - Hot data in PostgreSQL
CREATE TABLE sales_current (
  sale_id BIGINT PRIMARY KEY,
  sale_date DATE,
  amount DECIMAL(10,2)
);

- - Cold data in lakehouse
CREATE TABLE sales_archive () USING PGAA
WITH (
  pgaa.format = iceberg,
  pgaa.managed_by = lakehouse_catalog,
  pgaa.catalog_table = sales_historical
);

- - Unified view across tiers
CREATE VIEW sales_complete AS
SELECT * FROM sales_current
UNION ALL
SELECT * FROM sales_archive;

アーキテクチャコンポーネント#

ステートレスレイクハウスノード#

Lakehouseノードは、データをローカルに保存せずに、分析ワークロード用の専用の計算リソースを提供します。このステートレスデザインにより、データ量ではなくクエリ要求に基づいて柔軟なスケーリングが可能になります。

各ノードは、アナリティクスアクセラレーター拡張機能で強化された完全なPostgreSQLスタックを実行します。使い慣れたPostgreSQLインターフェイスは、既存のツールやアプリケーションとの互換性を保証し、基になるベクトル化エンジンが分析クエリ用に最適化されたパフォーマンスを提供します。

ノードは共有メタデータを介して自動的に調整され、マルチプルのインスタンスにわたる並列クエリの実行が可能になります。ロードバランサーは、利用可能なノード全体にクエリーを分散し、高可用性とホリゾンタル スケーラビリティーの両方を提供します。

ベクトル化されたクエリエンジン#

Apache DataFusionは、ベクトル化実行エンジンを強化し、列状データを行ごとではなくバッチで処理します。このアプローチにより、CPUキャッシュ使用率が最大化され、分析操作を劇的に高速化するSIMD最適化が可能になります。

エンジンは、フィルタとプロジェクションをストレージレイヤーに自動的にプッシュし、データ転送を最小限に抑えます。パーティションプルーニングにより、読み取りが開始される前にデータファイル全体が検討対象から除外されます。これらの最適化を組み合わせることで、 PostgreSQLの互換性を維持しながら、専用の分析データベースに迫るクエリパフォーマンスを提供します。

アダプティブクエリーの実行は、実行中に発見された実際のデータ特性に基づいて、処理戦略を調整します。初期統計は計画をガイドしますが、エンジンは、クエリの進行に応じて結合順序と集計戦略を動的に最適化します。

ストレージ抽象化レイヤー#

PostgreSQL File SystemPGFSは、多様なオブジェクトストレージシステムへの統一アクセスを提供します。この抽象化レイヤーは、認証、プロトコルの違い、およびパフォーマンスの最適化を透過的に処理します。

このシステムは、マルチプルのストレージバックエンドを同時にサポートし、クラウドプロバイダーにまたがる、またはクラウドとオンプレミスのストレージを組み合わせたクエリを有効にします。インテリジェントなキャッシュにより、基になるテーブル形式の一貫性要件を尊重しながら、繰り返しのメタデータ操作が削減されます。

接続プーリングと再試行ロジックは、クラウド環境で一般的な一時的なネットワーク問題を処理します。ストレージレイヤーは、観察されたレイテンシーとスループット特性に基づいて、要求パターンを自動的に調整します。

テーブルフォーマットの統合#

Apache IcebergとDelta Lakeのネイティブサポートにより、より広範なデータエコシステムとの相互運用性が可能になります。 Analytics Acceleratorは、テーブルのメタデータを読み取り、手動構成を必要とせずにスキーマ、パーティション、およびファイルの場所を理解します。

Icebergテーブルの場合、システムは、スキーマの進化、隠しパーティショニング、タイムトラベルクエリを含む完全な機能セットをサポートしています。カタログの統合により、複数のコンピューティングエンジン全体での自動テーブル検出とメタデータの同期が可能になります。

デルタレイクのサポートは現在読み取り操作に焦点を当てており、既存のデータレイク投資へのアクセスを提供します。トランザクションログの解析は透過的に発生し、デルタテーブルを標準のPostgreSQLリレーションとして表示します。

パフォーマンス特性#

クエリ最適化戦略#

クエリオプティマイザーは、実行プランを生成するときにレイクハウス固有の特性を理解します。テーブル形式のメタデータからの統計は、結合順序と集計戦略をガイドします。オプティマイザーは、パーティションプルーニングの有効性とメタデータ操作のオーバーヘッドのバランスをとります。

述語プッシュダウンは、単純なフィルターを超えて、複雑な式と結合を含めます。システムはクエリを書き換えて、ストレージレイヤーで実行される操作を最大化し、データの移動と計算要件を削減します。

コストベースの最適化では、ネットワーク遅延、データの局所性、およびフォーマット固有の特性を考慮します。プランは、データがキャッシュ、リージョンストレージに存在するか、またはクロスリージョン転送が必要かどうかに適応します。

キャッシングアーキテクチャ#

複数のキャッシュレイヤーは、分析ワークロードで一般的な繰り返しアクセスパターンを最適化します。メタデータのキャッシュにより、カタログ検索とスキーマ検出操作の繰り返しが不要になります。ファイルレベルのキャッシュは、頻繁にアクセスされるParquetファイルをローカルSSDに保存します。

クエリ結果のキャッシュは、同じクエリが繰り返し実行されるダッシュボードとレポートワークロードに対応します。キャッシュ無効化メカニズムはテーブルフォーマットのバージョン管理を尊重し、基になるデータが変更された場合でも一貫性を保証します。

適応型キャッシュ管理は、アクセスパターン、クエリコスト、および使用可能なリソースに基づいて、保持を優先します。ホットデータはキャッシュされたままですが、コールドデータはエージアウトし、最適なリソース使用率を維持します。

スケーラビリティーの考慮事項#

ホリゾンタル スケーリングは、ノードを追加して、実行中のワークロードを中断せずにクエリの同時実行性の増加を処理します。ステートレスアーキテクチャにより、新しいノードはすぐにクエリ処理能力に貢献します。

垂直スケーリングは、より多くのメモリまたはCPUを必要とする複雑な分析クエリに対して個々のノードリソースを調整します。システムは、利用可能なリソースに基づいて並列処理を自動的に調整し、リソースを枯渇させることなく使用率を最大化します。

ストレージのスケーリングはオブジェクトストレージを介して独立して発生し、事実上無制限のデータの増加をサポートします。コンピューティングとストレージを分離することにより、組織は比例するコンピューティングコストなしで長年の履歴データを保持できます。

統合パターン#

階層化ストレージの実装#

組織は、PostgreSQL操作テーブルとレイクハウス履歴テーブルを組み合わせることにより、階層化ストレージを実装します。トランザクションの一貫性が必要な最近のデータはPostgreSQLに残りますが、古いデータはオブジェクトストレージに移行します。

自動移行ポリシーは、経過期間、アクセスパターン、またはビジネスルールに基づいてデータを移動します。移行プロセスは、データの整合性を維持しながら、行指向のPostgreSQLデータを、分析クエリ用に最適化された列状のParquetファイルに変換します。

透過的なクエリルーティングは、述語に基づいてクエリを適切な層に転送します。時間ベースのクエリは、両方の層からの結果を自動的に結合し、手動クエリ変更なしで完全な分析ビューを提供します。

マルチエンジンアナリティクス#

レイクハウスアーキテクチャは、さまざまなワークロードタイプに専用のコンピューティングエンジンをサポートします。 Apache Sparkは複雑なETL変換を処理し、アナリティクスアクセラレーターはインタラクティブSQLクエリーを提供し、機械学習プラットフォームはトレーニングデータに直接アクセスします。

共有テーブルフォーマットにより、どのエンジンが変更を実行するかに関係なく、一貫性が保証されます。トランザクションの分離により、異なるエンジンからの同時操作間の競合が防止されます。この専門化により、組織は単一の真実の情報源を維持しながら、各ジョブに最適なツールを使用できます。

ストリーミング分析#

最新のストリーミングプラットフォームは、マイクロバッチコミットを使用してレイクハウステーブルに継続的に書き込みます。 Analytics Acceleratorは、スナップショット分離を介してほぼリアルタイムの可視性を提供し、進行中の更新にもかかわらず一貫したクエリ結果を保証します。

Apache KafkaやAmazon Kinesisのようなイベントストリーミングシステムは、耐久性のあるストレージと分析処理のためにレイクハウステーブルにデータを配信します。ストリーミングインジェストとSQL分析を組み合わせることで、リアルタイムの不正検出、操作モニタリング、顧客行動分析などのユースケースが可能になります。

運用上の考慮事項#

導入モデル#

ハイブリッドマネージャーを介した 管理展開 は、自動化されたプロビジョニング、スケーリング、およびメンテナンスを提供します。プラットフォームは、ノードのライフサイクル、セキュリティ更新、およびパフォーマンスの最適化を透過的に処理します。

自己管理展開 は、インフラストラクチャと構成の完全な制御を提供します。特定のコンプライアンス要件または既存のKubernetesインフラストラクチャを持つ組織は、多くの場合、自己管理型の展開を選択します。

ハイブリッド展開 は、管理対象コントロールプレーンと自己管理データプレーンを組み合わせます。このアプローチは、操作の簡素化と規制対象業界で一般的なデータ主権要件のバランスをとります。

モニタリング要件#

効果的なモニタリングは、クエリパフォーマンス、リソース使用率、およびストレージアクセスパターンを追跡します。クエリ実行時間、スキャンされたデータ、およびパーティションプルーニングの有効性は、最適化の機会を示します。

ストレージメトリックは、パーティショニング戦略とキャッシュポリシーを通知するアクセスパターンを明らかにします。データアクセスのホットスポットは、マテリアライズドビューまたは代替パーティションスキームの候補を示唆します。

リソース使用率メトリックは、キャパシティプランニングとスケーリングの決定をガイドします。 CPU、メモリ、およびネットワークの使用率パターンは、ワークロードがコンピューティング、メモリ、またはI/Oバウンドであるかどうかを示します。

セキュリティアーキテクチャ#

レイクハウスセキュリティモデルは、マルチプルのレイヤーにわたって多層防御を実装します。 PostgreSQLのロールベースのアクセス制御はユーザー権限を管理し、オブジェクトストレージIAMポリシーはデータアクセスを制御します。

暗号化は、クラウドプロバイダーの暗号化サービスまたはカスタマー管理キーを使用して、保存データを保護します。トランスポートレイヤーセキュリティは、計算ノードとストレージシステム間で移動しているデータを暗号化します。

監査ログは、コンプライアンスとセキュリティ分析のためのすべてのデータアクセスを追跡します。クエリログ、ストレージアクセスログ、および認証イベントは、システムの使用状況を完全に可視化します。

目次