通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Synapse 实现成功方法：评估工作区设计

  • 项目

注意

本文是“按设计成功实施 Azure Synapse”系列文章的一部分。 有关系列概述，请参阅 Azure Synapse 实现成功（设计）。

Synapse 工作区是一种统一的图形用户体验，它将分析和数据处理引擎、数据湖、数据库、表、数据集和报告项目以及代码和流程编排拼凑在一起。 考虑到集成到 Synapse 工作区中的技术和服务的数量，请确保设计中包含关键组件。

Synapse 工作区设计评审

确定解决方案设计是涉及一个 Synapse 工作区还是多个工作区。 确定此设计的驱动因素。 虽然原因可能不同，但在大多数情况下，多个工作区的原因是安全隔离或计费隔离。 在确定工作区和数据库边界的数量时，请记住每个订阅最多只能有 20 个工作区。

确定每个工作区中的哪些元素或服务需要共享以及与哪些资源共享。 资源可以包括数据湖、集成运行时 (IR)、元数据或配置以及代码。 确定选择此特定设计的原因（从潜在协同作用方面而言）。 问问自己这些协同作用是否证明了额外的成本和管理开销是合理的。

数据湖设计评审

我们建议对数据湖（如果是解决方案的一部分）进行适当分层。 应将数据湖划分为与“青铜”、“白银”和“黄金”数据集相关的三个主要区域。 青铜或原始层可能驻留在自己的单独存储帐户上，因为它可能存储未屏蔽的敏感数据，因此具有更严格的访问控制。

安全设计评审

评审工作区的安全设计，并将其与评估期间收集的信息进行比较。 确保满足所有要求，并考虑所有约束。 为了便于管理，建议将用户组织到具有适当权限分析的组中：可以通过使用与角色一致的安全组来简化访问控制。 这样，网络管理员可以在适当的安全组中添加或删除用户以管理访问。

无服务器 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 存储本身不是计算引擎，因此它没有选择性地屏蔽数据属性的内置功能。 可以使用基于角色的访问控制 (RBAC) 在存储帐户或容器级别应用 ADLS Gen2 权限，和/或使用访问控制列表 (ACL) 在文件夹或文件级别应用 ADLS Gen2 权限。 仔细评审设计，努力避免不必要的复杂性。

以下是安全设计需要考虑的一些要点。

  • 确保设计中包含 Microsoft Entra ID 设置要求。
  • 检查跨租户情况。 出现此类问题的原因可能是某些数据位于另一个 Azure 租户中，或者需要移动到另一个租户，或者需要由另一个租户的用户访问。 请确保在设计中考虑这些情况。
  • 每个工作区包含哪些角色？ 他们将如何使用工作区？
  • 工作区内的安全是如何设计的？
    • 谁可以查看所有脚本、笔记本和管道？
    • 谁可以执行脚本和管道？
    • 谁可以创建/暂停/恢复 SQL 和 Spark 池？
    • 谁可以向工作区发布更改？
    • 谁可以向源代码管理提交更改？
  • 管道是否使用存储的凭据或工作区托管标识来访问数据？
  • 用户是否有权访问数据湖以浏览 Synapse Studio 中的数据？
  • 数据湖是否使用 RBAC 和 ACL 的适当组合进行正确保护？
  • 是否为每个角色（数据科学家、开发人员、管理员、业务用户等）正确设置了 SQL 池用户权限？

网络设计评审

以下是网络设计需要考虑的一些要点。

  • 是否在所有资源之间设计连接？
  • 要使用的网络机制是什么（Azure ExpressRoute、公共 Internet 或专用终结点）？
  • 是否需要能够安全连接到 Synapse Studio？
  • 是否考虑了数据外泄？
  • 是否需要连接到本地数据源？
  • 是否需要连接到其他云数据源或计算引擎，例如 Azure 机器学习？
  • 是否已评审 Azure 网络组件（如网络安全组 (NSG)）的正确连接和数据移动？
  • 是否考虑了与专用 DNS 区域的集成？
  • 是否需要能够从 Synapse Studio 中浏览数据湖，或者只需使用无服务器 SQL 或 PolyBase 查询数据湖中的数据？

最后，确定所有数据使用者，并验证是否在设计中考虑了其连接。 检查网络和安全前哨是否允许服务访问所需的本地源，以及其身份验证协议和机制是否受支持。 在某些情况下，可能需要为 SaaS 解决方案（如 Microsoft Power BI）提供多个自承载 IR 或数据网关。

监视设计评审

评审 Azure Synapse 组件的监视设计，以确保它们满足评估期间确定的要求和期望。 验证是否已设计资源和数据访问的监视，并确定每个监视要求。 在第一次部署到生产的过程中，应实施可靠的监视解决方案。 这样，就可以及时识别、诊断和解决故障。 除了基本基础结构和管道运行之外，还应监视数据。 根据使用的 Azure Synapse 组件，确定每个组件的监视要求。 例如，如果 Spark 池构成解决方案的一部分，则监视格式不正确的记录存储。 

以下是监视设计需要考虑的一些要点。

  • 谁可以监视每种资源类型（管道、池等）？
  • 数据库活动日志需要保留多长时间？
  • 工作区和数据库日志保留将使用 Log Analytics 还是 Azure 存储？
  • 在发生管道错误时，是否会触发警报？ 如果是，应通知谁？
  • SQL 池的哪个阈值级别应触发警报？ 应通知谁？

源代码管理设计评审

默认情况下，Synapse 工作区使用内置发布功能直接将更改应用于 Synapse 服务。 可以启用源代码管理集成，这提供了许多优势。 优点包括更好的协作、版本控制、批准和发布管道，以促进对开发、测试和生产环境的更改。 Azure Synapse 允许每个工作区有一个源代码管理存储库，可以是 Azure DevOps Git 或 GitHub。

以下是源代码管理设计需要考虑的一些要点。

  • 如果使用 Azure DevOps Git，Synapse 工作区及其存储库是否在同一租户中？
  • 谁将能够访问源代码管理？
  • 在源代码管理中将为每个用户授予哪些权限？
  • 是否已制定分支和合并策略？
  • 是否会开发发布管道以部署到不同的环境？
  • 审批过程是否会用于合并和发布管道？

注意

开发环境的设计对于项目的成功至关重要。 如果已设计开发环境，则会在 此方法的单独阶段对其进行评估。

后续步骤

在“Azure Synapse 成功（设计）”系列的下一篇文章中，了解如何评估数据集成设计并验证它是否符合准则和要求。