Synapse POC 劇本：Azure Synapse Analytics 中使用專用 SQL 集區的資料倉儲
本文提供用於準備和執行專用 SQL 集區之有效 Azure Synapse Analytics 概念證明 （POC） 專案的高層級方法。
注意
本文是 Azure Synapse 概念劇本 系列文章的一部分 。 如需系列的概觀，請參閱 Azure Synapse 概念證明劇本 。
提示
如果您不熟悉專用 SQL 集區，建議您使用 Azure Synapse Analytics 學習路徑來使用 資料倉儲。
準備 POC
在決定 Azure Synapse POC 目標之前，建議您先閱讀 Azure Synapse SQL 架構 一文，以熟悉專用 SQL 集區如何分隔計算和儲存體，以提供領先業界的效能。
識別贊助商和潛在封鎖程式
一旦您熟悉 Azure Synapse，就可以確定您的 POC 具有必要的支援，而且不會遇到任何障礙。 您應該：
- 識別貴組織在雲端中移動資料，以及將資料儲存至雲端的任何限制或原則。
- 識別雲端式資料倉儲專案的主管和商務贊助。
- 確認您的工作負載適用于 Azure Synapse。 如需詳細資訊，請參閱 Azure Synapse Analytics 中的專用 SQL 集區架構。
設定時程表
POC 是具有特定、可測量目標和定義成功之計量的範圍限定時間練習。 在理想情況下，在商務現實中應該有一些基礎，讓結果有意義。
POC 在排定時間 時 有最佳結果。 Timeboxing 會將固定和最大時間單位配置給活動。 在我們的經驗中，兩周的時間足以完成工作，而不需要太多使用案例或複雜的測試矩陣的負擔。 在此固定時間週期內運作，建議您遵循此時程表：
- 資料載入： 三天以下
- 查詢： 五天以下
- 增值測試： 兩天以下
以下是一些提示：
- 請實際估計您完成計畫中的工作所需的時間。
- 辨識完成 POC 的時間與資料集大小、資料庫物件數目（資料表、檢視表和預存程式）、資料庫物件的複雜度，以及您將測試的介面數目有關。
- 如果您估計 POC 的執行時間超過四周，請考慮減少範圍，只專注于最重要的目標。
- 在開始 POC 之前，先取得時程表的所有潛在客戶資源和贊助者的支援。
一旦您判斷沒有任何立即的障礙，而且您已設定時程表，您就可以設定高階架構的範圍。
建立高階範圍架構
高層級未來的架構可能包含許多資料來源和資料取用者、巨量資料元件，以及機器學習和 AI 資料取用者。 若要讓您的 POC 目標保持可達成（且在您設定時程表的範圍內），請決定哪些元件會構成 POC 的一部分，以及將排除哪些元件。
此外，如果您已經使用 Azure，請識別下列各項：
- 您可以在 POC 期間使用的任何現有 Azure 資源。 例如，資源可以包含 Microsoft Entra ID 或 Azure ExpressRoute。
- 貴組織偏好的 Azure 區域。
- 您可以用於非生產 POC 工作的訂用帳戶。
- 您與 Azure 的網路連線輸送量。
重要
請務必檢查您的 POC 可以取用其中一些輸送量，而不會對生產解決方案產生負面影響。
套用移轉選項
如果您要從舊版資料倉儲系統移轉至 Azure Synapse，以下是需要考慮的一些問題：
- 您要移轉並想要對現有擷取、轉換和載入 （ETL） 進程和資料倉儲耗用量進行最少的變更嗎？
- 您要移轉，但想要一路上進行一些廣泛的改進嗎？
- 您要建置全新的資料分析環境（有時稱為 綠地專案 ）嗎？
接下來，您需要考慮您的痛點。
識別目前的痛點
您的 POC 應該包含使用案例，以證明解決您目前痛點的潛在解決方案。 要考慮的一些問題如下：
- 您預期 Azure Synapse 會填滿您目前實作中的哪些差距？
- 您需要哪些新的商務需求才能支援？
- 您需要符合哪些服務等級協定（SLA？
- 工作負載為何（例如 ETL、批次查詢、分析、報告查詢或互動式查詢）？
接下來，您必須設定 POC 成功準則。
設定 POC 成功準則
識別您執行 POC 的原因，並務必定義明確的目標。 您也必須知道您想要的 POC 輸出，以及您打算使用哪些輸出。
請記住，POC 應該是簡短且專注的努力，以快速證明或測試一組有限的概念。 如果您有很長的專案清單要證明，您可能會想要將它們深入探索到多個 POC。 POC 之間可以有大門，因此您可以判斷是否繼續進行下一個 POC。
以下是一些 POC 目標範例：
- 我們需要知道，我們大型複雜報告查詢的查詢效能將會符合新的 SLA。
- 我們需要知道互動式使用者的查詢效能。
- 我們需要知道我們現有的 ETL 程式是否適合，以及需要進行改進的地方。
- 我們需要知道是否可以縮短 ETL 執行時間，以及縮短多少。
- 我們需要知道 Synapse Analytics 具有足夠的安全性功能，以充分保護我們的資料。
接下來，您必須建立測試計劃。
建立測試計劃
使用您的目標，找出要執行的特定測試，以支援這些目標，並提供您識別的輸出。 請務必確定每個目標至少有一個測試，以及預期的輸出。 識別您將執行的特定查詢、報表、ETL 和其他程式，以提供可量化的結果。
藉由新增多個測試案例來厘清發生的任何資料表結構問題，以精簡您的測試。
良好的規劃通常會定義有效的 POC 執行。 請確定所有專案關係人都同意一個書面測試計劃，將每個 POC 目標與一組明確陳述的測試案例和成功度量聯繫起來。
大部分的測試計劃都圍繞效能和預期的使用者體驗。 以下是測試計劃的範例。 請務必自訂測試計劃，以符合您的商務需求。 清楚定義您正在測試的內容，將會在此程式中稍後支付股息。
| 目標 | Test | 預期的結果 |
|---|---|---|
| 我們需要知道，我們大型複雜報告查詢的查詢效能將會符合新的 SLA | - 複雜查詢的循序測試 - 針對所述 SLA 的複雜查詢並行測試 |
- 查詢 A、B 和 C 分別以 10、13 和 21 秒完成 - 在 10 個並行使用者中，查詢 A、B 和 C 平均完成 11、15 和 23 秒 |
| 我們需要知道互動式使用者的查詢效能 | - 在預期的並行層級為 50 位使用者，對所選查詢的並行測試。 - 使用結果集快取執行上述查詢 |
- 在 50 位並行使用者時，平均執行時間預期在 10 秒以內，且沒有結果集快取 - 在 50 個並行使用者時，平均執行時間預期在結果集快取下 5 秒以內 |
| 我們需要知道現有的 ETL 進程是否可以在 SLA 內執行 | - 執行一或兩個 ETL 程式以模擬生產負載 | - 以累加方式載入核心事實資料表必須在不到 20 分鐘內完成（包括預備和資料清理） - 維度處理需要不到五分鐘的時間 |
| 我們需要知道資料倉儲具有足夠的安全性功能來保護我們的資料 | - 檢閱並啟用 網路安全性 （VNet 和私人端點）、 存取控制 （資料列層級安全性、動態資料遮罩） | - 證明資料永遠不會離開我們的租使用者。 - 確保客戶內容很容易受到保護 |
接下來，您必須識別並驗證 POC 資料集。
識別及驗證 POC 資料集
使用範圍測試，您現在可以識別在 Azure Synapse 中執行這些測試所需的資料集。 請考慮下列事項來檢閱您的資料集：
- 確認資料集在內容、複雜度和規模方面充分代表您的生產資料集。
- 請勿使用太小（小於 1TB）的資料集，因為您可能無法達到代表性的效能。
- 請勿使用太大的資料集，因為 POC 不適合完成完整資料移轉。
- 識別每個資料表的 散發模式 、 索引選項 和 資料分割 。 如果有關于散發、編制索引或資料分割的任何問題，請將測試新增至您的 POC 以回答。 請記住，您可能想要測試一些資料表的多個散發選項或索引選項。
- 請洽詢企業主是否有任何封鎖程式，以將 POC 資料集移至雲端。
- 識別任何安全性或隱私權考慮。
重要
在將資料移至雲端之前，請務必先與企業主檢查是否有任何封鎖程式。 識別任何安全性或隱私權考慮，或任何在將資料移至雲端之前，應該完成的資料混淆需求。
接下來，您必須組合專家組。
組合小組
識別小組成員及其支援 POC 的承諾。 小組成員應包括：
- 執行 POC 專案的專案經理。
- 負責監督需求和結果的商務代表。
- 應用程式資料專家，用來源 POC 資料集的資料。
- Azure Synapse 專家。
- 將 POC 測試優化的專家建議程式。
- 任何需要特定 POC 專案工作，但整個期間不需要的人員。 這些支援資源可能包括網路系統管理員、Azure 系統管理員或 Microsoft Entra 系統管理員。
提示
建議您聘請專家顧問來協助處理您的 POC。 Microsoft 的合作夥伴社群 擁有專家顧問的全球可用性，可協助您評估、評估或實作 Azure Synapse。
既然您已做好充分的準備，是時候讓您的 POC 付諸實踐了。
將 POC 付諸實施
請務必記住下列事項：
- 使用任何生產專案的專業領域和嚴謹性來實作 POC 專案。
- 根據計畫執行 POC。
- 請設定變更要求程式，以防止您的 POC 範圍成長或變更。
測試開始之前，您必須設定測試環境。 它牽涉到四個階段：
- 設定
- 載入資料
- 查詢
- 增加值的測試
設定
您可以遵循下列步驟，在 Azure Synapse 上設定 POC：
- 使用此 快速入門 來布建 Synapse 工作區，並根據 POC 測試計劃設定儲存體和許可權。
- 使用此 快速入門 將專用 SQL 集區新增至 Synapse 工作區。
- 根據您的需求設定 網路和安全性 。
- 授與 POC 小組成員的適當存取權。 請參閱 本文 ，以瞭解存取專用 SQL 集區的驗證和授權。
提示
建議您 使用 DW500c 服務等級 （或以下） 來開發程式碼和單元測試 。 建議您 使用 DW1000c 服務等級 （或更新版本） 來執行負載和效能測試 。 您可以隨時 暫停專用 SQL 集 區的計算，以停止計算計費，以節省成本。
載入資料
設定專用 SQL 集區之後，您可以遵循下列步驟來載入資料：
- 將資料載入 Azure Blob 儲存體 。 針對 POC，建議您使用具有本地備援儲存體 （LRS） 的一 般用途 V2 儲存體帳戶 。 雖然有數個工具可將資料移轉至Azure Blob 儲存體，但最簡單的方式是使用 Azure 儲存體 Explorer ，可將檔案複製到儲存體容器。
- 將資料載入專用 SQL 集區。 Azure Synapse 支援兩種 T-SQL 載入方法： PolyBase 和 COPY 語句。 您可以使用 SSMS 連線到專用 SQL 集區，以使用任一方法。
當您第一次將資料載入專用 SQL 集區時，您必須考慮 要使用的散發模式 和 索引選項 。 雖然專用 SQL 集區支援各種兩者，但最佳做法是依賴預設設定。 預設設定會使用迴圈配置資源散發和叢集資料行存放區索引。 如有必要，您可以稍後調整這些設定，本文稍後會加以說明。
下列範例顯示 COPY 載入方法：
--Note when specifying the column list, input field numbers start from 1
COPY INTO
test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
'https://myaccount.blob.core.windows.net/myblobcontainer/folder1/'
WITH (
FILE_TYPE = 'CSV',
CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
FIELDQUOTE = '"',
FIELDTERMINATOR = ',',
ROWTERMINATOR = '0x0A',
ENCODING = 'UTF8',
FIRSTROW = 2
);
查詢
資料倉儲的主要用途是執行分析，這需要查詢資料倉儲。 大部分 POC 一開始會先循序並同時對資料倉儲執行少量代表性查詢。 您應該在測試計劃中定義這兩種方法。
循序查詢測試
在 SSMS 中執行循序查詢測試很容易。 請務必使用具有足夠大型 資源類別 的使用者來執行這些測試。 資源類別是專用 SQL 集區中預先決定的資源限制，可控管查詢執行的計算資源和並行。 針對簡單的查詢，我們建議使用預先定義的 staticrc20 資源類別。 如需更複雜的查詢，建議您使用預先定義的 staticrc40 資源類別。
請注意，下列第一個 查詢會使用查詢標籤 來提供追蹤查詢的機制。 第二個查詢會 sys.dm_pdw_exec_requests 使用動態管理檢視來依標籤搜尋。
/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
*
FROM
[dbo].[Date]
OPTION (LABEL = 'Test1');
/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
Total_elapsed_time AS [Elapsed_Time_ms],
[label]
FROM
sys.dm_pdw_exec_requests
WHERE
[label] = 'Test1';
並行查詢測試
記錄循序查詢效能之後，您就可以同時執行多個查詢。 如此一來，您可以模擬針對專用 SQL 集區執行的商業智慧工作負載。 執行此測試最簡單的方式是下載壓力測試工具。 最受歡迎的工具是 Apache JMeter ，這是協力廠商開放原始碼工具。
此工具會報告指定並行層級的最小、最大值和中位數查詢持續時間。 例如，假設您想要模擬會產生 100 個並行查詢的商業智慧工作負載。 您可以設定 JMeter 在迴圈中執行這 100 個並行查詢，然後檢閱穩定狀態執行。 您可以使用結果集快取 來評估 該功能的適用性。
請務必記錄您的結果。 以下是一些結果的範例：
| 並行 | # 查詢執行 | DWU | 最小持續時間（秒） | 最大持續時間（S） | 中位數持續時間（秒） |
|---|---|---|---|---|---|
| 100 | 1,000 | 5,000 | 3 | 10 | 5 |
| 50 | 5,000 | 5,000 | 3 | 6 | 4 |
混合工作負載測試
混合工作負載測試是並行查詢測試 的 延伸模組。 藉由將資料載入程式新增至工作負載混合，工作負載會更能模擬實際的生產工作負載。
優化資料
視在 Azure Synapse 上執行的查詢工作負載而定，您可能需要優化資料倉儲的散發和索引，然後重新執行測試。 如需詳細資訊，請參閱 Azure Synapse Analytics 中專用 SQL 集區的最佳做法。
安裝期間最常見的錯誤如下：
- 大型查詢會以資源類別執行，但太低。
- 專用 SQL 集區服務等級 DWU 對於工作負載而言太低。
- 大型資料表需要雜湊散發。
若要改善查詢效能，您可以：
增加值的測試
查詢效能測試完成後，最好測試特定功能，以確認它們是否符合您預期的使用案例。 這些功能包括：
最後，您必須解譯 POC 結果。
解譯 POC 結果
一旦您有資料倉儲的測試結果，請務必解譯該資料。 您可以採用的常見方法是比較價格/效能 方面的 執行。 簡單地說，價格/效能會移除每個 DWU 或服務硬體的價格差異，並為每個效能測試提供單一可比較的數位。
以下是範例：
| Test | 測試持續時間 | DWU | DWU 的 $/hr | 測試成本 |
|---|---|---|---|---|
| 測試 1 | 10 分鐘 | 1000 | $12/小時 | $2 |
| 測試 2 | 30 分鐘 | 500 | $6/小時 | $3 |
此範例可讓您輕鬆地看到 在 DWU1000 的測試 1 比每一測試回合 $3 相比，每個測試回合的 $2 更具成本效益。
注意
您也可以使用此方法來比較 POC 中廠商 的結果 。
總而言之，完成所有 POC 測試之後，您就可以評估結果。 首先，評估是否已符合 POC 目標，以及收集所需的輸出。 請記下需要其他測試的位置，以及引發的其他問題。