📗HMS 활용 방안

HMS(Hive Metastore Service)는 Apache Hive의 메타스토어(Metastore) 서비스로, 테이블, 데이터베이스, 파티션, 스키마 등의 메타데이터를 관리하는 역할을 한다.

여러 최신 기술이 생겼음에도 Hive Metastore (HMS)를 활용해야 하는 이유는 기존의 데이터 레이크 아키텍처와의 높은 호환성, 메타데이터 관리 기능, 그리고 여러 데이터 처리 엔진과의 연동성 때문이다.

🏳️‍🌈 [궁금한점]

• HMS 는 무엇이고 어디에 사용하나
• HMS는 카탈로그인가 메터데이터 관리 시스템인가
• HMS는 어떤 구조로 설계되어 있나
• 한계점은 무엇이고 어떻게 극복하고 있나
• ICEBERG를 HMS 대신 사용할 때 장점은 무엇인가

---

🔗[목차]

• 📗HMS 활용 방안
• 🔗[목차]
• HMS 활용법
  • 메타데이터 관리의 표준 역할
  • 기존 데이터 레이크 아키텍처와의 높은 호환성
  • Trino, Presto, Spark 등의 엔진과의 호환성
  • Iceberg와 함께 사용할 수 있음
  • 안정성과 검증된 운영 경험
• HMS 서버
  • HMS의 주요 기능
  • HMS 사용 이유
• HiveServer2의 역할
  • 주요 역할
• HS2 를 사용하는 이유
• HMS 와 HS2 아키텍처
  • HS2와 HMS가 같은 컨테이너에서 실행
  • HS2는 SQL을 처리하고, HMS에서 메타데이터 조회
• Trino + Iceberg 환경에서 HMS가 필요한가
  • HMS를 계속 사용하는 경우
  • HMS 없이 Iceberg 전용 Catalog 사용
• 카탈로그(Catalog)와 메타데이터(Metadata)의 개념 차이
  • 카탈로그(Catalog)
  • 메타데이터(Metadata)
• HMS는 카탈로그인가 메터데이터 관리 시스템인가
  • 메타데이터 관리 시스템 (Metadata Management System) 역할
  • HMS는 카탈로그 역할
• Hive Metastore의 한계
  • Hive Metastore의 주요 문제점
• iceberg 카탈로그로 hive를 사용하면 acid가 지원된다
  • Iceberg에서 ACID 지원 여부
    • Iceberg의 주요 ACID 기능
  • Iceberg에서 사용할 수 있는 카탈로그 유형
  • Hive Metastore 기반 Iceberg 카탈로그의 한계점
  • Hive Metastore 기반 Iceberg 카탈로그의 단점
• iceberg 카탈로그로 hive 카탈로그를 사용할 때 생기는 문제점
  • 성능 문제의 주요 원인
    • Hive 메타스토어의 성능 병목
    • 메타데이터 복잡성
    • ACID 트랜잭션 처리의 비효율성
  • 성능 문제 해결 방법
    • 메타스토어의 성능 개선
    • Iceberg 전용 카탈로그 사용 고려
    • 메타데이터 분리 및 최적화
    • 트랜잭션 처리 개선
• s3가 RDBMS보다 느린데 병렬처리로 인해 더 효과적으로 사용할 수 있다
  • 객체 스토리지(S3)의 특징과 RDBMS의 차이점
  • Iceberg의 병렬 처리와 성능 최적화
    • 병렬 처리
    • 효율적인 파일 관리
    • 분산 파일 시스템 관리
    • 최적화된 메타데이터 관리
    • 데이터 청크 크기 최적화
  • 성능 차이를 해결하는 방식

HMS 활용법

메타데이터 관리의 표준 역할

HMS는 테이블, 파티션, 스키마, 데이터 위치 등의 메타데이터를 중앙에서 관리하는 역할을 한다.
데이터 저장소가 변경되더라도 테이블 정의를 일관되게 유지할 수 있다.
Presto, Trino, Spark, Flink, Hive 등 여러 분산 처리 엔진과의 연동이 가능하다.

HMS가 있으면 다양한 엔진에서 동일한 메타데이터를 공유할 수 있으므로 데이터 관리가 용이

기존 데이터 레이크 아키텍처와의 높은 호환성

Hadoop 에코시스템을 포함한 기존 데이터 레이크 환경에서 HMS는 핵심적인 역할을 해왔고, 많은 기업이 이를 기반으로 운영 중이다.

데이터 레이크에서 Hive 테이블을 사용하고 있다면 HMS를 계속 유지하는 것이 운영 비용을 줄이고, 기존 인프라를 그대로 활용할 수 있는 방법이 될수 있다.

Iceberg, Delta Lake 등 새로운 포맷이 등장했지만, 여전히 HMS를 활용하여 메타데이터를 관리하는 경우가 많다.

HMS는 기존 Hive 기반 데이터 레이크와의 호환성을 유지하는 데 필수적

Trino, Presto, Spark 등의 엔진과의 호환성

HMS는 Trino, Presto, Spark 등 다양한 엔진에서 사용되는 공통 메타스토어 역할을 한다.

예를 들어, Trino의 Hive 카탈로그는 기본적으로 HMS를 사용하여 테이블과 파티션 정보를 가져온다.

Spark도 기본적으로 HMS와 연동되어 있으며, 이를 통해 데이터를 효율적으로 조회할 수 있다.

HMS는 여러 데이터 엔진과 쉽게 연결될 수 있도록 하는 "표준" 역할

Iceberg와 함께 사용할 수 있음

Apache Iceberg는 새로운 데이터 레이크 테이블 포맷이지만, 기존의 HMS를 활용할 수도 있다.

Iceberg의 Hive 카탈로그 모드를 사용하면 HMS를 통해 메타데이터를 저장하고 관리할 수 있다.

완전히 새로운 메타스토어 시스템을 구축할 필요 없이, 기존 HMS를 그대로 활용 가능하다.

HMS는 Iceberg 같은 최신 기술과도 함께 사용할 수 있어 높은 유연성

안정성과 검증된 운영 경험

HMS는 오랜 기간 동안 검증된 솔루션이며, 대규모 데이터 레이크 환경에서도 안정적으로 운영할 수 있다.

많은 기업들이 이미 HMS를 기반으로 수십~수백 PB(페타바이트)급 데이터 레이크를 운영하고 있다.

새로운 카탈로그 솔루션(예: Iceberg REST, Glue 등)이 있지만, 여전히 HMS가 성능과 안정성 면에서 유리한 경우가 많다.

HMS는 안정성과 운영 경험이 충분히 쌓인 검증된 솔루션이기 때문에, 많은 기업들이 계속 사용

HMS 서버

HMS의 주요 기능

• 메타데이터 저장: 테이블의 구조 및 위치, 파티션 정보 등을 저장
• 다양한 컴퓨팅 엔진과 연동: Hive뿐만 아니라 Trino, Spark, Presto 등과 함께 사용 가능
• ACID 트랜잭션 지원: 최신 버전에서는 ACID 트랜잭션을 활용할 수 있음
• RDBMS 기반 저장: PostgreSQL, MySQL, MariaDB 등의 RDBMS에 데이터를 저장

HMS 사용 이유

• Hive Metastore는 Hive의 메타데이터를 제공하는 API 서버 역할
  Hive Metastore는 단순한 저장소가 아니라, Hive의 테이블, 파티션, 스키마, 위치 등의 정보를 API 형태로 제공하는 서비스이다.
• • HiveServer2, Spark, Presto, Trino 등 여러 컴포넌트가 Hive Metastore를 조회하여 테이블 정보를 가져온다.
• • 직접 PostgreSQL에 접근하는 방식이 아니라, Thrift API를 통해 중앙 집중식으로 메타데이터를 관리한다.
• 여러 서비스에서 공통적으로 메타데이터를 사용
• • Trino, Presto, Spark, Flink 등 다양한 엔진이 Hive Metastore를 참조하여 테이블 스키마를 인식한다.
• • 만약 단순히 PostgreSQL을 이용한다면, 각 서비스가 직접 RDBMS와 연결되어야 하므로 관리가 어려워진다.
• Caching 및 성능 최적화
• • Hive Metastore는 캐싱 기능을 제공하여 RDBMS를 직접 조회하는 것보다 빠르게 메타데이터를 제공할 수 있다.

HiveServer2의 역할

HiveServer2(HS2)는 Apache Hive의 SQL 인터페이스를 제공하는 서버로, 클라이언트가 Hive와 상호작용할 수 있도록 해준다.

주요 역할

• SQL 쿼리 실행 및 관리: JDBC, ODBC, Beeline 등을 통해 Hive에 SQL 쿼리를 전송하고 실행
• 멀티 테넌시 지원: 여러 사용자가 동시에 접속하여 쿼리를 실행할 수 있도록 세션을 관리
• 보안 및 인증: Kerberos, LDAP, PAM과 같은 인증 방식을 지원하여 보안을 강화
• 쿼리 최적화 및 실행 계획 관리: 내부적으로 Hive의 Query Compiler와 Execution Engine을 이용하여 실행 계획을 수립
• 워크로드 관리: 리소스 사용량을 조정하고, 쿼리 실행을 분배하여 성능을 최적화

HS2 를 사용하는 이유

• HMS가 메타데이터 저장 역할을 한다면, HS2는 SQL 실행을 위한 게이트웨이 역할을 함
• Trino, Presto, Spark 등에서 HMS를 직접 조회할 수는 있지만, Hive SQL(HQL)을 실행하려면 HS2가 필요

HMS 와 HS2 아키텍처

HS2와 HMS가 같은 컨테이너에서 실행

테스트 및 개발 환경에서만 유용하고, 확장성이 부족하여 운영 환경에는 적절하지 않다.

                   +--------------------+
                   |  Beeline / JDBC / ODBC  |
                   +----------+---------+
                              |
                              v
                   +---------------------------+
                   | HiveServer2 + Metastore   |
                   | (하나의 컨테이너)          |
                   +---------------------------+
                              |
                              v
               +-------------------------+
               |  Metastore DB (PostgreSQL)  |
               +-------------------------+

HS2는 SQL을 처리하고, HMS에서 메타데이터 조회

HMS는 메타데이터를 DB(PostgreSQL, MySQL 등)에 저장한다. 유지보수와 확장성이 좋아지고, 다른 엔진(Trino, Spark 등)에서도 동일한 HMS를 사용할 수 있습니다.

                   +--------------------+
                   |  Beeline / JDBC / ODBC  |
                   +----------+---------+
                              |
                              v
                   +--------------------+
                   |  HiveServer2 (HS2)  |
                   +----------+---------+
                              |
                              v
                   +--------------------+
                   |  Hive Metastore (HMS)  |
                   +----------+---------+
                              |
                              v
               +-------------------------+
               |  Metastore DB (PostgreSQL)  |
               +-------------------------+

Trino + Iceberg 환경에서 HMS가 필요한가

Trino + Iceberg + MinIO 조합에서는 HMS가 필수는 아니다. Iceberg 자체가 HMS 없이 메타데이터를 S3(MinIO) 등의 오브젝트 스토리지에 저장할 수 있기 때문이다.
하지만, 기존 Hive 기반의 데이터도 함께 활용해야 한다면 HMS가 필요할 수 있다.

HMS를 계속 사용하는 경우

• Iceberg는 Hive Metastore(HMS)와 연동 가능하여 기존 Hive 환경과 호환됨
• Trino, Spark 등이 HMS를 통해 Iceberg 테이블을 조회할 수 있음
• 운영 중인 Hive Metastore를 유지하면서 Iceberg로 점진적 전환 가능

catalog.s3-catalog.type=hive
catalog.s3-catalog.uri=thrift://hive-metastore:9083
Iceberg가 HMS를 통해 메타데이터 관리

Hive 테이블과 Iceberg 테이블을 함께 운영 가능

HMS 없이 Iceberg 전용 Catalog 사용

• Iceberg는 HMS 없이 다른 메타데이터 저장 방식도 지원
• Hive Metastore 대신 REST Catalog 또는 JDBC Catalog 사용 가능
• PostgreSQL, DynamoDB 등을 메타데이터 저장소로 직접 활용

catalog.s3-catalog.type=jdbc
catalog.s3-catalog.connection-url=jdbc:postgresql://metastore-db:5432/iceberg
Iceberg가 직접 PostgreSQL을 사용하여 메타데이터 관리

• Trino, Spark 등이 HMS 없이 PostgreSQL을 직접 조회

카탈로그(Catalog)와 메타데이터(Metadata)의 개념 차이

개념	설명	예시
카탈로그 (Catalog)	데이터베이스 객체(테이블, 뷰 등)를 관리하는 논리적 컨테이너	Iceberg Catalog, Hive Metastore(HMS), Glue Catalog
메타데이터 (Metadata)	데이터를 설명하는 정보로, 구조, 위치, 스키마 등을 포함	테이블 스키마, 파일 위치, 파티션 정보

카탈로그(Catalog)

• 카탈로그는 데이터를 조직화하는 시스템, 메타데이터는 데이터를 설명하는 정보이다.
• 데이터베이스, 테이블, 뷰 등의 객체를 조직화하고 관리하는 역할
• 데이터를 저장하는 시스템이 아닌, 데이터를 찾고 접근할 수 있도록 정리하는 추상적인 개념
• 일반적으로 메타데이터를 저장하고, 조회하는 API를 제공

SHOW CATALOGS;

• 카탈로그의 종류
• • Hive Metastore (HMS) → Hive 기반 메타데이터 저장
• • AWS Glue Catalog → AWS 데이터 레이크의 메타데이터 관리
• • Iceberg REST Catalog → Iceberg 테이블을 관리하는 API 기반 카탈로그
• • Trino의 File-based Catalog → JSON/YAML 파일로 카탈로그 관리

메타데이터(Metadata)

• 데이터 자체가 아닌, 데이터에 대한 설명

• • 테이블의 컬럼 정보, 데이터 타입, 파일 경로, 파티션, 버전 이력 등을 포함
• • 일반적으로 카탈로그 내부에 저장됨

• 예제 (Trino에서 Iceberg 테이블 메타데이터 조회)

SELECT * FROM iceberg.information_schema.tables WHERE table_name = 'my_table';

• 특정 테이블의 위치, 포맷, 생성 시간, 파티션 정보 등을 조회 가능

• 메타데이터의 종류

• • 스키마 정보 (컬럼명, 데이터 타입)
• • 파티션 정보 (분할 기준, 물리적 위치)
• • 파일 위치 (S3 경로, HDFS 경로 등)
• • 버전 이력 (Iceberg의 Snapshot 정보)

HMS는 카탈로그인가 메터데이터 관리 시스템인가

HMS(Hive Metastore Service)는 메타데이터 관리 시스템이다. 하지만, 일부 맥락에서는 카탈로그 역할도 수행할 수 있다.

메타데이터 관리 시스템 (Metadata Management System) 역할

테이블, 데이터베이스, 파티션, 스키마 등의 메타데이터를 저장하고 관리한다. 즉, 데이터 자체가 아니라, 데이터에 대한 정보를 관리하는 시스템이다.

• HMS가 저장하는 메타데이터 예시:
• • 데이터베이스 정보 (SHOW DATABASES;)
• • 테이블 구조 (스키마) (SHOW CREATE TABLE my_table;)
• • 파일 경로 (HDFS, S3, MinIO 등) (DESCRIBE FORMATTED my_table;)
• • 파티션 정보 (SHOW PARTITIONS my_table;)

HMS는 카탈로그 역할

Hive, Trino, Spark 같은 엔진이 HMS를 "카탈로그"처럼 사용할 수 있다.
즉, HMS가 메타데이터를 저장하면서, 동시에 이를 조회하고 관리할 수 있도록 API를 제공하며 "Hive 카탈로그" 역할을 수행한다.

• Trino에서 HMS를 카탈로그로 사용하는 경우 예시

SHOW TABLES FROM hive.default;

• • 여기서 hive는 HMS를 백엔드로 사용하는 Trino의 카탈로그
• • HMS가 메타데이터를 저장하고, Trino가 이를 조회하는 구조

Hive Metastore의 한계

Hive Metastore는 전통적인 Hive 테이블을 관리하는 용도로 설계되었다. 이로인해 Iceberg, Delta Lake, Hudi 같은 최신 테이블 포맷을 지원하는 데 여러 한계가 있다.

Hive Metastore의 주요 문제점

• ACID 트랜잭션 미지원 → Iceberg, Delta Lake처럼 강력한 트랜잭션을 지원하지 않음
• 스냅샷 기반 테이블 관리 불가능 → Hive 테이블은 스키마 변경과 롤백이 어려움
• Object Storage 최적화 부족 → S3/MinIO 같은 오브젝트 스토리지에서 성능이 떨어짐
• Partition Evolution 미지원 → 파티션 변경이 어려움 (예: 날짜 형식 변경 등)

iceberg 카탈로그로 hive를 사용하면 acid가 지원된다

Iceberg 카탈로그로 Hive Metastore(HMS)를 사용하더라도 Iceberg의 ACID 기능은 지원된다. 다만, HMS 기반 Iceberg 카탈로그는 몇 가지 제약이 있을 수 있다.

Iceberg에서 ACID 지원 여부

Iceberg는 ACID 트랜잭션을 지원하는 테이블 포맷이다. 즉, Hive Metastore를 사용하든, Iceberg 전용 카탈로그(REST, JDBC, DynamoDB 등)를 사용하든 ACID 트랜잭션은 항상 지원된다.

Iceberg의 주요 ACID 기능

• Snapshot Isolation → 동일한 테이블을 여러 트랜잭션에서 읽고 쓸 수 있음
• Atomic Commit → 테이블 변경이 원자적으로 적용됨 (쓰기 충돌 방지)
• Time Travel → 특정 시점의 데이터로 롤백 가능
• Schema Evolution → 테이블 스키마를 안전하게 변경 가능

Iceberg에서 사용할 수 있는 카탈로그 유형

Iceberg는 다양한 카탈로그를 지원하는데, Hive Metastore도 그중 하나이다.

Iceberg 카탈로그 유형	설명	특징
Hive 카탈로그	HMS를 사용하여 Iceberg 테이블 메타데이터 관리	Trino, Spark 등에서 쉽게 사용 가능, 기존 HMS 인프라 활용
REST 카탈로그	Iceberg 전용 REST API 기반	확장성이 좋고 클라우드 친화적
JDBC 카탈로그	PostgreSQL, MySQL 등에서 Iceberg 메타데이터 관리	데이터베이스 기반으로 메타데이터 저장
DynamoDB 카탈로그	AWS DynamoDB 사용	AWS 환경에서 사용 최적화

Hive Metastore 기반 Iceberg 카탈로그의 한계점

Hive Metastore를 Iceberg 카탈로그로 사용할 경우, Iceberg의 ACID 기능은 정상적으로 동작하지만 몇 가지 제약이 있다.

Hive Metastore 기반 Iceberg 카탈로그의 단점

• Concurrent Write Issue → 다중 사용자/엔진 환경에서 동시 쓰기 성능이 낮음
• Hive는 스냅샷 관리 최적화가 부족함 → Iceberg의 Time Travel 기능이 비효율적
• Partition Evolution 제한 → 일부 파티션 기능이 Hive Metastore에서는 원활하지 않을 수 있음

iceberg 카탈로그로 hive 카탈로그를 사용할 때 생기는 문제점

Hive 메타스토어를 Iceberg 카탈로그의 메타데이터 저장소로 사용하는 경우, 일부 특성 때문에 성능이나 확장성에 영향을 미칠 수 있다. 이를 잘 이해하면 최적화 방법을 고려할 수 있다.

성능 문제의 주요 원인

Hive 메타스토어의 성능 병목

Hive 메타스토어는 기본적으로 RDBMS(예: MySQL, PostgreSQL, MariaDB 등) 또는 HDFS와 같은 분산 시스템에 테이블 메타데이터를 저장한다. Iceberg가 Hive 메타스토어를 사용할 경우, 메타데이터 관리에서 성능 저하가 발생할 수 있다.

RDBMS 기반의 Hive 메타스토어는 대규모 데이터에 대해 성능 문제가 발생할 수 있다. 특히, 테이블 수가 많거나 복잡한 쿼리가 자주 실행되면 메타스토어 접근이 느려질 수 있다.

• 성능 저하의 원인:
• • 쓰기/읽기 작업: 대규모 테이블에서 메타데이터 읽기/쓰기 작업이 빈번하게 발생하면, RDBMS에 부하를 줄 수 있다. 이는 트랜잭션을 처리하는 데 추가적인 시간 지연을 초래한다.
• • 동시성 문제: 여러 프로세스가 동시에 메타데이터를 읽고 쓰는 경우, 동시성 이슈가 발생하여 락(lock) 문제가 생길 수 있다. 특히 대규모 병렬 처리를 할 때 Hive 메타스토어는 성능 병목이 될 수 있다.

메타데이터 복잡성

Iceberg는 스냅샷 및 버전 관리를 사용하여 테이블의 메타데이터를 관리한다. 이 과정에서 메타데이터가 매우 복잡해지고, 커질 수 있다. Hive 메타스토어는 복잡한 스냅샷과 버전 관리를 처리하는 데 최적화되어 있지 않아서, 메타데이터 쿼리나 스냅샷 조회가 비효율적일 수 있다.

특히 스냅샷 수가 많을수록 메타데이터를 처리하는데 더 많은 시간이 걸릴 수 있으며, 이로 인해 쿼리 성능 저하나 쓰기 지연이 발생할 수 있다.

ACID 트랜잭션 처리의 비효율성

Iceberg는 ACID 트랜잭션을 완벽하게 지원하는 반면, Hive 메타스토어는 ACID 트랜잭션을 지원하는데 제약이 있을 수 있다. Iceberg는 동시성을 관리하고, 트랜잭션을 스냅샷 단위로 처리하지만, Hive 메타스토어는 이를 위한 추가적인 최적화가 부족하다.

트랜잭션 충돌이나 동시 작업에서 발생하는 비효율성이 Hive 메타스토어에서 발생할 수 있으며, 이는 데이터 일관성이나 성능 저하로 이어질 수 있다.

성능 문제 해결 방법

메타스토어의 성능 개선

Hive 메타스토어가 RDBMS를 사용할 경우, 해당 데이터베이스의 성능 최적화가 중요하다. 예를 들어, 인덱싱을 추가하거나, 쿼리 성능을 개선하는 방법을 사용할 수 있다.

쿼리 캐싱을 사용하여 자주 조회되는 메타데이터에 대해 성능을 향상시킬 수 있다.

메타스토어 RDBMS 성능을 튜닝하거나, 복제 및 분산 구성을 통해 확장성을 높일 수 있다.

Iceberg 전용 카탈로그 사용 고려

Hive 메타스토어 대신 Iceberg 카탈로그를 사용하면, 메타데이터 관리 및 ACID 트랜잭션을 보다 효율적으로 처리할 수 있다. Iceberg는 스냅샷 기반의 메타데이터 관리를 제공하며, 대규모 데이터에 대해서도 성능을 최적화할 수 있는 방식이다.

Iceberg 카탈로그를 사용하면 메타데이터를 효율적으로 관리할 수 있고, 복잡한 트랜잭션 처리에서도 성능을 높일 수 있다.

메타데이터 분리 및 최적화

Iceberg에서 관리되는 메타데이터의 크기와 복잡도를 줄이기 위해 스냅샷의 수를 관리하거나, 정기적인 메타데이터 정리(예: 불필요한 스냅샷 제거)를 고려할 수 있다.

메타데이터 저장소에 대한 분산 처리를 통해 성능을 개선할 수 있다.

트랜잭션 처리 개선

트랜잭션 관리에서 성능을 개선하려면, Iceberg에서 제공하는 ACID 지원을 효율적으로 사용해야 한다. 예를 들어, 스냅샷 격리 수준을 적절히 조정하거나, 트랜잭션 처리의 최적화 방법을 고려할 수 있다.

s3가 RDBMS보다 느린데 병렬처리로 인해 더 효과적으로 사용할 수 있다

RDBMS는 빠른 단일 데이터 조회와 트랜잭션에 강점이 있지만, 대규모 데이터 처리와 분산 시스템에서는 객체 스토리지(S3)가 효과적일 수 있다. Iceberg는 병렬 처리와 효율적인 메타데이터 관리를 통해 S3와 같은 객체 스토리지의 느린 성능을 어느 정도 극복할 수 있으며, 대규모 데이터 처리에서는 병렬 처리와 파일 최적화를 통해 성능 향상을 이끌어낼 수 있다.

객체 스토리지(S3)의 특징과 RDBMS의 차이점

RDBMS는 데이터를 테이블 형식으로 관리하며, 인덱싱, 캐싱, 트랜잭션 관리 등 여러 최적화 기술을 활용하여 빠른 쿼리 성능을 제공한다. 특히 저지연 데이터 액세스가 가능하고, 인메모리 기반의 최적화 기법을 사용할 수 있다.

S3와 같은 객체 스토리지는 데이터를 파일 단위로 저장한다. 이 방식은 저지연 액세스와 인덱스 관리가 부족해 단일 파일 조회 시 상대적으로 느릴 수 있다. 또한 객체 스토리지는 파일 시스템이 아니기 때문에, RDBMS처럼 상세한 쿼리 최적화나 인덱스가 지원되지 않는다.

Iceberg의 병렬 처리와 성능 최적화

Iceberg는 객체 스토리지에 저장된 데이터를 다룰 때, 병렬 처리와 효율적인 파일 관리 기법을 통해 성능을 최적화한다. 즉, 객체 스토리지가 느릴 수 있지만, 분산 처리 시스템(예: Trino, Spark 등)을 사용하여 병렬로 데이터를 처리하면 전체 성능을 효과적으로 향상시킬 수 있다.

병렬 처리

Iceberg는 분산 처리를 통해 데이터를 병렬로 읽고 쓰는 방식을 사용한다. 데이터를 여러 파트로 분할하고, 각 파트에 대해 독립적으로 병렬 처리를 수행함으로써 S3와 같은 객체 스토리지의 속도 제한을 상쇄할 수 있다.

트리거된 쿼리에 대해 여러 워커가 동시에 데이터를 읽고 쓰기 때문에 I/O 병목 현상을 최소화할 수 있다.

효율적인 파일 관리

Iceberg는 데이터를 파일 단위로 관리하는 대신, 테이블 단위로 데이터를 효율적으로 관리한다. 이를 통해 불필요한 데이터 읽기를 줄이고, 스냅샷 관리를 통해 특정 버전의 데이터만 효율적으로 읽을 수 있다.

파일 포맷(예: Parquet)을 사용해 데이터를 저장하면, 객체 스토리지에서 쿼리 성능을 최적화할 수 있다. Parquet는 컬럼형 저장 방식을 사용하여 데이터를 필요한 열만 읽기 때문에 불필요한 데이터 액세스를 줄일 수 있다.

분산 파일 시스템 관리

Iceberg는 파일 시스템을 관리하는 방식에서 분산 파일 시스템의 이점을 활용한다. 예를 들어, 파일을 작은 조각으로 나누어 여러 서버에서 병렬로 읽고 쓰는 방식으로 속도를 개선할 수 있다.

객체 스토리지는 비록 RDBMS보다는 느리지만, 대규모 데이터 처리에서는 분산 처리와 효율적인 데이터 분할로 이러한 성능 차이를 어느 정도 극복할 수 있다.

최적화된 메타데이터 관리

Iceberg는 스냅샷과 버전 관리를 통해 변경된 데이터만 조회하거나, 과거의 데이터를 효율적으로 검색할 수 있다. 이를 통해 객체 스토리지의 I/O를 절약하고, 성능을 개선할 수 있다.

데이터 청크 크기 최적화

Iceberg는 파일 단위로 데이터를 효율적으로 분할하고, 각 파일을 최적화된 크기로 유지한다. 이를 통해, 데이터를 병렬로 읽고 쓰는 과정에서 속도 차이를 줄일 수 있다.

성능 차이를 해결하는 방식

RDBMS의 고속 액세스가 필요한 경우에는 온디맨드 처리나 인메모리 데이터베이스가 적합하지만, 대규모 데이터를 분산 처리해야 할 경우에는 객체 스토리지(S3)와 Iceberg와 같은 시스템이 적합할 수 있다. 특히, 병렬 처리와 효율적인 파일 관리로 I/O 병목을 최소화할 수 있기 때문이다.

S3에서의 데이터 처리 성능은 분명히 단일 파일 처리에 있어 RDBMS보다 느릴 수 있지만, Iceberg의 스냅샷 관리, 파일 단위 관리, 병렬 처리로 성능 저하를 상쇄하고 대규모 데이터를 효율적으로 관리할 수 있다.