실제 애플리케이션에서 ClickHouse를 사용하는 이론 및 실제. 알렉산더 자이체프 (2018)

현재 거의 모든 곳에 많은 데이터가 있음에도 불구하고 분석 데이터베이스는 여전히 매우 이국적입니다. 그들은 잘 알려지지 않았으며 효과적으로 사용할 수 없습니다. 많은 사람들이 다른 시나리오를 위해 설계된 MySQL 또는 PostgreSQL로 계속해서 "선인장을 먹습니다", NoSQL로 인해 어려움을 겪거나 상용 솔루션에 대해 초과 비용을 지불합니다. ClickHouse는 게임의 규칙을 변경하고 분석 DBMS의 세계에 진입하기 위한 임계값을 크게 낮춥니다.

BackEnd Conf 2018의 보고서이며 발표자의 허가를 받아 게시됩니다.

나는 누구이며 ClickHouse에 대해 이야기하는 이유는 무엇입니까? 저는 ClickHouse를 사용하는 LifeStreet의 개발 이사입니다. 또한 저는 Altinity의 창립자입니다. ClickHouse를 홍보하고 Yandex가 ClickHouse를 더욱 성공적으로 만들 수 있도록 돕는 Yandex 파트너입니다. 또한 ClickHouse에 대한 지식을 공유할 준비가 되었습니다.

그리고 저는 Petya Zaitsev의 형제가 아닙니다. 나는 종종 이것에 대해 묻는다. 아니요, 우리는 형제가 아닙니다.

ClickHouse가:

• 매우 빠르고,
• 아주 편안한
• Yandex에서 사용됩니다.

어떤 회사에서 어떻게 사용되는지는 조금 덜 알려져 있습니다.

Yandex를 제외하고 ClickHouse가 사용되는 이유, 위치 및 방법을 알려 드리겠습니다.

다른 회사에서 ClickHouse의 도움으로 특정 작업을 해결하는 방법, 작업에 사용할 수 있는 ClickHouse 도구 및 다른 회사에서 사용된 방법을 알려드립니다.

다른 각도에서 ClickHouse를 보여주는 세 가지 예를 선택했습니다. 재미있을 것 같아요.

첫 번째 질문은 "ClickHouse가 필요한 이유는 무엇입니까?"입니다. 꽤 뻔한 질문인 것 같지만 그에 대한 대답은 하나 이상입니다.

• 첫 번째 대답은 성능입니다. ClickHouse는 매우 빠릅니다. ClickHouse의 분석도 매우 빠릅니다. 다른 것이 매우 느리거나 매우 나쁜 경우에 자주 사용할 수 있습니다.
• 두 번째 대답은 비용입니다. 그리고 무엇보다도 확장 비용입니다. 예를 들어 Vertica는 정말 훌륭한 데이터베이스입니다. 테라바이트의 데이터가 많지 않은 경우 매우 잘 작동합니다. 그러나 수백 테라바이트 또는 페타바이트의 경우 라이센스 및 지원 비용이 상당히 많이 듭니다. 그리고 비싸다. ClickHouse는 무료입니다.
• 세 번째 대답은 운영 비용입니다. 이것은 약간 다른 접근법입니다. RedShift는 훌륭한 아날로그입니다. RedShift에서는 매우 빠르게 결정을 내릴 수 있습니다. 그것은 잘 작동하지만 동시에 매시간, 매일, 매달 아마존에 상당히 비싼 서비스를 지불하게 될 것입니다. 왜냐하면 이것은 상당히 비싼 서비스이기 때문입니다. 구글 빅쿼리도 마찬가지다. 누군가가 그것을 사용했다면 그는 거기에서 여러 요청을 실행하고 갑자기 수백 달러의 청구서를 받을 수 있다는 것을 알고 있습니다.

ClickHouse에는 이러한 문제가 없습니다.

ClickHouse는 현재 어디에 사용됩니까? Yandex 외에도 ClickHouse는 다양한 비즈니스 및 회사에서 사용됩니다.

• 우선 이것은 웹 애플리케이션 분석입니다. 이것은 Yandex에서 온 사용 사례입니다.
• 많은 AdTech 회사에서 ClickHouse를 사용합니다.
• 다양한 소스의 트랜잭션 로그를 분석해야 하는 수많은 회사.
• 여러 회사에서 ClickHouse를 사용하여 보안 로그를 모니터링합니다. 그들은 ClickHouse에 업로드하고 보고서를 작성하며 필요한 결과를 얻습니다.
• 회사는 이를 재무 분석에 사용하기 시작했습니다. 즉, 점차 대기업도 ClickHouse에 접근하고 있습니다.
• 클라우드 플레어. ClickHouse를 팔로우하는 사람이라면 이 회사의 이름을 들어봤을 것입니다. 이것은 커뮤니티의 필수 기여자 중 하나입니다. 그리고 그들은 매우 진지한 ClickHouse 설치를 가지고 있습니다. 예를 들어, 그들은 ClickHouse용 Kafka 엔진을 만들었습니다.
• 통신 회사가 사용하기 시작했습니다. 여러 회사에서 개념 증명 또는 이미 생산 중인 ClickHouse를 사용합니다.
• 한 회사는 ClickHouse를 사용하여 생산 프로세스를 모니터링합니다. 그들은 미세 회로를 테스트하고 많은 매개 변수를 작성하며 약 2 가지 특성이 있습니다. 그런 다음 게임이 좋은지 나쁜지 분석합니다.
• 블록체인 분석. Bloxy.info와 같은 러시아 회사가 있습니다. 이더리움 네트워크 분석입니다. ClickHouse에서도 이 작업을 수행했습니다.

그리고 크기는 중요하지 않습니다. 하나의 작은 서버를 사용하는 회사가 많습니다. 그리고 그는 그들이 문제를 해결하도록 허용합니다. 그리고 더 많은 회사에서 많은 서버 또는 수십 대의 서버로 구성된 대규모 클러스터를 사용합니다.

그리고 기록을 보면 다음과 같습니다.

• Yandex: 500개 이상의 서버, 하루에 25억 개의 레코드를 저장합니다.
• LifeStreet: 60개의 서버, 하루에 약 75억 개의 기록. Yandex보다 서버 수가 적고 레코드가 더 많습니다.
• CloudFlare: 서버 36개, 하루에 200억 개의 레코드를 저장합니다. 서버는 훨씬 적고 더 많은 데이터를 저장합니다.
• Bloomberg: 102개의 서버, 하루에 약 XNUMX조 건의 항목. 기록 보유자.

지리적으로 이것은 또한 많습니다. 여기 이 지도는 전 세계에서 ClickHouse가 사용되고 있는 위치에 대한 히트맵을 보여줍니다. 러시아, 중국, 미국이 여기에서 분명히 두드러집니다. 유럽 ​​국가는 거의 없습니다. 그리고 4개의 클러스터가 있습니다.

이것은 비교 분석이므로 절대 수치를 찾을 필요가 없습니다. 이것은 Altinity 웹 사이트에서 러시아어를 사용하는 자료가 없기 때문에 영어 자료를 읽는 방문자에 대한 분석입니다. 그리고 러시아, 우크라이나, 벨로루시, 즉 커뮤니티에서 러시아어를 사용하는 부분은 가장 많은 사용자입니다. 그런 다음 미국과 캐나다가 온다. 중국이 많이 따라잡고 있습니다. XNUMX개월 전에는 중국이 거의 없었습니다. 이제 중국은 이미 유럽을 추월했고 계속 성장하고 있습니다. 구 유럽도 그다지 뒤처지지 않았으며 이상하게도 ClickHouse 사용의 리더는 프랑스입니다.

내가 왜이 모든 것을 말하고 있습니까? ClickHouse가 빅 데이터 분석을 위한 표준 솔루션이 되고 있으며 이미 많은 곳에서 사용되고 있음을 보여주기 위해. 당신이 그것을 사용한다면, 당신은 올바른 추세에 있습니다. 아직 사용하지 않는다면 혼자 남겨질 것을 두려워할 필요가 없으며 이미 많은 사람들이 이 일을 하고 있기 때문에 아무도 당신을 도와주지 않을 것입니다.

다음은 여러 회사에서 실제 ClickHouse를 사용하는 예입니다.

• 첫 번째 예는 광고 네트워크: Vertica에서 ClickHouse로의 마이그레이션입니다. 그리고 저는 Vertica에서 전환했거나 전환 과정에 있는 몇몇 회사를 알고 있습니다.
• 두 번째 예는 ClickHouse의 트랜잭션 스토리지입니다. 이것은 반패턴에 기반한 예제입니다. 개발자의 조언에 따라 ClickHouse에서 수행해서는 안 되는 모든 작업이 여기에서 수행됩니다. 그리고 그것은 매우 효과적으로 수행되어 작동합니다. 그리고 일반적인 트랜잭션 솔루션보다 훨씬 더 잘 작동합니다.
• 세 번째 예는 ClickHouse의 분산 컴퓨팅입니다. ClickHouse를 Hadoop 생태계에 통합할 수 있는 방법에 대한 질문이 있었습니다. 매우 사소한 작업을 계산하기 위해 회사가 ClickHouse의 맵 축소 컨테이너와 유사한 작업을 수행하고 데이터 현지화를 추적하는 등의 작업을 수행한 예를 보여 드리겠습니다.

• LifeStreet는 광고 네트워크와 함께 제공되는 모든 기술을 보유한 Ad Tech 회사입니다.
• 그녀는 광고 최적화, 프로그래밍 방식 입찰에 종사하고 있습니다.
• 많은 데이터: 하루에 약 10억 개의 이벤트. 동시에 이벤트는 여러 하위 이벤트로 나눌 수 있습니다.
• 이 데이터에는 많은 고객이 있으며 이들은 사람 일뿐만 아니라 프로그래밍 방식 입찰에 참여하는 다양한 알고리즘입니다.

회사는 길고 험난한 길을 왔습니다. 그리고 나는 HighLoad에서 그것에 대해 이야기했습니다. 첫째, LifeStreet는 MySQL(오라클에서 잠깐 중단됨)에서 Vertica로 이동했습니다. 그리고 그것에 대한 이야기를 찾을 수 있습니다.

그리고 모든 것이 매우 좋았지만 데이터가 증가하고 있고 Vertica가 비싸다는 것이 금방 분명해졌습니다. 따라서 다양한 대안을 모색했다. 그들 중 일부는 여기에 나열되어 있습니다. 실제로 우리는 13년에서 16년 사이에 시장에 나와 있고 기능면에서 거의 적합한 거의 모든 데이터베이스에 대해 개념 증명 또는 때때로 성능 테스트를 수행했습니다. 그리고 나는 또한 HighLoad에서 그들 중 일부에 대해 이야기했습니다.

데이터가 증가했기 때문에 작업은 처음에 Vertica에서 마이그레이션하는 것이 었습니다. 그리고 그들은 수년에 걸쳐 기하급수적으로 성장했습니다. 그런 다음 그들은 선반에 갔지만 그럼에도 불구하고. 그리고 이러한 성장, 일종의 분석이 수행되어야 하는 데이터 양에 대한 비즈니스 요구 사항을 예측하면서 페타바이트가 곧 논의될 것이 분명했습니다. 그리고 페타바이트에 대한 비용은 이미 매우 비싸기 때문에 우리는 갈 대안을 찾고 있었습니다.

어디로 가야? 그리고 오랫동안 어디로 가야할지 명확하지 않았습니다. 한편으로는 상용 데이터베이스가 있고 잘 작동하는 것 같습니다. 일부는 Vertica만큼 잘 작동하고 일부는 더 나쁩니다. 그러나 그들은 모두 비싸고 더 저렴하고 더 나은 것을 찾을 수 없습니다.

반면에 그다지 많지 않은 오픈 소스 솔루션이 있습니다. 즉, 분석의 경우 손가락으로 계산할 수 있습니다. 무료이거나 저렴하지만 느립니다. 그리고 종종 필요하고 유용한 기능이 부족합니다.

그리고 상용 데이터베이스에 있는 좋은 것과 오픈 소스에 있는 모든 무료를 결합할 수 있는 것은 아무것도 없었습니다.

예기치 않게 Yandex가 토끼처럼 모자에서 마술사처럼 ClickHouse를 꺼낼 때까지는 아무것도 없었습니다. 그리고 그것은 예상치 못한 결정이었습니다. 그들은 여전히 ​​"왜? "라는 질문을합니다. 그러나 그럼에도 불구하고.

그리고 2016년 여름에 바로 ClickHouse가 무엇인지 살펴보기 시작했습니다. 그리고 때로는 Vertica보다 더 빠를 수 있다는 것이 밝혀졌습니다. 서로 다른 쿼리에 대해 서로 다른 시나리오를 테스트했습니다. 그리고 쿼리가 조인(조인) 없이 하나의 테이블만 사용한 경우 ClickHouse는 Vertica보다 두 배 빠릅니다.

나는 너무 게으르지 않았고 요 전날 Yandex 테스트를 보았습니다. 여기도 마찬가지입니다. ClickHouse는 Vertica보다 두 배 빠르기 때문에 자주 이야기합니다.

그러나 쿼리에 조인이 있으면 모든 것이 명확하지 않습니다. 그리고 ClickHouse는 Vertica보다 두 배 느릴 수 있습니다. 요청을 약간 수정하고 다시 작성하면 거의 동일합니다. 나쁘지 않다. 그리고 무료입니다.

그리고 테스트 결과를 받고 다른 각도에서 본 LifeStreet는 ClickHouse로 이동했습니다.

올해로 16년차입니다. 쥐가 울고 찔렀는데도 계속 선인장을 먹는다는 농담 같았다. 그리고 이것은 자세히 설명되어 있으며 이에 대한 비디오 등이 있습니다.

따라서 나는 그것에 대해 자세히 이야기하지 않고 결과와 그 당시에 말하지 않은 흥미로운 몇 가지 사항에 대해서만 이야기 할 것입니다.

결과는 다음과 같습니다.

• 성공적인 마이그레이션과 XNUMX년 이상 시스템이 이미 프로덕션 환경에서 작동하고 있습니다.
• 생산성과 유연성이 향상되었습니다. 하루에 짧은 시간 동안 저장할 수 있는 10억 개의 레코드 중 LifeStreet는 이제 하루에 75억 개의 레코드를 저장하고 이 작업을 3개월 이상 수행할 수 있습니다. 피크에서 계산하면 초당 최대 백만 개의 이벤트입니다. 하루에 백만 개 이상의 SQL 쿼리가 이 시스템에 도착하는데, 대부분은 서로 다른 로봇에서 온 것입니다.
• Vertica보다 ClickHouse에 더 많은 서버가 사용되었음에도 불구하고 Vertica에는 다소 비싼 SAS 디스크가 사용되었기 때문에 하드웨어 비용도 절약되었습니다. ClickHouse는 SATA를 사용했습니다. 그리고 왜? Vertica에서 삽입은 동기식이기 때문입니다. 그리고 동기화를 위해서는 디스크 속도가 너무 느려지지 않아야 하고 네트워크 속도도 너무 느려지지 않아야 합니다. 즉, 비용이 많이 드는 작업입니다. 그리고 ClickHouse에서 삽입은 비동기식입니다. 또한 모든 것을 로컬에서 항상 쓸 수 있으며 이에 대한 추가 비용이 없으므로 더 느린 드라이브에서도 Vertika보다 훨씬 빠르게 ClickHouse에 데이터를 삽입할 수 있습니다. 그리고 독서는 거의 같습니다. SATA에서 읽기, RAID에 있으면 충분히 빠릅니다.
• 라이선스에 의해 제한되지 않습니다. 즉, 3개 서버(60개 서버는 하나의 복제본)에 있는 20페타바이트의 데이터와 팩트 및 집계에서 6조 개의 레코드입니다. Vertica에서는 이와 같은 것을 감당할 수 없습니다.

이제 이 예에서 실제적인 사항으로 전환합니다.

• 첫 번째는 효율적인 계획입니다. 많은 것이 스키마에 따라 다릅니다.
• 두 번째는 효율적인 SQL 생성입니다.

일반적인 OLAP 쿼리는 선택입니다. 일부 열은 그룹화 기준으로 이동하고 일부 열은 집계 함수로 이동합니다. 정육면체의 한 조각으로 표현될 수 있는 곳이 있습니다. 전체 그룹 by는 프로젝션으로 생각할 수 있습니다. 이것이 다변량 데이터 분석이라고 불리는 이유입니다.

그리고 종종 이것은 광선을 따라 측면을 따라이 사실의 중심 사실과 특성이있을 때 별 체계의 형태로 모델링됩니다.

그리고 물리적 디자인 측면에서, 그것이 테이블에 어떻게 맞는지, 그들은 보통 정규화된 표현을 합니다. 비정규화할 수 있지만 디스크에 비용이 많이 들고 쿼리에 그다지 효율적이지 않습니다. 따라서 그들은 일반적으로 정규화된 표현, 즉 팩트 테이블과 많은 차원 테이블을 만듭니다.

그러나 ClickHouse에서는 잘 작동하지 않습니다. 두 가지 이유가 있습니다.

• 첫 번째는 ClickHouse에 그다지 좋은 조인이 없기 때문입니다. 즉, 조인이 있지만 좋지 않습니다. 나쁜 동안.
• 두 번째는 테이블이 업데이트되지 않는다는 것입니다. 일반적으로 스타 회로 주변에 있는 이 플레이트에서 무언가를 변경해야 합니다. 예를 들어 고객 이름, 회사 이름 등 그리고 그것은 작동하지 않습니다.

그리고 ClickHouse에는 이것에서 벗어날 방법이 있습니다. 심지어 둘:

• 첫 번째는 사전의 사용입니다. 외부 사전은 99%가 업데이트 등을 통해 스타 스키마의 문제를 해결하는 데 도움이 됩니다.
• 두 번째는 배열을 사용하는 것입니다. 배열은 정규화와 관련된 조인 및 문제를 제거하는 데도 도움이 됩니다.

• 조인이 필요하지 않습니다.
• 업그레이드 가능. 2018년 XNUMX월부터 사전을 부분적으로, 즉 변경된 항목을 업데이트할 수 있는 문서화되지 않은 기회(문서에서 찾을 수 없음)가 나타났습니다. 실제로는 테이블과 같습니다.
• 항상 메모리에 있으므로 디스크에 있는 테이블인 경우보다 사전 작업과 조인이 더 빠르고 캐시에 있다는 것이 아직 사실이 아니며 대부분 그렇지 않을 가능성이 큽니다.

• 조인도 필요하지 않습니다.
• 이것은 간결한 일대다 표현입니다.
• 제 생각에는 어레이는 괴짜들을 위해 만들어졌습니다. 이들은 람다 함수 등입니다.

이것은 빨간색 단어가 아닙니다. 이것은 매우 간단하고 우아한 방식으로 많은 일을 할 수 있게 해주는 매우 강력한 기능입니다.

배열을 해결하는 데 도움이 되는 일반적인 예입니다. 다음 예는 간단하고 명확합니다.

• 태그로 검색합니다. 거기에 해시태그가 있고 해시태그로 게시물을 찾고 싶다면.
• 키-값 쌍으로 검색합니다. 값이 있는 속성도 있습니다.
• 다른 것으로 변환해야 하는 키 목록 저장.

이러한 모든 작업은 어레이 없이 해결할 수 있습니다. 태그는 어떤 줄에 넣고 정규 표현식으로 선택하거나 별도의 테이블에서 선택할 수 있지만 조인을 해야 합니다.

그리고 ClickHouse에서는 아무 것도 할 필요가 없습니다. 해시태그에 대한 문자열 배열을 설명하거나 키-값 시스템에 대한 중첩 구조를 만드는 것으로 충분합니다.

중첩 구조는 최고의 이름이 아닐 수 있습니다. 이들은 이름의 공통 부분과 일부 관련 특성이 있는 두 개의 어레이입니다.

그리고 태그로 검색하는 것은 매우 쉽습니다. 기능을 가지고 has, 배열에 요소가 포함되어 있는지 확인합니다. 여러분, 우리 회의와 관련된 모든 항목을 찾았습니다.

subid로 검색하는 것은 좀 더 복잡합니다. 먼저 키의 인덱스를 찾은 다음 이 인덱스가 있는 요소를 가져와서 이 값이 필요한지 확인해야 합니다. 그러나 매우 간단하고 컴팩트합니다.

여러분이 쓰고 싶은 정규 표현식을 한 줄에 모두 담았다면, 우선 어색할 것입니다. 둘째, 두 개의 어레이보다 훨씬 오래 작동했습니다.

다른 예시. ID를 저장하는 배열이 있습니다. 그리고 그것들을 이름으로 번역할 수 있습니다. 기능 arrayMap. 이것은 전형적인 람다 함수입니다. 거기에 람다 식을 전달합니다. 그리고 그녀는 사전에서 각 ID의 이름 값을 꺼냅니다.

검색도 같은 방법으로 할 수 있습니다. 요소가 일치하는지 확인하는 조건자 함수가 전달됩니다.

이러한 것들은 회로를 크게 단순화하고 많은 문제를 해결합니다.

그러나 우리가 직면한 다음 문제는 효율적인 쿼리입니다.

• ClickHouse에는 쿼리 플래너가 없습니다. 절대적으로하지.
• 그럼에도 불구하고 복잡한 쿼리는 여전히 계획해야 합니다. 어떤 경우에?
• 쿼리에 여러 조인이 있는 경우 하위 선택으로 래핑합니다. 그리고 그들이 실행되는 순서가 중요합니다.
• 그리고 두 번째 - 요청이 배포되는 경우. 분산 쿼리에서는 가장 안쪽의 하위 선택만 분산 실행되고 나머지는 모두 연결하여 실행한 한 서버로 전달되기 때문입니다. 따라서 조인(조인)이 많은 분산 쿼리가 있는 경우 순서를 선택해야 합니다.

그리고 더 간단한 경우에도 때때로 스케줄러의 작업을 수행하고 쿼리를 약간 다시 작성해야 할 수도 있습니다.

다음은 예입니다. 왼쪽에는 상위 5개 국가를 표시하는 쿼리가 있습니다. 제 생각에는 2,5초가 걸립니다. 그리고 오른쪽에는 동일한 쿼리이지만 약간 다시 작성되었습니다. 문자열로 그룹화하는 대신 키(int)로 그룹화하기 시작했습니다. 그리고 더 빠릅니다. 그런 다음 결과에 사전을 연결했습니다. 2,5초 대신 요청에 1,5초가 걸립니다. 좋습니다.

다시 쓰기 필터가 있는 유사한 예입니다. 다음은 러시아에 대한 요청입니다. 5초 동안 실행됩니다. 문자열이 아니라 숫자를 러시아와 관련된 키 집합과 다시 비교하는 방식으로 다시 작성하면 훨씬 빠를 것입니다.

그러한 트릭이 많이 있습니다. 또한 이미 빠르게 실행 중이거나 반대로 느리게 실행 중이라고 생각되는 쿼리의 속도를 크게 높일 수 있습니다. 그들은 더 빨리 만들 수 있습니다.

• 분산 모드에서 최대 작업.
• int로 했던 것처럼 최소 유형별로 정렬합니다.
• 조인(조인), 사전이 있는 경우 최소한 부분적으로 그룹화된 데이터가 이미 있을 때 최후의 수단으로 수행하는 것이 좋습니다. 그러면 조인 작업 또는 사전 호출이 더 적게 호출되고 더 빠릅니다. .
• 필터 교체.

제가 보여드린 기술뿐만 아니라 다른 기술도 있습니다. 그리고 그들 모두는 때때로 쿼리 실행 속도를 크게 높일 수 있습니다.

다음 예제로 넘어가겠습니다. 미국 X 회사. 그녀가 무엇을하고 있니?

작업이 있었습니다.

• 광고 거래의 오프라인 연결.
• 다른 바인딩 모델 모델링.

시나리오는 무엇입니까?

예를 들어 일반 방문자는 다른 광고를 통해 한 달에 20 번 사이트를 방문하거나이 사이트를 기억하기 때문에 때때로 광고없이 방문합니다. 일부 제품을 보고 바구니에 넣고 바구니에서 꺼냅니다. 그리고 결국 무언가를 산다.

합리적인 질문: "필요한 경우 누가 광고 비용을 지불해야 합니까?" 그리고 "그에게 영향을 미쳤다면 어떤 광고가 있었습니까?" 즉, 그는 왜 구매했으며 이 사람과 같은 사람들도 구매하도록 하는 방법은 무엇입니까?

이 문제를 해결하기 위해서는 웹사이트에서 발생하는 이벤트를 올바른 방식으로 연결해야 합니다. 즉, 어떻게든 그들 간의 연결을 구축해야 합니다. 그런 다음 분석을 위해 DWH로 보내집니다. 그리고 이 분석을 기반으로 누가 어떤 광고를 표시할지에 대한 모델을 구축합니다.

광고 트랜잭션은 광고 표시에서 시작하여 어떤 일이 발생하고 구매가 발생할 수 있으며 구매 내 구매가 있을 수 있는 일련의 관련 사용자 이벤트입니다. 예를 들어 이것이 모바일 애플리케이션 또는 모바일 게임인 경우 일반적으로 애플리케이션 설치는 무료로 이루어지며 거기에서 무언가를 수행하면 이에 대한 비용이 필요할 수 있습니다. 그리고 사람이 응용 프로그램에 더 많이 쓸수록 더 가치가 있습니다. 그러나이를 위해서는 모든 것을 연결해야합니다.

많은 바인딩 모델이 있습니다.

가장 인기있는 것은 다음과 같습니다.

• 상호작용이 클릭 또는 노출인 마지막 상호작용.
• 첫 번째 상호작용, 즉 사람을 사이트로 데려온 첫 번째 것.
• 선형 조합 - 모두 동일합니다.
• 감쇠.
• 등등.

처음에는 어떻게 작동했습니까? 런타임과 카산드라가 있었습니다. Cassandra는 트랜잭션 스토리지로 사용되었습니다. 즉, 모든 관련 트랜잭션이 여기에 저장되었습니다. 예를 들어 일부 페이지 또는 다른 것을 표시하는 것과 같이 런타임에 일부 이벤트가 발생하면 Cassandra에 요청이 이루어집니다. 그런 사람이 있는지 여부입니다. 그런 다음 이와 관련된 트랜잭션을 얻었습니다. 그리고 연결이 이루어졌습니다.

그리고 요청에 트랜잭션 ID가 있는 것이 운이 좋다면 쉽습니다. 그러나 일반적으로 운이 없습니다. 따라서 마지막 거래나 마지막 클릭이 있는 거래 등을 찾아야 했습니다.

바인딩이 마지막 클릭에 있는 한 모든 것이 잘 작동했습니다. 창을 한 달로 설정하면 하루에 10만 회의 클릭, 한 달에 300억 회의 클릭이 발생하기 때문입니다. 그리고 Cassandra에서는 Runtime이 빠르게 응답해야 하기 때문에 빠르게 실행하려면 메모리에 모두 있어야 하므로 약 10-15개의 서버가 필요했습니다.

그리고 트랜잭션을 디스플레이에 연결하려고 했을 때 즉시 재미가 없는 것으로 판명되었습니다. 그리고 왜? 30배 더 많은 이벤트를 저장해야 함을 알 수 있습니다. 따라서 30배 더 많은 서버가 필요합니다. 그리고 이것은 일종의 천문학적 수치라는 것이 밝혀졌습니다. 런타임에 훨씬 적은 수의 서버가 있음에도 불구하고 링크를 수행하기 위해 최대 500개의 서버를 유지하는 것은 일종의 잘못된 수치입니다. 그리고 그들은 무엇을 해야할지 생각하기 시작했습니다.

그리고 우리는 ClickHouse에 갔다. ClickHouse에서는 어떻게 하나요? 언뜻 보기에 이것은 일련의 안티 패턴인 것 같습니다.

• 트랜잭션이 증가하고 점점 더 많은 이벤트를 연결합니다. 즉, 변경 가능하며 ClickHouse는 변경 가능한 개체와 잘 작동하지 않습니다.
• 방문자가 우리에게 올 때, 우리는 그의 방문 ID로 키로 그의 거래를 꺼내야 합니다. 이것은 포인트 쿼리이기도 하며 ClickHouse에서는 그렇게 하지 않습니다. 일반적으로 ClickHouse에는 대규모 …스캔이 있지만 여기에서는 일부 레코드를 가져와야 합니다. 또한 반패턴입니다.
• 또한 트랜잭션이 json에 있었지만 다시 작성하고 싶지 않았기 때문에 구조화되지 않은 방식으로 json을 저장하고 필요한 경우 무언가를 꺼내고 싶었습니다. 그리고 이것은 또한 반패턴입니다.

즉, 일련의 반패턴입니다.

그럼에도 불구하고 매우 잘 작동하는 시스템을 만드는 것으로 밝혀졌습니다.

무엇을 했습니까? 로그가 던져진 ClickHouse가 레코드로 나뉩니다. ClickHouse에서 로그를 수신한 특성 서비스가 나타났습니다. 그 후 각 항목에 대해 방문 ID별로 아직 처리되지 않았을 수 있는 트랜잭션과 스냅샷, 즉 이미 연결된 트랜잭션, 즉 이전 작업의 결과를 받았습니다. 나는 이미 그들로부터 논리를 만들고 올바른 트랜잭션을 선택하고 새로운 이벤트를 연결했습니다. 다시 로그인했습니다. 로그는 ClickHouse로 돌아갔습니다. 즉, 지속적으로 순환하는 시스템입니다. 게다가 DWH에서 분석을 하러 갔습니다.

잘 작동하지 않는 것은 이러한 형태였습니다. 그리고 ClickHouse를 더 쉽게 만들기 위해 방문 ID로 요청이 있을 때 이러한 요청을 1~000개의 방문 ID 블록으로 그룹화하고 2~000명의 모든 거래를 추출했습니다. 그런 다음 모든 것이 작동했습니다.

ClickHouse 내부를 보면 이 모든 것을 제공하는 기본 테이블이 3개뿐입니다.

로그가 업로드되는 첫 번째 테이블이며 거의 처리 없이 로그가 업로드됩니다.

두 번째 테이블. 구체화된 보기를 통해 이러한 로그에서 아직 속성이 부여되지 않은 이벤트, 즉 관련되지 않은 이벤트가 제거되었습니다. 그리고 구체화된 뷰를 통해 이러한 로그에서 트랜잭션을 가져와 스냅샷을 생성했습니다. 즉, 특별한 구체화된 뷰가 스냅샷, 즉 트랜잭션의 마지막 누적 상태를 구축했습니다.

다음은 SQL로 작성된 텍스트입니다. 몇 가지 중요한 사항에 대해 언급하고 싶습니다.

첫 번째로 중요한 것은 ClickHouse의 json에서 열과 필드를 추출하는 기능입니다. 즉, ClickHouse에는 json 작업을 위한 몇 가지 방법이 있습니다. 그들은 매우 원시적입니다.

visitParamExtractInt를 사용하면 json에서 속성을 추출할 수 있습니다. 즉, 첫 번째 히트가 작동합니다. 이렇게 하면 트랜잭션 ID 또는 방문 ID를 꺼낼 수 있습니다. 이 시간.

둘째, 여기서는 까다로운 구체화된 필드가 사용됩니다. 무슨 뜻이에요? 즉, 테이블에 삽입할 수 없습니다. 즉, 삽입되지 않고 삽입 시 계산되어 저장됩니다. 붙여넣을 때 ClickHouse가 자동으로 작업을 수행합니다. 그리고 나중에 필요한 것은 이미 json에서 빼냈습니다.

이 경우 구체화된 뷰는 원시 행에 대한 것입니다. 그리고 실질적으로 원시 로그가 있는 첫 번째 테이블이 사용됩니다. 그리고 그는 무엇을합니까? 첫째, 정렬을 변경합니다. 즉, 특정인에 대한 트랜잭션을 신속하게 가져와야 하기 때문에 이제 정렬은 방문 ID별로 진행됩니다.

두 번째로 중요한 것은 index_granularity입니다. MergeTree를 본 적이 있다면 일반적으로 index_granularity는 기본적으로 8입니다. 이게 뭐야? 인덱스 희소성 매개변수입니다. ClickHouse에서 색인은 희소하며 모든 항목을 색인화하지 않습니다. 192마다 이 작업을 수행합니다. 그리고 많은 데이터를 계산해야 하는 경우에는 좋지만 적은 경우에는 오버헤드가 크기 때문에 좋지 않습니다. 인덱스 세분성을 줄이면 오버헤드도 줄어듭니다. 메모리가 부족할 수 있으므로 하나로 줄일 수 없습니다. 인덱스는 항상 메모리에 저장됩니다.

Snapshot은 다른 흥미로운 ClickHouse 기능도 사용합니다.

먼저 AggregatingMergeTree입니다. 그리고 AggregatingMergeTree는 argMax를 저장합니다. 즉, 이것은 마지막 타임스탬프에 해당하는 트랜잭션의 상태입니다. 거래는 주어진 방문자에 대해 항상 생성됩니다. 그리고 이 거래의 가장 마지막 상태에서 우리는 이벤트를 추가했고 새로운 상태를 갖게 되었습니다. 다시 ClickHouse를 쳤습니다. 그리고 이 구체화된 뷰에서 argMax를 통해 항상 현재 상태를 얻을 수 있습니다.

• 바인딩은 런타임에서 "분리"됩니다.
• 한 달에 최대 3억 건의 거래가 저장되고 처리됩니다. 이것은 카산드라, 즉 일반적인 트랜잭션 시스템에서보다 훨씬 더 큰 규모입니다.
• 2x5 ClickHouse 서버 클러스터. 5개의 서버와 각 서버에는 복제본이 있습니다. 이것은 클릭 기반 기여를 수행하기 위해 Cassandra에서보다 훨씬 적으며 여기에서는 노출 기반이 있습니다. 즉, 서버 수를 30배로 늘리는 대신 서버 수를 줄이는 데 성공했습니다.

그리고 마지막 사례는 주가 변동의 상관관계를 분석한 금융회사 Y사다.

그리고 과제는 다음과 같았습니다.

• 약 5주가 있습니다.
• 100밀리초마다 따옴표가 알려져 있습니다.
• 10년 동안 축적된 데이터입니다. 분명히 일부 회사는 더 많고 일부는 적습니다.
• 총 약 100억 개의 행이 있습니다.

그리고 변화의 상관관계를 계산할 필요가 있었다.

다음은 두 개의 주식과 시세입니다. 하나가 올라가고 다른 하나가 올라가면 이것은 양의 상관 관계입니다. 즉, 하나는 올라가고 다른 하나는 올라갑니다. 그래프 끝에서와 같이 하나가 올라가고 다른 하나가 내려가면 이는 음의 상관 관계입니다. 즉, 하나가 상승하면 다른 하나는 떨어집니다.

이러한 상호 변화를 분석하면 금융 시장에서 예측할 수 있습니다.

그러나 작업은 어렵습니다. 이를 위해 무엇을 하고 있습니까? 시간, 재고 및 가격이 포함된 100억 개의 레코드가 있습니다. 가격 알고리즘에서 runningDifference의 100억 배를 먼저 계산해야 합니다. RunningDifference는 두 문자열 간의 차이를 순차적으로 계산하는 ClickHouse의 함수입니다.

그리고 그 후에 상관관계를 계산해야 하고, 각 쌍에 대해 상관관계를 계산해야 합니다. 5주의 경우 쌍은 000만입니다. 그리고 이것은 많은 것, 즉 그러한 상관 함수를 계산하는 데 필요한 12,5 배입니다.

그리고 누군가 잊었다면 ͞x와 ͞y는 장군입니다. 샘플링 기대. 즉, 근과 합을 계산할 뿐만 아니라 이 합 안에 또 하나의 합이 더 필요합니다. 많은 계산을 12,5만 번 수행해야 하며 심지어 시간별로 그룹화해야 합니다. 우리는 또한 많은 시간을 가지고 있습니다. 그리고 60초 안에 해야 합니다. 그것은 농담.

ClickHouse가 오기 전에 이 모든 것이 매우 느리게 작동했기 때문에 적어도 어떻게든 시간이 필요했습니다.

그들은 Greenplum의 Spark, Hadoop에서 계산하려고 했습니다. 그리고 이 모든 것이 매우 느리거나 비쌌습니다. 즉, 어떻게 든 계산할 수 있었지만 비용이 많이 들었습니다.

그런 다음 ClickHouse가 등장했고 상황이 훨씬 좋아졌습니다.

상관 관계를 지역화할 수 없기 때문에 데이터 지역성에 문제가 있음을 상기시켜 드립니다. 우리는 데이터의 일부를 한 서버에, 일부를 다른 서버에 두고 계산할 수 없습니다. 모든 데이터가 어디에나 있어야 합니다.

그들은 무엇을 했습니까? 처음에는 데이터가 현지화됩니다. 각 서버는 특정 주식 세트의 가격에 대한 데이터를 저장합니다. 그리고 그것들은 겹치지 않습니다. 따라서 logReturn을 병렬 및 독립적으로 계산할 수 있으며, 이 모든 작업은 지금까지 병렬 및 분산 방식으로 발생합니다.

그런 다음 표현력을 잃지 않으면서 이러한 데이터를 줄이기로 결정했습니다. 배열 사용을 줄입니다. 즉, 각 기간 동안 주식 배열과 가격 배열을 만듭니다. 따라서 훨씬 적은 데이터 공간을 차지합니다. 그리고 그들은 작업하기가 조금 더 쉽습니다. 이들은 거의 병렬 작업입니다. 즉, 부분적으로 병렬로 읽은 다음 서버에 씁니다.

이후에는 복제가 가능합니다. 문자 "r"은 이 데이터를 복제했음을 의미합니다. 즉, 세 서버 모두에 동일한 데이터가 있습니다. 이들은 어레이입니다.

그런 다음 계산해야 하는 12,5만 개의 상관 관계 집합에서 특수 스크립트를 사용하여 패키지를 만들 수 있습니다. 즉, 2쌍의 상관 관계가 있는 500개의 작업입니다. 그리고 이 작업은 특정 ClickHouse 서버에서 계산됩니다. 그는 데이터가 동일하고 순차적으로 계산할 수 있기 때문에 모든 데이터를 가지고 있습니다.

다시 봐도 이런 모습입니다. 먼저 시간, 주식, 가격과 같은 구조의 모든 데이터가 있습니다. 그런 다음 logReturn, 즉 동일한 구조의 데이터를 계산했지만 가격 대신 이미 logReturn이 있습니다. 그런 다음 그들은 다시 실행되었습니다. 즉, 우리는 주식과 가격에 대한 시간과 groupArray를 얻었습니다. 복제됨. 그런 다음 우리는 많은 작업을 생성하고 ClickHouse에 입력하여 작업을 계산하도록 했습니다. 그리고 그것은 작동합니다.

개념 증명에서 작업은 하위 작업이었습니다. 즉, 더 적은 데이터가 사용되었습니다. 그리고 단 세 개의 서버.

처음 두 단계: Log_return 계산 및 배열 래핑에는 약 XNUMX시간이 걸렸습니다.

그리고 상관계산은 약 50시간이다. 그러나 그들은 몇 주 동안 일을 했기 때문에 50시간으로는 충분하지 않습니다. 큰 성공이었습니다. 세어보면 초당 70번씩 이 클러스터에서 모든 것이 세어졌습니다.

그러나 가장 중요한 것은 이 시스템이 실제로 병목 현상이 없다는 것입니다. 즉, 거의 선형으로 확장됩니다. 그리고 그들은 그것을 확인했습니다. 성공적으로 확장했습니다.

• 올바른 계획은 전투의 절반입니다. 올바른 계획은 필요한 모든 ClickHouse 기술을 사용하는 것입니다.
• Summing/AggregatingMergeTrees는 상태 스냅샷을 특수한 경우로 집계하거나 고려할 수 있는 기술입니다. 그리고 그것은 많은 것을 크게 단순화합니다.
• 구체화된 뷰를 사용하면 하나의 인덱스 제한을 무시할 수 있습니다. 아주 명확하게 말하지는 않았지만 로그를 로드했을 때 원시 로그는 하나의 인덱스가 있는 테이블에 있었고 속성 로그는 테이블에 있었습니다. 즉, 동일한 데이터, 필터링만 되었지만 인덱스는 완전히 기타. 데이터는 같지만 정렬이 다른 것 같습니다. 그리고 구체화된 보기를 사용하면 필요한 경우 이러한 ClickHouse 제한을 우회할 수 있습니다.
• 포인트 쿼리에 대한 인덱스 세분성을 줄입니다.
• 그리고 데이터를 현명하게 분배하고 가능한 한 서버 내에서 데이터를 현지화하십시오. 그리고 가능한 한 요청이 현지화를 사용하는지 확인하십시오.

이 짧은 연설을 요약하면 ClickHouse는 이제 상용 데이터베이스와 오픈 소스 데이터베이스, 즉 특히 분석을 위한 영역을 확고히 점유했다고 말할 수 있습니다. 그는 이 풍경에 완벽하게 들어맞는다. 게다가 ClickHouse가 있으면 InfiniDB가 필요하지 않기 때문에 천천히 다른 사람들을 몰아내기 시작합니다. Vertika가 정상적인 SQL 지원을 제공한다면 곧 필요하지 않을 수 있습니다. 즐기다!

-신고해 주셔서 감사합니다! 매우 흥미로운! Apache Phoenix와의 비교가 있었습니까?

아니요, 비교하는 사람을 본 적이 없습니다. 우리와 Yandex는 다른 데이터베이스와의 모든 ClickHouse 비교를 추적하려고 합니다. 갑자기 무언가가 ClickHouse보다 빠르면 Lesha Milovidov는 밤에 잠을 잘 수 없으며 빠르게 속도를 높이기 시작합니다. 나는 그런 비교를 들어본 적이 없다.

• (Aleksey Milovidov) Apache Phoenix는 Hbase로 구동되는 SQL 엔진입니다. Hbase는 주로 키-값 작업 시나리오용입니다. 각 라인에는 임의의 이름을 가진 임의 개수의 열이 있을 수 있습니다. 이것은 Hbase, Cassandra와 같은 시스템에 대해 말할 수 있습니다. 그리고 정상적으로 작동하지 않는 것은 정확히 무거운 분석 쿼리입니다. 또는 ClickHouse에 대한 경험이 없다면 제대로 작동한다고 생각할 수도 있습니다.

• 감사

  • 좋은 오후에요 분석 하위 시스템이 있기 때문에 이미 이 주제에 상당히 관심이 있습니다. 그러나 ClickHouse를 보면 ClickHouse가 변경 가능한 이벤트 분석에 매우 적합하다는 느낌이 듭니다. 그리고 여러 개의 큰 테이블로 많은 비즈니스 데이터를 분석해야 하는 경우 내가 이해하는 한 ClickHouse가 나에게 적합하지 않습니까? 특히 그들이 변한다면. 이것이 맞습니까, 아니면 이것을 반박할 수 있는 예가 있습니까?

  • 맞습니다. 그리고 이것은 대부분의 전문화된 분석 데이터베이스에 해당됩니다. 변경 가능한 하나 이상의 큰 테이블과 천천히 변경되는 많은 작은 테이블이 있다는 사실에 맞게 조정되었습니다. 즉, ClickHouse는 모든 것을 입력하고 매우 복잡한 쿼리를 작성할 수 있는 Oracle과 다릅니다. ClickHouse를 효과적으로 사용하려면 ClickHouse에서 잘 작동하는 방식으로 체계를 구축해야 합니다. 즉, 과도한 정규화를 피하고, 사전을 사용하고, 긴 링크를 적게 만드십시오. 그리고 이러한 방식으로 체계를 구축하면 ClickHouse에서 유사한 비즈니스 작업을 기존 관계형 데이터베이스보다 훨씬 더 효율적으로 해결할 수 있습니다.

신고해 주셔서 감사합니다! 최신 금융 사례에 대해 질문이 있습니다. 그들은 분석을 가지고 있었습니다. 올라가고 내려가는 방식을 비교하는 것이 필요했습니다. 이 분석을 위해 특별히 시스템을 구축했다고 알고 있습니까? 예를 들어 내일 이 데이터에 대한 다른 보고서가 필요한 경우 스키마를 다시 빌드하고 데이터를 업로드해야 합니까? 즉, 요청을 받기 위해 일종의 사전 처리를 수행하는 것입니까?

물론 이것은 매우 특정한 작업에 ClickHouse를 사용하는 것입니다. 전통적으로 Hadoop 내에서 해결할 수 있습니다. Hadoop의 경우 이는 이상적인 작업입니다. 그러나 Hadoop에서는 매우 느립니다. 제 목표는 일반적으로 완전히 다른 방법으로 해결되는 작업을 ClickHouse가 해결할 수 있지만 동시에 훨씬 더 효율적으로 수행할 수 있음을 입증하는 것입니다. 특정 작업에 맞게 조정됩니다. 비슷한 문제가 있으면 비슷한 방식으로 해결할 수 있음이 분명합니다.

알았습니다. 50시간이 처리되었다고 하셨습니다. 처음부터 언제 데이터를 로드하거나 결과를 얻었습니까?

예, 예.

네, 대단히 감사합니다.

이것은 3 서버 클러스터에 있습니다.

인사말! 신고해 주셔서 감사합니다! 모든 것이 매우 흥미 롭습니다. 기능에 대해 조금 묻지 않고 안정성 측면에서 ClickHouse 사용에 대해 묻겠습니다. 즉, 가지고 있었습니까? 복원해야 했습니까? 이 경우 ClickHouse는 어떻게 작동합니까? 그리고 당신도 복제품을 가지고 있었습니까? 예를 들어 ClickHouse가 여전히 한계를 벗어나 떨어지는 경우 문제가 발생했습니다.

물론 이상적인 시스템은 없습니다. 그리고 ClickHouse에도 자체 문제가 있습니다. 그러나 Yandex.Metrica가 오랫동안 작동하지 않는다는 소식을 들었습니까? 아마 아닐 겁니다. ClickHouse에서 2012-2013년부터 안정적으로 작동하고 있습니다. 내 경험에 대해서도 똑같이 말할 수 있습니다. 우리는 완전한 실패를 한 적이 없습니다. 일부 부분적인 일이 발생할 수 있지만 비즈니스에 심각한 영향을 미칠 만큼 중요한 것은 아닙니다. 그런 일은 일어나지 않았습니다. ClickHouse는 매우 안정적이며 무작위로 충돌하지 않습니다. 당신은 그것에 대해 걱정할 필요가 없습니다. 날것의 것이 아닙니다. 이것은 많은 회사에서 입증되었습니다.

안녕하세요! 당장 데이터 스키마를 고민해야 한다고 하셨습니다. 그런 일이 일어났다면? 내 데이터가 쏟아지고 쏟아지고 있습니다. XNUMX개월이 지났고 이렇게 사는 것이 불가능하다는 것을 이해하고 데이터를 다시 업로드하고 뭔가를 해야 합니다.

이것은 물론 시스템에 따라 다릅니다. 거의 멈추지 않고 이를 수행하는 방법에는 여러 가지가 있습니다. 예를 들어 고유하게 매핑될 수 있는 경우 다른 데이터 구조를 만드는 구체화된 뷰를 생성할 수 있습니다. 즉, ClickHouse를 사용하여 매핑을 허용하는 경우(예: 일부 항목 추출, 기본 키 변경, 분할 변경) 구체화된 보기를 만들 수 있습니다. 기존 데이터를 덮어쓰면 새 데이터가 자동으로 작성됩니다. 그런 다음 Materialized View를 사용하도록 전환한 다음 레코드를 전환하고 이전 테이블을 종료합니다. 이것은 일반적으로 논스톱 방법입니다.

감사합니다.

출처 : habr.com