1 of 43

ClickHouse

Introduction

2 of 43

Table of contents

0. ClickHouse ?

1. 어떻게 빠르게 만들었나?

2. 멋진 기능들

3 of 43

ClickHouse Intoduction

  • 오픈소스, 분산, Column-oriented, OLAP DB
  • Like Apache Druid, BigQuery, Amazon RedShift
  • 근데 가장 빠름
  • Real-time Serving이 가능하도록 설계
  • 100억건이 넘는 데이터에서도 1s 이내로 응답이 가능하도록

4 of 43

ClickHouse Adopters

5 of 43

어떻게 빠르게 만들었나?

6 of 43

Column-Oriented

7 of 43

Column-Oriented

  • ​
  • BigQuery, Redshift 등 기존 OLAP에서도 쓰는 방법
  • HDD 기준 디스크는 가로로 먼저 읽는다.
  • 모든 Row에 대해 특정 Column Aggregate 연산을 하는 상화을 가정
    • Row-Oriented: Full-scan
    • Column-Oriented: 해당 Column Offset start to end scan

8 of 43

SIMD

9 of 43

SIMD

10 of 43

SIMD

SIMD CPU instruction을 통해서 대량 데이터에 대해 Bulk 연산으로�Aggregate 연산이 빠름

  • SIMD Text Parsing
  • SIMD Data Filtering
  • SIMD Decompression
  • SIMD String operations

등에 쓰이고 있다.

11 of 43

Merge Tree

12 of 43

Merge Tree

  • Merge Sort를 DB indexing으로 구현한 자료구조
  • Immutable

​

  • 레벨별로 Part가 쪼개짐�ex) Level 0 Partition 10개, �Level 1 Partition 5개 ...
  • Level 0 에서 특정 Threshold가 다차면 Level 1 로 넘기면서 Merge Sort 실행
  • Level이 커지면 커질수록 Threshold는 커짐

​

  • 경우에따라 Disk Sync를 나중에 하기도 한다�=> Write가 B-Tree 보다 빠름

13 of 43

Primary Index

Primary Index에는 번호가 매겨진다.

Index 파일이 별도로 존재하고, 각 번호의 데이터 파일의 Offset을 가리킨다.

​

​

14 of 43

Data Skipping Index

15 of 43

Data Skipping Index

x → 010000

y → 001001

z → 000100

​

Block -> 011101 (x|y|z)

1)

W -> 000101

Block & W -> 000101 (O)

​

2)

W -> 000010

Block & W -> 000000 (X)

16 of 43

Data Skipping Index

  • False Positive,�찾을 데이터가 없는데 스캔 범위에 들어가는 경우는 있음
  • True Negative,�찾을 데이터는 있는데 스캔범위에 들어가지 않는 경우를 방지
  • 이를 통해 스캔할 범위를 대폭 줄일 수 있다.

17 of 43

Compression

Time-Series 에 유리한 Delta Compression

중복된 데이터에 유리한 Dictionary Encoding

18 of 43

Compression

  • Table-Level Compression을 통해 압축률 up to 1000%
  • RAW 데이터가 2TB라고 했을때 스토리지 사용량은 200GB로 충분할 수 있다.
  • 압축률은 데이터 패턴에 따라 다르다.

​

  • 데이터 사이즈가 작아지면 그만큼 스캔에 사용할 Disk 자원을 아낄 수 있고, �메모리에 버퍼링할 수 있는 데이터가 많아진다.
  • Cache Hit율이 올라가고, 속도가 빨라진다.

19 of 43

Map-Reduce를 쓰지 않음

  • MapReduce를 쓰면 Query Latency가 느려진다.

​

  • Real-time Data Serving을 목표로 설계한 ClickHouse기에 Map-Reduce는 철저히 배제

20 of 43

그 외 Low-Level Details

  • 쿼리 Planning시 Hash 함수 최적화: 30개가 넘는 해시함수중에서 가장 성능 좋은 애를 골라 쓴다. https://github.com/ClickHouse/ClickHouse/blob/master/src/Interpreters/Aggregator.h
  • 쿼리 Planning시 알고리즘 최적화
    • 무엇을 정렬시켜야 하는지에 따라서: 숫자 배열인가, 문자열 배열인가, Tuple 배열인가에 따라 다르다.
    • 데이터는 RAM에 모두 올릴 수 있는지?
    • 안정 정렬이 필요한지?
    • 전체 정렬이 필요한지 아니면 n번째 element까지만 구해도 되는지?
    • 이미 부분적으로 정렬된 데이터를 또 정렬하고 있는건 아닌지?
    • ex) LZ4 Compression 최적화: https://habr.com/en/company/yandex/blog/457612/

21 of 43

멋진 기능들

22 of 43

Buffer Table Engine

23 of 43

Buffer Table Engine

  • Application Level에서 1건씩 테이블에 insert하게 되면 매번 Disk Sync가 일어날 수 있다. 속도 및 성능이 낮아짐

​

  • 이에 ClickHouse 에서는 메모리 Buffer를 두고, �특정 Threshold가 넘어가면 Target 테이블에 Flush

​

  • Query 할때도 Target과 Buffer 두 테이블에서 모두 가져온다.

​

  • 주의점. 1건씩 insert 할때 throuput이 초당 1000건 insert. �Application Level에서 한번 더 Buffer를 둬서 1000건씩 insert 하면 �초당 백만건의 퍼포먼스가 가능하다고 함.

24 of 43

Buffer Table Engine

25 of 43

Materialized View

  • 원본 테이블에서 Aggregate 결과물을, �빠른 쿼리를 위해 미리 저장해두는 테이블
  • ClickHouse에서는 Insert 시마다 Materialized View가 갱신됨

​

  • 후술할 AggregatingMergeTree와 같이 쓰는 것을 권장

26 of 43

AggregatingMergeTree

  • MergeTree에서 Compaction 단계가 일어날 때 마다 �지정한 Aggregate 결과값만 남기고 원본 데이터를 삭제하는 테이블엔진

​

  • Materialized View와 같이 쓰는 것이 권장됨

27 of 43

S3 - Load Data From S3

Load Data From S3

​

  • 흔히 OLAP 하면 제공하는 기능
  • S3에 있는 CSV, parquet 등의 파일을 불러와 Table에 적재할 수 있다.

28 of 43

S3 - Remote Disk Storage

아예 S3를 ClickHouse의 Remote Disk로 쓸 수 있다.

​

이는 Computing Layer와 Stroage Layer 분리를 의미

​

유연한 Scaling이 가능하다.

ClickHouse Cloud는 이 기능을 활용해

무한 용량 Stroage & Serverless Computing 제공

29 of 43

Kafka Table

ClickHouse는 Kafka 테이블 엔진을 제공

​

ClickHouse가 직접 kafka Topic에서 데이터를 끌어가는 기능

​

​

30 of 43

Kafka Table

주의할 점.

​

  1. 테이블에 쿼리가 들어와야, �queue에서 데이터를 끌어다가 consumer offset를 갱신
  2. 데이터는 지속되지 않음. (Disk에 저장되지 않음)
  3. Re-read 하려면 offset을 reset 해야함

​

데이터를 지속시키려면, Materialized View를 따로 만들어야함

31 of 43

Kafka Table

32 of 43

Kafka Table

Kafka Ingestion -> Processing -> Serving을 ClickHouse에서 Simple하게 정의 가능

33 of 43

Kafka Table

34 of 43

Kafka Push From ClickHouse

35 of 43

Kafka Push From ClickHouse

36 of 43

Federated Query

External Data Source Table을 선언하면

ClickHouse 데이터와 Join이 가능하다

​

INSERT, ALTER 등 State를 변경하는 것은 불가능

​

User - Wallet 리스트 가져와서 손쉽게 join하는 등

쿼리가 가능할 것으로 보임

37 of 43

Federated Query - MongoDB

38 of 43

Federated Query - PostgreSQL

39 of 43

Federated Query - HTTP Server

40 of 43

ClickHouse Cloud

41 of 43

ClickHouse Cloud Architecture

42 of 43

ClickHouse Cloud

무한용량, Serverless

​

다만 잘못 쓰면 좀 비쌈

43 of 43

끝.