跳转到主要内容
该引擎提供与 Azure Blob 存储 生态的集成,可实现流式数据导入。

创建表

引擎参数 AzureQueue 的参数与 AzureBlobStorage 表引擎支持的参数相同。请参阅此处的参数部分。 AzureBlobStorage 表引擎类似,用户可以使用 Azurite 模拟器在本地进行 Azure Storage 开发。更多详情请参阅此处 示例

设置

支持的设置基本与 S3Queue 表引擎相同,只是不带 s3queue_ 前缀。请参阅完整设置列表。 如需查看为该表配置的设置列表,请使用 system.azure_queue_settings 表。该功能自 24.10 起可用。 以下设置仅适用于 AzureQueue,不适用于 S3Queue。

after_processing_move_connection_string

如果目标端是另一个 Azure 容器,则用于将已成功处理的文件移动到该容器的 Azure Blob 存储连接字符串。 可能的值:
  • String。
默认值:空字符串。

after_processing_move_container

如果目标端是另一个 Azure 容器,则此参数指定成功处理后的文件要移动到的容器名称。 可能的值:
  • String。
默认值:空字符串。 示例:

对 AzureQueue 表引擎执行 SELECT

默认情况下,AzureQueue 表禁止执行 SELECT 查询。这遵循了常见的队列模式:数据读取一次后,就会从队列中移除。禁用 SELECT 是为了防止意外的数据丢失。 不过,在某些场景下,这样做也可能很有用。要启用此功能,需要将设置 stream_like_engine_allow_direct_select 设为 True。 AzureQueue 引擎还为 SELECT 查询提供了一个特殊设置:commit_on_select。将其设为 False 可在读取后保留队列中的数据,设为 True 则会将其移除。

描述

SELECT 对流式导入并不是特别有用 (调试除外) ,因为每个文件只能导入一次。更实用的做法是使用 materialized views 创建实时处理链路。为此:
  1. 使用该引擎创建一个表,用于从 Azure Blob 存储中的指定路径消费数据,并将其视为数据流。
  2. 创建一个具有所需结构的表。
  3. 创建一个 materialized view,将来自该引擎的数据转换后写入前面创建的表中。
MATERIALIZED VIEW 关联到该引擎时,它就会开始在后台收集数据。 该引擎的参数形式为 AzureQueue(connection_string, container_name, blobpath, format[, compression]) 示例:

虚拟列

  • _path — 文件路径。
  • _file — 文件名。
有关虚拟列的更多信息,见此处

内部信息

通过表设置 enable_logging_to_queue_log=1 为该表启用日志记录。 内部信息相关功能与 S3Queue 表引擎 相同,但有以下几个明显区别:
  1. 对于服务器版本 >= 25.1,使用 system.azure_queue_metadata_cache 作为队列的内存状态。对于更早的版本,使用 system.s3queue_metadata_cache (其中也会包含 azure 表的信息) 。
  2. 通过 ClickHouse 主配置启用 system.azure_queue_log,例如:
这个持久化表包含与 system.s3queue_metadata_cache 相同的信息,但对应的是已处理和处理失败的文件。 该表的结构如下:
示例:
最后修改于 2026年6月25日