Monitoring and maintaining analytical tables

Monitoring and maintaining analytical tables#

Postgres Analytics AcceleratorPGAAは、Postgresプロンプトから直接ストレージ使用率、テーブルフォーマット、およびデータレイクテーブルのメタデータの状態を監査するのに役立つビルトイン機能を提供します。

テーブル統計の分析#

数百の標準のPostgresテーブルがある環境では、PGAAによって管理されているテーブルを特定することが困難になる場合があります。 pgaa.list_analytics_tables() ファンクションは、すべてのレイクハウス統合テーブルのグローバル概要を提供します。

SELECT * FROM pgaa.list_analytics_tables();

ファンクション出力は、次の洞察を提供します。

  • IDとフォーマット スキーマ、テーブル名、およびストレージフォーマットIceberg、Delta、またはParquetなどを表示します。

  • ストレージの場所 データファイルが存在する場所への正確なパス。

  • カタログのメタデータ 外部カタログを使用する場合、このファンクション出力には外部カタログサービス名、名前空間、およびリモートテーブル名が表示されます。

  • レプリケーションステータス データ移動の現在の状態を表示しますPGDレプリケーションシナリオの場合のみ。

  • ストレージメトリック

    • object_storage_snapshot_size_bytes 最新のライブスナップショットのサイズ。これは、SELECT * 中にスキャンされたデータの実際の量を表します。

    • object_storage_total_size_bytes 現在のバージョンで使用されていないメタデータ、マニフェスト、および履歴データファイルを含むバケット内の合計フットプリント。

    • object_storage_total_size_bytes メタデータを含むバケット内の合計フットプリント、マニフェスト、および履歴データファイルは使用されません。

pgaa.lakehouse_table_stats() ファンクションは、テーブルの物理的特性に関する特定の情報を提供します。これは、キャパシティプランニングとクエリパフォーマンスの微調整に重要です。

SELECT * FROM pgaa.lakehouse_table_stats(my_schema.my_table::regclass);

このファンクションは、基になるオブジェクトストレージを照会して、特定のマッピングの「内部」で何が起こっているのかを確認します。それはあなたに役立ちます

  • ライブデータとデッドデータを区別する 古いトランザクションログまたは圧縮されていない小さなファイルによってストレージが「無駄」になっている量を正確に特定します。

  • 成長の監視 新しいデータが外部ソースから取り込まれ、スナップショットサイズが時間の経過とともにどのように進化するかを追跡します。

  • キャッシュ認識 このファンクションの結果は、 pgaa.lakehouse_table_stats_cache_ttl_s 構成パラメーターによって制御されます。絶対的な最新の統計が必要であるのに表示されない場合は、キャッシュTTLが0に設定されていることを確認します。

latest_snapshot_size とtotal_size を比較することは、パフォーマンスとコストのバランスを保つために重要です。スナップショットのサイズは、「ライブ」データ、クエリー中にスキャンされる実際のボリュームを表しますが、合計サイズには、履歴バージョン、トランザクションログ、非圧縮行などのバケットフットプリント全体が含まれます。

IcebergやDelta Lakeのような形式では、合計サイズがスナップショットのサイズを超えて、タイムトラベルとロールバックをサポートします。これらの値の大きなギャップは、履歴オーバーヘッドの蓄積を示し、 VACUUM またはコンパクションを実行する信号として機能します。これらのメトリックを監視することは、無駄のない高パフォーマンスのデータレイクを維持するのに役立ちます。

テーブルパフォーマンスの最適化#

分析パフォーマンスは、頻繁なデータの更新により何千もの小さなファイルが作成され、メタデータのオーバーヘッドを増加させる「小さなファイル問題」によって大きな影響を受けます。

デルタレイクのメンテナンスの実行#

デルタテーブルの場合、メンテナンスはバックグラウンドワーカーによってpgaa.launch_task() ファンクションを使用して非同期に処理されます。これにより、アクティブなSQLセッションをブロックせずに、負荷の高い操作をトリガーできます。

SELECT pgaa.launch_task(
    table_name => my_delta_table::regclass,
    task_type => compaction, -- or z-order, vacuum, purge
    options => {"target_size": "128MB"}
);

サポートされているタスクタイプは次のとおりです。

  • コンパクション 小さなファイルをより大きな最適化されたブロック target_size で定義にマージして、分析スキャンを高速化します。

  • Z-オーダー 複数の列にわたってデータを再構成して、関連する値が物理的に近くに保存されます。これにより、エンジンがクエリフィルタと一致しないファイル全体を無視するデータスキップが有効になります。

  • バキューム アクティブなスナップショットに関連付けられなくなり、指定された保持期間より古いデータファイルを削除します。これにより、オブジェクトストレージ領域が再利用されます。

  • Purge 特定のストレージパスからデータを明示的に削除する管理ツール。失敗したエクスポートの手動クリーンアップに役立ちます。

Delta Lakeのメンテナンス例

  • コンパクションを使用して、小さなファイルをより大きな256MBブロックにマージし、スキャンパフォーマンスを高速化します。

SELECT pgaa.launch_task(
    table_name => lakehouse.sales_data::regclass,
    task_type  => compaction,
    options    => {"target_size": "256MB"}
);

  • Z-オーダーを使用してデータを物理的に再編成して、customer_id およびregion の同様の値を持つ行が一緒に保存され、エンジンが無関係なファイルをスキップできるようにします。

SELECT pgaa.launch_task(
    table_name => lakehouse.sales_data::regclass,
    task_type  => z-order,
    options    => {"columns": ["customer_id", "region"]}
);

  • アクティブテーブル状態の一部でなくなり、7日より古いファイルをバキューム削除して、記憶領域を再利用します。

SELECT pgaa.launch_task(
    table_name => lakehouse.sales_data::regclass,
    task_type  => vacuum,
    options    => {"retention_period": "7 days"}
);

サポートされているオプションと例の完全なリストについては、 pgaa.launch_task() のファンクションリファレンスセクションを参照してください。

Icebergのメンテナンスの実行#

Icebergのメンテナンスは、Sparkエンジンを使用して同期的に実行され、複雑なメタデータの更新とマニフェストの書き換えがIcebergの一貫性保証に従っていることを保証します。

注釈

これらの操作を実行するには、pgaa.spark_connect_url 構成パラメーターを設定して、使用可能なSpark Connectサービスをポイントする必要があります。

pgaa.execute_compaction() ファンクションは、断片化したデータファイルをより大きくて効率の高いParquetファイルに統合し、クエリーのパフォーマンスを向上させ、メタデータを最適化します。

SELECT pgaa.execute_compaction(my_iceberg_table::regclass);

ファンクションpgaa.spark_sql() を使用して、Spark SQLクエリーを直接実行します。

SELECT pgaa.spark_sql(query, catalog_name);

Icebergのメンテナンス例

  • 標準のテーブル圧縮を使用して、断片化したデータファイルをより大きなファイルにマージし、Icebergマニフェストを更新します。

SELECT pgaa.execute_compaction(lakehouse.inventory_iceberg::regclass);

  • pgaa.spark_sql() を使用して、 rewrite_data_files Sparkタスクを介してメタデータのオーバーヘッドを削減します。

SELECT pgaa.spark_sql($$
        CALL preexisting.system.rewrite_data_files(
          table => "preexisting"."ns-1"."table-1",
          strategy => sort,
          sort_order => value DESC,
          options => map(rewrite-all, true)
        )
    $$);

サポートされているオプションと例の完全なリストについては、 pgaa.execute_compaction() のファンクションリファレンスセクションを参照してください。

目次