Kusto 引入库的最佳做法
适用于：✅Azure 数据资源管理器
本文介绍使用 Kusto 引入库进行数据引入的最佳做法。
首选排队还不是直接引入
对于生产方案，请使用排队引入客户端。 有关详细信息，请参阅排队引入和直接引入。
使用单个引入客户端实例
Kusto 引入客户端实现是线程安全的，而且是可重用的。 对于每个目标数据库，每个进程使用已排队或直接引入客户端的单个实例。 运行多个实例可能会使数据库过载，导致数据库无响应或响应有效请求的速度变慢。
限制跟踪操作状态
对于大量数据流，请限制对引入请求使用积极通知。 过度跟踪可能会导致引入延迟增加，甚至完全无响应。 有关详细信息，请参阅操作状态。
优化吞吐量
规划引入管道时，请考虑以下因素，因为它们可能对引入吞吐量产生重大影响。
| 因子 | 说明 |
|---|---|
| 数据大小 | 在大型区块中操作时，引入效果更高。 建议批量发送 100 MB 到 1 GB 的数据（未压缩）。 |
| 数据格式 | 首选 CSV 或 PSV、TSV 等任何分隔文本格式，以及 Parquet、JSON 或 AVRO 等数据格式，这些格式经过优化，可实现最大吞吐量。 有关详细信息，请参阅引入支持的数据格式。 |
| 表宽度 | 只引入必要的数据。 需要对每一列进行编码和索引，这意味着表越宽，吞吐量可能越低。 通过提供引入映射来控制要引入哪些字段。 |
| 源数据位置 | 避免跨区域读取可加快引入速度。 |
| 在数据库上加载 | 当数据库遇到高查询负载时，引入需要更长的时间才能完成。 |
注意
排队引入客户端将大型数据集拆分为区块并聚合它们，如果在引入之前无法对数据进行批处理，则这非常有用。
成本优化
使用 Kusto 客户端库将数据引入数据库仍然是成本最低且最可靠的选项。 强烈建议客户查看其引入方法，以针对成本进行优化并利用 Azure 存储定价，该定价将使 blob 事务明显经济高效。
若要实现经济高效的引入：
- 限制引入的数据区块数，例如文件、blob 和流。
- 引入较大的区块（最多 1 GB 未压缩的数据）。
- 选择使用批处理。
- 提供确切的未压缩数据大小，以避免额外的存储事务。
- 不要将
FlushImmediately设置为true。 - 避免使用
ingest-by或drop-by盘区标记发送少量数据。
注意
过度使用最后两种方法可能会中断数据聚合，导致额外的存储事务，并损害引入和查询性能。