매일 320TB의 데이터가 추가됩니다. ClickHouse에서 ByConity로 마이그레이션한 후 쿼리 성능이 매우 안정적입니다!

배경 소개

ByConity는 다양한 비즈니스 시나리오에 적합하며 실시간 데이터 액세스, 크고 넓은 테이블의 집계 쿼리, 대용량 데이터에 대한 복잡한 분석 및 계산, 다중 테이블 상관 쿼리에서 매우 우수한 성능을 제공합니다. 실제 비즈니스 시나리오를 통해 본 행동분석 시스템을 소개하겠습니다. 본 행동분석 시스템은 다차원적인 사용자 행동분석 플랫폼을 기반으로 이벤트 분석, 리텐션 분석, 전환 분석, 사용자 그룹화, 분석 등 다양한 분석 방법과 시나리오를 제공합니다. 사용자 유지. 이 기사에서는 원래 ClickHouse 클러스터를 사용할 때 다차원적인 사용자 행동 분석 플랫폼이 직면하는 문제와 과제를 소개하고, ByConity 마이그레이션 후 이러한 문제를 해결하고 비즈니스에 이점을 가져오는 방법을 소개합니다.

그림 1 행동 분석 시스템 아키텍처 설계

문제와 과제

초기에는 ClickHouse 클러스터에 이 시스템을 구축했지만, 사업의 급속한 발전으로 인해 하루 최대 신규 데이터 양이 320TB를 넘어섰습니다. 새로운 행이 2조 3천억 개를 초과하고 사용자 데이터 차원이 20,000개를 초과했습니다. 반면, 사용자 쿼리 요구 사항은 더 유연하고 다양하며 세부 쿼리, 집계 쿼리 및 대화형 분석 쿼리를 동시에 지원해야 합니다. 빠른 응답 결과를 제공합니다. 또한, 데이터 양이 지속적으로 증가함에 따라(연간 성장률 35%) 이러한 대규모 데이터 증가로 인한 과제를 지원할 수 있을 뿐만 아니라 특정 범위 내에서 비용 증가율을 제어할 수 있어야 합니다.

하지만 기존 ClickHouse 클러스터에서는 이 작업을 수행하기가 어렵습니다. 그 이유는 ClickHouse가 Shared-Nothing 아키텍처를 기반으로 하기 때문입니다. 각 노드는 독립적이며 스토리지 리소스를 공유하지 않습니다. 따라서 컴퓨팅 리소스와 스토리지 리소스가 밀접하게 결합되어 다음과 같은 문제가 발생합니다.

확장 및 축소 비용이 높아지고 데이터 마이그레이션이 포함되어 필요에 따라 실시간으로 확장 및 축소할 수 없게 되어 리소스 낭비와 통제할 수 없는 비용이 발생합니다.
긴밀하게 결합된 아키텍처로 인해 다중 테넌트가 공유 클러스터 환경에서 서로 상호 작용하여 사용자 쿼리가 서로 영향을 미치게 됩니다.
클러스터의 노드에 대한 읽기와 쓰기는 동일한 노드에서 완료되므로 읽기와 쓰기는 서로 영향을 미칩니다.
다중 테이블 조인 작업과 같은 복잡한 쿼리에 대한 성능 지원은 그리 좋지 않으며 쿼리에 대한 사용자의 다양한 요구를 충족할 수 없습니다.

기술선택

이에 따라 2022년 초부터 컴퓨팅과 스토리지 분리 아키텍처를 갖춘 ByConity를 메인 OLAP 엔진으로 사용하기 시작했습니다. ByConity는 컴퓨팅-스토리지 분리 아키텍처를 채택하고 컴퓨팅-스토리지 분리, 탄력적인 확장 및 축소, 멀티 테넌트 리소스 격리, 데이터 읽기 및 쓰기의 강력한 일관성과 같은 여러 주요 기능을 지원하는 오픈 소스 클라우드 네이티브 데이터 웨어하우스입니다. . ByConity는 컬럼 저장, 벡터화된 실행, MPP 실행, 쿼리 최적화 등과 같은 주류 OLAP 엔진 최적화를 활용하여 탁월한 읽기 및 쓰기 성능을 제공할 수 있습니다.

그림 2 ByConity 3계층 기술 아키텍처 다이어그램

ByConity는 오픈소스 ClickHouse 아키텍처를 기반으로 한 업그레이드로, 컴퓨팅과 스토리지를 각 노드에서 로컬로 관리하던 기존 아키텍처를 전체 클러스터의 모든 작업을 통합 관리하는 아키텍처로 전환합니다. 분산 스토리지는 각 컴퓨팅 노드를 무상태 순수 컴퓨팅 노드로 만들고 분산 스토리지의 확장 기능과 컴퓨팅 노드의 무상태 특성을 사용하여 동적 확장 및 축소를 달성합니다. 이러한 개선으로 인해 ByConity는 다음과 같은 중요한 기능을 갖게 되었습니다.

리소스 격리 : 테넌트가 서로 영향을 받지 않도록 서로 다른 테넌트의 리소스를 격리합니다.
읽기 및 쓰기 분리 : 읽기 작업과 쓰기 작업이 서로 영향을 미치지 않도록 컴퓨팅 리소스와 스토리지 리소스를 분리합니다.
탄력적 확장 및 축소 : 탄력적 확장 및 축소를 지원하며 컴퓨팅 리소스를 실시간 및 요청 시 확장 및 축소할 수 있어 리소스의 효율적인 활용이 보장됩니다.
데이터의 강력한 일관성 : 데이터 읽기 및 쓰기의 강력한 일관성은 데이터가 항상 최신 상태를 유지하고 읽기와 쓰기 사이에 불일치가 없음을 보장합니다.
고성능 : 컬럼 저장, 벡터화된 실행, MPP 실행, 쿼리 최적화 등과 같은 주류 OLAP 엔진 최적화를 채택하여 탁월한 읽기 및 쓰기 성능을 제공합니다.

사업 소득

ByConity를 도입한 후 전체 성능은 91%에 도달할 수 있으며 사용자의 피드백 조사를 통해 모든 사용자 쿼리가 10초 이내에 완료될 수 있으며 이 성능 지표도 사용자가 허용할 수 있는 범위 내에 있습니다. ByConity로의 마이그레이션으로 인한 전반적인 이점과 경험을 요약하면 다음과 같습니다.

리소스 선점을 방지하고 쿼리 성능이 100% 안정적인지 확인하세요 .

원래 ClickHouse 클러스터에서는 리소스 혼잡 문제가 자주 발생했습니다. ClickHouse는 리소스 격리 및 테넌트 격리를 달성하지 못했기 때문에 여러 사용자가 쿼리를 위해 클러스터를 공유하면 한 사용자가 리소스를 쿼리하면 오버헤드가 매우 높아집니다. 관련 리소스 선점으로 인해 이 클러스터의 모든 공유 사용자 쿼리가 불안정해지고 서비스 품질이 만족될 수 없습니다. 그러나 ByConity로 마이그레이션한 후에는 컴퓨팅 그룹이 완전히 물리적으로 격리되므로 서로 다른 사용자의 쿼리가 서로 영향을 받지 않고 전체 쿼리 성능이 91%에 도달할 수 있습니다. 10초 안에 완료할 수 있습니다. 또한 ByConity는 자체 개발한 복잡한 쿼리 링크, 자체 개발한 디스크 캐시를 제공하여 콜드 데이터 읽기를 줄이고 자주 사용되는 인덱스를 제공하며, 핫 읽기 효율성도 원본 ClickHouse 클러스터보다 우수합니다. ClickHouse 클러스터, ByConity 클러스터의 성능 손실은 10% 이내입니다.

운영 및 유지 관리 비용이 저렴하고 결함이 있는 노드를 몇 초 만에 교체할 수 있습니다 .

원래 클릭하우스 클러스터에서는 클러스터 내의 노드 하나가 손상된 것으로 확인되면 전체 머신을 내려 수리해야 하는데, 이는 클릭하우스의 컴퓨팅 리소스, 스토리지 리소스, 메타데이터 정보가 모두 이 노드에 있기 때문이다. 이는 소규모 클러스터와 같습니다. 컴퓨팅 리소스가 손실되고 스토리지 복사본이 손실됩니다. 새 노드를 교체하기 전에 손상된 노드의 로컬 디스크를 백업하고 새 노드로 마이그레이션해야 합니다. 높고 데이터 일관성을 보장하기 어렵습니다. ByConity의 경우 컴퓨팅 그룹이 손상되면 컴퓨팅 그룹은 데이터를 저장하지 않고 상태 비저장 컴퓨팅 노드만 포함하기 때문에 새로운 컴퓨팅 그룹으로 교체하면 됩니다. 데이터의 신뢰성과 일관성은 HDFS에서 제공됩니다. 로컬 핫 읽기 데이터 캐시의 손실이 비즈니스 쿼리 성능에 따라 제어 가능하도록 보장합니다. 이 부분은 주로 ByConity 스토리지 및 컴퓨팅 분리 아키텍처의 이점을 얻습니다.

센서리스 확장 및 수축 으로 자원 비용 절감:

ByConity는 Kubernetes의 탄력적인 확장성을 기반으로 하는 모듈식 및 컨테이너형 배포이며, 머신이 충분하면 무한정 확장이 가능합니다. ByConity의 노드는 상태 비저장 컴퓨팅 노드일 뿐이므로 이를 직접 제거해도 전체 클러스터에 거의 영향을 미치지 않으므로 걱정할 필요가 없습니다. 또한 적응형 스케줄링은 느린 노드를 방지하고 처리량 기능을 향상하며 노드 리소스 활용도를 향상시키는 데 사용됩니다. 동시에 ByConity의 압축률은 매우 높습니다. 해당 비즈니스 중 하나를 예로 들면 매일 460TB의 데이터가 추가되어 압축 후 100TB에 도달하며 압축률은 65%입니다. 극단적인 경우에는 더 많은 스토리지를 소비하는 ZSTD 및 기타 압축 방법입니다.

데이터 일관성이 강력하게 보장되며 유지 관리 복잡성은 0에 가깝습니다 .

ByConity로 마이그레이션한 후 데이터 일관성 문제를 완전히 해결했습니다. ByConity에는 로컬 마스터-슬레이브 동기화 문제가 없으며 데이터 일관성 문제는 HDFS/S3 등과 같은 기본 객체 스토리지를 통해 직접 해결되기 때문입니다. 이러한 방식으로 일관성 유지 관리의 복잡성이 크게 줄어들고 오류 확률도 낮아집니다. 현재 데이터 일관성 문제를 보고하는 사용자는 거의 없습니다. 그러나 ClickHouse 클러스터는 노드 간 통신을 통해 여러 복사본으로 유지 관리되고 일관성 문제는 일관성 대기열을 통해 유지되기 때문에 이전에도 자주 발생했습니다. 또한 ByConity는 HDFS를 통해 데이터 파일에 직접 액세스할 수 있습니다. 다양한 컴퓨팅 엔진은 다양한 커넥터에 적응하여 데이터를 읽고 범용 기능을 갖습니다.

미래 전망

1년 반의 실제 탐색 끝에 ByConity는 내부적으로 사용되는 주요 OLAP 엔진이 되었으며 나중에 많은 수의 사용자와 데이터가 이전되어 원래 ClickHouse 클러스터를 대체하게 됩니다. ByConity는 컴퓨팅과 스토리지가 분리된 OLAP 엔진으로서 고성능, 높은 확장성, 높은 안정성이라는 장점을 가지고 있으며 대규모 데이터 처리 및 분석 요구를 충족할 수 있음을 알 수 있습니다. 동시에 커뮤니티 내 소통과 커뮤니티 https://github.com/ByConity/ByConity/issues/26에서 공개한 로드맵 토론을 통해 ByConity는 앞으로 다음과 같은 방향에 중점을 둘 예정입니다.

실행 계층의 다단계 실행, ETL 기능 등을 지원합니다.
Hudi, Iceberg 등과 같은 데이터 레이크 연합 쿼리를 지원합니다.

ByConity 커뮤니티는 많은 사용자를 보유하고 있으며 매우 개방적인 커뮤니티입니다. Github에서 우리와 함께 공동 구축에 대해 논의할 수 있도록 초대합니다. 또한 WeChat 그룹, Feishu 그룹 또는 Discord에 가입하여 커뮤니케이션에 참여할 수도 있습니다.

GitHub: https://github.com/ByConity/ByConity