LakebaseからLakehouseへのネイティブ同期を発表

本日、ネイティブLakehouse同期のパブリックプレビューを発表できることを嬉しく思います。これは、パイプラインや外部コンピューティングなしでLakebaseデータをUnity Catalog管理テーブルにレプリケートするLakebase Postgresの中核機能です。ネイティブLakehouse同期は、AWSおよびAzureのすべてのLakebaseリージョンで利用可能です。

開発の背景

以前は、アプリケーションは単一の運用データベース上で実行されていました。ユースケースが拡大するにつれて、1つのデータベースでは十分ではなくなりました。分析、ML、検索はすべて運用データベースの外で実行されるため、データの移動が必要になります。

歴史的に、これはデータウェアハウスへの日次バッチダンプを意味し、最終的には変更データキャプチャ（CDC）に進化しました。ハイパースケーラーはこれを「マネージド」同期（「ゼロETL」）としてパッケージ化し、データベースの隣にデータパイプラインをデプロイしました。しかし、これらのマネージド同期は、常時稼働ワークロード、安定したスキーマ、予測可能なクエリボリューム、単一の宛先データウェアハウスといった従来の前提に依存しています。データの宛先が増えるたびに問題は複雑化します。運用パフォーマンスは低下し、スキーマはドリフトし、スタック全体で障害点が指数関数的に増加します。

エージェントファースト開発は、このモデルを完全に破壊します。エージェントはデータを迅速に分岐させ、安全に反復処理し、タスク間でゼロにスケールし、短命な環境を起動します。すべてのブランチとすべての宛先に対してカスタムパイプラインを管理することは、単にスケーラブルではありません。

データウェアハウスへの接続は間違ったアプローチです。ダウンストリームコンシューマーは、もはや単なるダッシュボードではありません。埋め込みモデル、LLM、予測サービス、フィーチャーパイプラインです。Delta LakeやApache Iceberg™のようなオープンテーブルフォーマットは、理想的なプリミティブを提供します。安価なオブジェクトストレージにデータを一度保存し、重複なしにあらゆるワークロードを強化します。これは周知の事実です。Lakehouseが必要であり、最新の運用データをその中に取り込みたいと考えています。

しかし、運用データをLakehouseに書き込むことは新たな課題を生み出しました。チームは、Postgresレプリケーションスロット、Debeziumコネクタ、オープンフォーマットへの書き込み用のストリーム処理エンジン、テーブルを最適化するためだけの別個のコンピューティングを設定することを余儀なくされました。ホップごとに障害点が増加します。

Lakebaseのプロパティとしての同期

Lakebaseは根本的に異なる前提に基づいて構築されています。運用データベースは、Lakehouseと同じオープンで低コストなクラウドストレージ上で実行されるべきです。OLTPとOLAPがこの統合されたストレージ基盤を共有するため、ETLパイプラインを完全に排除できます。データ移動は、データベース自体のネイティブなプロパティになります。

ネイティブLakehouse同期を使用すると、LakebaseはWrite-Ahead-Log（WAL）をデコードし、Unity Catalog管理テーブルに直接書き込みます。単一のスキーマレベルのトグルで1分未満で有効になります。この同期はPostgresのパフォーマンスに全く影響を与えず、追加コストもかかりません。Databricksが両端を制御するため、スキーマ変更は自動的にフローし、ドリフトと遅延を排除します。

エンドツーエンドのエージェントファースト

エージェントはLakebase上にアプリを構築します。Databricks Genieのようなエージェントはデータを分析します。このライフサイクル全体を自律的に保つために、ネイティブLakehouse同期はLakebaseのコアプロパティとして構築されています。エージェントがシームレスに動作するために必要な正確な動作を継承します。

• ゼロへのスケール：データベースがゼロにスケールすると同期は一時停止し、再起動時に最後のLSNから再開します。
• コンピューティング管理不要：同期はLakebaseのネイティブな一部です。すべての監視とオブザーバビリティはLakebaseプロジェクト内に留まります。
• 自動スキーマ伝播：スキーマ変更は自動的にフローします。列の追加は即座に伝播されます。列の削除は宛先に保持されます。エージェントが同期を再作成する必要はありません。

宛先側のLakehouseプリミティブ

宛先がUnity Catalog管理テーブルであるため、同期されたデータには、着弾した瞬間からすべてのLakehouse機能が利用可能になります。

• AIネイティブ分析：Databricks GenieやGenie Codeのようなエージェントによるクエリ、分析、パイプライン生成にすぐに利用できます。
• ユニバーサル読み取り可能性：Databricks SQL、Apache Spark、Lakeflow Spark宣言型パイプライン、MLノートブック、およびDeltaまたはIcebergを話すあらゆるツールで読み取り可能です。
• 統合ガバナンス：ラインエージ、アクセスポリシー、タグ、監査はUnity Catalogから継承されます。
• 自動最適化：Predictive OptimizationとLiquid Clusteringは、セットアップなしで適用されます。
• デフォルトのバージョニング：すべての挿入、更新、削除はSCDタイプ2履歴として着弾します。監査ログ、ロールバック、CDFセマンティクスが組み込まれています。

ネイティブLakehouse同期で構築できること

これらのソースと宛先の動作を組み合わせることで、これまでカスタム変更データキャプチャ（CDC）スタックを必要としていた3つのパターンがアンロックされます。

エージェントによるメモリとライブMLフィーチャー。アプリケーションの書き込みは1分以内にUnity Catalogに着弾するため、個別の取り込みパイプラインなしで、モデルはアプリケーションの現在の状態に対して再トレーニングおよびスコアリングされます。

メダリオンアーキテクチャにおける運用データ。メダリオンアーキテクチャのブロンズテーブルとしてLakebaseを使用します。高頻度の更新はPostgresで行われ、変更履歴全体がSCDタイプ2として自動的にLakehouseにフローします。

コンプライアンスと監査。すべての挿入、更新、削除は、Unity Catalogの履歴行としてキャプチャされます。アプリケーション側の履歴追跡や個別の監査パイプラインは不要です。

開始方法

ネイティブLakehouse同期はパブリックプレビュー中です。Lakebaseの起動は即時です。スキーマで同期を一度トグルするだけで、既存および将来のすべてのテーブルが1分以内にUnity Catalogに表示されます。

Lakebaseは、Lakehouseと同じオープンデータ基盤上に構築されています。ネイティブLakehouse同期は、そのビジョンを実現し、個別のパイプラインなしでLakebaseデータがオープンフォーマットに自動的にフローすることを可能にします。

次のステップ：LakehouseからLakebaseテーブルへの同じオープン性を持ち込むこと。続報にご期待ください。

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