| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed |
@ankitbhatnagar
@ahegyi
@mikolaj_wawrzyniak
|
@grzesiek
|
@nhxnguyen
@stkerr
| workinggroup clickhouse | 2023-01-10 |
ClickHouse를 위한 확장 가능한 데이터 수집 추상화
목차
요약
ClickHouse로부터 고성능 스루풋 시스템으로부터 대량의 데이터를 효율적으로 적재하는 데 도움이 되는 확장 가능하고 안정적인 데이터 수집 추상화 개발.
왜
오늘날과 미래에 발생하는 데이터의 규모와는 상관없이 GitLab의 모든 응용 프로그램에서 ClickHouse로 필요한 데이터를 쓸 수 있도록 하기 위해. ClickHouse에 대한 원천은 [모티베이션] 확인.
어떻게
ClickHouse에 데이터를 작성할 수 있게 해주는 작성 추상화 (API/Library)를 구축하여 필요한 모든 구성, 표준 및 모범 사례를 기본적으로 내장시켜 제공함으로써.
모티베이션
ClickHouse는 매우 성능이 우수하며 전통적인 OLTP(PostgreSQL, MySQL과 같은) 데이터베이스에 비해 대량의 데이터를 처리할 수 있는 온라인 분석 처리(OLAP) 데이터베이스입니다. ClickHouse의 능력에 대한 자세한 내용은 [1], [2], [3]를 참조하세요.
GitLab에서 현재 및 미래의 ClickHouse 사용/능력은 ClickHouse를 백엔드 데이터 리포지터리로 사용할 수 있는 여러 사용 사례를 참조하고 설명합니다. 이 중 대부분은 다음과 같은 주요 관심 영역에 대해 이야기합니다:
-
기존 데이터베이스에서 ClickHouse의 OLAP 능력을 활용하여 짧은 기간 또는 긴 기간 동안 데이터를 집계 분석할 수 있는 지원시스템.
-
현재 주로 PostgreSQL에서 처리되는 데이터로 이러한 작업을 실행하는 것이 점차 어려워지고 성능이 떨어지는 문제점.
앞으로, 응용 프로그램이 생성하는 데이터 양이 더 많아지며 생성 속도, 이를 ClickHouse와 같이 더 능력 있는 시스템에 효과적이고 효율적으로 적재할 수 있는 능력은 응용 프로그램을 확장하고 비증가에 대비하는 데 도움이 됩니다.
케이스 스터디
ClickHouse를 사용하려는 모든 (보고된) 사용 사례를 초기평가한 결과, 다음과 같은 널리 사용되는 패턴이 관찰됩니다:
-
기존 데이터베이스에서 ClickHouse로 효율적으로 데이터를 복제하고, 특히 PostgreSQL에서.
-
ClickHouse로 대량의 데이터를 직접 적재하여 비동기 처리, 데이터 집계 및 분석 수행.
다음 섹션에서 각 문제 영역의 세부 사항을 설명합니다:
1. 기존 데이터를 ClickHouse로 복제
이에 관한 이전 작업을 참조하면, PostgreSQL에서의 논리 복제는 너무 느린 것으로 확인되었습니다. 대신, 데이터베이스 트랜잭션 내에서 데이터 변경 이벤트를 발출할 수 있어야 하며, 이러한 데이터 변경 이벤트는 비동기로 처리되어 ClickHouse에 해당 데이터를 쓰거나 업데이트할 수 있어야 합니다.
다음 케이스 스터디는 그룹이 기본 문제를 해결하려는 방법을 설명합니다:
-
~group::optimize은 응용 프로그램 계층에서 구현할 수 있는 확장 가능한 PostgreSQL 데이터 복제 전략에 대해 작업해왔습니다.
-
제안: 확장 가능한 데이터 동기화/복제 전략에서는 이러한 전략에 대해 설명하고 큐/배치 처리 요구 또는 동작시키기 위한 Sidekiq 사용 시 발생하는 추가적인 도전 과제에 대해 언급합니다.
-
PostgreSQL에서ClickHouse로 데이터를 직접 붐프하는 것은 다루고 있는 문제에 올바르지 않을 수 있음이 확인되었습니다. -
위에서 설명한 문제에 추가로, 시스템 간의 데이터 복제 시 데이터 백필 및/또는 상위 관리되는 데이터 이주와 관련된 문제의 다른 분류도 다루어야 합니다.
-
-
group::data는 일부 Postgres 데이터베이스의 데이터를 Snowflake 기반 데이터 웨어하우스로 동기화하는 작업을 해왔습니다. 현재 시스템 설계 이전에 고려한 옵션은 이 문제를 참조하십시오: List down all possible options for postgres to snowflake pipeline.
-
다음 세대 GitLab SaaS 데이터 파이프라인의 작업을 통해 데이터 팀은 “사용자별 생성일자” 시간스탬프 열을 기반으로 증분 데이터 추출을 수행하는 “사용자 정의” 파이프라인을 보유하게 됩니다. 이를 통해 운영 데이터베이스 관계의 상당한 부분을 Snowflake 데이터 웨어하우스로 가져올 수 있습니다.
-
데이터양이 늘어나면 (ETL) 파이프라인이 실행하는 비용과 시간이 더 많이 필요하게 될 것으로 예상되므로, 데이터 생성 및 Snowflake 데이터 웨어하우스에 사용 가능한 시간 간격이 지연될 수 있습니다.
-
또한, 현재 설정에서는 행 삭제가 Snowflake로 전달되지 않으므로 데이터 불일치/불완전 문제가 발생될 수 있으며, 가져오기 간격 기간 동안 여러 업데이트 정보도 손실됩니다.
-
데이터베이스에서 ClickHouse 또는 중간 시스템으로 데이터를 복제하고 대규모 적재 파이프라인을 보유하는 것은 시스템의 운영 특성을 개선하는 데 도움이 될 것으로 예상됩니다.
-
2. 대량의 데이터를 ClickHouse로 적재
ClickHouse로 대량의 집계되지 않은 데이터를 적재해야 합니다. 이로 인해 많은 수의 작은 쓰기가 발생할 수 있으며, 이는 ClickHouse가 수신된 데이터를 처리하고 저장하는 방식에 부정적인 영향을 미칠 수 있습니다. 따라서 항상 적재 파이프라인을 효율적으로 유지하기 위해 작은 쓰기를 큰 것으로 큐 및 배치 처리해야 합니다.
다음 케이스 스터디는 각 그룹이 기본 문제를 해결하려는 방법을 설명합니다:
-
~group::observability는 ClickHouse에 대량의 데이터를 적재하는 필요성과 관련하여 다음 두 가지 문제를 지적합니다:
-
제안: GitLab 관측 플랫폼 - 데이터 수집에서는 사용자로부터 수신된 데이터를 먼저 Kafka와 같은 외부 이벤트 리포지터리로 적재하고, 이후 ClickHouse로 큰 묶음으로 쓰여지게 하여 많은 수의 작은 쓰기를 작성하지 않고도 ClickHouse
MergeTree가 적재된 데이터를 처리하는 방식의 대부분의 문제를 해소합니다. -
또한, ClickHouse: ClickHouse에 쓰기를 배치 처리하기 위한 클라이언트 측 버퍼링 조사에서는 위에서 언급한 문제를 해결하기 위해 애플리케이션 로컬 큐/배치를 실험하는 것에 대해 이야기합니다.
-
-
~"group::analytics instrumentation"은 분석 오퍼링을 구축하면서 최근에 시스템 일부를 구축하거나 개선하고 있습니다.
-
제품 분석 수집기 컴포넌트에서는 Jitsu를 Snowplow로 교체하여 추적 이벤트를 수집 및 처리하는 것에 대해 설명합니다. 제안서의 자세한 내용은 Jitsu 교체를 참조하세요.
-
초기 설계는 Snowplow as Jitsu Replacement PoC과 같이 프로토타입이 되었습니다.
-
대량의 데이터가 ClickHouse로 적재될 것이므로 확장 가능한 적재 파이프라인을 사용하여 이득을 볼 수 있을 것으로 예상됩니다.
-
목표
잘 정의된, 확립된 클라이언트 추상화
ClickHouse로 데이터를 수집하는 데 도움이 되는 완전히 기능적인 애플리케이션 측 추상화를 정의하고 구축하고자 합니다. 이러한 애플리케이션은 애플리케이션 자체가 설계된 방식을 방해하지 않으면서 기본 코드 백엔드에 구애받지 않게 해야 합니다. 제안된 추상화는 GitLab의 어떤 애플리케이션(핵심 또는 위성)에서도 기본 선택 사항이 되어야 합니다.
쓰기 양의 고 처리량 지원
여기서의 솔루션은 애플리케이션이 배치로 작은 쓰기 수를 다량을 받을 수 있도록 효율적으로 기본 데이터베이스에 삽입할 수 있을 뿐만 아니라, 애플리케이션이 확장됨에 따라 성장도 가능하게 해야 합니다. ClickHouse가 들어오는 쓰기를 어떻게 처리하는지를 고려할 때, 제안된 솔루션은 매우 작은 쓰기의 수를 큰 배치로 묶을 수 있어야 합니다.
신뢰할 수 있고 일관된 데이터 전달
여기서의 솔루션은 ClickHouse에 최종적으로 영속화되기 전에 데이터의 미당르를 최소화하고 입력된 데이터의 신뢰성과 일관성을 보장해야 합니다.
비목표
데이터 유형, 스키마 또는 포맷 다루기
이 제안의 현재 단계에서 우리는 수신된 데이터의 데이터 유형, 스키마 또는 형식을 최적화하는 것은 고려하지 않습니다. 이 작업은 백엔드별 구현 자체에 위임되어야 하며 쓰기 추상화 내에서 처리되어서는 안됩니다.
현재 데이터 소스가 존재하는 위치 다루기
우리는 또한 이 단계에서 디자인에 클라이언트측 특정 세부사항을 다루지 않습니다. 쓰기 추상화는 그것이 작성된 언어를 위한 도구로 남아야 합니다. 애플리케이션이 타사 라이브러리로 데이터를 쓰도록 사용할 수 있다면, 그것으로 충분하여서 상위에 구축할 수 있는 좋은 도구여야 합니다.
일반적인 고려 사항
위에서 언급한 두 가지 문제 영역의 세부 사항에 대한 대응을 고려하면 다음과 같은 논리적 구조로 제안된 솔루션을 모델링할 수 있습니다:
- 흡수
- API/SDK
- HTTP2/gRPC 사이드카
- 전송 및 라우팅
- 다중 대상
- 소화/계산
- 풍부화
- 처리
- 영속화
이러한 기능을 구축함에 있어서 주요 도전 과제
Self-Managed형 환경
ClickHouse 및 관련 시스템을 도입하는 데 가장 큰 도전은 Self-Managed형되는 GitLab를 실행하는 사용자에게 사용 가능하게 만드는 것입니다. 이 제안의 의도된 목표는 의도적으로 이러한 제약 내에서 유지됩니다. 또한 여기서 제안하는 내용이 Self-Managed형되는 환경 내에서 ClickHouse를 사용하는 응용 프로그램에 적용 가능하다는 것을 명확히 하는 것이 중요합니다.
우리는 ClickHouse 인스턴스를 관리 환경에 대한 유통 및 배포를 최적화하는 데 관련된 노력을 계속하고 있습니다. 언급된 문제의 부분을 다루는 몇 가지 다른 문제는 다음과 같습니다:
다양한 데이터 소스, 그들의 구조 및 사용 패턴
ClickHouse로 흡수하고자 하는 데이터는 여러 다양한 데이터 소스에서 올 수 있으며, 다양한 스키마 또는 형식으로 구조화될 수 있습니다. 이를 고려하면 모든 사용 사례를 효율적으로 충족시키는 솔루션을 기술 문제입니다.
우리가 중간 흡수 시스템을 구축하기로 결정하면, 이러한 솔루션은 다양한 응용 프로그램이 활용할 수 있는 소스/스키마/형식에 중립적인 데이터 전송 계층을 제공하는 데 도움이 되어야 합니다.
현재 데이터베이스 인프라 위에 구축
우리의 현재 데이터베이스 인프라는 상당한 규모에서 운영되며 지속적으로 읽기/쓰기하는 더 많은 애플리케이션을 추가하면 기존 리소스에 압력이 가중됩니다. 안전하게 다른 컨텍스트에서 처리될 수 있는 작업 부하 및/또는 데이터셋을 움직이는 것이 중요합니다.
서비스 발견
우리는 여전히 ClickHouse 클러스터 및/또는 인스턴스의 유통 및 배포에 대한 세부 사항을 일반적으로 사용자, 어떻게 / 이에 따라 우리가 그것을 끝내게 될지에 따라 클라이언트가 그런 솔루션에 반드시 포함되어야 하는 어떤 클러스터, 샤드 또는 테이블을 발견할 수 있을지 결정해야 합니다.
제안된 솔루션
위에서 논의된 문제를 감안할 때, 현재 우리의 더 나은 이익을 위해 외부 중간 시스템을 사용할 수 있도록 하여 그 필요에 따라 특히 데이터의 양과 크기에 있어서 쓰는 애플리케이션에서 ClickHouse로 데이터를 저장하기 위한 추상화를 가능하게하는 것이 좋습니다.
따라서, 우리는 현재 운영중인 규모에 상관없이 애플리케이션이 데이터를 ClickHouse에 저장할 수 있는 추상화를 개발하고자 합니다. 또한 다음과 같습니다:
- 애플리케이션이 시간이 지남에 따라 그들의 성능 및/또는 규모 요구 사항이 변경되어 다른 기술로 전환할 수 있는 것을 용이롭게 합니다.
- 기본적인 구성, 설정 및 최상의 관행과 같은 백엔드별 컨벤션 및 구성요소를 모든 애플리케이션이 일관되게 활용할 수 있도록 하여야 합니다.
디자인 및 구현
핵심 가정
-
우리는 클라이언트 측 도구를 평가하기 위해 꽤 정교한 시험 판단을 피함으로써 ClickHouse에 데이터를 쓰기 위한 핵심가정만 초점을 맞추기로 결정했습니다. ClickHouse에 데이터가 어떻게 들어가는지에 대한 디테일은 이 문서에서(의도적으로) 다루지 않습니다. 이러한 디테일 중 일부는 이 데이터를 생성하는 각 응용 프로그램에 위임됩니다.
-
우리는 이 설계의 범위를 벗어나는 다양한 저장 백엔드의 선택을 뒤졌 또는 에픽으로 다음에 위임하기로 결정했습니다. ClickHouse를 우리의 데이터의 최종 목적지로 삼고 있으므로, 이 문서는 해당 데이터를 클릭 하우스에 쓰는 것에만 언급합니다. 이것은 직접 또는 큐잉/배칭 시스템을 통해 간접적으로 ClickHouse로 데이터를 쓰는 것에 대해 이야기합니다.
아키텍처
데이터 쓰기에 대한 추상화를 가진 것은 클라이언트 측 계측이 백엔드에 구애받지 않게하면서 어디에서 실행되어도 코드 경로를 전환할 수 있도록 도와줍니다.
예를 들어 설정은 다음과 같습니다:
ruby
Gitlab::Database::Writer.config do |config|
#
# sync 모드를 사용하는 경우 데이터가 직접 ClickHouse에 기록되므로,
# 여기서 백엔드는 ClickHouse로 추측됩니다.
config.mode = :sync 또는 :async
config.backend = :clickhouse # 선택 사항
# 또는
#
# async 모드를 사용하는 경우, 데이터가 처음에 중간 시스템에 기록되고
# 그런 후 ClickHouse로 비동기적으로 기록됩니다.
config.mode = :async
config.backend = :pubsub 또는 :kafka 또는 :otherbackend
#
# 그런 다음 백엔드별 구성 관련
#
config.url = 'tcp://user:pwd@localhost:9000/database'
# 예를 들어 직렬화기는 데이터가 와이어를 통해 이동하는 방법을 정의하는 데 도움이됩니다
config.json_serializer = ClickHouse::Serializer::JsonSerializer
# ...
end
# 응용 프로그램별 처리 실행
# eventually, write data using the object you just built
Gitlab::Database::Writer.write(
Gitlab::Database::Model::MyTable,
[{ id: 1, foo: 'bar' }],
)
Gitlab::Database::Writer.backend를 가능한 한 다소 백엔드별 클라이언트 구현에 가깝게 유지하고자 합니다. 순수한 클라이언트를 둘러싸는 래퍼는 백엔드에 대한 서비스 검색과 같은 외부 요소를 다루어 주고 사용자가 특정 클라이언트의 기능을 활용하도록 허용하는 동시에 허용합니다.
이터레이션
이 모든 일은 매우 큰 규모의 프로젝트이며 실제 사용에 대한 피드백의 필요성을 고려하면 이러한 제안된 추상화를 여러 번의 이터레이션 동안 구축하기로 결정하는 것이 합리적입니다.
이터레이션 1 - 동기 모드로 쓰기 추상화 개발
먼저 ClickHouse로 데이터를 쓸 수 있는 간단한 쓰기 추상화를 연구하고 개발합니다. 이렇게 함으로써 우리의 사용자들이 사용자 의견을 수집하고 쓰기 API/인터페이스를 개선할 수 있도록 해주고, 우리가 어떻게 사운드 환경에서 ClickHouse를 배포할 것인가에 대한 개발을 할 수 있도록 합니다. 이를 수행함으로써 사용자 의견을 수집하고 쓰기 API/인터페이스를 개선할 수 있으며, 이를 통해 사용자 피드백을 모아 쓰기 API/인터페이스를 개선할 수 있습니다.’]]
반복 2 - 스키마 및 데이터 유효성 검사 지원 추가
다음 반복에서는 스키마 사용 및 유효성 검사 지원을 추가할 계획입니다. 이는 모델 정의를 유지하고 삽입할 데이터를 유효성 검사하는 데 도움이 됩니다.
반복 3 - 비동기 모드 지원, 하나의 백엔드로 PoC 추가
위의 두 반복이 잘 실행된 후에는 ClickHouse에 데이터를 비동기적으로 쓰기 전에 중간 데이터 리포지터리에 데이터를 쓰는 지원을 추가하여 쓰기 추상화를 확장할 수 있습니다. 우리는 이러한 구현을 적어도 하나의 백엔드로 프로토타입화하는 것을 목표로 합니다.
추가 반복
백엔드에 의존하지 않는 추상화가 클라이언트가 상호 작용하는 투입 인터페이스가 되면서 이를 통해 여러 다른 사용 사례를 해결할 수 있습니다. 그 중 일부는 다음과 같습니다.
- 여러 소스에서의 제로 구성 데이터 투입
- 여러 소스에서 데이터 동적으로 풍부화
- 장기 보존 데이터 리포지터리로의 데이터 오프로드
가능한 백엔드 구현
- ClickHouse에 직접 쓰기 애플리케이션
- 애플리케이션 로컬 인메모리 큐/일괄 처리 데이터
- 애플리케이션 로컬 영구 큐/일괄 처리 데이터
- ClickHouse로 최종적으로 쓰기 전에 비로컬 큐/일괄 처리 데이터
- 관리되는 클라우드 백엔드:
- Self-Managed형 백엔드:
비로컬 백엔드 사용 시 추가 복잡성
- 운영되는 서브시스템이 해당 백엔드에서 데이터를 읽어 ClickHouse로 효율적이고 안정적으로 쓰기 위한 추가 프로세스/서브시스템 실행이 필요합니다.
- 추가된 백엔드 간의 호핑은 이러한 데이터가 얼마나 빨리 ClickHouse에 도달할 수 있는지에 잠재적인 지연이 있을 수 있다는 것을 의미합니다.
위에서 설명한 점들은 애플리케이션의 추가 복잡성을 나타내지만, 대규모 데이터 투입이 필요한 경우 유효한 트레이드오프로 간주될 수 있습니다.
여러 차원에서 백엔드 비교
| 차원 | CHProxy | Redis | Google PubSub | Apache Kafka |
|---|---|---|---|---|
| 작업 | 간단함 | 간단함 | 관리됨 | 비직관적이고 복잡함 |
| 데이터 유지 | 비내구성 | 비내구성 | 내구성 | 내구성 |
| 성능 | 좋음 | 좋음 | 높음 | 높음 |
| 데이터 스트리밍 | 없음 | 최소한 | 좋음 | 최상 |
| Self-Managed형 환경에 적합 | 간단함 | 간단함 | - | 복잡함 |