Lakeflow 管線提供了一個宣告式框架，用於使用 SQL 和 Python 建構批次與串流資料管線。 它們的核心概念包括管線、流程、串流資料表、實體化檢視和接收端，這些概念會協同運作，透過自動化協調與增量更新來處理資料。
Lakeflow 管線擴充了 Apache Spark™ 宣告式管道（SDP）。 想了解更多關於 SDP 及其與 Lakeflow 管線的比較，請參閱 Apache Spark 宣告式管線。
Tip
剛接觸管線嗎？ 從 如何使用 Lakeflow 管線 開始，了解你如何在整個生命週期中使用管線及其原因，並附上每個階段的任務連結。
備註
湖流量管線需要購買 高級方案。 如需更多資訊，請聯絡您的 Databricks 客戶團隊。
管線有哪些好處？
與在 Databricks 執行環境上使用 Apache Spark 及 Spark 結構化串流 API 並透過 Lakeflow Jobs 手動編排來開發資料工程流程不同，管線的宣告性質帶來以下好處：
- 自動編排：管線以正確順序執行處理步驟（稱為「流程」），並以最大平行度進行，並逐步重試暫時性失敗——從 Spark 任務、流程到整個管線。
- 宣告式處理：宣告式函式將數百行手動 Spark 與結構化串流程式碼簡化為少數程式碼。 AUTO CDC API 可處理變更資料擷取（CDC）事件——包括 SCD Type 1 和 Type 2——而無需手動撰寫程式碼來處理亂序事件，或處理如浮水印等串流處理概念。
- 增量處理： 增量處理 引擎保持具體化視圖的即時性：你用批次語意撰寫轉換邏輯，引擎僅在可能時重新處理新的或變更的原始資料。
關鍵概念
下圖說明了管線中最重要的概念。
資料集
管線會產生三種資料集，每種資料集的處理語意都不同：
| 數據集類型 | 紀錄的處理方式 |
|---|---|
| 串流資料表 | 每筆記錄都只會被處理恰好一次，前提是來源為只追加的。 串流資料表適合用於資料擷取，以及對持續增長的資料進行增量處理。 |
| 具現化視圖 | 結果會視需要重新計算，以反映資料的當前狀態。 實體化視圖適合用於轉換、彙總，或預先計算供多個下游資料集使用的結果。 |
| 檢視 | 按需評估，不會持久化。 使用檢視來進行中間轉換和檢查，這些不需發佈到目錄。 |
串流表是一種 Unity Catalog 管理的表格形式，同時也是串流目標。 串流資料表可以有一或多個串流流程 （附加、 自動 CDC） 寫入其中。 你可以明確且獨立於目標串流表定義串流流程，或隱含地作為串流表定義的一部分。
具體化檢視也是 Unity Catalog 管理資料表的一種形式，也作為批次目標。 具體化檢視可以寫入一或多個具體化檢視流程。 具體化檢視與串流資料表的不同之處在於，您一律會隱含地將流程定義為具體化檢視定義的一部分。
何時使用檢視、實體化檢視與串流資料表
在實作管線查詢時，選擇最適合你使用情境的資料集類型。
考慮使用視圖來：
- 將大型或複雜的查詢拆解成更易管理的查詢。
- 使用預期驗證中繼結果。
- 減少儲存和計算不需要保留之結果的成本。 由於數據表已具體化，因此需要額外的計算和記憶體資源。
請考慮在下列情況下使用具體化檢視：
- 多個下游查詢會取用數據表。 由於實體化檢視會快取結果，下游查詢會讀取預先計算的結果，而非每次存取都重新計算查詢。
- 其他管道、工作或查詢會消耗該表格。 由於實體化檢視會實體化為 Unity Catalog 資料表，因此在定義該檢視的管線之外的取用者也可以查詢它。 視圖不會被實體化，所以你只能在同一條管線內使用它們。
- 你應該在開發過程中檢查查詢的結果。 因為具體化的視圖是實體化的，可以在流程外查詢，你可以在開發過程中驗證計算的正確性。 驗證之後，將不需要具體化的查詢轉換成檢視。
- 你的查詢會進行聚合或連接，或者來源資料會因為更新和刪除而改變，而不只是增加。 具體化檢視會讓結果與來源資料的當前狀態保持一致，而串流資料表則是為僅附加來源設計，且每個記錄只處理一次。
請考慮在下列情況下使用串流資料表：
- 查詢是針對持續或累加成長的數據源所定義。
- 查詢結果應該以累加方式計算。
- 管線需要高輸送量和低延遲。
備註
串流數據表一律會針對串流來源定義。 您也可以搭配 AUTO CDC ... INTO 使用串流來源，以套用 CDC 資料來源的更新。 請參閱 AUTOTO CDC API：使用管線簡化變更資料擷取。
Flows
流程是管線中基礎的資料處理概念，支援串流與批次語意。 流程會從來源讀取資料、套用使用者定義的處理邏輯，並將結果寫入目標。 管線與 Spark 結構化串流共享相同的串流流程類型（Append、 Update、 Complete）。 （目前僅提供 Append 和 Update 流程。）如需詳細資訊，請參閱 Structured Streaming 中的輸出模式。
管線還提供其他流量類型：
- AUTO CDC 是 Lakeflow 管線中獨特的串流流，能處理亂序的 CDC 事件，並支援 SCD Type 1 與 Type 2。 自動 CDC 在 SDP 中無法使用。
- 實體化檢視是一種管線中的批次處理流程，會在可行情況下僅處理來源資料表中的新資料與變更。
詳情請參閱 「隨湖流量管線流量逐步載入與處理資料」。
Sinks
匯入是管線的串流目標，支援 Delta 表格、Apache Kafka 主題、Azure EventHubs 主題及自訂 Python 資料來源。 接收端可寫入一個或多個串流流程（Append、Update）。
詳情請參見 湖流管線中的匯。
Pipelines
管線是開發與執行的單位，也是用來容納你所定義的流程、串流資料表、實體化檢視表和接收端的容器。 你可以先在管線原始碼中定義這些物件，再執行管線來建構管線。 在管線運行時，它會分析定義物件的相依關係，並自動協調執行與平行化的順序。
詳情請參見 「什麼是管線？」。
你也可以在 Lakeflow 管線外定義獨立的實體化視圖和串流資料表，由 Azure Databricks 管理管線。 要比較兩種方法，請參見 獨立管線與湖流量管線。
管線會以觸發模式或連續模式運作，控制新資料到來時是否刷新可用資料，並停止或保持資料表新鮮。 要比較兩種模式，請參見 觸發式與連續流水線模式。
資料擷取
管線支援 Azure Databricks 中可用的所有資料來源。 Databricks 建議針對大部分的擷取使用案例使用串流數據表。 對於雲端物件儲存中的檔案，Auto Loader 提供增量式、冪等式載入。 對於串流資料，管線可以直接從訊息匯流排（如 Apache Kafka、Azure 事件中樞、Amazon Kinesis 和 Google Pub/Sub）匯入資料。 請參閱在管線中載入資料。
資料品質
期望是資料集上的可選條款，用來驗證資料在管線中流動的過程。 你將期望定義為 SQL 布林限制，並指定當記錄失敗時會發生什麼：警告、丟棄記錄，或更新失敗。 請參閱 使用管線期望來管理資料品質。
Delta 整合
所有由管線建立和管理的資料表都是 Delta 資料表。 它們具備與 Delta Lake 相同的保障，包括 ACID 交易、時間旅行和結構描述強制執行。 管線會新增額外的資料表屬性，並利用 預測性優化（包括 OPTIMIZE 和 VACUUM 操作）進行自動維護。 參見Azure Databricks 中的 Delta Lake 是什麼？。