2025년 1월 30일

빅쿼리에서 레이크하우스까지: 페타바이트 규모의 데이터 분석 플랫폼을 구축한 방법 - 1부

에서 TRM Labs에서는 금융 기관, 가상자산 비지니스, 정부 가상자산 비지니스 암호화폐 관련 금융 범죄와 사기를 탐지하고 조사할 수 있도록 블록체인 인텔리전스 도구를 제공하고 있습니다.

저희 분석 플랫폼은 30개 이상의 블록체인에서 페타바이트 규모의 블록체인 데이터를 처리하고 분산형 Postgres와 BigQuery를 기반으로 초저지연으로 분당 500건 이상의 고객 쿼리에 응답합니다. 수년 동안 효율적으로 확장하기 위해 BigQuery를 최적화했지만, 온프레미스에서 실행해야 할 때 벽에 부딪혔습니다. BigQuery는 우리의 다중 환경 요구 사항을 지원할 수 없었고, 대규모 데이터 수집을 위해 Postgres를 확장하는 데는 너무 많은 비용이 들었습니다. 그래서 우리는 사용자 대면 분석 요구 사항을 지원하기 위해 Apache Iceberg와 StarRocks로 페타바이트 규모의 데이터 레이크하우스를 구축하여 자체 호스팅되고 안전하며 성능이 뛰어난 개방형 솔루션이 필요했습니다. 이 글에서는 데이터 아키텍처에 대한 생각을 바꿀 수 있는 방법과 그 과정에서 배운 점, 그리고 그 이유에 대해 설명합니다.

1. 1세대 데이터 플랫폼

1세대 데이터 플랫폼에서는 빠른 포인트 조회와 소규모 사전 집계를 위해 분산형 Postgres 클러스터(Citus Data)를 사용했습니다. 워크로드가 분산 Postgres 클러스터의 용량을 초과하면 더 큰 쿼리와 임시 집계를 BigQuery에 통합했습니다.

[그림 1]은 TRM의 1세대 데이터 플랫폼이 사용자 대면 분석을 처리하고 Postgres 및 BigQuery를 통해 쿼리를 라우팅하는 방법을 보여줍니다.

2. BigQuery를 넘어 차세대 오픈 데이터 레이크하우스를 향하여

BigQuery는 수년 동안 고객의 분석 요구 사항을 잘 충족했지만, 온프레미스 환경을 포함한 여러 환경으로 확장하면서 한계에 부딪혔습니다. 여러 사이트에서 블록체인 분석 데이터를 공유해야 했기 때문에 BigQuery와 같은 관리형 서비스는 비현실적이었고, 서비스 워크로드에는 새로운 확장 접근 방식이 필요했습니다.

변화를 주도하는 주요 요구 사항

다중 사이트 배포: 여러 온프레미스 사이트에 플랫폼을 배포해야 하는 동시에 데이터 공유 기능을 유지하려면 Kubernetes에 배포할 수 있는 오픈 소스 솔루션을 사용해야 합니다.
규모와 성능: 이전에 BigQuery에 의존하여 서비스를 제공하던 최대 규모의 고객 대면 워크로드에는 115TB 이상의 데이터가 포함되어 있으며 매월 2~3%씩 증가하고 있습니다. 이러한 읽기 쿼리에는 시간 기반 및 배열 기반 필터가 포함된 복잡한 다단계 조인이 포함됩니다. BigQuery로 높은 동시성에서 3초의 P95 지연 시간을 충족하는 것은 고가의 컴퓨팅 슬롯에 투자하지 않고는 어려운 일이었습니다. 이와 같은 워크로드를 분산형 Postgres로 옮기려면 스토리지 비용만으로는 비용이 많이 듭니다.

차세대 데이터 플랫폼은 데이터 레이크의 유연성과 데이터 웨어하우스의 성능 및 안정성을 결합해야 했습니다. Apache Iceberg를 중심으로 최신 데이터 레이크하우스를 구축하면 Iceberg 사양을 지원하는 쿼리 엔진 및 분산 컴퓨팅 엔진과의 상호 운용성이 가능해졌습니다. 여러 쿼리 엔진을 벤치마킹한 끝에 StarRocks를 선택했습니다. Apache Iceberg와 StarRocks의 조합은 멀티 사이트 배포 및 성능 요구 사항을 충족하는 동시에 향후 성장을 위한 주요 이점을 제공했습니다.

우리가 본 기회

개방형 표준: Apache Iceberg의 오픈 소스 구현은 스키마 진화, 시간 이동, 객체 스토리지의 효율적인 메타데이터 관리 기능을 제공합니다. 유연성이 뛰어나 온프레미스 멀티사이트 환경에서도 배포할 수 있어 여러 위치에서 블록체인 분석 데이터를 공유하는 데 적합합니다.
고성능 데이터 레이크: StarRocks는 고급 캐싱과 완전 벡터화된 쿼리 처리를 통해 초저지연과 높은 동시성을 제공합니다. StarRocks와 Iceberg를 결합하면 데이터 레이크의 유연성을 유지하면서 데이터 웨어하우스 성능을 향상시킬 수 있습니다.
쿼리 엔진 독립성: Apache Iceberg에 데이터 레이크하우스를 구축함으로써 호환 가능한 모든 쿼리 엔진을 통합할 수 있는 유연성을 확보하여 기술 발전에 따라 적응할 수 있습니다. 벤치마크를 실행한 이후 1년 동안 쿼리 엔진 성능이 빠르게 발전하는 것을 목격했습니다. 저희는 기존 솔루션(예: Trino 및 DuckDB)과 신규 솔루션(예: Clickhouse 및 Crunchy Data Warehouse)을 모두 재평가하고자 합니다. 이러한 유연성 덕분에 단일 공급업체에 구애받지 않고 성능과 비용 효율성 면에서 최첨단을 유지할 수 있습니다.
비용 절감: 데이터와 메타데이터가 오브젝트 스토리지에 효율적으로 저장되기 때문에 분산된 Postgres 클러스터에서 워크로드를 마이그레이션하여 SSD 스토리지 비용을 절감할 수 있는 기회를 발견했습니다.

3. 데이터 레이크하우스를 위한 Apache Iceberg + StarRocks가 필요한 이유

온프레미스를 포함한 다중 환경 배포가 핵심 요구 사항이 되면서, 분석 사용 사례에 직면한 고객을 위한 대안 솔루션이 필요했습니다. BigQuery 및 Postgres와 함께 작업하면서 몇 가지 중요한 관찰 결과를 얻었습니다:

데이터 압축, 클러스터링, 파티셔닝을 사용하여 스캔을 최적화함으로써 쿼리 시 읽은 데이터를 최소화하는 것이 중요합니다.
기존의 B-트리 스타일 인덱스는 페타바이트 규모에서는 비효율적입니다.
최신 벡터화된 CPU 실행(예: SIMD)은 쿼리 처리 속도를 크게 높여줍니다.
수평적 확장은 비용을 합리적으로 유지하면서 높은 동시성을 가능하게 합니다.
컴퓨팅과 스토리지를 분리하면 데이터 중복 없이 쿼리 엔진 간에 유연하게 전환하거나 결합하여 워크로드 성능을 최적화할 수 있습니다.

이러한 인사이트를 바탕으로 기존 OLAP 데이터 저장소(예: Clickhouse)를 넘어 새롭게 떠오르는 '데이터 레이크하우스' 시장을 탐색하기 시작했습니다. 우리는 (1) 저장 형식과 (2) 쿼리 엔진이라는 두 가지 중요한 결정을 내려야 했습니다.

3.1 저장 형식

특히 처리량이 많은 블록체인의 등장으로 스토리지에 대한 요구가 매년 기하급수적으로 증가하고 있습니다. 향후 추가 블록체인을 온보딩할 때 스토리지 시스템의 성능과 비용 효율성을 모두 확보해야 했습니다.

가장 비싼 오브젝트 스토리지도 가장 저렴한 SSD보다 4배나 저렴하기 때문에 비용 측면에서 SSD에서 오브젝트 스토리지로 전환해야 한다는 것을 알았습니다.

옵션 범위를 오브젝트 저장소로 좁혀서 데이터 레이크하우스 구축에 가장 많이 사용되는 3가지 저장소 형식을 평가했습니다.

Delta Lake는 매력적인 기능과 성능을 제공했지만, 파티션 진화가 부족하고 대규모 분석 및 일괄 처리를 위한 Iceberg와 겹치는 부분이 있어 제외했습니다. 그런 다음 Apache Hudi를 벤치마킹했는데, 가장 성능이 좋은 Hudi 테이블은 Apache Iceberg보다 3배나 느렸습니다.

우리는 광범위한 커뮤니티 채택, 활발한 개발 커뮤니티, 광범위한 카탈로그 및 쿼리 엔진 지원을 자랑하면서 뛰어난 읽기 성능을 제공하는 Apache Iceberg에 베팅했습니다.

3.2 쿼리 엔진

테이블 형식을 선택한 후, 오픈 소스 버전에서 Iceberg와 호환되는 여러 쿼리 엔진을 벤치마킹했습니다. 세 가지 엔진을 평가했습니다: Trino, StarRocks, DuckDB. 벤치마크 결과, StarRocks가 지속적으로 다른 엔진보다 우수한 성능을 보였습니다(아래 그림 2 참조).

Trino: 매우 큰 데이터 세트를 쿼리하도록 설계된 오픈 소스 분산 쿼리 엔진입니다.
스타록스: 데이터 레이크하우스 안팎의 분석을 위한 빠른 오픈 소스 쿼리 엔진입니다.
DuckDB: 오픈 소스, 처리 중인 분석 SQL 쿼리 엔진.

[그림 2] 벤치마크 결과는 2.57TB의 블록체인 분석 데이터 세트에서 테스트한 세 가지 엔진의 여러 구성에 대한 조회/필터 작업의 쿼리 성능 비교를 보여줍니다. StarRocks는 모든 구성에서 일관되게 우수한 응답 시간을 제공했습니다.

3.3 실험 결과

실험은 필터링이 포함된 포인트 조회 쿼리와 필터링이 포함된 복잡한 집계 쿼리라는 두 가지 주요 워크로드[6.1.2]에 중점을 두었습니다. 부하 테스트를 수행하고 쿼리 엔진이 높은 동시성 하에서 성능을 유지할 수 있는지 확인하기 위해 JMeter를 사용했습니다.

3.3.1 조회/필터로 실험하기

그림 2는 2.57TB 데이터 집합에서 작은 하위 집합을 반환하는 포인트 조회 및 범위 조회 쿼리를 테스트한 이 워크로드에 대한 결과를 보여줍니다. 관찰한 결과

StarRocks: 모든 구성에서 일관되게 최고의 성능을 제공하며 데이터 캐싱을 통해 470ms의 낮은 쿼리 응답 시간을 달성했습니다.
Trino: 1,410밀리초에서 1,030밀리초 사이의 응답 시간을 제공했으며 클러스터 크기에 따라 다릅니다.
DuckDB: 강력한 단일 노드에서 2~3초의 합리적인 성능을 달성했습니다. 이 벤치마크 이후에는 Iceberg 테이블 지원의 한계로 인해 DuckDB 테스트를 중단했습니다. 향후 평가를 위해 DuckDB Iceberg 확장에 술어 푸시다운에 대한 지원이 추가되기를 기다리고 있습니다.

3.3.2 복잡한 집계 실험하기

[그림 3] 다양한 클러스터 구성에서 Trino와 StarRocks 간의 복잡한 집계 쿼리 성능을 비교한 벤치마크 결과.

다음 실험에서는 2.85TB 데이터 집합에서 배열 및 날짜 범위 필터를 사용하여 합계, 카운트, GROUP BY 연산을 수행하는 쿼리를 테스트했습니다. 그 결과 다음과 같은 결과가 나타났습니다:

StarRocks: StarRocks는 복잡한 총 워크로드를 매우 잘 처리하여 최대 규모의 테스트 클러스터에서 캐싱 없이 최대 2초, 캐싱을 사용하면 500ms의 낮은 레이턴시를 달성했습니다.
Trino: 트리노의 성능은 클러스터가 커질수록 크게 향상되었지만, 약 2.5초로 성능 상한선에 도달했습니다.

3.3.3 스트레스 테스트

JMeter를 사용하여 높은 동시 접속자 수에서 Trino와 StarRock의 성능을 스트레스 테스트했습니다.

StarRocks: StarRocks: 조회 및 집계 워크로드 모두에서 높은 동시성 테스트에서 지속적으로 Trino보다 우수한 성능을 보였습니다. 데이터 캐싱을 활성화하면 성능이 더욱 향상되었습니다.
Trino: 동시 사용자 부하가 증가함에 따라 Trino의 성능이 저하되었습니다. 2024년 초에 이 테스트를 수행했을 때 Trino에는 데이터 레이크 테이블에 대한 데이터 캐싱 기능이 없었습니다. 이 기능은 나중에 Trino 439에 추가되었지만 아직 평가하지 않았습니다.

[그림 4] 복잡한 집계 워크로드(왼쪽)와 조회/필터 워크로드(오른쪽)를 사용한 멀티스레드 테스트 결과.

4. 앞으로 나아갈 길

[그림 5]는 사용자 대면 분석을 위한 차세대 데이터 플랫폼을 보여줍니다.

세 가지 오픈 테이블 형식에 대한 평가와 여러 쿼리 엔진에 대한 실험을 바탕으로, 여러 사이트에 걸쳐 TRM의 데이터 플랫폼을 구축하기 위한 주요 요구 사항을 해결하고 고객의 성능을 개선하기 위해 StarRocks와 Apache Iceberg를 핵심 구성 요소로 하는 데이터 레이크하우스를 구축하기로 결정했습니다.

데이터 레이크하우스는 두 가지 이점을 제공합니다: 데이터 레이크하우스의 접근 방식은 데이터 레이크의 유연성과 데이터 웨어하우스의 성능을 결합하여 빠르고 안정적인 고객 대면 분석을 가능하게 합니다.
Apache Iceberg: 개방형 표준, 강력한 스키마 진화, 효율적인 메타데이터 처리 기능을 갖춘 Iceberg는 우리에게 필요한 엔진 간 상호 운용성을 제공합니다.
스타록스: Iceberg 테이블 파티셔닝, 클러스터링, StarRocks 클러스터 크기 조정, 캐싱 전략의 전략적 최적화를 통해 짧은 지연 시간과 높은 동시성으로 탁월한 성능을 달성했습니다. 이러한 개선으로 P95 응답 시간이 50% 개선되고 쿼리 시간 초과 오류가 54% 감소하여 목표 쿼리 성능 목표를 달성할 수 있었습니다.
테스트가 핵심입니다: 실제 워크로드를 통해 벤치마크만으로는 파악할 수 없는 사용 패턴과 최적화 기회가 드러나면서 규모에 맞는 철저한 테스트가 매우 중요하다는 사실이 강조되었습니다.

이 시리즈의 2부에서는 오브젝트 스토리지에 Apache Iceberg를 배포하는 것부터 온프레미스 환경을 포함한 다중 환경 배포를 위한 StarRocks 최적화에 이르기까지 이 아키텍처를 구현한 방법을 살펴보겠습니다.

5. TRM의 데이터 엔지니어링

에서 TRM Labs에서는 인공지능 범죄로부터 문명을 보호하고 수십억 명의 사람들을 위해 더 안전한 세상을 만든다는 대담한 사명을 추구하고 있습니다. 블록체인 인텔리전스 발전시키고 미래의 블록체인 데이터 플랫폼을 구축함으로써 금융 범죄와 블록체인 분석 가장 어려운 과제를 해결합니다.

저희의 미션은 다음과 같은 전문가들이 뒷받침합니다:

비제이 셰콰트 (공동 저자)의 핵심 멤버인 TRM Labs 데이터 플랫폼 팀의 일원으로 실시간 스트리밍, 데이터 레이크하우스 아키텍처, 페타바이트 규모의 분석을 위한 안전한 고처리량 파이프라인 구축에 대한 깊은 전문 지식을 제공하며 TRM의 미션을 추진하고 있습니다.
앤드류 피셔 (공동 저자), 스태프 소프트웨어 엔지니어인 TRM Labs 데이터 플랫폼 팀에서 대규모 배치 데이터 로드와 가상자산 사기에 맞서 싸우는 페타바이트급 분석을 지원하는 데이터 레이크하우스 솔루션을 전문으로 담당하고 있습니다.
엘레나 톰린슨, 모아멘 알리, 브리스 캄그네, 스티븐 호프, 샤라드 바두리아 등 주요 기여자들은 TRM Labs 데이터 제품 팀의 핵심 기여자인 이들은 주요 워크로드를 마이그레이션하여 데이터 레이크하우스 아키텍처를 검증하는 데 중요한 역할을 해왔습니다. 이들의 작업은 실제 사용 사례에서 플랫폼의 확장성, 효율성, 고성능을 보장하는 데 중요한 역할을 했습니다.

특별히 감사드립니다. 마이클 앤드류스 와 아밋 플라하 의 통찰력 있는 리뷰와 이 프로젝트 전반에 걸쳐 기술적 우수성을 위해 지속적으로 헌신해 주신 것에 대해 감사드립니다.

팀에 합류하세요

저희 엔지니어들은 초저지연 응답 시간을 갖춘 페타바이트 규모의 데이터 레이크하우스를 구축하여 블록체인 분석 가장 어려운 과제를 해결하고 범죄와 싸우며 수십억 명의 사람들을 위한 더 안전한 세상을 만들기 위해 노력하고 있습니다. 흥미롭고 영향력을 발휘할 준비가 되셨나요? 아니면 더 나은 솔루션을 구축할 수 있다고 생각하시나요? 지금 바로 기회를 살펴보고 지원하세요 .

‍

6. 부록 / 상세 실험

6.1 - 실험 여정

Apache Iceberg의 쿼리 성능을 평가하기 위해 다양한 쿼리 엔진을 사용하여 일반적인 읽기 워크로드를 벤치마킹하여 성능 및 확장 요구 사항을 가장 잘 충족하는 쿼리 엔진을 찾았습니다. 저희는 조회/필터와 복잡한 집계라는 두 가지 범주의 워크로드에 중점을 두었습니다.

6.1.1 - 데이터 준비

각 워크로드에 대해기존 BigQuery 데이터에서 Iceberg 테이블을 만들었습니다. 쿼리는 일반적으로 특정 블록체인 주소, 오프체인 엔티티 또는 기간을 참조하므로, 쿼리가 관련 데이터 하위 집합에만 액세스할 수 있도록 전략적으로 데이터 세트를 분할했습니다. 또한:

여러 테이블(2~3TB)을 BigQuery에서 Google 클라우드 스토리지의 Parquet 형식으로 내보냈습니다.
PySpark를 사용하여 이러한 Parquet 파일을 Iceberg 테이블로 변환하고 버킷 및 정렬 구성으로 최적화했습니다.
데이터프록 메타스토어를 사용하여 스키마 및 테이블 메타데이터를 유지 관리했습니다.

6.1.2 - 워크로드 설명

6.1.2.1 조회/필터로 실험하기

--  블록체인 트랜잭션에대한 샘플 아이스버그 테이블 
CREATE TABLE blockchain_transactions (
    트랜잭션_id STRING,
    block_number BIGINT,
    from_address STRING,
    to_address STRING,
    amount DECIMAL(38,18), 
    타임스탬프 TIMESTAMP,
    chain STRING
) 빙산 사용
PARTITIONED BY (bucket(transaction_id, 3000));

-- 트랜잭션을 ID로 필터링하는 샘플 쿼리
SELECT 
    transaction_id,
    FROM_ADDRESS,
    to_address,
    금액
    timestamp
FROM 블록체인_트랜잭션 
WHERE transaction_id = '0x1234abcd...';

6.1.2.2 복합 집계 실험하기

--  복잡한 집계를위한 샘플 쿼리 
SELECT
    e.id::TEXT AS entity_id,
    SUM(CASE WHEN t.transaction_type = 'type_a' THEN t.weight_normalized END) AS type_a_volume,
    SUM(CASE WHEN t.transaction_type = 'type_b' THEN t.weight_normalized END) AS type_b_volume, 
    SUM(t.weight_normalized) AS total_volume,
    SUM(CASE WHEN t.transaction_type = 'type_a' THEN 1 ELSE 0 END) AS type_a_count,
    SUM(CASE WHEN t.transaction_type = 'type_b' THEN 1 ELSE 0 END) AS type_b_count, 
    COUNT(*) AS total_count
FROM 트랜잭션 t
JOIN entities e ON t.entity_id = e.id
JOIN categories c ON e.category_id = c.id
WHERE t.chain = __chain::TEXT
  AND t.chain_id = __chain_id::TEXT
  AND t.timestamp BETWEEN __start_date::TIMESTAMP AND __end_date::TIMESTAMP
  그리고 t.경로_길이 __min_hop AND __max_hop 사이
  AND (
        __entity_ids IS NULL 
        또는 t.entity_id = ANY(__entity_ids)
      )
  AND (
        __category_ids IS NULL 
        또는 존재 (
            SELECT 1 
 FROM unnest(t.entity_category_ids) AS cat_id
            WHERE cat_id = ANY(__category_ids)
        )
      )
  AND e.id IS NOT NULL
GROUP BY e.id
ORDER BY __sort_column __sort_order NULLS LAST
LIMIT __limit
OFFSET __offset;

6.1.3 - 인프라

성능 확장을 평가하기 위해다양한 컴퓨팅 리소스 구성으로 각 쿼리 엔진을 배포했습니다. 자세한 구성 사양은 다음 섹션에 나와 있습니다.

StarRocks: 스타락스 쿠버네티스 오퍼레이터를 사용하여 GKE에 배포.
Trino: Google 데이터프록 (관리형 Hadoop/Spark 플랫폼)에 배포.
DuckDB: GCP VM에 배포됩니다.

6.2 - 인프라

6.2.1 Trino

방법: 사용 방법: 구글 데이터프록 (관리형 Hadoop/Spark 플랫폼)에 배포되어 단순성과 내장된 자동 확장 기능을 제공합니다.
버전: Trino 433
실험용 클러스터 크기:

6.2.2 스타록스

방법: 방법: 스타락스 쿠버네티스 오퍼레이터를 사용하여 GKE에 배포합니다.
버전: 3.1
실험용 클러스터 크기:

6.2.3 DuckDB

방법: 방법: Google Cloud Platform(GCP) 가상 머신에 배포됩니다.
버전: 0.9.2
실험용 클러스터 크기:

6.3 - 스트레스 테스트 방법론

도구 및 설정:

JMeter: 쿼리 서버에 대한 사용자 요청을 시뮬레이션하는 데 활용됩니다.
- JMeter는 동시 사용자 요청을 시뮬레이션하여 현실적인 서버 부하를 생성합니다. JDBC, HTTP, FTP를 비롯한 여러 프로토콜을 지원합니다.
- 주요 구성 요소:
  - 스레드 그룹: 지정된 작업을 수행하는 시뮬레이션된 사용자 집합으로, 사용자 수, 램프업 기간 및 실행 빈도를 조정할 수 있습니다.
매개변수화된 쿼리 및 CSV 데이터: 쿼리는 CSV 파일의 동적 매개변수를 활용하여 다양하고 사실적인 워크로드를 생성합니다.
JMeter 동시 스레드: 1, 3, 5, 8, 13, 21, 34, 55(동시 사용자 시뮬레이션)
실행:
- 지속 시간: 각 테스트는 1분 동안 연속으로실행됩니다↪CF_200D↩.
- 쿼리 제한: 테스트는 최대 시스템 용량을 측정하기 위해 쿼리 제한 없이 작동합니다.