Concepts
========

このコンセプトガイドでは、機能レイヤーごとに編成されたアナリティクスアクセラレーターPGAAアーキテクチャの技術的基盤を提供します。

ストレージとテーブルフォーマット
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

**PGFSストレージ抽象化**
`Postgres File System (PGFS) <https://www.enterprisedb.com/docs/edb-postgres-ai/latest/ai-factory/pipeline/pgfs/>`_ は、PostgresとオブジェクトストレージS3、GCS、Azure間の統一インターフェイスを提供するクラウドネイティブストレージレイヤーです。認証、ネットワークの復元力、およびリモートオブジェクトのローカルテーブル構造へのマッピングを処理します。

**Delta Lake**
ACIDトランザクションをデータレイクに提供するオープンソースのストレージフレームワーク。

**トランザクションログ** 中心的なメタデータレコードDelta
LakeのデルタログまたはIcebergのスナップショットなどテーブルへのすべての変更を追跡し、データの一貫性を保証します。

**タイムトラベル**
特定のタイムスタンプまたはログバージョンを参照することにより、以前のバージョンのデータを照会する機能。

**スキーマの進化**
データセット全体を書き換えずに、テーブルのスキーマを変更する機能たとえば列の追加。

**Apache Iceberg** 大規模な分析データセット用の高性能テーブル形式。

**メタデータ**
ファイルレベルの統計を追跡し、効率的なデータのスキップを可能にする多層マニフェストシステム。

**スナップショット**
特定の時点でのテーブルのバージョン。クエリは常に一貫したスナップショットに対して実行されます。

**パーティションの進化**
既存のデータを書き換えずに、テーブルのパーティション化戦略を変更する機能たとえば、日次から月次への変更。

**Parquetカラムナストレージ**
PGAAによって使用される基になるファイル形式。データを行に保存する標準のPostgresとは異なり、Parquetは列にデータを保存します。

**圧縮とエンコード**
カラムナストレージでは、同様のデータ型が一緒に保存され、ストレージのフットプリントとI/Oオーバーヘッドが大幅に削減されるため、積極的な圧縮SnappyまたはZstandardのようなエンコードとデルタまたはディクショナリエンコーディングのようなエンコードが可能です。

カタログ
^^^^^^^^

カタログは、テーブルメタデータの信頼できる中心的なソースとして機能します。これらにより、さまざまなコンピューティングエンジンPostgres、Spark、Trinoがテーブルを検出、スキーマを解決し、共有データレイク全体でトランザクションの整合性を維持できます。

**Iceberg REST**
PGAAが外部カタログと通信するために使用する標準化されたAPI。これにより、EDBは、Lakekeeper、Tabular、Snowflake
PolarisなどのREST仕様をサポートするカタログサービスと統合できます。

**AWS S3テーブル** AWSの管理対象カタログおよびストレージサービス。
PGAAはS3テーブルと統合して、サーバーレスメタデータレイヤーを提供し、AWSエコシステム内のIcebergテーブルの管理を簡素化します。

クエリーの実行
^^^^^^^^^^^^^^

**テーブルアクセスメソッドTAMアーキテクチャ**
PGAAがカスタムストレージエンジンをプラグインできるようにする内部Postgres
API。これにより、Postgresプランナーは、ネイティブローカルテーブルであるかのように、リモートオブジェクトストレージと対話できます。

**DirectScan**
クエリが完全に分析実行エンジンSeafowlまたはSparkにオフロードされるパフォーマンスの最適化。これは、クエリが分析テーブルのみを参照する場合に発生し、ベクトル化エンジンが操作全体を処理し、最終結果をユーザーに返すことができます。

**CompatScan**
ローカルのPostgresテーブルをリモート分析テーブルに結合するために、またはPostgresでのみサポートされているファンクションを処理するために使用されるハイブリッド実行モード。

**部分プッシュダウン**
PGAAは、フィルタと投影をオブジェクトストレージレイヤーにプッシュダウンすることによりクエリを最適化し、必要な行のみをPostgresにストリーミングして、結合または複雑なローカル操作を完了します。

**コストベースのプランニング**
Postgresオプティマイザーがレイクハウスメタデータからの統計行数やデータ分散などを使用して、ハッシュ結合またはネスト化の選択など、クエリを実行する最も効率的な方法を決定するプロセスループ。

**Seafowlでのベクトル化実行**
Seafowlエンジンのコア処理テクノロジー。データを行ごとに処理する代わりに、データをバッチベクターで処理します。これは、最新のCPU命令SIMDを活用して、マルチプルのデータポイントで数学的操作を同時に実行し、分析クエリを劇的に高速化します。

キャッシング
^^^^^^^^^^^^

ネットワークベースのオブジェクトストレージに固有のレイテンシーを最小限に抑えるために、PGAAは多層キャッシング階層を実装します。これにより、繰り返されるクエリーをローカルストレージと同等の速度で実行できます。

**オブジェクトストアキャッシュ**
このレイヤーは、レイクハウスノードのローカルSSDのデータレイクから取得した実際のデータブロックParquetファイルをキャッシュします。頻繁にアクセスされるデータをコンピューティングエンジンの「近く」に保つことにより、PGAAは、同じデータセグメントのリモートオブジェクトストアへの繰り返しのGET要求のオーバーヘッドを回避します。

**メタデータキャッシュ**
データレイクの構造情報ファイルマニフェストやスキーマ定義などのローカルの高速コピーを維持します。この方法により、エンジンはパーティションプルーニングとファイルレベルのフィルタリングを瞬時に実行でき、リモートストレージプロバイダーを繰り返し照会する高いレイテンシーなしで、取得するデータを正確に特定できます。

メタデータキャッシュは、データレイクテーブルの構造ファイルマニフェスト、スキーマ定義、パーティションの場所を含むを保存します。
IcebergおよびDelta
Lakeテーブルは、何千もの個々のファイルで構成される場合があるため、この「マップ」をキャッシュすることにより、クエリプランナーはストレージプロバイダーに連絡せずに無関係なデータをほぼ瞬時にスキップできます。

**テーブル統計キャッシュ** ``pgaa.lakehouse_table_stats()``
ファンクションをサポートするために物理テーブルサイズのローカルレコードを維持します。クエリプランナーは、プランの精度を高めるために実行時にストレージプロバイダーから新しいメタデータを取得しますが、このキャッシュにより、ファンクションはライブリモートスキャンを必要とせずにデータレイクオブジェクトのスケールの即時の可視性を提供できます。