데이터 분석 환경 구축 - 08. Clickhouse 클러스터 환경에서 데이터 삽입 및 업데이트 처리 방식 🚀(part. 2)

이전 clickhouse 클러스터 환경에서 데이터 처리 방식(Clickhouse 클러스터 환경에서 데이터 삽입 및 업데이트 처리 방식 🚀(part. 1)) 설명에 이어 ReplicatedMergetree 테이블에서 데이터가 처리되는 방식에 대해 설명하겠습니다.

1. ClickHouse Kubernetes 아키텍처 개요 🛠️

이번 실습에서는 replica를 추가하여 데이터가 복제되도록 설정했습니다. 기존 clickhouse helm 배포용 yaml 파일에서 replicaCount를 2로 설정했습니다.(Clickhouse 설치 방법)

NAME                     READY   STATUS    RESTARTS
clickhouse-shard0-0      1/1     Running   0       
clickhouse-shard0-1      1/1     Running   0       
clickhouse-shard1-0      1/1     Running   0       
clickhouse-shard1-1      1/1     Running   0       
clickhouse-zookeeper-0   1/1     Running   0

2. 데이터 삽입(Insert) 처리 방식 🔄

2.1 ReplicatedMergeTree

이전 실습에서 사용했던 regular_db에 replicatedmergetree 엔진을 사용하는 테이블을 생성하고 데이터를 추가합니다.

-- ReplicatedMergetree 엔진 테이블 생성
CREATE TABLE IF NOT EXISTS regular_db.test_replicated_merge_tree (
    id UInt64,
    event_date Date,
    event_time DateTime,
    user_id String,
    event_type String,
    payload String
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/regular/test_replicated_merge_tree', '{replica}')
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, id);

-- 분산 테이블
CREATE TABLE regular_db.distributed_replicated_table ON CLUSTER default
(
    id UInt64,
    event_date Date,
    event_time DateTime,
    user_id String,
    event_type String,
    payload String
)
ENGINE = Distributed(default, regular_db, test_replicated_merge_tree, cityHash64(id));

-- 데이터 추가
INSERT INTO regular_db.distributed_replicated_table
SELECT
    number as id,
    toDate('2024-03-01') + (number % 30) as event_date,
    toDateTime(toDate('2024-03-01') + (number % 30) + (number % 24) / 24) as event_time,
    concat('user_', toString(1 + number % 1000)) as user_id,
    multiIf(
        number % 5 = 0, 'click',
        number % 5 = 1, 'view',
        number % 5 = 2, 'purchase',
        number % 5 = 3, 'login',
        'logout'
    ) as event_type,
    concat('{"data":"', repeat('X', 10 + number % 50), '","value":', toString(number % 100), '}') as payload
FROM numbers(1000000);

위와 같이 약 1,000,000 row의 데이터를 넣어도 select count(*) from regular_db.test_replicated_merge_tree 시에 아무 데이터가 조회되지 않는 현상이 발생합니다. 이는 dbeaver에서 clickhouse cluster 연결 시 각각의 shard에 연결되기에 아직 복제되지 않은 shard에 데이터를 조회하여 문제가 발생한 것입니다.

select *
from cluster('default', regular_db.test_replicated_merge_tree)

만약 전체 클러스터에서 데이터 조회 쿼리를 실행하면 table not found 에러가 발생합니다.

이는 아직 clickhouse가 각 shard에 복제하지 못하여 발생하는 문제로 시간이 지나면(clickhouse가 background copy를 완료하면) 자연스럽게 데이터를 복제하며 모든 데이터 조회가 가능합니다.

MergeTree Vs ReplicatedMergetree의 차이점?

ReplicatedMergetree 엔진을 사용할 경우 shard 내 replica에 해당 데이터가 모두 복제됩니다. 데이터 조회 예시를 통해 알아보면

 

Clickhouse-shard1-0과 Clickhouse-shard1-1에 동일한 숫자의 데이터가 복제된 것을 확인할 수 있습니다. 하지만 mergetree의 경우 고정된 shard 내에만 존재하여 replicated 되지 않습니다.

 

 

3. 테이블 엔진 별 데이터 삽입(Insert) 처리 방식에 따른 장,단점 비교

테이블 엔진	장점	단점
Distributed + MergeTree	1. 수평 확장성: 샤드를 추가하면 자동으로 확장 가능 2. 중앙 집중식 조회: 클라이언트는 Distributed 테이블을 통해 모든 데이터를 조회할 수 있음 3. 효율적인 샤딩: 샤딩 키를 기준으로 데이터를 균등하게 분배하여 부하를 최소화	1. 데이터 복제 없음: 샤드 간 데이터가 중복되지 않아 특정 샤드 장애 시 데이터 손실 가능. 2.복구 시간 증가: 장애 발생 시 수동 복구가 필요함.
ReplicatedMergeTree	1. 고가용성: 장애 발생 시 다른 레플리카에서 데이터를 제공하여 서비스 중단 방지. 2. 데이터 무결성 보장: ZooKeeper를 통해 레플리카 간 동기화 관리. 3. 복구 자동화: 장애 노드 복구 시 ZooKeeper가 자동으로 상태를 조정함.	1. 운영 비용 증가: 레플리카 간 동기화로 인해 추가적인 리소스 소모 발생. 2. 복잡한 설정 요구: ZooKeeper 및 레플리카 관리가 필요함.

 

각 주요 엔진별 사용 사례는 다음과 같습니다.

 

Distributed + MergeTree: 실시간 분석 중심 환경 (대규모 이벤트 처리)

• 🚀 높은 쓰기 성능과 확장성이 필요하며, 장애 발생 시 일부 데이터 손실이 허용될 수 있는 경우에 적합합니다

ReplicatedMergeTree: 데이터 무결성이 중요한 환경 (금융/의료)

• 🚀 장애 발생 시에도 데이터 손실 없이 서비스를 지속해야 하는 경우에 적합합니다