CREATE TABLE
AzureQueue совпадают с параметрами, поддерживаемыми движком таблицы AzureBlobStorage. См. раздел с параметрами здесь.
Как и в случае с движком таблицы AzureBlobStorage, для локальной разработки Azure Storage можно использовать эмулятор Azurite. Подробнее здесь.
Пример
Настройки
S3Queue, но без префикса s3queue_. См. полный список настроек.
Чтобы получить список настроек, заданных для таблицы, используйте таблицу system.azure_queue_settings. Доступно начиная с версии 24.10.
Ниже приведены настройки, которые поддерживаются только в AzureQueue и не применяются к S3Queue.
after_processing_move_connection_string
- String.
after_processing_move_container
- String.
SELECT из таблиц на движке таблицы AzureQueue
stream_like_engine_allow_direct_select в True.
У движка AzureQueue есть специальная настройка для запросов SELECT: commit_on_select. Установите для неё значение False, чтобы сохранить данные в очереди после чтения, или True, чтобы удалить их.
Описание
SELECT не особенно полезен для потокового импорта (кроме отладки), потому что каждый файл можно импортировать только один раз. Гораздо практичнее организовать обработку в реальном времени с помощью materialized views. Для этого:
- С помощью движка создайте таблицу для чтения из указанного пути в Azure Blob Storage и рассматривайте её как поток данных.
- Создайте таблицу с нужной структурой.
- Создайте materialized view, которое преобразует данные из движка и помещает их в ранее созданную таблицу.
MATERIALIZED VIEW к движку начинается фоновый сбор данных.
Аргументы движка имеют вид AzureQueue(connection_string, container_name, blobpath, format[, compression]).
Пример:
Виртуальные столбцы
_path— путь к файлу._file— имя файла.
Интроспекция
enable_logging_to_queue_log=1.
Возможности интроспекции такие же, как у движка таблицы S3Queue, однако есть несколько важных отличий:
- Используйте
system.azure_queue_metadata_cacheдля состояния очереди в памяти в версиях сервера >= 25.1. Для более старых версий используйтеsystem.s3queue_metadata_cache(он также содержит информацию о таблицахazure). - Используйте таблицу
system.azure_queue_metadata, чтобы напрямую проверить состояние, хранящееся в Keeper: количество узловprocessed,processingиfailedдля каждого объекта метаданных, а при необходимости — их содержимое. Это аналогsystem.s3_queue_metadataдляAzureQueue. - Включите
system.azure_queue_logчерез основную конфигурацию ClickHouse, например:
system.s3queue_metadata_cache, но для обработанных и файлов, обработка которых завершилась ошибкой.
Таблица имеет следующую структуру:
Ограничения
AzureQueue использует ту же реализацию, что и S3Queue, и имеет те же ограничения. В частности, сбой питания устройства, на котором работает узел ClickHouse, может незаметно привести к потере обработанных строк: файл помечается в Keeper как обработанный (а при after_processing = 'delete' также удаляется исходный blob) сразу после завершения вставки, однако вставленные строки надёжно сохраняются только после выполнения fsync целевой части, который по умолчанию не выполняется синхронно (fsync_after_insert = 0). Для рекомендуемого способа обработки через материализованное представление установка fsync_after_insert = 1 (и fsync_part_directory = 1) для целевой таблицы MergeTree существенно сокращает это окно.