Synapse POC 劇本：Azure Synapse Analytics 中使用 Apache Spark 集區進行巨量資料分析
本文提供適用于 Apache Spark 集區之有效 Azure Synapse Analytics 概念證明 （POC） 專案的準備和執行高階方法。
注意
本文是 Azure Synapse 概念劇本 系列文章的一部分 。 如需系列的概觀，請參閱 Azure Synapse 概念證明劇本 。
準備 POC
POC 專案可協助您在雲端式平臺上實作巨量資料和進階分析環境的明智商務決策，以利用 Azure Synapse 中的 Apache Spark 集區。
POC 專案將識別雲端式巨量資料和進階分析平臺必須支援的主要目標和業務驅策因素。 它會測試關鍵計量，並證明關鍵行為，這對資料工程、機器學習模型建置和定型需求的成功至關重要。 POC 並非設計成要部署到生產環境。 相反地，它是一個短期專案，著重于關鍵問題，而且其結果可以捨棄。
開始規劃 Spark POC 專案之前：
- 識別貴組織對於將資料移至雲端的任何限制或指導方針。
- 識別巨量資料和進階分析平臺專案的主管或商務贊助者。 保護其移轉至雲端的支援。
- 識別技術專家和商務使用者的可用性，以在 POC 執行期間支援您。
開始準備 POC 專案之前，建議您先閱讀 Apache Spark 檔 。
提示
如果您不熟悉 Spark 集區，建議您使用 Azure Synapse Apache Spark 集 區執行資料工程學習路徑。
現在您應該已判斷沒有立即封鎖程式，然後您就可以開始準備 POC。 如果您不熟悉 Azure Synapse Analytics 中的 Apache Spark 集區，您可以在這裡參閱 此檔 ，以取得 Spark 架構的概觀，並瞭解它在 Azure Synapse 中的運作方式。
瞭解這些重要概念：
- Apache Spark 及其分散式架構。
- Spark 概念，例如彈性分散式資料集 （RDD） 和分割區 （記憶體內部和實體）。
- Azure Synapse 工作區、不同的計算引擎、管線和監視。
- 分隔 Spark 集區中的計算和儲存體。
- Azure Synapse 中的驗證和授權。
- 與 Azure Synapse 專用 SQL 集區、Azure Cosmos DB 等整合的原生連接器。
Azure Synapse 會將計算資源與儲存體分離，以便更妥善地管理資料處理需求和控制成本。 Spark 集區的無伺服器架構可讓您啟動和關閉，以及成長和縮小 Spark 叢集，與儲存體無關。 您可以完全暫停或設定自動暫停 Spark 叢集。 如此一來，您才會在使用時支付計算費用。 未使用時，您只需支付儲存體費用。 您可以相應增加 Spark 叢集，以處理大量資料處理需求或大量負載，然後在較不密集的處理時間相應減少 Spark 叢集（或完全關閉）。 您可以有效地調整和暫停叢集，以降低成本。 您的 Spark POC 測試應包含不同規模的資料擷取和資料處理，以比較不同規模的價格和效能。 如需詳細資訊，請參閱 自動調整 Azure Synapse Analytics Apache Spark 集區 。
請務必瞭解不同 Spark API 集合之間的差異，以便決定最適合您案例的內容。 您可以選擇提供更佳效能或便於使用的技能，並利用小組現有的技能集。 如需詳細資訊，請參閱 三個 Apache Spark API 的故事：RDD、DataFrame 和資料集 。
資料與檔案分割在 Spark 中的運作方式稍有不同。 瞭解差異可協助您優化效能。 如需詳細資訊，請參閱 Apache Spark 檔： 資料分割探索 和資料 分割組態選項 。
設定目標
成功的 POC 專案需要規劃。 首先，找出您為何要執行 POC 來充分瞭解真正的動機。 動機可能包括現代化、節省成本、改善效能或整合式體驗。 請務必記錄您 POC 的明確目標，以及定義其成功準則。 詢問自己：
- 您要做為 POC 的輸出是什麼？
- 這些輸出會怎麼做？
- 神秘會使用輸出嗎？
- 哪些專案會定義成功的 POC？
請記住，POC 應該是簡短而專注的努力，以快速證明一組有限的概念和功能。 這些概念和功能應該代表整體工作負載。 如果您有很長的專案清單要證明，您可能想要規劃多個 POC。 在此情況下，請定義 POC 之間的閘道，以判斷您是否需要繼續進行下一個閘道。 假設在 Azure Synapse 中使用 Spark 集區和筆記本的不同專業角色，您可以選擇執行多個 POC。 例如，一個 POC 可以專注于資料工程角色的需求，例如擷取和處理。 另一個 POC 可以專注于機器學習 （ML） 模型開發。
當您考慮 POC 目標時，請問自己下列問題，以協助您塑造目標：
- 您是否要從現有的巨量資料和進階分析平臺（內部部署或雲端）進行移轉？
- 您要移轉，但想要對現有的擷取和資料處理進行盡可能少的變更嗎？ 例如，Spark 至 Spark 移轉，或將 Hadoop/Hive 移轉至 Spark。
- 您要移轉，但想要一路上進行一些廣泛的改進嗎？ 例如，將 MapReduce 作業重新撰寫為 Spark 作業，或將舊版 RDD 型程式碼轉換為 DataFrame/資料集型程式碼。
- 您要建置全新的巨量資料和進階分析平臺 （綠地專案）嗎？
- 您目前的痛點為何？ 例如，延展性、效能或彈性。
- 您需要支援哪些新的商務需求？
- 您需要滿足哪些 SLA？
- 工作負載為何？ 例如，ETL、批次處理、串流處理、機器學習模型定型、分析、報告查詢或互動式查詢？
- 擁有專案的使用者有哪些技能（是否應實作 POC） ？ 例如，PySpark 與 Scala 技能、筆記本與 IDE 體驗。
以下是 POC 目標設定的一些範例：
- 我們為什麼要做 POC？
- 我們需要知道巨量資料工作負載的資料擷取和處理效能將符合新的 SLA。
- 我們需要知道是否可能進行近乎即時的串流處理，以及其可支援的輸送量。 （它會支援我們的業務需求嗎？
- 我們需要知道我們現有的資料擷取和轉換程式是否適合，以及需要進行改善的位置。
- 我們需要知道是否可以縮短資料整合執行時間，以及縮短多少。
- 我們需要知道資料科學家是否可以建置和定型機器學習模型，並在 Spark 集區中視需要運用 AI/ML 程式庫。
- 移至雲端式 Synapse Analytics 是否符合我們的成本目標？
- 在此 POC 結束時：
- 我們將擁有資料，以判斷批次和即時串流是否符合資料處理效能需求。
- 我們將測試支援我們使用案例的所有不同資料類型（結構化、半和非結構化）的擷取和處理。
- 我們將測試一些現有的複雜資料處理，並識別需要完成的工作，以將我們的資料整合組合遷移至新的環境。
- 我們將測試資料擷取和處理，並將有資料點來估計初始移轉和歷史資料負載所需的工作，以及估計移轉資料擷取所需的工作（Azure Data Factory （ADF）、Distcp、Databox 或其他專案。
- 我們將測試資料擷取和處理，並可以判斷是否可以符合 ETL/ELT 處理需求。
- 我們將獲得深入解析，以更進一些方式預估完成實作專案所需的工作。
- 我們將測試縮放比例和調整選項，並讓資料點更妥善地設定平臺，以取得更佳的效能設定。
- 我們將有可能需要更多測試的專案清單。
規劃專案
使用您的目標來識別特定測試，並提供您識別的輸出。 請務必確定您至少有一個測試可支援每個目標和預期的輸出。 此外，請識別特定的資料擷取、批次或串流處理，以及將執行的所有其他進程，以便識別非常特定的資料集和程式碼基底。 這個特定的資料集和程式碼基底會定義 POC 的範圍。
以下是規劃中所需特定層級的範例：
- 目標 A： 我們需要知道我們對於資料擷取和處理批次資料的需求是否符合我們定義的 SLA。
- 輸出 A： 我們將有資料來判斷批次資料擷取和處理是否符合資料處理需求和 SLA。
- 測試 A1： 處理查詢 A、B 和 C 會識別為良好的效能測試，因為它們通常是由資料工程小組執行。 此外，它們也代表整體資料處理需求。
- 測試 A2： 處理查詢 X、Y 和 Z 會識別為良好的效能測試，因為它們包含近乎即時的串流處理需求。 此外，它們代表整體事件型資料流程處理需求。
- 測試 A3： 比較 Spark 叢集不同規模的這些查詢效能（不同數目的背景工作節點、背景工作節點的大小，例如小型、中型和大型執行程式），以及從現有系統取得的基準測試。 請記住減少傳回 的規律;新增更多資源（無論是透過相應增加或相應放大），都有助於達到平行處理原則，但是每個案例都有一定的限制，可達成平行處理原則。 探勘測試中每個識別使用案例的最佳組態。
- 目標 B： 我們需要知道資料科學家是否可以在此平臺上建置和定型機器學習模型。
- 輸出 B： 我們將針對 Spark 集區或 SQL 集區中的資料進行定型，以測試部分機器學習模型，並利用不同的機器學習程式庫。 這些測試有助於判斷哪些機器學習模型可以遷移至新環境
- 測試 B1： 將會測試特定的機器學習模型。
- 測試 B2： Spark 隨附的測試基底機器學習程式庫（Spark MLLib）以及可在 Spark 上安裝的額外程式庫（例如 scikit-learn）以符合需求。
- 目標 C： 我們將測試資料擷取，並將資料點指向：
- 預估初始歷程記錄資料移轉至 Data Lake 和/或 Spark 集區的工作。
- 規劃移轉歷程記錄資料的方法。
- 輸出 C： 我們將測試並判斷環境中可達成的資料擷取率，並判斷我們的資料擷取速率是否足以在可用的時間範圍中移轉歷程記錄資料。
- 測試 C1： 測試歷史資料移轉的不同方法。 如需詳細資訊，請參閱 將資料傳送至 Azure 或從 Azure 傳輸資料。
- 測試 C2： 識別 ExpressRoute 的已配置頻寬，以及基礎結構小組是否有任何節流設定。 如需詳細資訊，請參閱 什麼是 Azure ExpressRoute？（頻寬選項）
- 測試 C3： 線上和離線資料移轉的測試資料傳輸速率。 如需詳細資訊，請參閱 複製活動效能和延展性指南 。
- 測試 C4： 使用 ADF、Polybase 或 COPY 命令，測試從 Data Lake 到 SQL 集區的資料傳輸。 如需詳細資訊，請參閱 Azure Synapse Analytics 中專用 SQL 集區的資料載入策略。
- 目標 D： 我們將測試累加式資料載入的資料擷取速率，並將資料點估計資料擷取和處理時間範圍至資料湖和/或專用 SQL 集區。
- 輸出 D： 我們將測試資料擷取速率，並判斷資料擷取和處理需求是否符合已識別的方法。
- 測試 D1： 測試每日更新資料擷取和處理。
- 測試 D2： 從 Spark 集區測試已處理的資料載入至專用 SQL 集區資料表。 如需詳細資訊，請參閱 適用于 Apache Spark 的 Azure Synapse 專用 SQL 集區連線或。
- 測試 D3： 在執行使用者查詢時，同時執行每日更新載入程式。
請務必藉由新增多個測試案例來精簡測試。 Azure Synapse 可讓您輕鬆地測試不同的規模（不同數目的背景工作節點、小型、中型和大型等背景工作節點的大小），以比較效能和行為。
以下是一些測試案例：
- Spark 集區測試 A： 我們將跨多個節點類型執行資料處理（小型、中型和大型），以及不同的背景工作節點數目。
- Spark 集區測試 B： 我們將使用 連接器，從 Spark 集區載入/擷取已處理的資料至專用 SQL 集區 。
- Spark 集區測試 C： 我們將透過 Azure Synapse Link，從 Spark 集區載入/擷取已處理的資料。
評估 POC 資料集
使用您識別的特定測試，選取支援測試的資料集。 請花點時間檢閱此資料集。 您應該確認資料集會充分代表您未來在內容、複雜度和規模方面的處理。 請勿使用太小（小於 1TB）的資料集，因為它不會提供代表性的效能。 相反地，請勿使用太大的資料集，因為 POC 不應該變成完整的資料移轉。 請務必從現有的系統取得適當的基準測試，讓您可以使用它們進行效能比較。
重要
在將資料移至雲端之前，請務必先與企業主檢查是否有任何封鎖程式。 識別任何安全性或隱私權考慮，或任何在將資料移至雲端之前，應該完成的資料混淆需求。
建立高階架構
根據您建議的未來狀態架構的高階架構，識別構成 POC 一部分的元件。 您的高階未來狀態架構可能包含許多資料來源、許多資料取用者、巨量資料元件，以及機器學習和人工智慧 （AI） 資料取用者。 您的 POC 架構應該特別識別將成為 POC 一部分的元件。 重要的是，它應該識別不會構成 POC 測試一部分的任何元件。
如果您已經使用 Azure，請識別您在 POC 期間可以使用的任何資源（Microsoft Entra ID、ExpressRoute 和其他資源）。 同時識別組織所使用的 Azure 區域。 現在很能識別 ExpressRoute 連線的輸送量，並與其他商務使用者檢查您的 POC 可能會耗用部分輸送量，而不會對生產系統造成負面影響。
如需詳細資訊，請參閱 巨量資料架構 。
識別 POC 資源
具體識別支援 POC 所需的技術資源和時間承諾。 您的 POC 將需要：
- 負責監督需求和結果的商務代表。
- 應用程式資料專家，為 POC 提供資料來源，並提供現有程式與邏輯的知識。
- Apache Spark 和 Spark 集區專家。
- 專家顧問，可將 POC 測試優化。
- POC 專案的特定元件所需的資源，但不一定需要在 POC 期間內使用。 這些資源可能包括網路系統管理員、Azure 系統管理員、Active Directory 系統管理員、Azure 入口網站系統管理員等。
- 請確定已布建所有必要的 Azure 服務資源，並授與必要的存取層級，包括儲存體帳戶的存取權。
- 請確定您有需要資料存取權限的帳戶，以從 POC 範圍中的所有資料來源擷取資料。
提示
建議您聘請專家顧問來協助處理您的 POC。 Microsoft 的合作夥伴社群 擁有專家顧問的全球可用性，可協助您評估、評估或實作 Azure Synapse。
設定時程表
檢閱您的 POC 規劃詳細資料和商務需求，以識別 POC 的時間範圍。 對完成 POC 目標所需的時間進行實際估計。 完成 POC 的時間將受到 POC 資料集的大小、測試的數目和複雜度，以及要測試的介面數目所影響。 如果您估計 POC 的執行時間超過四周，請考慮減少 POC 範圍，以專注于最高的優先順序目標。 在繼續之前，請務必從所有潛在客戶資源和贊助者取得核准和承諾。
將 POC 付諸實施
建議您使用任何生產專案的專業領域和嚴謹性來執行 POC 專案。 根據計畫執行專案並管理變更要求程式，以防止 POC 範圍的不受控制成長。
以下是高階工作的一些範例：
建立 Synapse 工作區 、Spark 集區和專用 SQL 集區、儲存體帳戶，以及 POC 方案中識別的所有 Azure 資源。
載入 POC 資料集：
- 從來源擷取或在 Azure 中建立範例資料，在 Azure 中提供資料。 如需詳細資訊，請參閱：
- 測試 Spark 集區和專用 SQL 集區的專用連線器。
將現有的程式碼移轉至 Spark 集區：
- 如果您要從 Spark 移轉，您的移轉工作可能很簡單，因為 Spark 集區會利用開放原始碼 Spark 散發套件。 不過，如果您在核心 Spark 功能上使用廠商特定功能，則必須正確地將這些功能對應至 Spark 集區功能。
- 如果您要從非 Spark 系統移轉，您的移轉工作會根據所涉及的複雜度而有所不同。
執行測試：
- 許多測試可以跨多個 Spark 集區叢集平行執行。
- 以消費性且容易理解的格式記錄您的結果。
監視以進行疑難排解和效能。 如需詳細資訊，請參閱
開啟 Spark 記錄伺服器的 [診斷 ] 索引標籤，以 監視資料扭曲、時間扭曲和執行程式使用量百分比。
解譯 POC 結果
當您完成所有 POC 測試時，會評估結果。 首先，評估 POC 目標是否符合，並收集所需的輸出。 判斷是否需要進行更多測試，或需要解決任何問題。