This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @ankitbhatnagar @ahegyi @mikolaj_wawrzyniak @grzesiek @nhxnguyen @stkerr workinggroup clickhouse 2023-01-10

요약

ClickHouse로부터 고철비율의 대량 데이터를 효율적으로 수용하기 위해 확장 가능하고 신뢰성 있는 데이터 수용 추상화를 개발합니다.

오늘날 또는 미래에 데이터를 생성하는 규모와 관계없이 GitLab의 모든 응용 프로그램이 ClickHouse에 필요한 데이터를 기록할 수 있도록합니다. ClickHouse를 처음부터 사용할 때의 이유는 동기를 참조하십시오.

어떻게

ClickHouse로 데이터를 기록할 수 있는 쓰기 추상화 (API/Library)를 구축함으로써 사용자가 데이터를 ClickHouse로 기록하고 필요한 모든 구성, 관례, 그리고 기본적으로 포함된 인스트루먼테이션, 서비스 검색 등을 제공합니다.

동기

ClickHouse는 실시간 집계 데이터를 가져오는 온라인 분석 처리 (OLAP) 데이터베이스로 많이 변하지 않는 고유한 실시간 집계 데이터를 처리해야 하는 사용 사례에 사용됩니다. ClickHouse는 전통적인 트랜잭션 관계형 데이터베이스(OLTP)인 Postgres, MySQL과 비교하여 대량의 데이터로 확장이 가능하고 높은 성능을 보입니다. ClickHouse의 능력에 대해 자세히 알아보려면 [1], [2], [3]을 참조하십시오.

GitLab에서 현재 및 미래의 ClickHouse 사용/기능은 ClickHouse를 사용하여 촉진 될 수 있는 여러 사용 사례를 참조하고 설명합니다. 이 중 대부분은 다음과 같은 주요 관심 영역에 대해 이야기합니다:

  1. 기존 데이터를 ClickHouse의 OLAP 능력을 활용할 수 있게하고 기존에는 Postgres에서 이러한 작업을 수행하는 것이 점차 어려워지고 성능이 떨어지고 있다는 점을 기반으로 하여 짧은 기간과 긴 기간에 걸쳐 데이터를 집계 할 수 있도록 합니다.
  2. 이러한 작업을 현재 존재하는 Postgres 데이터 세트로 수행하는 경우에 어려움을 겪고 있다는 것입니다.

나아가서 점점 더 많은 데이터가 응용 프로그램에서 생성되고 생성 속도가 빨라지면, 또더 더 효과적이고 효율적으로 그 데이터를 더 능숙한 시스템으로 수용하는 것은 응용 프로그램의 규모를 확장하고 비즈니스 성장에 대비하는 데 도움이 됩니다.

사례 연구

ClickHouse를 사용할 의도로 보고된 모든 사용 사례를 초기 평가한 결과, 다음과 같은 넓은 의용 패턴을 관찰할 수 있습니다:

  1. 기존 데이터베이스에서 ClickHouse로 효율적으로 데이터를 복제하는 것, 가장 많이 사용되는 것은 Postgres입니다.
  2. 대량의 데이터를 ClickHouse로 직접 수용하는 것, 비동기 처리, 데이터 집계 및 분석에 사용됩니다.

다음 섹션에서 각 문제 영역에 대한 자세한 설명을 제공합니다.

2. ClickHouse로 대량의 데이터 적재

우리는 ClickHouse에 대량의 집계되지 않은 데이터를 적재할 수 있어야 합니다. 이는 작은 쓰기 작업의 수가 많아질 수 있으므로 ClickHouse가 들어오는 데이터를 처리하고 저장하는 방식에 불이익을 줄 수 있습니다. 이 문제를 완화하기 위해 항상 적재 파이프라인을 효율적으로 유지하기 위해 작은 쓰기 작업을 큰 것으로 대기열에 넣고 일괄 처리해야 합니다.

다음 사례 연구는 각 그룹이 기본적인 문제를 해결하기 위해 어떻게 의도했는지 설명합니다:

  • ~group::observability는 ClickHouse로 대량의 데이터를 적재해야 하는 필요성에 대해 다음 두 가지 문제점을 설명합니다:

  • ~"group::analytics instrumentation"는 분석 오퍼링을 구축하고 최근 시스템의 일부를 구축하고/또는 개선하는 데 관심을 가지고 있었습니다.

    • 제품 분석 수집기 구성 요소는 Jitsu를 Snowplow로 대체하여 추적 이벤트를 수집하고 처리하는 내용을 다룹니다. 제안의 자세한 내용은 Jitsu 대체를 참조하세요.

    • 초안은 Jitsu 대체 PoC로서의 Snowplow로 프로토타입이 생성되었습니다.

    • 기본 설계를 통해 ClickHouse로 대량의 데이터가 적재될 것으로 보이며 확장 가능한 적재 파이프라인을 활용할 수 있을 것으로 보입니다.

목표

명확하고 확립된 클라이언트 추상화

우리는 어플리케이션에서 ClickHouse로 데이터를 적재하는 데 도움이 되는 완전 기능적인 응용 프로그램 내 추상화를 정의하고 확립하고자 합니다. 이러한 추상화는 어플리케이션이 디자인된 방식에 방해되지 않으면서도 하위 코드를 백엔드에 대한 의존 없이 유지할 수 있어야 합니다. 제안된 추상화는 GitLab의 핵심 또는 위성 어플리케이션의 기본 선택사항이 되어야 합니다.

높은 처리량을 지원하는 쓰기 작업

여기서의 솔루션은 어플리케이션이 기본 데이터베이스에 효율적으로 모든 양의 삽입(초당 1000-5000개의 쓰기 순서)을 기록할 수 있어야 하며, 어플리케이션이 확장됨에 따라 성장할 수 있어야 합니다. ClickHouse가 들어오는 작업을 처리하는 방식을 고려할 때, 제안된 솔루션은 매우 작은 쓰기 작업의 일부를 큰 일괄로 묶을 수 있어야 합니다.

신뢰할 수 있고 일관된 데이터 전달

여기서의 솔루션은 ClickHouse로 적재된 데이터의 신뢰할 수 있고 일관된 전달을 보장해야 하며, ClickHouse에 최종적으로 유지되기 전에 데이터의 무분별한 손실을 최소화해야 합니다.

비목표

데이터 유형, 스키마 또는 형식 다루기

본 제안의 단계에서는 적재된 데이터의 데이터 유형, 스키마 또는 형식을 최적화하지 않습니다. 이는 백엔드별 구현 자체에서 처리되어야 하며, 쓰기 추상화 내에서 처리되어서는 안됩니다.

현재 데이터 소스의 위치 다루기

우리는 또한 여기서는 디자인의 클라이언트측 특정 세부사항을 다루지 않습니다. 쓰기 추상화는 해당 언어를 사용하여 어플리케이션이 제3자 라이브러리와 같이 데이터를 쓸 수 있는 도구로 남아야 합니다. 어플리케이션이 그것을 사용할 수 있다면, 그 위에 구축할 수 있는 좋은 도구입니다.

일반 고려사항

상기된 두 가지 문제 영역의 세부 사항을 다룬 후, 제안된 솔루션을 다음과 같은 논리적 구조로 모델링할 수 있습니다:

  • 적재
    • API/SDK
    • HTTP2/gRPC 사이드카
  • 전송 및 라우팅
    • 다중 목적지
  • 소화/연산
    • 인리치먼트
    • 처리
    • 유지

이러한 능력을 빌드하는 데 대한 주요한 과제

Self-managed 환경

ClickHouse 및 관련 시스템을 도입하는 가장 큰 도전은 GitLab을 자체 관리환경에서 실행하는 사용자들에게 제공할 수 있는 능력입니다. 본 제안의 목표는 의도적으로 이러한 제약 내에서 유지됩니다. 또한 여기서 제안하는 내용이 자체 관리환경에서 ClickHouse를 사용하는 어플리케이션에 적용될 수 있도록 하는 것이 현명합니다.

ClickHouse에서의 GitLab 사용의 더 큰 범위 내에서 관리환경에 대한 ClickHouse 인스턴스의 배포와 배포를 최적화하는 데 관련된 지속적인 노력들이 있습니다. 앞서 언급한 문제를 해결하는 데 관련된 몇 가지 다른 이슈가 있습니다:

다양한 데이터 원본, 그들의 구조 및 사용 패턴

ClickHouse에 넣기로 한 데이터는 다양한 데이터 원본에서 나올 수 있으며 서로 다른 스키마 또는 형식으로 구조화될 수 있습니다. 이를 고려하면, 모든 사용 사례를 효율적으로 충족하는 솔루션을 작성하는 것은 간단한 일이 아닙니다.

중간 투입 시스템을 구축하기로 결정한다면, 어떤 솔루션을 작성하더라도 자체적인 소스/스키마/형식을 고려하지 않는 데이터 전송 계층을 제공하고 성숙한 클라이언트 추상화를 통해 가능한 많은 애플리케이션이 사용할 수 있도록 해야 합니다.

현재 데이터베이스 인프라 빌드

현재 데이터베이스 인프라는 상당한 규모에서 운영되며, 지속적으로 읽고 쓰는 애플리케이션을 추가하면 기존 리소스에 압력이 가해집니다. 안전하게 다른 맥락에서 처리할 수 있는 작업 부하 및/또는 데이터셋을 이동하는 것이 중요합니다.

서비스 검색

ClickHouse 클러스터 및/또는 애플리케이션에 대한 배포에 대한 세부 정보를 여전히 정규화하고 있습니다. 이를 어떻게 처리하게 될지에 따라 클라이언트가 어떤 ClickHouse 클러스터, 샤드 또는 테이블에서 솔루션이 되어야 할지 발견할 수 있어야 합니다.

제안된 솔루션

이전에 논의된 문제를 고려할 때, ClickHouse로부터 애플리케이션에서 작성되는 데이터의 양과 규모에 따라 외부의 중간 시스템 사용을 허용하는 것이 최선의 선택일 것입니다.

따라서, 애플리케이션이 현재 운영 중인 규모와 관계없이 ClickHouse에 데이터를 저장할 수 있는 추상화를 개발하고자 합니다. 또한:

  • 애플리케이션이 성능 및/또는 규모 요구 사항이 시간이 지남에 따라 변경될 경우 다른 기술로 전환할 수 있도록 합니다.
  • 백엔드별 관행, 설정 및 인스트루먼테이션, 서비스 검색 등의 모범 사례를 애플리케이션이 일관되게 활용할 수 있도록 한 곳에 인코딩할 수 있도록 합니다.

설계 및 구현

핵심 가정

  • 우리는 이전에 언급된 비목표에서 언급된대로 ClickHouse에 데이터를 기록하는 데 중점을 둘 것입니다. ClickHouse에 데이터가 어떻게 들어가는지에 대한 세부 정보는 이 문서에서 (간주적으로) 다루지 않습니다. 이러한 세부 사항 중 일부는 데이터를 생성하는 애플리케이션으로 위임됩니다. 즉, 이 추상화를 사용할 수 있다면 그들은 ClickHouse에 데이터를 기록할 수 있어야 합니다.

  • 우리는 다른 스토리지 백엔드의 선택을 이 설계의 범위를 벗어나는 사항이므로, 해당되는 블루프린트나 에픽에 이 선택을 위임할 것입니다. ClickHouse를 데이터의 최종 목적지로하는 이 문서는 이것에 관해 직접 또는 간접적으로 (큐잉/일괄 처리 시스템을 통해) 데이터를 기록하는 것에 대해서만 이야기합니다.

아키텍처

아키텍처

데이터를 기록하는 추상화를 갖는 것은 클라이언트 측 인스트루멘테이션을 백엔드에 독립적으로 유지하고, 어디서 실행되는지에 따라 코드 경로를 전환할 수 있도록 도와줍니다.

예상 설정은 다음과 같아야 합니다:

Gitlab::Database::Writer.config do |config|
  #
  # sync 모드를 사용할 때, 데이터는 직접 ClickHouse에 기록되므로 백엔드는 ClickHouse라고 가정됩니다
  config.mode = :sync OR :async
  config.backend = :clickhouse # optional
  # OR
  #
  # async 모드를 사용할 때, 데이터는 우선 중간 시스템에 기록되고, 그런 다음 ClickHouse에 비동기적으로 기록됩니다
  config.mode = :async
  config.backend = :pubsub OR :kafka OR :otherbackend
  #
  # 그런 다음 특정 백엔드 구성
  #
  config.url = 'tcp://user:pwd@localhost:9000/database'
  # 예를 들어, 직렬화기는 데이터의 전송 방법을 정의하는 데 도움이 됩니다
  config.json_serializer = ClickHouse::Serializer::JsonSerializer
  # ...
end
# 애플리케이션별 처리 수행
# 최종적으로 방금 작성한 객체를 사용하여 데이터 기록
Gitlab::Database::Writer.write(
  Gitlab::Database::Model::MyTable,
  [{ id: 1, foo: 'bar' }],
)

우리는 Gitlab::Database::Writer.backend를 가능한 한 백엔드별 클라이언트 구현과 가깝게 유지할 것입니다. 바닐라 클라이언트를 감싸는 것이 허용되는 한 그 클라이언트의 기능을 활용하면서도 백엔드에 대한 서비스 발견과 같은 주변적인 고려 사항을 다룰 수 있습니다.

반복

이 프로젝트의 광범위한 범위와 실제 사용에 대한 피드백 필요성을 고려하여, 우리는 다음과 같이 여러 반복을 거쳐 제안된 추상화를 구축하기로 결정했습니다.

반복 1 - sync 모드가 활성화된 쓰기 추상화 개발

먼저, 사용자가 ClickHouse에 데이터를 기록하기 시작할 수 있는 간단한 쓰기 추상화를 연구하고 개발합니다. 이렇게 함으로써 우리의 기선 선택이 되는 클라이언트가 가능한 많은 사용 사례의 요구를 충족하기에 충분하도록 충분한 연구가 되고 사용자 피드백을 모아 쓰기 API/인터페이스를 개선할 수 있습니다.

이러한 피드백과 ClickHouse를 환경 전반에 걸쳐 배포하는 방식에 대한 추가 개발을 고려하면, 이러한 추상화에 연결하여 연결 풀링, 서비스 발견 등과 같은 세부 정보를 추상화할 필요가 있을 것입니다.

이터레이션 2 - 스키마 및 데이터 유효성 검사 지원 추가

다음 이터레이션에서는 스키마 사용 및 유효성 검사 지원을 추가할 계획입니다. 이는 모델 정의를 명확하게 유지하고 삽입될 데이터를 유효성 검사하는 데 도움이 됩니다.

이터레이션 3 - 비동기 모드 지원 및 하나의 백엔드로 PoC 추가

상기 두 개의 이터레이션이 잘 실행된 후, 클라이언트가 ClickHouse에 데이터를 비동기적으로 쓰기 전에 중간 데이터 저장소로 데이터를 쓰는 지원을 추가하여 쓰기 추상화를 확장할 수 있습니다. 이러한 구현을 적어도 하나의 백엔드로 프로토타입화할 것을 목표로 합니다.

추가적인 이터레이션

백엔드에 대한 추상화가 수신 인터페이스가 되면서 클라이언트가 상호 작용할 수 있는, 내부에서 해결할 수 있는 다양한 유즈케이스가 있습니다. 일부는 다음과 같습니다:

  • 여러 소스로부터의 제로 구성 데이터 수신
  • 여러 소스에서 데이터 동적으로 보강
  • 장기 보존 데이터 저장소로 데이터 언로드

가능한 백엔드 구현

  • ClickHouse에 직접 쓰는 애플리케이션
    • 애플리케이션 로컬 메모리 큐/일괄 처리로 데이터 큐잉
    • 애플리케이션 로컬 영구적인 큐잉/일괄 처리로 데이터 큐잉
  • ClickHouse에 기록하기 전에 데이터를 비로컬 큐잉/일괄 처리

비로컬 백엔드 사용 시 추가 복잡성

  • 처리 백엔드에서 데이터를 읽고 신뢰할 수 있게 ClickHouse에 쓰기 위해 추가적인 프로세스/하위 시스템 실행이 필요합니다.
  • 처리 백엔드를 통한 추가적인 이동은 이 데이터가 ClickHouse에 얼마나 빨리 도착하는지에 딜레이가 발생할 수 있음을 의미합니다.

상기 점들은 애플리케이션의 추가 복잡성을 설명하지만, 대규모 데이터 수집이 필요한 경우에 유효한 교환으로 취급될 수 있습니다.

여러 차원에서 백엔드 비교

차원 CHProxy Redis Google PubSub Apache Kafka
작업 간단함 간단함 관리됨 비단순함, 복잡함
데이터 보존 비내구성 비내구성 내구성 내구성
성능 좋음 좋음 높음 높음
데이터 스트리밍 없음 최소 좋음 최상
셀프 매니지드 환경에 적합 간단함 간단함 - 복잡함

참고 문헌