通过

SQL 分析端点性能注意事项

  • 项目

适用于：✅Microsoft Fabric 中的 SQL 分析端点

借助 SQL 分析端点，可以使用 T-SQL 语言和 TDS 协议查询湖屋中的数据。 每个湖屋都有一个 SQL 分析端点。 工作区中的 SQL 分析端点数与在该工作区中预配的湖屋和镜像数据库数匹配。

一个后台进程负责扫描湖屋中的更改，并使 SQL 分析端点保持最新状态，以获取提交给工作区中湖屋的所有更改。 同步过程由 Microsoft Fabric 平台透明地管理。 当在湖屋中检测到更改时，后台进程会更新元数据，SQL 分析端点会反映提交给湖屋表的更改。 在正常操作条件下，湖屋和 SQL 分析端点之间的滞后时间不到一分钟。 实际时间长度可能从几秒钟到几分钟不等，具体取决于本文所讨论的多种因素。

Lakehouse 的 SQL 分析端点中自动生成的架构

SQL 分析端点管理自动生成的表，因此工作区用户无法修改它们。 用户可通过添加自己的 SQL 架构、视图、过程和其他数据库对象来丰富数据库模型。

对于 Lakehouse 中的每个 Delta 表，SQL 分析终结点都会在适当的架构中自动生成一个表。 有关 SQL 分析端点的自动生成的架构数据类型，请参阅 Microsoft Fabric 中的数据类型。

SQL 分析端点中的表创建存在轻微延迟。 在湖中创建或更新 Delta Lake 表后，将会自动创建/刷新引用 Delta Lake 表的 SQL 分析终结点表。

刷新表所需的时间与优化 Delta 表的方式有关。 有关详细信息，请查看 Delta Lake 表优化和 V 顺序了解关于关键方案的详细信息，以及有关如何高效维护 Delta 表以实现最佳性能的深入指南。

可以在 Fabric 门户中手动强制刷新自动元数据扫描。 在 SQL 分析端点的页面上，选择“资源管理器”工具栏中的“刷新”按钮以刷新架构。 转到“查询”SQL 分析端点并查找“刷新”按钮，如下图所示。

Fabric 门户中的屏幕截图显示了 SQL 分析端点的“刷新架构”按钮。

指南

  • 自动元数据发现跟踪提交给湖屋的更改，并且是每个 Fabric 工作区的单个实例。 如果观察到湖屋和 SQL 分析端点之间同步更改的延迟增加，这可能是由于一个工作区中有大量湖屋。 在这种应用场景下，请考虑将每个湖屋迁移到单独的工作区，因为这样就可以缩放自动发现元数据。
  • Parquet 文件设计是不可变的。 当存在更新或删除操作时，增量表将使用变更集添加新的 parquet 文件，并根据更新和删除的频率随着时间推移增加文件的数量。 如果没有安排维护，最终，这种模式会产生读取开销，这会影响将更改同步到 SQL 分析端点所需的时间。 若要解决此问题，请计划定期湖屋表维护操作。
  • 在某些应用场景中，你可能会发现，提交给湖屋的更改在关联的 SQL 分析端点中不可见。 例如，你可能已在湖屋中创建了一个新表，但它未列在 SQL 分析端点中。 或者，你可能已将大量行提交到湖屋中的表，但此数据在 SQL 分析端点中不可见。 我们建议启动按需元数据同步，该同步由 SQL 查询编辑器“刷新”功能区选项触发。 此选项会强制按需元数据同步，而不是等待后台元数据同步完成。
  • 并非所有 Delta 功能都会被自动同步过程理解。 有关 Fabric 中每个引擎支持的功能的详细信息，请参阅 Delta Lake 互操作性。
  • 如果在提取转换和加载 (ETL) 处理期间发生了非常大量的表更改，则在处理所有更改之前，可能会出现预期的延迟。

分区大小注意事项

为湖屋中的增量表选择分区列也会影响将更改同步到 SQL 分析端点所需的时间。 分区列的分区数量和大小对于性能很重要：

  • 基数较高的列（大部分或全部由唯一值组成）会导致大量分区。 大量分区会对元数据发现扫描更改的性能产生负面影响。 如果某一列的基数很高，请选择另一列进行分区。
  • 每个分区的大小也会影响性能。 我们的建议是使用能够产生至少（或接近）1 GB 分区的列。 我们建议遵循增量表维护和优化的最佳实践。 有关用于评估分区的 Python 脚本，请参阅分区详细信息的示例脚本。

大量小型 parquet 文件会增加在湖屋与其关联的 SQL 分析端点之间同步更改所需的时间。 由于以下一个或多个原因，可能最终会在增量表中留下大量的 parquet 文件：

  • 如果为具有大量唯一值的增量表选择分区，则它将按每个唯一值进行分区，并且可能会过度分区。 选择基数不太高的分区列，产生大小至少为 1 GB 的单个分区。
  • 批处理和流式传输数据引入速率也可能会产生较小文件，具体取决于写入湖屋的更改的频率和大小。 例如，可能会有少量更改传入湖屋，这将产生小型 parquet 文件。 若要解决此问题，建议实施常规湖屋表维护。

分区详细信息的示例脚本

使用以下笔记本打印一份详细说明支撑增量表的分区的大小和详细信息的报告。

  1. 首先，必须在变量 delta_table_path 中为增量表提供 ABSFF 路径。
    • 可以从 Fabric 门户资源管理器获取增量表的 ABFSS 路径。 右键单击表名，然后从选项列表中选择 COPY PATH。
  2. 该脚本会输出增量表的所有分区。
  3. 该脚本会循环访问每个分区，以计算文件的总大小和数量。
  4. 该脚本会输出分区的详细信息、每个分区的文件数和每个分区的大小（以 GB 为单位）。

完整的脚本可以从以下代码块复制：

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
  from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
  delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

相关内容