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）和/或在文件夹或文件级别使用访问控制列表（ACL）在存储帐户或容器级别应用 ADLS Gen2 权限。 仔细查看设计，努力避免不必要的复杂性。

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

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

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

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

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

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

下面是监视设计的一些注意事项。

• 谁可以监视每个资源类型（管道、池和其他资源） ？
• 需要保留数据库活动日志多长时间？
• 工作区和数据库日志保留将使用 Log Analytics 还是 Azure 存储？
• 如果出现管道错误，是否会触发警报？ 如果是这样，应该通知谁？
• 什么样的 SQL 池阈值级别应当触发警告？ 谁应该收到通知？

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