BigQuery에서 ClickHouse로 이벤트 로그 데이터 분석 환경 개선하기

2024.11.12 - [데이터 엔지니어링] - 유저의 액션 이벤트 로그 설계와 개선 과정

지난 시간에는 Firebase와 BigQuery를 조합하여 로그 이벤트를 수집했다.  데이터를 수집했으니 이제 조회하고 분석에 활용할 차례였다. 일반적으로 데이터 요청 프로세스는 다음과 같았다. 보고 싶은 데이터에 대한 요구사항이 오면 데이터팀에서 해당 요청을 검토한 후, 간단한 경우라면 쿼리로, 복잡한 경우라면 ETL을 통해 데이터를 가공하여 Redash나 Metabase 같은 툴을 이용해 제공하는 방식이었다.

---

문제점

그러나 몇 가지 문제가 있었다. 데이터를 보고 싶은 사람은 많지만, 데이터팀의 인적 자원은 한정되어 있어 모든 요구사항에 맞춰 데이터를 커스텀해줄 수는 없었다. 그래서 가능한 경우 직접 데이터베이스에 접근해 원하는 대로 조회할 수 있게 하고 싶었지만, BigQuery는 그런 용도로 적합하지 않았다.

1. 러닝 커브 존재

BigQuery의 특징 중 하나로 데이터가 Nested 형태로 저장될 수 있어 반복적이거나 계층적인 데이터를 효율적으로 관리할 수 있다. 하지만 이를 분석하려면 UNNEST 함수와 JOIN 등을 사용해야 하므로 쿼리 작성이 복잡해지고, 데이터베이스 경험이 적은 사용자에게는 러닝 커브가 높다. 특히 제일 중요한 이벤트 파라미터나 사용자 속성이 Nested 구조로 저장되어 있어 직관적이지 않고 쿼리 작성이 어렵다.

2. 조회 비용 발생

BigQuery는 스토리지 비용은 저렴하지만, 쿼리 실행 시 처리한 데이터의 양에 따라 비용이 발생한다. 서비스 오픈 이후로 데이터가 지속적으로 쌓여 데이터 양이 상당히 많았고, 쿼리를 실행할 때 데이터 범위를 좁히지 않으면 한 번의 쿼리로도 수십만 원의 비용이 발생하는 경우가 있었다. 따라서 비용 때문에 마음껏 쿼리를 실행하기 어려운 상황이었다.

3. 접근 어려움

GCP의 접근 권한 관리도 문제였다. 권한이나 사용자 관리를 별도로 해야 했고, 이는 우리가 자유롭게 관리할 수 있는 구조가 아니어서 데이터에 접근하는 것 자체가 허들이 되었다.

위에서 언급한 문제들로 인해 인원은 한정되어 있는데 모두가 쉽게 데이터에 접근해서 조회할 수 없었기 때문에, 새로운 분석 파이프라인을 구축하기로 결정했다.

---

새로운 파이프라인

BigQuery의 접근성과 조회 비용 문제를 해결하기 위해 새로운 OLAP DB로의 이전을 고려했다. 후보로는 Amazon Redshift와 ClickHouse 두 가지가 있었다.

Redshift

Redshift는 AWS에서 제공하는 완전관리형 데이터 웨어하우스 서비스로, 기존에 사용 중인 RDS나 S3와의 통합이 용이했다. 또한 당시 새롭게 등장한 Zero-ETL 기술로 인해 관심을 끌었다. Zero-ETL은 데이터 이동 없이 다양한 AWS 서비스 간에 실시간으로 데이터를 통합할 수 있게 해주는 기술이다. 그러나 Redshift의 비용이 만만치 않아 BigQuery의 비용을 대신한다고 할 순 없었고 , Zero-ETL도 AWS 생태계 내에서만 가능해 BigQuery에서의 데이터 마이그레이션에는 적합하지 않았다.

ClickHouse

최종적으로 ClickHouse를 선택했다. ClickHouse는 Yandex에서 개발한 오픈소스 컬럼 지향 OLAP 데이터베이스 관리 시스템이다.

장점

• 고성능: ClickHouse는 컬럼 지향 저장 방식과 데이터 압축, 인덱싱 기법을 통해 대용량 데이터에 대한 실시간 분석 쿼리를 매우 빠르게 처리할 수 있다.
• 비용 효율성: 자체 호스팅이 가능하고, 클라우드 서비스도 제공하지만 Redshift 대비 훨씬 저렴하다.
• 수평 확장성: 분산 시스템을 지원하여 데이터 증가에 따라 노드를 추가함으로써 성능을 향상시킬 수 있다.

단점

• 유명하지 않은 서비스: 상대적으로 신생 기술이라 사용자 커뮤니티나 레퍼런스가 부족하다.
• 호환성: Metabase 같은 BI 툴에서 바로 지원되지 않아 별도의 드라이버나 플러그인을 설치해야 한다.

---

ClickHouse의 기술적 특징

ClickHouse는 데이터를 로우 단위가 아닌 컬럼 단위로 저장한다. 특정 컬럼에 대한 연산을 수행할 때 불필요한 데이터를 읽지 않아도 되고, 컬럼은 하나의 컬럼 데이터를 연속적으로 저장하기 때문에 값의 분포가 비슷할 확률이 높아 압축의 효율이 높아진다.

컬럼 지향 저장(Column-Oriented Storage)

• 데이터 로딩 최소화 : 원래 쿼리는 조건문을 붙여 해당하는 row를 찾는다. 하지만 컬럼 지향은 row 단위가 아니라 아니라 필요한 컬럼만 읽기 때문에 디스크 I/O와 메모리 사용량이 줄어든다.
• CPU 캐시 효율성: 동일한 데이터 타입의 연속된 값들이 저장되어 있어 CPU 캐시 히트율이 높아진다.
• 벡터화 연산: 컬럼 단위로 데이터를 처리하므로 SIMD 명령어를 활용한 벡터화 연산이 가능하다.

데이터 압축(Data Compression)

• 중복 데이터 압축: 컬럼별로 데이터를 저장하므로, 동일하거나 유사한 값이 연속적으로 나타날 때 높은 압축 효율을 얻을 수 있다.
• 압축된 데이터로 벡터화 연산 : 10, 10, 10, 20, 20 이라는 값이 있을때 압축 형태는 10x3, 20x2 이다. 이때 평균을 구하고 싶다면 압축형태를 해제하지 않고 바로 30 + 40을 한 후 나누기를 통해 계산할 수 있다.

예시를 한가지 더 들어보면, 시험 합격 여부 인 pass/fail 값을 가진 컬럼의 경우 값의 종류가 두가지 뿐이다. 'pass'가 1000번 연속으로 나오면 이를 'pass x 1000'으로 표현하여 저장 공간을 크게 절약할 수 있다.

SELECT COUNT(*) FROM table WHERE status = 'pass'

또한 위와 같은 쿼리에 압축된 pass x 1000 데이터를 이용해 압축 해제 없이 바로 1000개라는 pass 값을 카운팅 할수 있다.

이러한 특징은 수백만 건의 데이터를 실시간으로 집계하거나 필터링하는 등 대용량 로그 이벤트 분석에 특히 적합하다. 사용자 행동 로그에서 특정 이벤트의 발생 횟수를 계산하거나 시간대별 트래픽을 분석하는 작업을 수행할 때, ClickHouse의 구조는 비용 효율성과 함께 높은 성능을 제공한다.

---

ETL 작업

BigQuery의 데이터를 ClickHouse로 마이그레이션하기 위해 ETL(Extract, Transform, Load) 작업이 필요했다. 앞서 언급했듯이 BigQuery는 Nested 구조를 지원하므로, 이를 ClickHouse에 적합한 형태로 변환해야 했다.

Nested 데이터의 Flatten

BigQuery의 Nested 구조는 반복적이고 계층적인 데이터를 저장할 때 유용하지만, 이를 Flatten(평탄화)하여 관계형 모델로 변환해야 했다. 예를 들어, 이벤트 파라미터나 사용자 속성은 배열이나 구조체로 저장되어 있으므로, 이를 개별 컬럼으로 분해하거나 JSON 형태로 직렬화해야 했다.

로그 이벤트 저장의 문제

이벤트 파라미터를 Flatten하여 ClickHouse에 적재하는 과정에서 또 다른 문제가 발생했다. 실제 파라미터 키의 수가 약 100개에 달했으며, 새로운 이벤트 파라미터가 추가될 때마다 스키마를 변경해야 하는 유지보수 문제가 있었다.

선택지

	파라미터 키를 전부 컬럼으로 펼쳐 저장	Key-Value 형태로 저장(JSON or Map)
장점	쿼리가 단순해지고 직관적으로 데이터 조회 가능	스키마 변경 없이 유연하게 데이터 저장 가능
단점	스키마 관리 복잡성 증가, 새로운 파라미터 추가 시마다 테이블 구조 변경 필요.	조회 시 파싱 작업이 필요하며, 컬럼 지향 데이터베이스의 이점을 충분히 활용하지 못함

Map 타입의 활용

ClickHouse는 Map 데이터 타입을 지원하여 Key-Value 형태의 데이터를 효율적으로 저장하고 조회할 수 있다. Map 타입을 사용하면 개별 파라미터 키에 대한 컬럼을 만들지 않아도 되며, 특정 키에 대한 값을 쉽게 조회할 수 있다.

사실 첫 번째 파트에서 언급했듯이 너무 많은 이벤트와 알 수 없는 파라미터들을 정의한 것이 파라미터 키의 수가 많아진 원인이 되었다. 이상적으로는 중요한 파라미터만 선별하여 컬럼으로 저장하는 것이 좋겠지만 이미 저장된 값을 제외하는 것은 또다른 의사결정의 문제이기 때문에 쉽지 않은 상황이다. 컬럼 지향 DB의 장점을 최대한 활용하고 싶었지만, 운영상의 제한으로 인해 완벽하게 구현하지 못한 점이 아쉬웠다. 개인적으로는 각자 담당하는 부분의 파라미터 이름과 값 정도는 알고 있을 것이라 생각하는데, 운영 방향성과 개발 방향성은 완전히 일치할 수 없다.

결론적으로는 고정 값은 컬럼화, 자주 추가될 이벤트 파라미터들은 map 타입으로 관리하게 되었다. 이렇게 하면 스키마 변경 없이도 새로운 파라미터를 처리할 수 있어 유지보수가 비교저거 용이하고, 컬럼 지향 저장의 이점도 일부 활용할 수 있다. 

정리

이렇게 실사용성 테스트와 방향성까지 작업을 마쳤지만, 여러 사정에 아직 프로덕션에 도입하지는 못했고 기약없이 밀리게 되었다. 그러나 장기적으로는 (꼭 ClickHouse가 아니더라도) 쉽게 접근 가능한 데이터 플랫폼이 반드시 필요하다고 생각한다. 데이터 팀으로서 팀원 모두가 데이터에 접근하여 자신이 개발하는 기능이 어떻게 동작하는지 파악하고, 개선점을 스스로 찾을 수 있는 환경을 마련하고 싶다. ClickHouse를 도입하면서 얻은 경험을 바탕으로 더 나은 데이터 활용 문화를 만들어 나가는데 힘써야겠다.