azure雲平臺介紹（妙手數評流式服務和Azure）

2023-09-18 02:48:14

在我之前的角色中，我使用 CDC（變更數據捕獲）、數據複製、ETL（提取-轉換-加載）和 RDBMS（關係資料庫管理軟體）組件的專有技術開發和管理了一個大型近實時數據倉庫。準確地說，我們的流程是 E-L-T，這意味著對於實時數據倉庫，資料庫不斷運行混合工作負載，激烈競爭系統資源，只是為了保持維度模型最新。有時因次優性能、延遲挑戰和供應商鎖定而感到沮喪，我經常考慮遷移到使用開源/大數據技術（稱為 ETL 卸載）構建的 ETL 過程，以及這是否會提供真正的水平可擴展性。當然，我對技術、所涉及的學習曲線和所需的開發時間之間的根本差異持謹慎態度。

然而，最近我有幸在一個 POC 上工作，它需要使用 Azure Databricks 的流 ETL 管道，所以我罕見地瞥見了這個遷移挑戰可能是什麼樣的，主要差異以及是否會有任何重大交易 -關閉。

在這篇博客中，我想通過使用 Azure Databricks 中最新最好的東西來構建一個更「傳統」但實時的 ETL 管道來分享我的經驗。我說「傳統」是因為結果應該代表數據倉庫中的星型架構，特別是 Azure SQL 數據倉庫，儘管在流模式下源和目標之間的延遲很低。我還想考慮納入數據湖的流行概念，這是一種經濟高效的可擴展存儲選項。幸運的是，Azure Data Lake Storage gen 2 在本月初正式發布，並且完全支持 Databricks 連接器。

本博客的第一部分將介紹主要概念和組件，以及用於演示的整體架構。第二部分介紹了 Azure 中的完整設置，第三部分介紹了在一系列 Databricks 筆記本中開發的 ETL 管道。但是，如果您渴望深入了解細節，您將能夠在 Azure 中以最少的設置運行管道。

但是，如果您在我們開始之前感覺像是一個輕鬆的消遣，那麼從 ETL 開發人員的角度來看，這是一段半虛構的時間之旅……

Databricks 由 Apache Spark 的創建者創立，提供了一個統一平臺，旨在提高數據工程師、數據科學家和業務分析師的工作效率。 Databricks 平臺提供開箱即用的交互式和協作筆記本體驗，並且由於其優化的 Spark 運行時，經常優於雲中的其他大數據 SQL 平臺。

Azure Databricks 是一項完全託管的服務，可提供強大的 ETL、分析和機器學習功能。與其他供應商不同，它是 Azure 上的第一方服務，可與其他 Azure 服務（例如事件中心和 Cosmos DB）無縫集成。

正如您對此類服務所期望的那樣，啟動可以自動擴展和自動終止的集群既快速又簡單——因此，一旦您的作業完成，您的集群將在指定的時間後關閉。這兩個功能使該服務具有成本效益，因為您僅在集群運行時根據集群中節點 (VM) 的數量和大小付費。有關計費的更多信息，請參見第二部分。如果您想使用第三部分中提供的筆記本運行演示，您可以預配 14 天的免費試用期，您只需為基礎 Azure VM 付費。在 Azure 中創建資源後，將為您預配一個 Databricks 工作區，它實質上存儲您的所有 Databricks 資產，例如筆記本和庫。即使沒有任何正在運行的集群，您仍然可以訪問工作區、查看筆記本、安排作業等，並且在啟動集群之前不會向您收費。值得注意的是，在流式傳輸場景或需要用於 BI 工具的專用分析集群的場景中，您需要一個專用集群，儘管它可以根據工作負載設置為自動擴展。

與 Azure Databricks 一起，在我看來真正開啟真正 ETL / 數據倉庫用例的兩個關鍵組件是 Spark Structured Streaming 和 Databricks Delta（現在稱為 Delta Lake）。通過這些改進，普通人現在可以嘗試在 Spark 中開發（批處理和流媒體）ETL 和分析管道。為什麼這樣？在結構化流之前，有使用 RDD 和 DStreams（基於 Java/Python 上相對低級操作）的 Spark Streaming，在 Databricks Delta 之前，並發讀/寫、DML 操作和性能優化是有限且複雜的。

Azure Databricks 上的結構化流式處理使用一組簡單的高級 API 提供可靠的、一次性的、容錯的流式處理平臺。您可以將傳入流視為無界表，它允許您處理遲到或無序的數據。更重要的是，通過稱為水印的功能，您可以加入流數據（與靜態或其他流數據）並指示引擎「等待」記錄加入多長時間。這與我們基於 RDBMS 的 ELT 流程的運行方式有很大不同，它會運行多個映射，但一次僅在一個更改集（CDC 表）上運行。這樣做是因為您不能依賴在同一（微批次）時間窗口中記錄的主從事件。

有人可能會問，為什麼 Spark 引擎不能簡單地無限期地等待這些遲到的記錄出現。嗯，它可以，但是這樣做需要保持無界狀態，換句話說，將密鑰存儲在內存中，沒有任何可以清除它們的閾值，這最終會耗盡所有可用內存並導致內存不足 (OOM)失敗。

因此，雖然處理遲到數據的能力在近實時 ETL 場景中可能非常有用，但它並非沒有限制和後果，因此需要定義仔細評估的水印閾值以限制狀態。至關重要的是，到達超過此閾值的數據將需要在批處理中進行處理。

更積極的一點是，使用 Spark 的結構化 API 的批處理和流之間的代碼更改很少，因此一旦您在流模式下開發了 ETL 管道，批處理運行的語法將需要最少的重新編碼。 （最終筆記本中提供了一個示例。）

現在將我們的注意力轉向 Databricks Delta，有一些「獨家」功能可以簡化和優化流（和批處理）ETL 場景。本質上，它是一個優化的 Spark 表，具有許多類似 SQL 的功能：

ACID 事務——多個作者可以同時修改一個數據集並查看一致的視圖。作者不影響讀者。

DELETES/UPDATES/UPSERTS — 編寫者可以修改數據集，而不會干擾讀取數據集的作業。合併操作也得到很好的支持。

統計信息、數據跳過和 ZORDER 集群——當跟蹤每個文件中的數據的統計信息時，讀取​速度提高 10-100 倍，允許 Delta 避免讀取不相關的信息。

使用 Delta，您可以將批處理和流數據寫入同一個表，其他筆記本和集群可以從同一個表中讀取並獲得一致的最新視圖。此外，Delta 可以通過將數據組織成可以高效讀取的大文件來提高數據訪問速度。這是通過將小文件合併為大文件來完成的。

所以本質上它是一個事務存儲層，專門設計用於利用 Apache Spark 和 Databricks 文件系統 (DBFS) 的強大功能。底層數據作為 Parquet 文件存儲在 DBFS 中，但 Delta 維護一個事務日誌，可有效跟蹤表的更改。您可以使用相同的熟悉的 Apache Spark SQL 批處理和流（結構化）API 讀取和寫入存儲在 Databricks Delta 中的數據。

那麼，Databricks Delta 可能是所有 ETL 挑戰的完美解決方案嗎？

雖然這兩種技術之間的差距似乎正在縮小，但仍然需要了解 Delta 和 RDBMS 之間的根本區別。它是文件而不是記錄，它是一種基於列和基於行的存儲格式，因此某些點操作（如合併或更新）（儘管可能）不太可能運行得那麼快，主要是由於缺乏真正的索引。在流場景中更是如此，因此如果您的工作負載依賴於以時間敏感的方式運行這些類型的操作，那麼您可能需要考慮替代方案，例如 Cosmos DB。希望通過自己運行第三部分中的演示，您可以評估這些注意事項。

數據框、數據集、轉換和惰性評估

如果您不熟悉 Spark 並且有 SQL 背景，我建議我們介紹一些您需要了解的「外國」概念：數據幀、轉換、動作和惰性求值。我不會詳細介紹任何細節，因此如果您喜歡睡前閱讀，我推薦由 Matei Zaharia 撰寫的「Spark：權威指南：大數據處理變得簡單」，他於 2009 年創立了 Spark 並與他人共同創立Databricks 和 Bill Chambers，他是 Databricks 的 PM。

數據幀和轉換的序列

數據幀和數據集都是分布式的、不可變的類似表格的數據結構，可以跨越數千臺計算機。因為它們是不可變的，所以我們需要對它們執行轉換，但將結果存儲在另一個數據幀中。轉換可以是任何形式，從將列轉換為不同類型、應用內置或自定義函數 (UDF) 來連接數據幀。因此，在實現您需要的輸出之前，通常會「連結」多個數據幀，每個數據幀都有自己的轉換。 Spark 將形成最佳執行計劃，但僅在您指定「操作」時執行它們 - 例如在筆記本中顯示計數，或寫入輸出接收器。因此就有了惰性求值的概念。

您可以將業務邏輯（在 R、Python、Scala 或 Java 中）表示為 SQL、DataFrames 或 Datasets 中的一組邏輯轉換，Spark 將透明地將該邏輯編譯為 RDD 並生成底層執行計劃。

首先，您可能只使用 Dataframes 而不是 Datasets，但是如果您想知道兩者之間的區別，那就是 Datasets 是強類型的，而 Dataframe 類型僅在運行時進行評估。

最後，Spark 支持 ANSI SQL 2003 標準的一個子集，因此您可以使用類似 SQL 的符號開發管道的許多部分，甚至可以根據需要在數據幀和 SQL 之間進行互操作。

雖然下面的演示鬆散地基於我之前提到的 POC，但出於保密目的，它已被更改和更改，尤其是數據集。我決定使用的場景基於經常引用的 Ad Tech 用例，但為簡單起見，我忽略了某些指標，例如點擊次數和轉化次數，這些指標已經很好地涵蓋了。

假設該業務屬於廣告行業，並監控某些網站上顯示的廣告量（印象數）。他們只對展示特定品牌的廣告感興趣。該企業對通常的點擊和轉化不感興趣。在這種情況下，廣告和印象作為來自第 3 方的 json 消息（可能是文件）的連續流/提要到達。廣告包含元數據，例如創建時間、唯一標識符、名稱以及它所屬的品牌。展示次數是廣告在何時以及在哪個網站上展示，包括會話和用戶信息。幸運的是，我們在兩者中都有一個廣告 ID 來連結這些，但是對於每次展示我們沒有任何類型的唯一鍵。

有一些靜態操作/參考源包含緩慢變化的數據：

包含正在監控的品牌列表的 SQL DB

運營團隊用來維護受監控域列表的 Web 應用程式。

為方便起見，假設這兩個數據集都已由第 3 方根據這些特定品牌和域進行了預過濾。廣告是參考數據的重要來源，運營應用程式需要能夠輕鬆訪問各個廣告。

我們需要生成的源表集和目標星型模式如下：

從源模式到星型模式

請注意，為簡潔起見，我排除了關鍵的時間維度，您還會注意到我包含了一個批處理 ETL 場景，以展示我們如何實現類型 II 緩慢變化的維度要求。

給定場景，我們將實現以下架構：

流媒體源部分可能看起來過於複雜，因此值得稍微解釋一下。為了生成數據流，我們將使用一個實用程序為廣告和展示生成 json 數據。該實用程序支持定義您選擇的架構，但遺憾的是僅支持將數據發送到 IoT 中心。我們需要使用流分析來使用流並根據文件內容將其路由到事件中心或 Cosmos DB。

現在查看商店部分，您可能想知道為什麼或如何向 Cosmos DB 發送流。在上面的場景描述中，提到廣告需要可由操作應用程式訪問，需要從中快速訪問單個廣告。這非常適合 Cosmos DB，它提供可擴展性和個位數毫秒的延遲。流分析可以輕鬆地將流發送到 Cosmos DB，我們可以使用出色的更改提要功能將其作為流再次讀回。流分析會將印象路由到事件中心，Databricks 將讀取這兩個流，運行 ETL 管道並將結果流式傳輸到 Azure SQL 數據倉庫。還將批量運行各種管道，以提供更全面的場景集。

為了更真實的演示，我想展示我們如何獲取兩個流，加入它們，以及加入其他緩慢變化的參考數據。事實上，Databricks（更具體地說是 Spark）的優勢之一是您可以相對輕鬆地從許多不同的數據源和數據格式中讀取數據，執行連接和轉換，然後將輸出寫入多個目標。這就是為什麼它已成為數據湖分析的流行選擇。

接下來，在本博客的第 2 部分，我們將構建上述架構，但如果您只想運行管道，則將在第 III 部分中描述一個選項，只需最少的設置即可實現這一點。