Bringing Data Warehouse Performance to Apache Iceberg

• 요약
• 0. 들어가기에 앞서서(about Iceberg)
• 1. Apache Iceberg 느린 쿼리성능이 아키텍쳐에 끼치는 영향
• 1.1. 현실은 아래의 이유들로 인해 실제 Iceberg를 사용한 Single Source of Truth를 구현하지 못하고 있습니다.
• 1.2. 성능 상승을 위한 Iceberg의 노력 그리고 V3에 대하여
• 2. 어떻게 Iceberg 테이블의 성능을 높일수 있는가(일반론)
• 2.1. 일반적으로 문제가 발생하는 원인
• 2.2 어떻게 해결할수 있는가
• 3. StarRocks를 시작해야하는 이유
• 3.1. About StarRocks
• 3.2. 빠른성능을 달성하는데 발생하는 흔한 문제들과 이를 StarRocks에서 해결한 법
• 3.3. StarRocks(CN) is fast as a data warehouse 그리고 추가적인 기능들
• 4. StarRocks 사용사례
• 4.1. TRM Labs(Blockchain)
• 4.2. Herdwatch
• 4.3. RedNote
• 4.4.Tencent Games

요약

apache iceberg의 쿼리 성능을 향상시키는 방법에 대해 논의합니다. Iceberg는 데이터 레이크에서 데이터 웨어하우스와 유사한 기능을 제공하지만, 쿼리 속도가 충분히 빠르지 않으면 그 약속이 깨질 수 있습니다. 이 문제를 해결하기 위해 v3 기능인 삭제 벡터(deletion vector)를 소개하고, 일반적인 성능 튜닝 팁과 모범 사례를 제시합니다. 또한, starrocks와 같은 쿼리 엔진을 사용하여 성능을 가속화하는 방법과 실제 사례 연구를 살펴봅니다. 핵심은 데이터 레이크하우스 환경에서 쿼리 성능을 최적화하여 데이터 거버넌스를 강화하고 비용을 절감하는 것입니다.

0. 들어가기에 앞서서(about Iceberg)

• Iceberg는 Hive format table에 비해서 많은 기능들을 지원합니다(ACID, Time Travel, SQL, 등) 그러면 왜 우리는 최근의 데이터웨어하우스의 요건들을 Parquet파일로 처리할려고 할까요? 그것은 다양한 요구사항들을 만족하면서 하나의 데이터 소스를 바라볼수 있도록 통합하고 싶기 때문입니다. 하나의 복사본만 가지고 있고 이를 활용하여 분석하는 환경을 만들수 있다면 정말 좋을것입니다.

1. Apache Iceberg 느린 쿼리성능이 아키텍쳐에 끼치는 영향

1.1. 현실은 아래의 이유들로 인해 실제 Iceberg를 사용한 Single Source of Truth를 구현하지 못하고 있습니다.

• 현존하는 Data Lake 쿼리 엔진들은 DW에 대응할수 없도록 구형되어있습니다.
• 고객이 직접 분석할 수 있는 상황들에 대한 구현이 부족합니다.
• Iceberg table에 대한 지원이 매우 부족합니다.
• 사용자가 성능 달성을 위해 너무 많은 엔지니어링 리소스를 사용하여 쿼리엔진을 활용하고 있습니다(이는 결국 지속가능하지 않습니다.)
• 결국한 이러한 문제로 인해서 사용자들은 성능달성을 위해 데이터를 DWH로 복사하여 제공하고 있습니다.

1.2. 성능 상승을 위한 Iceberg의 노력 그리고 V3에 대하여

• V2 대비해서 V3를 빠르게 만들 기능
• 삭제 백터
• 기존 Iceberg(V2)에서는 기존의 동등삭제(파일재처리를 통한 삭졔) 보다는 빠른 위치 삭제라는 기능을 만들었지만 여러 문제들에 직면함
• 읽을 때 모든 데이터 파일의 위치를 쿼리에 병합하게됨
• 여러삭제파일을 생성함에 따라 작은 파일 이슈를 맞게됨
• 이러한 방식은 결국 모든 작은 parquet 파일을 읽게 하면서 성능다운을 일으킴
• Writer가 데이터를 저장할때 결국 전역정렬 작업을 하게됨(경로기준으로 파일을 정렬하고 넣어야 하기 때문에) - 큰 셔플 발생
• Parquet파일 자체 압축 해제 비용 및 읽는 방법에서의 문제(CPU, 행단위 로드)
• 해결방안 : 삭제 백터를 위한 바이너리 파일인 Puffin 파일 도입(각 라인은 bitmap blob및 다양한 정보를 포함)
• 결과
• One DV per data-file : ~10x ~ 100x faster on delete loading
• faster writes : 1.71 ~ 2.16x
• faster read : x34 ~ x350
• 400K positions / 2M universe per data file 10 data files per delete file
• AS-IS : 0.717s
• TO-BE(uncompressed) : 0.002s
• Random Deletes(compression)
• Demse positions(20% delete)
• AS-IS : 4372672 bytes
• TO-BE(uncompressed) : 2545108 bytes(42% less)
• TO-BE(with zstd) : 1899346 bytes(56% less)
• Random positions(7% delete)
• AS-IS : 1650763 bytes
• TO-BE(uncompressed) : 3304 bytes

2. 어떻게 Iceberg 테이블의 성능을 높일수 있는가(일반론)

2.1. 일반적으로 문제가 발생하는 원인

• 작은 파일 문제
• 메타데이터 파일이 관리
• 너무 많은 데이터 삭제
• 올바르지 않은(혹은 적절하지 않은) 파티셔닝

2.2 어떻게 해결할수 있는가

• Truncate and bucket 같은 기능들을 활용하여 Hidden Partitioning 하기
• 파일 사이즈를 주기적으로 관리하기
• 100MB ~ 1GB per file
• 작은 사이즈의 파일은 주기적으로 압축하기
• 삭제 최적화
• 동등삭제 보다는 위치삭제를 사용하세요
• 삭제 파일을 압축하세요
• 메타데이터 성장을 관리
• 작은 메타데이터들을 재작성하세요
• 오래된 스냅샷을 삭제하세요
• 알맞은 파일 포맷을 사용하기
• 만약 OLAP 분석을 해야한다면 Parquet(or ORC) 를 사용하세요
• 웨어하우스 별로 알맞은 트릭(기술)을 적용해 보세요
• Sorting, Partitioning, indexes, collect statistics, 등.

⇒ 아니면 알맞은 쿼리 엔진을 선택하세요

3. StarRocks를 시작해야하는 이유

3.1. About StarRocks

• Linux Foundation의 오픈소스 프로젝트
• Datawhare house 워크로드를 대응 할수 있도록 설계되었음
• Natively intergrated with Apache Iceberg and open & standard file format
• 외부 의존성이 없는 심플한 아키텍처
• 범용 SQL 문법 지원, Trino SQL 지원
• 3.2 버전 기준으로 Trino(4.34, JDK 21)에 비해서 평균적으로 4.62배 뛰어남 - TPC DS 1TB

3.2. 빠른성능을 달성하는데 발생하는 흔한 문제들과 이를 StarRocks에서 해결한 법

• 문제점
• Apache Iceberg의 메타데이터를 파싱하는 것은 매우 많은 비용이 드는 작업(높은 IO + 대기시간)
• 카탈로그 읽기
• 메타데이터 파일 읽고 파싱
• 매니페스트 목록을 읽고 파싱 + 매니페스트 파일을 읽고 파싱
• S3에서 엔진 자체로 파일을 가져오는 과정에서 많은 IO가 발생함
• 네트워크 오버헤드, S3의 내구성은 매우 좋지만 지연시간이 100ms~200ms 가 될 수 있음
• 만약 또한 최적화되어있지 않은(작은 파일들이 많거나 너무 큰파일로 되어있는 경우) 느려짐
• 해결방안
• 계층적 캐싱 구조 적용
• 메모리와 스토리지를 활용하여 IO 비용을 감축
• 메타데이터 캐싱 및 데이터 캐싱 지원
• 메모리 및 메모리간 셔플링을 지원하는 MPP아키텍처 지원
• 집계 및 다중 집계 셔플 조인을 지원하지만 모든 작업은 메모리에서 수행
• 쿼리 엔진 자체의 성능 최적화
• CPU 명령어 세트를 최대한 활용하기 위해 C++로 엔진개발
• 모든 연산자를 백터화 되도록 적용

3.3. StarRocks(CN) is fast as a data warehouse 그리고 추가적인 기능들

Flat은 디노말을 친 기준으로 StarRocks는 Flat 테스트 기준으로 Clickhouse Druid 보다 빠르며 궁극적으로 디노말을 하지 않고 Join 과 같은 비싼 작업을 한다고 하더라도 Druid 보다는 빠른 성능을 가지고 있음

핫 쿼리 기준으로 성능을 비교하자면 당연히 DW쪽이 빠르지만 생각보다 성능차이가 크지 않으며 겨우 12%차이가 남, 이를 통해서 우리는 Single Source of Turth에 도달할수 있다는 것을 알 수 있음

더 높은 성능을 제공하기 위해 사용자들은 자주 전용 ETL 파이프라인을 생성하고 이를 다시 포인팅 하는 작업을 반복하고 있음 하지만 이는 시간이 오래 걸릴 뿐만 아니라 사용하지 않는 테이블에 파이프라인을 만드는 경우가 발생함 StarRocks 에서는 MV를 생성하면 자동으로 재사용하는 기능을 지원(쿼리플래닝 단계에서 적절한 MV로 라우팅하도록) 하는 기능을 통해 보다 빠른 쿼리가 가능하도록 함

4. StarRocks 사용사례

4.1. TRM Labs(Blockchain)

AS-IS

• 사용자가 직접 분석을 해야하는 상황
• 100TB + 연간 25~45%의 데이터가 증가중
• 복잡한 조인 및 카디널리티가 높은 쿼리가 자주 들어옴(3초 이내 처리 필요) → 높은 빅쿼리 비용
• 빅쿼리가 병목현상이 되기 시작했음

TO-BE

• Iceberg도입을 통한 어플리케이션 데이터 통합
• P95 성능 50% 향상
• 쿼리 타임아웃 오류 54% 감소

4.2. Herdwatch

• 기존의 고객 대면 분석 시스템을 Athena로 적용하였으나 느렸음
• StarRocks 도입을 통해서 2-5분 정도 걸리던 시간을 700ms - 1.5s로 줄였음
• 분석환경을 통합 : 단일 정보, 관리 단순화, 리포팅 단순화를 달성함

4.3. RedNote

• 100PB의 데이터와 일간 3PB가 늘어가는 상황에서 Iceberg를 사용한 StarRocks 도입을 통해 Clickhouse보다 나은 성능을 달성함

4.4.Tencent Games

• PB 수준의 Iceberg Lakehouse를 10초 이내의 데이터 신선도를 가지고 달성함