通过

连续数据导出概述

使用 “版本 ”下拉列表切换服务。 了解有关导航的详细信息。
适用于：✅ Azure Data Explorer

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

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

若要启用连续数据导出，创建外部表，然后创建指向外部表的连续导出定义。

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

权限

所有连续导出命令至少需要 Database Admin 权限。

连续导出准则

  • 输出架构：

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

  • 频率：

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

      注意

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

  • 文件数目：

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

  • External 表storage帐户：

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

导出恰好一次

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

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

“恰好一次”导出的保证仅适用于显示导出artifacts命令中报告的文件。 连续导出并不保证每条记录仅写入外部表一次。 如果在导出开始后发生故障，并且某些artifacts已写入外部表，则外部表可能包含重复项。 如果写入操作在完成之前被中止，则外部表可能包含已损坏的文件。 在这种情况下，不会从外部表中删除artifacts，但它们不会在 显示导出artifacts命令。 使用 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 天，则系统将自动禁用导出。 永久性错误包括：找不到外部表、连续导出查询的架构与外部表架构不匹配，storage帐户不可访问。 修复错误后，可以使用 .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")

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

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

  • 对导出数据的外部表使用 impersonation 身份验证。

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

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

重要

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

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

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

  1. 按照 创建外部增量表，并在 Azure Storage 上更改增量外部表。

    注意

    如果未提供架构，Kusto 将尝试在目标storage容器中定义增量表时自动推断该架构。
    增量表分区不受支持。

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

    重要

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

限制

常规：

  • 允许对目标表使用以下格式：CSV、TSV、JSON 和 Parquet。
  • 连续导出不能超过 材料化视图，因为具体化视图可能会更新，而导出到storage的数据始终追加，并且永远不会更新。
  • 无法对后继数据库创建连续导出，因为后继数据库是只读的，连续导出需要写入操作。
  • 必须使用“更新策略”或“从查询中引入”命令将源表中的记录直接引入到该表中。 如果使用 .move extents 或使用 .rename table 将记录移到表中，则连续导出可能不处理这些记录。 请参阅数据库游标页中所述的限制。
  • 如果连续导出使用的artifacts旨在触发事件网格通知，请参阅事件网格文档中的 known 问题部分。

跨数据库和跨群集：

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

策略：

相关内容

  • Last updated on