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

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

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

适应差距分析

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

卓越运营

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

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

性能效率

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

• 数据引入：查看数据在数据湖中的存储方式。 文件大小、文件数量和文件夹结构都会对性能产生影响。 请记住，虽然某些文件大小可能适用于 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)。 在项目中评审这些数据集的恢复设计。

安全性

数据的组织方式对于建立灵活的安全基础非常重要。 在大多数情况下，不同的过程和用户需要不同的权限，以及对数据湖或逻辑数据仓库的特定子区域的访问权限。

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

• 数据存储：使用在评估阶段收集的信息，确定是否需要将典型的“原始”、“暂存”和“特选”数据湖区域放在同一个存储帐户而不是独立的存储帐户上。 如果放在独立的存储帐户上，可能会提高角色和权限方面的灵活性。 如果体系结构必须支持繁重的同时读/写工作负载（例如实时或 IoT 方案），则这还可以增加可能需要的每秒输入/输出操作次数 (IOPS) 容量。 通过将沙盒数据区域和主数据区域保留在独立的存储帐户上来验证是否需要进一步隔离。 大多数用户不需要更新或删除数据，因此他们不需要对数据湖的写入权限，但沙盒和专用区域除外。
• 根据评估信息，确定是否有任何要求依赖于 Always Encrypted、动态数据掩码或行级安全性等安全功能。 验证这些功能在特定方案中的可用性，例如与 OPENROWSET 函数一起使用时。 提前得出可能需要的潜在解决方法。
• 根据评估信息，确定最佳身份验证方法。 考虑 Microsoft Entra 服务主体、共享访问签名 (SAS)，以及何时、如何使用身份验证传递并将其集成到客户选择的探索工具中。 评估设计，并验证作为设计一部分的最佳身份验证方法。

其他注意事项

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

后续步骤

在“按设计成功实施 Azure Synapse”系列教程的下一篇文章中，了解如何评估 Spark 池设计以识别问题并验证它是否符合准则和要求。