湖泊交易/分析處理（LTAP）是一種資料架構，能從湖中統一的資料儲存層，在一個治理模式下同時服務交易（OLTP）與分析（OLAP）工作負載，因此不必同時讓交易系統與分析系統保持同步。它移除了團隊傳統維護的變更資料擷取（CDC）、複製與轉換流程，這些流程是為了將營運資料複製到獨立的分析系統。 Azure Databricks 是在 Lakebase 儲存架構上建構 LTAP。 有關公告，請參閱 Databricks 推出 LTAP：首個 Lake 交易/分析處理架構。
LTAP 是一個架構，而非單一功能。 Azure Databricks 透過一系列持續開發與擴充的 Lakebase 功能來實現這些功能。 你能擁有的能力取決於你的雲端。 本頁說明了建築架構。 關於你今天可以在雲端使用的功能，請參見實 作 LTAP 的能力。
Important
在閱讀本頁之前，請先閱讀 Lakebase 架構 ，了解 Lakebase 架構及其組成部分：無狀態的 Postgres 運算、安全保管者、頁面伺服器與雲端物件儲存。 LTAP 直接建立在 Lakebase 如何將運算與儲存分離之上，而本頁其餘部分則建立在這個基礎之上。
保持兩疊數據同步的成本
應用程式將資料工作分為兩種工作負載。 交易型（OLTP）工作負載一次處理幾列，需要快速處理這些列的全部內容，例如處理付款或回傳 API 結果。 分析型（OLAP）工作負載會尋找跨大型資料集的洞察，通常會聚合並連接多個資料列，例如預測銷售或偵測詐欺。 這些模式是相反的：OLTP 需要對每列持續低延遲的讀寫，而 OLAP 則需要掃描並彙整大量資料。 數十年來，答案是兩個獨立系統：用於應用的交易資料庫，以及用於分析的資料倉儲或湖庫。
串接這兩個堆疊是成本最高的部分。 保持同步意味著執行變更資料擷取（CDC）、串流管線，以及讀取副本，這些副本的唯一任務是將資料從一個系統複製到另一個系統。 該基礎設施脆弱，從資料寫入到分析之間增加了延遲，且與主要交易資料庫爭奪資源。 隨著應用程式與 AI 代理越來越需要對最新交易資料進行分析，這個缺口拖慢了團隊的進度。 在兩個系統間複製資料也會造成治理風險：血統可能隨著資料移動而中斷，這使得像 GDPR 下架請求這類義務更難達成。
LTAP 如何在儲存層統一資料
LTAP 並非在兩個堆疊之間打造更好的管線，而是徹底免除對管線的需求。 它是透過從儲存層開始重新構想資料庫來做到這一點。
Lakebase 已經將無狀態的 Postgres 運算與由安全管理員、頁面伺服器及雲端物件儲存組成的持久儲存層分離。 當達到法定人數的 safekeepers 已將其預寫式日誌持久化記錄後，交易才會提交；接著 pageservers 會以非同步方式將這些變更具體化到雲端物件儲存中，因此資料不再被鎖定在單一資料庫引擎內。
Note
關於 Lakebase 如何分離運算與儲存，請參見 Lakebase 架構。
LTAP 會為該儲存層增加一層。 當 Lakebase 儲存將資料實體化為物件儲存時，會將列導向的 Postgres 資料轉碼成 Parquet 的列式佈局，當資料落入湖中時，並可透過 Delta 和 Iceberg 等開放表格格式讀取。 這種轉碼技術使得單一資料副本同時服務 OLTP 與 OLAP 工作負載。 它的設計是為了讓欄目文案忠實且高效地呈現 Postgres 原文：
- 語義保留。 Lakebase 儲存的將每個值轉碼為欄位形式，同時保留原始 Postgres 表示，因此任何相容 Postgres 的引擎都能在不遺失資訊的情況下重新詮釋資料。 無法直接對應到 Parquet 的型別，例如
NaNNUMERIC溢位，或是 vector、array、geography 和 JSON 等擴充型別，會保留在一個溢位欄位中；該欄位保存的是標準的 Postgres 表示法。 - 排版則被保存下來。 轉碼會保留中間的資料列版本，因此欄式副本會包含與資料列資料相同的版本資訊。
- 欄位式資料壓縮效果很好。 柱狀配置具有很高的壓縮率，可降低儲存空間占用，並減少進出物件儲存的資料量。
轉碼完全在儲存層執行，與主要的 Postgres 實例隔離，因此不會影響你的交易式服務工作負載。 它建立在 Lakebase 已經做過的事上：將已提交的資料沖洗到雲端物件儲存。 LTAP 只是將欄式格式加入到相同的 flush 中。 沒有需要你建置的管線，也沒有外部程序來輪詢你的資料庫。
不是所有東西都轉碼了。 Postgres 索引會在持久儲存層中維持其原始形式，而不是轉換為欄式資料，因此交易式點讀取與查找仍能保持快速，而欄式副本則用於分析。
由於資料存在外部化的版本控制儲存中，建立分支或還原到某一時間點屬於中繼資料操作，而非實體副本。 你可以在幾秒鐘內分支大型生產資料庫，對該分支進行實驗或風險遷移，然後丟棄，且不會重複底層資料。
Note
Lakebase 分支是你資料庫儲存的寫入複製複製：它共享父節點的現有資料，只儲存變更部分，因此一開始不會重複資料。 點點還原使用相同的版本化儲存空間，將資料庫回溯到還原視窗中的較早時刻。 欲了解更多，請參閱 資料庫分支 與 時間點還原。
這種儲存層級的方法正是 LTAP 與變更資料擷取（CDC）的區別所在。 CDC 會使用持續輪詢主資料庫的外部程序，以及將資料列變更轉換為欄式資料的資料管線，將資料從你的 OLTP 儲存體複製到獨立的分析層。 這條管線會消耗你主要交易資料庫的資源，讓你自己處理結構變更和邊緣案例，並且在資料新鮮度與管線成本之間取得平衡，同時還會增加故障點。 LTAP則採取儲存層級的方法：湖底儲存將資料轉碼到湖中，作為正常儲存運作的一部分，沒有外部流程與您的工作負載競爭，也沒有管線供您建置或維護。
LTAP的三大支柱
在儲存層統一資料賦予 LTAP 三個定義性特性。
- 普世治理。 Unity Catalog 可跨這兩種工作負載，管控對您資料單一邏輯副本的分析存取。
- 專為特定用途打造的引擎。 Postgres 負責交易，Lakehouse 負責分析，兩者互不妥協。
- 開放式儲存中的單一邏輯副本。 兩個引擎都會讀取您以開放格式儲存的同一份資料，無需讓副本或管線保持同步。
普遍治理
Unity Catalog 可跨這兩種工作負載控管對您資料的分析存取。 註冊 Lakebase 資料庫後，Unity Catalog 會對讀取該資料庫的外部運算者套用權限、血統和稽核。
Note
Unity Catalog 治理目前適用於 分析型存取：也就是會讀取您已註冊 Lakebase 資料的外部運算，例如 Lakehouse//RT 和 Change Data Feed。 目前尚未直接管理個別 Postgres 表格。 透過 交易 路徑存取，也就是連接到 Postgres 的應用程式和用戶端，仍由標準 Postgres 權限GRANT （和 REVOKE）控制，而非由 Unity 目錄控制。 實務上，Unity 目錄管理分析存取與湖庫存取，而 Postgres 的角色與權限則管理交易存取。
專為特定用途打造的引擎
Postgres 負責你的交易工作，Lakehouse 則負責分析，兩者各具其設計的優勢。 一個常見的誤解是，將兩者整合就意味著你的營運資料會變成存放在 Iceberg 中的冷資料。 事實並非如此。 Lakebase 仍維持標準 Postgres。 索引、分支、時間點還原、擴充功能，以及低延遲的點式讀取與寫入，全都會像目前一樣繼續完全正常運作。
分析讀取不會與你的交易工作量競爭，因為它們與主要的 Postgres 實例隔離。 當分析引擎如 Lakehouse//RT 查詢即時 Lakebase 資料時，會回傳一個全新且交易一致的結果，且不複製資料：
- 引擎從物件儲存中的欄位副本讀取大部分資料，而非從 Postgres 讀取。
- 為了獲得交易一致性的視圖，它只向 Postgres 詢問目前的日誌序號（LSN），這是一個標記預先寫入日誌位置的單一值。 這是一個便宜的元資料查詢。
- 對於尚未在湖中實現的一小部分近期變更，它會從網頁伺服器讀取並合併到最上面。
Postgres 除了回傳那個單一 LSN 外，不處理任何分析讀取流量，轉碼則是在儲存層執行，而不是在服務你應用程式的 Postgres 實例上。 你的營運工作量會如預期般持續運作。
一個位於開放儲存空間的單一邏輯副本
由於資料以柱狀Parquet形式存在於湖中，可透過Delta和Iceberg等開放表格格式讀取，Lakebase（OLTP）與Lakehouse（OLAP）共享相同的儲存基礎。 您可在兩種工作負載之間維護單一邏輯資料副本，而不必將交易式資料庫與另一份獨立的分析用副本進行核對。
每個引擎都可以快取或以不同的 物理 格式來呈現該資料以提升效能。 Lakebase 使用 Postgres 頁來快速執行 OLTP 點查詢，而分析引擎則讀取 Parquet 列式資料。 你仍然使用單一 邏輯 資料集，而不必維持獨立的交易與分析副本並保持同步。
每張桌子只有一位寫手，可能是 Lakebase 或 Lakehouse。 兩個引擎都會讀取同一份邏輯副本，因此相同的資料在你的應用程式和分析部門中都能取得，無需第二份副本。
你需要改變使用 Lakebase 的方式嗎
No. 採用 LTAP 功能不需要資料遷移或改變應用程式與 Lakebase 的連接方式。 Lakebase 依然是標準的 Postgres：你現有的擴充功能、索引、查詢和應用程式代碼都維持不變。 每個 LTAP 功能 都是獨立的，因此你可以在工作負載需要時採用任何一個。
實現 LTAP 的功能
你透過一套 Lakebase 功能，將 LTAP 架構付諸實務。 每個方案都建立在上述共享儲存基礎上，並共同涵蓋資料在 LTAP 中的路徑：
- 治理與註冊：將 Lakebase 資料納入 Unity 目錄。
- 在 Lakebase 中提供 Lakehouse 資料：已同步的資料表。
- 查詢即時 Lakebase 資料：使用 Lakehouse//RT 進行分析，使用 Lakebase 變更資料摘要處理變更串流。
下圖展示了這些能力如何寫入並讀取由 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 目錄資料表資料，以進行低延遲的 OLTP 讀取。 LTAP Direct Writes（測試版）可加速所有同步模式下的初始載入，以及完整刷新。 |
| Lakehouse//RT 查詢 Lakebase | Beta | 對即時 Postgres 資料執行交易一致的 OLAP 查詢，同時不影響 Lakebase 的 OLTP 效能。 |
| Lakebase 變更資料串流 | 公開預覽 | 將 Lakebase Postgres 資料表的列級變更儲存為 Unity 目錄 Delta 資料表，用於下游管線與稽核。 |
如何著手實施
既然你已經了解這些功能，接下來的問題是你的工作量需要哪些功能。 你透過結合與資料如何流經你的架構相符的各項能力來實作 LTAP。
關鍵決策在於方向：對每個資料集，哪個系統擁有寫入權？ 每個資料表都有一位寫入者，這決定了你使用哪些功能。
- Lakebase 擁有寫入權限。 你的應用程式會寫入 Postgres，你希望這些操作資料能用於分析，但不會複製出去。例如，銷售應用程式會在訂單和付款發生時即時寫入 Lakebase。 使用 Lakehouse//RT 針對這些訂單執行即時營收儀表板，或使用 Lakebase Change Data Feed，將每筆訂單變更串流至下游管線或稽核日誌。
- 湖邊別墅擁有這筆水。 你的資料是在湖屋中產生或維護的，你希望應用程式能對它進行低延遲的 OLTP 讀取。 例如，每晚執行的湖倉作業會計算產品推薦或定價表。 使用同步資料表將資料提供到 Lakebase，讓應用程式能以低延遲讀取。
將每個資料集映射到這些方向之一，將 資料庫註冊到 Unity 目錄中進行治理，然後依照能力文件實作每條路徑。 單一應用程式通常會同時採用雙向流程：將 lakehouse 中的參考資料提供至 Postgres，同時將自身的交易寫入回傳給分析系統。 可用性因雲端而異，請查看上方的能力表以確認你的雲端所提供的內容。
下一步
- Lakebase 架構：了解 Lakebase 如何區分無狀態運算與持久儲存。 參見 湖基建築。
- 在 Unity Catalog 中註冊資料庫：治理 Lakebase 資料，並從資料湖倉進行查詢。 請參閱在 Unity Catalog 中註冊 Lakebase 資料庫。
- 使用同步資料表提供資料：將 Unity Catalog 的資料表資料同步到 Lakebase，以進行低延遲讀取。 請參見 「提供與同步資料表的湖屋資料服務」。
- Lakebase 變更資料摘要：將資料列層級的變更串流到湖倉，供管線處理與稽核之用。 請參閱 Lakebase Change Data Feed。