LTAPアーキテクチャ
ベータ版
6月15日より、LakebaseはGCPでベータとして利用可能です。サポートされているリージョンについては、「リージョンの可用性」を参照してください。
Lake Transactional/Analytical Processing（LTAP）は、レイク内の統合データストレージレイヤーから、単一のガバナンスモデルの下でトランザクション（OLTP）ワークロードと分析（OLAP）ワークロードの両方を提供するデータアーキテクチャです。これにより、トランザクションシステムと分析システムを個別に同期させる必要がなくなります。これにより、運用データを別の分析システムにコピーするためにチームが従来維持していたチェンジデータキャプチャ（CDC）、レプリケーション、および変換パイプラインが不要になります。Databricksは、Lakebaseストレージアーキテクチャ上にLTAPを構築します。発表については、DatabricksがLTAPを発表：初のLake Transactional/Analytical Processingアーキテクチャをご覧ください。
LTAP は単一の機能ではなく、アーキテクチャです。Databricks は、積極的に開発および拡張が行われている一連の Lakebase 機能を通じてこれを提供します。利用可能な機能は、お使いのクラウドによって異なります。このページでは、アーキテクチャについて説明します。現在お使いのクラウドで利用可能な機能については、LTAP を実装する機能を参照してください。
このページを読む前に、Lakebaseアーキテクチャを読んで、Lakebaseのアーキテクチャとそのコンポーネント（ステートレスなPostgresコンピュート、セーフキーパー、ページサーバー、クラウドオブジェクトストレージ）について理解してください。LTAPは、Lakebaseがコンピュートとストレージを分離する方法に基づいて直接構築されており、このページの残りの部分は、その基盤を前提としています。
2つのスタックを同期し続けるためのコスト
アプリケーションは、データ作業を 2 種類のワークロードに分割します。トランザクション (OLTP) ワークロードは一度に少数の行に対して動作し、支払い処理や API 結果の返却のように、それらの行の全内容を高速に必要とします。分析 (OLAP) ワークロードは、売上予測や不正検知など、多くの行を集計および結合して、大規模なデータセット全体から知見を探します。これらのパターンは相反する性質を持っています。OLTP は個々の行に対する低レイテンシの読み取りと書き込みを常に必要としますが、OLAP は大量のデータ全体をスキャンして集計する必要があります。数十年にわたり、その答えは 2 つの別々のシステムでした。アプリケーション用のトランザクションデータベースと、アナリティクス用のデータウェアハウスまたは lakehouse です。
その2つのスタックを接続するのが、最もコストのかかる部分です。これらを同期させるには、チェンジデータキャプチャ(CDC)、ストリーミングパイプライン、そしてデータコピーを他システムにコピーするだけのジョブを実行する必要があります。そのインフラは脆弱で、データが書き込まれてから解析されるまでに遅延が生じ、主要なトランザクションデータベースとリソースを競合します。アプリケーションやAIエージェントが最新のトランザクションデータに対するアナリティクスを必要とする中、このギャップはチームの作業を遅らせています。2つのシステム間でデータをコピーすることはガバナンスリスクも生じます。データの移動でリネージが途切れることがあり、GDPRの削除要求のような義務の履行が難しくなります。
LTAP がストレージレイヤーでデータを統合する方法
2つのスタック間でより優れたパイプラインを構築するのではなく、LTAP はパイプラインそのものの必要性を排除します。これは、ストレージからデータベースを再考することで実現しています。
Lakebase は、ステートレスな Postgres コンピュートを、セーフキーパー、ページサーバー、およびクラウドオブジェクトストレージからなる永続的なストレージ層からすでに分離しています。トランザクションは、セーフキーパーのクォーラムがその先行書き込みlogを永続的に記録すると commit され、その後ページサーバーがそれらの変更をクラウドオブジェクトストレージに非同期でマテリアライズするため、データは単一のデータベースエンジン内にロックされたままではなくなります。
Lakebase がコンピュートとストレージを分離する方法については、「Lakebase アーキテクチャ」を参照してください。
LTAP は、そのストレージレイヤーに 1 つのステップを追加します。Lakebase ストレージはデータをオブジェクトストレージに具体化する際、データがレイクに格納される過程で、行指向の Postgres データを Parquet の列指向Layoutにトランスコードします。これにより、Delta や Iceberg といったオープンなテーブル形式で読み取り可能になります。このトランスコーディングにより、データの単一コピーで OLTP と OLAP の両方のワークロードに対応できるようになります。これは、列指向のコピーが Postgres のオリジナルを忠実かつ効率的に表現できるように設計されています：
- セマンティクスは保持されます。 Lakebaseストレージは、元のPostgres表現を保持しながらすべての値を列形式にトランスコードするため、Postgres互換エンジンであれば情報を失うことなくデータを再解釈できます。
NaN、NUMERICオーバーフロー、またはvector、array、geography、JSONのような拡張型など、Parquetにきれいにマッピングされない型は、正規のPostgres表現を保持するオーバーフロー フィールドに保存されます。 - 行のバージョンは保持されます。 トランスコーディングは中間行バージョンを保持するため、列形式のコピーは行データと同じバージョン情報を持ちます。
- 列指向データは圧縮効率に優れています。 列指向のLayoutは高度に圧縮されるため、ストレージフットプリントと、オブジェクトストレージとの間で移動されるデータ量が削減されます。
トランスコーディングは完全にストレージレイヤー内で実行され、プライマリ Postgres インスタンスから分離されているため、トランザクション提供ワークロードに影響を与えません。これは、Lakebase がすでに実行している機能、つまりコミットされたデータをクラウドオブジェクトストレージにフラッシュする機能に基づいています。LTAP は、その同じフラッシュに列指向形式を追加するだけです。構築すべきパイプラインはなく、データベースをポーリングする外部プロセスもありません。
すべてがトランスコードされるわけではありません。Postgres インデックスは列に変換されるのではなく、永続ストレージレイヤー内で元の表現のまま保持されるため、列形式のコピーがアナリティクスに利用される間も、トランザクションのポイント読み取りとルックアップは高速に維持されます。
データは外部化されたバージョン管理ストレージに存在するため、Branchの作成や特定の時点への復元は、物理的なコピーではなくメタデータ操作となります。大規模な本番運用データベースを数秒でBranch化し、そのBranchに対してエクスペリメントやリスクを伴う移行を実行した後、基盤となるデータを複製することなく破棄できます。
Lakebase Branch は、データベースのストレージのコピーオンライト クローンです。親の既存データを共有し、変更された内容のみを保存するため、事前にデータが複製されることはありません。ポイントインタイム リストアは、同じバージョン管理されたストレージを使用して、データベースをリストア ウィンドウ内の過去の時点に戻します。詳細については、データベース Branchおよびポイントインタイム リストアを参照してください。
このストレージレベルのアプローチこそが、LTAP をチェンジデータキャプチャ (CDC) と差別化する点です。CDC は、プライマリデータベースを継続的にポーリングする外部プロセスと、行の変更を列データに変換するパイプラインを使用して、OLTP ストレージから別のアナリティクス層へデータをレプリケートします。そのパイプラインはプライマリトランザクションデータベースのリソースを消費し、スキーマの変更やエッジケースへの対応をユーザー自身に強いるだけでなく、データの鮮度とパイプラインコストをトレードオフの関係にし、さらに障害ポイントを増やすことになります。LTAP は代わりにストレージレベルのアプローチを採用しています。Lakebase ストレージは、通常のストレージ操作の一環としてデータをレイクにトランスコードするため、ワークロードと競合する外部プロセスは存在せず、ユーザーが構築や保守を行うパイプラインも不要です。
LTAP の 3 つの柱
ストレージ層でデータを統合することで、LTAPには3つの決定的な特性が備わります。
- ユニバーサルガバナンス。 Unity Catalog は、両方のワークロードにわたって、データの 1 つの論理コピーへの分析アクセスを管理します。
- 目的に特化したエンジン。 Postgres はトランザクションを処理し、Lakehouse はアナリティクスを処理します。両者が互いに影響を及ぼすことはありません。
- オープンストレージ内の単一の論理コピー。 両方のエンジンがオープンフォーマットのデータコピーを 1 つ読み取るため、同期が必要なレプリカやパイプラインはありません。
ユニバーサル ガバナンス
Unity Catalog は、両方のワークロードにわたってデータへの分析アクセスを管理します。Lakebase データベースを登録すると、 Unity Catalog はそのデータベースを読み取る外部コンピュートに対して権限、リネージ、および監査を適用します。
Unity Catalog のガバナンスは現在、 分析 アクセスに適用されます。これは、登録済みの Lakebase データを読み取る Lakehouse//RT やチェンジデータフィードなどの外部コンピュートを指します。現時点では、個々の Postgres テーブルを直接管理するものではありません。 トランザクション パス（Postgres に接続するアプリケーションやクライアント）を通じたアクセスは、Unity Catalog ではなく、標準の Postgres 権限（GRANT および REVOKE）によって引き続き制御されます。実際には、Unity Catalog が分析および lakehouse へのアクセスを管理し、Postgres のロールと権限がトランザクションアクセスを管理します。
目的に特化したエンジン
Postgresはトランザクションワークロードを処理し、Lakehouseはアナリティクスを処理します。それぞれが構築された目的の強みを活かします。両者を統合するということは、運用データがIcebergに格納されたコールドデータになるという意味である、というのはよくある誤解です。そうではありません。Lakebaseは標準のPostgresのままです。インデックス作成、ブランチ作成、ポイントインタイムリカバリ、拡張機能、および低レイテンシのポイント読み取り／書き込みは、すべて現在と同様に機能し続けます。
分析読み取りはプライマリ Postgres インスタンスから分離されているため、トランザクションワークロードと競合することはありません。Lakehouse//RT などの分析エンジンがライブの Lakebase データをクエリーする場合、データをコピーすることなく、最新かつトランザクション的に一貫性のある結果を返します：
- エンジンは、Postgresからではなく、オブジェクトストレージ内のカラムナコピーからデータの大部分を読み取ります。
- トランザクション的に一貫性のあるビューを取得するために、Postgres に対して現在のログシーケンス番号（LSN）のみを要求します。これは、先行書き込みログ内の位置を示す単一の値です。これは安価なメタデータルックアップです。
- まだレイクにマテリアライズされていないごく最近の変更セットについては、ページサーバーから読み取り、それらをMergeします。
Postgres は、その単一の LSN を返す以外の分析用読み取りトラフィックを処理せず、トランスコーディングはアプリケーションを提供する Postgres インスタンス上ではなく、ストレージ層で実行されます。運用ワークロードは期待どおりに実行され続けます。
オープンストレージ内の単一の論理コピー
データはレイク内に列指向の Parquet として存在し、Delta や Iceberg といったオープンなテーブル形式で読み取り可能なため、Lakebase (OLTP) と Lakehouse (OLAP) は同じストレージ基盤を共有しています。トランザクションデータベースと分析用のコピーを個別に照合するのではなく、両方のワークロード全体でデータの論理コピーを 1 つ維持します。
各エンジンは、パフォーマンス向上のために、そのデータを異なる 物理 形式でキャッシュまたは表現できます。Lakebase は高速な OLTP ポイント読み取りに Postgres ページを使用し、分析エンジンは列指向の Parquet を読み取ります。トランザクション用と分析用のコピーを個別に保持して同期を維持するのではなく、単一の 論理 データセットを操作します。
各テーブルには、Lakebaseまたはレイクハウスのいずれか1つのライターが存在します。両方のエンジンがその1つの論理コピーを読み取るため、2つ目のコピーを作成することなく、アプリケーションとアナリティクスで同じデータを利用できます。
Lakebaseの使用方法を変更する必要がありますか
いいえ。LTAP 機能を導入しても、データ移行やアプリケーションの Lakebase への接続方法を変更する必要はありません。Lakebase は標準の Postgres のままです。既存の拡張機能、インデックス、クエリー、およびアプリケーションコードは、変更なしでそのまま動作します。LTAP 機能はそれぞれ独立しているため、ワークロードが必要とするタイミングでいつでも導入できます。
LTAPを実装する機能
一連の Lakebase 機能を通じて、LTAP アーキテクチャを実践します。それぞれが前述の共有ストレージ基盤の上に構築されており、それらが組み合わさることで、データが LTAP を通過するパスをカバーします：
- ガバナンスと登録する : Lakebase データを Unity Catalog の管理下に置きます。
- Lakebase で lakehouse データを提供する ：同期テーブル（LTAP Direct Writes で高速化）。
- ライブ Lakebase データのクエリー ：アナリティクスには Lakehouse//RT を、変更ストリームには Lakebase チェンジデータフィードを使用します。
以下の図は、Unity Catalogによって制御されたデータ一つのコピーにこれらの機能がどのように書き込み読み込むかを示しています。
Lakehouse//RTとLakebase チェンジデータフィードは同じ基礎データを読み取りますが、表現方法が異なります。Lakehouse//RTはアナリティクスのためにライブPostgresデータの現状を読み取ります。Change Data Feedは、下流パイプラインや監査のために行レベルの変更ストリームを提供します。LTAPが削除する外部CDCも同様で、どちらも単一のデータコピーで動作します。
次の表に、すべての LTAP 機能とその内容、およびご利用のクラウドでのリリース状況を示します。可用性はクラウドによって異なるため、ご利用のクラウドで提供されていない機能には「利用不可」とマークされます。
機能 | ステータス | 説明 |
|---|---|---|
GA | Lakebase データの分析アクセスをガバナンスし、レイクハウスからソース間クエリーを実行します。 | |
GA | 低レイテンシの OLTP 読み取りのために、Unity Catalog テーブルデータを Lakebase で提供します。 | |
Lakebase をクエリする Lakehouse//RT | GCPでは利用できません | Lakebase OLTP のパフォーマンスに影響を与えることなく、ライブの Postgres データに対してトランザクション的に一貫性のある OLAP クエリーを実行します。 |
Lakebase チェンジデータフィード | GCPでは利用できません | Lakebase Postgres テーブルの行レベルの変更を、ダウンストリームのパイプラインおよび監査用に Unity Catalog Delta テーブルとして保存します。 |
実装へのアプローチ方法
機能について理解できたところで、次はどの機能がワークロードに必要なのかという点が問題になります。アーキテクチャ内のデータの流れに合わせて機能を組み合わせることで、LTAP を実装します。
重要な判断は方向性です。各データセットに対して、どのシステムが書き込みを所有するのか?各テーブルには単一の書き込み権限があり、それによって使用できる機能が決まります。
- 書き込みは Lakebase が管理します。 アプリケーションが Postgres に書き込む際、その運用データをコピーせずにアナリティクスで利用できるようにしたい場合。例えば、販売アプリケーションは、注文や支払いを発生時に Lakebase に書き込みます。Lakehouse//RT を使用してそれらの注文に関するライブ収益ダッシュボードをランするか、Lakebase チェンジデータフィードを使用して各注文の変更を下流のパイプラインまたは監査LogにStreamします。
- 書き込みはレイクハウスが管理します。 データがレイクハウスで生成または保持されており、アプリケーションから低レイテンシでOLTP読み取りを行いたい場合。例えば、夜間のlakehouseジョブが製品のレコメンデーションや価格テーブルをコンピュートします。同期テーブルを使用してそのデータをLakebaseに提供することで、アプリケーションが低レイテンシで読み取れるようになります。また、LTAPダイレクト書き込みを有効にすると、大きなテーブルの初期ロードを高速化できます。
各データセットをこれらの方向のいずれかにマッピングし、 Unity Catalogにデータベースを登録する してガバナンスを行い、各パスを実装するために機能ドキュメントに従って進めます。単一のアプリケーションはしばしば両方向を利用します。lakehouseからPostgresに参照データを提供しつつ、自身のトランザクション書き込みをアナリティクスに公開するというものです。利用可能性はクラウドによって異なるため、上記の能力表でクラウド上で何が提供されているかを確認してください。
次のステップ
- Lakebase アーキテクチャ : Lakebase がステートレスなコンピュートと永続的なストレージをどのように分離しているかを理解します。「Lakebase アーキテクチャ」を参照してください。
- Unity Catalog : Govern Lakebaseデータに登録するし、lakehouseからクエリーしてください。See Register a Lakebase database in Unity Catalog.
- 同期されたテーブルを使用してデータを提供する : Unity Catalog テーブルのデータを Lakebase に同期して低レイテンシの読み取りを実現し、LTAP ダイレクト書き込みで大規模なロードを高速化します。「同期されたテーブルを使用してレイクハウス データを提供する」を参照してください。