📗Lakehouse개요

🏳️‍🌈 [궁금한점]

• 왜 Lakehouse를 써야 할까
• 카탈로그는 무엇인가

---

🔗[목차]

• Lakehouse 개요
  • Lakehouse 배경 및 필요성
  • Lakehouse 아키텍처의 주요 특징
  • Lakehouse 구성 요소 예시
  • Lakehouse 장점
  • 대표 기술 스택 비교
• Lakehouse 아키텍처
  • 기존 아키텍처 문제점
  • 핵심 기술 요소
  • 아키텍처 주요 특징
  • 아키텍처 구현 예시
  • 아키텍처 장점 vs 단점
• 카탈로그
  • 카탈로그 개요
    • 카탈로그의 정의
    • 주요 역할
    • 카탈로그의 유형
    • 레이크하우스에서의 카탈로그의 중요성
  • Iceberg 카탈로그
    • 주요 Iceberg 카탈로그 종류
    • 카탈로그 활용
  • hive catalog
    • HiveCatalog 구성 구조
    • HiveCatalog 특징
    • HiveCatalog 사용 시 장점
    • HiveCatalog 한계점
    • hive catalog는 hdfs를 사용하나

Lakehouse 개요

Lakehouse는 데이터 웨어하우스(Data Warehouse) 와 데이터 레이크(Data Lake) 의 장점을 결합한 차세대 데이터 아키텍처이다. 이름 그대로 "Lake(호수) + House(창고)"의 개념으로, 유연한 저장소와 강력한 분석 기능을 모두 제공하고자 등장했다.

Lakehouse는 특히 데이터 엔지니어링, ML, BI를 하나의 플랫폼에서 통합하려는 조직에 매우 유용하다.

Lakehouse 배경 및 필요성

Data Lake는 구조화되지 않은 대규모 데이터를 저렴하게 저장할 수 있지만, 데이터 품질 관리, 스키마 관리, 쿼리 성능에서 한계가 있었다.
Data Warehouse는 구조화된 데이터를 빠르게 분석할 수 있지만, 저장 비용이 높고 비정형 데이터 처리에 약했다.
이를 보완하기 위해 등장한 것이 Lakehouse Architecture이다.

Lakehouse 아키텍처의 주요 특징

항목	설명
단일 저장소	정형, 반정형, 비정형 데이터를 모두 하나의 스토리지(S3, HDFS 등)에 저장
오픈 포맷	Parquet, ORC, Iceberg, Delta Lake 등 오픈 포맷 사용
트랜잭션 지원	ACID 트랜잭션 지원으로 안정적인 데이터 처리 가능
카탈로그 관리	Hive Metastore, Unity Catalog, AWS Glue 등으로 테이블 관리
고성능 쿼리 엔진	Trino, Apache Spark, Dremio 등으로 빠른 쿼리 실행 가능
ML/BI 통합	ML 모델 훈련과 BI 분석 모두 같은 데이터 소스에서 수행 가능

Lakehouse 구성 요소 예시

• 스토리지: Amazon S3, Azure Data Lake, MinIO
• 포맷: Apache Iceberg, Delta Lake, Hudi
• 엔진: Apache Spark, Trino, Presto, Flink
• 메타스토어: Hive Metastore, AWS Glue
• 오케스트레이션: Airflow, Dagster
• BI/ML 도구: Tableau, PowerBI, Jupyter, DBT

Lakehouse 장점

• 단일 데이터 사일로: 운영/분석 데이터를 동일한 플랫폼에서 처리
• 유연성: 다양한 워크로드(ETL, ML, BI)에 대응
• 비용 효율성: 저렴한 오브젝트 스토리지 + 오픈소스 생태계
• 확장성: 페타바이트 급 데이터 처리에 적합

대표 기술 스택 비교

항목	Data Lake	Data Warehouse	Lakehouse
저장 포맷	Parquet, JSON	Columnar (Proprietary)	Parquet + Table Format (Iceberg 등)
쿼리	느림	빠름	빠름
트랜잭션	없음	있음	있음
ML 지원	강함	약함	강함
스키마 강제	약함	강함	강함

Lakehouse 아키텍처

레이크하우스(Lakehouse) 아키텍처는 데이터 웨어하우스(DW) 와 데이터 레이크(Data Lake) 의 장점을 결합한 차세대 데이터 관리 구조이다. 대규모 데이터를 유연하게 저장하면서도, 분석·BI·머신러닝 용도로 활용 가능한 일관성과 성능을 제공한다.

기존 아키텍처 문제점

• Data Lake: 확장성과 유연성은 뛰어나나, 스키마 없음, 데이터 정합성·품질 부족
• Data Warehouse: 정형 데이터 처리에 뛰어나나, 유연성 부족, 비용 증가
  → Lakehouse는 이 둘의 단점을 극복하고 장점을 결합

핵심 기술 요소

구성 요소	설명
Object Storage	저렴하고 확장 가능한 저장소 (S3, MinIO 등)
Table Format	Iceberg, Delta Lake, Hudi → ACID 트랜잭션, 스냅샷, 스키마 진화 등 지원
Catalog	테이블 및 메타데이터 관리 (HMS, Glue, Nessie 등)
Query Engine	대화형 쿼리 및 분석 처리 (Trino, Spark, Flink 등)
BI/ML 도구	Tableau, Superset, Jupyter, Pandas 등과 연결 가능

아키텍처 주요 특징

특징	설명
ACID 지원	Iceberg 등의 테이블 포맷이 트랜잭션, 롤백 등 제공
스키마 진화	컬럼 추가/변경 등 구조 변경이 안전하게 가능
타입 혼합	정형/반정형/비정형 데이터 혼합 처리
고속 쿼리	컬럼 프루닝, 파티셔닝, Z-order 정렬 등으로 최적화
오픈 포맷	Parquet, ORC, Avro 등의 표준 포맷 사용 가능

아키텍처 구현 예시

스택	설명
MinIO + Iceberg + Hive Metastore + Trino	오픈소스로 레이크하우스 구축, 비용 효율 높음
AWS S3 + Glue + Athena / EMR + Iceberg	서버리스 또는 Spark 기반 고도화 환경
Databricks (Delta Lake)	상업적 완성도 높지만 비용 있음

아키텍처 장점 vs 단점

장점	단점
비용 절감 (object storage 기반)	초기 구성 복잡도
확장성 우수	성능 튜닝 필요
다양한 도구와 연계	Table Format 이해 필요
데이터 품질 및 거버넌스 향상

카탈로그

카탈로그 개요

레이크하우스(Lakehouse) 아키텍처에서 카탈로그(Catalog) 는 데이터를 구조적으로 관리하고, 쿼리 엔진과의 연결을 가능하게 해주는 핵심 구성 요소다.

카탈로그의 정의

레이크하우스 카탈로그는 데이터 레이크에 저장된 테이블, 뷰, 파티션, 스키마 등의 메타데이터를 관리하는 시스템이다. 데이터베이스의 메타데이터 관리 기능과 유사하지만, S3나 HDFS 같은 오브젝트 스토리지에 저장된 데이터를 대상으로 한다.

주요 역할

• 테이블 스키마 관리: 컬럼 이름, 타입, 파티션 정보 등을 유지
• 데이터 위치 추적: 테이블이나 파티션이 어느 경로(S3 URI 등)에 저장돼 있는지 추적
• 버전 관리 및 트랜잭션 지원: Iceberg, Delta Lake 같은 포맷에서는 스냅샷 및 ACID 트랜잭션을 지원
• 쿼리 엔진 연동: Trino, Spark, Flink 등이 카탈로그를 통해 테이블을 조회하거나 조작할 수 있음

카탈로그의 유형

• Hive Metastore: 전통적인 카탈로그, Iceberg나 Delta Lake에서 지원
• Nessie / AWS Glue / Unity Catalog: 클라우드 네이티브 또는 버전 관리 강화형 카탈로그
• Iceberg Catalog: JDBC, Hive, REST 등을 통해 자체적으로 구현 가능
• Hudi: 자체 메타데이터 시스템 포함

레이크하우스에서의 카탈로그의 중요성

• 다양한 엔진 간 호환성 확보
• 데이터 일관성 보장 및 트랜잭션 추적
• 스키마 진화, 타임 트래블, 데이터 거버넌스 등의 고급 기능 지원

Iceberg 카탈로그

Iceberg는 다양한 카탈로그 백엔드를 지원하며, 이 중 Hive Metastore(HMS), REST, JDBC, Nessie 등이 자주 사용된다.

Iceberg 테이블은 아래 계층 구조로 관리된다

카탈로그 (Catalog)
 └── 데이터베이스 (Namespace / DB)
      └── 테이블 (Iceberg Table)
           └── 스냅샷, 매니페스트, 데이터 파일 등

주요 Iceberg 카탈로그 종류

유형	설명	사용 예시
HiveCatalog	Hive Metastore를 사용	Trino, Spark에서 가장 많이 사용
HadoopCatalog	파일 시스템 기반 카탈로그	Hive 없이 사용 가능
RESTCatalog	REST API로 구현된 Iceberg 네이티브 카탈로그	클라우드 환경, Nessie 연동
JDBCCatalog	JDBC 연결로 RDB에 메타데이터 저장	PostgreSQL, MySQL 등
NessieCatalog	Git처럼 브랜치/버전 관리	고급 거버넌스 및 협업 시 사용

예시: HiveCatalog 구성 (Trino + HMS + MinIO)

connector.name=iceberg
iceberg.catalog.type=hive
hive.metastore.uri=thrift://hive-metastore:9083
iceberg.file-format=parquet
hive.s3.endpoint=http://minio:9000
hive.s3.aws-access-key=minioadmin
hive.s3.aws-secret-key=minioadmin
hive.s3.path-style-access=true

이 구성은 Trino가 Iceberg 테이블을 Hive Metastore를 통해 인식하고, 데이터는 MinIO(S3) 에 저장된다.

예시: HadoopCatalog 구성 (Spark 단독)

spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.my_catalog.type=hadoop
spark.sql.catalog.my_catalog.warehouse=s3a://my-bucket/warehouse

이 방식은 Hive 없이도 Iceberg를 사용 가능하지만, 데이터베이스/테이블 정보를 디렉토리 구조로 관리한다.

카탈로그 활용

목적	추천 카탈로그
Hive와 연동 (Trino/Spark 공용)	HiveCatalog
Hive 없이 간단하게	HadoopCatalog
데이터 브랜치/버전 관리	NessieCatalog
커스텀 메타데이터 저장소 사용	JDBCCatalog

hive catalog

HiveCatalog는 Apache Iceberg에서 가장 널리 사용되는 카탈로그 중 하나로, Hive Metastore(HMS) 를 백엔드로 사용하는 카탈로그이다. HiveCatalog는 기존 Hive 환경을 그대로 활용하면서 Iceberg의 기능(스냅샷, 트랜잭션, 스키마 진화 등)을 사용할 수 있게 해준다.

• 메타데이터 저장소로 Hive Metastore를 사용
• 테이블 및 데이터베이스 구조를 HMS에 저장
• Iceberg 테이블은 HMS에 등록되지만, 실제 데이터는 S3, HDFS, MinIO 등에 저장

HiveCatalog 구성 구조

Hive Metastore
 └── Database (Namespace)
      └── Table (Iceberg Table)
           ├── Metadata 파일 (S3 또는 HDFS)
           └── Data 파일 (Parquet, ORC 등)

Hive Metastore는 테이블의 논리 정보(이름, 위치) 만 저장

Iceberg의 메타데이터 파일들은 스토리지(S3/MinIO 등)에 저장

HiveCatalog 특징

항목	설명
호환성	Trino, Spark, Flink 등 다양한 엔진에서 공통으로 사용 가능
ACID 트랜잭션	Iceberg 포맷이 제공, HMS는 단순 메타 저장
S3 호환	MinIO, AWS S3, HDFS 등 다양한 저장소와 연결 가능
의존성	HMS 서비스가 반드시 필요함

HiveCatalog 사용 시 장점

• 중앙 집중형 메타데이터 관리: 다양한 엔진에서 동일한 테이블을 참조 가능
• 레거시 Hive 테이블과의 연계 가능
• 트랜잭션 안전한 데이터 관리 (Iceberg 덕분에)

HiveCatalog 한계점

• Hive Metastore가 반드시 항시 가동 중이어야 하며, 네트워크로 접근 가능해야 함
• Metastore의 버전 호환성 주의 (특히 Trino, Spark 등과)

hive catalog는 hdfs를 사용하나

HiveCatalog 자체가 HDFS를 반드시 사용하는 것은 아니다. HiveCatalog는 메타데이터 저장소로 Hive Metastore(HMS) 를 사용하고,
데이터 파일과 Iceberg 메타데이터 파일은 HDFS, S3, MinIO 등 원하는 스토리지에 저장할 수 있다.

구성 요소	저장 위치	설명
Hive Metastore (HMS)	RDB (MySQL/PostgreSQL 등)	테이블 이름, 위치, 스키마 등의 메타데이터를 저장
Iceberg 메타데이터 파일	HDFS 또는 S3/MinIO 등	.metadata.json, 스냅샷 등 Iceberg 특유의 정보
실제 데이터 파일	HDFS 또는 S3/MinIO 등	Parquet/ORC 등의 포맷으로 저장됨