Synapse POC 劇本：在 Azure Synapse Analytics 中使用無伺服器 SQL 集區進行資料湖探索
本文提供用於準備和執行適用于無伺服器 SQL 集區之有效 Azure Synapse Analytics 概念證明 （POC） 專案的高層級方法。
注意
本文是 Azure Synapse 概念劇本 系列文章的一部分 。 如需系列的概觀，請參閱 Azure Synapse 概念證明劇本 。
準備 POC
POC 專案可協助您在雲端式平臺上實作巨量資料和進階分析環境的明智商務決策，以利用 Azure Synapse 中的無伺服器 SQL 集區。 如果您需要探索或從 Data Lake 中的資料取得深入解析，或優化現有的資料轉換管線，您可以使用無伺服器 SQL 集區來獲益。 它適用于下列案例：
- 基本探索和探索： 快速推斷儲存在 Data Lake 中各種格式的資料（Parquet、CSV、JSON），以便規劃如何從中解除鎖定見解。
- 邏輯資料倉儲： 在未經處理或不同的資料上產生關聯式抽象概念，而不需要重新放置或轉換資料，提供資料的一律最新檢視。
- 資料轉換： 使用 T-SQL 執行簡單、可調整且高效能的資料湖查詢。 您可以將查詢結果饋送至商業智慧 （BI） 工具，或將它們載入關係資料庫。 目標系統可以包含 Azure Synapse 專用 SQL 集區或 Azure SQL 資料庫。
不同的專業角色可以受益于無伺服器 SQL 集區：
- 資料工程師 可以使用無伺服器 SQL 集區來探索資料湖、轉換和準備資料，並簡化其資料轉換管線。
- 資料科學家 可以使用 OPENROWSET T-SQL 函式及其自動架構推斷，快速推斷資料湖 中儲存的資料內容和結構。
- 資料分析師 可以在慣用的查詢工具中寫入 T-SQL 查詢，以連線到無伺服器 SQL 集區。 他們可以探索由資料科學家或資料工程師所建立的 Spark 外部資料表中的資料。
- BI 專業人員 可以快速建立連線至 Data Lake 或 Spark 資料表的 Power BI 報表。
無伺服器 SQL 集區 POC 專案會識別無伺服器 SQL 集區設計來支援的主要目標和業務驅策因素。 它也會測試關鍵功能，並收集計量以支援您的實作決策。 POC 並非設計成要部署到生產環境。 相反地，它是一個短期專案，著重于關鍵問題，而且其結果可以捨棄。
開始規劃無伺服器 SQL 集區 POC 專案之前：
- 識別貴組織對於將資料移至雲端的任何限制或指導方針。
- 識別巨量資料和進階分析平臺專案的主管或商務贊助者。 保護其移轉至雲端的支援。
- 識別技術專家和商務使用者的可用性，以在 POC 執行期間支援您。
開始準備 POC 專案之前，建議您先閱讀 無伺服器 SQL 集區檔 。
提示
如果您不熟悉無伺服器 SQL 集區，建議您使用 Azure Synapse 無伺服器 SQL 集 區學習路徑來建 置資料分析解決方案。
設定目標
成功的 POC 專案需要規劃。 首先，找出您為何要執行 POC 來充分瞭解真正的動機。 動機可能包括現代化、節省成本、改善效能或整合式體驗。 請務必記錄您 POC 的明確目標，以及定義其成功準則。 詢問自己：
- 您要做為 POC 的輸出是什麼？
- 這些輸出會怎麼做？
- 神秘會使用輸出嗎？
- 哪些專案會定義成功的 POC？
請記住，POC 應該是簡短而專注的努力，以快速證明一組有限的概念和功能。 這些概念和功能應該代表整體工作負載。 如果您有很長的專案清單要證明，您可能想要規劃多個 POC。 在此情況下，請定義 POC 之間的閘道，以判斷您是否需要繼續進行下一個閘道。 假設您可以使用無伺服器 SQL 集區的不同專業角色（以及無伺服器 SQL 集區支援的不同案例），您可以選擇執行多個 POC。 例如，一個 POC 可以專注于資料科學家角色的需求，例如以不同格式探索和探索資料。 另一個可能著重于資料工程角色的需求，例如資料轉換和建立邏輯資料倉儲。
當您考慮 POC 目標時，請問自己下列問題，以協助您塑造目標：
- 您是否要從現有的巨量資料和進階分析平臺（內部部署或雲端）進行移轉？
- 您要移轉，但想要對現有的擷取和資料處理進行盡可能少的變更嗎？
- 您要移轉，但想要一路上進行一些廣泛的改進嗎？
- 您要建置全新的巨量資料和進階分析平臺 （綠地專案）嗎？
- 您目前的痛點為何？ 例如，延展性、效能或彈性。
- 您需要支援哪些新的商務需求？
- 您需要滿足哪些 SLA？
- 工作負載為何？ 例如，對不同資料格式的資料探索、基本探索、邏輯資料倉儲、資料準備和/或轉換、T-SQL 互動式分析、Spark 資料表的 T-SQL 查詢，或報告資料湖上的查詢。
- 擁有專案的使用者有哪些技能（是否應實作 POC） ？
以下是 POC 目標設定的一些範例：
- 我們為什麼要做 POC？
- 我們需要知道我們是否可以使用無伺服器 SQL 集區來探索我們儲存的所有原始檔案格式。
- 我們需要知道我們的資料工程師是否可以快速評估新的資料摘要。
- 我們需要知道使用無伺服器 SQL 集區的資料湖查詢效能是否符合我們的資料探索需求。
- 我們需要知道無伺服器 SQL 集區是否是一些視覺效果和報告需求的好選擇。
- 我們需要知道無伺服器 SQL 集區是否為一些資料擷取和處理需求的絕佳選擇。
- 我們需要知道我們移至 Azure Synapse 是否會符合我們的預算。
- 在此 PoC 結束時：
- 我們將有資料來識別適合無伺服器 SQL 集區的資料轉換。
- 我們將有資料來識別資料視覺效果期間最能使用無伺服器 SQL 集區。
- 我們將讓資料知道資料工程師和資料科學家可以採用新平臺的輕鬆程度。
- 我們將取得深入解析，以更妥善地估計完成實作或移轉專案所需的工作。
- 我們將有可能需要更多測試的專案清單。
- 如果我們擁有所需的資料，且已完成已識別的測試，以判斷無伺服器 SQL 集區如何支援我們的雲端式巨量資料和進階分析平臺，我們的 POC 將會成功。
- 我們將決定是否可以移至下一個階段，或是否需要更多 POC 測試才能完成我們的決定。
- 我們將能夠做出特定資料點所支援的良好商務決策。
規劃專案
使用您的目標來識別特定測試，並提供您識別的輸出。 請務必確定您至少有一個測試可支援每個目標和預期的輸出。 此外，請識別特定的資料探索和分析工作、特定轉換，以及您想要測試的特定現有處理。 識別您可以使用的特定資料集和程式碼基底。
以下是規劃中所需特定層級的範例：
- 目標： 我們需要知道資料工程師是否可以在所需的 SLA 內，達到名為「每日批次原始檔案驗證」的現有 ETL 處理常式的對等處理。
- 輸出： 我們將有資料來判斷是否可以使用 T-SQL 查詢，在必要的 SLA 內執行「每日批次原始檔案驗證」ETL 程式。
- 測試： 驗證查詢 A、B 和 C 是由資料工程識別，它們代表整體資料處理需求。 比較這些查詢的效能與從現有系統取得的基準測試。
評估 POC 資料集
使用您識別的特定測試，選取支援測試的資料集。 請花點時間檢閱此資料集。 您應該確認資料集會充分代表您未來在內容、複雜度和規模方面的處理。 請勿使用太小的資料集，因為它不會提供代表性的效能。 相反地，請勿使用太大的資料集，因為 POC 不應該變成完整的資料移轉。 請務必從現有的系統取得適當的基準測試，讓您可以使用它們進行效能比較。
重要
在將資料移至雲端之前，請務必先與企業主檢查是否有任何封鎖程式。 識別任何安全性或隱私權考慮，或任何在將資料移至雲端之前，應該完成的資料混淆需求。
建立高階架構
根據您建議的未來狀態架構的高階架構，識別構成 POC 一部分的元件。 您的高階未來狀態架構可能包含許多資料來源、許多資料取用者、巨量資料元件，以及機器學習和人工智慧 （AI） 資料取用者。 您的 POC 架構應該特別識別將成為 POC 一部分的元件。 重要的是，它應該識別不會構成 POC 測試一部分的任何元件。
如果您已經使用 Azure，請識別您在 POC 期間可以使用的任何資源（Microsoft Entra ID、ExpressRoute 和其他資源）。 同時識別組織所使用的 Azure 區域。 現在很能識別 ExpressRoute 連線的輸送量，並與其他商務使用者檢查您的 POC 可能會耗用部分輸送量，而不會對生產系統造成負面影響。
識別 POC 資源
具體識別支援 POC 所需的技術資源和時間承諾。 您的 POC 將需要：
- 負責監督需求和結果的商務代表。
- 應用程式資料專家，為 POC 提供資料來源，並提供現有程式與邏輯的知識。
- 無伺服器 SQL 集區專家。
- 專家顧問，可將 POC 測試優化。
- POC 專案的特定元件所需的資源，但不一定需要在 POC 期間內使用。 這些資源可能包括網路系統管理員、Azure 系統管理員、Active Directory 系統管理員、Azure 入口網站系統管理員等。
- 請確定已布建所有必要的 Azure 服務資源，並授與必要的存取層級，包括儲存體帳戶的存取權。
- 請確定您有需要資料存取權限的帳戶，以從 POC 範圍中的所有資料來源擷取資料。
提示
建議您聘請專家顧問來協助處理您的 POC。 Microsoft 的合作夥伴社群 擁有專家顧問的全球可用性，可協助您評估、評估或實作 Azure Synapse。
設定時程表
檢閱您的 POC 規劃詳細資料和商務需求，以識別 POC 的時間範圍。 對完成 POC 目標所需的時間進行實際估計。 完成 POC 的時間將受到 POC 資料集的大小、測試的數目和複雜度，以及要測試的介面數目所影響。 如果您估計 POC 的執行時間超過四周，請考慮減少 POC 範圍，以專注于最高的優先順序目標。 在繼續之前，請務必從所有潛在客戶資源和贊助者取得核准和承諾。
將 POC 付諸實施
建議您使用任何生產專案的專業領域和嚴謹性來執行 POC 專案。 根據計畫執行專案並管理變更要求程式，以防止 POC 範圍的不受控制成長。
以下是高階工作的一些範例：
- 建立 Synapse 工作區 、儲存體帳戶，以及 POC 方案中識別的 Azure 資源。
- 根據您的需求設定 網路和安全性 。
- 授與 POC 小組成員的適當存取權。 請參閱 這篇文章 ，以瞭解直接從 Azure 儲存體 存取檔案的許可權。
- 載入 POC 資料集。
- 實作和設定測試和/或將現有的程式碼移轉至無伺服器 SQL 集區腳本和檢視。
- 執行測試：
- 許多測試可以平行執行。
- 以消費性且容易理解的格式記錄您的結果。
- 監視以進行疑難排解和效能。
- 評估您的結果並呈現結果。
- 請與技術專案關係人和業務合作，規劃專案的下一個階段。 下一個階段可能是後續 POC 或生產實作。
解譯 POC 結果
當您完成所有 POC 測試時，會評估結果。 首先，評估 POC 目標是否符合，並收集所需的輸出。 判斷是否需要進行更多測試，或需要解決任何問題。