S3Queue 테이블 엔진

S3Queue 테이블 엔진

이 엔진은 Amazon S3 생태계와의 통합을 제공하고 스트리밍 가져오기를 허용해요. 이 엔진은 Kafka, RabbitMQ 엔진과 비슷하지만 S3 고유 기능을 제공해요.

S3Queue 구현의 원래 PR의 이 참고를 이해하는 것이 중요해요: MATERIALIZED VIEW가 엔진에 조인되면 S3Queue 테이블 엔진이 백그라운드에서 데이터 수집을 시작해요.

출처: 문서

본문

테이블 생성하기

CREATE TABLE s3_queue_engine_table (name String, value UInt32)
    ENGINE = S3Queue(path, [NOSIGN, | aws_access_key_id, aws_secret_access_key,] format, [compression], [headers], [extra_credentials])
    [SETTINGS]
    [mode = '',]
    [after_processing = 'keep',]
    [keeper_path = '',]
    [loading_retries = 10,]
    [processing_threads_num = 16,]
    [parallel_inserts = false,]
    [enable_logging_to_queue_log = true,]
    [last_processed_path = "",]
    [tracked_files_limit = 1000,]
    [tracked_file_ttl_sec = 0,]
    [polling_min_timeout_ms = 1000,]
    [polling_max_timeout_ms = 600000,]
    [polling_backoff_ms = 30000,]
    [cleanup_interval_min_ms = 60000,]
    [cleanup_interval_max_ms = 60000,]
    [buckets = 0,]
    [list_objects_batch_size = 1000,]
    [enable_hash_ring_filtering = 0,]
    [max_processed_files_before_commit = 100,]
    [max_processed_rows_before_commit = 0,]
    [max_processed_bytes_before_commit = 0,]
    [max_processing_time_sec_before_commit = 0,]

24.7 이전에는 mode, after_processing, keeper_path를 제외한 모든 설정에 s3queue_ 접두사를 사용해야 해요.

엔진 매개변수

S3Queue 매개변수는 S3 테이블 엔진이 지원하는 것과 같아요. 매개변수 섹션은 여기를 참고해요.

예시

CREATE TABLE s3queue_engine_table (name String, value UInt32)
ENGINE=S3Queue('https://clickhouse-public-datasets.s3.amazonaws.com/my-test-bucket-768/*', 'CSV', 'gzip')
SETTINGS
    mode = 'unordered';

named collections 사용:

<clickhouse>
    <named_collections>
        <s3queue_conf>
            <url>https://clickhouse-public-datasets.s3.amazonaws.com/my-test-bucket-768/*</url>
            <access_key_id>test</access_key_id>
            <secret_access_key>test</secret_access_key>
        </s3queue_conf>
    </named_collections>
</clickhouse>

CREATE TABLE s3queue_engine_table (name String, value UInt32)
ENGINE=S3Queue(s3queue_conf, format = 'CSV', compression_method = 'gzip')
SETTINGS
    mode = 'ordered';

설정

테이블에 대해 구성된 설정 목록을 얻으려면 system.s3_queue_settings 테이블을 사용해요. 24.10부터 사용 가능해요.

버전 24.7부터 S3Queue 설정은 s3queue_ 접두사가 있거나 없이 지정할 수 있어요.

• 현대 문법 (24.7+): processing_threads_num, tracked_file_ttl_sec 등
• 레거시 문법 (모든 버전): s3queue_processing_threads_num, s3queue_tracked_file_ttl_sec 등

두 형태 모두 24.7+에서 지원돼요. 이 페이지의 예시는 접두사가 없는 현대 문법을 사용해요.

Mode

가능한 값:

• unordered — unordered 모드에서 이미 처리된 파일들의 집합은 ZooKeeper의 영구 노드로 추적돼요
• ordered — ordered 모드에서 파일은 사전순으로 처리돼요. 즉, 'BBB'라는 파일이 어느 시점에 처리되었고 나중에 'AA'라는 파일이 버킷에 추가되면 무시된다는 뜻이에요. 성공적으로 소비된 파일의 최대 이름(사전순 의미)과 로딩 시도 실패 후 재시도될 파일의 이름만 ZooKeeper에 저장돼요
• exclusive - exclusive 모드에서는 Zookeeper에서 아무것도 추적되지 않아요. S3 url(S3Queue()의 첫 인자) 반드시 고유한 호스트나 경로로 해석되어야 해요. 이 모드는 높은 처리량 및/또는 자체 호스팅 시나리오에만 유용해요

기본값: 24.6 이전 버전에서 ordered. 24.6부터 기본값이 없고 설정을 수동으로 지정해야 해요. 이전 버전에서 만든 테이블의 경우 호환성을 위해 기본값은 Ordered로 유지돼요. exclusive 모드를 사용할 때 S3 url에서 {replica} 매크로 사용이 지원돼요.

after_processing

성공적으로 처리된 후 파일을 어떻게 다룰지. 가능한 값:

• keep
• delete
• move
• tag

기본값: keep. Move는 추가 설정이 필요해요. 같은 버킷 내 이동의 경우 새 경로 접두사를 after_processing_move_prefix로 제공해야 해요. 다른 S3 버킷으로 이동하려면 대상 버킷 URI를 after_processing_move_uri로, S3 자격 증명을 after_processing_move_access_key_id와 after_processing_move_secret_access_key로 제공해야 해요.

예시:

CREATE TABLE s3queue_engine_table (name String, value UInt32)
ENGINE=S3Queue('https://clickhouse-public-datasets.s3.amazonaws.com/my-test-bucket-768/*', 'CSV', 'gzip')
SETTINGS
    mode = 'unordered',
    after_processing = 'move',
    after_processing_retries = 20,
    after_processing_move_prefix = 'dst_prefix',
    after_processing_move_uri = 'https://clickhouse-public-datasets.s3.amazonaws.com/dst-bucket',
    after_processing_move_access_key_id = 'test',
    after_processing_move_secret_access_key = 'test';

Azure 컨테이너에서 다른 Azure 컨테이너로 이동하려면 Blob Storage 연결 문자열을 after_processing_move_connection_string으로, 컨테이너 이름을 after_processing_move_container로 제공해야 해요. AzureQueue 설정 참고.

태깅은 태그 키와 값을 after_processing_tag_key와 after_processing_tag_value로 제공해야 해요.

after_processing_retries

요청된 후처리(action)를 위한 재시도 횟수, 그 후에는 포기해요.

가능한 값:

• 음이 아닌 정수

기본값: 10.

after_processing_move_access_key_id

대상이 다른 S3 버킷인 경우 성공적으로 처리된 파일을 이동할 S3 버킷의 Access Key ID.

가능한 값:

• String

기본값: 빈 문자열.

after_processing_move_prefix

성공적으로 처리된 파일을 이동할 경로 접두사. 같은 버킷 내 이동과 다른 버킷으로 이동 둘 다에 적용돼요.

가능한 값:

• String

기본값: 빈 문자열.

after_processing_move_preserve_path

true면 성공적으로 처리된 파일을 이동할 때 전체 소스 객체 경로가 after_processing_move_prefix에 추가돼서 버킷 아래의 소스 디렉터리 구조가 대상에 보존돼요. false면 파일 이름만 사용되고 소스 디렉터리 구조는 평면화돼요.

가능한 값:

• true / false

기본값: false.

after_processing_move_secret_access_key

대상이 다른 S3 버킷인 경우 성공적으로 처리된 파일을 이동할 S3 버킷의 Secret Access Key.

가능한 값:

• String

기본값: 빈 문자열.

after_processing_move_uri

대상이 다른 S3 버킷인 경우 성공적으로 처리된 파일을 이동할 S3 버킷의 URI.

가능한 값:

• String

기본값: 빈 문자열.

after_processing_tag_key

after_processing='tag'면 성공적으로 처리된 파일에 태깅을 위한 태그 키.

가능한 값:

• String

기본값: 빈 문자열.

after_processing_tag_value

after_processing='tag'면 성공적으로 처리된 파일에 태깅을 위한 태그 값.

가능한 값:

• String

기본값: 빈 문자열.

keeper_path

ZooKeeper에서 큐 메타데이터의 경로. 명시적으로 지정하지 않으면 ClickHouse는 s3queue_default_zookeeper_path, 데이터베이스 UUID, 테이블 UUID에서 경로를 만든다. 절대 값(/로 시작)은 제공된 대로 사용되고, 상대 값은 구성된 접두사에 추가돼요. {database}나 {uuid} 같은 매크로는 엔진이 ZooKeeper에 연결하기 전에 확장돼요.

보조 ZooKeeper 클러스터를 대상으로 하려면 값을 구성된 이름으로 접두사를 붙여요. 예: analytics_keeper:/clickhouse/queue/orders. 이름은 <auxiliary_zookeepers>에 존재해야 해요. 그렇지 않으면 엔진이 Unknown auxiliary ZooKeeper name ...을 보고해요. 전체 문자열(접두사 포함)은 문을 그대로 복제할 수 있도록 SHOW CREATE TABLE에 보존돼요.

가능한 값:

• String

기본값: /.

loading_retries

지정된 횟수만큼 파일 로딩을 재시도해요.

가능한 값:

• 음이 아닌 정수

기본값: 10.

processing_threads_num

처리를 수행할 스레드 수. Unordered 또는 Exclusive 모드에만 적용돼요.

기본값: CPU 수 또는 16.

parallel_inserts

기본적으로 processing_threads_num은 하나의 INSERT를 만들므로 파일을 다운로드하고 여러 스레드에서 파싱만 해요. 그러나 이것은 병렬성을 제한하므로 더 나은 처리량을 위해 parallel_inserts=true를 사용해요. 이러면 데이터를 병렬로 삽입할 수 있어요 (단, MergeTree 패밀리에 대해 생성되는 데이터 파트 수가 더 많아진다는 점을 명심해요). INSERT는 max_process*_before_commit 설정을 존중하며 생성돼요.

기본값: false.

enable_logging_to_queue_log

system.s3queue_log에 로깅을 활성화해요.

기본값: 1.

polling_min_timeout_ms

ClickHouse가 다음 폴링 시도를 하기 전에 기다리는 최소 시간(밀리초)을 지정해요.

가능한 값:

• 양의 정수

기본값: 1000.

polling_max_timeout_ms

ClickHouse가 다음 폴링 시도를 시작하기 전에 기다리는 최대 시간(밀리초)을 정의해요.

가능한 값:

• 양의 정수

기본값: 600000.

polling_backoff_ms

새 파일이 없을 때 이전 폴링 간격에 추가되는 추가 대기 시간을 결정해요. 다음 폴링은 이전 간격과 이 backoff 값의 합 또는 최대 간격 중 더 낮은 값 후에 발생해요.

가능한 값:

• 양의 정수

기본값: 30000.

tracked_files_limit

'unordered' 모드를 사용하면 Zookeeper 노드 수를 제한할 수 있고, 'ordered'나 'exclusive' 모드에서는 아무것도 하지 않아요. 한도에 도달하면 가장 오래된 처리된 파일이 ZooKeeper 노드에서 삭제되고 다시 처리돼요.

가능한 값:

• 양의 정수

기본값: 1000.

tracked_file_ttl_sec

'unordered' 모드에서 처리된 파일을 ZooKeeper 노드에 저장하는 최대 초 수 (기본적으로 영원히 저장). 'ordered'나 'exclusive' 모드에서는 아무것도 하지 않아요. 지정된 초 수 후 파일은 다시 가져와져요.

가능한 값:

• 양의 정수

기본값: 0.

cleanup_interval_min_ms

'Ordered' 모드용. 추적된 파일 TTL과 최대 추적 파일 집합을 유지하는 백그라운드 작업의 재스케줄 간격의 최소 경계를 정의해요.

기본값: 60000.

cleanup_interval_max_ms

'Ordered' 모드용. 추적된 파일 TTL과 최대 추적 파일 집합을 유지하는 백그라운드 작업의 재스케줄 간격의 최대 경계를 정의해요.

기본값: 60000.

buckets

'Ordered' 모드용. 24.6부터 사용 가능. S3Queue 테이블의 여러 복제본이 있고 각각 keeper의 같은 메타데이터 디렉터리로 작업한다면 buckets 값은 최소 복제본 수와 같아야 해요. processing_threads 설정도 사용하면 buckets 설정의 값을 더 늘리는 것이 합리적인데, S3Queue 처리의 실제 병렬성을 정의하기 때문이에요.

use_persistent_processing_nodes

영구 처리 노드는 처리가 시작된 후 S3Queue가 처리된 파일을 커밋하기 전에 keeper 세션이 만료될 때 중복 가능성을 제거해요. 이전 버전은 임시 처리 노드를 사용했는데 이 경우 중복을 만들 수 있었어요.

이 설정은 더 이상 사용되지 않으며 그 값은 무시돼요: 영구 처리 노드가 항상 사용돼요. use_persistent_processing_nodes = 0으로 만든 테이블도 여전히 그것을 사용하고, SHOW CREATE TABLE을 포함한 설정 인트로스펙션은 제공된 값과 관계없이 1을 보고해요.

persistent_processing_node_ttl_seconds

비정상적인 서버 종료의 경우 제거되지 않은 처리 노드가 있을 수 있어요. 이 설정은 이 처리 노드들이 안전하게 정리될 수 있는 기간을 정의해요. 같은 TTL은 Ordered 모드의 버킷 잠금에도 사용되는데, 이는 단일 처리 노드보다 오래 보유될 수 있으므로 값은 그것도 고려해야 해요.

기본값: 21600 (6시간).

processing_state_cache_ttl_seconds

keeper의 processing 노드가 다른 서버에 의해 보유된 파일은 인메모리 파일 상태 캐시에 Processing으로 기억되므로 다음 목록이 keeper에 다시 묻지 않고 그것을 건너뛰어요.

Processed와 Failed와 달리 이 상태는 최종적이지 않아요: 다른 프로세서가 커밋하지 않고 파일을 해제할 수 있어요(예: 그 프로세서가 죽은 경우). 이 설정은 캐시된 Processing 상태를 얼마나 오래 신뢰할지 정의해요. 그 후에는 파일이 keeper에서 다시 확인되고 다시 자유로우면 처리돼요. 0은 항상 keeper를 다시 확인한다는 뜻이에요.

기본값: 300 (5분).

S3 관련 설정

엔진은 모든 s3 관련 설정을 지원해요. S3 설정에 대한 자세한 내용은 여기를 참고해요.

S3 역할 기반 접근

s3Queue 테이블 엔진은 역할 기반 접근을 지원해요. 버킷에 접근할 역할을 구성하는 단계는 여기 문서를 참고해요. 역할이 구성되면 아래처럼 extra_credentials 매개변수로 roleARN을 전달할 수 있어요.

CREATE TABLE s3_table
(
    ts DateTime,
    value UInt64
)
ENGINE = S3Queue(
                'https://<your_bucket>/*.csv',
                extra_credentials(role_arn = 'arn:aws:iam::111111111111:role/<your_role>')
                ,'CSV')
SETTINGS
    ...

S3Queue ordered 모드

S3Queue ordered 처리 모드는 ZooKeeper에 더 적은 메타데이터를 저장할 수 있지만, 시간상 나중에 추가된 파일은 영숫자(alphanumeric)로 더 큰 이름을 가져야 한다는 제한이 있어요.

S3Queue ordered 모드는 unordered와 마찬가지로 (s3queue_)processing_threads_num 설정(s3queue_ 접두사 선택)을 지원하며, 이는 서버에서 로컬로 S3 파일 처리를 수행할 스레드 수를 제어할 수 있게 해줘요.

파티셔닝 없는 ordered 모드에서 ClickHouse는 전체 접두사 기록을 다시 나열하지 않기 위해 마지막 처리된 키에서 S3 목록을 재개할 수 있어요. 버킷화된 ordered 모드에서 재개 지점은 처리되지 않은 파일을 건너뛰지 않기 위해 모든 버킷에 걸친 가장 작은 처리 키로 보수적으로 선택돼요.

이 재개-목록 재개 최적화는 파티셔닝 없는 ordered 모드의 S3 지원 큐에만 사용돼요 (AzureQueue나 partitioning_mode가 설정된 경우에는 아님).

또한 ordered 모드는 (s3queue_)buckets라는 또 다른 설정도 도입하는데, 이것은 "논리적 스레드"를 의미해요. 분산 시나리오에서 S3Queue 테이블 복제본이 있는 여러 서버가 있을 때, 이 설정은 처리 단위의 수를 정의해요. 예를 들어 각 S3Queue 복제본의 각 처리 스레드는 처리를 위해 특정 bucket을 잠그려 시도하고, 각 bucket은 파일 이름의 해시로 특정 파일에 귀속돼요. 따라서 분산 시나리오에서는 (s3queue_)buckets 설정이 최소한 복제본 수와 같거나 더 크게 하는 것이 매우 권장돼요. 버킷 수가 복제본 수보다 많은 것은 괜찮아요. 가장 최적의 시나리오는 (s3queue_)buckets 설정이 number_of_replicas와 (s3queue_)processing_threads_num의 곱과 같게 하는 것이에요.

(s3queue_)processing_threads_num 설정은 버전 24.6 이전에는 사용을 권장하지 않아요. (s3queue_)buckets 설정은 버전 24.6부터 사용할 수 있어요.

S3Queue 테이블 엔진에서 SELECT

S3Queue 테이블에서는 기본적으로 SELECT 쿼리가 금지돼요. 이것은 데이터가 한 번 읽힌 다음 큐에서 제거되는 일반적인 큐 패턴을 따르기 때문이에요. SELECT는 우발적인 데이터 손실을 막기 위해 금지돼요.

그러나 때때로 유용할 수 있어요. 그러려면 stream_like_engine_allow_direct_select 설정을 True로 설정해야 해요. S3Queue 엔진은 SELECT 쿼리를 위한 특별한 설정이 있어요: commit_on_select. 읽은 후에도 데이터를 큐에 보존하려면 False로, 제거하려면 True로 설정해요. (참고: 이 설정은 exclusive 모드에서 의미가 없고 무시돼요. exclusive 모드는 항상 commit_on_select가 True인 것처럼 동작해요.)

설명

SELECT는 (디버깅 외에는) 스트리밍 가져오기에 특히 유용하지 않아요. 각 파일은 한 번만 가져올 수 있기 때문이에요. materialized views를 사용해 실시간 스레드를 만드는 것이 더 실용적이에요. 그러려면:

• 엔진을 사용해 S3의 지정된 경로에서 소비하는 테이블을 만들고 그것을 데이터 스트림으로 간주해요
• 원하는 구조로 테이블을 만들어요
• 엔진의 데이터를 변환해 앞서 만든 테이블에 넣는 materialized view를 만들어요

MATERIALIZED VIEW가 엔진에 조인되면 백그라운드에서 데이터 수집을 시작해요.

예시:

CREATE TABLE s3queue_engine_table (name String, value UInt32)
    ENGINE=S3Queue('https://clickhouse-public-datasets.s3.amazonaws.com/my-test-bucket-768/*', 'CSV', 'gzip')
    SETTINGS
        mode = 'unordered';

CREATE TABLE stats (name String, value UInt32)
    ENGINE = MergeTree() ORDER BY name;

CREATE MATERIALIZED VIEW consumer TO stats
    AS SELECT name, value FROM s3queue_engine_table;

  SELECT * FROM stats ORDER BY name;

가상 컬럼

• _path — 파일 경로
• _file — 파일 이름
• _size — 파일 크기
• _time — 파일 생성 시간

가상 컬럼에 대한 자세한 내용은 여기를 참고해요.

경로의 와일드카드

path 인자는 bash 스타일 와일드카드를 사용해 여러 파일을 지정할 수 있어요. 처리되는 파일은 존재해야 하고 전체 경로 패턴과 일치해야 해요. 파일 목록은 (CREATE 시점이 아닌) SELECT 중에 결정돼요.

• * — /를 제외한 어떤 수의 문자(빈 문자열 포함)를 대체해요
• ** — /를 포함한 어떤 수의 문자(빈 문자열 포함)를 대체해요
• ? — 단일 문자를 대체해요
• {some_string,another_string,yet_another_one} — 문자열 'some_string', 'another_string', 'yet_another_one' 중 하나를 대체해요
• {N..M} — N에서 M까지(양쪽 경계 포함)의 어떤 수를 대체해요. N과 M은 앞에 0을 가질 수 있어요. 예: 000..078

{}가 있는 구조는 remote 테이블 함수와 비슷해요.

제한 사항

• 다음 결과로 중복 행이 발생할 수 있어요:
  • 파일 처리 중간에 파싱 중 예외가 발생하고 s3queue_loading_retries로 재시도가 활성화된 경우
  • S3Queue가 zookeeper의 같은 경로를 가리키는 여러 서버에 구성되어 있고, 한 서버가 처리된 파일을 커밋하기 전에 keeper 세션이 만료되어 다른 서버가 그 파일의 처리를 맡을 수 있는 경우. 그러나 이것은 버전 25.8부터 사용 가능하고 이제 항상 사용되는 영구 처리 노드(use_persistent_processing_nodes 참고)에 의해 방지돼요
  • 비정상적인 서버 종료
• S3Queue가 zookeeper의 같은 경로를 가리키는 여러 서버에 구성되어 있고 Ordered 모드를 사용하면 s3queue_loading_retries가 동작하지 않아요. 조만간 수정될 거예요
• ClickHouse 노드의 장치 수준 전원 손실로 인한 행 손실. 소비된 파일은 삽입이 끝나자마자 Keeper에서 처리된 것으로 기록되고 (그리고 after_processing = 'delete'이면 소스 객체가 제거) 되지만, 삽입된 행은 대상 파트가 fsync된 후에만 내구성이 생기는데, 기본적으로 동기적으로 발생하지 않아요 (fsync_after_insert = 0). Keeper는 강제 동기화되고 보통 별도의 노드에서 실행되므로 이 노드의 전원 손실을 견뎌요. 노드가 파일이 처리된 것으로 커밋된 후 대상 파트가 fsync되기 전에 전원을 잃으면 그 파일은 재시작 시 다시 읽히지 않고 그 행은 손실돼요 (after_processing = 'delete'에서는 복구 불가). 일반적인 프로세스 종료는 페이지 캐시가 이를 견디므로 드러나지 않아요. 권장하는 materialized-view 소비 경로(파일은 전체 삽입 파이프라인이 끝난 뒤에만 커밋)에서는 대상 MergeTree 테이블에 fsync_after_insert = 1(그리고 fsync_part_directory = 1)을 설정하면 삽입된 파트가 파일이 처리된 것으로 커밋되기 전에 내구성이 생겨 이 창이 크게 좁아져요. 이것은 commit_on_select = 1을 사용한 직접 INSERT ... SELECT에는 적용되지 않아요. 이 경우 파일은 대상 싱크가 마지막 파트를 마무리하기 전에 읽기 끝에서 커밋되기 때문이에요

인트로스펙션

인트로스펙션에는 system.s3queue_metadata_cache와 system.s3_queue_metadata 상태 비저장 테이블과 system.s3queue_log 영구 테이블을 사용해요.

• system.s3queue_metadata_cache를 사용해 로컬 서버의 per-file 처리 상태(현재 처리 중, 처리됨 또는 실패한 파일)의 인메모리 캐시를 조사해요
• system.s3_queue_metadata를 사용해 keeper에 직접 저장된 상태를 조사해요: 메타데이터 객체당 processed, processing, failed 노드 수와, 필요시 그 내용. 이것은 인메모리 캐시가 (아직) keeper를 반영하지 않을 때나 클러스터 전체의 공유 상태를 볼 때 유용해요
• system.s3queue_log를 processed와 failed 파일의 영구 기록에 사용해요
• system.s3queue_metadata_cache. 이 테이블은 영구적이지 않고 S3Queue의 인메모리 상태를 보여줘요: 현재 처리 중인 파일, 처리된 또는 실패한 파일

┌─statement──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE system.s3queue_metadata_cache
(
    `database` String,
    `table` String,
    `file_name` String,
    `rows_processed` UInt64,
    `status` String,
    `processing_start_time` Nullable(DateTime),
    `processing_end_time` Nullable(DateTime),
    `ProfileEvents` Map(String, UInt64)
    `exception` String
)
ENGINE = SystemS3Queue
COMMENT 'Contains in-memory state of S3Queue metadata and currently processed rows per file.' │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

예시:

SELECT *
FROM system.s3queue_metadata_cache

Row 1:
──────
zookeeper_path:        /clickhouse/s3queue/25ea5621-ae8c-40c7-96d0-cec959c5ab88/3b3f66a1-9866-4c2e-ba78-b6bfa154207e
file_name:             wikistat/original/pageviews-20150501-030000.gz
rows_processed:        5068534
status:                Processed
processing_start_time: 2023-10-13 13:09:48
processing_end_time:   2023-10-13 13:10:31
ProfileEvents:         {'ZooKeeperTransactions':3,'ZooKeeperGet':2,'ZooKeeperMulti':1,'SelectedRows':5068534,'SelectedBytes':198132283,'ContextLock':1,'S3QueueSetFileProcessingMicroseconds':2480,'S3QueueSetFileProcessedMicroseconds':9985,'S3QueuePullMicroseconds':273776,'LogTest':17}
exception:

• system.s3_queue_metadata. 이 테이블은 영구적이지 않고 keeper에서 직접 상태를 읽어요: 메타데이터 객체당 processed, processing, failed 노드 수, 그리고 필요시 그 내용.

processed_nodes, processing_nodes, failed_nodes, processed_path 컬럼은 keeper 요청을 발행하고 해당 컬럼이 선택될 때만 가져와져요. 따라서 *_nodes_count 카운터만 선택하면 추가 keeper 트래픽을 피할 수 있어요.

SELECT zookeeper_path, processed_nodes_count, processing_nodes_count, failed_nodes_count
FROM system.s3_queue_metadata

Row 1:
──────
zookeeper_path:         /clickhouse/s3queue/25ea5621-ae8c-40c7-96d0-cec959c5ab88/3b3f66a1-9866-4c2e-ba78-b6bfa154207e
processed_nodes_count:  128
processing_nodes_count: 2
failed_nodes_count:     0

전체 컬럼 목록은 system.s3_queue_metadata 참조 페이지를 보세요.

• system.s3queue_log. 영구 테이블. system.s3queue_metadata_cache와 같은 정보를 가지고 있지만 processed와 failed 파일에 대한 것이에요.

테이블은 다음 구조를 가져요.

SHOW CREATE TABLE system.s3queue_log

Query id: 0ad619c3-0f2a-4ee4-8b40-c73d86e04314

┌─statement──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE system.s3queue_log
(
    `event_date` Date,
    `event_time` DateTime,
    `table_uuid` String,
    `file_name` String,
    `rows_processed` UInt64,
    `status` Enum8('Processed' = 0, 'Failed' = 1),
    `processing_start_time` Nullable(DateTime),
    `processing_end_time` Nullable(DateTime),
    `ProfileEvents` Map(String, UInt64),
    `exception` String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, event_time) │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

system.s3queue_log를 사용하려면 서버 구성 파일에 그 구성을 정의해요.

    <s3queue_log>
        <database>system</database>
        <table>s3queue_log</table>
    </s3queue_log>

예시:

SELECT *
FROM system.s3queue_log

Row 1:
──────
event_date:            2023-10-13
event_time:            2023-10-13 13:10:12
table_uuid:
file_name:             wikistat/original/pageviews-20150501-020000.gz
rows_processed:        5112621
status:                Processed
processing_start_time: 2023-10-13 13:09:48
processing_end_time:   2023-10-13 13:10:12
ProfileEvents:         {'ZooKeeperTransactions':3,'ZooKeeperGet':2,'ZooKeeperMulti':1,'SelectedRows':5112621,'SelectedBytes':198577687,'ContextLock':1,'S3QueueSetFileProcessingMicroseconds':1934,'S3QueueSetFileProcessedMicroseconds':17063,'S3QueuePullMicroseconds':5841972,'LogTest':17}
exception:

더 알아보기 (Learn more)

• materialized view
• system.s3queue_metadata_cache
• system.s3queue_log