Kusto 引入库的最佳做法

本文介绍使用 Kusto 引入库进行数据引入的最佳做法。

首选排队还不是直接引入

对于生产方案,请使用排队引入客户端。 有关详细信息,请参阅排队引入直接引入

使用单个引入客户端实例

Kusto 引入客户端实现是线程安全的,而且是可重用的。 对于每个目标集群,每个进程使用排队引入或直接引入客户端的单个实例。 运行多个实例可能会使集群过载,导致集群无响应或对有效请求的响应缓慢。

限制跟踪操作状态

对于大量数据流,请限制对引入请求使用积极通知。 过度跟踪可能会导致引入延迟增加,甚至使整个群集无响应。 有关详细信息,请参阅操作状态

优化吞吐量

规划引入管道时,请考虑以下因素,因为它们可能对引入吞吐量产生重大影响。

因子 说明
数据大小 在大型区块中操作时,引入效果更高。 建议批量发送 100 MB 到 1 GB 的数据(未压缩)。
数据格式 CSV 是最快的引入格式。 对于相同量的数据,JSON 可能需要 2 倍或 3 倍的时间。 有关详细信息,请参阅引入支持的数据格式
表宽度 只引入必要的数据。 需要对每一列进行编码和索引,这意味着表越宽,吞吐量可能越低。 通过提供引入映射来控制要引入哪些字段。
源数据位置 避免跨区域读取可加快引入速度。
群集上的负载 当群集遇到较高的查询负载时,引入需要更长的时间才能完成。

注意

排队引入客户端将大型数据集拆分为区块并聚合它们,如果在引入之前无法对数据进行批处理,则这非常有用。

成本优化

使用 Kusto 客户端库将数据引入群集仍是最便宜且最可靠的选项。 强烈建议客户查看其引入方法,以针对成本进行优化并利用 Azure 存储定价,该定价将使 blob 事务明显经济高效。

若要实现经济高效的引入:

  • 限制引入的数据区块数,例如文件、blob 和流。
  • 引入较大的区块(最多 1 GB 未压缩的数据)。
  • 选择使用批处理。
  • 提供确切的未压缩数据大小,以避免额外的存储事务。
  • 不要将 FlushImmediately 设置为 true
  • 避免使用 ingest-bydrop-by分片标记发送少量数据。

注意

过度使用最后两种方法可能会中断数据聚合,导致额外的存储事务,并损害引入和查询性能。