[Naver Deview 2021] ClickHouse (클릭하우스) 리뷰

아래 영상을 보고 리뷰 및 정리한 글 입니다.

https://www.deview.kr/2021/sessions/462

글로벌 데이터 주권 강화 시대에 맞는 DATA CUBE 개발 ( GDPR 에 맞서는 개발 )

 

https://www.deview.kr/data/deview/session/attach/4_%E1%84%80%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%87%E1%85%A5%E1%86%AF%20%E1%84%83%E1%85%A6%E1%84%8B%E1%85%B5%E1%84%90%E1%85%A5%20%E1%84%8C%E1%85%AE%E1%84%80%E1%85%AF%E1%86%AB%20%E1%84%80%E1%85%A1%E1%86%BC%E1%84%92%E1%85%AA%20%E1%84%89%E1%85%B5%E1%84%83%E1%85%A2%E1%84%8B%E1%85%A6%20%E1%84%86%E1%85%A1%E1%86%BD%E1%84%82%E1%85%B3%E1%86%AB%20DATA%20CUBE%20%E1%84%80%E1%85%A2%E1%84%87%E1%85%A1%E1%86%AF%20(%20GDPR%20%E1%84%8B%E1%85%A6%20%E1%84%86%E1%85%A1%E1%86%BD%E1%84%89%E1%85%A5%E1%84%82%E1%85%B3%E1%86%AB%20%E1%84%80%E1%85%A2%E1%84%87%E1%85%A1%E1%86%AF%20).pdf

 

 

1. Backgrounds and issues

배경 : 국가 차원에서 데이터를 다른 나라로 이전 시킬 수 없다

1.1 데이터 주권주의 란

• 사람의 신체와 같이 데이터의 권리 또한 사용자 개개인에게 있다는 개념.
• 국가 차원에서의 자국 데이터 산업 보호를 위한 개념 (중국, 미국, 러시아, 일본 등등)
• 네이버 스마트 스토어, 웹툰 등 세계로 뻗어나가는 서비스 등장
  • 다양한 형태의 대용량 데이터 분석 요구가 증가
• 데이터 이동을 제한하는 각 국가별 관련 법규를 준수하는 것은 선택이 아닌 필수
  • 유연한 데이터 분석 기술 개발이 필요한 시점

1.2 데이터 이동 제한 (Data Localization) 이란

• 수집된 사용자 데이터를 타국으로 반출하는 것을 제한 ( 예: GDPR 등)
• 국가 마다 데이터 이동 제한 정책이 매우 다름

1.3 데이터 이동제한 지키지 않는다면?

• 금전적 손해
• 국가, 회사 이미지 실추
• 위반 사례
  • facebook 개인정보 위탁 및 국외 이전 관련 내용 미공개 등으로 과태료 2600만원
  • Google 국외 이전 개인정보 항목의 구체적 명시 등으로 인한 개선 권고
• 국가별로 제재가 계속 되고 있는 사례
  • 아일랜드 DPC의 TikTok 사용자 데이터 중국 이전 조사
  • 중국의 PIPL 위반시 최대 90억원
  • 국내도 EU GDPR과 동등한 수준으로 법 체계 마련

1.4 피할 수 없는 네이버 로그의 파편화

• 로그 수집에서 지표 조회까지 모든 데이터 처리/저장은 로그 수집이 있던 국가의 IDC에서 진행
• Backend engineer Frontend engineer 동일한 시스템을 복수개로 유지
• 유니크 계산이 불가능 하거나 굉장히 불필요하고 비효율 적인 작업들이 발생

1.5 데이터 시스템 분리 구축시 발생되는 문제

• 회사 입장
  • infra 비용 발생
  • 불필요한 현지인력 채용 증가
• 개발자 입장
  • 굉장히 하기 싫은 업무로 전락
  • 유지보수 증가

1.6 절대 할 수 없는 것과 도전할 수 있는 부분

• 법규 준수를 위해 피할 수 없는 부분
  • 로그 수집 & 로그 파편화
  • 지표값 이외의 정보가 담긴 중간 집계 데이터
• 도전 할 수 있는 부분
  • 가상의 통합 테이블 구축
  • 집계 & 저장 이후의 프로세스는 단일화
    • 빠른 네트워크 / 빠른 연산 속도가 중요함

2. 네이버 지표의 특성

2.1 네이버 서비스의 구조적인 특징

• 네이버는 포털 서비스,
  • 검색, 쇼핑, 페이, 뉴스 등등 다양한 서비스를 포함하는 포털이라는 개념
  • 개별 서비스는 네이버 메인과 검색 서비스를 통한 유입이 많은 특징
  • 개별 서비스도 중요하겠지만 거시적인 관점에서의 뷰가 중요

2.2 네이버 서비스의 유연한 지표 특징

• 구조적 지표 관점
  • 서비스 key를 tree 형태의 구조로 잡혀 있기 때문에
  • 하위노드의 합이나 유니크 계산을 자연스럽게 할 수 있는 구조
• 커스텀 지표 관점
  • Tree의 방향도 다르고, Tree의 depth도 다른 Node 들의 통합 지표 제공
  • PV는 합산으로 문제 해결, 하지만 user 수는…?
• tree 구조
  • (장점) 상위 하위 개념이 있어 상위로 갈수록 하위를 포함하는 지표여서 거시적인 지표를 잡기 쉬움
  • (단점) 상위로 갈수록 unique 계산에 드는 비용이 굉장히 커짐

2.3 네이버 서비스의 유연한 지표 제공을 위한 난관

 

 

PV 집계

한국 스마트스토어 23 + 일본 스마트스토어 24 + 스페인 스마트스토어 25 = 72

• 각 IDC에서 집계된 값을 단순 SUM해서 해결이 가능

user 수 집계

한국스마트스토어 3 + 일본 스마트 스토어 3 + 스페인 스마트 스토어 2 = 8

• 각 IDC에서 집계된 값을 단순 SUM해서 해결이 불가능
• unique(a) + unique(b) != unique(a+b)

3. 글로벌 통합 가상 테이블 구축

3.1 글로벌 통합 가상 테이블

연산 성능이 가장 뛰어난 IDC에 가상 테이블을 구성함

이 가상 테이블에는 어떤 IDC 어떤 테이블의 어떤 컬럼들을 어떻게 연산하면 되는지 메타 정보만 가지고 있음

지표 시스템에서는 가상 테이블에 select 했을때 저장된 메타데이터정보를 이용해서 빠르게 연산해서 리턴함

그럼 write는 각각의 IDC에서 이루어지기 때문에, 지표 시스템은 각각 IDC에 질의할 필요 없이 글로벌 통합 테이블만 바라보고 질의하면 되고, 중복 시스템도 없고 유지 보수도 단순해짐

3.2 ClickHouse 분산 테이블 엔진을 활용한 분리 구축

 

 

ClickHouse를 선택한 이유

1. 기능적으로 데이터 Write 없이 통합 테이블을 만들 수 있는 엔진이 있음
2. 성능적으로 Read가 빠르고, 연산이 빨라서 다차원 지표를 정할 수 있음

4. 글로벌 Clickhouse 구성

4.1 글로벌 Clickhouse 구성 (예)

 

MergeTree Table Engine 기반

• LSM Tree 기반의 table engine
• 이 자체로 index가 존재하며 독립적인 Table Component

Distributed Table Engine 기반

• Persistent Data 저장소는 아님 (Write 시 MergeTree Engine으로 가기 위한 Buffer)
• Write 시 Data를 분리하는 Shard Key를 정의하고
• Read시 연결된 MergeTree Engine의 Data를 취합 (Requestor / Remote Node)

4.2 글로벌 Clickhouse 구성 방법 - Shard

 

(1) 분산 테이블 만드는 과정 - 각각의 노드에 MergeTree 테이블을 생성함

(2) 분산 테이블 만드는 과정 - 각각의 노드마다 한개의 MergeTree 테이블과 Distributed Table을 생성함

(3) 클릭하우스 설정 방법

4.3 글로벌 Clickhouse 구성 방법 - Replication

Zookeeper path를 이용하는 방법

주키퍼 path와 replicated path를 넣어야 함

always_fetch_merged_part = 1 로 설정 시, 해당 노드에서는 merge가 발생하지 않고, 다른 노드에 머지된 동일 데이터를 가져올 수 있음

노드성능을 고려해야하는 특수한 경우가 아니면, multi-master로 하는 것이 일반적인 방법 (slave-master X)

4.4 글로벌 Clickhouse 구성 - for Write

 

(여기 다시 정리)

#3 샤드와 두개의 리플리카가 교차하면서 존재하고

클릭하우스의 흥미로운 특징

3 샤드 2 리플리카 = 개별적인 테이블 처럼 동작함

분산 테이블을 지원하지 않았다면, 2 리플리카를 지원하는 3개의 테이블이 따로 있는 샘

클릭하우스의 머지트리 테이블은 독립적인 특징을 갖고 있고,

디스트리뷰티드 테이블로 분리된 테이블이 한대 뒤섞일 수 있는것

기본적인 테이블을 IDC 별로 만들고, write 하는데만 사용하면 사용자 데이터는 IDC에 대해서만 분산이 될 수 있음

 

4.5 글로벌 Clickhouse 구성 - for Read

 

 

모든 IDC에 샤드 정보를 한데 묶어 통합된 설정을 구성하면 됨

새로운 클러스터를 정의하고 클러스터에서 사용될 모든 IDC 클러스터 정보를 한대 묶어 저장하는 것

• HA 구성도 그대로 유지하며 사용할 수 있도록 가져옴

4.6 글로벌 Clickhouse 구성

통합된 테이블을 바라봐야 하는 FE / BI 툴에서는 Read-Only 테이블만 바라게 구성해서 모든 IDC 테이블을 한번에 읽을 수 있는 관점을 가질 수 있게 되었음

또한 H/A topology를 유지할 수 있음.

각각 IDC별로 replica 구조를 그대로 유지함
→ 특정한 IDC에서 문제가 생겨도, 같은 IDC에 속한 노드가 이후에 요청을 처리할 것이기 때문에 H/A가 가능, 2개 이상 replica를 가지는 것도 가능함

5. 통합 테이블 활용

5.1 통합 테이블 활용 case 1

 

5.2 통합 테이블 활용 case 2

 

5.3 통합 테이블 활용 case 3

 

6. 왜 Clickhouse 였는가 ?

6.1 LSM-Tree를 통해서 본 Clickhouse의 특징

 

 

모든 데이터는 Append 형태로 Write 된다. (빠른 Write 성능)

• 새로운 LSM Component를 생성하며 Write
• Random I/O → Sequential I/O 로 변환

Append Only 로 저장된 이 데이터를 다시 효과적으로 읽을 수 있도록 재구성 (빠른 Read 성능)

• Back-ground Merge Process를 통해서 다시 Sequential Read 할 수 있도록 준비
• Random Read → Sequential Write

LSM Tree의 Merge 란?

• 데이터를 일단 작은 단위로 나누어 Sorting 하고
• 점점 더 큰 단위로 데이터를 생성하여 Merge

 

 

Merge Process 는 Write Performance의 키

• 다시 읽을 때를 대비하여 Strictly Sort
• Primary Key 를 통해서 빠르게 Sequential Read

Merge Policy

• Cassandra 등 기타 LSM : Leveling Merge, Tiering Merge와 같이 Merge Policy 를 선택 하는 것이 가능
• Clickhouse : Partition By 를 통해서 Merge Component의 최대 크기를 조절하는 것이 가능

 

 

LSM Tree and Bloom Filter

• Bloom Filter를 사용하여 수많은 LSM Component 중 Key data의 위치를 찾아냄

Query 시에는 데이터 있는 Part 찾을 때는 Bloom Filter

• 대상 데이터를 빠르게 찾아낼 수 있음
• 단 이러한 특성으로 CH 의 경우 Write Visibility가 떨어짐

 

 

Bloom Filter의 기본적인 특징

• 특정 원소 (key) 가 집합 (LSM-Tree Component)에 속하는지 아닌지를 검사하는 데에 사용
• 매우 빠르며, Space-Efficiently
• False Positive (특정 Key가 집합에 속하지 않지만 있다고 할 가능성 ) 존재, 확률로서 Control 가능
• False Negative (있는데 없다고할 가능성) 없음

Insert 시의 동작

• 데이터 마다 N개의 Hash Function을 사용하며 결과 값을 Bit Vector에 계속해서 Or 연산
• N개의 함수이므로 N개 이하의 바드가 세팅된다 (Bit Vector Space 상 충돌 가능)

Search 시의 동작

• 검색 대상 Key에 대해서 N개의 Hash Function으로 연산하여 Bit Vector를 구함
• 만약 Bit Vector 가 모두 켜져 있는 집합(Component)를 찾는다.
• False Positive 확률이 존재 (다음 Componet에서 search)

6.2 Distributed Table Engine

 

 

 

자유로운 Table 조합을 가능하게 하는 Key Point

• MergeTree를 Merge 한 관점을 제공

Sharding Key를 통한 데이터 분배 및 H/A를 담당하는 Table Engine

• 데이터 저장을 위한 테이블이 아닌 Sharding 및 H/A를 구현한 구현체
• Distributed Table을 통해 실제 데이터를 가지고 있는 MergeTree Engine table로 Query 전달

MergeTree table은 완벽히 독립적인 존재

• 이를 특정 Sharding key 와의 의존성 없이 자유롭게 Distributed 을 재구성 할 수 있다.
• 이러한 이유로 Table 생성을 2번 하는 것
• 각각의 MergeTree Table 은 Distributed Table과 관계 없이 독립적으로 Query 처리가 가능

 

Query 가능한 독립적 LSM Component의 특성이 MergeTree 까지 반영되어 있다.

Table Schema 만 같다면 다양하게 Shard를 재조합하여 사용할 수 있다.

이러한 특성을 이용하여 Global IDC의 다양한 Topology를 구성하는데 사용할 수 있다.

6.3 기타 다양한 응용

Cross IDC Replication

• IDC 간의 데이터를 복제
• 하나의 IDC가 장애 자연재해 등과 같은 장애를 일으켜도 서비스 가능

Read Only Cluster

• 데이터를 가지고 있지 않은 Node 에서 Distributed Table 이용
• 최종 Aggregation이 많이 발생하는 경우

→ 성능변화가 크진 않았지만 Post-aggregation이 메모리를 많이 사용한다면, 각각 메모리를 분리하는데 사용할 수 있음

7. 성능 분석

7.1 성능 측정 (통합 테이블)

 

성능 변수들

• IDC별 데이터 볼륨
• IDC간 망 속도
• Server의 성능

Requestor Node / Remote 노드 구분

• Requestor Node 는 한국 IDC 내 존재
• 한국과 일본 데이터를 모두 대상으로 함

측정된 성능 특성

• 한국, 일본 데이터를 모두 통합하여 Query하는 경우 성능 변화는 거의 없다
• 매우 Light 한 Query를 하는 경우 30ms → 600ms 의 비교적 큰 변화 관측
• 왜 이런 일이 일어나는 걸까?

Clickhouse의 MergeTree 특성상 MergeTree에 대한 Query 실행은 병렬화

• MergeTree engine의 데이터 처리 과정

수식화

 

병렬 처리와 IDC간의 Data Skew로 적은 Volumen의 IDC 데이터는 성능에 큰 영향을 미치지 않음

7.2 성능의 주요 요소

Reomte / Requestor Node Seperation

• Requestor Node : Query 를 실행하는 Node
• Remote Node : 데이터를 실제 가지고 있는 원격 Node
• 이 두개를 분리하는 Configuration 을 적용하여 실험

 

 

성능 향상은 미미

• Remote Node 가 Requestor Node 가 되는 것이 더 좋겠다는 판단,
• Query 실행에 필요한 메모리만 충분하다면 이 둘을 분리하는 것도 방법
• 병렬처리 되는 Query 중 1개는 Local 데이터 전송을 통해 처리하는 셈.
• 따라서 Memory 만 충분하다면 특별히 느릴 이유가 없음

 

7.3 성능 요소 요약

Real-time OLAP 을 처리중인 현재의 시스템

• 해외/국내 네이버 전체 사용자를 대상으로 한 다양한 로그
• Flink를 통한 1st Aggregation 데이터를 Window Triggered Write
• 일간 14억 레코드 (1750 record/sec) 를 Write 하며 Read

IDC별 Data Skewness를 고려한 전략적 Requestor Node 선택

• Requestor Node의 선택이 중요 (Data가 많은 IDC에서 Query 를 실행 해라 )
• Aggregate Pushdown의 특성을 고려하여 Requestor Node를 선택하는 것이 현명함.
• IDC간의 Data Skewness를 적극적으로 이용하기