PostgresとS3上のParquetで実現する次世代データ基盤：LTAPアーキテクチャ徹底解説

PostgresのデータをS3上にParquet形式で保存し、効率的なデータ分析を実現する「LTAP（Long-Term Analytical Processing）」アーキテクチャについて解説します。この手法を用いることで、トランザクション処理（OLTP）と分析処理（OLAP）を高度に分離し、コストを抑えつつスケーラブルなデータレイクの構築が可能になります。

ここが理解できないんだよね。

ストリーミングレプリケーションでETLパイプラインを行う価値の一部は、テーブル内の全データ履歴を手に入れられることにある。各行にvalid_fromとvalid_toのタイムスタンプ列を持つSCDタイプ2のテーブルのようなものだ。

このアーキテクチャで同じことをするにはどうすればいいんだろう？

めちゃくちゃクールだ。分析プラットフォームとトランザクションデータベースを、中間にETLパイプラインを構築することなく1つのストレージ層に統合できるのは本当にゲームチェンジャーだよ。特に、独自のプロプライエタリなデータベースじゃなくて、ただのPostgresを使えるっていうのが最高だ。

記事を理解する頭がないだけかもしれないけど……これってどうやってOLAPとOLTPの用途両方でパフォーマンスの高いクエリを実現してるの？

自分の理解では、OLAPクエリは列指向で保存されたParquetファイルに向かって、OLTPスタイルのクエリはそのParquetファイルの上層にあるキャッシュレイヤーに向かうってことだよね？

ここでの「特別なソース（秘伝のタレ）」は何なんだ？結局のところデータをキャッシュしているだけで、彼らが避けていると言っていた「データのコピーをもう一つ保存する」という解決策と同じに見えるんだけど。

じゃあLTAPはメダリオンアーキテクチャの左右両方に位置するってことかな？つまり、Bronzeの左側でOLTPとして使い、Goldの右側でOLAPとして使うっていう意味？現状、自分たちはUnity Catalogで設定されたRBAC/ACLを再利用して分析PERNアプリケーションを開発するために、主にGoldの右側で使っているんだけど、この記事を読むとそれって有用性の半分でしかないってこと？

でも、なぜ？「エレガント」とか「クール」に聞こえるという理由だけでストレージを統一する考えには懐疑的だ。単一のストレージエンジンが、PostgresやClickHouseのような用途特化型のOLTP/OLAPシステムと、大きな妥協なしに競合できるとは到底思えない。

それにCDCパイプラインの削除についても言及しているけれど、フォーマット変換のマテリアライズが、最近よくあるような高負荷なOLTPワークロード（秒間5万トランザクション以上）に追いつけるのか疑問だ。それに、CDCは正しく丁寧に実装すればユーザーにとって魔法のような体験になるし、OLTP/OLAPデータストアのネイティブな仕組みのままでいられる。

第三に、データレイクやオープンフォーマットは、顧客向けリアルタイムアプリよりもデータウェアハウスやデータ分析のユースケースに適している。もちろん君たちがそれを変えようと取り組んでいるのはわかるけど、常にトレードオフに直面するはずで、後者に不可欠な最高のパフォーマンスを引き出すのは難しくなると思う。

LTAPアーキテクチャってPostgresのメジャーアップグレードにどう対応するの？アップストリームとダウンストリームの両方で、本当にゼロダウンタイムでいけるものなの？

これってテーブルバケットを使っているの？

面白い進展だね。

OLAPデータベースは今、レイクハウスアーキテクチャとして知られる方向に進んでいる。OLTPもすぐに同じ道を辿るだろうと予想してたよ。

CDCやその他のデータエンジニアリングタスクを排除することで、ホットデータを分析するための面白い方法が生まれるはず。RisingWaveなどは、ホットデータで何ができるかの最前線に既にいたけれど、これからは別途運用するものが必要なくなるというわけだ。

驚いたことに、S3にデータチャンクを保存する解決策に今週だけで2回も遭遇したよ。

これが一般的になりつつあるね。Playcodeでは、フルスタックWebソフトの開発を可能にする革新的なファイルシステムをPlaycode Cloud (https://playcode.io/cloud) のために構築した。このFSはRustを使ってゼロから作ったものだ。自分たちが一番賢くて、他にこんなことを考えたやつはいないと思ってたけど、DatabricksやNeon、他にも数社がすでに実現していたみたいだ。

「底なしファイルシステム（Bottomless File System）」という考え方は本当にクールだし、自分たちにとってもすごく上手くいっている。基本的にはここに書かれている通りだ：

• ページサーバーがある
• チャンク（ページじゃなくこう呼ぼう）に分割されたLinuxファイルシステム
• NVMe上のキャッシュ
• そしてもちろんオブジェクトストレージ（全てが非同期に同期される）

かなり上手く動くけど、欠点もある。

明らかな利点は、最近NVMeドライブが高価になっている一方でオブジェクトストレージは安いままなので、恩恵は否定できない。とはいえ、レイテンシも要因の一つだ。

さらに、アップリンクのコストも上がっている。オブジェクトストレージをベースにしたファイルシステムを動かすには、安定した速度を持つ強力なアップリンクが必要で、1Gbpsじゃ全く足りない。理想的には負荷にもよるが5〜10Gbpsは欲しいところだ。

私たちはホスティングプロバイダー、特にベアメタルハードウェアの最適化と実験に多くの時間を費やしている。主な課題は：

• ディスクが遅い
• アップリンクが遅い
• そして判明したことだが、S3を使わない限りオブジェクトストレージは信頼性が低い可能性がある

でもAWSのハードウェアは高いから、人生そんなに単純じゃないよね。

一つ疑問がある。LTAPやレイクベースをターゲットにするコンピューティングエンジンのためのオープンなプロトコル、つまりLTAPの読み書きパスのようなものは存在するのかな？IcebergからDeltaLakeへの進化に近いけど、それが一段上の層（OLTP+OLAP）になったようなものだ。

LTAPやレイクベースは、私たちがgfql（CPU+GPUターゲットを持つ初のOSSフルベクトル化プロパティグラフ演算エンジン）を構築する過程でずっと追ってきた興味深いギャップを提示している。新しいエンジンにはOLAPとOLTPの両モードをサポートしてほしいという自然な欲求がある一方で、自前で持ちたくはないクラウドネイティブストレージ層のギャップが存在するんだ。

Icebergなどは、S3以上に書き込みフレンドリーな標準ベースのOLAPバックエンドを導入し、アトミシティを提供したり、オープンなガバナンスでコードやプロトコルを扱えたりした点で刺激的だった。LTAPは理論上、OLTP+OLAPバックエンドのターゲットにできるパターンを提示しているけど……実際にはプロプライエタリなやり方になっている。潜在的な「オープン」な書き込み形式としては、OLTPパスの書き込みにはPostgresを、OLAPパスにはSparkライター（たぶんArrow-flightフレンドリーなもの）をサポートすることになるんだろうけど、それはあまりにハック的すぎる。