共用方式為

Synapse 實作成功方法：評估無伺服器 SQL 集區設計

  • 發行項

注意

本文會透過設計 一系列文章，形成 Azure Synapse 實作成功的一部分 。 如需系列的概觀，請參閱 Azure Synapse 實作成功設計 。

您應該評估 無伺服器 SQL 集區 設計，以找出問題並驗證它是否符合指導方針和需求。 藉由在解決方案開發開始 前評估設計 ，您可以避免封鎖程式和非預期的設計變更。 如此一來，您就可以保護專案的時程表和預算。

新式資料、分析平臺和服務之儲存體和計算的架構分離一直是趨勢且常用的模式。 它可節省成本，並提供更多彈性，讓您獨立隨選調整儲存體和計算。 Synapse SQL 無伺服器可藉由新增功能來直接查詢 Data Lake 資料，藉此擴充此模式。 使用自助式工作負載類型時，不需要擔心計算管理。

調整差距分析

規劃在 Azure Synapse 中實作 SQL 無伺服器集區時，您必須先確定無伺服器集區適合您的工作負載。 您應該考慮卓越營運、效能效率、可靠性和安全性。

卓越營運

針對卓越營運，請評估下列幾點。

  • 解決方案開發環境： 在此方法中，會評估 解決方案開發環境 。 識別環境（開發、測試和生產環境）的設計方式，以支援解決方案開發。 通常，您會發現生產和非生產環境（用於開發和測試）。 您應該在所有環境中找到 Synapse 工作區。 在大部分情況下，您必須隔離生產環境與開發/測試使用者和工作負載。
  • Synapse 工作區設計： 在此方法中，會評估 Synapse 工作區設計 。 識別如何為您的解決方案設計工作區。 熟悉設計，並瞭解解決方案是否會使用單一工作區，或多個工作區是否構成解決方案的一部分。 瞭解為何選擇單一或多個工作區設計。 通常會選擇多重工作區設計來強制執行嚴格的安全性界限。
  • 部署： SQL 無伺服器可隨選使用每個 Synapse 工作區，因此不需要任何特殊的部署動作。 檢查服務的區域鄰近性，以及其所連線的 Azure Data Lake 儲存體 Gen2 （ADLS Gen2） 帳戶。
  • 監視： 檢查內建監視是否足夠，以及是否需要放置任何外部服務來儲存歷程記錄資料。 記錄資料可讓您分析效能的變更，並可讓您針對特定情況定義警示或觸發的動作。

效能效益

與傳統的資料庫引擎不同，SQL 無伺服器不會依賴自己的優化儲存層。 因此，其效能在很大程度上取決於資料在 ADLS Gen2 中的組織方式。 針對效能效率，請評估下列幾點。

  • 資料擷取： 檢閱資料如何儲存在 Data Lake 中。 檔案大小、檔案數目和資料夾結構都會影響效能。 請記住，雖然某些檔案大小可能適用于 SQL 無伺服器，但它們可能會造成其他引擎或應用程式有效率處理或取用的問題。 您必須評估資料儲存體設計，並針對所有資料取用者進行驗證，包括 SQL 無伺服器和構成解決方案一部分的任何其他資料工具。
  • 資料放置： 評估您的設計是否具有統一和定義的資料放置常見模式。 請確定目錄分支可以支援您的安全性需求。 有一些常見的模式可協助您組織時間序列資料。 無論您選擇什麼，請確定它也適用于其他引擎和工作負載。 此外，驗證它是否有助於分割 Spark 應用程式和外部資料表的自動探索。
  • 資料格式： 在大部分情況下，SQL 無伺服器會使用 Parquet 格式來提供最佳效能和更佳的相容性功能。 確認您的效能和相容性需求，因為 Parquet 可改善效能 -- 由於 IO 的壓縮和縮減（唯讀取分析所需的必要資料行）-它需要更多的計算資源。 此外，由於某些來源系統原生不支援 Parquet 做為匯出格式，因此可能會導致整個架構中的管線和/或相依性中執行更多轉換步驟。
  • 探索： 每個行業都不同。 不過，在許多情況下，在最常執行的查詢中找到常見的資料存取模式。 模式通常涉及依日期、類別或地理區域的篩選和匯總。 識別最常見的篩選準則，並將其與最常執行的查詢讀取/捨棄的資料量產生關聯。 驗證資料湖上的資訊是否組織，以偏向您的探索需求和期望。 如需設計中和評估中所識別的查詢，請參閱您是否可以在 OPENROWSET 路徑參數中排除不必要的分割區，或 -如果有外部資料表，是否可協助建立更多索引。

可靠性

如需可靠性，請評估下列幾點。

  • 可用性： 驗證評估階段 期間 識別的任何可用性需求。 雖然 SQL 無伺服器沒有任何特定的 SLA，但查詢執行會有 30 分鐘的逾時。 識別評定中執行時間最長的查詢，並針對無伺服器 SQL 設計進行驗證。 30 分鐘的逾時可能會中斷工作負載的預期，並顯示為服務問題。
  • 一致性： SQL 無伺服器主要是針對讀取工作負載所設計。 因此，驗證資料湖資料布建和形成程式期間是否已執行所有一致性檢查。 隨時掌握新功能，例如 Delta Lake 開放原始碼儲存層，可提供對交易的 ACID（不可部分完成性、一致性、隔離和持久性）的支援。 這項功能可讓您實作有效的 Lambda 或 kappa 架構 ，以支援串流和批次使用案例。 請務必評估您的設計，以取得套用新功能的機會，但不會犧牲專案的時間軸或成本。
  • 備份： 檢閱評估期間識別的任何災害復原需求。 針對您的 SQL 無伺服器設計進行復原驗證。 SQL 無伺服器本身沒有自己的儲存層，而且需要處理資料的快照集和備份複本。 無伺服器 SQL 存取的資料存放區是外部的 （ADLS Gen2）。 檢閱專案中這些資料集的復原設計。

安全性

組織資料對於建立彈性安全性基礎很重要。 在大部分情況下，不同的進程和使用者需要不同的許可權和存取權，才能存取資料湖或邏輯資料倉儲的特定子領域。

針對安全性，請評估下列幾點。

  • 資料儲存體： 使用評估階段 收集 的資訊，識別是否需要將一般 Raw 、 Stage 和 策展資料 湖區域放在相同的儲存體帳戶上，而不是獨立的儲存體帳戶。 後者可能會在角色和許可權方面產生更大的彈性。 如果您的架構必須支援大量且同時的讀取/寫入工作負載（例如即時或 IoT 案例），也可以增加每秒可能需要的輸入/輸出作業 （IOPS） 容量。 驗證您是否需要進一步隔離，方法是將沙箱化和主要資料區域保留在個別的儲存體帳戶上。 大部分的使用者不需要更新或刪除資料，因此除了沙箱化和私人區域之外，他們不需要將資料湖寫入權限。
  • 從您的評定資訊中，識別任何需求是否依賴 Always Encrypted 、 動態資料遮罩 或 資料列層級安全性等 安全性 功能。 在特定案例中驗證這些功能的可用性，例如搭配 OPENROWSET 函式使用時。 預期可能需要的潛在因應措施。
  • 從您的評量資訊中，找出最適合的驗證方法。 請考慮 Microsoft Entra 服務主體、共用存取簽章（SAS），以及驗證傳遞的時機和方式，以及如何在客戶選擇的探索工具中整合。 評估設計，並驗證設計中的最佳驗證方法。

其他考量

檢閱您的設計，並檢查您是否已設定 最佳做法和建議 。 請特別注意篩選優化和定序，以確保述詞下推正常運作。

下一步

在 Azure Synapse 成功設計 系列中的 下一篇文章 中，瞭解如何評估 Spark 集區設計，以找出問題並驗證它是否符合指導方針和需求。