通过

连续数据导出概述

  • 项目

适用于：✅Azure 数据资源管理器

本文介绍了如何使用定期运行的查询，将 Kusto 中的数据连续导出到外部表。 结果会存储在外部表中，该表定义了导出的数据的目标（例如 Azure Blob 存储）和架构。 此过程确保所有记录都导出“恰好一次”，但有一些例外。

默认情况下，连续导出在分布式模式下运行，其中所有节点都并发导出，因此项目的数量取决于节点的数量。 连续导出不适用于低延迟流式处理数据。

若要启用连续数据导出，请创建一个外部表，然后创建连续导出定义并将其指向该外部表。

在某些情况下，必须使用托管标识来成功配置连续导出作业。 有关详细信息，请参阅使用托管标识运行连续导出作业。

权限

所有连续导出命令都至少需要数据库管理员权限。

连续导出准则

  • 输出架构：

    • 导出查询的输出架构必须与要导出到的外部表的架构匹配。

  • 频率：

    • 连续导出将根据在 intervalBetweenRuns 属性中为其配置的时间段运行。 此间隔的建议值至少为几分钟，具体取决于你愿意接受的延迟时间。 如果引入速率较高，则时间间隔最小可为一分钟。

      注意

      intervalBetweenRuns 仅作为建议，并不能保证是准确的。 连续导出不适用于导出定期聚合。 例如，使用每小时聚合 (T | summarize by bin(Timestamp, 1h)) 的 intervalBetweenRuns=1h 的配置将无法按预期工作，因为连续导出不会完全按小时运行。 因此，每小时箱都将收到导出数据中的多个条目。

  • 文件数目：

    • 每个连续导出迭代中导出的文件数取决于外部表的分区情况。 有关详细信息，请参阅导出到外部表命令。 每个连续导出迭代始终会写入到新文件中，永远不会附加到现有文件中。 因此，导出的文件的数目也取决于连续导出的运行频率。 频率参数为 intervalBetweenRuns。

  • 外部表存储帐户：

    • 为了获得最佳性能，数据库和存储帐户应并置在同一 Azure 区域中。
    • 连续导出以分布式方式工作，因此所有节点都并发导出。 在大型数据库上，如果导出的数据量很大，这可能会导致存储限制。 建议为外部表配置多个存储帐户。 有关更多详细信息，请参阅在执行 export 命令期间发生存储故障。

导出恰好一次

为了保证导出“恰好一次”，连续导出使用数据库游标。 连续导出查询不应包含时间戳筛选器 - 数据库游标机制可确保不会多次处理记录。 在查询中添加时间戳筛选器可能会导致导出的数据中缺少数据。

必须在所有已在查询中引用且应当在导出中处理“恰好一次”的表上启用 IngestionTime 策略。 此策略默认在所有新创建的表上启用。

导出“恰好一次”的保证仅适用于显示导出的项目命令中报告的文件。 连续导出并不保证仅将每个记录向外部表中写入一次。 如果在开始导出后发生故障，并且某些项目已被写入到外部表，则外部表可能包含重复项。 如果写入操作在完成之前被中止，则外部表可能包含已损坏的文件。 在这种情况下，不会从外部表中删除这些项目，但也不会在显示导出的项目命令中报告这些项目。 通过 show exported artifacts command 使用导出的文件可保证无重复且无损坏。

从事实数据表和维度表导出

默认情况下，会假定导出查询中引用的所有表都是事实数据表。 因此，它们的作用域限定于数据库游标。 此语法显式声明哪些表具有作用域（事实数据表）以及哪些表没有作用域（维度表）。 有关详细信息，请参阅over中的 over 参数。

导出查询仅包含自上一次执行导出后联接的记录。 导出查询可能包含维度表，维度表的所有记录都包括在所有导出查询中。 在连续导出中，当在事实数据表与维度表之间使用联接时，请记住，事实数据表中的记录仅处理一次。 如果在维度表中的记录缺少某些键的情况下运行导出，则相应键的记录会丢失，或者会在导出的文件中包含维度列的 null 值。 是返回缺少的记录还是返回 null 记录取决于查询使用的是内部联接还是外部联接。 如果对于匹配的记录，事实数据表和维度表是在同一时间引入的，则在这种情况下，连续导出定义中的 forcedLatency 属性可能很有用。

注意

不支持连续导出纯维度表。 导出查询必须包含至少一个事实数据表。

监视连续导出

使用以下导出指标监视连续导出作业的运行状况：

  • Continuous export max lateness - 数据库中连续导出的最大延迟（以分钟为单位）。 这是从现在到数据库中所有连续导出作业的最短 ExportedTo 时间之间的时间。 有关详细信息，请参阅 .show continuous export 命令。
  • Continuous export result - 每个连续导出执行的失败/成功结果。 此指标可以按连续导出名称拆分。

使用 .show continuous export failures 命令查看连续导出作业的特定故障。

警告

如果连续导出由于永久性故障而失败超过 7 天，则系统将自动禁用导出。 永久性错误包括：找不到外部表、连续导出查询架构与外部表架构不匹配、存储帐户不可访问。 修复错误后，可以使用 .enable continuous export 命令重新启用连续导出。

资源消耗

  • 连续导出对数据库的影响取决于连续导出正在运行的查询。 大多数资源（例如 CPU 和内存）都由查询执行操作使用。
  • 可以并发运行的导出操作数受数据库的数据导出容量限制。 有关详细信息，请参阅管理命令限制。 如果数据库没有足够的容量来处理所有连续导出，则有些连续导出将开始滞后。
  • 可以使用 show commands-and-queries 命令来估计资源消耗情况。
    • 根据 | where ClientActivityId startswith "RunContinuousExports" 进行筛选，查看与连续导出关联的命令和查询。

导出历史数据

连续导出只从其创建时间点开始导出数据。 在该时间之前引入的记录应该使用非连续导出命令单独导出。 历史数据可能太大，无法在单个导出命令中导出。 如果需要，请将查询分成几个较小的批。

为了避免与连续导出所导出的数据重复，请使用由StartCursor返回的 StartCursor，仅导出 where cursor_before_or_at 该游标值的记录。 例如：

.show continuous-export MyExport | project StartCursor
StartCursor
636751928823156645

后面是：

.export async to table ExternalBlob
<| T | where cursor_before_or_at("636751928823156645")

从具有行级别安全性的表连续导出

若要使用某个引用具有行级别安全性策略的表的查询来创建连续导出作业，你必须：

向增量表的连续导出 - 预览版

“向增量表的连续导出”目前以预览版提供。

重要

连续数据导出不支持增量表分区。

如果增量协议编写器版本高于 1，Kusto 不会写入现有增量表。

若要定义向增量表的连续导出，请执行以下步骤：

  1. 如在 Azure 存储上创建和更改增量外部表中所述，创建外部增量表。

    注意

    如果未提供架构，Kusto 将尝试在目标存储容器中已经定义了一个增量表的情况下自动推断它。
    增量表分区不受支持。

  2. 使用创建或更改连续导出中所述的命令，定义向此表的连续导出。

    重要

    增量表的架构必须与连续导出查询同步。 如果基础增量表发生更改，导出可能会开始失败并出现意外行为。

限制

常规：

跨数据库和跨群集：

  • 连续导出不支持跨群集调用。
  • 连续导出仅支持对维度表进行跨数据库调用。 所有事实数据表都必须驻留在本地数据库中。 有关更多详细信息，请参阅从事实数据表和维度表导出
  • 如果连续导出包括跨数据库调用，则必须使用托管标识进行配置。

策略：

相关内容