共用方式為


使用適用於 NoSQL 的 Azure Cosmos DB 進行反向擷取、轉換和載入 (ETL)

雲端數據倉儲和數據湖會擴充數據、集中資訊,並啟用功能強大的分析。 但數據的實際價值在於將深入解析轉換成真實世界的決策和客戶體驗。 若要達成此目標,整潔、高品質的數據必須從倉儲或數據湖移到作業系統。 反向 ETL 會將數據從數據倉儲層,例如 Azure Databricks 中的 Delta Lake 或 Microsoft Fabric,移回作系統。 此移轉步驟可讓下游應用程式使用最新的擴充數據來進行即時作業分析。 反向 ETL 在填補分析與作業之間的鴻溝,並發揮數據資產的最大潛力方面扮演關鍵角色,能夠促進更優質的決策制定。

適用於 NoSQL 的 Azure Cosmos DB 專為超低延遲、全域散發和 NoSQL 延展性所設計,因此非常適合即時應用程式。 透過反向 ETL,您可以將差異擴充的資料同步處理至 Azure Cosmos DB,以啟用即時作業分析。 您可以使用此模式來推送產品類別目錄、個人化客戶資訊、定價更新、庫存數據和功能建議等數據。 您可以將此數據推送至作業數據存放區,讓下游應用程式能夠立即做出數據驅動決策。

解決方案架構

實作反向 ETL 的簡化架構是由 Apache Spark 和 Azure Databricks 所組成。 此架構會從 Delta 表等來源擷取清理和增強的數據,並將數據寫回適用於 NoSQL 的 Azure Cosmos DB 作業存放區。

由移轉數據之多個元件所組成的反向 ETL 架構圖表。

此圖表包含下列元件:

  • 包含這類數據的數據源;產品數據、CRM 數據、訂單資訊和廣告資訊。

  • ETL 工作流程 會將數據從原始數據源移至數據倉儲或數據湖,以使用 Azure Databricks 或 Microsoft Fabric 等解決方案來儲存和擴充數據。

  • 反向 ETL 工作流程 ,使用 Apache Spark 和 Delta 數據表將擴充的數據遷移至作業數據存放區

  • 作業資料存放區,例如 Azure Cosmos DB for NoSQL,以在即時應用程式中使用擴充的資料。

反向 ETL 流程可實現如下案例:

  • Real-Time 決策: 應用程式不需要依賴分析師或 SQL 即可存取最新的數據。

  • 資料啟用:系統會將深入解析推送到有此需求的位置,而不只是推送到儀表板。

  • 統一真相來源: Delta Lake 可作為標準層,確保系統之間的一致性。

數據擷取階段

對於功能存放區、建議引擎、詐騙偵測或即時產品目錄等案例,請務必將數據流分成兩個階段。 這些階段假設您有從 Delta Lake 到適用於 NoSQL 的 Azure Cosmos DB 反向 ETL 管線。

從 Delta Lake 到適用於 NoSQL 的 Azure Cosmos DB 的兩個反向 ETL 階段圖表。

此圖表中的階段包含:

  1. 初始載入:初始載入是一個一次性批次流程步驟,用於匯入所有歷史數據,從 Delta 表到 Azure Cosmos DB (適用於 NoSQL)。 它會藉由確保作業數據存放區具有完整的歷程記錄數據,來設定反向 ETL 管線的基礎。 此載入是開始增量同步處理資料之前的基本步驟。

  2. 異動數據擷取(CDC)同步 處理:此步驟會實作增量式連續同步,將 Delta Tables 的變更持續同步至適用於 NoSQL 的 Azure Cosmos DB。 在啟用差異變更資料摘要 (CDF) 後,便可擷取差異資料表中的變更。 您可以實作批次式或串流式變更資料擷取 (CDC) 同步處理。

Azure Cosmos DB for NoSQL 的 CDC 同步處理有兩個選項:

  • 批次 CDC 同步處理:此選項會依排程執行 (例如每日或每小時),並根據自上個版本或時間戳記起所擷取的變更載入資料的累加快照集。

    小提示

    切換到較新的 Azure Cosmos DB 快照,以避免在從增量數據表向用於 NoSQL 的 Azure Cosmos DB 載入大量增量數據時出現數據不一致的問題。 例如,寫入至新的容器或使用版本旗標時,在完整載入新數據之後,將指標翻轉至較新的螢幕快照。

  • 串流 CDC 同步處理:此選項會以近乎即時的方式持續同步累加變更,讓目標系統保持最新狀態,且延遲最少。 此選項使用 Apache Spark 結構化串流來持續擷取和寫入變更。 Delta 表格可作為具有 readChangeData = true 的串流來源,而適用於 NoSQL 的 Azure Cosmos DB 連接器則作為串流接收端。

    小提示

    指定檢查點位置以確保追蹤進度,並避免重複寫入。

最佳做法

  • 使用 Apache Spark 批次作業搭配適用於 NoSQL 的 Azure Cosmos DB 連接器來執行初始載入步驟。

  • 如果預計初始負載相對於分配的輸送量會消耗大量 RU/秒,請將擷取輸送量切換為標準化的預配置輸送量,以優化處理效率。 具體來說,如果在初始載入流程的大部分期間,一直使用最大的每秒要求單位數 (RU/秒),請使用標準佈建的輸送量。 在此案例中,請勿針對初始載入步驟使用自動縮放輸送量。

    小提示

    如果 標準化 RU 耗用量計量 一致為 100%,則計量表示初始負載一致會耗用最大自動調整要求單位 (RU)。 此閾值明確指出此案例適用於您的工作負載,而且您應該使用標準布建的輸送量。

  • 選擇可將平行處理原則最大化的有效分割區索引鍵。 如需詳細資訊,請參閱 有關分區和分區鍵的建議

  • 針對大型資料擷取,規劃所有分割區的分割區總數和每秒 RU 總計。 如需詳細資訊和指導,請參閱資料分割和輸送量的建議 (部分機器翻譯)。

  • 使用 Apache Spark 輸送量控制 來限制作業的要求單位 (RU) 耗用量。 輸送量控制有助於防止目標作業容器多載。

  • 在 Azure Cosmos DB for NoSQL 中盡可能使用自動縮放輸送量來進行 CDC 同步處理,因為自動縮放會根據使用量動態擴大/縮小每秒 RU 數。 自動縮放輸送量很適合定期和尖峰的工作負載使用,例如已排程的 CDC 同步處理作業。 如需詳細資訊,請參閱 輸送量建議

  • 預估初始資料載入步驟的初始擷取期間。 如需詳細資訊和範例,請參閱 輸送量估計

後續步驟