카탈로그 소개

데이터 레이크의 카탈로그 서비스는 데이터의 메타데이터를 관리하는 중요한 컴포넌트로, 데이터셋을 탐색하고 이해하며 효율적으로 사용할 수 있도록 돕는 역할을 한다. 이를 통해 데이터를 저장소에 저장하는 것뿐만 아니라, 데이터의 구조와 변화를 추적하고, 접근 제어를 적용하며, 다양한 분석 엔진과 연동할 수 있다.

• 카탈로그 서비스 활용 예시
• • 데이터 엔지니어: 새로운 데이터셋 등록 및 관리
• • 데이터 분석가: 필요한 데이터를 쉽게 검색하여 활용
• • 데이터 사이언티스트: 모델 학습용 데이터 탐색 및 버전 관리
• • 보안 팀: 민감한 데이터 접근 제어 및 감사

🏳️‍🌈 [궁금한점]

• 카탈로그 서비스는 어떤 역할을 할까
• 카탈로그 서비스 제품 선정을 위해 고려해야 할 점은 무엇일까

---

🔗[목차]

• 카탈로그 소개
• 🔗[목차]
• 카탈로그 서비스 주요 기능
  • 메타데이터 관리
  • 데이터 검색 및 탐색
  • 데이터 거버넌스 및 보안
  • 다양한 분석 엔진과의 연동
• 주요 카탈로그 서비스 및 솔루션
  • 솔루션 종류
    • AWS Glue Data Catalog
    • Apache Hive Metastore
    • Apache Iceberg Catalog
    • Apache Hudi Catalog
    • Delta Lake Catalog (Unity Catalog)
  • 주요 솔루션 비교
  • 선택 가이드
  • 카탈로그 제품 선정에 고려해야 할 주요 요소
    • 성능(읽기/쓰기 성능)
    • 확장성 및 유지보수 용이성
    • 분석 엔진과의 호환성
    • 데이터 거버넌스 및 보안
• (최적화) 카탈로그 서비스가 미치는 성능 영향
  • 성능 개선 책
    • 읽기(조회) 성능에 미치는 영향
    • 읽기 속도 개선
    • 읽기 속도 저하 가능성
    • 쓰기(삽입/업데이트) 성능에 미치는 영향
    • 쓰기 성능 개선
    • 쓰기 성능 저하 가능성
  • Hive vs Iceberg 속도 비교

카탈로그 서비스 주요 기능

메타데이터 관리

• 테이블 스키마(컬럼명, 타입 등) 저장
• 데이터 위치(파일 경로, 오브젝트 스토리지 URI 등) 추적
• 데이터 버전 관리 및 변경 사항 추적

데이터 검색 및 탐색

• 데이터셋 및 테이블 목록 제공
• 태그, 설명, 샘플 데이터를 통한 검색 기능

데이터 거버넌스 및 보안

• 접근 제어 및 권한 관리 (예: RBAC, IAM)
• 데이터 감사를 위한 로그 및 이력 관리

다양한 분석 엔진과의 연동

• Presto, Trino, Spark, Flink, Hive, Dremio 등과 호환
• 다양한 스토리지 포맷 지원 (Parquet, ORC, Avro 등)

주요 카탈로그 서비스 및 솔루션

솔루션 종류

AWS Glue Data Catalog

• AWS의 관리형 서비스
• S3 데이터 레이크 및 Redshift, Athena 등과 통합
• 크롤러를 사용하여 자동으로 데이터셋 등록 가능

Apache Hive Metastore

• Hive에서 시작된 메타데이터 저장소
• Spark, Presto, Trino에서도 사용 가능
• RDBMS(MySQL, PostgreSQL 등)를 백엔드로 활용

Apache Iceberg Catalog

• 테이블 포맷과 함께 제공되는 메타데이터 관리 기능
• Spark, Flink, Trino와 네이티브 통합
• REST API를 통한 확장성 제공

Apache Hudi Catalog

• 스트리밍 데이터 처리와 버전 관리를 지원
• 변경 데이터 캡처(CDC) 기능 내장
• Hive Metastore 또는 AWS Glue와 연동 가능

Delta Lake Catalog (Unity Catalog)

• Databricks에서 제공하는 관리형 카탈로그
• Delta Table과 연동하여 ACID 트랜잭션 지원
• 멀티 클라우드 환경에서 데이터 공유 가능

주요 솔루션 비교

솔루션	읽기 성능	쓰기 성능	확장성	호환성	거버넌스
Hive Metastore	보통 (RDBMS 성능 의존)	보통 (Lock 이슈 발생 가능)	제한적 (DB 성능 문제)	Spark, Presto, Hive 등	기본 RBAC
AWS Glue	빠름 (Fully Managed)	빠름 (Serverless)	매우 우수	AWS Athena, Redshift 등	IAM 기반 보안
Iceberg Catalog	빠름 (트랜잭션 최적화)	매우 빠름 (Snapshot, Merge-on-Read)	우수 (REST API, 다양한 백엔드 지원)	Spark, Flink, Trino 기본 지원	강력한 버전 관리
Delta Lake (Unity Catalog)	빠름 (Databricks 최적화)	빠름 (ACID 지원)	우수 (Databricks 기반)	Spark 최적화, ML 연계 강함	강력한 정책 적용 가능
Hudi Catalog	빠름 (Streaming 최적화)	빠름 (Incremental Processing)	우수 (Streaming 지원)	Spark, Flink와 연계 강함	변경 데이터 추적

선택 가이드

• Spark, Presto, Flink 기반 분석을 고려한다면 → Iceberg Catalog
• AWS 중심의 데이터 레이크라면 → AWS Glue
• 데이터 변경(UPSERT, DELETE)이 많다면 → Delta Lake, Hudi
• 오픈소스 및 유연성이 필요하다면 → Iceberg REST Catalog

카탈로그 제품 선정에 고려해야 할 주요 요소

성능뿐만 아니라 확장성, 관리 용이성 등 다양한 측면을 균형 있게 고려해야 한다.

성능(읽기/쓰기 성능)

• 읽기 성능

• • 메타데이터 조회 속도: 테이블 스키마, 파티션 정보, 파일 위치 등을 빠르게 조회할 수 있는가?
• • 쿼리 최적화 지원: 카탈로그가 프루닝(Partition Pruning, Predicate Pushdown 등)을 지원하는가?
• • 캐싱 지원 여부: 메타데이터를 인메모리에 캐싱할 수 있는가?

• 쓰기 성능

• • 트랜잭션 처리 능력: 테이블 변경(INSERT, UPDATE, DELETE)이 많을 때 성능이 유지되는가?
• • 멀티 라이터 지원: 동시에 여러 개의 작업이 데이터를 삽입/수정할 때 충돌을 방지할 수 있는가?
• • ACID 트랜잭션 지원: 데이터 일관성을 보장할 수 있는가?

확장성 및 유지보수 용이성

• 확장성
• • 대량 데이터 처리 지원: 수십억 개 이상의 파일과 메타데이터를 처리할 수 있는가?
• • 분산 아키텍처 지원: 단일 노드(RDBMS 기반)뿐만 아니라 분산 환경에서도 안정적으로 동작하는가?
• 유지보수 용이성
• • 운영 복잡도: 설치 및 유지보수가 쉬운가? (예: AWS Glue는 관리형, Hive Metastore는 직접 운영)
• • 백업 및 복구 지원: 메타데이터를 안전하게 백업하고 복구할 수 있는가?

분석 엔진과의 호환성

• Spark, Flink, Presto, Trino, Hive 등과 연동이 쉬운가?
• ML/AI 프레임워크(PyTorch, TensorFlow)와 통합 가능한가?
• 쿼리 엔진에서 기본 지원하는가? (예: Spark SQL에서 Iceberg는 기본 지원)

데이터 거버넌스 및 보안

• Access Control: RBAC(Role-Based Access Control), ABAC(Attribute-Based Access Control) 지원 여부
• 감사 로깅(Audit Logs): 데이터 변경 및 접근 내역을 추적할 수 있는가?
• 데이터 암호화 및 마스킹 지원: 민감 데이터 보호를 위한 기능이 있는가?

(최적화) 카탈로그 서비스가 미치는 성능 영향

카탈로그 서비스는 메타데이터를 관리하는 역할을 하며, 데이터 조회 및 쓰기 성능에 영향을 줄 수 있다. 카탈로그 유형에 따라 장단점이 다르기 때문에 살펴볼 필요가 있다.

성능 개선 책

• 읽기 성능은 개선됨 (메타데이터 기반 조회, 파티션 최적화)
• 쓰기 성능은 경우에 따라 다름 (트랜잭션 관리 오버헤드 발생 가능)
• REST Catalog 사용 시 네트워크 오버헤드 존재 (규모가 커질수록 영향 커질 수 있음)
• 적절한 정리 작업 필요 (expire_snapshots, rewrite_manifest)

읽기(조회) 성능에 미치는 영향

카탈로그 서비스는 테이블의 메타데이터(파일 목록, 스키마, 파티션 정보)를 조회하는 단계에서만 성능에 영향을 줌.

읽기 속도 개선

• Iceberg는 스냅샷 기반 쿼리 최적화를 수행함.
• • Hive는 디렉터리를 직접 스캔하는 반면, Iceberg는 메타데이터 파일을 조회하여 필요한 데이터만 읽음.
• • HMS → Iceberg 전환 시, 쿼리 성능이 향상되는 경우가 많음.
• Iceberg는 Hidden Partitioning을 지원 → 파티션 프루닝 최적화 가능

읽기 속도 저하 가능성

• REST Catalog 사용 시, 네트워크 레이턴시 추가
• 대규모 테이블에서는 메타데이터 파일 크기 증가로 인해 조회 지연 가능
• • 해결책: expire_snapshots, rewrite_manifest 같은 정리 작업 필요

쓰기(삽입/업데이트) 성능에 미치는 영향

• Iceberg는 ACID 트랜잭션을 제공하기 때문에 기존 Hive보다 쓰기 성능이 저하될 수도 있음.

쓰기 성능 개선

• Merge-on-Read 방식 적용 → 실시간 데이터 처리 성능 향상
• Delta Commit 구조 → 병렬 쓰기 가능 (Hive보다 빠를 수 있음)

쓰기 성능 저하 가능성

• 트랜잭션 관리로 인한 오버헤드 발생
• • Hive는 파일을 단순 추가하는 방식이지만, Iceberg는 트랜잭션을 관리하기 때문에 추가적인 레이어가 생김.
• • REST Catalog 사용 시, 트랜잭션 정보를 주고받는 과정에서 네트워크 레이턴시 발생 가능.
• Compaction 필요
• • Iceberg는 작은 파일이 많아지면 성능이 저하될 수 있음 → 정기적인 병합 필요.

Hive vs Iceberg 속도 비교

비교 항목	Hive	Iceberg	결과
데이터 조회 속도	느림 (디렉터리 전체 조회)	빠름 (메타데이터 기반 조회)	Iceberg 우위
파티션 조회	느림 (Hive의 수동 파티셔닝)	빠름 (자동 파티션 프루닝)	Iceberg 우위
데이터 삽입 속도	빠름 (파일 추가)	느림 (트랜잭션 관리 필요)	Hive 우위
데이터 업데이트	불가능 (파일 재작성 필요)	가능 (Copy-on-Write, Merge-on-Read 지원)	Iceberg 우위
확장성	RDBMS(HMS) 의존	다양한 카탈로그 지원 (REST, Glue 등)	Iceberg 우위