共用方式為

使用 Azure Synapse Analytics 進行近乎即時的 Lakehouse 資料處理

Azure AI 搜尋服務
Azure Cosmos DB
Azure Data Lake
Azure 事件中樞
Azure Synapse Analytics

資料驅動型企業需要讓後端和分析系統與面向客戶的應用程式，進行近乎即時的同步處理。 交易、更新和變更的影響必須透過端對端流程、相關應用程式和線上交易處理 （OLTP） 系統準確反映。 OLTP 應用程式中變更反映在使用資料的下游系統中的可容忍延遲可能只有幾分鐘。

本文說明近乎實時數據處理的端對端解決方案，可讓 Lakehouse 數據保持同步。此解決方案會使用 Azure 事件中樞、Azure Synapse Analytics 和 Azure Data Lake Storage 來進行數據處理和分析。

備註

您可以使用 Microsoft Fabric 實作類似的架構，其提供統一的軟體即服務 （SaaS） 平台，用於資料擷取、轉換、儲存和分析。 在此情況下，Fabric 會取代架構的 Azure Synapse Analytics 元件，並提供即時資料處理和分析的整合功能。 如需詳細資訊，請參閱 Fabric Real-Time Intelligence。

Apache 和 Apache ® Spark 是美國和/或其他國家/地區的 Apache Software Foundation 註冊商標或商標。 使用這些標記不會隱含 Apache Software Foundation 的背書。

架構

顯示端對端數據處理解決方案數據流的圖表。

下載此架構的 Visio 檔案 。

資料流程

  1. 變更資料擷取 （CDC） 是來源系統接聽變更的先決條件。 Debezium 連接器 可以連線到不同的來源系統，並在變更發生時加以利用。 連接器可以擷取變更，並從各種關係資料庫管理系統 （RDBMS） 產生事件。 安裝 Debezium 連接器需要 Kafka 連線系統。

  2. 連接器會擷取變更資料，並將擷取的事件傳送至事件中樞。 事件中樞可以從多個來源接收大量數據。

  3. 事件中樞會直接將資料串流至 Azure Synapse Analytics Spark 集區，或以原始格式將資料傳送至 Data Lake Storage 登陸區域。

  4. 其他批次資料來源可以使用 Azure Synapse Analytics 管線將資料複製到 Data Lake Storage，並使其可供處理。 端對端擷取、轉換和載入 （ETL） 工作流程可能需要鏈結不同的步驟，或在步驟之間新增相依性。 Azure Synapse Analytics 管線可以在整體處理架構內協調工作流程相依性。

  5. Azure Synapse Analytics Spark 集區會使用完全支援的 Apache Spark 結構化串流 API 來處理 Spark 串流架構中的資料。 數據處理步驟會納入數據質量檢查和高階商務規則驗證。

  6. Data Lake Storage 會以開放式 Delta Lake 格式儲存已驗證的數據。 Delta Lake 提供不可部分完成性、一致性、隔離和持久性 （ACID） 語意和交易、可調整的元數據處理，以及現有 Data Lake 的統一串流和批次數據處理。

    使用索引進行查詢加速可改善 Delta Lake 效能。 來自 Data Lake Storage 已驗證區域的數據也可以是進一步進階分析和機器學習的來源。

  7. 來自 Data Lake Storage 驗證區域的資料，已轉換並擴充更多規則，進入其最終處理狀態，會載入至專用的 SQL 集區，以執行大規模分析查詢。

  8. Power BI 會使用透過專用 SQL 集區公開的資料來建置企業級儀表板和報表。

  9. 您也可以使用 Data Lake Store 中擷取的原始資料，以及 Delta 格式的驗證資料來執行下列工作：

    • 透過 Azure Synapse Analytics 無伺服器 SQL 集區進行非計劃性和探索性分析

    • 透過 Azure Machine Learning 進行機器學習模型定型和部署

  10. 對於某些低延遲介面，數據必須反正規化，才能讓單一數字伺服器延遲。 此使用案例主要針對 API 回應。 此案例會查詢 NoSQL 數據存放區中的檔，例如 Azure Cosmos DB 中的單一位數毫秒回應。

  11. Azure Cosmos DB 資料分割策略可能無法有效支援所有查詢模式。 如果是這種情況，您可以藉由編製 API 需要透過 Azure AI 搜尋存取的數據編制索引，來增強解決方案。 Azure Cosmos DB 和 AI 搜尋服務可以滿足大部分需要低延遲查詢回應的案例。 例如，零售應用程式會將產品目錄資料儲存在 Azure Cosmos DB 中，但需要全文檢索搜尋功能和彈性索引。 AI 搜尋可以索引資料並提供自動完成、同義詞和語義排名等進階搜尋功能。 當 Azure Cosmos DB 索引限制限制複雜的搜尋案例時，這些功能很有用。

元件

此解決方案使用下列 Azure 元件：

  • 事件中樞 是受控分散式擷取服務，可調整為擷取大量數據。 藉由使用事件中樞發行者-訂閱者機制，不同的應用程式可以將訊息傳送至事件中樞主題，而下游取用者可以連線並處理這些訊息。 事件中樞擷取功能可以在訊息抵達時以 Avro 格式將訊息寫入 Data Lake Storage。 這項功能可讓您輕鬆進行微批處理和長期保留案例。 事件中樞也提供與 Kafka 相容的 API，並支援結構描述登錄。 在此架構中，事件中樞會從多個來源接收 CDC 事件，並將其散發給下游取用者。

  • Data Lake Storage 是一種可擴展且安全的數據湖解決方案。 它形成儲存子系統，以原始和經過驗證的格式儲存所有資料。 在此架構中，Data Lake Storage 會大規模處理交易，並支援不同的檔案格式和大小。 階層命名空間可協助將數據組織成熟悉的資料夾結構，並支援 Unix 的可攜式作業系統介面 （POSIX） 許可權。 Azure Blob 檔案系統 （ABFS） 驅動程式提供與 Hadoop 相容的 API。

  • Azure Synapse Analytics 是一項無限的分析服務，結合了數據集成、企業數據倉儲和巨量數據分析。 此解決方案使用 Azure Synapse Analytics 生態系統的下列功能：

    • Azure Synapse Analytics Spark 集區 是提供隨選 Spark 執行階段的叢集，可將內建效能增強功能新增至開放原始碼 Spark。 在此架構中，客戶可以設定彈性的自動調整設定、透過 Apache Livy 端點從遠端提交作業，以及使用 Synapse Studio 筆記本介面來取得互動式體驗。

    • Azure Synapse Analytics 無伺服器 SQL 集區 是隨選查詢功能，可提供使用熟悉的 T-SQL 語法查詢湖屋資料的介面。 無需設定基礎結構，Azure Synapse Analytics 工作區部署會自動建立端點。 在此架構中，Azure Synapse Analytics 無伺服器 SQL 集區可讓您基本探索和探索就地的資料，以進行非計劃性查詢分析。

    • Azure Synapse Analytics 專用 SQL 集區 是佈建的資料倉儲資源。 它們使用單欄式儲存將資料儲存在關聯式表格中。 在此架構中，專用 SQL 集區會使用向外延展架構，將資料處理分散到多個節點。 PolyBase 查詢會將數據帶入 SQL 集區數據表。 數據表可以連線到Power BI進行分析和報告。

  • Power BI 是一項業務分析服務，提供視覺化介面來建立和存取報表和儀表板。 Power BI Desktop 可以連線到各種數據源、將來源合併成數據模型，以及建置報表或儀錶板。 在此架構中，您可以使用 Power BI 根據業務需求轉換數據，並與客戶共用視覺效果和報表。

  • Azure Cosmos DB 是全域分散式 NoSQL 資料庫服務。 此解決方案會針對需要單一位數毫秒響應時間和高可用性的應用程式使用 Azure Cosmos DB。 Azure Cosmos DB 提供跨所有 Azure 區域的多個區域寫入。

  • AI Search 是一個 AI 驅動的平台即服務 （PaaS），使開發人員能夠為其應用程序和網站構建豐富的搜索體驗。 當 Azure Cosmos DB 索引模型對於進階搜尋案例來說太嚴格時，請在此解決方案中使用 AI 搜尋。 AI 搜尋透過拼字錯誤容忍度、自動完成、語義排名和同義詞匹配等功能實現靈活的查詢。 您可以使用 REST API 或 .NET SDK 來查詢索引資料。 如果您需要從多個索引中檢索數據，您可以將它們合併為單一索引，或使用 複雜的資料類型 來對巢狀結構進行建模。

案例詳細資料

以近乎即時的方式處理變更的端對端工作流程需要：

  • CDC 技術。 OLTP 應用程式可能會有不同的後端資料存放區，例如 SQL Server、MySQL 和 Oracle。 第一個步驟是接聽變更發生時，並向前傳播變更。

  • 擷取緩衝區，以大規模發佈變更事件。 此服務應該能夠在訊息送達時處理大量數據。 個別訂閱者可以連線到此系統並處理數據。

  • 依原狀格式針對數據的分散式和可調整記憶體。

  • 分散式且有效率的串流處理系統，可讓使用者重新啟動和管理狀態。

  • 大規模執行的分析系統，可決定商務決策。

  • 自助分析介面。

  • 對於低延遲的 API 回應，NoSQL 資料庫可儲存資料的非正規化表示法。

  • 在某些情況下，系統要編製數據索引、定期重新整理索引，並讓最新的數據可供下游取用。

上述所有技術都應該使用相關的安全性結構來進行周邊安全性、驗證、授權和資料加密。

潛在使用案例

此解決方案適用於下列使用案例：

  • 需要將變更從 OLTP 傳播到在線分析處理 （OLAP） 的產業。

  • 需要資料轉換或擴充的應用程式。

實時數據處理案例對於金融服務產業尤其重要。 例如，如果保險、信用卡或銀行客戶進行付款，然後立即連絡客戶服務，客戶支援專員必須擁有最新資訊。

類似的情況也適用於零售、商業和醫療保健行業。 啟用這些場景可以簡化運營，並提高組織生產力和客戶滿意度。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

可靠性

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性的設計檢閱檢查清單。

  • Event Hubs 在進階層和專用層上提供 90 天的資料保留。 針對故障轉移案例，您可以在配對區域中設定次要命名空間，並在故障轉移期間加以啟用。 啟用區域備援，以確保針對資料中心故障的復原能力。 您可以使用事件中樞擷取功能，將資料保存至 Data Lake Storage，以進行重播和復原案例。

  • Azure Synapse Analytics Spark 集區作業會每 7 天回收一次，因為節點會關閉以進行維護。 當您處理與系統繫結的服務等級協定 （SLA） 時，請考慮此活動。 對於復原時間目標 （RTO） 約為 15 分鐘的許多案例來說，此限制不是問題。 請確定已設定自動調整，以處理負載尖峰和節點失敗。

  • 使用具有異地備份和區域備援儲存體 （ZRS） 的專用 SQL 集區，以防止區域和區域中斷。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。

  • 您可以根據工作負載特性，從不同的事件中樞層中選取。 事件中樞會根據儲存在 Data Lake Storage 上的資料量，個別擷取儲存體。

  • 請考慮透過 Data Lake Storage 上的層進行物件生命週期管理。 隨著資料老化，您可以將資料從需要存取最新資料進行分析的熱層移至成本較低的冷儲存層。 冷儲存層是長期保留的符合成本效益的選項。

  • 當您未在開發或測試環境中使用它時，您可以暫停專用 SQL 集區。 您可以視需要排程腳本來暫停集區，也可以透過入口網站手動暫停集區。

  • 針對 Azure Synapse Analytics Spark 集區，請使用自動調整，根據工作負載需求動態配置資源，並避免過度佈建。 選擇滿足效能需求的最小池大小，並使用自動終止設定及時關閉閒置池。 透過將隨機操作、快取中間結果和調整分割區大小來優化 Spark 任務，以減少執行時間和資源消耗。 使用 Azure Synapse Analytics 監視工具監視使用量，並根據作業效能和成本趨勢調整設定。

  • 若要優化 Azure Cosmos DB 中的成本效益，請量身打造索引原則，以僅包含必要的路徑，以減少儲存體和要求單位 （RU） 耗用量。 選擇適當的 API 和一致性層級，以符合工作負載需求，而不會過度佈建。 使用自動調整輸送量，根據需求動態調整 RU，並儘可能將工作負載合併到較少的容器中，以將額外負荷降到最低。 使用 Microsoft 成本管理定期監視使用情況，並設定警示以避免非預期的費用。

  • 使用 Azure 定價計算機 來預估定價。

效能效率

效能效率是指工作負載能夠有效率地調整以符合使用者需求。 如需詳細資訊，請參閱 效能效率的設計檢閱檢查清單。

  • 您可以透過資料分割來調整事件中樞，這會將事件分散到多個平行記錄 （分割區） 之間，以增加輸送量。 若要保留相關事件的順序，例如來自相同客戶或裝置的事件，請在發佈事件時使用一致的 分割區索引鍵 。 此做法可確保所有相關事件都會路由傳送至相同的分割區，讓事件中樞維護其順序。 根據預期的事件量調整輸送量單位 （TU）。 使用擷取功能以 Avro 或 Parquet 格式直接寫入 Data Lake Storage，以有效率地進行下游處理。

  • 您可以根據工作負載，使用小型、中型或大型虛擬機器 （VM） SKU 來設定 Azure Synapse Analytics Spark 集區。 您也可以在 Azure Synapse Analytics Spark 集區上設定自動調整，以考慮工作負載中的活動尖峰。 如果您需要更多運算資源，叢集會自動相應增加以滿足需求，並在處理完成後相應減少。

  • Delta Lake 在確保此架構中的高效能、可靠且可調整的資料處理方面扮演核心角色：

    • 啟用 Delta Lake 中的自動最佳化和自動壓縮功能，以在寫入作業期間自動管理小型檔案並優化資料配置。 這些功能非常適合串流或頻繁的微批次擷取案例，因為它們可減少手動介入的需求。

    • 用於 OPTIMIZE 手動將小檔案壓縮成較大的檔案。 當您想要在串流擷取建立許多小檔案後提高讀取效率並減少中繼資料額外負荷時，此做法特別有用。

    • 在經常查詢的資料行（例如時間戳記或客戶ID）上使用 OPTIMIZE ， ZORDER BY 以共置相關資料。 此查詢可減少讀取期間掃描的資料量，以改善查詢效能。

  • 若要優化專用 SQL 集區中的效能以進行近乎即時的分析，請執行下列工作：

    • 使用適當的散發方法，例如雜湊、循環、複製方法。
    • 依時間或區域分割大型資料表，以改善查詢修剪。
    • 針對經常存取的資料使用具體化檢視和結果集快取。
    • 維護 up-to日期統計資料和索引，以有效率地執行查詢。
    • 指派資源類別來管理記憶體和並行。
    • 使用 SQL 深入解析和動態管理檢視 （DMV） 等內建工具來監視效能。

    這些做法有助於確保大規模分析工作負載中的低延遲、高輸送量效能。

  • 若要在即時分析案例中優化 Azure Cosmos DB 的效能，請設定適當的索引原則以減少查詢延遲和儲存體額外負荷，並選擇正確的一致性層級，以平衡效能與資料準確性。 有效地使用分割區來均勻分配工作負載並避免熱分割區。 啟用多區域寫入以進行低延遲全域存取，並使用 RU 根據需求動態調整來監視輸送量。 這些做法有助於確保高擷取、低延遲工作負載的回應性、可擴展的效能。

參與者

本文由 Microsoft 維護。 下列參與者撰寫本文。

主要作者：

其他投稿人：

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

下一步