Synapse 實作成功方法：評估工作區設計

發行項
10/18/2023

注意

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

Synapse 工作區是統一的圖形化使用者體驗，可結合您的分析和資料處理引擎、Data Lake、資料庫、資料表、資料集和報告成品，以及程式碼和流程協調流程。考慮到整合到 Synapse 工作區中的技術和服務數目，請確定您的設計中包含關鍵元件。

Synapse 工作區設計檢閱

識別您的解決方案設計是否牽涉到一個 Synapse 工作區或多個工作區。判斷此設計的驅動程式。雖然可能有不同的原因，但在大多數情況下，多個工作區的原因是安全性隔離或計費隔離。判斷工作區和資料庫界限的數目時，請記住每個訂用帳戶的限制為 20 個工作區。

識別每個工作區內需要共用哪些專案或服務，以及哪些資源。資源可以包括 Data Lake、Integration Runtime （IRs）、中繼資料或組態，以及程式碼。判斷為何在潛在的協同效應方面選擇此特定設計。詢問這些協同效應是否證明額外的成本和管理額外負荷合理。

Data Lake 設計檢閱

建議您適當地分層 Data Lake（如果您的解決方案的一部分）。您應該將 Data Lake 分成三個主要區域，這些 區域與銅級 、銀級和金級資料集相關。銅級 - 或原始層 - 可能會位於自己的個別儲存體帳戶上，因為它因為可能儲存的未遮罩敏感性資料而具有更嚴格的存取控制。

安全性設計檢閱

檢閱工作區的安全性設計，並將其與您在評量期間收集的資訊進行比較。請確定符合所有需求，並考慮所有條件約束。為了方便管理，我們建議您將使用者組織成具有適當許可權分析的群組：您可以使用與角色一致的安全性群組來簡化存取控制。如此一來，網路系統管理員可以從適當的安全性群組新增或移除使用者來管理存取權。

無伺服器 SQL 集區和 Apache Spark 資料表會將其資料儲存在與工作區相關聯的 Azure Data Lake Gen2 （ADLS Gen2）容器中。使用者安裝的 Apache Spark 程式庫也會在此相同的儲存體帳戶中管理。若要啟用這些使用案例，必須將使用者和工作區受控服務識別（MSI）新增至 ADLS Gen2 儲存體容器的儲存體 Blob 資料參與者 角色。根據您的安全性需求確認此需求。

專用 SQL 集區提供一組豐富的安全性功能，以加密和遮罩敏感性資料。專用和無伺服器 SQL 集區都啟用 SQL Server 許可權的完整介面區，包括內建角色、使用者定義角色、SQL 驗證和 Microsoft Entra 驗證。檢閱解決方案專用 SQL 集區和無伺服器 SQL 集區存取和資料的安全性設計。

檢閱資料湖的安全性計畫，以及將構成 Azure Synapse Analytics 解決方案一部分的所有 ADLS Gen2 儲存體帳戶（以及其他帳戶）。 ADLS Gen2 儲存體本身不是計算引擎，因此它沒有選擇性地遮罩資料屬性的內建功能。您可以在儲存體帳戶或容器層級套用 ADLS Gen2 許可權，方法是使用角色型存取控制（RBAC）和/或透過存取控制清單（ACL）在資料夾或檔案層級套用 ADL。仔細檢閱設計，並努力避免不必要的複雜度。

以下是安全性設計的一些考慮點。

請確定設計中包含 Microsoft Entra ID 設定需求。
檢查跨租使用者案例。可能會發生這類問題，因為某些資料位於另一個 Azure 租使用者中，或需要移至另一個租使用者，或需要由來自另一個租使用者的使用者存取。請確定這些案例會在您的設計中考慮。
每個工作區的角色為何？他們如何使用工作區？
如何在工作區內設計安全性？
- 神秘可以檢視所有腳本、筆記本和管線？
- 神秘可以執行腳本和管線嗎？
- 神秘可以建立/暫停/繼續 SQL 和 Spark 集區嗎？
- 神秘可以將變更發佈至工作區嗎？
- 神秘可以將變更認可至原始檔控制？
管線是否會使用預存認證或工作區受控識別來存取資料？
使用者是否具有資料湖的適當存取權，以流覽 Synapse Studio 中的資料？
Data Lake 是否使用適當的 RBAC 和 ACL 組合來保護資料湖？
是否已針對每個角色正確設定 SQL 集區使用者權限（資料科學家、開發人員、系統管理員、商務使用者和其他角色）？

網路設計檢閱

以下是網路設計的一些考慮點。

所有資源之間的連線是否設計？
要使用的網路機制為何（Azure ExpressRoute、公用網際網路或私人端點）？
您是否必須能夠安全地連線到 Synapse Studio？
資料外流是否已納入考慮？
您需要連線到內部部署資料來源嗎？
您是否需要連線到其他雲端資料來源或計算引擎，例如 Azure 機器學習？
是否已檢閱 Azure 網路元件，例如網路安全性群組（NSG），以取得適當的連線和資料移動？
是否已考慮與私人 DNS 區域的整合？
您是否必須能夠從 Synapse Studio 內流覽資料湖，或使用無伺服器 SQL 或 PolyBase 查詢 Data Lake 中的資料？

最後，識別所有資料取用者，並確認其連線能力已在設計中考慮。檢查網路和安全性前哨是否允許您的服務存取所需的內部部署來源，以及其驗證通訊協定和機制是否受到支援。在某些情況下，您可能需要有多個自我裝載 IR 或 SaaS 解決方案的資料閘道，例如 Microsoft Power BI。

監視設計檢閱

檢閱 Azure Synapse 元件監視的設計，以確保它們符合評估期間所識別的需求和期望。確認已設計監視資源和資料存取，並識別每個監視需求。在生產環境的第一個部署中，應備妥健全的監視解決方案。如此一來，就可以及時識別、診斷和解決失敗。除了基底基礎結構和管線執行之外，也應該監視資料。根據使用的 Azure Synapse 元件而定，找出每個元件的監視需求。例如，如果 Spark 集區構成解決方案的一部分，請監視格式不正確的記錄存放區。

以下是監視設計的一些考慮點。

神秘可以監視每個資源類型（管線、集區和其他人）？
需要保留資料庫活動記錄多久？
工作區和資料庫記錄保留是否會使用 Log Analytics 或 Azure 儲存體？
當發生管線錯誤時，是否會觸發警示？如果是，應該通知誰？
SQL 集區的臨界值層級應該觸發警示？應該通知神秘？

原始檔控制設計檢閱

根據預設，Synapse 工作區會使用內建的發佈功能，直接將變更套用至 Synapse 服務。您可以啟用原始檔控制整合，以提供許多優點。優點包括更好的共同作業、版本控制、核准和發行管線，以透過開發、測試和生產環境來提升變更。 Azure Synapse 允許每個工作區的單一原始檔控制存放庫，可以是 Azure DevOps Git 或 GitHub。

以下是原始檔控制設計的一些考慮點。

如果使用 Azure DevOps Git，Synapse 工作區及其存放庫是否位於相同的租使用者中？
神秘可以存取原始檔控制嗎？
在原始檔控制中，每位使用者都會獲得哪些許可權？
是否已開發分支和合併策略？
是否會開發發行管線以部署至不同的環境？
核准程式是否會用於合併和發行管線？

注意

開發環境的設計對於專案的成功至關重要。如果已設計開發環境，則會在此方法的個別階段進行評估。

下一步

在 Azure Synapse 成功設計 系列中的下一篇文章 中，瞭解如何評估資料整合設計，並驗證其是否符合指導方針和需求。

共用方式為