Kusto 引入客户端库

Microsoft.Azure.Kusto.Ingest 库是一个 .NET 4.7.2 库,用于将数据引入到 Azure 数据资源管理器服务。 它依赖于以下库和 SDK:

引入方法通过 IKustoIngestClient 接口定义。 这些方法可以同时采用同步和异步模式处理来自流、IDataReader、本地文件和 Azure blob 的数据引入。

引入客户端风格

引入客户端有两种基本风格:排队引入和直接引入。

排队引入

排队引入模式由 IKustoQueuedIngestClient 定义,它限制了客户端代码对 Kusto 服务的依赖性。 通过将 Kusto 引入消息发布到 Azure 队列来完成引入,然后从 Kusto 数据管理(引入)服务获取该消息。 任何中间存储项都将由引入客户端使用来自 Kusto 数据管理服务的资源创建。

排队模式的优点包括:

  • 将数据引入过程与 Kusto 引擎服务分离
  • 能够在 Kusto 引擎(或引入)服务不可用时持久保存引入请求
  • 借助引入服务对入站数据进行高效且可控的聚合,从而提高性能
  • 允许 Kusto 引入服务管理 Kusto 引擎服务上的引入负载
  • 根据需要,在出现暂时性引入失败(例如因为 Azure 存储限制而导致的失败)时重试 Kusto 引入服务
  • 提供了一种方便的机制来跟踪每个引入请求的进度和结果

下面的关系图概述了排队引入客户端与 Kusto 的交互:

Diagram showing how the Kusto.Ingest library sends queries to the Kusto service in queried ingestion mode.

直接引入

由 IKustoDirectIngestClient 定义的直接引入模式强制与 Kusto 引擎服务进行直接交互。 在此模式下,Kusto 引入服务不会限制或管理数据。 每个引入请求最终都转换为直接在 Kusto 引擎服务上执行的 .ingest 命令。

下面的关系图概述了直接引入客户端与 Kusto 的交互:

Diagram showing how the Kusto.Ingest library sends queries to the Kusto service in direct ingestion mode.

注意

建议不要将直接模式用于生产级引入解决方案。

直接模式的优点包括:

  • 低延迟且无聚合。 不过,使用排队引入时也可以实现低延迟
  • 使用同步方法时,方法完成即表示引入操作结束

直接模式的缺点包括:

  • 客户端代码必须实现任何重试或错误处理逻辑
  • 当 Kusto 引擎服务不可用时,无法进行引入
  • 客户端代码可能会大量向 Kusto 引擎服务发送引入请求,因为它不知道引擎服务容量

引入最佳做法

引入最佳做法提供了有关引入的 COGS(所售货物成本)和吞吐量 POV。

  • 线程安全性 - Kusto 引入客户端实现是线程安全的,可以重复使用。 无需为单个或多个引入操作创建 KustoQueuedIngestClient 类的实例。 每个目标 Kusto 群集的每个用户进程需要 KustoQueuedIngestClient 的单个实例。 运行多个实例会适得其反,可能会导致数据管理群集上出现 DoS。

  • 支持的数据格式 - 使用原生引入时,如果其尚未存在,请将数据上传到一个或多个 Azure 存储 blob。 目前支持的 blob 格式都记录在受支持的数据格式中。

  • 架构映射 -架构映射有助于确定性地将源数据字段绑定到目标表列。

  • 引入权限 -Kusto 引入权限解释了使用 Kusto.Ingest 包成功进行引入所需的权限设置。

  • 用法 - 如前所述,建议用于 Kusto 的可持续大规模引入解决方案的基础应该是 KustoQueuedIngestClient。 为了最大限度地减少 Kusto 服务上的不必要负载,建议你为每个 Kusto 群集的每个进程使用 Kusto 引入客户端(排队引入或直接引入)的单个实例。 Kusto 引入客户端实现是线程安全的,并且是完全可重入的。

后续步骤