数分でテラバイト規模のデータをLakebase Postgresにロード

Postgresのような運用データベースは、データのサブセットに対して高い並列性と低レイテンシでクエリを確実に実行するように構築されています。しかし、テラバイト規模のデータロードやテーブル全体をスキャンする分析クエリのような一括処理は、この信頼性に影響を与えることがよくあります。これらの操作はアプリケーションのワークロードと同じリソースを奪い合い、パフォーマンスの低下やダウンタイムのリスクを引き起こします。

私たちの目標は、Lakebase Postgresを運用ワークロードにとって最も安全で信頼性の高い場所にする事です。これを実現するため、重いバッチ操作をプライマリコンピュートから、これらのタスク専用に作られたSparkのような分散エンジンにオフロードします。これは、トランザクションエンジンと分析エンジンの両方がレイク内の全く同じデータに対して機能することを可能にするLTAP（Lake Transactional/Analytical Processing）アーキテクチャによって実現されています。

この分離が行われない場合、チームは一括処理に対して極めて慎重にならざるを得ません。データの鮮度を犠牲にし、業務時間外にまれにロードを実行したり、複雑なバックフィルやチェックポイント処理を手動で管理したりします。現在では、LTAPアーキテクチャを活用することで、取り込みパイプラインを完全にSparkにオフロードし、稼働中のシステムのパフォーマンスを損なうことなく、アプリが最新データを受け取れるようになります。

数字で見る成果

ベータ期間中、あるお客様はSynced Tablesを使用して毎日約10億行をLakebaseにロードしていました。LTAPアーキテクチャを活用することで、運用ワークロードに全く影響を与えることなく、ロードを劇的に高速化しました。

以前は、一括ロードに8時間以上かかり、CPUとメモリが完全に飽和していました。Lakebaseのオートスケーリングを使用しても、同期を維持するためだけにOLTPリソースを大幅に過剰プロビジョニングせざるを得ませんでした。これは、従来のPostgresアーキテクチャでは、プライマリが永続状態の唯一のゲートキーパーであるために発生します。一括ロードはこの単一のボトルネックを通過せざるを得ず、インポートされたすべての行が、稼働中のアプリケーショントラフィックを処理しているのと同じインスタンス上でヒープページを生成し、インデックスを更新し、WALレコードを書き込むことを意味します。

LTAPアーキテクチャはプライマリインスタンスへの負荷を完全に軽減し、稼働中のアプリケーショントラフィックを保護しました。データ量の増加に伴いロードスループットをほぼ線形にスケーリングできる、分散エンジンのフルパワーが得られます。社内ベンチマークによると、1 TBのロードにかかる時間は現在5分未満です。

注：このベンチマークは、データロード時間（ヒープページの構築）を測定したものです。ロードされたこのデータのインデックス構築の並列化にも意欲的に取り組んでいます。

本記事の残りの部分では、PostgresのようなOLTPデータベースにデータを一括ロードする際の課題を深く掘り下げ、それらを解決するためにLTAPアーキテクチャをどのように活用しているかを探ります。

Postgresにおける大規模データの一括ロードの問題

ネイティブのPostgresのCOPYコマンドは、標準的で小規模な取り込みには効率的です。

しかし、お客様が運用環境と分析環境を近づけるにつれて、スケールが変化します。ますます一般的になりつつあるワークロードとして、運用クエリパターンを持つアプリケーションに、大規模なゴールド層のLakehouseテーブルを提供するというものがあります。それほど極端な量のデータを本番データベースに流し込むと、2つの根本的な限界が露呈します：

1. インポートされるすべての行が単一のプライマリライターを通過する必要があるため、本質的にロードが遅くなります。
2. ロードに使用されるのと同じコンピュートが、アプリケーションクエリの処理にも使用されます。一括ロードは多大なCPU、I/O、接続、WAL帯域幅を要求し、OLTPトラフィックと競合します。

これは、ロードを分散Sparkジョブとして開始した場合でも変わりません。Sparkはソースパーティションを並列に読み取ることができますが、各行は依然として1つのPostgresライターを通過する必要があります：

1. ワーカーはCOPYを介して行をPostgresに送信します
2. プライマリはそれらの行をヒープページおよびインデックスページに変換します
3. プライマリは変更を先行書き込みログ（WAL）に記録します
4. ロードをコミットする前に、WALを永続ストレージにフラッシュする必要があります

従来の一括ロードは、単一ライターによってボトルネックが発生します

ソース側は水平にスケーリングできますが、宛先側はできません。Sparkエグゼキュータを追加するとスキャンは高速化されますが、単一ライターのボトルネックは解消されません。さらに、この同じPostgresプライマリがオンラインアプリケーションのトランザクションを処理しています。大規模なインポートは、CPU、メモリ、I/O、接続、WAL帯域幅をめぐってこれらと競合します。レイテンシが増大するため、チームはアクセスが少ない時間帯にロードをスケジュールしたり、日常のトラフィックではなく最大のインポートに合わせてプライマリをプロビジョニングしたりすることがよくあります。

LTAPがもたらす変化

LTAPアーキテクチャは、プライマリが永続的なPostgres状態を作成する唯一の方法ではなくなるため、これを回避する道を開きます。 Lakebaseではトランザクションコンピュートはステートレスです。永続状態はプライマリのローカルディスクではなく、分散ストレージレイヤーに存在します。ある意味で、Postgresはストレージのクライアントであり、クエリやトランザクションを処理しますが、すべての新しいページを具現化するプロセスである必要はありません。

一括ロードの場合、SparkがPostgres状態を構築してストレージに書き込み、プライマリはその結果を公開するだけで済むことを意味します。

運用上のメリットは以下の通りです：

• 一括ロードがプライマリ上のOLTPと競合しません。これは稼働中のコンピュートエンドポイントの外で実行されます。アプリケーションワークロードは、必要なCPU、I/O、接続、WAL帯域幅を維持できます。
• 同じ宛先への大規模なロードを同時に実行できます。各インポートはプライマリ上に単一のWALレコードを書き込んで終了するため、ロードが互いのCOPYストリームの後ろで順番待ちをすることがなくなります。
• プライマリはロードサイズに合わせてスケーリングする必要がありません。1 CUのプライマリは、Sparkが別のコンピュートで数十億行をロードしている間もトラフィックを処理し続けることができ、Sparkコンピュートはロードが完了するとすぐに終了します。

有効なPostgresページを安全かつ並列に構築する

Postgresファイルの構築と主キーインデックスの作成には、さまざまな最適化が存在します。

ヒープの並列構築

Sparkが生成するページは、プライマリが構築した場合と同様に、宛先データベースに対して有効である必要があります。

各Sparkエグゼキュータは、pg_upgradeがメジャーバージョンアップグレード全体でカタログOIDを保持するために使用するのと同じメカニズムであるバイナリアップグレードモードで、サンドボックス化されたPostgresインスタンスを起動します。これを利用して宛先のカタログOIDを各サンドボックスに移植し、生成されたページに埋め込まれたOIDが宛先のOIDと確実に一致するようにします。ドライバーはまた、同時に作成されたオブジェクトが衝突しないように、重複しないOID範囲をサンドボックスに割り当てます。

各サンドボックス内では、FREEZEを備えたバイナリCOPYが、そのエグゼキュータのヒープのスライスを構築します。フリーズ処理により、インポートされたタプルはコミット済みとしてマークされるため、Postgresはサンドボックスからのトランザクション履歴を参照することなく、それらを可視として扱うことができます。

次に、各ワーカーは生成されたすべてのページのチェックサムを計算します。Lakebaseのページサーバーはファイルを取り込む際にそれらのチェックサムを検証し、インポートされたページが正式なものになる前に破損を検出します。

バイナリアップグレードモード、フリーズされたタプル、調整されたOID、チェックサム検証が連携することで、Sparkは宛先が通常のPostgresページとして読み取れるページを生成できます。これをPostgresコアを変更することなく、Postgres拡張機能とテーブルアクセス方式を通じて実装しています。

使い捨てのサンドボックスにより、UNLOGGEDヘルパーテーブルなどのパフォーマンス最適化も可能になります。これらは安全機構ではなく最適化であり、アプリケーショントラフィックがサンドボックスを共有しないため、不必要なWALやロックの競合を回避できます。

ヒープをスキャンせずにインデックスを構築する

Bツリーはキー空間全体にわたる1つの順序構造であり、そのリーフエントリにはヒープを指し戻すキーとタプルIDのペアが含まれています。

通常、Postgresはヒープをスキャンすることでそれらのペアを取得します。しかしここでは、ヒープがアップロードされたスライスに分散されているため、そのすべてをインデックス作成ワーカーにダウンロードすると、並列構築のメリットの多くが失われてしまいます。

インデックスビルダーは、実際にはヒープの内容を必要としません。必要なのは、ヒープスキャンによって生成される(key, ctid)ペアのストリームです。そのため、前のステップの各ヒープワーカーは、スライスを構築しながら、キー列とタプルIDを個別のオブジェクトストレージファイルにエクスポートします。

これらのレコードを、元の行ではなくエクスポートされたキー列とタプルIDのみを保持するヘルパーテーブルに投入します。CREATE INDEXの間、カスタムテーブルアクセス方式はheapamと同じようにヘルパーテーブルをスキャンしますが、ヘルパー行自体の物理タプルIDではなくctidを各インデックスエントリに書き込みます。レコードがロードされると、各スライスローカルのctidは先行するヒープスライスの累積サイズ分だけシフトされ、結合されたヒープ内でのタプルの最終位置を指すようになります。要するに、Postgresの標準的なBツリービルダーは、このヘルパーテーブルを変更なしでスキャンし、ダウンロードしたことのないヒープに対してインデックスを作成できます。これにより、ヒープ全体の移動が、大幅に小さいキーとタプルIDの表現の移動に置き換わります。

結果をPostgresに渡す

ヒープおよびインデックスのスライスがオブジェクトストレージに配置されると、Sparkドライバーはマニフェストを書き込み、送信先で1つのSQL関数を呼び出します。プライマリはインポートをコンパクトなWALレコードとして記録します。従来のCOPYではsafekeeperクォーラムを通じて全データ量が送信されますが、ここではインポートの記述のみを送信します。

ページサーバーはアップロードされたファイルを信頼できるページとして認識し、チェックサムを検証します。また、最初の読み取りでオブジェクトストレージからのコールドフェッチが発生しないよう、ローカルSSDにページをプレウォームします。最後に、プライマリはステージングされたデータをユーザーに表示される同期済みテーブルへアトミックにスワップします。

そのトランザクションがコミットされるまで、インポートされたテーブルは分離されたままとなります。コミット後、プライマリは標準的なPostgresフォーマットとインターフェースを通じて作成された通常のヒープおよびBツリーページを認識します。

今すぐ始めましょう。

LTAPアーキテクチャを使用してSynced Tablesを強化し、レイクハウスからゴールドデータセットを提供する際の同期を大幅に高速化します。レイクハウスから手動でReverseETLジョブを実行している場合は、Lakebaseの利用を検討してください。

このプロトコルを汎用化し、インデックス構築やマイグレーションなどの大規模な運用・保守に対応できるようにすることを楽しみにしています。LTAPアーキテクチャを備えたLakebaseは、OLTPワークロードを実行するのに最適な環境です。

LakebaseとSynced Tablesをまだお試しでない方は、今すぐ始めましょう。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事