Lake Transactiongal/Analytical Processing(LTAP)は、湖内の統合データストレージ層から、トランザクション(OLTP)と分析(OLAP)の両方のワークロードを一つのガバナンスモデルの下で提供するデータアーキテクチャです。これにより、トランザクションシステムと分析システムを別々に同期させる必要がありません。これは、チームが従来運用データを別の分析システムにコピーするために維持してきた変更データキャプチャ(CDC)、レプリケーション、変換パイプラインを排除します。 Azure DatabricksはLakebaseストレージアーキテクチャの上にLTAPを構築します。 発表については、Databricks、LTAPを発表: 初のLake Transactional/Analytical Processingアーキテクチャをご覧ください。
LTAPはアーキテクチャであり、単一の機能ではありません。 Azure Databricksは、現在開発・拡張が進められているLakebaseの機能群を通じてそれを実現しています。 利用可能な機能はクラウドによって異なります。 このページでアーキテクチャについて説明します。 今日クラウドで利用できる機能については、「 LTAPを実装する能力」を参照してください。
Important
このページを読む前に、 Lakebaseアーキテクチャ とその構成要素(ステートレスPostgresの計算、セーフキーパー、ページサーバー、クラウドオブジェクトストレージ)を理解するためにLakebaseアーキテクチャを読んでください。 LTAPはLakebaseがコンピュートとストレージを分離する方法を直接構築しており、このページの残りの部分はその基盤を前提としています。
2つのスタックを同期させるコスト
アプリケーションはデータ作業を2種類の作業に分けます。 トランザクション型(OLTP)ワークロードは、一度に数行に処理され、支払い処理やAPI結果の返送など、その行の全内容を迅速に処理する必要があります。 分析型(OLAP)ワークロードは、大規模なデータセットにわたる洞察を探し、多くの場合、販売予測や不正の検出など、多くの行を集約・結合します。 これらのパターンは逆方向に引っ張られます。OLTPは個々の行に対して低遅延の読み書きを常に行う必要があり、OLAPは大量のデータにわたってスキャンと集約が必要です。 何十年もの間、答えは2つの別々のシステムでした。アプリケーション用のトランザクションデータベースと、分析のためのデータウェアハウスやレイクハウスです。
この2つのスタックをつなぐのがコストのかかる部分です。 これらを同期させるということは、変更データキャプチャ（CDC）、ストリーミングパイプライン、一方のシステムからもう一方へデータをコピーすることだけを役割とする読み取りレプリカを稼働させることを意味します。 そのインフラは脆弱で、データが書き込まれてから解析されるまでに遅延が生じ、主要なトランザクションデータベースと資源を競合します。 アプリケーションやAIエージェントが最新のトランザクションデータに対する分析を必要とする中、このギャップはチームの作業を遅らせています。 2つのシステム間でデータをコピーすることはガバナンスリスクも生じます。データの移動で系譜が途切れることがあり、GDPRの削除要求のような義務の履行が難しくなります。
LTAPがストレージ層でデータを統合する方法
2つのスタック間でより良いパイプラインを構築するのではなく、LTAPはパイプライン自体の必要性を排除します。 それをデータベースをストレージ層から見直すことで実現しています。
LakebaseはすでにステートレスのPostgres計算を、セーフキーパー、ページサーバー、クラウドオブジェクトストレージといった耐久性のあるストレージ層から分離しています。 トランザクションは、セーフキーパーの定足数が書き込み先行ログを恒久的に記録するとコミットし、ページサーバーはその変更を非同期にクラウドオブジェクトストレージに転送することで、データが単一のデータベースエンジン内に閉じ込められなくなります。
Note
Lakebaseがコンピュートとストレージをどのように分離しているかについては、 Lakebaseアーキテクチャを参照してください。
LTAPはそのストレージ層に一段階のステップを加えます。 Lakebaseストレージがデータをオブジェクトストレージに具現化する際、行指向のPostgresデータを湖に降り立つ際にParquetの列状レイアウトにトランスコードし、DeltaやIcebergなどのオープンテーブル形式で読み取ることができます。 このトランスコーディングにより、単一のデータコピーがOLTPとOLAPの両方のワークロードを処理できるようになります。 列指向コピーがPostgresの元データを忠実かつ効率的に表現し続けるように設計されています:
- 言葉の意味は保持されています。 Lakebaseストレージは、元のPostgres表現を保持しつつ、すべての値を列形式にトランスコードするため、Postgres互換エンジンは情報を失うことなくデータを再解釈できます。 Parquetにきれいにマッピングされない型(
NaN、NUMERICオーバーフロー、ベクター、配列、地理、JSONなどの拡張型)は、標準的なPostgres表現を保持するオーバーフローフィールドに保存されます。 - 行のバージョンは保持されます。 トランスコーディングは中間行バージョンを保持するため、列形式のコピーは行データと同じバージョン情報を持ちます。
- 列状データはよく圧縮されます。 列状レイアウトは非常に圧縮されており、ストレージの使用量やオブジェクトストレージへのデータ転送量を削減します。
トランスコーディングは完全にストレージ層で動作し、プライマリのPostgresインスタンスから隔離されているため、トランザクションサービスワークロードには影響しません。 これはLakebaseがすでに行っていること、すなわちコミットデータをクラウドオブジェクトストレージにフラッシュするという点を基盤としています。 LTAPは単に同じフラッシュにカラム形式を加えるだけです。 パイプラインを作る必要もなく、外部プロセスがデータベースをポーリングすることはありません。
すべてがトランスコードされているわけではありません。 Postgreのインデックスは、カラムに変換されるのではなく、元の表現を耐久ストレージ層に残すため、トランザクションのポイント読み取りやルックアップは高速で、カラムコピーは分析に使われます。
データは外部化されたバージョン制御ストレージに保存されるため、ブランチの作成や時点への復元は物理的なコピーではなくメタデータ操作です。 大規模な本番データベースを数秒で分岐し、実験やリスクの高い移行を行い、基礎となるデータを重複せずに破棄できます。
Note
Lakebaseブランチは、データベースのストレージのコピーオンライト方式のクローンです。親の既存データを共有し、変更された分だけを保存するため、作成時点でデータが複製されることはありません。 ポイントインタイム復元は、同じバージョン管理ストレージを使って、リストアウィンドウ内のデータベースを以前の瞬間に戻します。 詳しくは「 データベースブランチ 」および「 ポイントインタイム復元」をご覧ください。
このストレージレベルのアプローチこそが、LTAPが変更データキャプチャ(CDC)と異なる点です。 CDCは外部プロセスを使ってOLTPストレージから別の分析層にデータを複製し、メインデータベースを継続的にポーリングし、行の変更を列データに変換するパイプラインを用います。 そのパイプラインは主要なトランザクションデータベースのリソースを消費し、スキーマの変更やエッジケースを自分で処理しなければならず、データの新鮮さとパイプラインコストをトレードし、故障ポイントも増えます。 LTAPは代わりにストレージレベルのアプローチを採用しています。レイクベースのストレージは通常のストレージ運用の一部としてデータを湖にトランスコードし、外部プロセスがあなたの作業量と競合せず、パイプラインを構築したり維持したりする必要もありません。
LTAPの三本柱
ストレージ層でデータを統合することで、LTAPは3つの決定的な特性をもたらします。
- 普遍的な統治。 Unity Catalogは、両方のワークロードにわたるデータの論理的コピーへの分析アクセスを管理します。
- 目的別に設計されたエンジン。 Postgresはトランザクションを、Lakehouseは分析を担当し、どちらも互いに妥協しません。
- オープンストレージにある単一の論理コピー。 両方のエンジンは、レプリカやパイプラインを同期させることなく、オープンフォーマットのデータの1コピーを読み取っています。
普遍的統治
Unity Catalogは両方のワークロードにおけるデータへの分析アクセスを管理します。 Lakebaseデータベースを登録した後、Unity Catalogはそれを読み取る外部コンピュートに対して権限、系譜、監査を適用します。
Note
Unity Catalogのガバナンスは現在、 Lakehouse //RTやChange Data Feedのような外部計算ツールが登録済みLakebaseデータを読み取る分析アクセスに適用されます。 まだ個々のPostgresテーブルを直接管理しているわけではありません。
トランザクションパス、すなわちPostgresに接続するアプリケーションやクライアントへのアクセスは、Unity Catalogではなく標準的なPostgres権限(GRANTおよびREVOKE)によって制御されています。 実際には、Unity Catalogが分析アクセスとレイクハウスアクセスを管理し、Postgresの役割と特権がトランザクションアクセスを管理します。
専用設計のエンジン
Postgresはトランザクション作業に対応し、Lakehouseは分析を提供し、それぞれが本来の強みを持っています。 よくある誤解は、両者を統合すると運用データが氷山の中に冷たく残るものになるというものです。 しかし、それは事実ではありません。 レイクベースは標準的なPostgresのままです。 インデックス作成、分岐、ポイントインタイムリカバリー、拡張、低遅延のポイント読み書きはすべて現在とまったく同じように動作しています。
分析リードは、主要なPostgresインスタンスから分離されているため、トランザクション作業と競合しません。 Lakehouse//RTのような分析エンジンがライブのLakebaseデータをクエリすると、データをコピーせずに新しくトランザクション的に整合した結果を返します。
- エンジンはPostgresではなく、オブジェクトストレージ内の列状コピーからデータの大部分を読み込みます。
- トランザクション的に一貫したビューを得るために、Postgresには書き込み先行ログ内の位置を示す単一の値である現在のログシーケンス番号(LSN)のみを求めます。 これは安価なメタデータ検索です。
- 湖にまだ実装されていないごく最近の変更点については、ページサーバーから読み取って上位にマージします。
Postgresは解析的な読み取りトラフィックには一切対応せず、単一のLSNを返すだけで、トランスコードはストレージ層で実行され、アプリケーションを担当するPostgresインスタンスでは動作しません。 運用業務は期待通りに進み続けています。
オープンストレージ内の単一の論理コピー
データは湖内に柱状のパーケット形式で存在し、DeltaやIcebergなどのオープンテーブル形式で読み取れるため、Lakebase(OLTP)とLakehouse(OLAP)は同じストレージ基盤を共有しています。 トランザクションデータベースと別の分析コピーを照合する代わりに、両方のワークロードで1つの論理的なデータコピーを維持できます。
各エンジンはパフォーマンスのためにデータをキャッシュしたり、異なる 物理 フォーマットで表現したりできます。 LakebaseはPostgresページを使って高速なOLTPポイント読み取りを行い、解析エンジンは柱状Parquetを読み込みます。 トランザクションと分析のコピーを別々に管理し同期させるのではなく、単一の 論理 データセットで作業できます。
各テーブルにはレイクベースかレイクハウスの1人のライターがいます。 両方のエンジンはその1つの論理コピーを読み取るため、同じデータがアプリケーションや分析に利用可能で、2つ目のコピーがなくても共有されます。
Lakebaseの使い方を変える必要がありますか?
No. LTAP機能の導入にはデータ移行やアプリケーション接続方法の変更は必要ありません。 Lakebaseは標準のPostgresのままです。既存の拡張機能、インデックス、クエリ、アプリケーションコードは変更せずに動作します。 各 LTAP機能は 独立しているため、ワークロードが必要なときにいつでも採用可能です。
LTAPを実装する機能
LTAPアーキテクチャをLakebaseの機能セットを通じて実践に移します。 それぞれは上記の共有ストレージの基盤の上に構築されており、LTAPを通じてデータが辿る経路をカバーしています。
- ガバナンスと登録:LakebaseデータをUnityカタログに取り込む。
- Lakebase でレイクハウスデータを利用可能に: LTAP Direct Writes によって高速化された同期テーブル。
- ライブのLakebaseデータをクエリしてください:分析用にLakehouse//RT、変更ストリーム用にLakebase Change Data Feed。
以下の図は、Unity Catalogによって制御されたデータ一つのコピーにこれらの機能がどのように書き込み読み込むかを示しています。
Lakehouse//RTとLakebase Change Data Feedは同じ基礎データを読み取りますが、表現方法が異なります。 Lakehouse//RTは分析のためにライブPostgresデータの現状を読み取ります。 Change Data Feedは、下流パイプラインや監査のために行レベルの変更ストリームを提供します。 LTAPが削除する外部CDCも同様で、どちらも単一のデータコピーで動作します。
以下の表は、すべてのLTAP機能とその機能、そしてクラウド上でのリリース状況を示しています。 利用可能性はクラウドによって異なるため、クラウド上で提供されていない機能は利用不可とマークされます。
| Capability | 地位 | Description |
|---|---|---|
| UnityカタログでLakebaseを登録 | GA | Lakebaseのデータへの分析アクセスを管理し、lakehouseからクロスソースクエリを実行します。 |
| 同期されたテーブルを使用してデータを提供する | GA | LakebaseでUnity Catalogのテーブルデータを低遅延のOLTP読み取りに提供します。 LTAP Direct Writes(ベータ版)は、すべての同期モードで初期ロードを加速し、フルリフレッシュも行います。 |
| Lakehouse//RT がLakebaseに問い合わせ | ベータ | ライブPostgresデータに対してトランザクション一貫性のあるOLAPクエリを実行し、Lakebase OLTPのパフォーマンスに影響を与えません。 |
| Lakebase 変更データ フィード | パブリック プレビュー | Lakebase Postgresテーブルからの行レベルの変更をUnityカタログのDeltaテーブルとして保存し、下流パイプラインや監査用に活用します。 |
実装へのアプローチ方法
機能が分かった今、問題はあなたのワークロードに必要なものがどれかです。 LTAPは、データがアーキテクチャを通過する流れに合った機能を組み合わせて実装します。
重要な判断は方向性です。各データセットに対して、どのシステムが書き込みを所有するのか? 各テーブルには1人のライターがいて、それによってどの機能を使うかが決まります。
- レイクベースが書き込みを支配しています。 あなたのアプリケーションはPostgresに書き込みを行っており、その運用データをコピーせずに分析のために利用できるようにしたいのです。例えば、営業アプリケーションは注文や支払いが発生した際にLakebaseに書き込みます。 Lakehouse//RTを使ってこれらの注文に対してライブ収益ダッシュボードを実行し、Lakebase Change Data Feedで各注文変更を下流のパイプラインや監査ログにストリーミングできます。
- レイクハウスが書き込みを管理します。 データはレイクハウスで生成または管理されており、アプリケーションから低遅延のOLTP読み取りが求められます。 例えば、夜のレイクハウス作業では商品推薦や価格表を計算します。 同期テーブルを使ってそのデータをLakebaseに提供し、アプリケーションが低遅延で読み取れるようにし、LTAP Direct Writesを有効にして大きなテーブルの初期負荷を加速させましょう。
各データセットをこれらの方向のいずれかにマッピングし、 Unity Catalogにデータベースを登録 してガバナンスを行い、各パスを実装するために機能ドキュメントに従って進めます。 1つのアプリケーションで、両方向のデータフローを利用することはよくあります。たとえば、レイクハウス内の参照データをPostgresに取り込みつつ、自身のトランザクション書き込みを分析用に公開するといった形です。 利用可能性はクラウドによって異なるため、上記の能力表でクラウド上で何が提供されているかを確認してください。
次のステップ
- Lakebaseアーキテクチャ:Lakebaseがステートレスコンピュートと耐久ストレージをどのように分離しているかを理解しましょう。 Lakebase アーキテクチャを参照してください。
- Unity Catalog にデータベースを登録する: Lakebase のデータを管理し、レイクハウスからクエリします。 「Unity カタログに Lakebase データベースを登録する」を参照してください。
- 同期されたテーブルでデータを提供:UnityカタログのテーブルデータをLakebaseに同期して低遅延の読み取りを行い、LTAPダイレクトライトで大負荷を加速します。 「同期されたテーブルを使用して Lakehouse データを提供する」を参照してください。
- レイクベース変更データフィード:パイプラインと監査のために湖のハウスの行レベルの変更をストリーミングします。 「Lakebase Change Data Feed」を参照してください。
