引入批处理策略

概述

在排队引入过程中,服务通过在引入前一起批处理较小的流入量数据块,来针对吞吐量进行优化。 批处理减少了排队引入过程消耗的资源,并且不需要资源在引入后优化非批处理引入产生的小型数据分片。

在引入前执行批处理的缺点是强制延迟。 因此,从请求数据引入到准备好查询的数据的端到端时间更长。

定义 IngestionBatching 策略时,需要在吞吐量优化与时间延迟之间找到平衡。 此策略适用于排队的引入。 它定义将小型 Blob 一起批处理时允许的最大强制延迟。 若要详细了解如何使用批处理策略命令和优化吞吐量,请参阅:

密封批

批量引入的最佳大小为大约 1 GB 的未压缩数据。 具有少得多的数据的 Blob 的引入是次佳选择,因此在排队的引入中,服务将一起批处理小型 Blob。

以下列表显示了密封批的基本批处理策略触发器。 满足第一个条件时,将密封并引入批:

  • Size:达到或超过批大小限制
  • Count:已达到批文件编号限制
  • Time:批处理时间已过期

可以在数据库或表上设置 IngestionBatching 策略。 默认值如下:最大延迟时间为 5 分钟,项数为 1000,总大小为 1GB。

重要

将此策略设置为非常小的值会增加群集的 COGS(所售货物成本)并降低性能。 此外,由于并行管理多个引入进程而产生的开销,减小批处理策略值实际上可能导致增大有效的端到端引入延迟。

以下列表显示了密封与单个 Blob 引入相关的批的条件。 满足条件时,会密封并引入批:

  • SingleBlob_FlushImmediately:引入单个 blob,因为设置了 'FlushImmediately'
  • SingleBlob_IngestIfNotExists:引入单个 blob,因为设置了'IngestIfNotExists'
  • SingleBlob_IngestByTag:引入单个 blob,因为设置了'ingest-by'
  • SingleBlob_SizeUnknown:引入单个 blob,因为 blob 大小未知

如果设置了 SystemFlush 条件,则触发系统刷新时将密封批。 如果设置了 SystemFlush 参数,系统会刷新数据(例如由于群集缩放或系统组件的内部重置)。

默认值和限制

类型 属性 默认 低延迟设置 最小值 最大值
项数 MaximumNumberOfItems 500 500 1 25,000
数据大小 (MB) MaximumRawDataSizeMB 1024 1024 100 4096
时间 (秒) MaximumBatchingTimeSpan 300 20 - 30 10 1800

使用引入批处理策略控制端到端延迟的最有效方法是根据延迟要求的上限在数据库级别更改其时间边界。 数据库级别策略会影响该数据库中未定义表级策略的所有表,以及任何新创建的表。

重要

如果在低入口表上将引入批处理策略的时间边界设置得太低,则群集尝试优化新创建的数据分片时,可能会产生额外的计算和存储工作。 有关数据分片的详细信息,请参阅分片

批数据大小

已针对未压缩的数据设置批处理策略数据大小。 对于 Parquet、AVRO 和 ORC 文件,根据文件大小计算估算值。 对于压缩数据,按以下准确度降序计算未压缩的数据大小:

  1. 如果在“引入源”选项中提供了未压缩的大小,则使用该值。
  2. 使用 SDK 来引入本地文件时,会检查 zip 存档和 gzip 流,以评估其原始大小。
  3. 如果以前的选项未提供数据大小,则会对压缩数据大小应用一个因子,以估计未压缩的数据大小。

批处理延迟

延迟可能是许多原因造成的,可以使用批处理策略设置处理这些原因。

原因 解决方案
数据延迟与 time 设置匹配,数据过少未达到 sizecount 限制 降低 time 上限
由于存在大量非常小的文件,批处理效率低下 增加源文件的大小。 如果使用 Kafka 接收器,请将其配置为以大约 100 KB 块或更多块发送数据。 如果有许多小文件,请在数据库或表引入策略中增加 count(最多到 2000)。
批处理大量未压缩的数据 在引入 Parquet 文件时,这很常见。 递减表或数据库批处理策略的 size 到 250 MB,并检查改进情况。
积压工作,因为群集未充分扩展 接受任何 Azure 顾问建议,以充分扩展或纵向扩展群集。 或者,手动缩放群集,查看积压工作是否关闭。 如果这些选项不起作用,请联系支持人员寻求帮助。