LTAPの誤解を解く

Reynold Xin の投稿「From monolith to Lakebase to LTAP」では、LTAP とは何か、そして Lakebase アーキテクチャがそれをどのように実現するのかについて説明されています。つまり、CDC パイプラインや 2 つ目のデータベースを使用せず、Postgres とアナリティクスの両方に対応する、ガバナンスの効いた運用データの単一コピーです。

その後に続いたコメントの多くは、その主張を既存のシステム担当者の視点で解釈したものでした。よく見られた解釈は以下の 4 つです。

• 「LTAP は名前を変えただけの CDC である」
• 「データの単一コピーが持てる物理レイアウトは 1 つだけなので、ポイントルックアップまたはスキャンの一方は遅いはずである」
• 「オブジェクトストレージ上の Iceberg または Delta テーブルは本質的に古いデータである」
• 「Postgres はすでに抽出パス（ロジカルレプリケーション）を提供している」

これらの神話はいずれも、Lakebase がデータをどのように保存するかについての誤った前提に基づいています。1 つずつ確認していきましょう。

神話 1: 「LTAP はレプリケーションである」

現実: LTAP は、レイク内に各テーブルの耐久性のあるコピーを 1 つ保持します。その手前にあるレイヤーは、そのテーブルの耐久性と高速性を確保するために同じバイトの一部を保持しますが、それらのいずれも 2 つ目のデータベースではありません。

外側から見ると、LTAP は見慣れたパイプラインのように見えることがあります。Postgres が行を書き込み、プロセスがログをテールし、変更が Iceberg テーブルに反映され、アナリティクスが Iceberg を読み取ります。そのパイプラインは CDC です。また、それはロジカルレプリケーション、ミラーリング、およびほとんどのゼロ ETL 製品の構造でもあります。そのため、LTAP を同じ設計として分類するのは簡単です。

そうではない理由を理解するために、何が「2 つ目のコピー」としてカウントされるかを正確に把握しておくと役立ちます。システムが同じデータを複数の場所に保持することになる方法には、主に 2 つの異なる方法があります。 

• レプリケーションは、一方から他方へ変更を送信することで、2 つのデータベースを同期させます。各側には独自のカタログと独自のタイムラインがあり、どちら側も信頼できる情報源（ソースオブトゥルース）としてクエリを実行できます。送信が停滞すると、2 つのコピーの乖離が進み、それらを強制的に再結合するものはありません。
• 階層化（タイアリング）は、1 つのデータベースを維持し、その手前にキャッシュのスタックを配置します。読み取りを高速化するために、キャッシュは同じバイトの一部を保持します。読み取りがキャッシュにヒットしなかった場合、1 つ下のレイヤーに移動するため、レイテンシが発生します。2 つ目のカタログを作成することはなく、キャッシュが失われても、テーブルは失われません。

したがって、テストはシンプルです。このレイヤーに対して、独自のデータベースとしてクエリを実行できるか、あるいはフェイルオーバーできるかということです。できる場合はレプリカであり、できない場合はティアです。

そのテストに従うと、Postgres は常に階層化されていました。WAL、バッファキャッシュ、およびインデックスはすべて、ヒープと重複するバイトを保存します。インデックスには独自のカタログやタイムラインがないため、誰もインデックスをテーブルのレプリカとは呼びません。 

LTAP はその階層をそのまま維持します。それをオブジェクトストレージに移行し、レイクハウスエンジンが一番下の耐久性のあるティアを読み取れるようにします。

書き込みとそれに続く読み取りを行った場合の、Lakebase におけるその階層の様子は次のとおりです。

• 書き込みは、その WAL がセーフキーパーのクォーラムに到達したときに永続化されます。その後、ページサーバーがログを適用し、ホットページをメモリ内およびローカルディスク上に保持し、データをオブジェクトストレージにマテリアライズします。
• 読み取りはコンピュートノードから始まります。コンピュートノードはバッファキャッシュとローカルファイルキャッシュを保持しています。インデックス、TOAST、および可視性マップは同じホットパスに存在します。そこにキャッシュされていないページは、ページサーバーから取得されます。

オブジェクトストレージ自体も同様に機能します。オブジェクトを S3 に PUT すると、多くの場合イレージャコーディングを使用して可用性ゾーンを跨いで、複数回保存されます。API は依然として 1 つのオブジェクトを指定し、コピー間で同期ジョブは実行されません。Lakebase は、ログ、キャッシュ、ページサーバー、オブジェクトストレージという同じアイデアをレイクの手前に重ねています。追加のファイルは、1 つのテーブルの耐久性と高速性を確保するためのものです。

CDC は確かに 2 つ目のデータベースを作成します。ロジカル変更ストリームを外部スキーマにデコードし（通常は主キーでキー設定されます）、ソースが二度と読み取らないテーブルにアップサートします。その 2 つ目のテーブルに対して単独でクエリを実行できますが、ソースとの同期がずれる可能性があります。型の乖離、DDL の欠落、レプリケーションスロットによる行のドロップ、選択されなかったテーブルの非表示などが発生します。その結果、2 つのカタログが生成されます。

LTAP には、同期を維持すべき 2 つ目のテーブルはありません。オプトインするテーブルのリストもありません。Postgres に存在するテーブルはレイクにも存在し、プライマリが提供するページはそのストアのキャッシュとなります。

神話 2: 「単一のコピーはルックアップやスキャンの低速化を意味する」

現実: 同じ行に対する 2 つのロスレスエンコーディングは、ポイントルックアップにはヒープページ、スキャンには Parquet のように、異なるアクセスパスを提供できます。各クエリは、自分にとって高速なレイアウトを読み取ります。

追加ファイルが階層構造になっているとしても、レイアウトは別の問題として残ります。ポイントルックアップは行に対して効率的で、スキャンは列に対して効率的です。ディスク上のエンコーディングが 1 つだけである場合、それらのアクセスパターンのいずれかが I/O のコストを支払うことになります。テーブルを単一の論理コピーと呼んでも、それは変わりません。

その推論は正しいですが、1 つの前提、つまり「1 つのコピーは 1 つのエンコーディングを意味する」という前提に基づいています。2 つのフォーマットがロスレスで同じ行を表現できる限り、そうとは限りません。 

したがって、問題は LTAP の 2 つのフォーマットがロスレスであるかどうかです。

• プライマリフォーマットは Postgres のヒープページであり、ポイントルックアップやアップデートに適しています。
• 2 つ目のフォーマットは分析アクセス用に構築されています。Delta または Iceberg の背後にある Parquet です。値は保持され、ファイルには元のページを再構築するのに十分な物理メタデータ（ヒープブロック、オフセット、および MVCC バージョン）が含まれています。Parquet でロスレスに表現できない値は、強制変換されたりドロップされたりすることはありません。同じテーブル内のオーバーフローフィールドに格納されて移動します。

何も失われないため、カラムナコピーをレイク内の耐久性のあるストアにし、ヒープページをそのキャッシュにすることができます。これにより、各アクセスパスは自分に適したフォーマットを読み取ります。ルックアップは、コンピュートノード、ローカルディスク、およびページサーバー上の 8 KB ページにヒットします。スキャンは、OLAP エンジンを介して Parquet にヒットします。インデックスはホットティアに残ります。Parquet にトランスコードされることはありません。

Postgres はすでにこのように動作しています。異なるアクセスパスのために、同じ行に対してヒープとカバリングインデックスという 2 つの物理構造を保持しています。誰もインデックスを customer の CDC レプリカとしては扱いません。SELECT * FROM t WHERE id = 1 と SELECT count(*) FROM t は、1 つのテーブルに対する 2 つのアクセスパスです。

より限定的な観点としては正しいと言えます。Postgres からのカラムナファイルはヒープ順序です。ページがコンパクションごとに書き換えられる単位であるため、行はページ番号順に配置されます。そのレイアウトは、ページの再構築や、ダーティページのみの書き換えにおいて効率的です。WHERE order_date >= … にとっては、クラスタリングキーとしては不適切です。ウェアハウスのクエリにそのクラスタリングが必要な場合は、運用ソースからシルバーテーブルがすでに導出されている方法と同様に導出できます。不要になったのは、レイクのコピーを作成することを目的としていた CDC パイプラインです。

神話 3: 「オープンテーブルフォーマットは結果整合性を意味する」

現実: すべての分析クエリは一貫性のあるスナップショットを読み取ります。まだレイクに到達していないコミットはページサーバーから読み取られるため、クエリの前にコミットされたデータが漏れることはありません。

IcebergとDeltaはオブジェクトストレージ上でスナップショット分離を提供し、オブジェクトストレージは高レイテンシです。そのため、分析は常に遅れ、多くの小さなテーブルを常に最新に保つことができず、テーブル間の結合が一貫性を保てないという結論に至るのも当然です。この説明は、レイクへのCDCインジェクションに当てはまります。

これは1つの前提に依存しています。それは、クエリがオブジェクトストレージにすでに書き込まれたものしか見ることができないという点です。LTAPでは、クエリはまだオブジェクトストレージに存在しないページも参照できます。これにより結果が変わり、クエリの処理をたどることで最もよく理解できます。

分析クエリが開始されると、

1. Postgresに現在のLSNを要求します。これはメタデータのルックアップです。
2. そのLSNまでにマテリアライズされたすべてのデータなど、オブジェクトストレージからほぼすべてのデータを読み取ります。OLTPノードとCPUを共有しないエンジンがこの読み取りを行います。
3. 残りのデータをpageserverからマージします。最後のマテリアライズ以降にコミットされたページはpageserverから取得され、その上にマージされます。

Postgresは一括読み取りトラフィックを処理せず、数値を返すか、せいぜいそれらの最近のページを返すだけです。レイクには、そのコミットを表示するために最新のコミットが含まれている必要はありません。レイクには、ほぼすべてが含まれており、さらに最後のマテリアライズ以降にコミットされたページを取得する方法があればよいのです。LSNが境界線となります。これは、マージをどこまで実行する必要があるかをエンジンに伝えます。

また、同じLSNによって結合の一貫性が保たれます。CDCはテーブルごとに適用されるため、1つのリレーションが別のリレーションよりも後のスロット位置にある場合があり、結合によって2つの時点が混在することになります。LTAPは、各パイプラインが最後にフラッシュした時点ではなく、PostgresがREPEATABLE READに使用するような単一のLSNですべてのテーブルを読み取ります。そのLSNは共有ウォーターマークです。ウォーターマーク以降の最近の変更を読み取るためのAPIは、Lakebase用としてネイティブに、またアップストリームのPostgres用として拡張機能として開発されています。

小さなテーブルはメタデータのコストであり、鮮度の制限ではありません。Icebergのオーバーヘッドはファイルとスナップショットです。少数の行からなるリレーションの場合、その管理コストは削減できるコストよりも大きく、スキャンパフォーマンスにおいてレイアウトは重要ではありません。これらのテーブルはページキャッシュに残り、LSN一貫性読み取りに参加し、Icebergのコミットをスキップします。

これにより、似ているようで異なる2つの主張が残ります。

• 「長いクエリには新しいコミットが見えない」 - これは事実であり、正しいです。LSN Xで開始されたクエリには、X以降のコミットは表示されません。これはスナップショット分離であり、レプリカの遅延ではなく、REPEATABLE READと同じ契約です。
• 「クエリがコミットされたデータを見落としている」 - これは誤った結果になります。Xで開始されたクエリが、CDCバッファに残っていたためにXの時点ですでに耐久性があったコミットを見逃してしまう場合です。LTAPがこのケースを回避する方法は、その時点のLSNとして最近のページをマージすることです。

マテリアライズされたカラムナースナップショットは最新のコンパクション間隔の分だけプライマリから遅れる可能性がありますが、クエリ自体は遅れません。Parquetファイルが数分遅れている可能性があるからといって、リーダーがコミットされたデータを確認できないわけではありません。

神話4：「Postgresのレプリケーションだけで十分である」

現実：logicalレプリケーションは、レイクをデータベースと同期させ続けるためのコストのかかる方法です。すべての変更を行単位でリプレイするため、それに追従できるパイプラインが必要です。ログレコードを独立して処理できないため、WALの並列デコードではこの問題を回避できません。

新鮮なPostgresで分析を行うための標準的な方法は、ロジカルレプリケーションを有効にすることです。Debezium、PeerDB、pgoutputなどのツールは、データベースがすでに変更ストリームを出力しているという点に着目し、追加でどのようなストレージフォーマットが必要かを問いかけます。

問題は、変更ストリームがレイク内にテーブルを構築するのに適した方法であるかどうかです。ストリームの2つの特性、すなわち読み取る必要がある量と、保持する必要がある状態の量がそれを否定しています。

ロジカルレプリケーションですべての変更を読み取る

WALはページ編集の物理ログであり、Postgresがクラッシュから復旧できるように書き込まれます。ロジカルデコードはこれをコミット順の行イベントに変換します。この変換では、同じページに対する多くの更新を現在のページイメージにまとめることはできず、すべての変更を通過させる必要があります。ホットページでは、Postgresはチェックポイント間に同じ8 KBのログを100回記録することがあります。ロジカルデコードは100個のイベントを出力し、その後、ダウンストリームのジョブがプライマリキーによってそれらをParquetにアップサートします。これに対し、ページ階層化パスはページを1回読み取ります。計測された書き込み集中型のワークロードでは、CDCは少なくともWALのボリュームを読み取りますが、ダーティページのコンパクションはその一部を読み取る場合があります。

ロジカルレプリケーションが状態を保持する

レプリケーションスロットは、コンシューマーが進め続けなければならないWALへのカーソルです。コンシューマーの処理が遅れると、スロットが削除されるかディスクがいっぱいになるまで、WALはディスク上に残ります。ロジカルデコードはDDLを出力しないため、ALTER TABLE、型の変更、および名前の変更により、イベントが現在のカタログと矛盾するようになるか、スロットが無効になります。プライマリキーのないテーブルにはREPLICA IDENTITY FULLが必要です。パイプラインにはコストがかかるため、通常はテーブルのサブセットに適用されます。これは、存在するすべてのPostgresテーブルがレイクに表示されるのとは逆のことです。

関連する主張：ロジカルデコードをスキップし、WALを並列でデコードできる

pageserverはすでにWALを消費しているため、並列のログからParquetへのパスは、小さな追加ステップのように見せることができます。原則としてそれは可能です。これは本番用のエクストラクターとしては構築されておらず、LTAPが使用しているパスでもありません。後のレコードは前のレコードを前提としているため、WALレコードには順序があります。可視性はタプルではなく、そのLSNにおける pg_xact、procアレイ、およびカタログに存在します。独立したワーカーは、それぞれが不連続なバイト範囲をデコードして正しい現在の行を出力することはできません。

LTAPが並列化するのはログレコードではなくページです。システムは、最後の日付のスナップショット以降にどのページが変更されたかを問い合せ（Postgres 17以降のWALサマリー、またはpageserverのログ構造化マージツリー）、変更された各ページが独立した作業となります。そのセットがパーティション分割され、ページがトランスコードされ、1つのIcebergスナップショットがコミットされます。ログは書き込みを永続化する方法であり、どのページが変更されたかを検出する1つの方法です。スナップショットは、それらをダーティにしたすべてのレコードのリプレイではなく、現在のページです。

だからといって、マイグレーション、メジャーバージョンのアップグレード、2番目のPostgresへの切り替えなど、本来の目的に対してレプリケーションが間違ったツールになるわけではありません。しかし、ロジカルレプリケーションをストレージとして使用すると、2番目の真実のソースが生まれます。

まとめ

4つの神話はすべて同じ誤解から生じています。それは、データのすべてをマテリアライズすることを2つ目のデータベースとして扱うことです。

LTAPは1つの論理テーブルを維持し、レイクはその永続的なコピーとなります。ヒープページ、インデックス、およびキャッシュは、カバーリングインデックスがヒープに対するクエリを処理するのと同様に、OLTPレイテンシでそのテーブルをPostgresが提供するためのものです。OLAPエンジンはParquetを直接スキャンし、最後のマテリアライズ以降のトランザクション的に一貫した変更をマージします。

これらのレイヤーのいずれも、2つ目のカタログや、乖離する可能性のある2つ目の真実のソースを追加しません。

LakebaseのストレージアーキテクチャがどのようにLTAPにつながるのかについての詳細については、 こちらの投稿をご覧ください。

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