Synapse 实现成功方法：评估无服务器 SQL 池设计

应评估 无服务器 SQL 池 设计，以确定问题并验证它是否符合准则和要求。 通过在开始开发解决方案之前评估设计，可以避免阻碍和意外的设计更改。 这可以保护项目的时间表和预算。

现代数据、分析平台和服务存储和计算的体系结构分离是一种趋势和常用模式。 它提供了成本节省和更大的灵活性，允许独立按需缩放存储和计算。 无服务器 Synapse SQL 通过添加直接查询数据湖数据的功能来扩展这种模式。 使用自助服务类型的工作负荷时，无需担心计算管理。

在 Azure Synapse 中规划实现 SQL 无服务器池时，首先需要确保无服务器池适合工作负荷。 应考虑卓越运营、性能效率、可靠性和安全性。

为实现卓越运营，请评估以下要点。

• 解决方案开发环境： 在此方法中，会评估 解决方案开发环境。 确定环境（开发、测试和生产）的设计方式，以支持解决方案开发。 通常，你将找到生产和非生产环境（用于开发和测试）。 应在所有环境中找到 Synapse 工作区。 在大多数情况下，你将不得不隔离生产和开发/测试用户和工作负载。
• Synapse 工作区设计：在此方法中，会评估 Synapse 工作区设计。 识别工作区是如何为你的解决方案进行设计的。 熟悉设计，并了解解决方案是使用单个工作区，还是多个工作区构成了解决方案的一部分。 了解选择单个或多个工作区设计的原因。 通常选择多工作区设计来强制实施严格的安全边界。
• 部署：SQL 无服务器可供每个 Synapse 工作区按需使用，因此不需要任何特殊的部署操作。 检查服务的区域性邻近度及其连接到的 Azure Data Lake Storage Gen2 (ADLS Gen2) 帐户。
• 监测： 检查内置监视是否足够，以及是否需要设置任何外部服务来存储历史日志数据。 日志数据允许分析性能变化，并可以针对特定情况定义警报或触发的操作。

与传统的数据库引擎不同，SQL 无服务器不依赖于自己的优化存储层。 因此，其性能在很大程度上取决于如何在 ADLS Gen2 中组织数据。 对于性能效率，请评估以下要点。

• 数据引入： 查看数据存储在 Data Lake 中的方式。 文件大小、文件和文件夹结构都对性能产生影响。 请记住，虽然某些文件大小可能适用于 SQL 无服务器，但它们可能会给其他引擎或应用程序的有效处理或使用情况带来问题。 需要评估数据存储设计，并针对所有数据使用者验证它，包括 SQL 无服务器以及构成解决方案的任何其他数据工具。
• 数据放置： 评估设计是否具有统一和定义的用于数据放置的常见模式。 确保目录分支可以支持安全要求。 有一些常见模式可以帮助你保持时序数据井然有序。 无论选择什么，请确保它也适用于其他引擎和工作负载。 此外，请验证它是否有助于分隔 Spark 应用程序和外部表的自动发现。
• 数据格式：大多数情况下，SQL 无服务器使用 Parquet 格式提供最佳性能和更好的兼容性功能。 验证您的性能和兼容性要求，因为尽管 Parquet 通过更好的压缩和仅读取分析所需的列来提高性能，但它需要更多计算资源。 此外，由于某些源系统本身不支持 Parquet 作为导出格式，因此可能会导致整个体系结构中的管道和/或依赖项中的更多转换步骤。
• 勘探： 每个行业都是不同的。 但是，在许多情况下，最常见的运行查询中发现了常见的数据访问模式。 模式通常涉及按日期、类别或地理区域进行筛选和聚合。 确定最常见的筛选条件，并将其与最常运行的查询读取/丢弃的数据量相关联。 验证是否组织了 Data Lake 上的信息，以符合你的探索要求和期望。 对于设计中和评估中确定的查询，看看是否可以消除 OPENROWSET 路径参数中的不必要分隔，或者如果有外部表，则创建更多索引是否有帮助。

对于可靠性，请评估以下几点。

• 可用性： 验证 在评估阶段确定的任何可用性要求。 虽然没有用于 SQL 无服务器的任何特定 SLA，但查询执行超时为 30 分钟。 识别评估中运行时间最长的查询，并针对无服务器 SQL 设计对其进行验证。 30 分钟超时可能破坏你对工作负载的预期，并显示为服务问题。
• 一致性：SQL 无服务器主要用于读取工作负载。 因此，验证数据湖数据预配和形成过程中是否执行了所有一致性检查。 紧跟最新功能发展，例如 Delta Lake 开源存储层，它为事务提供 ACID（原子性、一致性、隔离性和持久性）保证的支持。 此功能允许实现有效的 lambda 或 kappa 体系结构 来支持流式处理和批处理用例。 请务必评估你的设计，寻找应用新功能的机会，但不以牺牲项目的时间线或成本为代价。
• 备份： 查看评估期间确定的任何灾难恢复要求。 根据 SQL 无服务器恢复设计对其进行验证。 SQL 无服务器本身没有自己的存储层，这需要处理数据的快照和备份副本。 无服务器 SQL 访问的数据存储是外部的（ADLS Gen2）。 查看项目中针对这些数据集的恢复设计。

组织数据对于构建灵活的安全基础非常重要。 在大多数情况下，不同的进程和用户需要对 Data Lake 或逻辑数据仓库的特定子区域具有不同的权限和访问权限。

对于安全性，请评估以下几点。

• 数据存储： 使用 评估阶段收集的信息，确定是否需要将典型的 原始、 阶段和 特选 数据湖区域放置在同一存储帐户而不是独立的存储帐户上。 后者可能会在角色和权限方面产生更大的灵活性。 如果体系结构必须支持大量同时读取/写入工作负荷（例如实时或 IoT 方案），还可以添加所需的每秒输入/输出作数（IOPS）容量。 通过在单独的存储帐户上保留沙盒和主数据区域来验证是否需要进一步隔离。 大多数用户不需要更新或删除数据，因此，除了沙盒区域和专用区域之外，他们不需要对数据湖具有写入权限。
• 在评估信息中，确定任何要求是否依赖于 Always Encrypted、 动态数据掩码 或 行级别安全性等安全功能。 在特定方案中验证这些功能的可用性，例如在 OPENROWSET 函数中使用时。 预测可能需要的潜在解决方法。
• 从评估信息中，确定最佳身份验证方法。 请考虑 Microsoft Entra 服务主体、共享访问签名 (SAS)，以及何时和如何在客户选择的探索工具中使用和集成身份验证直通。 评估设计并验证设计过程中的最佳身份验证方法。

查看你的设计，并检查是否已实施 最佳做法和建议。 特别注意筛选优化和排序规则，以确保谓词下推正常工作。

在 Azure Synapse 成功设计系列中的下一篇文章中，了解如何评估 Spark 池设计，以确定问题并验证它是否符合指南和要求。