新たなDBアーキテクチャ「LTAP」にDeep Dive!!

Transcript

1. 新たなDBアーキテクチャ 『LTAP』にDeep Dive Data + AI Summit 2026をみんなで振り返ろう！ 2026年7月15日 株式会社NTTデータ 井能 猛 © 2025 2026 NTT DATA Japan Corporation
2. 株式会社NTTデータ Databricksビジネス推進室 井能 猛 Takeru Ino 職種：データサイエンティスト、データエンジニア Databricks Champion © 2026 NTT DATA Japan Corporation
3. Data+AI Summit 2026 で 『LTAP』 が発表！ Databricks Launches LTAP : The First Lake Transactional/Analytical Processing Architecture © 2026 NTT DATA Japan Corporation
4. そして2026.6.30、ついに東京リージョンでLakebaseが利用可能に！ June 2026 | Databricks on AWS © 2026 NTT DATA Japan Corporation
5. 目次 • これまでのLakebase • LTAPとはなにものなのか • LTAPのアーキテクチャにDeep Dive • まとめ © 2026 NTT DATA Japan Corporation 5
6. 目次 ➢ これまでのLakebase • LTAPとはなにものなのか • LTAPのアーキテクチャにDeep Dive • まとめ © 2026 NTT DATA Japan Corporation 6
7. はじめに：「OLTP(行指向)」と「OLAP(列指向)」の違い OLTPはトランザクション処理を高速に行なうことを目的として、データを行ごとに持つ(行指向)のデータベースで実現。 OLAPは収集・蓄積したデータを分析することを目的として、データを列ごとに持つ(列指向)のデータベースで実現。 OLTP(行指向) OLAP(列指向) Online Transaction Processing Online Analytical Processing OrderID CustomerID OrderDate Amount OrderID CustomerID OrderDate Amount 1 CUST005 2025-07-16 2,980 1 CUST005 2025-07-16 2,980 2 CUST003 2025-07-17 8,750 2 CUST003 2025-07-17 8,750 3 CUST001 2025-07-17 1,500 3 CUST001 2025-07-17 1,500 OLTPを実現するDBは行ごとにデータを保存するため 特定の行に高速アクセス可能で追加や更新に強い OLAPを実現するDBは列ごとにデータを保存するため 特定の列に高速アクセス可能で集計やフィルタに強い ＝ アプリのバックエンド用 ＝ データ分析用 © 2025 NTT DATA Japan Corporation
8. はじめに：「OLTP(行指向)」と「OLAP(列指向)」の違い OLTPはトランザクション処理を高速に行なうことを目的として、データを行ごとに持つ(行指向)のデータベースで実 現。 OLAPは収集・蓄積したデータを分析することを目的として、データを列ごとに持つ(列指向)のデータベースで実現。 OLTP(行指向) Online Transaction Processing は や OLAP(列指向) Online Analytical Processing OrderID CustomerID OrderDate Amount OrderID CustomerID OrderDate Amount 1 CUST005 2025-07-16 2,980 1 CUST005 2025-07-16 2,980 2 CUST003 2025-07-17 8,750 2 CUST003 2025-07-17 8,750 3 CUST001 2025-07-17 1,500 3 CUST001 2025-07-17 1,500 OLAP が得意 OLTPを実現するDBは行ごとにデータを保存するため 特定の行に高速アクセス可能で追加や更新に強い ではOLTPは？ ＝ アプリのバックエンド用 © 2025 NTT DATA Japan Corporation OLAPを実現するDBは列ごとにデータを保存するため 特定の列に高速アクセス可能で集計やフィルタに強い ＝ データ分析用
9. What is Lakebase？ Postgresベースで、コンピュート・ストレージが分離されるなどサーバレスに最適化された行指向データベース。 フルマネージドな Postgresデータベース コンピュート・ストレージが 分離されたアーキテクチャ 現代のAI開発に 最適化された開発体験 10ms未満のレイテンシ、10ks以上のQPS 拡張、ツールなどのエコシステムも利用可能 オートスケール(≧0)による性能拡張性や セカンダリノードによる可用性の担保 ブランチやPoint-in-timeリカバリなど NeonをベースとしたDevExの提供 Lakehouse(列指向データベース)との統合 © 2026 NTT DATA Japan Corporation
10. Lakebaseのアーキテクチャ コンピュートとストレージに分離されており、個別にスケール可能であるため性能拡張やコスト最適化が可能。 ストレージはキャッシュやバッファとして機能する中間層があり、永続化は非同期でオブジェクトストレージに実施。 従来のデータベース Lakebase From monolith to Lakebase to LTAP: rethinking the database from storage up | Databricks Blog © 2026 NTT DATA Japan Corporation
11. Lakebaseのユースケース 主なユースケースはアプリケーション、AIエージェント、オンライン推論などが中心。 従来のLakehouseでは難しかった、トランザクション処理やレイテンシが求められる処理が使いどころ。 for アプリケーション Apps for AIエージェント for オンライン推論 Agent ML Model Lakebase Lakebase • アプリの状態保持のために利用 • トランザクション処理に利用 • エージェントのメモリーとして利用 • Vector Indexとして利用 Lakebase • オンライン特徴量ストアとして利用 従来はAuroraなどのOLTPを別途立てる必要があったユースケースもDatabricksで完結可能に！ © 2026 NTT DATA Japan Corporation
12. OLTP×OLAPの両方に対応するためのアーキテクチャ 業務ロジックの中で利用するOLTPデータベースと、分析で利用するOLAPデータベースを両方持ち、 用途によって使い分け、ユースケースによっては相互にデータを連携することで業務ロジックと分析どちらも実現。 Lakebase Lakehouse ETL https://youtu.be/Qux8E-L1mk8?si=d3KuZFcsqo_QQntB&t=10067 © 2026 NTT DATA Japan Corporation
13. Lakebaseに蓄積されたデータを分析するユースケース トランザクション処理の中で実施する追加・更新・削除に加えて、蓄積したデータを分析したいケースも多数。 その場合はLakehouse(Delta Table/Iceberg)にコピーを作成して、OLAPから利用できるようにする。 © 2026 NTT DATA Japan Corporation
14. Lakehouseへの同期・連携における課題 同期・連携のための方式は ①Change Data FeedによるETL ②データ仮想化 の2通りあるが、 ①は取り込み遅延や不整合、②はクエリ性能低下、そして両案ともETLやFederationのコストが課題に。 CDCによるETL データ仮想化 CDCによる増分ETLでLakehouseにコピーを作成 Lakebaseを仮想化してLakehouseからクエリ可能に ETL with SDP Federation Lakebase Delta Table ✕：データ更新の取り込みに遅延や不整合の可能性 ✕：更新取り込みの頻度に応じてETLコストが増加 © 2026 NTT DATA Japan Corporation Lakebase 仮想テーブル ✕：DB間の通信が発生するためクエリ性能が低下 ✕：接続先/元の両コンピュートが稼働しコスト増加
15. 参考：従来の解決策としての『HTAP』 行指向/列指向の両データストアを保持するDBアーキテクチャで、これまでは先頁の課題の解決策の筆頭。 但し、運用/性能/コストなど課題あり。 Hybrid Transactional/Analytical Processingの略称。 SQLエンジン １つのエンジンでトランザクション処理と分析処理の両方に最適化 トランザクションクエリ 分析クエリ HTAP テーブル 行指向ストア 列指向ストア レコードA … レコードB ︙ © 2026 NTT DATA Japan Corporation 同期 列X 列Y 列Z
16. 目次 • これまでのLakebase ➢ LTAPとはなにものなのか • LTAPのアーキテクチャにDeep Dive • まとめ © 2026 NTT DATA Japan Corporation 16
17. OLTP×OLAPの両方に対応するためのアーキテクチャ 再掲 業務ロジックの中で利用するOLTPデータベースと、分析で利用するOLAPデータベースを両方持ち、 用途によって使い分け、ユースケースによっては相互にデータを連携することで業務ロジックと分析どちらも実現。 Lakebase Lakehouse ETL https://youtu.be/Qux8E-L1mk8?si=d3KuZFcsqo_QQntB&t=10067 © 2026 NTT DATA Japan Corporation
18. 新たなDBアーキテクチャ 『LTAP』 ストレージ層はDelta/Iceberg形式で保存された列指向のデータに統一、コピーは一切作成しない。 そして、コンピュート層を用途別に分離する。 Lake Transactional/Analytical Processingの略称。 LTAP https://youtu.be/Qux8E-L1mk8?si=RqUrZ8nq04j7SbB4&t=10076 © 2026 NTT DATA Japan Corporation
19. 『LTAP』 がもたらす恩恵 業務で更新したデータを、常に最新状態で分析やエージェントから活用、リアルタイムに意思決定に反映！ CDCやミラーリングといったETLが不要になり、運用負荷や処理コスト、データ不整合などの課題も解消する！ LTAP © 2026 NTT DATA Japan Corporation
20. 補足：『Lakehouse//RT』 を利用すればリアルタイム処理も可能に 『Lakehouse//RT』 もDelta/Icebergのテーブルに対してエンジンを変えるだけで利用できる。 厳しい同時実行要件や、最新データによる分析結果をミリ秒で表示したい要件があるユースケースで活きる。 LTAP © 2026 NTT DATA Japan Corporation
21. 目次 • これまでのLakebase • LTAPとはなにものなのか ➢ LTAPのアーキテクチャにDeep Dive • まとめ © 2026 NTT DATA Japan Corporation 21
22. 再掲 Lakebaseのアーキテクチャ コンピュートとストレージに分離されており、個別にスケール可能であるため性能拡張やコスト最適化が可能。 ストレージはキャッシュやバッファとして機能する中間層があり、永続化は非同期でオブジェクトストレージに実施。 従来のデータベース Lakebase From monolith to Lakebase to LTAP: rethinking the database from storage up | Databricks Blog © 2026 NTT DATA Japan Corporation
23. LTAPのアーキテクチャ 列指向のクエリエンジンであるLakehouseからObject Storageに格納されたテーブルを参照する。 加えて、PostgresサーバやPageServerにも一部通信と軽微なデータ取得が行われる。 行指向のクエリエンジン Postgres Safekeeper 列指向のクエリエンジン ①LSN PageServer Lakehouse ③直近の変更 ②大部分のデータ Object Storage / Lake (Parquet) From monolith to Lakebase to LTAP: rethinking the database from storage up | Databricks Blog © 2026 NTT DATA Japan Corporation
24. ふとした疑問 • 永続化データを列指向にしても行指向のRead/Writeの性能は劣化しない？ • オブジェクトストレージに永続化されていないデータはどうなる？ • Lakehouseで分析するときもLakebaseは起動が必要？ © 2026 NTT DATA Japan Corporation
25. 永続化データを列指向にしても行指向のReadの性能は劣化しない？ Readでは、大部分のデータはキャッシュから参照するため、ファイルフォーマットが及ぼす影響は大きくない。 キャッシュ戦略の工夫が重要である前提で、全キャッシュにデータが存在しないCold Readの性能は検証が必要。 Postgresサーバ Buffer Pool (memory) Read ✕ Local file cache ✕ PageServer Hit Hit Hit データの返却 データの返却 データの返却 ✕ Object Storage Hit データの返却 (Cold Read) 順番にキャッシュを確認し、それでも存在しない場合のみObject Storageにアクセス(Cold Read)する © 2026 NTT DATA Japan Corporation
26. 永続化データを列指向にしても行指向のWriteの性能は劣化しない？ Writeでは、更新は一時的にキャッシュを保持し、PageServerの余剰CPUを利用して永続化を実施する。 Mooncake Labsの技術や、Open Table Format化による圧縮率の向上もあり影響は発生しない。 PageServer 別処理を実行したうえで余ったPageServerのリソースを利用して 行指向→列指向の変換による永続化準備を実行する 買収したMooncake Labsが持っていた 行指向→列指向の変換技術を活用して最適化 引用 Object Storage © 2026 NTT DATA Japan Corporation Open Table Format形式にしたことで圧縮率が10倍以上となり 書き込みの通信量が無視できるレベルまで削減、高速化がかなった
27. オブジェクトストレージに永続化されていないデータはどうなる？ オブジェクトストレージへの永続化が未了の更新は、PageServerから取得してマージされる仕様である。 クエリ実行時のテーブルのシーケンス(LSN)を取得し、永続化済の更新との差分を抽出して対象を検出する。 Read処理の実行時 行指向のクエリエンジン Postgres PageServer ①最新断面の確認 列指向のクエリエンジン Lakehouse ③キャッシュにのみ存在する 変更(あれば)のマージ Object Storage / Lake (Parquet) © 2026 NTT DATA Japan Corporation ②データ取得
28. Lakehouseで分析するときもLakebaseは起動が必要？ 現時点では不明だが、LSNや直近の変更をLakebaseから取得する仕様により、起動が必要になる想定。 本件はプレビューの開始後に実機やドキュメントで実際の仕様を確認する必要がある。 行指向のクエリエンジン Postgres PageServer 最新断面の確認 列指向のクエリエンジン Lakehouse キャッシュにのみ存在する 変更(あれば)のマージ 行指向のクエリエンジン(Lakebase)が起動している必要があるのでは？ © 2026 NTT DATA Japan Corporation
29. 目次 • これまでのLakebase • LTAPとはなにものなのか • LTAPのアーキテクチャにDeep Dive ➢ まとめ © 2026 NTT DATA Japan Corporation 29
30. 『LTAP』 がもたらす恩恵 業務で更新したデータを、常に最新状態で分析やエージェントから活用、リアルタイムに意思決定に反映！ CDCやミラーリングといったETLが不要になり、運用負荷や処理コスト、データ不整合などの課題も解消する！ LTAP © 2026 NTT DATA Japan Corporation